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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This commit adds a new Verity= setting to repart definition files
with two possible values: "data" and "hash".
If Verity= is set to "data", repart works as before, and populates
the partition with the content from CopyBlocks= or CopyFiles=.
If Verity= is set to "hash", repart will try to find a matching
data partition with Verity=data and equal values for CopyBlocks=
or CopyFiles=, Format= and MakeDirectories=. If a matching data
partition is found, repart will generate verity hashes for that
data partition in the verity partition. The UUID of the data
partition is set to the first 128 bits of the verity root hash. The
UUID of the hashes partition is set to the final 128 bits of the
verity root hash.
Fixes#24559
rootidmap bind option will map the root user from the container to the
owner of the mounted directory on the filesystem. This will ensure files
and directories created by the root user in the container will be owned
by the directory owner on the filesystem. All other user will remain
unmapped.
So this is a bit of a bikeshedding thing. But I think we should do this
nonetheless, before this is released.
Playing around with the glob matches I realized that "=$" is really hard
to grep for, since in shell code it's an often seen construct. Also,
when reading code I often found myself thinking first that the "$"
belongs to the rvalue instead of the operator, in a variable expansion
scheme.
If we move the $ character to the left hand, I think we are on the safer
side, since usually lvalues are much more restricted in character sets
than rvalues (at least most programming languages do enforce limits on
the character set for identifiers).
It makes it much easier to grep for the new operator, and easier to read
too. Example:
before:
ConditionOSRelease=ID=$fedora-*
after:
ConditionOSRelease=ID$=fedora-*
The only reason to do this is to ensure uniformity with the other
options, that work like this, i.e. ConditionOSRelease= or
ConditionSecurity=.
This is a compatibility break, but a minor one, given that string
comparison and version comparison is mostly the same for equality and
inequality.
These two operators always indicate ordering comparisons, as opposed to
"=" and "!=" which depending on context mean literal string compares.
This is useful for ConditionOSRelease= for example, as this means
there's now always a way to do version compares.
Often I end up debugging a problem on a system, and I
do e.g. `journalctl --grep=failed|error`. The use of the term
"failed" for condition checks adds a *lot* of unnecessary noise into
this.
Now, I know this regexp search isn't precise, but it has proven
to be useful to me.
I think "failed" is too strong of a term as a baseline, and also
just stands out to e.g. humans watching their servers boot or
whatever.
The term "met condition" is fairly widely used, e.g.
https://stackoverflow.com/questions/63751794/what-does-the-condition-is-met-exactly-mean-in-programming-languages
Use that instead.
New directive `NetLabel=` provides a method for integrating static and dynamic
network configuration into Linux NetLabel subsystem rules, used by Linux
Security Modules (LSMs) for network access control. The label, with suitable
LSM rules, can be used to control connectivity of (for example) a service with
peers in the local network. At least with SELinux, only the ingress can be
controlled but not egress. The benefit of using this setting is that it may be
possible to apply interface independent part of NetLabel configuration at very
early stage of system boot sequence, at the time when the network interfaces
are not available yet, with netlabelctl(8), and the per-interface configuration
with systemd-networkd once the interfaces appear later. Currently this feature
is only implemented for SELinux.
The option expects a single NetLabel label. The label must conform to lexical
restrictions of LSM labels. When an interface is configured with IP addresses,
the addresses and subnetwork masks will be appended to the NetLabel Fallback
Peer Labeling rules. They will be removed when the interface is
deconfigured. Failures to manage the labels will be ignored.
Example:
```
[DHCPv4]
NetLabel=system_u:object_r:localnet_peer_t:s0
```
With the above rules for interface `eth0`, when the interface is configured with
an IPv4 address of 10.0.0.123/8, `systemd-networkd` performs the equivalent of
`netlabelctl` operation
```
$ sudo netlabelctl unlbl add interface eth0 address:10.0.0.0/8 label:system_u:object_r:localnet_peer_t:s0
```
Result:
```
$ sudo netlabelctl -p unlbl list
...
interface: eth0
address: 10.0.0.0/8
label: "system_u:object_r:localnet_peer_t:s0"
...
```
getopt allows non-ambiguous abbreviations, so backwards-compat is maintained, and
people can use --kill-who (or even shorter abbreviations). English is flexible,
so in common speach people would use both forms, even if "whom" is technically
more correct. The advantage of using the longer form in the code is that we
effectively allow both forms, so we stop punishing people who DTGCT¹, but still
allow people to use the spoken form if they prefer.
1. Do the gramatically correct thing
Previously the field "_SYSTEM_CONTEXT" knew he values "initrd" + "main". Let's change
this to "_RUNTIME_SCOPE" and "initrd" + "system".
Why? The sysext logic has a very similar concept of "scopes", declaring
whether a sysext image is intended for the initrd or the main system.
Let's thus use the same naming for both.
sysext's extension-release files hence know SYSEXT_SCOPE=initrd|system,
and the journal messages know _RUNTIME_SCOPE=initrd|system, which makes
this reasonably systematic.
Follow-up for: cae8edd93c
(This is not an API break, since no version with this commit has ever
been released.)
/bin/sh as a shell is punishing. There is no good reason to make
the occasional root login unpleasant.
Since /bin/sh is usually /bin/bash in compat mode, i.e. if one is
available, the other will be too, /bin/bash is almost as good as a default.
But to avoid a regression in the situation where /bin/bash (or
DEFAULT_USER_SHELL) is not installed, we check with access() and fall back
to /bin/sh. This should make this change in behaviour less risky.
(FWIW, e.g. Fedora/RHEL use /bin/bash as default for root.)
This is a follow-up of sorts for 53350c7bba,
which added the default-user-shell option, but most likely with the idea
of using /bin/bash less ;)
Fixes#24369.
The ":=" operator was only added in Python 3.8 so splitting the line with it into two makes check-os-release.py actually fulfill its claim of working with any python version.
When a service is triggered by a path unit, pass the
path unit name and the path that triggered it via env vars
to the spawned processes.
Note that this is best-effort, as there might be many triggers
at the same time, but we only get woken up by one.
Not wired in by any unit type yet, just the basic to allocate,
ref, deref and plug in to other unit types.
Includes recording the trigger unit name and passing it to the
triggered unit as TRIGGER_UNIT= env var.
The general idea is that users should be able to figure out if some option
that they see in a config file or on some internet page is something that
systemd knows about. Once users know that, yes, this was an option but has
been deprecated and removed from the documentation, it's much easier for them
to find any docs in old versions if they want to. Or to switch to something
different.
This allows allows shortcutting measurements of the specified files and
use the information from /sys/ instead.
This is not too useful on its own given that "systemd-measure status"
already exists which displays the current, relevant PCR values. The main
difference is how "complete" the information is. "status" will detect if
the measurements make any sense, and show more than PCR 11. "calculate
--current" otoh only reads PCR 11 and uses that, and that's really it.
This is mainly preparation for later work to add PCR signing to the
tool, where usually it makes most sense to sign prepared kernel images,
but for testing it's really useful to shortcut signing to the current
PCR values instead
entry.
By default an entry named "Linux Boot Manager" is created (which is the
previous behavior). With the flag the name of the entry can be
controlled, which is useful when installing systemd-boot to multiple ESP
partitions and having uniquely named entries.
Fixes#17044.
