SoylentNews is people
SoylentNews
from the resistance-is-futile.-/home-will-be-assimilated dept.
Good News:
Linux home directory management is about to undergo major change:
With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.
[...] Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy.
But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.
[...] let's take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.
However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.
[...] Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes.
Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.
[...] Of course, such a major change doesn't come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH?
The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user's home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration.
Older articles:
- Pack Your Bags – Systemd Is Taking You To A New Home
- Systemd-Homed Merged As A Fundamental Change To Linux Home Directories
Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?
(Score: 5, Insightful) by Anonymous Coward on Friday May 01 2020, @12:13PM (6 children)
I would have much more respect for Red Hat and Lennart, if they would come clean and at least admit what they're really doing -- developing a totally different operating system. This is what systemd is. Hence the comment title: systemd/linux. Sure its a variant on UNIX and gnu/linux, and runs much of the same software, but it is a different OS. Plus, I believe what I have read others say: systemd is a take-over attempt on the free software world. Red Hat wants to be the Microsoft of Linux.
This is not a good development in my book.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @12:45PM (1 child)
Linext/Leannext
(Score: 0) by Anonymous Coward on Friday May 01 2020, @02:36PM
Linexit/Leannexit
fthfy
(Score: 0) by Anonymous Coward on Friday May 01 2020, @02:48PM (1 child)
I also wish he would put his hands into the X world. People dislike that API and interaction so much, and this guy _loves_ crappifying everything more, no doubt he has a grand vision for that.
Also, with breaking X compatibility, then he'll have broken the _complete_ stack and there's nothing left but systemd/linux. That'll be a complete fork. Hopefully it happens sooner rather than later, so that we can all get back to something that isn't broken.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @08:53PM
Can you say Wayland [freedesktop.org]?
(Score: 5, Informative) by rleigh on Friday May 01 2020, @07:34PM (1 child)
Well said. I think that what Lennart and his pals are doing is something that many of us have wanted to do. We've noticed that the way things are done can be improved, and that the existing way has numerous deficiencies.
Where we differ is that (when I was maintaining Debian sysvinit and related low-level boot stuff), I saw the possibilities but I also took into account the widespread breakage which would result, and decided to leave things alone. Which is not to say no improvements were made, but that they were always made with both sets of tradeoffs carefully considered. I introduced /run, for example following the systemd lead but being painless upgrade on working systems. Breaking an existing workflow was an absolute no-no. The contrast is that Lennart has cheerfully broken the entire system in multiple ways, and then told all us developers and end users to suck it up. That's where we differ. I would never have countenanced behaving that way.
I always saw software maintenance as being mindful of the legacy and being diligent in preserving compatibility. When hundreds of thousands of companies and individuals have entrusted you with keeping their businesses running and enabling their work and leisure activities, I always considered it a responsibility of some importance, and took great care not to break that trust, with small and focussed changes backed by extensive testing. systemd drove a bulldozer through it all. The breakage in Debian was unreal. Yes, the system wasn't perfect, but it had over 25 years of accumulated experienced encoded in it to support a truly vast set of use cases, and hardware variants. With systemd, if Lennart doesn't think your use case is important, then screw you! You're doing it his way! I see the fallout of this as an act of utter vandalism. After sinking so much of my life into Debian, I don't feel too ashamed to admit that I spent several years afterward with what I suspect was depression. I couldn't even face working on free software for several years afterward. Some bits, I still can't face. My motivation has been completely erased.
What really surprises me is the seeming lack of oversight within RedHat itself. Though maybe after we saw how the RPM maintainer used to behave, it shouldn't be surprising.
(Score: 4, Interesting) by Thexalon on Saturday May 02 2020, @02:55PM
The thing I've also noticed about Lennart's approach is that it seems to have carefully ignored everything about *why* the old way of doing things was the old way of doing things.
A key design decision systemd made very early on that has colored everything it has done since is "text-based communication between processes is bad". And this is the exact opposite of what Thompson, Ritchie, Kernighan, et al were trying to do when they built Unix, namely to avoid giant blobs of code where you can't easily examine or modify how the various parts talk to each other. And there was a very good reason for that: Those guys had experienced lots of quite complex operating systems with giant blobs of code where they couldn't easily examine or modify how the various parts talk to each other, and found them to be inflexible and hard to work with. This decision is precisely what leads to monstrosities like binary logs that can only be read if you have the right tools on hand and were written to disk without errors (even as the system might be in the process of crashing).
A key assumption that went into the design of Unix was "anything can break in ways we didn't anticipate, so let's make sure an admin can cope and fix it". A key assumption that went into the design of systemd was "anything that breaks breaks in a way that Lennart anticipated", and that assumption is so key that when things have broken in ways Lennart didn't anticipate his response has frequently amounted to "WONTFIX - theoretically impossible, so the bug report must be wrong". As an example of this being a problem, the experience that will always color my opinion of systemd was the day I rendered my system unbootable by cold-unplugging my mouse, because apparently Lennart hadn't anticipated that somebody might do that, and rather than start up without mouse support or drop me to a single-user shell or even spit out an error message systemd instead decided to show me a black black screen with a non-responsive keyboard.
And the thing is, I've worked with people like Lennart before, folks who were completely certain that their way of doing things was the One True Way and everyone else didn't understand their vision and skill and if those nattering nabobs of negativism would just let them code the results would be great all around. And every single one of them produced code that didn't actually work very well and was a nightmare to fix.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.