SoylentNews is people
SoylentNews
from the all-your-computer-are-belong-to-us dept.
At the All Systems Go conference in Berlin 20-22 September, Lennart Poettering proposed a new extension to systemd, systemd-homed.service. A video of his session can be downloaded from media.ccc.de with accompanying slides [PDF].
In his presentation, Poettering outlines a number of problems he sees with the current system, like /etc needs to be writeable, UIDs need to be consistent across systems, and lack of encryption and resource management.
His goals with the proposed solution are migrateable and self-contained, UID-independent home directories with extensible user records that unify the user's password and encryption key; LUKS locking on system suspend; and Yubikey support.
He identifies a number of problems this new idea could cause with SSH logins, disk space assignments, UID assignments, and LUKS locking.
He plans to introduce JSON user records that can be queried via a Varlink interface and to a certain extent are convertible to and from existing formats. The home directories will be stored as LUKS-encrypted files that will be managed by the proposed new service, systemd-homed.service. The system integration will be supported by pam_systemd and systemd-logind.service.
It will be interesting to see how the world responds to this new take on systemd's ever-increasing encroachment of Linux.
... and lastly, this story is brought to you from a systemd-free laptop.
(Score: 2) by rleigh on Sunday September 22 2019, @10:33PM (1 child)
If you think that Ansible is idempotent, then you've not been using it long enough...
Yes, it touts idempotency as one of its features. But there are so many non-idempotent behaviours that I regard it as something of a joke. Are your roles and playbooks truly idempotent? I strongly suspect that most people do not have genuinely idempotent behaviour.
Like systemd, Ansible is a grossly overengineered monstrosity, which can be incredibly fragile.
(Score: 2) by NickM on Monday September 23 2019, @09:04PM
You are technically correct most of my install and upgrade playbooks are not technically idenpotent because they create timestamped backup, still we take care to specify a when condition when using nonidenpotent operations (line insert and xml add_children, come to mind) and our networking playbooks are. Also we dont use Ansible roles, we only use import_playbook in an "orchestration playbook", the recommended directory layout is excessively complex for no apparent benefits. We settled on the following layout on a per product basis :
It's not because a tool enables complexity that it necessarily requires it.
I a master of typographic, grammatical and miscellaneous errors !