And they might actually achieve this there, since SSSD is another abomination that kinda does that and mostly works, but once it doesn't and you try to debug it, you want to stab yourself in the brain with a dumb object.
For any other distro, I very much hope this thing is not enabled or even installed by default. Since I don't get the complaints about ecryptfs. I've been using it since around 2012 on multiple machines, multiple dist-upgrades and password changes and it never failed me once. Oh and SSHing into the machine works as expected!
This was impossible to debug. You could send some signal (USR1 or 2 iirc) to sssd to force it into online mode, we even tried a crude script that would run after system resume and spam sssd with that signal for a minute to no avail. Shortly after I left that department the decision was made to move to Centrify. It's a pita in other ways apparently, but everything I know about it is just from hearsay from old colleagues aynways.
As you eluded to, the problems this is trying to solve include better integration/less rough edges with enterprise authentication (AD and the like), encrypting home directories, and making home directories and user accounts more portable. Anyone that does desktop fleet management will find a lot of stuff to be excited about here.
What do you do if you've left files on your desktop at home/work and need them from work/home?
Im personally curious to see how this works with a tool like Syncthing
Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse?
As far as USB goes-- can you suggest a currently manufactured _good_ usb storage device? I've found myself scrounging for old ones because anything currently made are unreliable, slow (in spite of amazing performance claims), or usually both.
This doesn't really make sense as a response to comment mentioning Syncthing which works with any backend, including your other machines.
> What's systemd's excuse?
Systemd's excuse for what exactly?
Who do you think is putting the resources (manhours/money/etc) into mainlining this crap into Linux? It's the corps. Add Intel to the list.
For now. Until GNOME pulls it in as a dependency.
And also, this is just the default, the mechanism is general, how to do this unlocking can be done in many ways by other people who want to use these tools.
Is this really so common as to deserved two questions marks and an exclamation point? As one datapoint, if I've left files on my desktop at home that I need from work, I get fired.
Is it what most "normal people" do? Of course not! Most normal people buy a spyware 'smart TV', roku, or some other proprietary appliance. So why the hell should the common habits of the general population be considered? If their habits are to be the guiding principle of the linux desktop, I'll soon have no reason to use the linux desktop.
Incidentally at one of my former (FANG) workplaces, each developer was given a RHEL workstation and a windows or mac laptop. Using ssh from one's laptop to access the workstation while in meetings, working from home (including oncall in the middle of the night), etc was common and permitted. This is not as crazy as you seem to think.
https://www.freedesktop.org/software/systemd/man/homectl.htm...
> Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token.
Key hierarchy management can probably be delegated to an external system.
In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).
What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts?
Doing a ^F I find no mention in the man page of either LDAP or Kerberos.
We already sorta have this now. What I'm (half-jokingly) suggesting is a big ugly fork a la Emacs/XEmacs, where the world visibly and somewhat incompatibly separates.
And like that fork we'll end up with everything more-or-less reconciling eventually, but it's going a weird ride until then.
BTW, among other problems that the plan 9 paradigm alreay solved, I'm pretty sure they solved the security issues that Wayland was intended to solve, and from what I understand, I'm pretty sure they did a better job, too.
My religious view, having started since the Slackware on CD days with original rc and experienced upstart, launchd, openrc, daemontools, runit, daemontools-encore and s6 is: SystemD does too much, has too many dependencies, does it awkwardly and is unfriendly to configuration management, robustness, troubleshooting, "least surprise" principle and simplicity.
If I were Debian devs, there are two choices to init-agnosticism: a) pick one init provider at a time or b) manage multiple init systems simultaneously. For the latter, a very simple meta-init process could either exec() the only init system if one is used or supervise 2+ init systems. Then, there would need to be a tool to manage the lifecycle of a service no matter which init system it belonged to.
It might be easier to pick a), but a common use-case is to use daemontools for custom or other services that need to be kept running. Granted, there are probably packages that already run daemontools, runit or daemontools-encore as a child under the existing system init.
It's times like these that I wish there were a capabilities-oriented standard file layout such that every service knew how to start, soft-stop, hard-stop, enable, disable, reload-config and validate-config itself rather than every N init system having to find magic command-line args to not spawn in the background, change the user/group and change the log level, ports, bound address(es) and log destination. And then Cfengine, augeas, puppet, chef, salt, etc. reimplemented all of that logic per service. Services should also know how to backup/restore/wipe their own data (if not a 12Factor service themselves), whether they're up/down and how to gather their own metrics... and then cacti, nagios, nrpe and so on implemented all of that sort of logic per service too. sigh Cross-cutting concerns should be managed at the place that knows best how to manage the data and process lifecycle best: per service. Then, once that's done in a standard way, /etc configuration and configuration management can customize away. Having each service become enumerable and discoverable like a Bluetooth profile is another matter.
Experimenting with FreeBSD has been a breath of fresh air. Things I've come to expect to take an extended amount of time figuring out just work out of the box.
Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.
The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
Of course not. But I do want to have the nohup software they have running to keep running when they log out.
> The whole point is for the administrators to be able to avoid users running long-running processes on shared systems (e.g. university systems).
Right, which is why it should be possible to do this. The issue is that the default behavior has changed from honoring nohup to not honoring nohup. Defaulting to honoring nohup is what's expected, and is reasonable.
Yet, all the things he mentioned, like, remotely accessing a locked laptop via ssh, or maintaining a external user database for a cluster of machines in LDAP, are things I do on a regular basis.
He also mentioned something about requiring a privileged daemon to change your ssh keys? Is there any more information about that?
Given the gravity of systemd, and all it's ancillary services, how long till this is the one true way? How does this work in the case of true remotely accessible multi-user systems?