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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The directory might not be created in the ESP but in the extended boot
loader partition, hence don#t claim otherwise.
Also, give a brief reason why the concept exists at all.
Link up machine-id man page.
Follow-up for: 6a3fff75baad94d9ebff1a6c7d1fb35448c44a81
To determine the network interface type for use in the `Type=` directive, it is more concise to use the `list` command. Whereas, the `status` command requires an interface parameter.
For example, on a RaspberryPi 4 the following shows that the `wlan0` interface type `wlan` is more coveniently listed by the `list` command.
```
root@raspberrypi4-64:~# networkctl list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 wlan0 wlan off unmanaged
3 links listed.
```
Whereas the `networkctl status` command doesn't include this information.
```
root@raspberrypi4-64:~# networkctl status
● State: routable
Address: 192.168.1.141 on eth0
fd8b:8779:b7a4::f43 on eth0
fd8b:8779:b7a4:0:dea6:32ff:febe:d1ce on eth0
fe80::dea6:32ff:febe:d1ce on eth0
Gateway: 192.168.1.1 (CZ.NIC, z.s.p.o.) on eth0
DNS: 192.168.1.1
May 07 14:17:18 raspberrypi4-64 systemd-networkd[212]: eth0: Gained carrier
May 07 14:17:19 raspberrypi4-64 systemd-networkd[212]: eth0: Gained IPv6LL
May 07 14:17:19 raspberrypi4-64 systemd-networkd[212]: eth0: DHCPv6 address fd8b:8779:b7a4::f43/128 timeout preferred -1 valid -1
May 07 14:17:21 raspberrypi4-64 systemd-networkd[212]: eth0: DHCPv4 address 192.168.1.141/24 via 192.168.1.1
```
To get the interface type using the `status` command you need to specify an additional argument.
```
root@raspberrypi4-64:~# networkctl status wlan0
● 3: wlan0
Link File: /lib/systemd/network/99-default.link
Network File: n/a
Type: wlan
State: off (unmanaged)
Path: platform-fe300000.mmcnr
Driver: brcmfmac
HW Address: dc:a6:32:be:d1:cf (Raspberry Pi Trading Ltd)
MTU: 1500 (min: 68, max: 1500)
QDisc: noop
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
```
This ensures we not only synthesize regular paswd/group records of
userdb records, but shadow records as well. This should make sure that
userdb can be used as comprehensive superset of the classic
passwd/group/shadow/gshadow functionality.
Some tokens support authorization via fingerprint or other biometric
ID. Add support for "user verification" to cryptenroll and cryptsetup.
Disable by default, as it is still quite uncommon.
In some cases user presence might not be required to get _a_
secret out of a FIDO2 device, but it might be required to
the get actual secret that was used to lock the volume.
Record whether we used it in the LUKS header JSON metadata.
Let the cryptenroll user ask for the feature, but bail out if it is
required by the token and the user disabled it.
Enabled by default.
Closes: https://github.com/systemd/systemd/issues/19246
Some FIDO2 devices allow the user to choose whether to use a PIN or not
and will HMAC with a different secret depending on the choice.
Some other devices (or some device-specific configuration) can instead
make it mandatory.
Allow the cryptenroll user to choose whether to use a PIN or not, but
fail immediately if it is a hard requirement.
Record the choice in the JSON-encoded LUKS header metadata so that the
right set of options can be used on unlock.
On headless setups, in case other methods fail, asking for a password/pin
is not useful as there are no users on the terminal, and generates
unwanted noise. Add a parameter to /etc/crypttab to skip it.
$ coredumpctl info |grep Command
Command Line: bash -c kill -SEGV $$ (before)
Command Line: bash -c "kill -SEGV \$\$" (road not taken, C quotes)
Command Line: bash -c $'kill -SEGV $$' (now, POSIX quotes)
Before we wouldn't use any quoting, making it impossible to figure how the
command line was split into arguments. We could use "normal" quotes, but this
has the disadvantage that the commandline *looks* like it could be pasted into
the terminal and executed, but this is not true: various non-printable
characters cannot be expressed in this quoting style. (This is not visible in
this example). Thus, "POSIX quotes" are used, which should allow any command
line to be expressed acurrately and pasted directly into a shell prompt to
reexecute.
I wonder if we should another field in the coredump entry that simply shows the
original cmdline with embedded NULs, in the original /proc/*/cmdline
format. This would allow clients to format the data as they see fit. But I
think we'd want to keep the serialized form anyway, for backwards compatibility.
This commit applies the filtering imposed by LogLevelMax on a unit's
processes to messages logged by PID1 about the unit as well.
The target use case for this feature is a service that runs on a timer
many times an hour, where the system administrator decides that writing
a generic success message to the journal every few minutes or seconds
adds no diagnostic value and isn't worth the clutter or disk I/O.
The maximum allowed value of the sysfs device index entry was limited to
16383 (2^14-1) to avoid the generation of unreasonable onboard interface
names.
For s390 the index can assume a value of up to 65535 (2^16-1) which is
now allowed depending on the new naming flag NAMING_16BIT_INDEX.
Larger index values are considered unreasonable and remain to be
ignored.
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
Similar to sd_bus_error_has_names() that was added in
2b07ec316a0e25a3e10c270c7f6baee9e0187bf8.
It is made inline in the hope that the compiler will be able to optimize
all the va_args boilerplate away, and do an efficient comparison when
the arguments are all constants.
