Introduces new extended variants of the various incarnations of
Create and Update, which take a map of filenames to FDs. This map is
then used to populate the bulk directory.
FDs are used to prevent the client from abusing homed's blob directory
permissions (everything is made world-readable by homed) to open files
that they normally aren't allowed to open. Passing along an FD ensures
that the client has read access to the file it wants homed to make
world-readable.
Internally, homework uses the map to overwrite the system blob dir.
Later, homework's existing blob dir reconciliation logic will propagate
the new contents from the system blob dir into the embedded blob
dir
This ensures that a user-specific blob directory exists in
/var/cache/systemd/homed for as long as the user exists, and gets
deleted if the user gets deleted.
It also advertises this blob directory via the user record, so that
clients can find and use it.
Allows to configure bond arp_missed_max is the maximum number of arp_interval monitor cycle
for missed ARP replies. If this number is exceeded, link is reported as
down.
In case the D-Bus policy is not set up correctly the example just
loops forever. Check the return of sd_bus_request_name_async() in
a callback and exit if the error is not temporary.
Follow-up for 34bbda18a5
This commit adds a new way of forwarding journal messages - forwarding
over a socket.
The socket can be any of AF_INET, AF_INET6, AF_UNIUX or AF_VSOCK.
The address to connect to is retrieved from the "journald.forward_address" credential.
It can also be specified in systemd-journald's unit file with ForwardAddress=
owneridmap bind option will map the target directory owner from inside the
container to the owner of the directory bound from the host filesystem.
This will ensure files and directories created in the container will be owned
by the directory owner of the host filesystem. All other users will remain
unmapped. Files to be written as other users in the container will not be
allowed.
Resolves: #27037
This field is like preferredLanguage, but takes a priority list of
languages instead. If an app isn't translated into a user's primary
language, it can fall back to one of the other languages in the list
thus making the app more accessible to the user.
For instance: in my experience, many Ukrainians are fluent in Russian,
often significantly better than English (especially if they are of a
generation that grew up during the USSR). Such a person might set this
new variable to ["uk_UA.UTF-8", "ru_UA.UTF-8"] so that software that
lacks Ukrainian translations will first try Russian translations before
defaulting to English.
Fixes#31290
cryptsetup 2.7.0 adds feature to link effective volume key in custom
kernel keyring during device activation. It can be used later to pass
linked volume key to other services.
For example: kdump enabled systems installed on LUKS2 device.
This feature allows it to store volume key linked in a kernel keyring
to the kdump reserved memory and reuse it to reactivate LUKS2 device
in case of kernel crash.
OOMPolicy in scope units is separately supported in
version v253, so I think it cannot be directly used
in the manpage with the version from the service.
fix:#30836
The idea is simple: skip the final operation that creates or removes things
or changes the attributes, but otherwise go through the rest of the code.
This results in quite a lot of fairly repetitive conditions in the low-level
code. Another approach would be to print earlier, at a higher level, but then
we'd have less precise information about what is about to happen.
It exposes the varlink_collect() call we internally provide: it collects
all responses of a method call that is issued with the "more" method
call flag. It then returns the result as a single JSON array.
The setting currently puts limits on connections per IP address and
AF_UNIX CID. Let's extend it to cover AF_UNIX too, where it puts a limit
on connections per UID.
This is particularly useful for the various Accept=yes Varlink services
we now have, as it means, the number of per-user instance services
cannot grow without bounds.
Looking for the ESP node is useful to shortcut things but if we're told that
the node is not referenced in fstab that doesn't necessarily mean that ESP is
not mounted via fstab. Indeed the check is not reliable in all cases. Firstly
because it assumes that udev already set the symlinks up. This is not the case
for initrd-less boots. Secondly the devname of the ESP partition can be wrongly
constructed by the dissect code. For example, the approach which consists in
appending "p<partnum>" suffix to construct the partition devname from the disk
devname doesn't work for DM devices.
Hence this patch makes the logic more defensive and do not mount neither ESP
nor XBOOTLDR automatically if any path in paths that starts with /efi or /boot
exists.
I think this was just overlooked in #13754, which removed
the restriction of Restart= on Type=oneshot services.
There's no reason to prevent RestartForceExitStatus=
now that Restart= has been allowed.
Closes#31148
These can be used along with two new settings MountPoint= and
EncryptedVolume= to write fstab and crypttab entries to the given
paths respectively in the root directory that repart is operating on.
This is useful to cover scenarios that aren't covered by the
Discoverable Partitions Spec. For example when one wants to mount
/home as a separate btrfs subvolume. Because multiple btrfs subvolumes
can be mounted from the same partition, we allow specifying MountPoint=
multiple times to add multiple entries for the same partition.
... i.e. apply nested config (exclusions and such) when executing R and D.
This fixes a long-standing RFE. The existing logic seems to have been an
accident of implementation. After all, if somebody specifies a config with
'R /foo; x /tmp/bar', then probably the goal is to remove stuff from under /foo,
but keep /tmp/bar. If they just wanted to nuke everything, then would not specify
the second item.
This also makes R and D use O_NOATIME, i.e. the access times of the directories
that are accessed will not be changed by the cleanup.
Obviously, we'll have to add this to NEWS and such.
Looking at the whole tmpfiles.d config in Fedora, this change has no effect.
The test cases are adjusted as appropriate. I also added another test case for
'R'/'D' with a file, just to test this code path more.
Replaces #20641.
Fixes#1633.
One of the three must always be specified, but they buried in a long list of
options in the output of --help. Make them more visible to draw the eye.
Also, drop "marked" from the description. It's supposed to mean "configured",
but it's a strange way to say that, and also it's generally obvious that the
program does what its configuration tells it to, and it's not going to remove
all files found on the system.
Previously, if given an absolute path, we would open the file, but when given a
relative path, we'd attempt to search the directories. If the user wants to open
a file from the search path, allowing paths is very confusing. E.g. with a path
like 'sysusers/foo.conf', we'd try to open '/etc/sysusers.d/sysusers/foo.conf',
'/run/sysusers.d/sysusers/foo.conf', …, and with '../foo.conf', we'd try to open
'/etc/sysusers.d/../foo.conf', '/run/sysusers.d/../foo.conf', …. This just isn't
useful, and in fact for a scheme like sysusers.d and tmpfiles.d where there we
have a flat directory with config files, only searching for plain names can
result in success. When a user specifies a relative path, it's more likely that
they wanted to open some local file. OTOH, to correctly open a local file, e.g.
one that they're just writing, this interface is also awkward, because something
like '$PWD/file.conf' has to be used to open a file with a relative path.
This patch changes the interface so that any path (i.e. an argument with "/") is
used to open a file directly, and only plain basenames are used for searching.
(Note that tpmfiles and sysusers are somewhat special here: their "config files"
make sense without the other config and users are likely to want to test them
without the other config. I was trying to do just that when writing a spec file
for a package and attempting to convert the existing scripts to sysusers and
tmpfiles. The same logic wouldn't apply for example to units or udev rules,
because they generally can only be interpreted with the whole rest of config
also available.)
The provider API which is new requires providers, which are not
widely available and don't work very well yet, so also use a
fallback with the legacy engine API.
Let's allow configuring the debug tty independently of enabling/disabling
the debug shell. This allows mkosi to configure the correct tty while
leaving enabling/disabling the debug tty to the user.
