On 12/6/18 2:36 PM, 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.
Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would
say that this must be solves if this module is enabled by default. Was
there any progress in this area?
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.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
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
_______________________________________________
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
