
Reinventing Home Directories - Schiphol
https://media.ccc.de/v/ASG2019-164-reinventing-home-directories
======
dijit
Full Disclosure: I am violently opposed to systemd and pulseaudio (before it
was taken away from Poettering).

However, I think I'm seeing a pattern, Poettering identifies real issues and
actually tries to fix them.

But it seems like his ambition is impeding his ability to consider those who
do not want to approach the fix his way. It's never a measured approach, it
/feels/ like a "lets write it now and figure out all the problems down the
line and fix them" which, for core pieces of software is a dangerous mindset.

After watching the intro here I agree with him, the current state of things is
not ideal, and nobody _wants_ to touch user account management on Linux. On
MacOS for example, it's much more thought out, and I think Linux could do it
better.

As much as I hate poetterings specific approaches (and, subsequent lockout) I
have to give credit to him identifying these issues and actually trying to fix
them, it's more than I do. Then again I am a lowly sysadmin type.

~~~
teekert
I like the tone of your comment, unlike many others here. But to your remark:

"But it seems like his ambition is impeding his ability to consider those who
do not want to approach the fix his way. It's never a measured approach, it
/feels/ like a "lets write it now and figure out all the problems down the
line and fix them" which, for core pieces of software is a dangerous mindset."

I'd like to say that he forces nobody and so we should not complain about his
creative endeavors. The market will decide, and you, will decide.

~~~
dijit
I disagree, you can argue the semantics of if it's him specifically or if it's
another project that decides it will only target systemd/pulseaudio. But the
fact that if I want a stable distro for server usage in 2019 I _must_ use a
systemd distro speaks to the fact that I am indeed forced to use it.

