Cockpit's podman plugin needs to know the lingering status so the UI can
advertise enabling `podman-restart` (which depends on lingering to
work). Currently it relies on watching `/var/lib/systemd/linger/${user}`
but that isn't a public API.
Related: #22244
While we can safely assume that `/proc/sys/kernel/random/boot_id`
exists, the same can't be said for `/etc/machine-id` in environments
where systemd is installed, but not running. An example would be OCI
containers like with the official Arch Linux image, see [0].
Without this check the prompt would constantly output `/etc/machine-id:
no such file or directory` with the OSC events introduced in dadbb34
(v258).
[0] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/issues/107
First, let's say "must" rather than "shall" regarding creation of these
files, because without them group memberships will not work.
Secondly, suggest placing an empty JSON object in them, rather than
making them empty, simply to avoid issues with older systems that didn't
backport d6570eafe3.
Fixes: #38943
Followon to #37024.
This implements (mostly) what was suggested there, except that only a
single UUID is accepted (modifying things to support multiple is a
relatively straightforward change from here)
I'm not really convinced this is the right approach:
* I can't really think of any cases where you'd need to query by
multiple UUIDs (I guess you might want to lookup multiple users, but in
that case why aren't there "usernames" or "uids" arrays?)
* If I specify username "foo" and UID 1234 and UID 1234 exists and has
username "bar", I get back the error `ConflictingRecordFound`
* If I specify username "foo" and UUID abcdef... and username "foo"
exists but has UUID 123456..., I get back the error
`NonMatchingRecordFound`
This makes the two ID types behave differently.
Additionally, when querying by `uuid`, the multiplexer will always sends
`more: true`, which is fine but a little unexpected.
I do think unifying things through the `UserDBMatch` struct could make
sense, but in that case I think it would make sense to unify all query
types in that way (username, uid, uuid), identify when the filter is for
a single or multiple records, and centralise determination of conflict
vs non matching record errors.
`userdb_by_name`/`userdb_by_uid` could then become helper functions for
the simple case where no additional filtering is needed.
Thoughts?
One other thought: Should the multiplexer just pass through all
parameters, even unknown ones, to the backend services? Even if it
doesn't know how to filter by every property, the backends might, and it
would be useful to allow them to optimise things. (I realise the
disadvantage of this, ofc, is loss of error checking)
The ability to encrypt/authenticate encryption with a null key was
originally just a fallback concept for cases where during early boot we
have no host key, but the local system has no TPM2. Nowadays it is used
for other stuff as well, such as pcrlock data propagation (i.e. data
that needs no protection itself and required to properly to TPM key
derivation).
Let's give better, explicit control over null key usage, i.e. let's make
it a tristate both on the systemd-creds command line and in the Varlink
IPC to control three cases:
- the default that we allow it only if SecureBoot is off
- explicitly allowed
- explicitly refused (this is new)
Ideally systemd-creds --allow-null switch would take a boolean argument
to control this as a tristate. Alas, that would be a compat break, hence
I added --refuse-null instead (which also maps to the low-level flag for
this).
This also normalizes that the null key is always called "null key" in
messages, and not sometimes "empty key" or "fallback key".
This makes systemd-sysctl support following syntax, like
systemd-sysusers and systemd-tmpfiles:
```sh
$ /usr/lib/systemd/systemd-sysctl --inline 'foo.bar=42'
$ /usr/lib/systemd/systemd-sysctl - <<EOF
foo.bar=42
EOF
```
```
$ build/systemd-mute-console -q
Code should not be reached at src/mute-console/mute-console.c:103, function parse_argv(). Aborting. 💥
Aborted (core dumped)
```
At least when doing a local review, asking it to be thorough results
in a lot more comments on coding style violation so let's add such an
instruction to the global instructions.
This was generated using copilot itself with Claude Sonnet 4.5 as
the backing model.
The idea is to test this out on some PRs to see whether copilot can
provide useful PR reviews. The idea is that it'll be able to take care
of the low hanging fruit like coding style issues and such. Once we get
some feedback on how it performs, we can make more changes to this document
to get it to behave better (assuming we decide to keep using it at all).
* e50fce1d4b Fix installation of new manpages
* 8b45d3d793 Install new files for upstream build
* a401468f75 autopkgest: install bsdutils and bsdextrautils for unit tests
* 587584577e Explicitly disable bpf-framework for stage1 builds
* 209a8475d9 systemd: recommend login package
