On Thu, 2018-12-06 at 16:00 +0000, Zbigniew Jędrzejewski-Szmek wrote: > 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. I wonder if we should think of a tighter system integration and subsume the tasks of nss_machines into SSSD. It would allow for detection and logging of UID conflicts should they happen in a live system with the ability, for the admin to better choose which of the pools should have priority in case of conflict ... Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ 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
