Yu Watanabe [Mon, 7 Jun 2021 12:53:35 +0000 (21:53 +0900)]
network: address: always read address flag from IFA_FLAGS attribute
Otherwise, update flag become incomplete and the IFA_F_MANAGETEMPADDR flag
will not be stored, thus no temporary addresses will be removed when
networkd requests to remove the main address.
tmpfiles: do not check if unresolved globs are autofs paths
With the previous commit, we would not complain about the not-found path, but
the check is still not useful. We use a libc function to resolve the glob, and
it has no notion of treating autofs specially. So we can't avoid touching
autofs when resolving globs. But usually the glob is found in the last
component of the path, so if we strip the glob part, we can still do a useful
check in many cases. (E.g. if /var/tmp is on autofs, something like
"/var/tmp/<glob>" is much more likely than "/var/<glob-that-matches-tmp>/<something>".)
With the system config in F34, we check the following prefixes:
tools/analyze-dump-sort: a helper to compare two 'systemd-analyze dump' outputs
Lines in the dumps are ordered by some pseudo-random hashmap entry order, which
makes it hard to diff two outputs. This sort the entries alphabetically, and
also sorts items within the entries, and supresses timestamps and other fields
which always vary.
We could sort the output inside of systemd itself, but it'd make things more
complex, and we probably don't need output to be sorted in most cases. It also
wouldn't be enough, because timestamps and such would still need to be ignored
to do a nice diff. So I think doing the sorting and suppression in a python
helper is a better approach.
pid1: downgrade if we can't make sense of the old device on MOVE uevent
If the name of the old device didn#t work for us, we don't have to clean
anything up, since we know for sure that there won't be a device unit
for it. hence downgrade log message about it.
pid1: properly propagate errors from device_setup_unit()
We want to propagate errors here, since we want to make dependent on the
success of creating the main device unit the creation of the auxiliary
device units. Thus if we suppress errors here we might end up in exotic
corner cases in a situation were we create the auxiliary ("following")
device units without the primary one.
ask-password: make password echo fully configurable
This adds --visible=yes|no|asterisk which allow controlling the echo of
the password prompt in detail. The existing --echo switch is then made
an alias for --visible=yes (and a shortcut -e added for it too).
Yu Watanabe [Wed, 2 Jun 2021 07:29:59 +0000 (16:29 +0900)]
sd-device: do not use ::subsystem member directly
The value is set dynamically when sd_device_get_subsystem() is called
first time.
Fixes the following issue:
```
$ build/udevadm test /sys/class/block/dm-1
...
Assertion '_subsystem' failed at src/libsystemd/sd-device/sd-device.c:767, function device_set_subsystem(). Aborting.
Program received signal SIGABRT, Aborted.
```
tmpfiles: stop complaining about autofs on not-found paths
systemd-tmpfiles[328]: Failed to determine whether '/run/cryptsetup' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/etc/resolv.conf' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/lock/subsys' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/setrans' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/console' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/faillock' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/sepermit' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/motd.d' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/motd.d' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/motd' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/run/nologin' is below autofs, ignoring: No such file or directory
systemd-tmpfiles[328]: Failed to determine whether '/var/lib/systemd/pstore' is below autofs, ignoring: No such file or directory
... and so on and so on.
various: don't say that the timestamp 'changed' on initial load
I always found this a bit annoying.
With the patch:
$ SYSTEMD_LOG_LEVEL=debug build/udevadm test /sys/class/block/dm-1
...
Loaded timestamp for '/etc/systemd/network'.
Loaded timestamp for '/usr/lib/systemd/network'.
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
Loaded timestamp for '/etc/udev/rules.d'.
Loaded timestamp for '/usr/lib/udev/rules.d'.
...
dissect: if dissecting without udev, don't look for usec timestamp on db record
There will likely be none, hence don't bother.
This fixes an issue in systemd-gpt-auto-generator where we'll try to
wait for the udev db for the partitions even though though udev might
simplynot be around and via the DISSECT_IMAGE_NO_UDEV flag were
explicitly told not to bother.
pam: do not require a non-expired password for user@.service
Without this parameter, we would allow user@ to start if the user
has no password (i.e. the password is "locked"). But when the user does have a password,
and it is marked as expired, we would refuse to start the service.
There are other authentication mechanisms and we should not tie this service to
the password state.
The documented way to disable an *account* is to call 'chage -E0'. With a disabled
account, user@.service will still refuse to start:
systemd[16598]: PAM failed: User account has expired
systemd[16598]: PAM failed: User account has expired
systemd[16598]: user@1005.service: Failed to set up PAM session: Operation not permitted
systemd[16598]: user@1005.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
systemd[1]: user@1005.service: Main process exited, code=exited, status=224/PAM
systemd[1]: user@1005.service: Failed with result 'exit-code'.
systemd[1]: Failed to start user@1005.service.
systemd[1]: Stopping user-runtime-dir@1005.service...
cryptsetup: don't bother waiting for TPM2 devices if we are on EFI and EFI says there is no TPM2 device
Note that this means EFI-systems with a manually added TPM device won't
be supported automatically, but given that the TPM2 trust model kinda
requires firmware support I doubt it matters supporting this. And in all
other cases it speeds things up a bit.