Systemd-homed merged as a fundamental change to Linux home directories | Hacker News Reader

Systemd-homed merged as a fundamental change to Linux home directories

phoronix.com

61 pointsmbreese113 comments

I read the design document for this.

What's the point? This is not the 1990s. Who exactly is this for?

Who actually has multi-user systems. Really has them.

Clients are either all single-user laptops (at home and at work), or single-user workstations. Very rarely they're multi user workstations, but then they use something non-local for their home directories anyway, so again who is this for?

This isn't the 1990s with 100 users on your computer club Linux server. Everyone just gets their own VM, now.

Honestly, who still runs a 1990s style shared shell server?

And per-user /home encryption on a shared system just sounds like a threat model contradiction. If you want to protect the users from each other then turning a blind eye to the regular local root exploits sounds odd at best. On servers for cifs /home if my home directory is secret, why would I expose it to every server I log in to?

And if not for human user accounts, how will this help anyone run their docker containers or any other type of service?

Am I just out of touch? Does this actually have users? Does it actually solve a problem?

It breaks many use cases, that's very obvious.

Anecdotally, my laptop is being used by two users. It irks very much that neither Ubuntu nor Fedora can easily support a common directory for data to be shared between users. I ve created custom bash commands to fix group file ownership and similar issues arising from sharing a directory between two home users.

Have you looked into ACLs and/or setgid with a shared group? Used to do this at work all the time for numerous groups of users. This is definitely possible. You may need to pay attention to your umask.

I have not looked at ACLs. They look too complex. Setgid works on file copy but not on file move. Not sure about umask.

Well, move on ext4 (and most other Linux filesystems) has very specific semantics - keep the file intact in every possible way (including permissions, modification time, ownership etc) but make it visible through another name.

Please be aware that that the common semantics are that permissions are associated with a file, not with its name (and a file may have a lot of names through hard links, or no name at all - open a file, delete it, and it is only accessible if you have an fd, or with little more work through the inode number)

I am indeed on ext4 (and MATE DE). Thank you for the information, although I am not sure what's the next step to have the OS enforce a certain group (and 775 permissions optimally) on all files created/copied/moved (moved is the part that's the biggest pain) within a certain directory.

You can write a script that does "inotify_wait" on your directory and changes the permission on anything that's there and doesn't have them.

a share command that does the necessary permission changes (and optionally the move) would be nice.

effectively you want to be able to say: share this file with joe, or

    share -rw joe john ... file ... destination/;

something along those lines that will change the acl as needed.

You should be able to share a FAT32 partition without overwhelming permission problems.

Not much differently than sharing a USB volume.

It should be easy to do this? Create a group, place the two users in that group, create a directory and setgid it to the group.

That works when copying but not when moving files. For the latter case you need to manually edit those properties.

Just setup a third user ("adduser [--disabled-login] user3", then share his home directory: make both users members of the third user's main group "adduser user1 user3 && adduser user2 user3" (assuming you don't want to alter both user's main groups for privacy), then "chmod g+wx /home/user3" and have a cron job enforcing all files in the shared directory belong to the user3 user/group and are writable by the group "* * * * * root chown -r user3:user3 /home/user3 [possibly add: && false || chmod -r g+w /home/user3]". Then create (soft|hard) links to the third user's home dir if you like.

This way you retain each user's privacy, since main groups aren't changed, don't need to run custom scripts each time, and don't have multiple copies of the shared files. The only (IMHO minor) issue would be that newly shared files might only be accessible for the other user 30s later on average, and 1 minute at most. The cron job might be converted into a daemon monitoring new files appearing in /home/user3, but that is left as an exercise for the reader :)

You don't need to use groups since ACLs:

    setfacl -R \
    -m d:u:user1:rwx -m u:user1:rwx \
    -m d:u:user2:rwx -m u:user2:rwx \
    /home/shared

d:u: sets the default user ACL for future directory entries

u: sets the current user ACL for existing directory entries

-R sets the ACLs recursively on existing files

I'm not a systemd fan by any means, but yes, there are far more ways Linux is used where this will be useful. There are still compute clusters and terminal servers where the overhead and isolation of a VM is counterproductive, and use cases where containers are not yet secure enough.

I also think it's likely there are future solutions which will be made possible that we can't even imagine right now, through what this brings to the table.

But in these clusters where a VM is too much overhead, isn't LUKS and the others?

I manage huge compute clusters, with and without VMs, and can't imagine a feasible use case for this, barring a time machine to the 90s.

