I am pretty sure /etc/hosts (i.e. an explicitly configured, local,
trusted database) should be useful for overriding the automatic
myhostname logic.
resolved's internal logic handles it that way and hence we should
suggest it in the NSS fallback line, too.
Let's also bring the factory file back into sync with what the docs say.
And update the prose a bit too, to actually match what we recommend.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
This changes nss-systemd to use the new varlink user/group APIs for
looking up everything.
(This also changes the factory /etc/nsswitch.conf line to use for
hooking up nss-system to use glibc's [SUCCESS=merge] feature so that we
can properly merge group membership lists).
Fixes: #12492
Booting up an image with --volatile=yes otherwise looks so naked, so
let's include this file in the default factory too. It's common and
simple and should be safe to ship.
Apparently PAM reacts differently on different systems (?) and if no
authoritative matching module is found might either succeed/fail,
depending on the system.
Let's lock this down explicitly, by hooking in pam_deny.so.
Of course, these PAM files are just examples, and no distro in its right
mind would ship these unmodified, but let's default to something safe.
Fixes: #12950
Stupid PAM, please just go away!
login[26]: pam_limits(login:session): error parsing the configuration file: '/etc/security/limits.conf'
login[26]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
login[26]: Error in service module
