[06:37] <lordievader> Good morning
[06:52] <heller_> hey
[06:53] <heller_> how do you guys keep track that your servers are up to date with security?
[08:14] <yossarianuk>  Hi - for the zombieload bug - when using VMs do I need to update the VMs as well as Hypervisors or is just the hypervisor enough
[08:19] <heller_> im trying to dry-run unattended-upgrades but i get error about "sudo unattended-upgrade --dry-run
[08:19] <heller_> An error occurred: '404  Not Found'
[08:19] <heller_> The URI 'http://security.ubuntu.com/ubuntu/pool/main/c/cups-filters/libcupsfilters1_1.8.3-2ubuntu3.4_amd64.deb' failed to download, aborting"
[08:19] <heller_> Does this mean that UU requires manual apt update?
[08:22] <lordievader> I don't think unattended-upgrades promises to run 'apt update' before the actual update run.
[08:24] <lordievader> There should be an `/etc/apt/apt.conf.d/10periodic` where this period of `apt update` is defined.
[12:22] <ahasenack> rbasak: I would like to update the importer whitelist
[12:22] <ahasenack> rbasak: the code is updated already, but the snap that is doing the import isn't
[12:42] <rbasak> ahasenack: to do that I grab the latest nightly build from Jenkins and push it to edge in the store
[12:42] <rbasak> ahasenack: then eventually promote it up to beta, and refresh and restart the importer service
[12:43] <rbasak> ahasenack: or alternatively move the importer service instance to the edge snap temporarily
[12:45] <ahasenack> rbasak: this is really just a config file in the end, right
[12:48] <rbasak> Yes
[12:48] <rbasak> It can be overridden on the command line
[12:49] <rbasak> But I've never been confident about keeping that in sync properly, so have been going via the snap
[12:49] <rbasak> Suggestions welcome
[12:52] <ahasenack> rbasak: how can we see what changed between the snap that is running and the one to be pushed to edge?
[12:53] <ahasenack> rbasak: would another option be to import the package manually from somewhere else?
[12:54] <rbasak> ahasenack: yes you can just run the importer on the importer service instance in a different screen window
[12:54] <rbasak> ahasenack: for the differences, snap info git-ubuntu and look for the git commit hashes?
[12:54] <ahasenack> let me check
[12:55] <ahasenack> ok, edge is just one commit behind my whitelist change, as expected
[12:55] <ahasenack> beta is quite behind
[12:55] <ahasenack> does not have the --split change
[12:56] <ahasenack> nor the cache changes? That's odd
[12:56] <rbasak> Did I leave the importer service instance on edge?
[12:56] <ahasenack> rbasak: let's check
[12:56] <rbasak> Yes, I did
[12:56] <ahasenack> well, good for me :)
[12:56] <ahasenack> and it's been working for a couple of weeks now?
[12:57] <rbasak> So we could probably upload the latest nightly to edge and beta together, and move the importer service instance back to beta.
[12:57] <rbasak> Yes
[12:57] <ahasenack> rbasak: ok, want to walk me through it, or do it yourself this time?
[12:57] <rbasak> I can walk you through it
[12:57] <ahasenack> h/o?
[12:58] <rbasak> ack
[12:58] <ahasenack> let me fetch my headset
[14:21] <tobias-urdin> coreycb: hello :) quick questions, will ubuntu keep neutron-lbaas packages for the train release?
[14:21] <tobias-urdin> it will be retired in Train, but RDO will keep the packages pinned to latest version https://review.rdoproject.org/r/#/c/20683/
[14:21] <tobias-urdin> will ubuntu do something the same, or will it be completely removed in Train?
[14:22] <tobias-urdin> s/latest version/latest commit/g
[14:22] <tobias-urdin> then drop next release
[14:22] <coreycb> tobias-urdin: that's a good question. i think we can keep them around.
[14:23] <coreycb> jamespage: +1 on keep neutron-lbaas* around for train?
[16:14] <jerichowasahoax> "journalctl -u postfix" used to bring me my mail logs in 16.04, but in 18.04 it comes up empty, and my postfix logs are in /var/log/mail.log instead. Can I switch back to journalctl? I don't want to rework my scripts today.
[16:32] <TJ-> jerichowasahoax: are you sure you've not got that inverted? the 16.04 Xenial package has no systemd-related files or config, but the 18.04 Bionic package does
[16:47] <jerichowasahoax> TJ-: does 16.04 have some kind of package that lets journalctl read "classic" log files?
[16:47] <jerichowasahoax> it's possible that in 16.04 "journalctl -u postfix" was just some kind of fancy pants "cat /var/log/mail.log"
[16:49] <jerichowasahoax> but like, my daily report scripts are reading mail logs via https://pypi.org/project/systemd/, and i wrote these scripts back in 2017, so i was most definitely for sure using journald
[16:49] <jerichowasahoax> somehow
[16:50] <TJ-> jerichowasahoax: I'd suspect a custom config to route the mail logs to journald
[16:51] <jerichowasahoax> TJ-: depends on how custom we're talking - i could definitely have filled in "syslog" for a log file somewhere but i wouldn't have gone more complex than that
[17:12] <TJ-> jerichowasahoax: I would presume that journald was configured to take over the syslog function, via its /run/systemd/journal/dev-log (symlink to /dev/log). That's where the syslog() library function writes to (and Postfix uses syslog() by default)