> But in these clusters where a VM is too much overhead, isn't LUKS and the others?

No. First of all, in general disk encryption is orthogonal to multi-user or multi-seat systems, and the same case for disk encryption can be made wrt VM sessions. Secondly, the main feature is migratable and self-contained home directories, which is also relevant for VMs (or even more relevant).

Hmm... migratable and self-contained home directories. What do you mean? iSCSI, or something like it? Again, I'm not seeing what value systemd is adding here.

Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous as it's Android) implementation.

Still, the main aim of this is in my opinion not safe isolation of users on a single machine, but rather safe locking of the encrypted root folder.

With a normal LUKS setup, everything is inside a LUKS container, including the rootfs from which the OS itself is running. This complicates locking the LUKS container when the device gets suspended, as there will be open files, etc.

With Homed as far as I can tell, this is explicitly possible, it should be able to drop the encryption keys when machine goes to suspend, making it less likely your data will be recovered if the machine gets lost or stolen. With the keys in RAM an attacker might attempt to pull it from the machine & read the keys or use some method to defeat the lockscreen. With the keys dumped from RAM, this is no longer possible.

Android is so hugely different that it's not really an argument for adding it to systemd.

> [locking when suspenden] With Homed as far as I can tell, this is explicitly possible

Is it? Your home dir definitely will have open files when you lock or suspend.

> The go-luks-suspend program replaces the default suspend mechanism of systemd. It chroots to initramfs in order to perform the luksSuspend, suspend to RAM, and luksResume operations. It relies on the shutdown initcpio hook to provide access to the initramfs.

https://github.com/guns/go-luks-suspend from 2013

This also doesn't accidentally leak all the stuff not within /home/you

They're rampant in the education industry - At basically every level.

School labs with many shared computers for kids high school aged and below.

Larger servers at colleges for projects that are just unreasonable to run on a standard desktop machine.

I'm out of date here, but in my days this was often AFS and stuff.

But again: What's the threat model for LUKS, here? A student has their stuff on that exact shared machine in the computer lab, and somehow local root attacks only work when attacker is alone on the machine?

> Who actually has multi-user systems. Really has them.

In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense?

Speaking for myself, if multiseat Linux boxes were more easy to setup, I would certainly use one of those as my family's primary desktop. Today's desktop systems are quite capable of taking a multi-user computational beating and breeze through any amount of browser windows opened. Thus, if buying a monitor and keyboard is all it takes to get another computer seat then why not?

> a monitor and keyboard

And a Raspberry Pi.

Nope, you plug multiple monitors and peripherals into the multiseat box. Terminal(emulator)s are only used over long distances.

Plugging in an underpowered and resource-starved raspberry pi doesn't give you the same user experience as plugging in a Ryzen7 with 32GB of RAM that you already paid for and have lying around and idling at 5%

I guess people have different ideas about what a thin terminal means.

You're the one confusing a thin terminal with a multi-seat system. This thread is discussing multi-user and multi-seat systems and thin clients is a whole different beast.

Not really. A thin client is just another way to add a seat to a multiuser machine. Thin clients are just fine for a lot of real work (programming, office tasks). But for home use you need clean 1080p fullscreen video playback and none of the traditional thin clients can handle that.

systemd supposedly has built-in plug-and-play multiseat support: http://0pointer.de/blog/projects/multi-seat.html

Not sure I've heard of people using it, but I'm curious!

I use it. It works. I lucked into a semi-obsolete high-end gamer machine with a 6-core i7 and 24GB of memory and three full-length PCI-Express slots. I leave my machine on. The standby power of this monster (850W power supply) was too high to justify. So I tried it. Three video cards in the three slots. Came right up, the Linux desktop extended seamlessly across any monitor plugged into any of the cards (a mix of AMD and Nvidia no less).

Enter multi-seat. A few "sticky" commands later (i.e. only needed for reconfiguration, not on every boot) I have three user stations, each with monitor, keyboard, mouse, audio and at least one dedicated USB socket. Works a treat. It's not 100% bulletproof; crashes to the point of needing a reboot maybe 2-3 times a year, but aside from that indistinguishable from dedicated computers for each screen.

Stock Fedora 28. Here's the sum total of commands needed to set up the multiseat in my setup (seat 0 gets everything not assigned to the others).

