IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
--empower gives full privileges to a non-root user. Currently this
includes all capabilities but we leave the option open to add more
privileges via this option in the future.
Why is this useful? When running privileged development or debugging
commands from your home directory (think bpftrace, strace and such),
you want any files written by these tools to be owned by your current
user, and not by the root user. run0 --empower will allow you to run
all privileged operations (assuming the tools check for capabilities
and not UIDs), while any files written by the tools will still be owned
by the current user.
--no-hostname is one of the switches I use very often. In particular,
when looking at CI logs, the hostname is almost never interesting.
-H is not yet used in journalctl, because journal operates locally, but
will want it if display of remote journals is implemented. Use -W.
Both kernel-core and kernel-uki-virt call kernel-install upon removal. Need an additional argument to avoid complete removal for both traditional kernel and UKI.
Signed-off-by: Li Tian <litian@redhat.com>
The zsh completions only complete one type argument, even though multiple
args are allowed. But the same issue occurs with other completions, e.g.
for options. I don't know how to solve this.
[1] says:
> Since 0.60.0 the name argument is optional and defaults to the basename of
> the first output
We specify >= 0.62 as the supported version, so drop the duplicate name in all cases
where it is the same as outputs[0], i.e. almost all cases.
[1] https://mesonbuild.com/Reference-manual_functions.html#custom_target
This is useful when the previous invocation is unexpectedly killed.
Otherwise, if systemd-nspawn is killed forcibly, then unix-export
directory is not cleared and unmounted, and the subsequent invocation
will fail. E.g.
===
[ 18.895515] TEST-13-NSPAWN.sh[645]: + machinectl start long-running
[ 18.945703] systemd-nspawn[1387]: Mount point '/run/systemd/nspawn/unix-export/long-running' exists already, refusing.
[ 18.949236] systemd[1]: systemd-nspawn@long-running.service: Failed with result 'exit-code'.
[ 18.949743] systemd[1]: Failed to start systemd-nspawn@long-running.service.
===
Currently homed scans /home/ via inotify for new .home + .homedir/
popping up to register as local users. Let's also add an explicit way to
request this form of "adoption": a bus call that takes a path and that
makes a home dir activatable locally.
(Usecase: you cross boot between two systems – let's say your traditional
fedora and your ParticleOS – and want to use the same homedir from both:
simply mount the /home dir from the other somewhere, and then hit
"homectl adopt /somewhere/lennart.home" and you have the user locally
too).
This adds --json=MODE option for 'udevadm test' command.
When specified, all messages, except for the final result, will be
written to stderr, and the final result is shown in JSON format to
stdout. It may be useful for parsing the test result.
When '--resolve-names=late', systemd-udevd resolves user/group names
during each event being processed, and does not verify names on parse.
When '--resolve-names=never', systemd-udevd refuses any user/group names
on parse. Hence, the parser of udev rules behaves diffrently. Let's not
convert 'never' -> 'late' silently, and use the specified option as is.
This also updates man page and shell completion for --resolve-names
option.
So far, we supported two modes:
1. when running unpriv we'd get the mounts from mountfsd, and the userns
from nsresourced
2. when running priv we'd do the mounts/userns ourselves
This untangles this a bit, so that we can also use mountfsd/nsresourced
when running privilged.
I think this is generally a bit nicer, and probably something we should
switch to entirely one day, as it reduces the variety of codepaths.
With this patch the default behaviour remains unchanged, but by
selecting the new "managed" option for --private-users= the codepaths
via mountfsd/nsresourced can be explicitly requested even when running
with privs.
This is mostly just reworks that we check for arg_userns_mode !=
USER_NAMESPACE_MANAGED rather than arg_privileged for a number of
codepaths, but requires more fixes, too. The devil is in the details.
