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 will greatly reduce the number of cases where the global unicast
scope overlaps with link scopes configured as default-route, making it
feasible to use the global DNS setting in conjunction with per-link dns
servers configured by the network.
This change is preferred over demoting links to default-route=no where
the user prefers to use the network provided DNS servers, and I expect
it is non-disruptive in that it should not degrade the efficacy of any
existing configuration.
Note, `systemd-analyze foo@.service --instance=hoge` is equivalent to
`systemd-analyze foo@hoge.service`. But, the option may be useful when
e.g. passing multiple template units that have restriction on their
instance name:
```
$ ls
template_aaa@.service template_bbb@.service template_ccc@.service
$ systemd-analyze ./template_* --instance=hoge
```
Without the option, we need to embed an instance name into each unit
name, so cannot use globs.
Prompted by #33681.
After 3976c43092 (#31423), IPMasquerade=
implies only per-interface IP forwarding. That means, nspawn users need
to manually enable IPv4/IPv6Forwarding= in networkd.conf when
--network-veth or friend is used. Even the change was announced in NEWS,
the change itself breaks backward compatibility and extremely reduces
usability.
Let's make the setting imply the global setting again.
Fixes#34010.
The net_id builtin only checked the of_node of a netdev's parent device,
not that of the netdev itself. While it is common that netdevs don't have
an OF node assigned themselves, as they are derived from some parent
device, this is not always the case. In particular when a single
controller provides multiple ports that can be referenced indiviually in
the Device Tree (both for aliases/MAC address assignment and phandle
references), the correct of_node will be that of the netdev itself, not
that of the parent, so it needs to be checked, too.
A new naming scheme flag NAMING_DEVICETREE_PORT_ALIASES is added to
allow selecting the new behavior.
This allows for example forcing to use /sbin/init instead of always
using /usr/lib/systemd/systemd if it exists. Or it allows using a
different path altogether.
The PrepareForShutdownWithMetadata signal was added via
e4aab5cf1a but a corresponding property
was not. A property has to be a single type, so the bool needs to be
one of the key/value pairs as 'ba{sv}' is not a valid property.
+ Scale the x-axis of the resulting plot by a factor (default 1.0)
+ Add activation timestamps to each bar
Signed-off-by: rajmohan r <rajmohan.r@kpit.com>
This fixes
commit 9b0688f491
Author: Yu Watanabe <watanabe.yu+github@gmail.com>
Date: Tue Jan 9 10:52:49 2024 +0900
virt: add Google Compute Engine support
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Arch and Tumbleweed do not do EOLs but are still stable, so clarify the paragraph.
Also break the entry in paragraphs, to make it more readable when rendered.
The point was made on https://lists.debian.org/debian-ctte/2024/08/msg00005.html
that 'pre-release sounds' like an RC candidate, ie, something that will change
very slightly in the released version. But this is not necessarily the case
for example at the beginnig of a Fedora Rawhide or Debian Testing release cycle,
so change it to a more generic 'development'
Follow-up for 7102dc52e6
This is for experimental builds of the OS made to test some specific WIP
feature.
For example, let's say the distro in question is Asahi Linux and Apple
just released the M3 SoC. The Asahi developers will start porting to the
M3, and will quickly generate builds of Asahi Linux that can technically
boot but aren't ready for any kind of daily use. These images are marked
as experimental, and can be shared among the developers. If a user
somehow stumbles upon one of these images and tries to install it,
they'll be warned that they're about to install an experimental Apple M3
port of Asahi Linux. Eventually, once the Asahi developers think that
their M3 port is ready for a wider audience, they can merge it into the
mainline Asahi repos, where it will be distributed through the usual
nightly CI builds (where RELEASE_TYPE=pre-release; M3 support is no
longer experimental).
This will allow GUIs to customize their behavior a little based on the
type of release.
For example, an OS installer may display a warning/disclaimer if
RELEASE_TYPE=prerelease. The software updates app might be a bit more
insistent about upgrading to the next major release if
RELEASE_TYPE=stable than if RELEASE_TYPE=lts
The --list-invocations command is similar to --list-boots, but shows
invocation IDs of specified unit. This should be useful when showing
a specific invocation of a unit.
The --invocation option is similar to --boot, but takes a invocation ID
or an offset. The -I option is equivalent to --invocation=0.
This allows for "per-instance" credentials for units. The use case
is best explained with an example. Currently all our getty units
have the following stanzas in their unit file:
"""
ImportCredential=agetty.*
ImportCredential=login.*
"""
This means that setting agetty.autologin=root as a system credential
will make every instance of our all our getty units autologin as the
root user. This prevents us from doing autologin on /dev/hvc0 while
still requiring manual login on all other ttys.
To solve the issue, we introduce support for renaming credentials with
ImportCredential=. This will allow us to add the following to e.g.
serial-getty@.service:
"""
ImportCredential=tty.serial.%I.agetty.*:agetty.
ImportCredential=tty.serial.%I.login.*:login.
"""
which for serial-getty@hvc0.service will make the service manager read
all credentials of the form "tty.serial.hvc0.agetty.xxx" and pass them
to the service in the form "agetty.xxx" (same goes for login). We can
apply the same to each of the getty units to allow setting agetty and
login credentials for individual ttys instead of globally.
- Improve wording for explanation when these variables are inherited
- Clarify that these variables are not placed in the process environment block,
so /proc/PID/environ cannot be used as a debugging tool
Currently inhibitors are bypassed unless an explicit request is made to
check for them, or even in that case when the requestor is root or the
same uid as the holder of the lock.
But in many cases this makes it impractical to rely on inhibitor locks.
For example, in Debian there are several convoluted and archaic
workarounds that divert systemctl/reboot to some hacky custom scripts
to try and enforce blocking accidental reboots, when it's not expected
that the requestor will remember to specify the command line option
to enable checking for active inhibitor locks.
Also in many cases one wants to ensure that locks taken by a user are
respected by actions initiated by that same user.
Change logind so that inhibitors checks are not skipped in these
cases, and systemctl so that locks are checked in order to show a
friendly error message rather than "permission denied".
Add new block-weak and delay-weak modes that keep the previous
behaviour unchanged.
This adds support in `systemd-analyze capability` for decoding
capability masks (sets), e.g.:
```console
$ systemd-analyze capability --mask 0000000000003c00
NAME NUMBER
cap_net_bind_service 10
cap_net_broadcast 11
cap_net_admin 12
cap_net_raw 13
```
This is intended as a convenience tool for pretty-printing capability
values as found in e.g. `/proc/$PID/status`.
The page was written when systemd-repart was primarily intended to be used on a
running system. But nowadays it's more often used to create images, so extend
that part of the description.
While at it, fix some whitespace issues and trim some overly complicated sentences.
Certainly on systemd 252 at least a configuration of
```
MemorySwapMax=40%
```
is supported but this was missing from the man page.
Only MemoryMax was documented as supporting a %.
Since Linux commit ddd1ad68826d ("net: bridge: Add netlink knobs for number
/ max learned FDB entries") [1] it is possible to limit to number of
dynamically learned fdb entries per bridge.
Add support to the systemd netdev bridge for the new netlink attribute
IFLA_BR_FDB_MAX_LEARNED.
[1] https://lore.kernel.org/all/20231016-fdb_limit-v5-0-32cddff87758@avm.de/
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
When credentials are used with Type=simple + ExecStartPost=,
i.e. when multiple sd-executor instances are running in parallel
for a single service, the state of final credential dir
might be unexpected wrt path_is_mount_point() and other
steps. So, let's imply Type=exec if not explicitly specified,
and emit a warning otherwise.
pci_get_hotplug_slot() has the following limitations:
- if slots are not hotpluggable, they are not in /sys/bus/pci/slots.
- the address at /sys/bus/pci/slots/X/addr doesn't contains the function part,
so on some system, 2 different slots with different _SUN end up with the same
hotplug_slot, leading to naming conflicts.
- it tries all parent devices until it finds a slot number, which is incorrect,
and what led to NAMING_BRIDGE_MULTIFUNCTION_SLOT being disabled.
The use of PCI hotplug to find the slot (ACPI _SUN) was introduced in
0035597a30
"udev: net_id - export PCI hotplug slot names" on 2012/11/26.
At the same time on the kernel side we got
bb74ac23b1
"ACPI: create _SUN sysfs file" on 2012/11/16.
Using PCI hotplug was the only way at the time, but now 12 years later we can use
firmware_node/sun sysfs file.
Looking at a small selection of server HW, for HPE (Gen10 DL325), the _SUN is attached
to the NIC device, whereas for Dell (R640/R6515/R6615) and Cisco (UCSC-C220-M5SX),
the _SUN is on the first parent pcieport.
We still fallback to pci_get_hotplug_slot() to handle the s390 case and
maybe some other coner cases (_SUN on grand parent device that is not a
bridge ?).
Make the warning for oneshot services (where RuntimeMaxSec= has no
effect) more actionable by pointing to the directive people can use
instead to effectively limit their runtime.
As per DPS the UUID for /var/ should be keyed by the local machine-id,
which is non-trivial to do in a script. Enhance 'systemd-id128' to
take 'var-partition-uuid' as a verb, and if so perform the
calculation.
This is an analog of x-systemd.requires that adds a Wants dependency
instead. This is useful for filesystems that support mounting in
degraded states (such as multi-device filesystems).
Makes it possible to specify URLs to a changelog and an appstream
catalog XML in the sysupdate.d/*.conf files. This will be passed along
to the clients of systemd-sysupdated, which can then present this data.
This prevents sysupdate from going out to the network to enumerate
available instances. When combined with the list command, this lets us
query installed instances
The XDG base dir spec adopted ~/.local/state/ as a thing a while back,
and we updated our docs in b4d6bc63e6, but
forgot to to update the table at the bottom to fully reflect the update.
Fix that.
This file doesn't document features of systemd, but is more a of a
general description that generalizes/modernizes FHS. As such, the items
listed in it weren't "added" in systemd versions, they simply reflect
general concepts independent of any specific systemd version. hence
let's drop this misleading and confusing version info.
Or in other words, the man page currently claims under "/usr/": "Added
in version 215." – Which of course is rubbish, the directory existed
since time began.
This also rebreaks all paragaphs this touches.
No content changes.
Previously, the order was quite chaotic, even sometimes interleaved with
entirely unrelated switches. Let's clean this up and use the same order
as in the spec.
This doesn't change anything real, but I think it's a worthy clean-up in
particular as this order is documented as the PCR measurement order of
these sections, hence there's actually a bit of relevance to always
communicate the same order everywhere.
At this point we have a clearer model:
* systemd-measure should be used for measuring UKIs on vendor build
systems, i.e. only cover stuff predictable by the OS vendor, and
identical on all systems. And that is pretty much only PCR 11.
* systemd-pcrlock should cover the other PCRs, which carry inherently
local information, and can only be predicted locally and not already
on vendor build systems.
Because of that, let's not bother with any PCRs except for 11 in
systemd-measure. This was added at a time where systemd-pcrlock didn't
exist yet, and hence it wasn't clear how this will play out in the end.
Update the man page of tmpfiles.d to remove outdated comments regarding the behavior of ownership with symlinks.
The behavior has been changed in this commit 51207ca134
The new "password-cache" option allows customizing behavior of the
ask-password module in regards to caching credentials in the kernel
keyring. There are 3 possible values for this option:
* read-only - look for credentials in kernel keyring before asking
* on - same as read-only, but also save credentials input by user
* off - disable keyring credential cache
Currently the cache is forced upon the user and this can cause issues.
For example, if user wants to attach two volumes with two different
FIDO2 tokens in a quick succession, the attachment operation for the
second volume will use the PIN cached from the first FIDO2 token, which
of course will fail and since tokens are only attempted once, this will
cause fallback to a password prompt.
Currently, if user doesn't specify a key file, /etc/cryptsetup-keys.d/
and /run/cryptsetup-keys.d/ will be searched for a key file with name
matching the volume name. But current implementation has an important
flaw. When the auto-discovered key is a socket file - it will read the
key only once, while the socket might provide different keys for
different types of tokens. The issue is fixed by trying to discover the
key on each unlock attempt, this way we can populate the socket bind
name with something the key provider might use to differentiate between
different keys it has to provide.
It seems entirely reasonable to make a policy which e.g. allows block operations
for interactive users after authentication. The tool should support this, so that
more complicated local policies can be used.
Related to https://github.com/systemd/systemd/pull/30307.
This adds %q, %A and %M specifiers to tmpfiles:
- %A and %M were previously added to tmpfiles.d man page, but not to specifier_table
- %q is added via COMMON_SYSTEM_SPECIFIERS
As discussed in https://github.com/systemd/systemd/pull/32724#discussion_r1638963071
I don't find the opposite reasoning particularly convincing.
We have ProtectHome=tmpfs and friends, and those can be
pretty much trivially implemented through TemporaryFileSystem=
too. The new logic brings many benefits, and is completely generic,
hence I see no reason not to expose it. We can even get more tests
for the code path if we make it public.