loginctl attach seat1 /sys/devices/pci0000:00/0000:00:09.0/0000:05:00.0/drm/card0 /sys/devices/pci0000:00/0000:00:09.0/0000:05:00.0/graphics/fb0 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:07.0/0000:04:00.0/drm/card2 /sys/devices/pci0000:00/0000:00:07.0/0000:04:00.0/graphics/fb2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.1/1-4.1.4/1-4.1.4:1.2/0003:046D:C52B.00A3/0003:046D:4004.00A4/input/input194 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.4/1-4.4:1.0/0003:045E:00B9.00A5/input/input195

I hope this functionality doesn't turn into abandonware before I'm done with this monster machine i.e. it breaks or becomes too obsolete. I did in the past try to set up multiseat, just for fun, with a Displaylink box, after reading the article about it, but got nowhere, with the distinct feeling that they got it working once, and then abandoned it.

A few more details. One thing that doesn't work very well is storage devices. For one thing, as soon as one appears, the (non-multiseat aware) file managers all jump on it and try to mount it. And two of the three get a password prompt because they don't own the USB socket, and tie up the device so the one that does can't mount it. Solution: Turn off automount, and only use storage devices from seat 0.

You run into occasional other "more than one user per computer" issues. For example, trying to access the same UDP RTSP camera from VLC on two different desktops.

And the three desktops do get actively used by three differerent family members. Linux on the desktop for non-geeks/kids? Nobody cares. As long as the browser works with full video capability (smooth 1080p Youtube) and, in the child's case, the Tuxpaint painting program, everybody happy.

I keep thinking of more stuff to add. Multiple monitors: Well, a typical video card has two output sockets and easily drives two monitors. So why not two users? Because multiseat only works if each session gets to own its video chip, in its own private instance of Xorg or Wayland. There are hacks to split it by overlaying nested servers onto the one that owns the chip, but they have awful video performance (I tried it).

So you do need the multiple video cards (and slots to put them into). One per user. And even more idle power consumption. But the 124W that the machine now sucks down 24/7 is sort of justifiable in that it serves the whole family's browsing/computing needs aside from a few smartphone type gadgets. And the setup is physically robust, in a household with small children, in a way that laptops just aren't.

Cheap 7m HDMI cables and active USB extension cables (from Ali Express) take care of the physical separation between stations.

Sound is easy as long as you get it over HDMI - no need to configure a separate device, it comes with the video. But one of the stations owns the physical audio sockets on the motherboard, and one, for reasons too complicated to get into here, uses network audio over another Lennart special -Pulseaudio. That has its own frustrations, but the remote audio, once I got it working, has been solid.

Thanks for the detailed reply!

Also, are you using wired networking for remote audio? Last time I tried PulseAudio remote audio over wifi it instantly made wifi useless for everyone in the house. (Honestly I wouldn't mind mildly lossy compression, but there doesn't seem to be support for that.)

Wired, of course. Though I did accidentally configure the sending instance of PA to send multicast pakcets. Which it did, with abandon, even when no audio was playing, saturating the wifi to such an extent that I was driven to despair before I figured it out. Consumer grade Wifi gear, even if loaded with, say, OpenWRT, does not handle overload gracefully. PA configuration is a confusing mix of config files and GUI stuff.

> In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense?

No need for personal attacks.

I note that you opted to ridicule instead of answering, which I find unnecessary.

Use all the time for hobby website. It’s through Pair.com. BSD though, not Linux. It’s very inexpensive and a lot cheaper and easier than me setting up and maintaining a whole virtual box.

Plenty of places still have homes on NFS shared amongst all their machines. It is very handy. It means you can use any computers and still have all your files.

The fact that you are unfamiliar with a use case doesn't mean it doesn't exist.

> Plenty of places still have homes on NFS shared amongst all their machines.

Oh, I agree! That's my point. So what is systemd trying to solve?

Bay area large (not huge) corp dev here.

We do. We have like a dozen shared, beefy shell servers (varies, but think ~32 core not too old Xeon, ~256GB RAM, 1G or 10G stable network that's local to the office, TB's of storage and essentially unlimited on NFS) for devs (and more of the same dedicated for CI/CD).

We need this because the codebases are huge and take hours to build on a laptop (and copying across a home uplink would take forever too).

Homedirs are NFS mounted.

It's more cost efficient than spinning up an AWS/Azure instance for myself, and more limited resource efficient than spinning up a VM in OpenStack (both of which I do when appropriate). And it's very convenient team work wise.

There are (many, some avoidable but hard to fix by now) downsides for sure, but I cannot imagine doing this work solely on a laptop.

