Is the PyraOS going to have systemd-homed?

[Silent-Hunter]

I don't really like the sound of this.

Linux home directory management is about to undergo major change | TechRepublic

With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.

www.techrepublic.com

Does the PyraOS have to use this?

 

[lukey]

PyraOS == debian

Also the Article forgets to mention that systemd-homed is *optional*.

Also systemd 245 is already released.

 

[levi]

Probably not; looks like Buster only took systemd 241. Over time we'll move to whatever comes after Buster I think, and that may well give us systemd 245 or later, because 244 is in sid so they do seem to be tracking the project.

However, it's my understanding that systemd can't force you to use this. If I'm wrong I'll have to stick with 244 on my archlinux servers, because I ssh into that. It's all encrypted under luks to begin with, although my entire home partition gets unlocked at boot when I type in its password, and I've never had a problem moving my home folder around, but to be fair I do appreciate the idea of home folders only being accessible when they're someone using them, if someone more clever than me can figure out the sshd conundrum. And adding users could be easier; remembering that you need useradd not adduser to add a user and remembering to supply the -m flag to give them a home folder, and remembering that to add a user to a group you don't use groupadd (that adds groups to the system), instead you need usermod. In my experience, the interfaces the pottering and his crew add make more sense that that.

Edit:

Also systemd 245 is already released.

That's true. I've apparently been running it for a couple of weeks now, and it hasn't touched my home folders yet. Mind you, homectl doesn't work on my systems because of a missing service that perhaps I need to install before problems start.

Edit: Looks like the text list I was looking at was out of date; sid does have 245, as does bullseye (the one after buster).

 

[elvissteinjr]

Can somebody explain me how cryptographically signed JSON records and home directories as encrypted containers are a valid response to "This is inefficient, and Poettering has decided to make a drastic change."?
It's the author's words, sure, but even that aside, none of this strikes me as especially efficient.

Stuff is optional right now it seems, so that's something at least. But hey, that portable home directory container won't be that portable if we don't make sure homed is running everywhere, so watch out.
Imagine just wanting to boot into a system with no bs.

 

[Linux-SWAT]

No need systemd to have a portable /home/joe.
Just mount a drive in /home/joe.

 

[levi]

Can somebody explain me how cryptographically signed JSON records and home directories as encrypted containers are a valid response to "This is inefficient, and Poettering has decided to make a drastic change."?

'Inefficient' is perhaps a misleading word, at least how you frame it. The problem with traditional home directories is that they're insecure without extra cruft. Your computer gets stolen, they won't be able to log in, but if they simply remove the disc drive they can read everything in your home folder; get all of your emails, your photos, any private data you have there. It's why on more recent computers I've set up, I've encrypted the home partition, so you need to provide a password during boot to unlock it. With this system, the computer should be able to boot more fully before it needs a password (I'm not sure what actually depends on my home folder being present, but my archlinux box asks for the password about half way through bootup).

Portability without systemd might be a bit more involved, but as I read it it's all done with standard tools; LUKS is what I use for encrypting my home partition, and it should be possible to find out the password for it.

 

[FBnil]

Can somebody explain me how cryptographically signed JSON records and home directories as encrypted containers are a valid response to "This is inefficient, and Poettering has decided to make a drastic change."?

First of all, do not think about your home computer, where everything is on a local disk(s). Rather, a company, where many people need to access many machines. Those machines do not have harddisks, they have network storage, which get mounted from SAN's. Now one of those machines actually does not have your userid in /etc/passwd, instead, it has it as an LDAP (maybe even linked to an Active Directory). And your home directory is mounted on-the-fly with autofs when you log in. The FS could also be NFS, and ... Ninja'd by @levi Pretty good points.

 

[Djoga'Ro]

(I'm not sure what actually depends on my home folder being present, but my archlinux box asks for the password about half way through bootup)

Processing fstab?

 

[levi]

Yes, almost certainly. Or at least, that's the opinion I held shortly after writing that

 

[PowerGod]

Your computer gets stolen, they won't be able to log in, but if they simply remove the disc drive they can read everything in your home folder; get all of your emails, your photos, any private data you have there. It's why on more recent computers I've set up, I've encrypted the home partition, so you need to provide a password during boot to unlock it.

Are you able to access the data if the disk can't boot anymore, and you have to put it in an external box ?

 

[levi]

Yes, provided the partitions themselves are okay and turn up when I plug it in (which applies even if I hadn't encrypted the disc), I need to issue 'cryptsetup open /dev/disk/by-label/home', type in my password, then 'mount /dev/mapper/home /mnt' to mount it.

 

[netcat]

I'm not familiar with homed, but I hope it doesn't result in churn like we saw with eg sysvinit, systemd, upstart, etc.

Pyra needs an approach that is stable and lightweight more than portable and efficient, i would think.

That said, encrypting /home is the correct thing to do by default in this modern day and age. Hopefully we can find a way that is performant and not too onerous.

I am also interested in filesystem compression. Game images became bloated with the advent of the CD-ROM.