Debian considering going systemd init only

golinux · 2020-02-04 18:12:40

Head_on_a_Stick wrote:

I'm genuinely curious as to why an optional added feature for an init system you don't even use elicits "blistering condemnation". It's quite bizarre.

pulseaudio also used to be "optional". 'nuf said.

Head_on_a_Stick · 2020-02-04 18:26:12

golinux wrote:

pulseaudio also used to be "optional".

It still is

steelpillow · 2020-02-04 18:57:11

Head_on_a_Stick wrote:

I'm genuinely curious as to why an optional added feature for an init system you don't even use elicits "blistering condemnation". It's quite bizarre.

Follow the link to the discussion?

Last edited by steelpillow (2020-02-04 18:57:50)

Head_on_a_Stick · 2020-02-04 19:13:05

Do you not have a tl;dr? Or perhaps an opinion of your own?

I tried reading some of the thread but it just seems to be clueless idiots venting their spleen about things they can't control and don't understand.

steelpillow · 2020-02-04 20:01:29

Head_on_a_Stick wrote:

Do you not have a tl;dr? Or perhaps an opinion of your own?
I tried reading some of the thread but it just seems to be clueless idiots venting their spleen about things they can't control and don't understand.

Ah yes, you get a lot of that there. But you also get experienced sysadmins telling it like it really is.

tl:dr then (and I cannot vouch for the correctness of all accusations, or the completeness of the list):
1. the number of users with their whole life on a USB stick, multiple Linux laptops and no further portability requirement is basically the number of homed developers.
2. "optional" in systemd speak means "to be baked in before you can say 'Poettering'".
3. similarly, "disabled by default" means "to be enabled by default next time you blink".
4. it is odiously insecure, exposing more vulns than it fixes.
5. ssh login credentials are so secure that you cannot log in to access your login credentials.
6. mixing home directories into system init is barking insanity, even on a personal laptop.
7. the whole thing is a Microsoft/IBM/Lizard plot to commercialise FLOSS.

Without going into detail, I buy some of that but not all of it.
IMHO systemd does some good things but more bad things but, far worse than that, its developer community have utterly failed to earn my trust. I fully expect homed to expand its scope over time until it rolls Debian over and tickles its tummy yet again. I also fully expect somebody sane to fork/clone/copy the good bits and do one thing at a time but do it well.

Last edited by steelpillow (2020-02-04 20:02:32)

Head_on_a_Stick · 2020-02-04 20:04:11

Thanks, appreciate you taking the time to share that.