At least one huge Bay Area elephant used to run NFS home dirs for basically all their corp.

So do you run fscrypt or LUKS with that?

Because NFS was already possible, so what is systemd trying to solve?

encrypted home directories?

Is that a question? I think you missed the point on this one.

> > Does it actually solve a problem?

> encrypted home directories?

This is something that isn't widely available on personal systems that would be supported by this change.

I should note I think the idea of systemd is valid, but I am not a fan of the implementation. (binary log files? disorganized configuration directories?)

All my workstations/laptops (at home and at work) have encrypted root filesystem, which includes /home.

So… this has not been a problem for 99%+ of users for like 20 years.

I do like the idea of some parts of systemd. Like structured logging. I'm so sick of every single tool having its own logging format. Some multi line, some not. Some using UTC, some not. Some making up their own BS date format, etc…

One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation.

Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.

Full disk encryption is the only reasonable solution and it already works with suspend

> Who actually has multi-user systems. Really has them.

systemd-homed isn't about multi-user systems, it's about multi-system users.

Goal #1: Migratable Home Directories (all the way to the point of "home-on-a-stick") https://cfp.all-systems-go.io/media/homed-asg2019.pdf

I want to take my home with me across all my systems, and /don't/ want network sync to do it with.

I really hope this gets nicely abstracted away into a NixOS module soon. I've been looking for a solution to securely suspend to RAM by clearing the LUKS keys and reopening the LUKS volume when resuming. It looks like systemd-homed will be the first viable option to accomplish that.

Interesting,

I don't really understand why distribution maintainers are allowing this one project to have so much control over the operating system.

There's a couple of possible reasons from the structure of your question:

1. The project really doesn't have that much control. Like packaging any other software, it adds a feature you can choose to install, but it does not affect the distro if you don't enable it.

2. The project generally comes up with good ideas, or at least better ideas than the shared consensus of historical UNIX practice, such that incorporating the product's changes is a sound technical decision.

In this case I suspect it's 1 - the article points out that it's optional.

> Like packaging any other software, it adds a feature you can choose to install, but it does not affect the distro if you don't enable it.

I didn't want systemd, and there wasn't really an option for me to 'disable' it. I switched distros, because that was vastly easier.

> The project generally comes up with good ideas, or at least better ideas than the shared consensus of historical UNIX practice

[citation needed]

> I didn't want systemd

I'm talking about this feature that is the subject of the article, not systemd in general.

> [citation needed]

I'm discussing possible reasons why a distro might choose to trust systemd. Perhaps I should have said, "The distro believes that...." Whether systemd does or does not do this is debatable, but it certainly seems possible, which is the entirety of my claim. (Also, I'm tentatively concluding that this is not the reason why distros are okay with this particular change.)

> Perhaps I should have said, "The distro believes that...."

I think so. As it stands, you are flat out stating that systemd produces better system design than UNIX - which is not only questionable of itself, but in blatant disregard of those who disagree with the systemd design philosophy.

Do you even know what UNIX is?

Even if I were making that claim (which is not what that comment said), there's no blatant disregard involved - the claim is not that systemd is good, but that it's better than UNIX, which is truly terrible.

I think the fact that all major distros have gone the direction of systemd is probably a good indicator that it makes sense to move there.

I’m sure the distro leads are smarter than I am, too.

They had no choice. After the udev fiasco running the Linux kernel without systemd becomes prohibitively complicated for many use cases. The main GUIs were similarly captured (e.g. with logind). You obviously can still run a Linux kernel based system without systemd but it is already hard and will get harder to run the larger userland components that other distros get “for free”.

If you don’t like systemd then the only sane option for you is to make the jump to FreeBSD.

Gentoo is looking at you disapprovingly .

I used gentoo without systemd for some time but things became problematic. Bluetooth headphones were barely functional, Firefox required pulse audio or sound didn’t work out of the box.

I’m not in love with systemd, personally. But it’s harder to live without it than with it.

People seem to forgot, but majority move to systemd was caused by GNOME not working on systems without it, while the API it depended on was made near impossible to implement outside of systemd (the docs were incomplete and incorrect, etc).

That was the tipping point for systemd adoption, caused by incestuous relationship between systemd, GNOME, and Fedora.

Because it makes their lives easier. Not only does systemd take on a lot of the work distributions used to do by theirselves, a lot of the features of how it works makes maintaining packages easier (e.g. the fact that you have 'system' unit files which can then be overridden or augmented by the admin as a seperate file).

