[01:45] <House> does anyone have 16.04, sssd+AD & autofs mounting smb shares working? i've got ssh, login, /home/AD/user folder creation, & sudo. smbclient works with password, but not with -k and auto.smb is failing for the same reason.  any suggestions on troubleshooting kerberos tickets?
[02:48] <lunaphyte> what am i doing wrong here? http://dpaste.com/345PZV6.txt
[02:52] <k2gremlin> Hello all. I am trying to add monitoring to a plex server. PlexPy is functional if I manually launch the file. However, I am trying to get it to run as a daemon using this guide. https://github.com/drzoidberg33/plexpy/wiki/Install-as-a-daemon Followed the Ubuntu section but when I attempt to start the service, it tells me failed to start no such file or directory..
[02:54] <tarpman> lunaphyte: what would "right" look like? is /topic applicable?
[03:00] <lunaphyte> tarpman: ah, thanks.  yes, it is
[03:01] <lunaphyte> interesting.  has that always been like that?  i seem to remember it wasn't
[03:02] <lunaphyte> indeed - do-release-upgrade -d reveals an upgrade
[03:55] <John[Lisbeth]> I am doing a dist-upgrade on my vm. Teeming with excitement as this is my first dist-upgrade
[03:55] <sarnold> John[Lisbeth]: are you intending to use it to upgrade to a new release?
[03:55] <John[Lisbeth]> yeah and I kind of already typed it
[03:56] <sarnold> oops
[03:56] <John[Lisbeth]> lol
[03:56] <John[Lisbeth]> oh well this is just a throw-away vm anyway
[03:56] <sarnold> do-release-upgrade does a significantly better job :)
[03:56] <John[Lisbeth]> Yeah I forgot that one
[03:57] <sarnold> granted I use dist-upgrade daily on my systems, but that'sjust to upgrade from day to day.. not jumping releases
[03:57] <John[Lisbeth]> well this will be a good learning experience for me then
[03:57] <John[Lisbeth]> This is just a sort of mainframe I use so my cs peers and I can get into repls
[08:39] <heftig> how usable is LVM's integrated RAID?
[08:40] <heftig> I would prefer being able to select mirroring/striping per LV
[10:28] <norc> Hi. What is the defined behaviour of Ubuntu when no more memory can be allocated?
[10:28] <hateball> flush cache or start swapping, depending on how you've set vm.swappiness
[10:29] <hateball> if everything is full, crash :D
[10:29] <norc> hateball: I find that hard to believe that the operating system would crash.
[10:29] <norc> That would allow any application to straight crash the server by just malloc'ing until the server runs out.
[10:29] <ogra_> it calls OOM and starts killing processes
[10:29] <heftig> s/crash/sacrifice a random process/
[10:29] <hateball> Well, yea
[10:29] <norc> Random? Or is there some algorithm for selection?
[10:29] <ogra_> random usually
[10:30] <heftig> Yes, memory hogs are targeted first
[10:30] <ogra_> there are ways to hand an oom_score value to apps
[10:30] <heftig> Each process also has an attribute that modifies its likeliness to be picked
[10:30] <heftig> oom_killer_something
[10:30] <maswan> typically though, on a normal server, it is time to reboot after you've found the oom killing stuff
[10:31] <heftig> Or oom_score_adj or something like that
[10:31] <norc> Ah. Im guessing the amount of memory used is also a factor, so that memory hogs will be killed first unless that oom_score gives it some priority, right?
[10:31] <ogra_> well ... there are systems that use this as a feature ;)
[10:31] <ogra_> like android
[10:31] <maswan> yeah, thus my weasel words in the beginning. :)
[10:32] <heftig> Android uses the oom killer?
[10:32] <heftig> I thought the termination of paused background processes was at user level
[10:32] <ogra_> yep
[10:32] <ogra_> they patch it and call it lowmemory_killer though ...
[10:32] <ogra_> and yes, there is userspace involved too
[10:33] <ogra_> on a very low end server like an IoT device such a feature might actually even make sense :)
[10:34] <ogra_> (system reliability over app availability)
[10:35] <heftig> Well, those devices usually have relatively constant memory use
[10:37] <ogra_> yet :)
[10:37] <ogra_> just wasit til you can install a spotify proxy and owncloud on your heating controller which is also your NAS and wlan router ;)
[10:38] <heftig> Well, I would have it so potentially memory intensive/dynamic tasks in sequence
[10:38] <heftig> It do potentially
[10:43] <ogra_> in the above case you would want the heating and wlan serivices to be highly available and very fail ... while the others are possible to be killed
[11:00] <patdk-lap> yes, very annoying, when your are running like a database server, and some other program start eating ram, and OOM kills your database
[11:03] <ogra_> uh ... s/fail/failsafe/ :P
[14:04] <OlofL_> anyone setup nxfilter here?
[14:11] <spm_draget> Is this a known bug that phpmyadmin package fails to run because it is missing php-mbstirng and php-gettext packages? http://askubuntu.com/questions/760567/phpmyadmin-missing-mbstring-extention-ubuntu-16-04
[14:30] <spm_draget> Was there an update from <mysql-5.7 to mysql-5.7 on the ubuntu 16.04 release!?
[14:39] <frickler> spm_draget: yes
[14:40] <frickler> pretty late in the cycle I think with some fallout like https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1574509
[14:40] <rbasak> nacc: see http://askubuntu.com/questions/760567/phpmyadmin-not-working-due-to-missing-mbstring-extention from above. Should phpmyadmin be listing dependencies there?
[14:40] <spm_draget> I thought it was feature-freeze a few weeks before release.
[14:41] <spm_draget> It blew my jira/confluence installation, too. Meh!
[14:42] <teward> spm_draget: there are cases where some things can be slipped past FeatureFreeze in some cases - this was one of them
[14:42] <teward> unfortunately
[14:42] <teward> (in your case)
[14:43] <spm_draget> *sighs* Oh well. Tomorrow is a day off. Good day to fix things :)
[15:12] <nacc> teward: yeah, i guess based upon the linked to question from there, phpmyadmin already depends on php-gettext, but i guess needs a dep on php-mbstring
[15:15] <nacc> teward: so i'm guessing that at least in one case, they installed from source (as the packaging wouldn't have allowed the former not to be installed)
[15:21]  * teward was pinged?
[15:21] <teward> oh
[15:23] <nacc> teward: there are already two bugs for the same (mbstring) issue
[15:23] <teward> nacc: probably should cc/ping rbasak who poked on it ;P
[15:23] <teward> nacc: but yes this is one of those times where this type of thing blows up :P
[15:25] <nacc> rbasak: want to upload the fix from LP: #1577482 ? I guess his versioning is off (probably for a PPA upload)
[15:26] <teward> nacc: if it depends on mbstring then yes it should probably get that dep update - both in Yakkety and Xenial if SRU-able
[15:26] <teward> but i leave that to you and rbasak, my php focus extends to about the default conf of nginx :P
[15:26] <teward> oh and any php services I run but meh
[15:27] <teward> thanks to Landscape, deployment scripts are fun xD
[15:27]  * teward has a "Install PHP 7.0 with all necessary deps" script to push to Xenial boxes :P
[15:27] <teward> (adds mbstring and gettext to the list)
[15:50] <nacc> rbasak: made quite a bit of progress yesterday! the code is all there now, but have to debug why merges aren't quite working (i think it's mostly a mistake on my part with gitpython)
[15:54] <rbasak> nacc: sounds good!
[15:57] <rbasak> nacc: re bug 1577482, I'm happy to sponsor that, but do you need to send upstream?
[16:01] <nacc> rbasak: actually, for yakkety we should sync and selectively backport the same deps (as i think it also migh tneed php-xml) to 16.04
[16:04] <rbasak> nacc: that sounds reasonable. Are you happy for me to sponsor the sync?
[16:04] <rbasak> (as in - have you confirmed that it's correct?)
[16:04] <nacc> rbasak: yeah, i'm filing the bug now -- one sec
[16:14] <nacc> rbasak: so i believe we can sync, i'll finish that in a `requestsync` bug and subscribe you, but from an ease-of-use perspective, we may want to consider reverting parts of this in the Y cycle: http://anonscm.debian.org/cgit/collab-maint/phpmyadmin.git/commit/?id=80a81e7915ee35cd27f8521a314812f3f38bc9ff
[16:14] <nacc> rbasak: as, by default, phpmyadmin won't require the apache module, which i think will violate the principle of least surprise for many users?
[16:15] <nacc> i guess it will prefer fpm by default, (via php -> php7.0 -> php7.0-fpm)
[16:15] <rbasak> nacc: sorry, I don't follow.
[16:15] <rbasak> You want to sync but then revert something that is in the thing that we synced?
[16:15] <nacc> rbasak: i think debian made it less user-friendly
[16:15] <nacc> rbasak: and ubuntu is supposed to be the nicer debian :)
[16:16] <nacc> rbasak: it's unrelated to our delta
[16:16] <nacc> rbasak: they removed the OR'd deps on libapache2-mod-php7.0 (and i believe dep resolution will take the first one if possible?, I forget the rule)
[16:17] <rbasak> Yeah, first possible.
[16:18] <rbasak> Will that do the wrong thing on Ubuntu? Or otherwise, how is it less user-friendly?
[16:18] <nacc> right, so i think (i'm verifying this in lxc right now) that `apt-get install phpmyadmin` in 16.04 will install libapache2-mod-php7.0, but in Debian (and if we sync in Yakkety) will install php7.0-fpm. So maybe not less user-friendly, but less expected potentially
[16:20] <rbasak> Oh, because it depends on just php now, and not the specific ones?
[16:21] <nacc> rbasak: right, i dont' know why debian didn't do 'Depends: libapache2-mod-php | php-cgi | php-fpm | php
[16:22] <nacc> rbasak: hrm, i guess something else pulls in apache, so never mind! :)
[16:22] <rbasak> nacc: I guess Debian doesn't want to choose? Ondrej prefers fpm I believe anyway?
[16:23] <nacc> rbasak: yeah, that's probably why
[16:23] <nacc> rbasak: ok, so that's all my point was -- we'd be making the "default" for phpmyadmin fpm, which would be a behavior change to end-users
[16:23] <rbasak> nacc: I think it's worth considering whether we want to maintain a delta for this.
[16:23] <sdeziel> teward: just looked at your paste (https://paste.ubuntu.com/16208886/) and in addition to using the "service" wrapper, I'd recommend calling "upgrade" on nginx so that you don't incur any downtime
[16:24] <rbasak> How much are we prepared to maintain phpmyadmin in Ubuntu? I understand that we needed to do this for the transition, but what about on an ongoing basis?
[16:24] <teward> sdeziel: s/upgrade/update/
[16:24] <teward> sdeziel: bit late, though, i already ran the script during the scheduled maintenance window on my servers (all of them) last night
[16:24] <nacc> rbasak: ideally not at all, meaning i'd rather we sync now and see what the fallout is ... it would only be in fresh installs of 16.10, afaict
[16:24] <rbasak> OK. That sounds fine to me.
[16:24] <nacc> rbasak: and it's an easy adjustment in the control file if people don't like it
[16:24] <sdeziel> teward: no, I really meant to say "service nginx upgrade" ;_
[16:25] <teward> sdeziel: heheh
[16:25] <sdeziel> teward: that's the cool binary pivot thing :)
[16:25] <teward> sdeziel: ah, indeed.
[16:26] <sdeziel> teward: and I'm sure there will be more security updates requiring httpd restarts in the future
[16:26] <teward> sdeziel: on my servers, though, it was coincided already with an nginx upgrade (PPAs with my own changes lol), so it was still necessary to 'restart' anyways (which is done during the upgrade process and in the postinst)
[16:26] <teward> sdeziel: but you're right, it's why I still have the script on Landscape :)
[16:27] <sdeziel> teward: why would "upgrade" not work in postinst? Sure it would require a bit more logic but should work IMHO
[16:28] <teward> sdeziel: it may be using 'upgrade' but i'll double check
[16:28] <teward> been a while since i stabbed the init and install scripts
[16:28] <sdeziel> in fact, if the postinst could use "upgrade", I'd stop setting up a /usr/sbin/policy-rc.d before pulling those packages
[16:29] <hallyn> smb: sadly i think your adding the Alias=libvirtd complicated upgrade to the new libvirtd.service
[16:30] <sdeziel> teward: looks like the postinst is redoing the "upgrade" dance on its own: http://paste.ubuntu.com/16220815/
[16:30] <teward> sdeziel: i don't need the code i have it here thanks (remember I constantly poke the package)
[16:30] <teward> sdeziel: you're right - it rolls its own :p
[16:30] <teward> but it matches the 'upgrade' code
[16:31] <teward> i know there's other processes which 'stop' the thing in some versions, though... maybe I'm thinking the Trusty days
[16:32] <teward> sdeziel: in my case it wouldn't have mattered - the maintenance I had planned included a kernel update on many of my KVM VPSes (and VMware VMs) so that needed some reboots anyways
[16:32] <nacc> rbasak: sync bug filed and i subscribed you
[16:32] <teward> which would have been ultimately the same impact of service stop, service start
[16:32] <teward> but at a longer timeperiod due to the reboot
[16:32] <teward> sdeziel: ^
[16:32] <sdeziel> teward: indeed but I was talking more in general
[16:32] <teward> sdeziel: right
[16:33] <sdeziel> teward: Truty also has the same code dup
[16:33] <teward> sdeziel: *shrugs* then i misread code sometimes, in any case it works as is - i'll update my scripts
[16:33] <teward> sdeziel: note i'm kind of half burned out right now with other things :/
[16:33]  * teward has literally only half of his attention span as of late
[16:33] <smb> hallyn, hm ... not intentionally but systemd is makeing things complicated generally (imho)
[16:34] <sdeziel> teward: it's not like if it was urgent ;)
[16:34] <teward> sdeziel: ;)
[16:34]  * teward yawns
[16:34] <sdeziel> teward: want me to send a bug your way about it?
[16:36] <teward> sdeziel: for the code duplication?  Send it to Debian first
[16:36] <teward> i'm trying to *reduce* the delta, not add to it :p
[16:37] <sdeziel> make sense, will do
[16:37] <teward> sdeziel: 'low' item on the totem pole for Xenial, so it wouldn't land in Xenial unless something else came in that needed some attention
[16:37] <teward> sdeziel: file against src:nginx up in Debian, file in Launchpad, link bugs.
[16:38] <teward> i'll look at it 'eventually'
[16:38] <sdeziel> teward: that's indeed not SRU worthy
[16:38] <sdeziel> I'll try to provide a patch in the Debian bug :P
[16:38] <teward> sdeziel: it would probably be implemented in Yakkety at the earliest, Z-series at the latest
[16:38] <sdeziel> Z-series sounds kinda neat
[16:38] <teward> the next 'merge' from debian is basically ending up as a "we have to almost start from scratch Debian"
[16:39] <teward> because merges.u.c and Merge-o-Matic are breaking things
[16:39] <teward> basically, keep changelog file from MoM, reapply the existing delta by hand
[16:39] <teward> rbasak: ^
[16:39] <teward> sarnold is also aware
[16:40] <teward> (dynamic module support is breaking things!  >.<)
[16:40] <rbasak> nacc: sync sponsored. Thanks!
[16:40] <nacc> rbasak: thank you!
[16:42] <hallyn> smb: +1
[16:49] <lamont> stgraber: you around?
[16:49] <lamont> stgraber: would like to chat a bit about bind vs lxd and port 53
[17:04] <stgraber> lamont: around-ish, sprinting
[17:06] <lamont> yeah
[17:06] <lamont> I'm going to dig back to where BIND started listening on every IP instead of just using inaddr-any by default, and thinking that I may just want to change that
[17:07] <lamont> I suspect that it was part of the cache-poisoning vs 16-bit ID changes
[17:08] <stgraber> does that make an actual difference though? whether you bind on everything :53 or [::]:53 nothing else can bind port 53 while you're doing that
[17:08] <lamont> bullcrap
[17:09] <lamont> if you bind to :53 then someone binding to a particular IP:53 steals all traffic for that IP
[17:09] <lamont> inaddr-any says "I'll take the traffic if no one wants it more than me"
[17:10]  * lamont accidentally put postfix in production because of that feature of bind(2)
[17:10] <lamont> wow. 19 years ago
[17:11] <stgraber> ah, well, that's nice then :)
[17:11] <teward> sdeziel: when you file the bug, link me to both the Debian one and the Launchpad one - that way I can track both, though I'll probably do that anyways whether Ig et bug numbers or not heh
[17:12] <Sling> lamont: was that in the time when DEBUG on sendmail gave you root?
[17:13] <lamont> Sling: I don't remember... I had postfix listenin on inaddr_any (to catch 2 ports without having an extra line of master.cf), and sendmail was listening on the production IP... and died.
[17:13] <lamont> no one noticed for 2 weeks
[17:13] <lamont> that was back in the alpha days
[17:13] <Sling> ah sendmail way back used to respond to the DEBUG command and just gave you root like that
[17:13] <Sling> cuz why not, internet was for researchers
[17:13] <lamont> past that point
[17:13] <lamont> it was definitely after the morris worm
[17:31] <hallyn> yeah that's much much more than 19 years ago today, isn't it.  how time flies.
[17:36] <lamont> time flies.  you can't: they fly too fast.  <-- thanks for the reminder
[17:50] <lamont> and listening on inaddr-any is a somewhat invasive change to bind9. sigh
[17:51] <hallyn> still seems to me like a .d directory is the way to go.  though inaddr-any sounds like a duh-why-not
[17:53] <lamont> yeah... I'm finding that it might be more straightforward to just teach include some magic on how to handle directories
[17:54] <hallyn> maybe once i finish some kernel gorp i'll take a look at implementing that
[17:59] <lamont> git.debian.org//git/pkg-bind/pkg-bind.git <-- hallyn I also need to update the control file once I figure out what the url wants to be ther.
[17:59] <lamont> hallyn: anyway, 9.10.3.dfsg.P4-10 is current
[18:00] <lamont> said fix wanting to be SRUed into xenial (drop python2 dependency)
[18:00] <lamont> hallyn: I'd be inclined to check the type of the include file, and if it's a directory, include any file directly in that directory whose name ends in ".conf"
[18:01] <lamont> I'd rather not change the syntax of the config file in the least
[18:01] <lamont> and with that, lunch date
[18:48] <sdeziel> teward: https://bugs.launchpad.net/debian/+source/nginx/+bug/1578344 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823435
[18:52] <teward> sdeziel: I would retitle that a little more, expect a retitle from me :/
[18:53] <sdeziel> np
[19:43] <jge> hey all good afternoon, I have two ubuntu servers running 14.04.1 LTS and OpenSSL OpenSSL 1.0.1f 6 Jan 2014
[19:44] <jge> however, when I do apt-get upgrade, one of them wants to upgrade openssl and the other does not see it
[19:44] <jge> I have only main and security repos enabled
[19:44] <jge> same on both
[19:44] <jge> what am I missing here..
[19:45] <mdeslaur> jge: did you do apt-get update first?
[19:46] <sarnold> do they both have security.ubuntu.com repos listed?
[19:46] <teward> sarnold: i would imply that based on their statement about only main + security enabled on both.
[19:47] <teward> also good afternoon to you
[19:48] <jge> mdeslaur: yep
[19:48] <jge> sarnold: yes
[19:48] <mdeslaur> jge: what's the result of "apt-cache policy openssl" on the server that doesn't find it?
[19:50] <jge> damnit, I have to keep remembering the usefulness of this command.. looks like it was already upgraded to the version the other is nagging about
[19:50] <jge> :)
[19:50] <mdeslaur> ah, well there you go :)
[19:52] <jge> thanks
[19:53] <mdeslaur> yw
[19:57] <lamont> hallyn: +XS-Vcs-Browser: http://anonscm.debian.org/git/pkg-bind/pkg-bind.git
[19:58] <lamont> (which will be reflected in -11 :/)
[19:58] <JanC> jge: do you have automatic security upgrades enabled on one of them?
[19:59] <sdeziel> I wonder why HTTPS isn't the default for anonscm.debian.org
[19:59] <lamont> bother.  good catch sdeziel
[20:00] <lamont> it should have been https in the first place <-- hallyn
[20:04] <RoyK> hm... https://launchpad.net/~kernel-ppa/+archive/ubuntu/ppa doesn't seem to work with xenial
[20:08] <hallyn> lamont: just to be clear - nothing in that git tree implements .d support right?
[20:08] <lamont> nothing whatsoever
[20:08] <lamont> at least that I'm aware of
[20:09] <sdeziel> RoyK: that PPA is empty ATM
[20:09] <lamont> hallyn: thinking about it, maybe: include "/some/dir/*.conf"; <-- for syntax?
[20:09] <RoyK> sdeziel: any idea where I can find upstream kernels without compiling them myself?
[20:10] <sdeziel> RoyK: https://wiki.ubuntu.com/Kernel/MainlineBuilds ?
[20:12] <RoyK> sergey: nothing there about xenial
[20:14] <sdeziel> RoyK: I'd give that a try http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
[20:15] <RoyK> thanks
[20:19] <hallyn> lamont: it's been too long since i've used bind itself, but something analogous to /etc/network/interfaces.d/*.conf would be nice and unsurprising
[20:23] <lamont> yeah... the issue is that the poor config file is structured, and the user will want to be able to inject a "include this directory" snippet into way too many places to predict.
[20:24] <lamont> ergo, extend the include directive to let them do just that
[20:26] <hallyn> oh.  heh.  structured.
[20:27] <hallyn> don't suppose there is some existing convention for third party sed'ing of the file to add in and remove hunks or file includes?
[20:28] <hallyn> grep lxd /etc/bind.conf || sed -i 's/REPLACEME/\0\nskip lxd network\n/' /etc/bind.conf
[20:33] <lamont> not that I know of, though there are probably dozens. :/
[20:39] <lamont> hallyn: of course, once we get the grammar, then the config file will grow to include several strtegically placed include statements
[20:41] <hallyn> yeah <pained grin>
[20:59] <sarnold> teward: it's possible to subscribe to the security pocket on a different server though