Maybe that's just adoption though, typically the sysadmin community considers
the "safe" options to be CentOS/RHEL or Debian Stable. Both of which default
to systemd. (and no sysadmin is going to change the init system on production
servers unless it presents some abject nightmare, short of eating 30%
CPU/Mem-- it's core software, it wont be touched).

Projects like Devuan are simply not considered safe choices by the majority of
the sysadmin community, and there's no alternative for RHEL-esque sites.

So, semantically: it's not poetterings fault. But at the same time, I'm still
forced.

~~~
massysett
You can use a BSD or Slackware.

~~~
bscphil
Or Alpine Linux. I believe it's already one of the best-regarded distributions
for the container space, and it uses OpenRC, not systemd.

~~~
hollerith
OK, but aren't most Alpine instances running in containers hosted by Linux
instances using systemd?

~~~
yjftsjthsd-h
That doesn't mean it doesn't work fine as the base layer. I run Alpine on bare
metal... actually, I really like Alpine as the thing that hosts KVM and/or
Docker, too.

------
bscphil
I haven't yet watched the video, but I'm pretty familiar with the concept from
previous links, and I had the following thought about the controversy this
project will probably create.

Personally I've been consistently happy with Poettering's projects, especially
PulseAudio and systemd. Systemd is just an infinitely better way of handling
init and service configuration than anything else _I 've_ used on Linux (the
weird amalgam of systemd and other service configuration tools you find on a
lot of distributions these days strikes me as a particular abomination that
hides how nice a cleanly configured systemd setup can be). I would be happy to
use a Linux system designed entirely by LP (the infamous systemd/Linux); it
would probably be a lot better designed than what we have now. (I'm not really
familiar with what the BSDs are doing these days, so I can't comment on them.)

My one complaint, which I think is behind many of the criticisms of systemd,
is that I don't see why it needs to be so tightly integrated. I would prefer
to see many of the projects under the systemd umbrella (Wikipedia describes
systemd as a "software suite", which is telling) broken apart into individual
programs that can be run entirely independently. Network management, logging,
and container management seem like they could all be separate projects. This
new one probably should be too. I get the nagging feeling that if Poettering
created PulseAudio today, it would be systemd-audio, and therefore wouldn't be
as useful to Linux users universally as PA is.

~~~
icebraining
What did you use besides systemd and sysv? Personally, while I'm ok with
systemd, I think Upstart was a decent replacement for the pile of scripts of
yore, and gained little from the switch from it to systemd (we used Ubuntu
Server where I worked).

~~~
bscphil
I used Upstart, and I briefly tested systems with OpenRC. I wasn't really
happy with the configuration tools or the service file format with Upstart,
and actually Ubuntu's attempt to do a kind of hybrid between a traditional
SysV init and Upstart, and now a hybrid with systemd (the "service" command
somehow still exists on Ubuntu!) was one target of my ire in the comment.

------
Jonnax
Just copied the following from the slides.

It all seems reasonable to me. Linux home directories are a bit of a mess and
unportable.

Can someone explain to me the hate for systemd other than: "It's trying to do
too much" "I hate Poettering" "I prefer things to stay the same, that's why I
use a ThinkPad from 2008"

 _These are their identified problems:_

    
    
      Needs writable /etc + Mixes State and Con guration
    
      UID assignments need to be propagated between systems
    
      No encryption (Or \mismatching" encryption)
    
      No modern authentication mechanisms
    
      Not extensible; plenty \Sidecar" databases (/etc/shadow,

accounts-daemon, samba, SSH, pam limits)

    
    
      No resource management
    

_These are their stated goals:_

    
    
      Migratable Home Directories (all the way to the point of

\home-on-a-stick")

    
    
      Self Contained Home Directories (i.e. mere existance of a  le

/home/foobar.home synthesizes a user foobar)

    
    
      UID assignments as local artifact
    
      Unification of User Password and Encryption Key
    
      Extensible User Records
    
      Lock LUKS on System Suspend
    
      Yubikeys, from day #1
    

"Complications:*

    
    
      SSH Logins
    
      Disk Space Assignments
    
      UID Assignments (chown() on login)
    
      LUKS Locking
    

_They have two solutions:_

Concept A: JSON User Records

(Superset of NSS records: struct passwd + struct group)

Queriable via Varlink interface

Convertible forth and back (lossy though, necessarily)

Concept B Encrypted LUKS Home Directories in Loopback Files

(/home/foobar.home with JSON records in ~/.identity)

Managed by systemd-homed.service

Concept A may be used without Concept B though

~~~
Smithalicious
> Can someone explain to me the hate for systemd other than: "It's trying to
> do too much" "I hate Poettering" "I prefer things to stay the same, that's
> why I use a ThinkPad from 2008"

These are all perfectly valid reasons, you can't just hand-wave them away. The
way you phrase them makes them semi-strawmen but they're just the equivalent
of conventional wisdom: "do one thing well", "don't put all your eggs in one
basket" and "don't fix what isn't broken".

And also, my ThinkPad is from 2012, thank you very much.

~~~
majewsky
Just to be clear, "I hate Poettering" is a perfectly valid reason, and not at
all ad hominem?

~~~
Smithalicious
"I hate Poettering" is an ad hominem, but also a strawman. It's perfectly
legitimate to not trust Poettering, or anyone else for that matter, to have
such an individual influence over the entire FOSS ecosystem.

------
ktpsns
Slides: [https://cfp.all-systems-go.io/media/homed-
asg2019.pdf](https://cfp.all-systems-go.io/media/homed-asg2019.pdf)

Conference website: [https://all-systems-go.io/](https://all-systems-go.io/)
(September 20-22, 2019)

------
cbhl
I like the idea of logging in with a Yubikey, but this presentation seems out
of touch with the requirements of the real world: folks needing to SSH into
cloud machines without logging in to a physical console first; IT departments
that need to reset a forgotten password or decrypt a hard drive for compliance
reasons; people who have multiple Yubikeys; people who change passwords and
don't want to spend hours re-keying the encryption on their USB key.

~~~
lorenzhs
He starts the talk with something along the lines of: this is what I want for
my laptop, not servers. It's explicitly meant for personal machines, not cloud
machines. There is no reason why those should have to change, they're served
pretty well by account management as it is today. Laptops are not, and he's
trying to fix that.

And by the way, LUKS has multiple authentication slots (you can have multiple
passwords for the same volume, for example a long random password that the IT
department keeps in a safe place if they ever need to access the volume) and
it takes a second to re-key, not hours. This is all well-known. But Poettering
brings out the worst knee-jerk reactions in people.

~~~
johannes1234321
While for a laptop many of those problems he describes are non issues. I.e.
configuration via LDAP doesn't happen on a laptop.

That said: Integration with encryption and so on is definitely good. So maybe
this goes too far in some direction, but too little I. The other?

~~~
lorenzhs
Enterprise-managed laptops need this just as much as my personal machine, they
are woefully underserved by current user management.

~~~
jacquesm
Enterprise managed laptops typically run Windows or OS/X. I haven't seen a
Linux laptop in the wild at the enterprise level for years. Which companies
use those?

~~~
diffeomorphism
> Enterprise managed laptops typically run Windows or OS/X. I haven't seen a
> Linux laptop in the wild at the enterprise level for years.

Chicken-egg. If you don't have appropriate management features (like the ones
introduced here), then you don't get enterprise deployments.

~~~
jacquesm
That's RedHat's wishful thinking at work. Linux on the desktop is called
'Chromebooks', not 'RedHat'. They missed that boat by a couple of years and it
is not coming back.

~~~
diffeomorphism
So which is it?

\- This is going to be so awesome that "everybody and their brother can't stop
themselves from tripping over their own feet to adopt".

or

\- Wishful thinking, doesn't matter.

~~~
jacquesm
Package managers and distro maintainers are not typically the end-users I have
in mind.

But if you can't see these groups as different then that's fine, but lets just
leave it at that I, an end user was forced to adopt a set of system changes
that I had no influence over because of RedHat's continued aspiration to put
'Linux on the desktop' when that had in fact happened ages ago.

That you feel that adoption only happens because something is 'so awesome' is
putting the horse behind the cart, stuff gets adopted all the time when better
alternatives are available, all it takes is enough clout behind the push and
it's a done deal.

If technical merits were the deciding factor DR-Dos and OS/2 would still be
around today instead of their lesser alternatives.

~~~
jraph
So, basically, people who maintain the system you use have made decisions on
its evolution that you don't like. Keeping the system as it is would have been
another, arguable, possibility, not the obvious thing to do.

I can't see any solution to this problem for you apart from another system
emerging with features you like (maybe from a fork). Which is not trivial.

------
rswail
The interesting thing here for me (aside from the actual ideas about home
directories) was varlink. Is this the new D-Bus?

It looks like yet another IDL and server/client. Aside from being JSON etc,
what are the advantages of gRPC/protobuf, or even ONC RPC and XDR?

Oh and full disclosure: I actually like the various systemd utilities and
functions. Things like the resolver replacement can be a pain when you want to
do weird split horizon and other things, or for bastions of VPNs, but as
systemd has "settled" it compares reasonably well to Sun and Apple's
equivalents.

------
westurner
Perhaps ironically, here's a link to the presentation PDF that was posted
yesterday:
[https://news.ycombinator.com/item?id=21036020](https://news.ycombinator.com/item?id=21036020)

And my comments there:

> _What a good idea._

> _Here 's the hyperlinkified link to the {systemd-homed.service, systemd-
> userdbd.service, homectl, userdbctl} sources from the PDF:
> [https://github.com/poettering/systemd/tree/homed](https://github.com/poettering/systemd/tree/homed)
> _

> _Hadn 't heard of varlink: [https://varlink.org/](https://varlink.org/) _

> _Is there a FIPS-like subset of the most-widely-available LUKS configs?
> Otherwise home directories won 't work on systems that have a limited set of
> LUKS modules. _

------
ComodoHacker
Slightly off-topic, but why WebM video is larger than MP4? Isn't WebM standard
more efficient?

~~~
bscphil
WebM and MP4 are containers, not video codecs. You can't assume anything about
the efficiency of the video just by knowing the container. In this case, the
WebM files contain video encoded with the VP8 codec, which in my opinion is
significantly less transparent at the same bitrate than the h264 codec that
the MP4 file contains.

But it's more likely that whoever encoded these files did so without trying to
hit specific transparency targets, so you shouldn't really conclude anything
from the file size.

------
jacquesm
Change for change's sake is the worst possible reason for change. All this
systemd stuff can jump off a cliff as far as I'm concerned. The main reason
why I chose for Linux on my desktop and laptop machines is because I like the
stability of the platform, the lack of non-sensical change and the fact that
it makes it much easier to switch between desktop and server environments.

Not that I want my servers to be more like my desktop, but the other way
around.

Where Poetering & Co. get it completely wrong - just speaking for myself here
- is that the lack of change in the Linux world to me is a good thing. It
means that any investment in time will pay back over many years.

~~~
diffeomorphism
> Change for change's sake is the worst possible reason for change

Which is not the case here. The slides outline what is currently lacking and
why and how improvements are needed. Admittedly this seems more driven by
enterprise needs (LDAP, encryption, yubikey support etc.). You can rightfully
criticize the systemd project for many thinks, but "change for change's sake"
is definitely not among them.

> Not that I want my servers to be more like my desktop, but the other way
> around.

In which way are managed, scriptable home directories not more like servers?

~~~
jacquesm
Yes, you can always come up with a bunch of mumbo-jumbo to justify that which
you wanted to do anyway. That's how the whole systemd madness got going and it
will continue until all of the system has been consumed.

Take pulseaudio as a nice example: works for 95% of the trival cases, fails
for 100% of the more complex cases. The more Linux is dumbed down the harder
it gets to do real work.

A desktop on top of a powerful multi-user system is far more capable than a
trimmed down Unix under a slick, single person UI. We already had that, it's
called Mac OS/X and those who want it have had that option since forever.

~~~
icebraining
I don't see how PA is "trimmed down" or "dumbed down". From what I can tell,
it provides quite a few more features than ALSA+dmix, which was the solution
typically used previously. For example, I can now route the output of mpv to
HDMI so someone can watch a movie, while I route other applications to my
bluetooth headphones. Was this possible with ALSA?

~~~
jacquesm
> Was this possible with ALSA?

Sure, but truth be told ALSA required a bit of knowledge to set up properly.
But instead of re-doing the whole audio system from the ground up and tossing
away the good with the bad it could have been done just as well by making a
proper ALSA auto-configurator. No need for all this re-invention in more buggy
ways.

Besides that, when PA came out you couldn't do any of that either, it was
barely usable and the most frequent PA related activity was 'uninstall'.

~~~
icebraining
>> Was this possible with ALSA?

> Sure

Fair enough. I did look and I couldn't find any way to set up independent
outputs from different inputs. In any case, I still don't see the dumbing
down.

> Besides that, when PA came out you couldn't do any of that either, it was
> barely usable and the most frequent PA related activity was 'uninstall'.

Most FOSS software is released to the public at a very early stage. The
problem is trigger-happy distros including it by default too soon, but that's
not PA's team fault.

~~~
jacquesm
If the 'trigger happy' distro happens to have a billion dollar company behind
it then you can forget about packages competing on merit.

------
ageofwant
One thing that will need to be fixed is the ssh access that his current scheme
does not allow. I cannot see how I should be logged into my machine on another
continent before I can log into it again. Paradoxically this would mean moving
the ssh keys, or equivalent, out of $HOME, which is the opposite of what he
wants.

~~~
magicalhippo
Indeed. This seems like a very severe limitation. If the computer gets
rebooted, either due to updates or power-loss, you effectively lose access to
the machine until you can get to it physically.

So for me, his solution only works for computers for which you want casual SSH
access to. Which would be the minority of my computers.

~~~
knocte
Workstations, not servers.

~~~
magicalhippo
I routinely log on to my work computer remotely. I couldn't use a system which
denied me that just because the computer rebooted for whatever reason.

------
pnako

      Microsoft: Embrace, Extend, Extinguish
      Lennart: Reject, Rewrite, Extend, Extend, Extend

------
moonbug
oh great, Lennart's here to help again.

~~~
teekert
Seems like his last 2 projects were pretty successful. What was your last
contribution that was taken up at such scale?

~~~
effie
What is the point of such a question? Writing software that is successful in
the sense it gets major adoption is not necessarily desired by power users. On
the contrary, we have a well known example in systemd. That's why you see
sarcasm here, people are afraid of what is yet to come.

If the "successful software" is causing you only problems and upon inspection,
you discover it is restricting your computing, you're likely to worry about
next project of the author.

------
dschuetz
This systemd train has to stop. Why isn't Poettering just forking the Linux
kernel for his very own systemd-OS distribution? If any of the Linux
distributions I'm using touches the home directory because of Poettering's
say-so in that video I'll cease using and supporting them.

~~~
teekert
Isn't anyone free do make what they want and see if the market takes it up?
Anyway, this week's Linux Action News [0] has a nice breakdown of the
features, I think it is better to discuss the merit and downsides of this that
to just shouting: "Stop the systemd, pulse-audio, any-new-feature-that-scares-
unix-natives -train."

[0] [https://linuxactionnews.com/](https://linuxactionnews.com/)

~~~
dschuetz
No. Because this nonsense will break my systems.

What is this? Some crazy guy makes significant changes to a standard, the
distribution maintainers will just gobble it up (as per usual) and then I have
to weigh the pros and cons instead of complaining and fixing/adapting my
systems e.g. wasting time because of a crazy guy's ideas?

There is no _market_ in OSS. It's either use it or leave it. But even in OSS
there are established standards which are relied upon! Poettering doesn't care
about that, because he likes change.

~~~
fhennig
If systemd-adoption would make it harder to maintain a distro, the distros
would not have adopted it.

Instead, systemd solves a lot of problems for distro maintainers. The didn't
just "gobble it up", they made a very measured choice to adopt it.

~~~
AstralStorm
Now what were those problems, specifically, for distros, that weren't caused
by systemd eating and replacing previous solutions, which suddenly became
unmaintained and unsupported?

(I'm looking especially at udev and all the dbus hookery.)

