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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Kernel 5.8 gained a hidepid= implementation that is truly per procfs,
which allows us to mount a distinct once into every unit, with
individual hidepid= settings. Let's expose this via two new settings:
ProtectProc= (wrapping hidpid=) and ProcSubset= (wrapping subset=).
Replaces: #11670
This specification is useful independently of UEFI, so avoid making assertions
about UEFI. Also reword the intro to say what this is about in the very first
sentence. Closes#16570.
Defaulting to fedora makes it a pain to override mkosi.default
point to one of the other mkosi settings files. Instead, have
every developer manually add the symlink to his distro
of choice and don't commit the symlink to the repository by
putting it in the .gitignore.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
sssd people don't like enumeration and for some other cases it's not
nice to support either, in particular when synthesizing records for
container/userns UID/GID ranges.
Hence, let's make enumeration optional.
We'd like to use it for FIDO2 tokens too, and the concept is entirely
generic, hence let's just reuse the field, but rename it. Read the old
name for compatibility, and treat the old name and the new name as
identical for most purposes.
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
In order to allow applications to detect the host OS version or other
metadata, ask container managers to expose the os-release files as
read-only bind mounts.
For systemd-nspawn, we will also expose ID, BUILD_ID, VERSION_ID and
VARIANT_ID as lowercase environment variables prefixed by the
container_host_ string.
One problem found with the current draft specification is we can't have
an application provide a non-transient systemd service file in a way
that is spec compliant as the service name currently needs to end in a
random token defined by the launcher.
This came up when trying to put DBus activated services into the correct
cgroup. There isn't enough metadata in the DBus service file to know the
correct application ID, and the most intuitive fix is for those
applications to just specify the SystemdService file in the existing
system. They're generally unique for a given user session anyway so
don't need a separate cgroup identifier.
This changes the spec for RANDOM to be optional for services.
It also changes the separator between in services to act like templates.
Ultimately that's what we're trying to recreate with the RANDOM token of
the systemd service and it's a better fit. It's needed as otherwise with
launcher and the random ident being both optional it would be impossible
to get the application ID reliably.
Scopes are unchanged as they don't support templates.
The old version of this command will delete everything under the new home directory (including `.identity`), rendering the directory unusable with homed.
We need both a slice name and a prefix for application units. For
consistency we tried to use the same name and ended up standardising on
"apps.slice" and and "apps-" prefix for the units.
However, "app-" would be a more natural prefix for applications. And it
is no problem to simply also name the slice "app.slice" for consistency
rather than keeping the current "apps.slice".
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
This is work in progress and not finished yet. However, I hope to have
captured some of the key points that came up in previous discussions
with appropriate notes about things that still need to be defined.
I may revisit it later. Also, feel free to completely rewrite if the
format is not quite right.
I assume it’s supposed to be “see Home Directories for details” and not
“… and embeds these JSON records directly in the home directory images …
for details”, but the previous text suggested the latter reading to me.
