Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux