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: 3, Insightful) by NickM on Sunday September 22 2019, @02:35PM (7 children)
I understand the systemd hate to be mostly political as peoples felt is was rammed down their throats and that created long lasting resentment but I side with the distro maintainer on this because there are measurable benefits to the systemd approach when it come to treating servers like disposables cattles.
I work in a small team (6 including myself) in the information systems division of the biggest employer of my town, we manage 130 REHL6 VMs and 50¹ REHL7 VMs and countless containers. The REHL7 servers with systemd are much easier to works with Ansible² than the dusty init.d based REHL6 one's. The services files are much more uniform than the random mix of init.d scripts, making playbook creation a breezes.
On my workstation I use Arch another systemd infected distro. The user unit files are a great replacement to a hodgepodge of .rc scripts. I have a few of them in ~/.config/systemd/user/ . Mostly daemons I wrote in python that listen to dbus events to automate things like timekeeping.
The only thing I have against systemd is the retarded default of systemd-journald its configured to drop logs if the logging rate reach a stupidly low numbers of entry per seconds. But it's a minor inconvenience at best, as it takes a second to run the make-systemd-default-sane.yml Ansible playbook ...
Even though I like the current systemd-* collection of system deamon, I hope that the the portable encrypted yubikey supporting home will be introduced in a more civilized manners with the choice resting on the users.
I a master of typographic, grammatical and miscellaneous errors !
(Score: 1, Insightful) by Anonymous Coward on Sunday September 22 2019, @03:49PM (1 child)
Your post implies systemd is merely system software. It is not. What gets owned by systemd is not being relinquished to user discretion. If it cannot be done by tweaking config files it cannot be done at all. Say goodbye to a programmable environment. Say hello to a configurable environment. It will give you guys something to be paid for forever, until a bot takes over. By that time the server will be a play store instance.
(Score: 1) by NickM on Sunday September 22 2019, @04:47PM
The bot can take over it will free us from system maintenance and give us more time to spend on developers tooling and workflow automation...
Your servers play store already exists and its called the docker registry. But for security reason you should rebuild the images on your servers, sign them and disallow unsigned containers execution.
I a master of typographic, grammatical and miscellaneous errors !
(Score: 1, Interesting) by Anonymous Coward on Sunday September 22 2019, @04:02PM (3 children)
I've always used rsync and shell scripts to image servers. Why use card houses like puppet and ansible?
(Score: 2, Informative) by NickM on Sunday September 22 2019, @04:38PM (2 children)
I can speak about Puppet but Ansible favor description over imperatives programming. A normal playbook is self-documenting and idenpotent while a shell script is not unless you take the time and the effort to make it so. Does your scripts edit appplication server xml using xpath ? Do they configure load balancing your F5 BigIP appliance? Do they interop with ActiveDirectory (it is unavoidable in a enterprise settings)?
A 100 lines playbook correspond to something like 1000 to 10000 lines of shell script.
For a team of one rsync+shell works but as you scale, having an homogeneous descriptive way to configure systems is not a luxury it's a time saver
I a master of typographic, grammatical and miscellaneous errors !
(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 !
(Score: 4, Insightful) by Anonymous Coward on Sunday September 22 2019, @05:08PM
Poettering's ideas are decent. But basically he is reinventing the the windows/VMS subsystems that do these exact things. He just described good swaths of active directory and ldap.
But the problem is he half asses these huge ideas. It takes *ages* to fix the damage he does. Then after 10 years of *other* people fixing the holes the thing works again.
One big is issue is his scope creep on things. There are things in system.d that have 0 place in that stack. Yet they are there. An init system should init things. Do it consistently then get the hell out of the way. But it contains things that do not belong like DNS another reinvented logging syste. Those are subsystems. We already had a few dozen of those yet they reinvented yet another one. Which is fine. But why is it part of the systemd packages? He completely blew up the sound subsystem in linux. It took *years* before people could reliably get sound out of their computers again with out a major config pain.
He has done this pattern over and over of blowing things up then leaving to wander off to some other new toy. Leaving behind a ruin of code that someone else has to clean up.
THAT is why we look at what he does with disdain. Not the idea itself. But the implementation stinks.
as it takes a second to run the make-systemd-default-sane.yml Ansible playbook
A perfect example. The out of the box is un-sain. You have to spend time fiddling and tweaking to get it to behave in a nice way. That sums up pretty much everything he does. Half assed with no '90%' case looking to the average user and config points for the non average. Just 'haha you should have RTFM'. Freeking annoying and a freeking waste of everyone's time.