On Thu, Dec 06, 2018 at 02:36:36PM +0100, Lennart Poettering wrote: > On Do, 06.12.18 12:20, Pavel Březina (pbrezina@xxxxxxxxxx) wrote: > > > Hello, > > Heya! > > > systemd and nss-mdns packages modifies nsswitch.conf in their %post > > scriptlets which creates conflicts with authselect on systems that are > > configured by authselect. This needs to be solved somehow. > > > > Originally, I wanted to create an authselect command that can be used by > > packages on systems that are configured by authselect and on systems that > > are configured with different ways [1]. But it turned out that there are > > only two packages that touches nsswitch.conf so I do not think this is > > necessary. > > > > I prepared initial design document with multiple solutions that came to my > > mind [2] and I would like to discuss this with the community to see what is > > the correct and desired way to solve this. > > nss-systemd should be in nsswitch.conf by default. It's required for > systemd's DynamicUser=1 option to work correctly, and that's core > service functionality. Hence, given that systemd is Fedora's PID 1, > nss-systemd should also be in nsswitch.conf unconditionally (in the > 'passwd' and 'group' lines). A system where nss-systemd is not enabled > is simply broken right now. > > nss-myhostname should be in nsswitch.conf by default too. It's very > minimal, and just makes sure the local hostname remains resolvable all > the time. By enabling this, installers and image generators don't have > to patch /etc/hosts anymore like they traditionally did, in fact they > can remove it altogether and just leave resolution of the local > hostname to the module, and it will magically follow whatever is > currently set via sethostname(). This module should be in the 'hosts' > line. > > Then there is nss-mymachines. It's primarily useful if > systemd-machined or systemd-nspawn is used. Given that those are now > part of the 'systemd-container' RPM it would be OK to also add > nss-mymachines to nsswitch.conf only when the RPM is installed, if > there's a concept for that. That said, in order to simplify things, > and given that systemd is a very core part of the OS I'd personally > just put it statically in nsswitch.conf too by default. After all a > missing NSS module listed in nsswitch.conf is just skipped, hence this > should not matter. This module should be in the 'passwd', 'group' and > 'hosts' lines. > > Finally, there's nss-resolve. It's the client side to > systemd-resolved. It's the client side to systemd-resolved's > DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in > Fedora right now. Quite frankly I think it should be, but that's another > political discussion (and I am not sure I am ready to have it right > now). The module is benign though: if resolved is not running it > doesn't do anything. It only does its thing if resolved is > running. Thus I'd also suggest to just enable it by default, and > simplify things because then people can use resolved just by doing > "systemctl enable systemd-resolved" and don't need to do anything > else. This module should be in the 'hosts' line. > > Summary: I'd make things simple, and enable all four unconditionally > and by default without any dynamic infrastructure, without postinst > scripts or anything. If that's not acceptable, then at least two of the > four should be unconditionally enabled. I also think we should "enable" them unconditionally, in the sense that they should be configured in the default /etc/nsswitch.conf configurations. As Lennart wrote, if the module is not installed in the filesystem, that configuration has no effect. And if it is installed, but talks to an inactive service, it has almost no effect too (apart from the linkage and small runtime overhead). "Enabling" them in one consistent way in the normal distro configuration seems much better to me then patching it in, in a slightly different way on each installation. In QA the subject of reducing the test matrix often comes up. This is a nice opportunity: let's avoid having a nsswitch line that depends on the installation order. -- Also, we are not talking about whether those modules are active or not. They *already* *are*, on any Fedora system where the configuration was not overridden and the right packages are installed. The question is *how* they should be enabled: either through the installed file or through rpm scriptlets. Without those modules, too much stuff breaks, so disabling them is not a realistic option. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
