[09:20] <lordievader> Good morning
[10:18] <rbasak> kstenerud: if you're still looking for bugs, bug 1581864 might be an interesting one to tackle.
[10:18] <rbasak> Unless teward is already working on it?
[10:21] <rbasak> ahasenack: see bug 1677755. Maybe worth updating the bug with Disco inclusion staus (I know it's still closed, but is a branch pending somewhere?)
[10:24] <rbasak> cpaelzer__, kstenerud: I think bug 1800040 can be low prio as it's armhf only. Shall I communicate that with the repoerter and then leave it ("patches welcome")?
[10:29] <cpaelzer__> rbasak:  hiho
[10:29] <cpaelzer__> rbasak: you can do so (downpedal the bug to low)
[10:29] <cpaelzer__> rbasak: there were too much tests for me to get a good overview what exactly was affected eventually
[10:30] <cpaelzer> I would have needed the time to really read into it
[10:30] <cpaelzer> and that is what I asked karl to take a look
[10:31] <cpaelzer> if it really is only armhf that is affected I agree it is not too important then
[10:33] <rbasak> cpaelzer: done, thanks
[10:33] <rbasak> (every failure report has armhf in it, AFAICT)
[10:33] <rbasak> If I'm wrong, I'm sure he'll get back to us.
[10:34] <ahasenack> kantlivelong: I got it working on plain ubuntu, btw
[10:34] <cpaelzer> rbasak: thanks
[10:34] <ahasenack> there is a search order for the host's keytab
[10:35] <ahasenack> kantlivelong: did you check the rpc.gssd manpage? It lists the principals it looks for
[10:35] <ahasenack> I had a host/<fqdn>@ key for the nfs client
[10:36] <ahasenack> kantlivelong: check /etc/hosts and /etc/hostname on both machines, I think what is different is the output of "hostname -f" and those files could be setting that
[10:37] <ahasenack> kantlivelong: I found #1616123 while experimenting, btw. triplicate-filed bug, since xenial (aka, introduction of systemd) :(
[10:37]  * ahasenack wonders who owns nfs server packages
[10:50] <cpaelzer> ahasenack: you know how that works, now it is you :-)
[10:51] <ahasenack> hehe
[10:51] <ahasenack> three bugs in nfsv4 server with kerberos, I'm a bit surprised, more people use that than I expected
[10:55] <kstenerud> rbasak: I've posted a summary on the bug page for what's tested and what failed. It looks like the critical element is bacula-fd on armhf.
[10:56] <TJ-> ahasenack: if you find out who owns nfs, please ask them to deal with Bug #1697339 too
[10:59] <cpaelzer> ahasenack: your acpi MP could also contain the adding of comments for dirmngr
[10:59] <cpaelzer> the updates on the task read as if it is resolved (would be auto-installed but we want to keep it explicit)
[10:59] <cpaelzer> if that is correct we'd want to add that as a comment I think
[11:02] <ahasenack> cpaelzer: I was planing on doing one MP per package
[11:06] <ahasenack> TJ-: thanks, I'll take a look
[11:07] <TJ-> ahasenack: had a few users report that on 16.04; I helped one such last week rebuild the packages locally with the patch because they had 10s of systems affected
[11:32] <DenBeiren> is anyone around to help out with a transmission-daemon issue?
[11:55] <lordievader> DenBeiren: What is the issue?
[12:14] <ahasenack> cpaelzer: have you seen this before? https://pastebin.ubuntu.com/p/Hf34BhDnN4/
[12:14] <ahasenack> cpaelzer: it's my first multipass launch
[12:14] <ahasenack> but the files it complained about are in qemu
[12:14] <ahasenack> might be another case of a classic snap not working in an ubuntu release different from where it was built
[12:19] <cpaelzer> ahasenack: these are .so's that break out certain functions of qemu
[12:19] <cpaelzer> ahasenack: you can that way reduce your attack surface from guests, or put only some of them in main
[12:20] <cpaelzer> ahasenack: seems to be an incompatibility of your systems .so's with what is in the snap ?
[12:20] <cpaelzer> I thought LD magic should avoid that
[12:22] <DenBeiren> lordievader: i had a working system that borked,.. so i removed it, purged all packets, removed the dir and tried a reinstall.
[12:23] <DenBeiren> now it seems if i stop, edit the settings, start and check, none of the settings are changed
[12:23] <DenBeiren> altough the settingsfile is correct afaik
[12:23] <DenBeiren> change of port for example,.
[12:23] <lordievader> Are you editing the correct settings file? It might be that in an update the path changed.
[12:24] <lordievader> I had at one time three possible paths...
[12:24] <DenBeiren> /etc/transmission-daemon/settings.json
[12:24] <ahasenack> cpaelzer: I pinged #multipass
[12:24] <ahasenack> might open a bug
[12:25] <ahasenack> kstenerud: where are multipass bugs opened again?
[12:25] <lordievader> DenBeiren: What is the output of `systemctl cat transmission-daemon.service`?
[12:26] <DenBeiren> https://pastebin.com/Fv9MS3x7
[12:27] <kstenerud> ahasenack: On their github issues page
[12:27] <ahasenack> thx, got it
[12:28] <lordievader> DenBeiren: Does `/var/lib/transmission/config` exist?
[12:29] <DenBeiren> https://pastebin.com/aya2CbJ8
[12:33] <kantlivelong> ahasenack: hmm il have to check again. i had host/ and nfs/
[12:33] <ahasenack> I have nfs/ for the server
[12:33] <ahasenack> and the client has host/<fqdn>
[12:33] <ahasenack> but check the output of hostname -f
[12:33] <ahasenack> on both sytems
[12:33] <ahasenack> normally just "hostname" should be a name without dots, and "hostname -f" should be the fqdn
[12:34] <kantlivelong> right
[12:34] <ahasenack> freeipa has a different opinion, fwiw
[12:35] <kantlivelong> you used the variable mentioned in that ticket?
[12:37] <kantlivelong> didnt see any opts that applied
[12:38] <ahasenack> what variable?
[12:38] <ahasenack> you mean bug #1616123 ?
[12:41] <kantlivelong> yeah.sorry im mobile
[12:42] <ahasenack> kantlivelong: that bug is embarassing, it's been out there since xenial
[12:42] <ahasenack> kantlivelong: I will fix it
[12:42] <kantlivelong> happens
[12:43] <kantlivelong> im going to check everything again tonight when i get home
[12:44] <kantlivelong> oh and duh thats for nfs-server. shouldnt be affecting me anyway
[12:45] <ahasenack> it's for that svcgssd service in particular
[12:45] <ahasenack> but yeah
[12:45] <ahasenack> the client runs rpc.gssd
[12:46] <ahasenack> both do
[12:46] <ahasenack> anyway
[12:46] <ahasenack> found some other bugs about nfsv4 in the nfs-utils package, while looking at that one
[12:46] <kantlivelong> right. but it wouldnt use the options from nfs-kernel-server on a client would it?
[12:47] <ahasenack> nope
[12:48] <ahasenack> kantlivelong: have you tried storing the kerberos tickets in the kernel keyring? I found a bug about that, looks like rpc.gssd can't read it
[12:48] <ahasenack> I flagged it for further investigation, see what's going on upstream, what alternatives there are, check fedora, etc
[12:48] <kantlivelong> ahasenack: is that available in 16.04? i thought that was something new in later veraions
[12:49] <ahasenack> oh, I didn't check that
[12:49] <ahasenack> I mean, the bug is against 16.04, so kerberos itself can probably store it
[12:49] <ahasenack> bug #1733571
[12:49] <kantlivelong> i did notice in my logs that it looks for machine ticket using the fqdn
[12:50] <kantlivelong> or maybe you noticed that. cant remember haha
[12:50] <ahasenack> just check what hostname -f returns, it's the most likely source for the <hostname> bit in the ticket. I didn't see anything in the manpage about it being the shortname once, and later versions wanting the fqdn
[12:50] <kantlivelong> but from what i can tell there isnt a way for me to to generate an entry with that many characters
[12:51] <ahasenack> (the keyring question I brought up is about something else entirely, sorry for crossing the streams)
[12:51] <ahasenack> it was just one of those bugs I saw while looking at the state of the package
[12:52] <kantlivelong> im just grateful that your taking a look. i was going insane
[12:54] <lordievader> DenBeiren: Does that .config also exist when transmission is not runnign?
[13:09] <DenBeiren> lordievader: i believe it is
[13:09] <DenBeiren> https://pastebin.com/AW168bxj
[13:14] <Gekko> How could I configure netplan / systemd-resolved to prefer any DHCP based DNS servers, but fallback to hardcoded DNS IPs if none are found working via DHCP? I've tried adding DNS=x.x.x.x into /etc/systemd/resolved.conf, but that seems to override any DHCP based DNS
[13:15] <Gekko> I'm trying to make this system manage DNS configuration in any network it's plugged into, regardless of if the local LAN offers DNS or not
[13:15] <Gekko> Ubuntu server 18.04
[13:17] <Gekko> So far the cases I've had involved all public DNS IPs being blocked in the network, and configured LAN DNS not working
[13:18] <Gekko> But never both
[13:18] <kstenerud> Does anyone know how to build debian packages using git-buildpackage? I'm using https://wikitech.wikimedia.org/wiki/Git-buildpackage as a guide, but it errors out right at the start :/
[13:21] <TJ-> Gekko: maybe you can use netplan's "optional" and "optional-addresses" ?
[13:22] <Gekko> I'll read about them, thanks
[13:22] <TJ-> Gekko: I suspect those only apply to the IP address allocation itself though
[13:24] <kantlivelong> ahasenack: hostname -f returns the right fqdn, hostname shows fqdn, hostname -s shows shortname
[13:25] <kantlivelong> looks right
[13:25] <ahasenack> in both machines?
[13:25] <kantlivelong> both clients or server and affected client?
[13:26] <kantlivelong> its right on the server
[13:26] <ahasenack> the client that can't mount
[13:26] <kantlivelong> yeah its valid
[13:27] <ahasenack> ok
[13:27] <TJ-> Gekko: I think you're better off doing it directly in systemd-networkd config; using "UseDNS=True" (the default) DHCP addresses take precendence over manually set addresses
[13:27] <ahasenack> kantlivelong: so the complaint on that client was that the principal it selected from /etc/krb5.keytab wasn't found on the server datbase
[13:27] <kantlivelong> ahasenack: server meaning krb5 server?
[13:27] <ahasenack> yes
[13:27] <kantlivelong> its certainly there
[13:28] <kantlivelong> matches the working client
[13:28] <kantlivelong> (minus the shortname of course)
[13:30] <kantlivelong> https://i.imgur.com/BiHL3Bf.png
[13:30] <ahasenack> from your earlier pastebin,
[13:30] <ahasenack> it's looking for these in /etc/krb5.keytab, in this order:
[13:30] <ahasenack> 1) ADTESTUBUNT.XXX.YYY.ZZZ$@XXX.YYY.ZZZ
[13:30] <ahasenack> 2) root/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ
[13:30] <ahasenack> 3) nfs/adtestubunt.xxx.yyy.com@ <--
[13:30] <ahasenack> it found the 3rd
[13:31] <kantlivelong> #1 is where i have concern
[13:31] <ahasenack> and then says
[13:31] <ahasenack> WARNING: Client 'nfs/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ' not found in Kerberos database while getting initial ticket for principal 'nfs/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ' using keytab 'FILE:/etc/krb5.keytab'
[13:31] <kantlivelong> shouldn't it be looking for ATESTUBUNT$@XXX.YYY.ZZZ?
[13:31] <ahasenack> the manpage just says "<hostname>", without detailing if it's the fqdn or not
[13:32] <kantlivelong> the shortname is certainly there
[13:33] <kantlivelong> :/
[13:33] <kantlivelong> have to head to work now tho
[13:34] <ahasenack> on my ubuntu client, it does look for the short name as well
[13:34] <ahasenack> I mena, ubuntu 18.04
[13:34] <ahasenack> kantlivelong: https://pastebin.ubuntu.com/p/6pb4GCRWjm/ it stopped when it found the host/ key
[13:34] <ahasenack> it's what I'm using
[13:35] <ahasenack> gssd_get_single_krb5_cred: principal 'host/nsnx.lowtech@LOWTECH' ccache:'FILE:/tmp/krb5ccmachine_LOWTECH'
[13:35] <ahasenack> and I actually have the key with the fqdn in the keytab
[13:36] <kantlivelong> odd.
[13:36] <ahasenack> so how come you have nfs/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ in the keytab, but no such principal exists in the kdc?
[13:36] <kantlivelong> im not asking you to or anything but i wouldnt object if you had interest in hopping on the boxes
[13:37] <kantlivelong> the nfs/fqdn is definitely there
[13:38] <ahasenack> can you kinit that principal?
[13:38] <ahasenack> like
[13:38] <ahasenack> kinit -V -t /etc/krb5.keytab -k <principal>
[13:38] <ahasenack> for example, here:
[13:38] <kantlivelong> on the client or ad?
[13:38] <ahasenack> kantlivelong: https://pastebin.ubuntu.com/p/ZhgVs5cw7B/
[13:38] <ahasenack> client
[13:38] <ahasenack> on that machine where rpc.gssd failed
[13:39] <ahasenack> using nfs/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ as the principal
[13:39] <ahasenack> because that's what rpc.gssd tried to do, after finding nfs/adtestubunt.xxx.yyy.com@XXX.YYY.ZZZ in the keytab
[13:39] <kantlivelong> ill give it a shot
[13:40] <Gekko> TJ-: thanks, I'll see if that does it. I had to remove some entries from /etc/systemd/resolved.conf as apparently there can be too many, says systemd
[13:41] <Gekko> Right now I'm getting nameserver 8.8.8.8 followed by nameserver local_ip_here in /run/systemd/resolve/resolv.conf, so maybe it's good enough
[13:43] <TJ-> ahasenack: this might be useful for you, a patch that landed for 1.2.9. The commit messsage is insightful: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bdc50fc12a621545feaf9925999723d45171c34d
[13:43] <TJ-> ahasenack: bearing in mind the issue is on 16.04 with 1.2.8, and 18.04 has 1.3.4
[13:43] <ahasenack> and upstream is past 2.x
[13:44] <TJ-> ahasenack: 1.2.8 was 2013 :)
[13:45] <TJ-> there is a 2nd commit immediately before ^^ that one with the same commit message:  http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=a6ab6f63de618180127daadc070d696f6268000f
[13:45] <TJ-> ahasenack: I'm looking at the commits pre 1.2.9, listed at http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog;pg=5
[13:46] <ahasenack> TJ-: the order in which it looks up the principals (line 126+ in https://paste.ubuntu.com/p/GZqqcGgsvk/) matches the rpc.gssd manpage
[13:47] <TJ-> here's another one, talking specifically about the fqdn/hostname http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=05e6d39a988e76d5803f79018a9e40d435f6d2f7
[13:47] <ahasenack> I don't know what the target= field is that he mentions
[13:48] <ahasenack> kantlivelong: all that being said, let me try on xenial, I've been trying with bionic as the client
[14:10] <ahasenack> kantlivelong: worked with a xenial client as well: https://pastebin.ubuntu.com/p/Htpvgq6fy4/
[14:17] <TJ-> ahasenack: "target=" refers to the part to the right of the @, the realm, I thinik, from looking at the code (where service is to the right of the @)
[14:17] <ahasenack> it's @REALM, yep
[14:17] <ahasenack> it's something like <name/someoptionalqualifier@REALM>
[17:08] <rbasak> ahasenack: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/358334 please, to put the git-ubuntu fire out.
[17:08] <ahasenack> saw it
[17:08] <ahasenack> rbasak: you are using the +build path from launchpad because this package is not in discoyet?
[17:09] <rbasak> ahasenack: it is actually in Cosmic. But that will end up in oldreleases. Launchpad will last longer.
[17:10] <ahasenack> rbasak: I think you can use http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-keyring/ubuntu-keyring_2018.09.18.1_all.deb, is that better?
[17:10] <ahasenack> or not, for the reason you just mentioned
[17:11] <ahasenack> kstenerud: did you get your debian mysql build issue sorted out after standup?
[17:16] <ahasenack> rbasak: my master (and I updated, I think?) doesn't have test_gpg_public_key_list() in gitubuntu/integration_test.py, do you know what's going on?
[17:17] <ahasenack> https://git.launchpad.net/usd-importer/tree/gitubuntu/integration_test.py also doesn't
[17:18] <ahasenack> oh, wait
[17:18] <ahasenack> ok, n/m
[17:18] <ahasenack> was confused by a commit message
[17:22] <rbasak> BTW CI is still running.
[17:23] <rbasak> But I've tested a full build/CI run locally, etc. I will wait for the official one before merging.
[17:47] <rbasak> ahasenack: thanks!
[20:18] <granjero> hi, ubuntu server 18.04 fstab looks quite empty. is still working for mounting windows shares at startup?
[20:19] <cryptodan_mobile> granjero: https://www.hiroom2.com/2018/05/04/ubuntu-1804-cifs-utils-en/
[22:41] <kantlivelong> ahasenack: hmm. cant kinit on either the working or non-working box. have to do it from ad
[23:03] <kantlivelong> i might have found hte issue.. will check