[00:40] <lamont> ahasenack: interestingly, livecd + packages seems to work, but I don't think it did the dlopen call.  same kernel on my installed desktop still results in failure.  Now comes the fun of looking at file diffs. sigh.
[01:02] <lamont> ahasenack: turns out that error 610 from virtualbox is bitching about non-root owner of /usr /usr/lib or /usr/lib/vitualbox.  Thanks for the classy error messages, Oracle.
[05:04] <cpaelzer> good morning
[10:40] <jamespage> coreycb: newer snapshots of py2.7, 3.6 and 3.7 all generate that same hacking test failure in nova
[10:40] <jamespage> coreycb: life is to short so I've skipped it across all versions
[10:40] <jamespage> but something changed
[11:52] <coreycb> jamespage: ok
[11:56] <coreycb> jamespage: there are some dep8 failures due to curl not being available in arm. i'll fix those up.
[12:00] <coreycb> jamespage: it seems that some of the nasty py3.7 bugs may be fixed in py3.7 itself.  i'll check and work with doko on it. i was hitting similar ones to this on a handful of projects: https://storyboard.openstack.org/#!/story/2003186
[12:04] <jamespage> coreycb: have you worked on any py3 switchovers for components yet?
[12:04] <jamespage> in the charms that is
[12:04] <coreycb> jamespage: not for the charms yet, but planning to start once rocky cleanup is done
[12:04] <jamespage> coreycb: ok I'll start poking on a few - cinder first
[12:05] <coreycb> jamespage: ok, thanks
[12:25] <ahasenack> hmm
[12:25] <ahasenack>  /tmp/autopkgtest.cRVUhE/build.cWY/src/debian/tests/ldap-user-group-krb5-auth: 57: /tmp/autopkgtest.cRVUhE/build.cWY/src/debian/tests/ldap-user-group-krb5-auth: debian/tests/login.exp: Permission denied
[12:25] <ahasenack> it has +x
[12:28] <ahasenack> maybe it's mounted as noexec
[12:28] <ahasenack> it worked locally in qemu/kvm
[12:29] <cpaelzer> maybe it looses +x on the way?
[12:29] <cpaelzer> can you for testing chmod it before calling?
[12:29] <cpaelzer> or pass it like $ expect -f foo.exp
[12:30] <ahasenack> the latter would be my next attempt
[12:30] <ahasenack> but it worked here
[12:30] <ahasenack> kvm and lxd
[12:30] <cpaelzer> odd
[12:30] <cpaelzer> I also thought that there should be no difference
[12:30] <ahasenack> also worked in a debian lxd
[12:30] <cpaelzer> which architecture was the fail ahasenack
[12:31] <ahasenack> all
[12:31] <cpaelzer> wow
[12:31] <ahasenack> https://bileto.ubuntu.com/excuses/3399/cosmic.html
[12:33] <ahasenack> hm, maybe I need -f in the shebang line
[12:33] <cpaelzer> maybe dash/bash/sh is different there?
[12:33] <cpaelzer> is expect a test dependency?
[12:34] <cpaelzer> hmm, yes it is
[12:36] <cpaelzer> ahasenack: http://paste.ubuntu.com/p/Q3gXJv5zGB/ ?
[12:36] <ahasenack> yeah
[12:37] <ahasenack> better go all the way, or else verifying all alternatives will take a whole day
[12:37] <cpaelzer> yep
[12:37] <cpaelzer> I also found the -- in the man page
[12:37] <cpaelzer> so I added i
[12:37] <cpaelzer> t
[12:57] <ahasenack> cpaelzer: snapper upstream took the armhf build fix patch
[12:57] <ahasenack> another delta will bite the dust, soon
[13:02] <jamespage> coreycb: ok so cinder looks promising - got all but on of the tempest.api.volume tests to pass first run
[13:03] <coreycb> jamespage: not bad
[13:03] <jamespage> coreycb: https://review.openstack.org/600027
[13:08] <cpaelzer> ahasenack: \o/
[13:09] <coreycb> jamespage: commented
[13:13] <jamespage> coreycb: good question about clearing out the py2 cruft
[13:16] <jamespage> coreycb: we can purge out any python-* packages from the original installed pkgs; however we'll need an autoremove helper to then purge out any deps!
[13:16] <coreycb> jamespage: ick
[13:16] <jamespage> coreycb: meh it kinda needs to happen
[13:16] <jamespage> coreycb: for example python-cinder would still be installed, but is not mention anywhere in the charm
[13:18] <coreycb> jamespage: worth noting this is likely just a rockey issue. stein will be easier. we can just make py3 alternatives have precedence.
[13:18] <coreycb> rocky
[13:18] <jamespage> agreed
[13:30] <kstenerud> ahasenack: Is there more to do with logwatch re: getting debian's attention?
[13:31] <cpaelzer> kstenerud: does "knowing the maintainer well" count?
[13:32] <ahasenack> kstenerud: did you create a merge request?
[13:32] <ahasenack> kstenerud: good morning :)
[13:32] <ahasenack> kstenerud: while I have you, keep an eye on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:32] <ahasenack> kstenerud: your bind9 sponsored upload is in there
[13:51] <jamespage> coreycb: https://github.com/juju/charm-helpers/pull/209
[14:12] <ahasenack> kstenerud: I think you can move the 1769440 card to done, bind9 migrated. Did you check that proposed-migration page in time, while bind9 was still in there? Just so you know the process
[14:17] <kstenerud> ahasenack: Yes I saw it with tests passed and expected fails yellow
[14:17] <ahasenack> ok
[14:17] <ahasenack> kstenerud: that bind9 bug, it needs an sru to bionic now :)
[14:18] <ahasenack> feel free to use the same card I mentioned above, or create a new one for the sru work
[14:18] <jamespage> coreycb: do you think missing curl might be the issue on the glance autopkgtest failures as well?
[14:18] <coreycb> jamespage: yes that's the problem. i have a couple pkgs testing here: https://bileto.ubuntu.com/#/ticket/3125
[14:25] <jamespage> coreycb: ack will leave in your more than capable hands!
[14:26] <coreycb> jamespage: ha!
[14:35] <dpb1> kstenerud: did we hear back from debian on logwatch?
[14:37] <kstenerud> No, I hadn't done the change in their git repo. Working on that now
[14:39] <kstenerud> ahasenack: Is there a special procedure for making patches to salsa? Like tests to run etc?
[14:40] <ahasenack> kstenerud: nothing standard
[14:40] <ahasenack> if there are dep8 tests in the package, then I would run them
[14:40] <ahasenack> otherwise, I would show how the change was tested
[14:40] <ahasenack> don't forget it's debian, not ubuntu, when copying logs and such
[14:40] <kstenerud> So basically I just fork, make the same 2 commits, then merge req?
[14:40] <ahasenack> luckily it's easy to use a debian container
[14:41] <ahasenack> yeah, and I would leave the debian release as "UNRELEASED" in d/changelog, since the commit is not necessarily tied to a new upload
[14:41] <ahasenack> let them sort that out
[14:41] <ahasenack> but do use dch, and format d/changelog approprietly
[14:42] <kstenerud> dch?
[14:43] <ahasenack> try it :)
[14:44] <kstenerud> oh hah cool :)
[14:44] <ahasenack> I suggested dch this time, instead of git-ubuntu.reconstruct-changelog, because git-ubuntu wouldn't work in a debian container
[14:44] <ahasenack> not out-of-the-box at least
[14:45] <kstenerud> Oh, the version is labeled logwatch (7.4.3+git20161207-2ubuntu1)
[14:45] <kstenerud> should it have the ubuntu1 at the end?
[14:45] <ahasenack> nope
[14:45] <ahasenack> well, not in a debian merge request for sure
[14:46] <ahasenack> and, if the current d/changelog already has an entry with UNRELEASED, then don't create a new (versioned) one, just add your bit to the existing one
[14:46] <ahasenack> there is a format for that, you can find it on other changelog files if you look, it's like [Some Name]\n  * change
[14:49] <kstenerud> OK so I'm basically doing:
[14:49] <kstenerud>   * sshd: ignore disconnected from user USER. (closes: 855539)
[14:50] <kstenerud> 855539 being their bug report on this
[14:54] <ahasenack> kstenerud: yes, but please mention the file you are changing
[14:54] <ahasenack> like, full path
[15:07] <dpb1> kstenerud: (just curious on logwatch, since we hadn't reached out before)
[15:12] <ahasenack> cpaelzer: sea of green! https://bileto.ubuntu.com/excuses/3399/cosmic.html
[15:13] <ahasenack> cpaelzer: calling expect -f <script>
[15:13] <ahasenack> instead of <script> directly
[15:20] <cpaelzer> ok, then that shall be the solution
[16:08] <SuperLag> I'm trying to set up an Ubuntu VM on my local machine. It'll use NAT, and share the existing connection, but I'd like to make it a static IP, so when the term opens and my SSH-on-open command runs, it connects automatically. I'm not sure how do set up a static IP during the install process.
[16:24] <subvhome> Can someone direct me to a resource that can help me configure my ubuntu server to login automatically (no GUI)
[16:27] <subvhome> nevermind figured it out :)
[16:30] <dpb1> SuperLag: are you using the 18.04.1 LTS server install?
[16:58] <SuperLag> yes
[16:58] <SuperLag> dpb1: yes
[17:25] <dpb1> SuperLag: in the network config screen, you can choose a static IP
[17:56] <ahasenack> kstenerud: in your logwatch salsa mp,
[17:56] <ahasenack> kstenerud: the file you should mention in d/changelog is the patch file you are adding, not the file that the patch itself is changing
[17:57] <ahasenack> kstenerud: so, it should be d/p/ssh-ignore-disconnected.patch
[17:57] <ahasenack> (or debian/patches/...)
[17:58] <kstenerud> ah ok
[18:03] <kstenerud> ahasenack: For the strongswan repro case, I'm going to have to set up a fairly complicated thing with config files and scripts. How would I fit that to the bug report and MP?
[18:03] <ahasenack> kstenerud: strongswan related to logwatch?
[18:04] <ahasenack> or that other mp which was started by a community member?
[18:04] <kstenerud> the other mp
[18:04] <kstenerud> I'll need to set up a vpn server and client in separate machines and then test with different versions on the client side
[18:04] <ahasenack> it is complicated indeed. I would suggest to just run the dep8 tests, they cover a lot already
[18:05] <ahasenack> I mean,
[18:05] <ahasenack> not the depp8 tests
[18:05] <ahasenack> the qa-regression-tests
[18:05] <ahasenack> https://launchpad.net/qa-regression-testing
[18:05] <ahasenack> inside the scripts directory, there is a test-strongswan.py script
[18:05] <ahasenack> with instructions
[18:07] <ahasenack> this mp of mine, from some days ago, went through them. The description of the mp has pastebins showing these scripts being run: https://code.launchpad.net/~ahasenack/ubuntu/+source/strongswan/+git/strongswan/+merge/353642
[18:10] <ahasenack> kstenerud: btw, your logwatch salsa mp, you still have the old s/s/ path in the changelog entry, not sure if you saw that. I see you changed the mp title
[18:14] <kstenerud> ahasenack: how were you able to see the diffs on salsa? I can't find a button for it
[18:16] <kstenerud> also, for that entry, I was copying from previous entries in the changelog, like: s/s/amavis: Fix perl warning "redundant argument in sprintf".
[18:18] <kstenerud> should I change it to the other style in changelog?
[18:26] <ahasenack> kstenerud: there are three tabs in the MR page
[18:26] <ahasenack> discussion, commits, changes
[18:26] <ahasenack> it defaults to discussion
[18:29] <ahasenack> kstenerud: about s/s, hm, I see the previous entries. It looks odd
[18:29] <ahasenack> I'm fine either way then, as you prefer
[18:48] <kstenerud> ahasenack: How do I initiate a qa-regression test?
[18:49] <ahasenack> kstenerud: branch that code, cd into scripts/
[18:49] <ahasenack> there is a readme file in that dir
[18:49] <ahasenack> start with     $ sudo ./install-packages test-foo.py
[18:50] <ahasenack> that will install dependencies needed by that particular test-<foo>.py script
[18:50] <ahasenack> then read instructions on that script test
[18:50] <ahasenack> er, test script
[18:51] <kstenerud> All I see are a bunch of *.c files in scripts
[18:52] <kstenerud> find . -name install-packages returns nothing
[18:57] <ahasenack> kstenerud: "that code" -> https://launchpad.net/qa-regression-testing
[18:57] <ahasenack> is that what you branched?
[18:57] <ahasenack> https://code.launchpad.net/qa-regression-testing
[19:09] <kstenerud> ahasenack: Is this meant to be cloned and run from within a vm?
[19:09] <ahasenack> kstenerud: yes, and it's meant to be run on the machine where the software you are testing is installed
[19:10] <ahasenack> so a vm or lxd is best, yes
[20:09] <sdeziel> cpaelzer: re LP: #1789551, I'm not sure don't understand why Xenial would be harder to tackle than Bionic. Isn't is just a matter of calling "seccomp_attr_set(ctx, > SCMP_FLTATR_CTL_TSYNC, 1)" irrespective of whitelist vs blacklist?
[20:09] <ubottu> Launchpad bug 1789551 in qemu (Ubuntu Bionic) "qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads" [High,Triaged] https://launchpad.net/bugs/1789551
[20:41] <ahasenack> kstenerud: in the command line from that MP I pasted you earlier,
[20:41] <ahasenack> sudo ./test-strongswan.py $test 192.168.122.78 10.0.2.0/24 192.168.122.42 10.0.1.0/24 -v
[20:41] <ahasenack> 192.x.x.x is the libvirt network where the vm is on
[20:42] <ahasenack> 10.0.2 and 10.0.1 are made up networks, no config at all. the test script will set that up
[20:42] <kstenerud> ok
[20:49] <ScottE> Oh boy, this is going to be fun... We're finding users who upgrade to openssh 7.8 can no longer ssh to our ubuntu servers due to some strictness in the new openssh version. I created https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963 with links to the same issue found in other Linux distro. It's unclear what the right fix is, but thought I would mention it here because it's likely to have
[20:49] <ubottu> Launchpad bug 1790963 in openssh (Ubuntu) "Unable to connect with openssh 7.8 client" [Undecided,Confirmed]
[20:49] <ScottE> wide blast radius.
[20:54] <blackflow> ScottE: not sure I see this problem here
[20:55] <blackflow> ScottE: hmmm, wait, 7.8 clients when connecting to older clients, you say?
[20:57] <ScottE> blackflow Basically the 7.8 client is not (fully) compatible with openssh version <7.8
[20:58] <TJ-> ScottE: according to the release notes, the breakage should only occur in non-default configurations. Is that the case here, or is the Ubuntu default for 7.6/7.7 causing the issue
[21:00] <blackflow> ScottE: yea I thought I was running 7.8 but I'm not, it's 7.6. I'm gonna test now with 7.8 from Fedora
[21:00] <ScottE> You very well could be correct there TJ- we're still in the process of trying to figure that out
[21:03] <TJ-> here, on 18.04 with v7.6, "sshd -T" with no sysadmin over-ride shows "hostbasedacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa"
[21:04] <TJ-> And pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
[21:07] <TJ-> seems like a daft change for openssh to make though; keeping the option name with *KeyTypes but changing the semantics to mean *SignatureAlgorithms! Recipe for confusion there
[21:08] <ScottE> Yeah, it's looking very likely that our custom server config (with the intent to improve security) is causing the breakage here. I never did suspect it to be an Ubuntu bug per se
[21:10] <ahasenack> so the option is still called PubkeyAcceptedKeyTypes, but now its value is a signature algorithm instead of a key type?
[21:11] <blackflow> ScottE: yeah, default configs work just fine
[21:11] <blackflow> 7.8p1 client from Fedora connecting to 7.6 Ubuntu and 7.2 FreeBSD
[21:12] <ScottE> blackflow great, thanks for the confirmation on that - that will greatly limit who runs into this right there
[21:13] <TJ-> ahasenack: that's seems to be correct
[21:13] <TJ-> ahasenack: I guess (some of) the values were always signature algorithms, not key-types
[21:14] <TJ-> ScottE: well, your changes did improve security - no-one could connect :)
[21:14] <kstenerud> ahasenack: None of the tests fail in bionic. I'm not really sure how to cause the issue
[21:14] <ScottE> TJ- haha
[21:15] <ahasenack> kstenerud: did you see apparmor denied messages in dmesg?
[21:15] <kstenerud> nope
[21:15] <ahasenack> kstenerud: then ok, proceed with just the dep8 results, we will rely on the reporter for this one
[21:15] <kstenerud> ok
[21:17] <TJ-> did I see mention of a possible strongswan problem? (wondering if it's something I've hit recently!)
[21:22] <ahasenack> TJ-: https://code.launchpad.net/~fermulator/ubuntu/+source/strongswan/+git/strongswan/+merge/353423
[21:22] <ahasenack> bug being #1786250
[21:23] <ahasenack> kstenerud: wait, was apparmor even enabled for strongswan? It might be an optional apparmor profile
[21:23] <TJ-> ahasenack: hmmm, I think I've been seeing NetworkManager reporting the same
[21:23] <kstenerud> How do I check?
[21:24] <sdeziel> strongswan's apparmor is enabled by default IIRC
[21:24] <sdeziel> kstenerud: aa-status
[21:25] <sdeziel> you should see charon as being confined
[21:25] <TJ-> ahhh, no, slightly different. I've been seeing: <warn>  [1536149701.2078] error requesting auth for org.freedesktop.NetworkManager.enable-disable-connectivi
[21:25] <TJ-> ty-check: Authorization check failed: Failed to open file “/proc/1554/status”: No such file or directory
[21:26] <TJ-> I see "enforced" for /usr/lib/ipsec/charon
[21:30] <kstenerud> sdeziel: It says charon is unconfined
[21:31] <ScottE> So this openssh issue might be only when using certificates (which we do) - compiling 7.8 with the same config works fine - so it appears not our customization - I'll update the bug with specific mention around certificates
=== keithzg_ is now known as keithzg
[23:57] <SuperLag> RHEL has a kickstart configurator that'll give you at the very least a template to work from for kickstart files. Is there an Ubuntu equivalent for preseed files?