On Tue, Jun 04, 2024 at 11:53:17PM +0100, Luca Boccassi wrote: > > This has recently been fixed in the systemd packages for sid/trixie. > [4] > > I'm going to reassign this to the systemd maintainers for now to see > if > > they're willing to backport (or accept a merge request to backport) > this > > fix to bookworm for an upcoming point release. If they aren't > willing > > to do that (the blast radius for such a change is wide and they may > not > > be comfortable introducing it in a stable release), then we can > consider > > making the change in the cloud images. That's less desirable because > it > > introduces a change to a conffile, which will introduce issues on > > upgrades, but we will see. > > Such a change in a stable release would be very risky, and at the very > least it would need to get buy-in from the release team in advance. If > you want to ask RT if they are ok with it, and then thoroughly test it > and provide a MR, with RT's blessings, then I will merge it and include > it in the next point release.
The commits in https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162 cherry pick cleanly to the debian/bookworm branch and have the expected effect when libnss-myhostname is freshly installed. Test scenarios: [*] Fresh install of libnss-myhostname (nsswitch.conf lists the modules in the expected order) [*] Upgrade of libnss-myhostname (this does not attempt to rewrite nsswitch.conf, which is the same as upgrading to the fixed version in trixie) [ ] Validate that the name resolution behavior is correct with the new nss module ordering; that is attempts to resolve the local hostname, localhost.localdomain, _gateway, and _outbound are handled by nss-myhostname and don't result in a DNS lookup [ ] Validate that resolution of external names is unimpacted [ ] validate that a cloud image build based on the updated packages lists the nss modules in the desired order, with myhostname ahead of dns Is there any specific additional testing that the systemd maintainers would like to see? noah
