[06:54] <lordievader> Good morning
[08:19] <sveinse> Will 18.04 server by default reboot on automated updates?
[08:20] <sveinse> I had a reboot on server yesterday, and I'd like to know if it was intentional/software triggered or if it was something unexpected
[09:42] <jamespage> coreycb: working on ceph mimic and py3 transitions for neutron/networking pkgs hope that's ok
[12:08] <coreycb> jamespage: sounds good, thanks
[12:23] <ahasenack> good morning
[12:56] <a_ok> How can I install a package as a dependency?
[12:57] <a_ok> If anyone here is familiar with Arch I want to do: pacman -S --asdeps package
[14:39] <jamespage> coreycb: how are you assessing py3 readiness for projects?
[14:40] <coreycb> jamespage: well, i'm not really. there is the upstream wiki doc that has status. for now i'm adding dep8 tests to ensure daemons start and py2/py3 usr/bin shebangs are correct.
[14:41] <coreycb> jamespage: and installing py2 by default with py3 as an alternative for now
[14:42] <coreycb> jamespage: i think we need to do this until all upstream projects are +1 saying they support py3 and then we can drop all the py2 support
[14:47] <jamespage> coreycb: ok
[16:42] <nacc> rbasak: fyi, my changes to the importer loop now pass self-test (i used the edge snapcraft build) and integration test. Working on cleaning them up, I still haven't got to the point where I've written the tests for the branch moves, but I might put up an MP just so you can see what I mean.
[16:42] <rbasak> OK
[16:43] <rbasak> I'm half way through preparing a PR to switch our CI to use the edge snap
[16:45] <nacc> cool, it does seem better there in my testing so far
[17:04] <jaydemir> I want to build a basic file server for my office to reduce the dependency on google drive. I have a few machines at my disposal, but DDR3 ram is scarce and I'm practically swimming in DDR2. Is it a significant difference what I use?
[17:11] <oerheks> a duak core machine with gigabit and 4 gb memory, perfect for an owncloud server
[17:12] <oerheks> you could serve 100 clients with that, i guess
[17:31] <RoyK> oerheks: or nextcloud, perhaps? ;)
[17:37] <oerheks> sure, own/next/.. openstack :-P
[18:27] <sruli> i have a few 16.04 headless servers, don’t really need to login more than 2-3 times a year, each time i have a full boot drive (never reboot so its full of kernels the oldest one is in use) cant install anything, removing the kernels manually is a taks and a half, and still as there are still more newer kernels downloaded and not installed as soon as i remove a few and run "install -f" boot gets full again and i have to remove again and again, how do o
[18:37] <sarnold> sruli: irc has line length limits, looks like you were cut off at 'how do o'
[18:38] <sruli> sarnold: thanks... "how do others get by this issue? and is there at least a script to hook onto update to check if there is a new kernel and i'll manually login and reboot each time"
[18:38] <ahasenack> sruli: I run "apt autoremove" every now and then, that takes care of it. I don't have it automated, though
[18:39] <ahasenack> it knows which old kernels to remove, and leaves two behind, plus the one you are currently booted into, iirc
[18:39] <sruli> ahasenack: problem is i only login 2-3 times a year by the time i login its too late for auto remove
[18:39] <ahasenack> sruli: what handles the updates? unattended-upgrades?
[18:40] <sruli> yes unattended-upgrades
[18:40] <sruli> i dont mind logging in when a new kernel is installed but i need some script to check that and i'll add it to my email script
[18:40] <sarnold> what's *really* annoying is that the automated update things supposed to handle this transparently
[18:40] <ahasenack> sruli: check /etc/apt/apt.conf.d/50unattended-upgrades
[18:41] <ahasenack> / Do automatic removal of new unused dependencies after the upgrade
[18:41] <ahasenack> / (equivalent to apt-get autoremove)
[18:41] <ahasenack> Unattended-Upgrade::Remove-Unused-Dependencies "true";
[18:41] <ahasenack> that's what I have in my little remote server
[18:41] <ahasenack> it can also automatically reboot if you are so inclined, there is an option for that
[18:41] <sarnold> apt.conf.d/01autoremove-kernels
[18:41] <sarnold> // DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
[18:41] <ahasenack> that configures which kernels to remove, right
[18:42] <ahasenack> the one I linked to is about unattended upgrades only, and not specific to kernels, but it has that "apt autoremove" bit
[18:42] <ahasenack> so it covers removing old kernels
[18:44] <sruli> the problem is not that it doesnt remove old kernels, it cant remove it as usually the oldest one is the one in use, the problem is it keeps on installing new ones with the oldest in use until it gets full than the download dir has a belly full of even newer kernels that it cant install
[18:44] <ahasenack> sruli: it won't get full
[18:44] <ahasenack> sruli: as new kernels come in, it removes installed ones that are not in use
[18:44] <sruli> i need some script which checks if a newer kernel is install, i cannot have it reboot automatically at a random time
[18:44] <ahasenack> so you always have 3 installed, of which one is in use
[18:45] <sruli> ahasenack: it will remove newer ones than the one installed?
[18:45] <ahasenack> sruli: that config file I showed also has a config option to reboot at a specified time if needed
[18:45] <ahasenack> sruli: yes
[18:45] <ahasenack> Unattended-Upgrade::Automatic-Reboot "true";
[18:45] <ahasenack> Unattended-Upgrade::Automatic-Reboot-Time "02:00";
[18:45] <sarnold> sruli: just how small is your boot partition anyway?
[18:45] <sruli> i changed "Unattended-Upgrade::Remove-Unused-Dependencies" to "true" thats it?
[18:45] <sarnold> sruli: it might be too small to handle the number of packages ..
[18:46] <sruli> sarnold: the default installer size 256MB, which in my opinion is way to small for ubuntu boot
[18:46] <ahasenack> true, you need to be able to hold at least 3, possibly more to cope with temporary files during initrd generation perhaps
[18:46] <sarnold> yikes
[18:46] <ahasenack> 256mb? wow
[18:46] <ahasenack> that won't work
[18:46] <ahasenack> well
[18:47] <ahasenack> that machine I'm using as an example
[18:47] <sruli> 256mb is the default installer size if you choose guided partitioning, i stopped using guided for that reason some time ago
[18:47] <ahasenack> $ sudo du -hs /boot
[18:47] <ahasenack> 137M	/boot
[18:47] <ahasenack> with 3 kernels
[18:47] <ahasenack> my that /boot is not on its own partition :)
[18:47] <sarnold> neither of my machines has a separate /boot, I guess I got sick of dealing with those
[18:47] <sarnold> and now that I'm not using lilo any more ..
[18:48] <ahasenack> it's a tight fit, but using that autoremove option might be what you can do now
[18:48] <sruli> what i did now was add a virtual drive 1GB (its vm) dismounted boot mounted this as boot copied all files over, updated fstab, will now "grub-install /dev/new1" and hope that it will work fine
[18:48] <ahasenack> also have it email you
[18:49] <sruli> have it email what?
[18:52] <ahasenack> whenever it upgrades or autoremoves packages
[18:52] <ahasenack> there is a config setting in that file
[18:54] <sruli> i will try to find it.. i'd rather have it email me when a new kernel is installed as it would be ideal to run on latest kernel anyway
[19:07] <sruli> i can simply make a script to check if /var/run/reboot-required exists, is this file only created after new kernel install?
[19:08] <ahasenack> sruli: other packages can touch that file as well, like openssl
[19:08] <ahasenack> any package that decides that a reboot is required for a particular update will touch that package, not just the kernel
[19:10] <sruli> what command would i use to check if there is a newer kernel installed than the one in use?
[19:13] <sarnold> sruli: afaik no such command exists ready-made for that task..
[19:14] <sarnold> sruli: you could probably drop a script in /etc/kernel/postinst.d/ that could alert you in some fashion
[19:14] <sruli> i will need for the script to check if its a kernel that's been updated
[19:16] <sarnold> considering that we publish new kernels every three weeks or so and you downgrad ekernels .. once a year? once per install? :) .. it might be fine to fudge it and just alert on every new kernel package install
[19:17] <sdeziel> sruli: you can do this:grep ^linux-image- /var/run/reboot-required.pkgs
[19:17] <sruli> i dont mind rebooting once a month.. what would i put in the script to alert me that a kernel package has been installed?
[19:18] <sdeziel> reboot-required.pkgs contains a list of packages that wanted you to reboot
[19:18] <sdeziel> grep -q ^linux-image- /var/run/reboot-required.pkgs && reboot
[19:18] <sruli> sdeziel: thanks, that will do, if true will email me, great
[19:19] <sruli> sdeziel: cant reboot randomly, have to make sure no users are connected...
[19:19] <sarnold> sruli: something like echo new kernel | mail -s "new kernel" sruli@sruli.example.com   might do the trick
[19:19] <sarnold> assuming mail works, anyway
[19:20] <sruli> sarnold: i use python to email me on different vents, will add a crontab to check this
[19:20] <sdeziel> sruli: you can check for connected users with "w -h | wc -l"
[19:20] <sruli> sdeziel: users dont connect directly, its a local web-server
[19:21] <Ussat> Is july still the target for upgrades from 16.04LTS --> 18.04LTS ?
[19:21] <sdeziel> sruli: then "netstat -puant | grep ESTABLISHED" or something with ss instead
[19:22] <sruli> sdeziel: it will never reboot, lol, if there are < 10 users i send a quick email that service will be down for few minutes
[19:22] <sruli> if there are > 10 i wait, i useually get up in the early hours of the morning to do my reboots
[19:23] <sruli> sdeziel: thanks for "grep -q ^linux-image- /var/run/reboot-required.pkgs" great help
[19:23] <sdeziel> np
[21:00] <compdoc> is there a webpage that mentions which large corps or businesses that use ubuntu?
[21:02] <DirtyCajun> #AllTheOnesThatDontHaveTheirOwnOSorAre100YearsOldLikeIBM
[21:02] <nacc> define "use ubuntu'
[21:02] <nacc> IBM actively contributes to Ubuntu
[21:02] <DirtyCajun> contributes yes but more of their evironment is on CentOS/RedHat as of the last polling