I wonder the same thing about privacy: why are so many people willing to give up so much for so little.

I think the answer is the same: this is emergent behavior.

Nobody is in charge, so somebody does something in their own self-interest and the effects cascade widely.

Systemd adds a feature, few know about it, and it spreads via the normal release channels.

Same thing happens with telemetry. Docker has telemetry, ubuntu keeps screwing with it, etc.

Without the amount of changes systemd makes to the operation of a system, at this point it should be thought of as a new operating system that shares a kernel with Linux.

This is exactly what systemd sceptics have been shouting for years.

We're not there yet:

Every program attempts to expand until it can read mail. — Zawinski's Law

All that's missing is a gvfs module to mount your IMAP directories...

At this point you'd think systemd was trying to catch up with Emacs as the most 'everything but the kitchen sink' of all the software

From a UI perspective, this is brilliant. Windows had it with a shell extension that essentially turned Windows Explorer (not IE) into what would later be Outlook Express. It's awful that they opted out of making the desktop Explorer smarter and went the stand-alone application route.

Emacs went further. It absorbed systemd.

See systemE.

Sure, the .emacs script could be just as good an init as any.

I don’t have a problem with this. I am seeing systemd as a system management layer and as such it makes sense that it should manage as much of the moment-to-moment operation of the system as possible. It seems like a lot of people are upset because it’s a new thing to learn that’s being forced on them by their distro.

I used to feel the same way. I’m only a casual linux user and I didn’t want to climb this particular mountain but having learned just a little about it, created some of my own units and played with the tools the sense of alienation dissipated and I was fairly happy with it.

I suspect most of us are upset not at learning a new thing, but dealing with brand new bugs in new unexpected ways. Learning a new thing has never really been a problem -- fighting instability in new software has always been the issue.

Speaking as a distribution developer, I can say that systemd has bitten me in multiple ways due to upstream bugs that are either ignored or left to rot for quite a while. I've had to resort to patching them, or working around them, which makes things very difficult to live with, especially given the pace of systemd development and feature additions.

The older software had a number of bugs, yes, but they were well known and battle tested. In short, it's not "I don't want to learn" -- it's "the new shiny has a slew of unknown bugs we can't easily identify and fix".

[edit: removing bits of incendiary text]

Older software should always have fewer bugs simply due to maturity. Ie. progress isn't free. The best way to mitigate that is where distros like Debian stable come in. They help gate these developments, releasing more well tested versions of the software and fixing any critical issues that come up with it over the time of the release.

My distribution is based on Debian. Systemd is still a thorn.

Very much agree. I'd add that the reaction of the systemd developers to security and functionality bug reports has been...decidedly mixed, which is enough to make me very nervous.

For me personally, it's also that systemd keeps expanding and expanding, which both makes more things dependent on their security profile and reduces choice in the ecosystem. The number of different boot/init systems I might need to use is pretty limited and I might be OK with just one (especially since systemd /is/ really good at it). The number of DHCP clients, firewall systems, DNS clients, and so forth is decidedly not so limited, and results in a nasty choice of "use the systemd thing and hope it supports all the features you need" or "rip out the systemd thing and replace it and hope that works and continues to work" or "install something that sits on top of the systemd thing and thus has to interact with it in strange ways that may bite you unpredictably". Each of those is a recipe for a lot of Maalox moments, and it feels like the response to that concern is, "Aww, you're just being a worry-wart."

I recently migrated to FreeNAS/FreeBSD. It's joyfully oldschool sysadmining, and for hobbyists/home server owners, it's so much nicer.

For business vs systemd... you gotta keep your crew busy with change, right?

For business we want something that works. At my last three jobs in a row I've had problems that systemd has been solving in an elegant, robust way. (Eight years ago it was startup ordering bugs with Upstart in an appliance; four years ago it was cleaning up a pile of cronjobs and handling the ordering relationships between them; today it's cleaning up a single cronjob that starts a big supervisord.)

For home use, sure, there's a joy to making things work. Same as some people enjoy building a computer from parts - but you'll never see a business telling their employees to go to PCPartPicker and put something together.

> Upstart in an appliance

> single cronjob that starts a big supervisord

/me screams

Seriously, why? All of those you're listing are monsters, and they should never have existed in the first place.

Because real-world systems aren't as pretty as hobby systems.

I think this is going in the opposite direction of where I'd like to see Linux and UNIX home directories going, but it's still an interesting change.

