and use dedicated knobs for every option used in
former SimpleConnectProperties.
New section is [MobileNetwork] with the following configuration options:
APN=
AllowedAuthenticationMechanisms==
User=
Password=
IPFamily=
AllowRoaming=
PIN=
OperatorId=
Closes#40877. As requested, --extra-drive=path[:format] is changed
to --extra-drive=[format:]path, so that the parsing is less ambiguous.
(In the original request, it was requested that the empty format can be
used also, but that was dropped in the second version of the patch.)
Closes#40883. As described in the issue, it's not "jobs" that are
marked, and also the name is unnecessarilly long.
I think we don't need any compatibility measures here. At least in the
rpm world, package upgrade scripts go through the helper which is part
of the package so the new systemctl and the new helper are upgraded
together.
I found the existing explanation of RestartSteps to be simply
impenetrable. Even providing the full docs context to several of our new
AI overlords resulted in wildly different (and completely incorrect)
explanations of the final restart intervals.
Digging through the code, I found the restart delay computation in
`service_restart_usec_next` in `src/core/service.c`.
I've updated the documentation for RestartSteps with an example,
suggested value range and a detailed enough explanation that accurately
describes the current behavior.
The json files were originally generated for Ubuntu stubble and are kown
to work since they ship in all Ubuntu arm64 ISOs by default.
Some of the devices might not be supported in mainline Linux yet and use
preliminary compatible strings.
If the option is not manually specified, and the hwids directory exists
for the target EFI architecture, default to it. Allow passing '' to skip.
Fixes https://github.com/systemd/systemd/issues/40542
As in the previous commit, checking for both requirements and ordering seems
unnecessary. In practical cases, the mount will be pulled in by the rest
of the transaction, so ordering is the part that matters. (The setup is
racy without the ordering.) If we drop the second check, the admin can
just use After=tmp.mount to achieve the desired behaviour, without needing
to explicitly pull in the unit. This is easier to configure and more robust.
This changes the implementation introduced in
6156bec7a4.
Also actually describe the implemented behaviour in the man page.
In https://github.com/systemd/systemd/issues/28515, multiple people report that
services that have PrivateTmp=yes and DefaultDependencies=no fail to create the
temporary directories under /tmp, when /tmp is e.g. a bind mount or some other
kind of mount that takes more time.
Before PrivateTmp=disconnected was added, we didn't have a nice solution:
DefaultDependencies=no is used to start services very early, so we wouldn't
want to add a dependency on /tmp automatically. With PrivateTmp=disconnected we
have a fairly nice solution. Let's "upgrade" to this mode automatically.
Strictly speaking, it is a small compat break, but in practice it's unlikely to
matter for early-boot services whether their /tmp is private or disconnected.
The dependency on /tmp that is checked is After. I think this is enough,
since any tmp.mount would be pulled in by local-fs.target and the rest of
the transaction anyway, so we don't need to check more than After.
The asserts are relaxed, because now the two settings can now diverge
in either way.
Resolves https://github.com/systemd/systemd/issues/28515.
[yhndnzj: fix unit_add_exec_dependencies() to handle the new
combination; add a comment in exec_needs_sys_admin()]
We expose this via --private-users-delegate= which takes the number of
ranges to delegate. On top of delegating the ranges, we also mount in
the nsresourced socket and the mountfsd socket so that nested containers
can use nsresourced to allocate from the delegated ranges and mountfsd to
mount images.
Finally, we also create /run/systemd/dissect-root with systemd-tmpfiles to
make sure it is always available as unpriv users won't be able to create it
themselves.
Whenever delegating UID ranges to a user namespace, it can also be
useful to map the foreign UID range, so that the container running in
the user namespace with delegated UID ranges can download container
images and unpack them to the foreign UID range.
Let's add an option mapForeign to make this possible. Note that this option
gives unprivileged users full access to the any foreign UID range owned directory
that they can access. Hence it is recommended (and already was recommended) to
store foreign UID range owned directories in a 0700 directory owned by the
owner of the tree to avoid access and modifications by other users.
This is already the case for the main users of the foreign UID range,
namely /var/lib/machines, /var/lib/portables and /home/<user> which all
use 0700 as their mode.
Users will also be able to create foreign UID range owned inodes in any
directories their own user can write to (on most systems this means /tmp,
/var/tmp and /home/<user>).
mkosi does all of its environment setup in an unprivileged user
namespace with an identity mapping. When it invokes nspawn and nspawn
tries to get a transient userns from nsresourced, this fails as no
transient ranges are mapped into mkosi's unprivileged userns (as doing
so would require privileges).
To fix this problem, let's allow allocating unprivileged self user
namespaces in nsresourced, similar to what the kernel allows, except that
we also support delegations for these. This means that mkosi can get its
unprivileged userns as before from nsresourced, but it can also request a
delegated 64K range inside that userns as well, which nsresourced can then
allocate to nspawn later when it asks for one.
Similar to the kernel, we disallow setgroups for self mappings. However,
instead of doing this via /proc/self/setgroups, which applies to the current
user namespace and all its child user namespaces, we use the BPF LSM to deny
setgroups instead, so that it can still be allowed for child user namespaces.
We need this because as soon as a container launches in a child user namespace
using one of the delegated mappings, it has to be able to do setgroups() to be
able to function properly.
To allow mapping the root user, we need to add the CAP_SETFCAP capability to
nsresourced.
We want to support the scenario where we bind mount the nsresourced
varlink socket into a container to allow nested containers where the
outer container runs in its own transient range from nsresourced but
can still allocate transient ranges for its own nested containers.
To support this use case let's add support for delegation. Delegated
ranges are allocated when allocating the primary range and are propagated
1:1 to the user namespace. We track delegated ranges in ".delegate" files
in the userns registry so that they can't be used for other range allocations.
We make one exception for delegated ranges though, if we get a request from
a user namespace that is a child of the user namespace that owns the delegated
ranges, we allow allocating from the delegated range. The parent userns already
has full ownership over the child userns, so it doesn't matter that the parent
userns and the child userns share the same range. This allows making use of
delegated ranges without having to run another copy of nsresourced inside the
parent userns to hand out from the delegated range.
To support recursive delegations, we keep track of the previous owners of the
delegated range and restore ownership to the last previous owner when the current
owner is freed.
This reverts commit 351b4dd123.
I'm pretty sure we should not create more of these multiplexer
interfaces, which in this specific also leads to a fair bit of
confusion: start/stop/reload-or-restart --marked all enqueue
all job types.
Instead, a dedicated verb will be introduced in later commits.
Currently, there's no way for a desktop environment to detect when a
systemd inhibitor has been added or removed. This means that a desktop
environment that wishes to show current inhibitors to the user will be
either forced to poll systemd or just use stale data.
Now, the desktop can listen for changed events on NCurrentInhibitors and
call GetInhibitors() in response to that.
Desktops cannot currently tell the difference between a power action
being set to challenge permanently (i.e. because the sysadmin wanted to
restrict the given user) and a power action being set to challenge
because it's temporarily inhibited.
Thus, a desktop might take an action that is valid in the first case but
not the second case. For instance: GNOME hides all of its automatic
suspend settings from the UI whenever a sleep inhibitor is active.
This now returns a new state: "inhibited". It communicates to the
desktop that the action is available normally, but at the moment the
desktop isn't allowed to perform the action due to an inhibitor.
Related: https://github.com/systemd/systemd/issues/37311
Now that it’s been replaced by `Acquire()` and `Install()`, there’s no
need to expose it as a separate method. Wrappers around `sysupdated` can
still expose an ‘update’ convenience verb by calling those two methods.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
These mirror the `sysupdate acquire` and `sysupdate update --offline`
verbs, which are themselves a split of `sysupdate update` into
downloading and installing stages.
The existing `sysupdated` `Update()` method is kept for now, for
convenience. It might be dropped in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
xfsprogs 6.17.0 added support for populating xfs filesystems from
directories. As this supports extended attributes unlike our current
hack with protofiles. Let's make use of the new feature in mkfs-util.c
As there's no clean way to do feature detection on the mkfs.xfs binary,
we drop support for the old hack with protofiles that we had before.
Useful for packaging scripts, when units are removed.
When multiple markers are assigned without +/-, the last one wins.
When using +/-, the job merging logic is followed to the extent possible.
Otherwise, `<variable>location</variable>` is rendered:
```
[2365/2925] Generating man/systemd.mstack.7 with a custom command
Element variable in namespace '' encountered in para, but no template matches.
```
I expressed the issue I have with parse_tristate_argument()
in #37751: it doesn't add any value to direct use of parse_tristate();
on the contrary, it doesn't support means to reset the arg to "auto"/-1 state.
The mere reason it existed is that we need a int type ret param.
Since the previous attempt to address this mess failed, let's
try to make the function more useful by making it accept "auto".
I figure this is useful on its own.
As requested in
https://github.com/systemd/systemd/pull/40652#discussion_r2831833996,
the function name is suffixed with _with_auto() to establish
that "auto" is handled internally.
Luca Boccassi
Oleksandr Andrushchenko
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Bouke van der Bijl
Val Markovic
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Adrian Vovk
Daan De Meyer
Mike Yuan
Yu Watanabe
André Paiusco
Philip Withnall
Antonio Alvarez Feijoo