=== gnomethrower is now known as Wings === Wings is now known as uphoria === uphoria is now known as wings [06:37] Good morning [06:52] hey [06:53] how do you guys keep track that your servers are up to date with security? [08:14] 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] im trying to dry-run unattended-upgrades but i get error about "sudo unattended-upgrade --dry-run [08:19] An error occurred: '404 Not Found' [08:19] 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] Does this mean that UU requires manual apt update? [08:22] I don't think unattended-upgrades promises to run 'apt update' before the actual update run. [08:24] There should be an `/etc/apt/apt.conf.d/10periodic` where this period of `apt update` is defined. [12:22] rbasak: I would like to update the importer whitelist [12:22] rbasak: the code is updated already, but the snap that is doing the import isn't [12:42] ahasenack: to do that I grab the latest nightly build from Jenkins and push it to edge in the store [12:42] ahasenack: then eventually promote it up to beta, and refresh and restart the importer service [12:43] ahasenack: or alternatively move the importer service instance to the edge snap temporarily [12:45] rbasak: this is really just a config file in the end, right [12:48] Yes [12:48] It can be overridden on the command line [12:49] But I've never been confident about keeping that in sync properly, so have been going via the snap [12:49] Suggestions welcome [12:52] rbasak: how can we see what changed between the snap that is running and the one to be pushed to edge? [12:53] rbasak: would another option be to import the package manually from somewhere else? [12:54] ahasenack: yes you can just run the importer on the importer service instance in a different screen window [12:54] ahasenack: for the differences, snap info git-ubuntu and look for the git commit hashes? [12:54] let me check [12:55] ok, edge is just one commit behind my whitelist change, as expected [12:55] beta is quite behind [12:55] does not have the --split change [12:56] nor the cache changes? That's odd [12:56] Did I leave the importer service instance on edge? [12:56] rbasak: let's check [12:56] Yes, I did [12:56] well, good for me :) [12:56] and it's been working for a couple of weeks now? [12:57] So we could probably upload the latest nightly to edge and beta together, and move the importer service instance back to beta. [12:57] Yes [12:57] rbasak: ok, want to walk me through it, or do it yourself this time? [12:57] I can walk you through it [12:57] h/o? [12:58] ack [12:58] let me fetch my headset === svetlana is now known as Sveta [14:21] coreycb: hello :) quick questions, will ubuntu keep neutron-lbaas packages for the train release? [14:21] 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] will ubuntu do something the same, or will it be completely removed in Train? [14:22] s/latest version/latest commit/g [14:22] then drop next release [14:22] tobias-urdin: that's a good question. i think we can keep them around. [14:23] jamespage: +1 on keep neutron-lbaas* around for train? [16:14] "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] 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] TJ-: does 16.04 have some kind of package that lets journalctl read "classic" log files? [16:47] it's possible that in 16.04 "journalctl -u postfix" was just some kind of fancy pants "cat /var/log/mail.log" [16:49] 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] somehow [16:50] jerichowasahoax: I'd suspect a custom config to route the mail logs to journald [16:51] 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] 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)