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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
SIG-prefixed signals for `kill` are not POSIX compliant, so on Ubuntu CI
(which defaults to dash instead of bash) the TEST-52 contains following
error:
[ 9693.549638] sh[51]: + systemctl poweroff --no-block
[ 9693.553130] systemd-logind[26]: System is powering down.
[ 9693.608911] sh[54]: /bin/sh: 1: kill: Illegal option -S
This can be reproduced manually as well, either by running dash, or bash
in POSIX mode:
$ dash -c 'kill -SIGKILL 123'
dash: 1: kill: Illegal option -S
$ bash --posix -c 'kill -SIGKILL 123'
bash: line 0: kill: SIGKILL: invalid signal specification
Because this was left unset, the unit_write_setting() function was
refusing to write out the automount-specific TimeoutIdleSec= and
DirectoryMode= settings when creating transient automount units.
Set it to the proper value in line with other unit types.
There's some highly specific PKCS#11 code in homectl.c. Let's split that
out, since it is easily isolatable, to make homectl.c a bit more
readable.
No funcional changes, just some moving around and renaming two functions
to make them more suitably named when exported.
When updating a home directory we might update the record first, then
resize the image and finally synchronize the passwords to the storage
layers. These are three individually authenticated operations. Since
each might require touching a FIDO2 or PKCS#11 key we should say what we
are doing. Hence do so.
Usually we are pretty quiet with what we do, and let's stick to that.
Hence show this information only if we actually do more than one thing.
If we only update (and do not resize/sync passwords) then let's be quiet
as usual, as the command line then sufficiently clarifies what we are
doing.
After all, when creating we might need interaction with the security
token too, and our initial attempt to create the user will fail, since
we do not allow interactive auth on the security token, so that we then
can print a log message and retry with interactive auth then enabled.
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.
