[11:40] I see lots of build failures in the update excuses pages without logs from syncs in the past ~4 hours; I am retriggering some of the php ones. === athos_ is now known as athos [12:54] does anyone know how to use resolvectl to accomplish this: use 192.168.122.10 for the "test.lan" domain, and 192.168.122.1 for anything else, including a "vms" search domain [12:54] I'm trying to use the SNI syntax, but it just complains, even though the manpage says it should work [12:55] like "That is, the acceptable full formats are "111.222.333.444:9953%ifname#example.com" for IPv4" [12:55] root@j-dc:~# resolvectl dns 192.168.122.1:53%enp1s0#vms [12:55] Failed to resolve interface "192.168.122.1:53%enp1s0#vms": Invalid argument [12:56] even /etc/systemd/resolved.conf has that SNI example [12:56] # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: [12:56] # Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com [12:57] oh, this worked: resolvectl dns enp1s0 192.168.122.1#vms [12:57] well, it didn't complain [13:12] ahasenack: the SNI thing is for DNS over TLS (DoT) or DNS over HTTPS (DoT) certificate validation (where https://1.1.1.1/ should have a cert with a CN or SAN matching "cloudflare-dns.com") [13:13] I knot SNI has a meaning in the TLS context, but here I thought it was also just a way to specify routing [13:13] that syntax, ip:port%nic#domain is also used by dnsmasq [13:13] well, not the exact same syntax [13:13] --server=[/[]/[domain/]][[#]][@] [13:14] so, back to the original question, forgetting about this sni [13:14] there must be a way to use resolvectl via its command line options to do what I described? [13:15] https://pastebin.com/k2E4VN62 is my starting point, after reboot [13:15] ahasenack: `resolvectl dns enp1s0 192.168.122.1 domain vms` maybe [13:16] or possibly use `~vms` instead [13:16] this is a syntax error: resolvectl dns enp1s0 192.168.122.10 domain ~test.lan [13:16] I think each dns and domain are their own commands [13:17] ahasenack: https://linuxcontainers.org/lxd/docs/latest/howto/network_bridge_resolved/ might give you a hint [13:17] yeah, I googled that too, but so far I only have hints [13:17] not answers :) [13:19] ahasenack: I don't know why but the LXD doc does 2 calls to resolvectl, one for the dns and another for the domain so maybe that's important somehow [13:19] yeah, but I want the domain from the second call to use a different dns ip [13:19] so somehow I need to tie those together [13:19] I have two dns servers [13:19] domain vms -> 192.168.122.1 [13:19] domain test.lan -> 192.168.122.10 [13:20] and another default resolver? [13:20] what's unique here probably is that it's only one nic [13:26] it's too geared towards interfaces [13:30] ahasenack: might be one for #systemd [14:02] sergiodj: ok, std join from kinetic, old sssd (2.6.3), failed with a more reasonable error [14:02] * (2022-06-21 14:01:56): [gpo_child[1474]] [copy_smb_file_to_gpo_cache] (0x0400): [RID#8] smb_uri: smb://j-dc.test.lan/sysvol/test.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Microsoft/Windows NT/SecEdit/GptTmpl.inf [14:02] and [14:02] * (2022-06-21 14:01:56): [gpo_child[1474]] [copy_smb_file_to_gpo_cache] (0x0020): [RID#8] smbc_getFunctionOpen failed [2][No such file or directory] [14:02] OK [14:03] so it tried to fetch that gpo, which does not exist, and failed [14:03] access denied [14:03] alright, makes sense [14:03] what should I check now, create that file, or upgrade sssd? :) [14:03] I think create that file [14:03] (actually, No such file or directory) [14:03] yeah, create the file [14:03] baby steps [14:05] ok, worked [14:05] the login worked? [14:05] yes, on kinetic, sssd 2.2.x, with the inf file [14:05] so far so good [14:05] that's good [14:05] now add cráshed to GPT.INI [14:06] this drove us nuts yesterday [14:06] I'm thinking about snapshotting this vm [14:06] good idea [14:06] both are snapshotted: server and client [14:07] # echo "displayName=crásher" | iconv -f UTF-8 -t CP850 >> GPT.INI [14:08] * (2022-06-21 14:07:55): [gpo_child[1585]] [perform_smb_operations] (0x0020): [RID#16] Cannot parse ini file: [84][Invalid or incomplete multibyte or wide character] [14:08] failed as expected [14:08] now upgrade sssd? [14:08] this on k still [14:08] * ahasenack checks on the sssd migration [14:08] failed to build? [14:09] ah, the i386 [14:09] time to ping vorlon [14:09] I'll grab it from the ppa [14:09] https://launchpad.net/~sergiodj/+archive/ubuntu/sssd-bugfix/ right? [14:10] ahasenack: yes [14:10] ahasenack: I pinged vorlon yesterday. will ping again [14:12] E: The repository 'https://ppa.launchpadcontent.net/sergiodj/sssd-bugfix/ubuntu kinetic Release' does not have a Release file. [14:12] wait, what? [14:12] I uploaded the package yesterday "just in case" [14:12] what indeed [14:12] I did the usual add-apt-repository -y -u [14:12] and apt update again [14:13] oh, wait [14:13] you don't have a kinetic build there [14:13] don't I? [14:13] ah, right [14:13] no, was it a different ppa for the merge? [14:13] yes [14:13] should be sssd-merge [14:13] yep [14:13] https://launchpad.net/~sergiodj/+archive/ubuntu/sssd-merge/+packages [14:14] you, sir, need to do some cleanup in your ppas :) [14:14] hah [14:15] ok, updating to 2.7.1 [14:15] btw, have you done anything different when setting up the samba AD DC VM? [14:15] yes [14:15] I'm still wondering why I can't make the GptTmpl.inf trick work here [14:16] on the ad dc, just install "samba winbind" [14:16] hm [14:16] no need for libnss*, krb5-kdc [14:16] or pam [14:16] OK, that was it? [14:16] can't say [14:16] I just simplified things [14:16] I will simplify the Test Plan too [14:16] and the samba wiki says to not use the ad as a file server, so there is no need to actually install libnss-winbind and use it, afaik [14:17] I also did some things around resolved and netplan [14:17] but no rocket science, just simplifying it [14:17] and yes, we have to disable systemd-resolved [14:17] OK [14:17] samba doesn't like that it cannot bind to 0.0.0.0:53, even though resolved is only using 127.0.0.53:53 [14:18] ok, sssd upgraded [14:18] login should work now, with a notice about the invalid chars in GPT.INI being replaced by "?" [14:18] nope [14:18] got "permission denied" now [14:19] * (2022-06-21 14:18:35): [gpo_child[3892]] [copy_smb_file_to_gpo_cache] (0x0400): [RID#5] smb_uri: smb://j-dc.test.lan/sysvol/test.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI [14:19] * (2022-06-21 14:18:41): [gpo_child[3892]] [copy_smb_file_to_gpo_cache] (0x0020): [RID#5] smbc_getFunctionOpen failed [13][Permission denied] [14:19] that same permission denied? [14:19] this is bonkers [14:19] hm [14:20] and this is with sssd 2.7.1-2, right? [14:20] yes [14:20] maybe we should try a join with that version already [14:20] maybe it's an upgrade problem [14:20] wait [14:20] can you revert the change to GTP.INI and try again? [14:21] sure [14:21] GPT.INI* [14:21] and I just realized my "echo" from above missed a \n [14:21] the file got kind of corrupted [14:21] [General] [14:21] Version=0displayName=crsher [14:21] ah [14:21] yeah, but that shouldn't trigger a Permission Denied error [14:22] but still, it failed at parsing before, so I think the test was still valid [14:22] file restored, it's working (!) [14:22] alright! [14:22] let's reintroduce the crásher, properly [14:22] yes [14:23] worked, and I got [14:23] ^[[D(2022-06-21 14:23:33): [gpo_child[4045]] [gpo_sanitize_buffer_content] (0x3f7c0): [RID#20] Value for key 'displayName' contains non-ascii symbol. Replacing with '?' [14:23] OK, so everything is working, then [14:23] so, hm [14:23] yeah [14:24] but I still have the .inf file I think [14:24] yeah, let me get rid of it [14:24] OK [14:24] worked again [14:24] that should still work [14:24] but I got two replacement warnings [14:24] like it fetched GPT.INI twice [14:25] maybe that's what happened before with the corruption, the first time it replaced the á with ?, and then the second time the file was really invalid due to my bad echo > [14:25] hm, no, it was probably something to do with a local cache [14:26] now I just get one parsing notice [14:26] I'm happy that you finally got everything to work, but I am puzzled about why my setup doesn't work [14:26] well, even my "all is working" might be temporary [14:26] as it was yesterday [14:26] yes, this setup is very fragile [14:27] one thing I did was just not use dhcp on the addc [14:27] I'm actually impressed at how easy it is to break it [14:27] specified everything manually [14:27] ip, nameserver, default route [14:27] also specified myself as a dns server, and .1 [14:27] and in smb.conf, there is a forwarder to .1 [14:27] the provisioning tool adds a forwarder to 127.0.0.53 [14:28] you know, yesterday I was really suspicious of my DNS setup here [14:28] trying to cope with systemd-resolved I gues [14:28] now, let's try jammy [14:28] OK [14:29] heh, this is all part of the MP review [14:29] sssd/samba/winbind/allthatstack is definitely not simple [14:29] it can be 1h or 1d [14:29] imagine taking care of this in production [14:30] even maintaining the packages and coping with all scenarios would require a team over here [14:30] one can say that 2 people are already a team ;) [14:31] yeah, calling is a coupld would be weird [14:31] :D [14:31] couple* [14:31] duo [14:31] but I do agree, this is all complex and requires a lot of time to setup [14:32] on the + side, this works, no need to specify the samba ip: # realm discover -v test.lan [14:32] just the domain [14:32] once this client machine is using the samba addc as its dns server [14:33] I think it's the DNS that fixed it [14:33] if you're available, I'd like to compare notes after the standup [14:33] right after I can't, family lunch [14:33] but I can now [14:33] OK [14:33] meet you there [15:47] athos: https://code.launchpad.net/~bryce/ubuntu/+source/nginx/+git/nginx/+merge/424337 has an empty comment from you and I think you grabbed the slot. Is this intentional? [16:07] rbasak: I picked the slot but tried to restore it at some point. I thought I did it. [16:08] given the size of the merge, it would be nice to have someone who did touch nginx before to review that one [16:08] rbasak: I guess I could not re-assign that slop [16:08] slot* [16:09] when do they make 22.04.1? [16:09] Soni: around august [16:13] athos: no problem I'll review, thanks. [16:13] (not sure I'll finish today though) [16:22] thanks, rbasak :) [16:29] Soni: if you're already running 22.04 it will automatically become 22.04.1 just by keeping it up to date [16:29] no need to re-install [20:31] sergiodj: does this just need a retry click? https://launchpad.net/ubuntu/+source/sssd/2.7.1-2ubuntu1/+build/24097136 [20:32] ahasenack: https://launchpad.net/ubuntu/+source/jose/11-2/+build/24097239 -- jose's build is still pending [20:32] has been like this for hours and hours [20:32] "start in 42min" [20:34] sometimes I think someone should write a crawler to parse the build page and use this estimate as a random number generator [20:36] did you trigger that build, or it's been like this since yesterday perhaps? [20:37] if you cancel it, can you retry it? [20:37] ahasenack: vorlon triggered that build [20:37] yesterday, when he added jose to i386 [20:38] I can try cancelling it, but I don't know if this will have any undesired consequences or not [20:41] I'll wait a bit more. if it doesn't start building by my EOD, I'll cancel and retry