Has anyone played with it any? I know it just got merged, but I figure one of you may have tried it prior to that, so I might as well ask.

I agree that this is not the direction that I want Linux to go. I object to systemd all by itself for the same reason, and it's why I'm moving from Linux to BSD.

I haven't played with this, though. I don't have a use case for it.

where do you like to see home directories going insead?

21k lines of new code added in systemd to maintain home directories?

What would happen if the daemon goes down or has security hole? Are users screwed?

Do not fret. Systemd crew does not make any mistakes.

Because we have control over our own computers, right?

Do I really need to mark an obvious sarcasm so that everybody can enjoy it?

Probably. I vouched for the comment.

Yes. I have already set up a VM for a friend where the root user could login but regular users could not.

Took some research and at least an hour of my time... something was not set up in the user slice configuration for systemd's liking.

I seem to recall this is incompatible with cronjobs, which puts it pretty far to the the game console end of the tool spectrum.

Pretty sure it also breaks ssh logins. This needs more discussion before blessing it. Systemd has bled far, far, beyond an init replacement.

> Systemd has bled far, far, beyond an init replacement.

This has been my main objection to it: feature creep (with tight coupling between 'components').

You can store SSH keys in the user records.

systemd was never just an init replacement, it's a project that includes an init replacement.

Don't worry about SSH, just wait for the systemd replacement for SSH.

Please elaborate because that sounds odd to me. How on earth can a home directory manager mess with another daemon? I use winbind's associated PAM NSS module to run up a home dir as needed for my AD joined Linux machines. cron still works.

I don't do games consoles, only business systems.

Easy: crontabs are in /var/spool/cron/..., not /home, and user editable. If the user's homedir isn't mounted because they logged off and cleared their security tokens, any crontab they write that uses their homedir will break.

The same way pulseaudio stops playing when the screen locks. Most annyoing behaviour I've ever had.

That's a reasonable default behaviour, can you change it though?

I'm not sure if your comment is accurate or not, but systemd timers have existed for a while now, and provide some flexibility cron doesn't.

They had better provide flexibility for all the complexity and tedium they introduce. It takes creating two new config files of about 10 lines each and a long system command to set up the simplest possible systemd timer.

Yep, I wanted to create a systemd timer to run my nightly backups.

I was pretty shocked that I needed to have three files. My backup script, a systemd service to call the backup script, and a systemd timer to call my systemd service that calls my backup script.

It took A LOT of fiddling and reading the Arch wiki before I had everything working as I wanted it to.

I have also set up timers in Arch, and it wasn't that bad...

Really? How did you do it then?

https://wiki.archlinux.org/index.php/Systemd/Timers

You can also find more documentation on the official systemd website, or Gentoo, CoreOS, and RedHat's website.

As an example: https://wiki.gentoo.org/wiki/Systemd#Timer_services

I'm confused, unless I'm missing something, both of those pages seem to describe exactly the process mbreedlove described:

    1) create systemd service to call your script
    2) create a systemd timer to call that service

What did you do differently?

I didn't say I did anything different, I said it wasn't that difficult.

Systemd-homed isn't inventing the idea of encrypted home partitions and fundamentally, what you're saying is that cron is incompatible with encrypted home partitions (or any other auto mounted home partition, ex: network mounted). The same is true for the concerns about ssh.

If you listened to the original talk from Lennart, you're really just giving examples of one of his major points. Because /etc/passwd wasnt flexible enough to accomodate arbitrary user properties, user configuration has organically spread out over time into all these "side car" configuration files. Some are scattered around /etc so not easily portable while others are in the user's home directory and suffer from exactly the scenario you've mentioned. One of the goals of systemd-homed is to add a portable, extensible format for a user record external to the home directory which would mean that systemd-homed rather than causing, could actually lead to a solution for the issue you've highlighted.

I'd much rather see easily portable desktop environments configs e.g. in KDE and xfce

How would that work?

I was thinking of a tool that would list GUI and integrated apps (maybe with a bunch of advanced options), you'd select which of those you'd like to backup and would give you an option to save a file which you'd then be able to import on another machine. It'd only dump non machine specific settings into the file.

But in order to do this there should be some kind of a standard so that pretty much any app could integrate into such tool if it listed allowed settings and its locations.

Can systemd dynamically load new kernels at this point?

kexec has existed for ages...

Systemd can launch an Emacs session, so...

Reply on news.ycombinator.com