So far we didn't provide any concept to enumerate local Varlink
services. Let's change that.
Let's define very light-weight scheme for this: provide a well-known dir
/run/varlink/registry/ where services that implement public interfaces
can link their sockets into. When enumerating services it's thus
sufficient to enumerate inodes in that directory.
The usecase for this is twofold:
1. It's simply very useful to be able to see which public services are
bound on the local system, for debugging/admin/development purposes.
2. At Amutable we'd like to optionally provide a HTTP-to-Varlink bridge
on individual nodes, that allows remote peers (after authentication)
to access local Varlink services. For that it's essential we know the
list of services and their entrypoints to expose, it would be
security-wise highly problematic for clients to provide AF_UNIX
entrypoint paths when connecting. hence: let's instead just have a
dir with the public stuff, and let's ensure the HTTP-to-Varlink
bridge simply exposes that stuff, and nothing else.
Non-public interfaces (such as the oomd interfaces between PID 1 and
oomd), and interfaces with multiple implementors (such as the resolved
hook interface, or the metrics collection stuff) should not be linked
in.
This is inspired by the Varlink.org "registry" concept, briefly
explained here:
https://varlink.org/FAQ#how-do-i-find-the-service-which-implements-a-local-interface
Note however that the described Varlink interface is not actually
implemented here, the directory is introduced however in a fashion that
conceptually matches the registry defined there, and would allow us to
implement the registry interface on top of it. (One of the reason the
registry Varlink API is not implemented right now is that the URI format
it relies on is entirely unspecified in the Varlink docs right now. Some
research needs to be done to extract what's implemented in the reference
implementation and to determine how it maps to the Varlink entrypoint
address format systemd's own tooling currently uses)
This primarily installs the symlinks via Symlinks= in unit files and via
a new tmpfiles.d/ drop-in. But since we touch all .socket units relating
to Varlink this also sets the FileDescriptorName= to varlink for each,
just to minimize diffrences and make things work more alike (the
services in questin don't care about the name, so this doesn't change).
In one case we replace a pair of separate sockets for two closely
related varlink services by a socket and a symlink, so that we can
safely use Symlinks= to also install the registry symlinks.
agetty from util-linux is meanwhile following the configuration file
specification for /etc/issue. The usage of "--issue-file" breaks this
on distributions with current util-linux.
This partially reverts commit e58ba80a40. Those
aliases were removed as part of the removal of sysvinit compat, but the removal
was immediately reported as a regression by users. In particular, users can
have one of those set as the default target, or use those names in Wants= or
Requires= dependencies. At least in Fedora, the removal was immediately
reverted.
When looking at our "portability and stability promise", I noticed that those
units are explicitly listed in the promise. Let's restore them upstream. They
are conditionalized under a new -Dcompat-sysv-interfaces=bool option, so that
downstreams like Arch that wasnt to strictly avoid legacy interfaces can easily
disable them. They are dropped from the docs, like we do for all deprecated
interfaces.
In Fedora, kmsconvt@.service is starting to be used instead of getty@.service
to have nicer font handling. This means that we need the autovt@.service alias
point to the new unit. So far the alias was done through a static symlink
because there was little reason to change it. Let's use [Install] instead so
the decision which implementation to use can be made after installation.
https://bugzilla.redhat.com/show_bug.cgi?id=2429626https://fedoraproject.org/wiki/Changes/UseKmsconVTConsole
This does not yet support directory images properly
as systemd itself does not support unpriv directory
images properly yet.
The user profiles are a copy of the system profiles but without
DynamicUser=yes (can't be used by user managers) and without
ProtectHome=yes (this masks /home which breaks StateDirectory= which
is lcoated inside /home)
NvPCR need to read from /var/lib/nvpcr and the current unit file is
executed before /var is mounted. This adds the dep back so its always
runs after /var is mounted like systemd-tpm2-setup.service
They are separate and independent settings, so adjust meson rules
and unit files accordingly. It is possible to enable support for
rc-local script without support for sysvinit scripts, and viceversa.
This will become useful later when sysvinit scripts support is
removed.
If a crash occurs during an offline update, we do not get a
coredump, because systemd-coredump is not enabled. This of course
complicates debugging.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Let's make our networkd sockets recognizable purely by name. It hink
already for debugging it's a good idea to always set socket names, in
particular for services that have multiple sockets they listen on.
This adds a name to the rtnl socket, which so far missed one. Note that
the C code won't look for it, for compat with older versions, but at
least things are a bit more debuggable.
Let's synthesize DNS RRs for leases handed out by our DHCP server. This
way local VMs can have resolvable hostnames locally.
This does not implement reverse look ups for now. We can add this
later in similar fashion.
We do this in a separate service (rather than inside of
systemd-tpm2-setup), since we want failures of this measurement to
result in an instant reboot, like for most our measurements.
Failures to initialize nvpcrs, or allocate an SRK are somewhat OK (and
more likely), as long as this separator communicates clearly where they
have to have taken place, if they worked.
This has irked me for a while. For me network configuration is the stuff
we store on disk in configuration file. And networkd then *applies* the
configuration. But the units so far claimed that networkd was the
"configuration" itself. Which I guess might make sense to some, but to
me sounds a bit unprecise. Let's clean this up, and call what networkd
is doing "Network Management".
Most of those were dropped in 7d247d3cb8. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
The keymap only really matters if there's local access to a system, i.e.
if there's actually a physical kbd directly connected to it, to apply it
to. If during firstboot we are not talked to via a VT (but via SSH,
container, or hypervisor console or so instead), then it's very unlikely
we ever are. Hence, don't ask for a keymap, and let#s shortcut the
questions asked at boot.
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
Since mountfsd was added in 702a52f4b5 the
caps bounding set line was commented. That's an accident. Fix that. (We
need to add a bunch of caps to the list).
This adds TTYReset=yes to all units which run directly on the TTY. We
already had this in place for the gettys, but this adds it for the rest
that basically has StandardInput=tty + StandardOutput=tty set.
Originally, for these tools it wasn't necessary to reset the TTY,
because we after all already reset /dev/console very very early on once,
during PID1's early initialization, and hence there's no real reason to
do it again for these early boot services. But that's actually not
right, because since #36666 the TTY we reset from PID 1 is typically
/dev/console but the TTY those services are invoked on is typically the
resolved version of that, i.e. wherever that points. Now you might
think: if one is just an alias to the other, why does it matter to reset
this again? Well, because it's only a half-assed alias, and as it turns
out WIOCSWINSZ is not propagated from one to the other, i.e the terminal
dimesions we initialize for /dev/console don't propagate to whatever
that points to.
One option to address that would be to immediately propagate this down
ourselves (or to fix the kernel for it), but it felt safer to simply do
the reset again before the use, after all these one one-off services,
and there's no point in optimizing much here. Moreover, its probably
safer to give the guarantee that when the firstboot stuff (which after
all queries for pws to set) runs it definitely certainly guaranteed has
a properly reset terminal.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
systemd-coredump sandbox already has ProtectSystem=strict hence all non
API filesystems are made read-only, thus RestrictSUIDSGID= doesn't buy
us much.
On top of that systemd-coredump's EnterNamespace= feature requires
openat2() to work correctly and that is implicitly blocked by
RestrictSUIDSGID=.
Follow-up for 8f8148cb08
This combines nicely with the X_SYSTEMD_UNIT_INACTIVE= notification
we send out, to ensure when all sshd units go down the actual
status is always reflected on the target.