This makes things a bit simpler and the build a bit faster, because we don't
have to rewrite files to do the trivial substitution. @rootbindir@ is always in
our internal $PATH that we use for non-absolute paths, so there should be no
functional change.
According to the designer of the page layout a page only should have one
h1 header, and everything else should be h2, h3, … I think that makes a
ton of sense, hence let's downgrade some headers here.
In SecureBoot mode this is probably not what you want. As your cmdline
is cryptographically signed like when using Type #2 EFI Unified Kernel
Images (https://systemd.io/BOOT_LOADER_SPECIFICATION/) The user's
intention is then that the cmdline should not be modified. You want to
make sure that the system starts up as exactly specified in the signed
artifact.
'stored on disk' gives the impression that this option affects only
permanent storage, even though it affects everything the journal
records, regardless of the storage type.
Use 'stored in the journal' to avoid confusion.
We need to run sysctl also in containers, because the network
subtree is namespaces and may legitimately be writable. But logging
all "errors" at notice level creates unwanted noise.
Also downgrade message about missing sysctls to log_info. This might also be
relatively common when configuration is targeted at different kernel
versions. With log_debug it'll still end up in the logs, but isn't really worth
of "notice" most of the time.
https://bugzilla.redhat.com/show_bug.cgi?id=1609806
This section is loaded in a bunch of places, so this affects many
man pages.
1. point the reader to the synopsis section, which has the exact paths
that are used to load files.
2. put the "reference" part first, and recommendations later, in separate
paragraphs.
3. describe how individual settings and whole files are replaces.
Closes#12791.
This extends on d253a45e1c, and instead of
merging just a single flag from previous mount entries of
/proc/self/mountinfo for the same path we merge all three.
This shouldn't change behaviour, but I think make things more readable.
Previously we'd set MOUNT_PROC_IS_MOUNTED unconditionally, we still do.
Previously we'd inherit MOUNT_PROC_JUST_MOUNTED from a previous entry on
the same line, we still do.
MOUNT_PROC_JUST_CHANGED should generally stay set too. Why that? If we
have two mount entries on the same mount point we'd first process one
and then the other, and the almost certainly different mount parameters
of the two would mean we'd set MOUNT_PROC_JUST_CHANGED for the second.
And with this we'll definitely do that still.
This also adds a comment explaining the situation a bit, and why we get
into this situation.
(This also changes the suggested /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).
This also updates the suggested PAM snippet in a number of way:
1. Be closer to the logic nowadays implemented in Fedora where the
auth/account/password stacks are all finished off with
pam_{deny|permit}.so
2. Make pam_unix.so just "sufficient" instead of "required" (paving
ground for pam_systemd_home.so being hooked in as additional
sufficient module.
3. Only do pam_nologin in the "account" stack, since it's about account
validity really.
4. Use modern parameters to pam_unix when changing passwords, i.e.
sha512 and shadow, and use already set up passwords (preparing ground
for pam_systemd_home again)
Zbigniew Jędrzejewski-Szmek