[06:15] <cpaelzer> thanks for taking logwatch rbasak
[06:29] <Quozl> i'm in a do-release-upgrade for a remote headless 16.04 to 18.04 upgrade, and postgres is failing to upgrade because systemd is not responding, in another shell systemctl gives "Failed to connect to bus: No such file or directory".  journalctl has "System is tainted: var-run-bad".  any ideas?
[06:46] <Quozl> solved with "ln -s /var/run/dbus /run"
[07:18] <lordievader> Good morning
[07:32] <cpaelzer> good morning lordievader
[07:33] <lordievader> Hey cpaelzer
[07:33] <lordievader> How are you doing?
[07:52] <cpaelzer> lordievader: good, how are you today (and late happy new year to you)
[07:54] <lordievader> Happy New Year to you too
[07:54] <lordievader> Doing good here 😁
=== JanC is now known as Guest41406
=== JanC_ is now known as JanC
[11:04] <ahasenack> good morning
=== bigbrovar_ is now known as bigbrovar
[13:26] <Lope> Hey guys I need to choose between LXC and KVM
[13:26] <Lope> I don't have a huge number of VM's so while LXC could achieve higher density in theory, it's unlikely to be an issue for me.
[13:27] <Lope> So my main consideration is ease of maintenance/admin of whatever I put into production.
[13:27] <Lope> So for that reason I'm leaning towards KVM over LXC.
[13:27] <Lope> KVM supports live migration and has snapshot support.
[13:28] <Lope> LXC can't really do live migration. So I'm thinking KVM has a bit of an edge over LXC
[13:31] <sdeziel> Lope: nowadays you probably want to look at LXD instead of LXC
[13:32] <Lope> sure, but same thing more or less.
[13:32] <sdeziel> yeah but the LXD experience is much more pleasant
[13:35] <sdeziel> Lope: lxc supports live snapshots too
[13:35] <Lope> sdeziel, interesting
[14:02] <ahasenack> rbasak: do you remember this bug? https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1323930
[14:02] <ubottu> Launchpad bug 1323930 in apache2 (Ubuntu Trusty) "mod_lua.so missing from 14.04 install (apache2-bin, 2.4.7-1ubuntu4))" [Undecided,Confirmed]
[14:02] <ahasenack> rbasak: for trusty, we could just change apache'2 build-deps back to lib lua 5.1, like you did for the utopic release
[14:03] <ahasenack> rbasak: is this valid for an sru? It would make apache2 grow a (intented) lua5.1 runtime dep, something it didn't have before (due to the bug)
[14:03] <ahasenack> rbasak: trusty's backports do contain a newer apache which has lua support
[14:04] <ahasenack> and even lua 5.1
[14:05] <ahasenack> backports actually has the same change you made for utopic
[14:12] <ahasenack> Lope: and you can copy lxd containers to other machines, and use snapshots too
[14:36] <rbasak> Looking
[14:37] <rbasak> ahasenack: it feels to me that lua support is rotting currently. Perhaps we'll need to eventually drop lua 5.1 support from apache2 altogether. In that case, I don't think it's of much benefit to add lua to Trusty. It will be EOL soon. Nobody should be deploying anything new on it today anyway.
[14:39] <rbasak> And if we're not going to support lua on apache2 any more, then I don't think it really counts as a "feature regression" for a release to not have shipped with it. It was an accident, sure, but if the long term goal is to drop support, then intermittent/no support in previous releases may be acceptable. As long as it's not a regression during the lifetime of a single release, which this isn't.
[14:44] <ahasenack> rbasak: lua in apache is fine in all other distros. Xenial is the last one with 5.1, all the rest (including disco) has 5.2 support
[14:45] <ahasenack> question is specifically about a trusty sru to enable it, and I think your opinion is "no", correct?
[14:45] <ahasenack> I added a comment to the bug, maybe after you read it
[14:48] <rbasak> 4 people affected
[14:48] <rbasak> Apparently trusty-backports has a lua-enabled apache
[14:48] <rbasak> And Xenial and Bionic are available of course
[14:49] <rbasak> The last date of someone indicated caring was in 2017
[14:50] <ahasenack> well, it's an old bug, at some point people give up
[14:50] <rbasak> Yeah, I accept that.
[14:50] <rbasak> But with only four months remaining now, I don't think there's any point for Trusty any more.
[14:50] <ahasenack> ok, I'll mark that task as wontfix
[14:51] <rbasak> Not from a policy perspective necessarily, just from an effort perspective, including SRU team effort.
[14:52] <ahasenack> done, thanks
[15:52] <rbasak> kstenerud: got your logical tag, but why does it have a different prefix to the others? Is that intentional?
[15:52] <rbasak> (for logwatch)
[15:54] <kstenerud> no, not intentional
[15:55] <rbasak> It breaks my automatic checking script :-/
[15:55]  * rbasak works around
[15:55] <kstenerud> sorry
[16:42] <cpaelzer> jamespage: such a dependency can be added
[16:42] <cpaelzer> jamespage: my question was would you want to add it in UCA's qemu only
[16:42] <cpaelzer> or should we add it to Bionic as well?
[16:48] <jamespage> cpaelzer: I guess its really a UCA only problem so we should hold a patch for the backport to add the versioned dependency
[16:48] <jamespage> as a do-release-upgrade to bionic won't have this issue...
[16:49] <jamespage> cpaelzer: partial upgrades with UCA are a grey area - we don't test for mixed version deployment (where only certain pkgs have been upgraded).
=== bigbrovar_ is now known as bigbrovar
[17:15] <ahasenack> rbasak: sru question, wrt https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1807439
[17:15] <ubottu> Launchpad bug 1807439 in openvpn (Ubuntu Disco) "openvpn crashes when run with fips openssl" [Undecided,New]
[17:16] <ahasenack> rbasak: fips is only offered for LTS releases
[17:16] <ahasenack> rbasak: so is cosmic needed in there?
[17:16] <ahasenack> disco I think is, just so we can be sure it won't be forgotten until the next lts comes
[18:49] <sayi> hi, can someone confirm if squid package for ubuntu18.04 supports SSL/ HTPPS?
[18:54] <sdeziel> sayi: it doesn't AFAIK
[19:01] <TJ-> According to 'man squid3' on 18.04, "Squid  supports  SSL,  extensive  access  controls, and full request logging."
[19:03] <sdeziel> http://www.squid-cache.org/Doc/config/https_port/: Requires:--with-gnutls or --with-openssl
[19:03] <sdeziel> squid -v shows none of those flags
[19:05] <TJ-> yes, the Depends also don't show any indications. Seems the man-page is not tailored for the build
[19:09] <rbasak> ahasenack: Canonical only commercially offers FIPS for LTS releases, but I think if part of that involves regular-Ubuntu-archive then that's not a justification for skipping the regular "no regression on release upgrade" SRU policy.
[19:10] <rbasak> ahasenack: IOW, I think that without Canonical's FIPS offering the openvpn SRU and bug would make sense on their own (eg. if an interested non-commercial user were driving it). If so, then Cosmic needs to also be fixed by my understanding of SRU policy. Assuming I understand the bug being fixed here.
[19:17] <ahasenack> rbasak: I see, thanks
[19:17] <ahasenack> rbasak: good point about the third party
[19:17] <ahasenack> rbasak: cosmic wasn't in that bug, it was I who added the task earlier today, but was left wondering
[19:25] <sarnold> squid build logs show a bunch of ssl stuff though https://launchpadlibrarian.net/391424489/buildlog_ubuntu-bionic-amd64.squid3_3.5.27-1ubuntu1.1_BUILDING.txt.gz
[19:28] <ahasenack> I think that is just for squidclient
[19:28] <ahasenack> proper ssl termination support was only added in squid4
[19:34] <sarnold> ahhhhh
[19:42] <sayi> sdeziel: do you know how to confirm it 100%?
[19:49] <fletch8527> Im hoping someone here can help me with my Ubuntu 18.04 server (no GUI). I have its NIC set to a static IP via the /etc/netplan/50-cloud-init.yalm but for what ever reason is seems that DNS stops working every now and then. I have the nameservers specified in the file but I cannot resolve anything, I just get "ping: www.google.com: Temporary failure in name resolution".
[19:49] <fletch8527> here is my netplan yaml: https://paste.ubuntu.com/p/43ndRgvs9n/
[19:50] <sdeziel> sayi: I'd try setting https_port and see if squid successfully binds a socket with TLS/SSL on it
[19:51] <ahasenack> fletch8527: can you ping the nameservers' ip when that happens?
[19:51] <sarnold> fletch8527: I suggest ditching 1.1.1.1 and just use your own dns server, that'll probably be more debuggable
[19:52] <sdeziel> sayi: but "ldd /usr/sbin/squid" doesn't show the usual SSL libs so I don't think it will work
[19:53] <fletch8527> I can try switching it back, but I switched to 1.1.1.1 because I though my local one might have been the issue. I can also ping 1.1.1.1 and 192.168.1.1 (local dns) without issue
[19:58] <fletch8527> is there a preferred method for setting a static IP in 18.04? Im coming from a Windows background it a kinda throws me that there is more than 1 way to set a static
[19:58] <rbasak> fletch8527: see if dig works direct to a nameserver perhaps, to eliminate a network problem?
[19:58] <Ool> fletch8527: you can try dig debian.org @1.1.1.1
[19:59] <sarnold> fletch8527: it's complicated in part because 18.04 upgrades from earlier releases won't automatically get netplan configs
[19:59] <rbasak> systemd-resolve(1) might also be of help
[19:59] <Ool> with the @ you can tell which DNS server you want to use
[19:59] <sarnold> fletch8527: is systemd-resolved in use on this machine? (it probably is) -- I've heard once it gets one bad response it can get endlessly confused and become worthless
[20:00] <fletch8527> @sarnold it was a fresh install and i followed a guide that i think disabled systemd-resolved (it had me rename resolv.conf)
[20:01] <fletch8527> @Ool that command worked as expected
[20:03] <fletch8527> https://paste.ubuntu.com/p/zC5VRyGnKJ/
[20:04] <sdeziel> fletch8527: debian.ord != debian.org
[20:04] <Ool> .org not .ord but ok you can ask your server and got an answer
[20:04] <Ool> did you netplan generate to validate your file ?
[20:04] <fletch8527> what would be the best way to disable the netplan setting and re-enable systemd-resolve (sorry, its probably a noob question)
[20:04] <fletch8527> oops haha
[20:05] <fletch8527> jacked up on cold medicine atm :/
[20:06] <Ool> without following this unknown guide (link ?), your yaml file seems good
[20:06] <UsQUE> anyone known why sftp doesn't allow me to use NFS mounted directory? I get permissions denied error? when I login via terminal ssh and go to the directory I can see the content :/
[20:08] <fletch8527> @Ool, yea im trying to find it now. But I could just blank out the 50-cloud-init.yaml file then enable/start the systemd-resolve service?
[20:09] <sdeziel> fletch8527: you probably want to ensure /etc/resolv.conf is a symlink to systemd-resolve's version
[20:09] <fletch8527> @sdeziel ok. ill look into that
[20:12] <Ool> fletch8527: usualy I use netplan to configure the systemd-network or I install ifupdown to use the old method
[20:15] <fletch8527> @Ool I think that it what I did, but not sure why it just loses its abaility to resolve. I actually switched to this method becuase my resolv.conf kept getting wrong info in it and would break resolving as well. Would you happen to have a guide you could link to about correctly using netplan?
[20:16] <Ool> if you install ifupdown , your yaml file isn't readed, you need to put your nameservers into /etc/network/interfaces
[20:16] <fletch8527> also, this server is used to run my Docker setup. Only the host is effected all the containers work just fice
[20:17] <sarnold> netplan's best docs are on the website https://netplan.io/
[20:17] <sarnold> figure out *why* your resolv.conf is getting bad data though..
[20:18] <fletch8527> Thanks Ill check it out. I was going down the path figuring out what was going on with my resolv.conf when I found a guide to use netplan (though I cant find the guide now :/ ). my resolv.conf is no longer being used.
[20:34] <sayi> sdeziel: would you know how to install a squid server that supports ssl and https?
[20:35] <sdeziel> sayi: it depends on what you want to do with it
[20:36] <sdeziel> sayi: if you only want to secure the client<->proxy connection, it should be easy to do with a side daemon (like HAProxy for example)
[20:36] <sdeziel> sayi: but if you want to do TLS MITM/ssl_bump'ing, this is a different story
[20:40] <sayi> sdeziel: im looking for TLS MITM setup, can you help directing me to a how to doc?
[20:40] <sayi> im moving squid server from pfsense to ubuntu
[20:41] <sdeziel> sayi: that's something I never tried, only read about it :(
[20:42] <sdeziel> sayi: you could probably rebuild squid with the needed dependencies/compile flags and/or try on a newer version of Ubuntu/squid
[20:46] <sayi> sdeziel: do you know which version of squid?
[20:46] <sdeziel> sayi: ahasenack mentioned squid 4
[20:47] <sdeziel> cosmic ships squid 4.1 and disco will ship 4.4