As I noticed a lot of missing information when trying to implement checking
for missing info. I reimplemented the version information script to be more
robust, and here is the result.
Follow up to ec07c3c80b
This tries to add information about when each option was added. It goes
back to version 183.
The version info is included from a separate file to allow generating it,
which would allow more control on the formatting of the final output.
As mentioned in the NEWS entry, it seems to see very little use, but adds
complexity in our code. It was added mainly with the goal of making it easier
for people using grub2 to modify their boot configuration, but grub2 is gaining
support for BLS snippets. On the systemd side, we now have credentials. So
let's deprecate this, and if there's no outcry, remove it in a few releases.
Let's hook up one more thing with credentials: the machine ID to use
when none is initialized yet.
This requires some reordering of initialization steps in PID 1: we need
to import credentials first, and only then initialize the machine ID.
Let's move the long explanation to the man page of the component that
interprets the credential, and keep only a brief summary in
systemd.system-credentials(7).
ImportCredential= takes a credential name and searches for a matching
credential in all the credential stores we know about it. It supports
globs which are expanded so that all matching credentials are loaded.
The general idea is that users should be able to figure out if some option
that they see in a config file or on some internet page is something that
systemd knows about. Once users know that, yes, this was an option but has
been deprecated and removed from the documentation, it's much easier for them
to find any docs in old versions if they want to. Or to switch to something
different.
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
Let's merge the footnote with the overall explanation of where systemd
parses its options from and reword the section a bit to hopefully make
things a bit more clear.
Before this patch, there was no way to request all running user instances for
reexecuting. However this can be useful especially during package updates
otherwise user instances are never updated and keep running a potentially very
old version of the binaries.
Now assuming that we have enough priviledge, it's possible to request
reexecution of all user instances:
systemctl kill --signal=SIGRTMIN+25 "user@*.service"
Note that this request is obviously asynchronous as it relies on a
signal. Keeping "systemctl kill" as the only interface should be good enough to
make this obvious and that's the reason why another interface, such as
"systemctl --global daemon-reexec" has not been considered.
PID1 already uses SIGTERM for reexecuting hence sending it SIGRTMIN+25 is a
nop.
* Fixed typo
Before, the file claimed that some systemd units are created "from other
configuration". It should have read "from other configuration files".
Co-authored-by: Nozz <nozolo90@gmail.com>
Some extra safety when invoked via "sudo". With this we address a
genuine design flaw of sudo, and we shouldn't need to deal with this.
But it's still a good idea to disable this surface given how exotic it
is.
Prompted by #5666
I'm not sure if the LogTarget property is sufficiently general to be made into
a property that can be generally implemented. It is very closely tied to the internal
systemd logic. The other two seem fine thoough.