But it is optional (because it won't work for anything except laptops) and it does solve a genuine problem (suspend & resume for encrypted laptops).

steelpillow · 2020-02-04 20:07:59

Head_on_a_Stick wrote:

But it is optional

for now

because it won't work for anything except laptops

yet

and it does solve a genuine problem (suspend & resume for encrypted laptops).

do you really need to roll that into the init ecology? [I ask as a reasonably genuine ignoramus]

Last edited by steelpillow (2020-02-04 20:09:19)

Head_on_a_Stick · 2020-02-05 17:20:58

steelpillow wrote:

Head_on_a_Stick wrote:
But it is optional
for now

Well systemd provides *many* optional features: networkd, resolved, timesyncd, bootd, nspawn, etc. No sign of any of them being made compulsory. In fact Fedora's very own Core version has recently dropped systemd-networkd as it's default networking tool.

Can you name any previously optional tools that have been made compulsory?

I can mask any services I don't want in buster and so prevent them from being started even by other services but I can't do that with sysvinit (or OpenRC or runit or s6) so it's pretty flexible in that respect.

steelpillow wrote:

because it won't work for anything except laptops
yet

How would systemd-homed be implemented on a server? Or even make any sense?

steelpillow wrote:

and it does solve a genuine problem (suspend & resume for encrypted laptops).
do you really need to roll that into the init ecology?

I suppose not but why is it such a problem that the systemd developers are attempting to provide a unified set of user space tools that are consistent across many distributions? That seems like a good thing to me. But perhaps I'm not using enough tin foil...

steelpillow · 2020-02-05 18:08:34

Head_on_a_Stick wrote:

Can you name any previously optional tools that have been made compulsory?

systemd
Seriously, you tell me why the good Devuan devs have so much work on their plates leveraging the "option" not to use systemd-based tools?

Head_on_a_Stick wrote:

How would systemd-homed be implemented on a server? Or even make any sense?

Not all clients are laptops, you don't need to go to servers to expand its scope.
But then again, the ability to plug your personal toolset into whatever server you are administering must seem a nice idea to some. Most servers I ever met ran desktops, remote or otherwise, for their admins.

Head_on_a_Stick wrote:

why is it such a problem that the systemd developers are attempting to provide a unified set of user space tools that are consistent across many distributions? That seems like a good thing to me. But perhaps I'm not using enough tin foil...

Nothing wrong with a compatible set of tools, but there is everything wrong with bundling user toolsets into system init space.

Not enough tinfoil perhaps, but more to the point, why come and troll a community created expressly to expunge it all from our lives? If you want to abandon the "do one thing but do it well" philosophy of *nix, then why not go the whole hog and abandon *nix?

Last edited by steelpillow (2020-02-05 18:46:54)

Head_on_a_Stick · 2020-02-05 18:29:37

steelpillow wrote:

why come and troll a community created expressly to expunge it all from our lives?

I'm bored.

steelpillow · 2020-02-05 18:49:58

Head_on_a_Stick wrote:

steelpillow wrote:
why come and troll a community created expressly to expunge it all from our lives?
I'm bored.

I have to admit, that is the most convincing argument I ever heard from a systemd advocate.

Head_on_a_Stick · 2020-02-05 18:54:53

Just for the record, I'm not an advocate. I find the enormous code base and memory usage of systemd objectionable. But I do like some of the features. For me systemd is a bit like cheesecake: I like the taste but I know it's bad for me

ChuangTzu · 2020-02-05 21:48:40

steelpillow wrote:

Head_on_a_Stick wrote:
steelpillow wrote:
why come and troll a community created expressly to expunge it all from our lives?
I'm bored.
I have to admit, that is the most convincing argument I ever heard from a systemd advocate.

steel, let me introduce HOAS, if you read their signature all will be made clear to you. They have a history/track record on other fora as well of similar "behavior".

steelpillow · 2020-02-06 05:33:07

ChuangTzu wrote:

let me introduce HOAS, if you read their signature all will be made clear to you. They have a history/track record on other fora as well of similar "behavior".

That does not surprise me. Still, anybody who has a Life glider for an avatar and suffers anomie at the foibles of the human condition is all right by me.

ToxicExMachina · 2020-02-10 08:45:10

Head_on_a_Stick wrote:

steelpillow wrote:
Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release
You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.
[1] Like most of systemd's tools.

Don't call those features optional. They are pure EEE. SystemD is not GNU/Linux - it's svchost.exe. Home directories in svchost.exe-like service is the greatest insanity achieved recently.

Last edited by ToxicExMachina (2020-02-10 08:45:25)

ToxicExMachina · 2020-02-10 08:52:11

Head_on_a_Stick wrote:

Just for the record, I'm not an advocate. I find the enormous code base and memory usage of systemd objectionable. But I do like some of the features. For me systemd is a bit like cheesecake: I like the taste but I know it's bad for me

All of useful features from SystemD can be implemented with a standard tool set accessible in GNU/Linux OS. Moreover: they were implemented many times before SystemD was developed. If nobody made features like "portable home directories" then such features are obvious and already exist or they aren't demanded.

HevyDevy · 2020-02-10 12:43:20

ToxicExMachina wrote:

Head_on_a_Stick wrote:
steelpillow wrote:
Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release
You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.
[1] Like most of systemd's tools.
Don't call those features optional. They are pure EEE. SystemD is not GNU/Linux - it's svchost.exe. Home directories in svchost.exe-like service is the greatest insanity achieved recently.

More like launchd by apple.

Last edited by HevyDevy (2020-02-10 12:43:34)

Head_on_a_Stick · 2020-02-10 16:46:46

ToxicExMachina wrote:

Don't call those features optional.

But they are optional. For example, can you name a single distribution that's actually using systemd-networkd?

ToxicExMachina wrote:

All of useful features from SystemD can be implemented with a standard tool set accessible in GNU/Linux OS.

I would agree that most features can be implemented with other tools but I like the consistency of the systemd tool set and also the fact that they're all being produced and maintained by the same team, just as you would find in real UNIX systems.

But there are some features that are unique to systemd. I've already mentioned masking units, another is hardening of services:

https://www.ctrl.blog/entry/systemd-ser … ening.html

Check this out:

empty@E485:~ $ systemd-analyze security --no-p
UNIT                                 EXPOSURE PREDICATE HAPPY
accounts-daemon.service                   9.5 UNSAFE    ?    
alsa-state.service                        9.5 UNSAFE    ?    
anacron.service                           9.5 UNSAFE    ?    
auditd.service                            9.5 UNSAFE    ?    
btrfs-scrub@-.service                     9.5 UNSAFE    ?    
colord.service                            8.7 EXPOSED   ?    
cron.service                              9.5 UNSAFE    ?    
dbus.service                              9.5 UNSAFE    ?    
emergency.service                         9.5 UNSAFE    ?    
gdm.service                               9.7 UNSAFE    ?    
getty@tty1.service                        9.5 UNSAFE    ?    
hddtemp.service                           9.5 UNSAFE    ?    
iwd.service                               5.7 MEDIUM    ?    
polkit.service                            9.5 UNSAFE    ?    
rc-local.service                          9.5 UNSAFE    ?    
rescue.service                            9.5 UNSAFE    ?    
rtkit-daemon.service                      6.9 MEDIUM    ?    
sysfsutils.service                        9.5 UNSAFE    ?    
systemd-ask-password-console.service      9.3 UNSAFE    ?    
systemd-ask-password-wall.service         9.3 UNSAFE    ?    
systemd-fsckd.service                     9.5 UNSAFE    ?    
systemd-initctl.service                   9.3 UNSAFE    ?    
systemd-journald.service                  4.3 OK        ?    
systemd-logind.service                    4.1 OK        ?    
systemd-networkd.service                  2.8 OK        ?    
systemd-resolved.service                  2.1 OK        ?    
systemd-rfkill.service                    9.3 UNSAFE    ?    
systemd-timesyncd.service                 2.0 OK        ?    
systemd-udevd.service                     8.3 EXPOSED   ?    
upower.service                            7.2 MEDIUM    ?    
user@1000.service                         9.1 UNSAFE    ?    
uuidd.service                             9.1 UNSAFE    ?    
empty@E485:~ $

Can you do that with sysvinit?

ToxicExMachina wrote:

If nobody made features like "portable home directories" then such features are obvious and already exist or they aren't demanded.

So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?

I asked the same question over at the MX forums and one of their developers claimed that the "solution" was not to use suspend. And I think they were being serious

Last edited by Head_on_a_Stick (2020-02-10 16:50:42)

farmatito · 2020-02-10 20:41:07

So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?

Just out of curiosity where is it stored by systemd-homed?

Head_on_a_Stick · 2020-02-10 20:53:48

farmatito wrote:

where is it stored by systemd-homed?

In the LUKS2 header, the entire volume being un-mounted for the suspend operation.

Technical details here: https://systemd.io/HOME_DIRECTORY/

ToxicExMachina · 2020-02-11 12:08:10

Head_on_a_Stick wrote:

ToxicExMachina wrote:
Don't call those features optional.
But they are optional. For example, can you name a single distribution that's actually using systemd-networkd?

Networkd? What about logind and udev?

Head_on_a_Stick wrote:

ToxicExMachina wrote:

All of useful features from SystemD can be implemented with a standard tool set accessible in GNU/Linux OS.

I would agree that most features can be implemented with other tools but I like the consistency of the systemd tool set and also the fact that they're all being produced and maintained by the same team, just as you would find in real UNIX systems.

But there are some features that are unique to systemd. I've already mentioned masking units, another is hardening of services:

https://www.ctrl.blog/entry/systemd-ser … ening.html

Check this out:

empty@E485:~ $ systemd-analyze security --no-p
UNIT                                 EXPOSURE PREDICATE HAPPY
accounts-daemon.service                   9.5 UNSAFE    ?    
alsa-state.service                        9.5 UNSAFE    ?    
anacron.service                           9.5 UNSAFE    ?    
auditd.service                            9.5 UNSAFE    ?    
btrfs-scrub@-.service                     9.5 UNSAFE    ?    
colord.service                            8.7 EXPOSED   ?    
cron.service                              9.5 UNSAFE    ?    
dbus.service                              9.5 UNSAFE    ?    
emergency.service                         9.5 UNSAFE    ?    
gdm.service                               9.7 UNSAFE    ?    
getty@tty1.service                        9.5 UNSAFE    ?    
hddtemp.service                           9.5 UNSAFE    ?    
iwd.service                               5.7 MEDIUM    ?    
polkit.service                            9.5 UNSAFE    ?    
rc-local.service                          9.5 UNSAFE    ?    
rescue.service                            9.5 UNSAFE    ?    
rtkit-daemon.service                      6.9 MEDIUM    ?    
sysfsutils.service                        9.5 UNSAFE    ?    
systemd-ask-password-console.service      9.3 UNSAFE    ?    
systemd-ask-password-wall.service         9.3 UNSAFE    ?    
systemd-fsckd.service                     9.5 UNSAFE    ?    
systemd-initctl.service                   9.3 UNSAFE    ?    
systemd-journald.service                  4.3 OK        ?    
systemd-logind.service                    4.1 OK        ?    
systemd-networkd.service                  2.8 OK        ?    
systemd-resolved.service                  2.1 OK        ?    
systemd-rfkill.service                    9.3 UNSAFE    ?    
systemd-timesyncd.service                 2.0 OK        ?    
systemd-udevd.service                     8.3 EXPOSED   ?    
upower.service                            7.2 MEDIUM    ?    
user@1000.service                         9.1 UNSAFE    ?    
uuidd.service                             9.1 UNSAFE    ?    
empty@E485:~ $

Can you do that with sysvinit?

That's the great example of SystemD flawness. So called "consistency" of SystemD is just overcomplication. Sandboxing is not the feature accessible only via SystemD.

Head_on_a_Stick wrote:

ToxicExMachina wrote:
If nobody made features like "portable home directories" then such features are obvious and already exist or they aren't demanded.
So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?
I asked the same question over at the MX forums and one of their developers claimed that the "solution" was not to use suspend. And I think they were being serious

I have no this problem at all. If I don't want such security flaw I just won't use suspend. Security isn't about making illusion of secure state.

ChuangTzu · 2020-02-12 02:29:46

Head_on_a_Stick wrote:

[
Can you do that with sysvinit?

What's the emoji for broken by design?

Last edited by ChuangTzu (2020-02-12 02:30:09)

mmaglis · 2020-02-12 10:34:47

ChuangTzu wrote:

What's the emoji for broken by design?

farmatito · 2020-02-17 13:38:18

Head_on_a_Stick wrote:

farmatito wrote:
where is it stored by systemd-homed?
In the LUKS2 header, the entire volume being un-mounted for the suspend operation.
Technical details here: https://systemd.io/HOME_DIRECTORY/

Isn't it a little risky to encrypt the whole file system as a loop mountable file.
Couldn't one bad block in the LUKS header or maybe even in the file body make the file undecryptable?

czeekaj · 2020-03-08 22:19:58

I've had fully encrypted laptops die with battery dying on me.
I couldn't decrypt the system, I mounted from a USB though. was able to boot fine after that. Couldn't mount from grub cryptomount. Every time the passphrase was wrong.

As for homed, time will tell how it gets implemented. However, even if networkd isn't widely adopted. Doesn't resolvd solve so many problems present in linux? I kid.

anyway. On an encrypted system I can suspend to ram in xfce session. Return to normal operation with no hitches. Probably not the same as dismounting though! Although from a root terminal I'm sure you could remount it, but maybe would have to reboot and close a bunch of processes running from non-root user! I'm sure someone smart could write a script to dismount a home partition and remount the thing and get xorg back up and running without leaking the passphrase. Manually mounting from terminal isn't hard just takes time

https://github.com/tuxlovesyou/sshfs-home
is homed something like this? I stumbled on this browsing github. I usually don't install much from git if ever.

Thing is about convenience is you are trading something.

So far the only systemd feature I like is nspawn. It seems powerful.

Last edited by czeekaj (2020-03-09 06:11:01)

The officially official Devuan Forum!

#101 2020-02-04 18:12:40

Re: Debian considering going systemd init only

#102 2020-02-04 18:26:12

Re: Debian considering going systemd init only

#103 2020-02-04 18:57:11

Re: Debian considering going systemd init only

#104 2020-02-04 19:13:05

Re: Debian considering going systemd init only

#105 2020-02-04 20:01:29

Re: Debian considering going systemd init only

#106 2020-02-04 20:04:11

Re: Debian considering going systemd init only

#107 2020-02-04 20:07:59

Re: Debian considering going systemd init only

#108 2020-02-05 17:20:58

Re: Debian considering going systemd init only

#109 2020-02-05 18:08:34

Re: Debian considering going systemd init only

#110 2020-02-05 18:29:37

Re: Debian considering going systemd init only

#111 2020-02-05 18:49:58

Re: Debian considering going systemd init only

#112 2020-02-05 18:54:53

Re: Debian considering going systemd init only

#113 2020-02-05 21:48:40

Re: Debian considering going systemd init only

#114 2020-02-06 05:33:07

Re: Debian considering going systemd init only

#115 2020-02-10 08:45:10

Re: Debian considering going systemd init only

#116 2020-02-10 08:52:11

Re: Debian considering going systemd init only

#117 2020-02-10 12:43:20

Re: Debian considering going systemd init only

#118 2020-02-10 16:46:46

Re: Debian considering going systemd init only

#119 2020-02-10 20:41:07

Re: Debian considering going systemd init only

#120 2020-02-10 20:53:48

Re: Debian considering going systemd init only

#121 2020-02-11 12:08:10

Re: Debian considering going systemd init only

#122 2020-02-12 02:29:46

Re: Debian considering going systemd init only

#123 2020-02-12 10:34:47

Re: Debian considering going systemd init only

#124 2020-02-17 13:38:18

Re: Debian considering going systemd init only

#125 2020-03-08 22:19:58

Re: Debian considering going systemd init only

Board footer