Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday May 01 2020, @11:04AM   Printer-friendly
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:

Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by Arik on Friday May 01 2020, @02:25PM (4 children)

    by Arik (4543) on Friday May 01 2020, @02:25PM (#988967) Journal
    "What a ridiculous argument."

    It's not a ridiculous argument at all. Making programs more powerful doesn't always or even often make them better programs. If take my init system and give it power over the entire system I don't get a better init, I just make the consequences of a bug in the init system much more severe.

    "Imagine a temporary problem with my network."

    OK.

    "Several parts of the system might stop working because they have lost connectivity."

    What? Why? That shouldn't be happening. Which parts specifically?

    "systemd knows which programs rely on the network and, when the temporary problem is resolved, it automatically restarts all the programs that need to be restarted."

    Well that sounds like slapping a bandaid on a gunshot wound. It would be better to fix the parts of your system that are faulty. Bandaids like automatically restarting a program can be applied with different tools.

    "it is doing everything that I ask of it"

    Perhaps you should think about what you are asking of it, and why.

    What I ask of an init system is to reliably start (init, get it?) my system, no less and no more.

    Once I have a shell prompt it needs to unload and get out of the way. If I need something restarted, that's the job of another program, not the init system.
    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Moderation   +3  
       Insightful=3, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 1, Troll) by janrinok on Friday May 01 2020, @03:10PM (3 children)

    by janrinok (52) Subscriber Badge on Friday May 01 2020, @03:10PM (#988999) Journal

    Bandaids like automatically restarting a program can be applied with different tools.

    I was with you until here - then you lost it.

    You admit by implication that there is a need to automatically restart programs because there are different tools for doing that job. So your objection is that they are perfectly acceptable but systemd isn't. Systemd wasn't written for the home user - it was initially targetted at instances running in the cloud. Have you tried manually restarting several thousand instances when necessary? No, I thought not. There it is very useful indeed. However, it can be equally useful on much small networks or even individual systems. You don't have to use any of it, if you don't wish. But many distros are looking at supporting more than just the home user or indeed larger networks. So they adopted a standard way of doing the things that their customers wanted to be done. And one of those things was to enable systems to keep themselves going when there are faults.

    I have no problem with those that don't want to use it - but the people on here complaining about it are mostly those who DO NOT use it. They tell us about how this distro or that distro is still free of systemd and therefore 'much better'. That's fine, but why argue about something that you do not use? Lots of us just get on with it. It works, I have no problems with it, it does what it says on the tin, and I have no need of paid support from Red Hat or anyone else. Why shouldn't I be able to use it if it does exactly what I want. And this feature - to me - is useful. I won't tell you what to install on your computers.

    Shall we argue about emacs/vi next or Python/Rust/Go?

    • (Score: 5, Insightful) by Arik on Friday May 01 2020, @03:59PM

      by Arik (4543) on Friday May 01 2020, @03:59PM (#989012) Journal
      "You admit by implication that there is a need to automatically restart programs because there are different tools for doing that job."

      Sure, in practice it's sometimes good to have a bandaid available. That doesn't mean we need to re-organize our entire lives around a full body suit that applies bandaids automatically.

      "So your objection is that they are perfectly acceptable but systemd isn't."

      My objection is that this is not how you build good tools. Systemd is an attempt to replace the entire toolbox with one robot.

      I can see how this idea can have some attraction - working with tools requires effort, and thought, and occasionally you skin a knuckle. It's so much easier just to turn the robot on and let it do all the work.

      But then we're left with no good tools, and completely dependent on the robot and its owner (hint, that is not you or I.)

      "it was initially targetted at instances running in the cloud."

      You mean in VMs right? "The cloud" is meaningless marketdroid speak.

      Look it might be very useful there. But if you want that functionality, implement it within the design of the system, or fork your own distro just for VMs and include shims so that you don't break things.

      "That's fine, but why argue about something that you do not use?"

      Because it's a well-funded commercial project that's not only openly aiming to destroy the free software infrastructure needed to support my continued ability to operate without them, but is already pretty far down that road.

      Yes, we still have other choices. And we'd like for that to continue to be the case. Operating systems do require maintenance. The more free software developers that get hornswoggled into using systemd, the more quickly that choice will disappear.
      --
      If laughter is the best medicine, who are the best doctors?
    • (Score: 0) by Anonymous Coward on Friday May 01 2020, @10:21PM (1 child)

      by Anonymous Coward on Friday May 01 2020, @10:21PM (#989237)

      Have you tried manually restarting several thousand instances when necessary?

      { for ip in $(cat ips.txt); do ssh -n "$ip" "whatever command" & done } >output.log 2>error.log

      Works pretty well for me when I need to do stuff on ~2400 VMs simultaneously. Which was pretty darn regular until last week when that project finished.

      • (Score: 0) by Anonymous Coward on Saturday May 02 2020, @05:56AM

        by Anonymous Coward on Saturday May 02 2020, @05:56AM (#989348)

        We do what one of my coworkers calls "FCUs" or ForceCommand Users. Just the act of authenticating with ssh with the right credentials triggers certain actions. Proper auditing and access control makes that stuff simple and a lot easier to find bad actions.