A word about systemd • Hacker News Board

Re: A word about systemd

#11

Post by nwmcsween » Tue, Feb 05, 2019, 7:51 AM UTC

theamk wrote: post #3

taylodl wrote: post #2

I have a quibble with the following statement: "It's as if we had learned nothing from the mistakes of the past 20 years." My quibble is it's as if we had learned nothing from the mistakes of the last 40 years, not 20. The problem I see with the whole discussion/argument around systemd is it ignores there's two philosophies in computer science, which for convenience sake I'll call the Unix way and the Windows way. I…

How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know? I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry abou…

You are somewhat confused, systemd doesn't do priv sep, systemd doesn't do 'logging' and there are already tools that do what you want via chain loading

Re: A word about systemd

#12

Post by JdeBP » Tue, Feb 05, 2019, 10:43 AM UTC

theamk wrote: post #3

taylodl wrote: post #2

I have a quibble with the following statement: "It's as if we had learned nothing from the mistakes of the past 20 years." My quibble is it's as if we had learned nothing from the mistakes of the last 40 years, not 20. The problem I see with the whole discussion/argument around systemd is it ignores there's two philosophies in computer science, which for convenience sake I'll call the Unix way and the Windows way. I…

How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know? I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry abou…

> How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"?

You are predicating your argument upon a fallacy. AT&T Unix had a service manager from 1988 onwards.

* http://jdebp.eu./FGA/unix-service-access-facility.html

Indeed Laurent Bercot's s6 is one of the very toolsets where all of those things are done by the toolsets. Arguing that the idea is having each program incorporate this is at best foolish and pretty much the very only-systemd-or-van-Smoorenburg-rc fallacy called out by the Uselessd Guy years ago.

* http://jdebp.eu./FGA/daemontools-family.html

* http://uselessd.darknedgy.net./ProSystemdAntiSystemd/

> no one did the hard job of converting thousands of packages to daemontools

Ahem!

    % find /package/admin/nosh/config/services -name run | wc -l
    849
    % find /var/sv -name run | wc -l
    816
    %

* http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html...

* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...

* http://jdebp.eu./Softwares/nosh/guide/creating-bundles.html

Re: A word about systemd

#13

Post by JdeBP » Tue, Feb 05, 2019, 10:49 AM UTC

saghm wrote: post #10

theamk wrote: post #9

Earlier quoted context omitted.

I am not sure who said that systemd was just an init system. While the very first blog post did call it so, it is certainly not described as such now: Package: systemd Description-en: system and service manager "systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1" (from https://www.freedesktop.org/wiki/Software/systemd/ ) In any case, Linux is no…

> In any case, Linux is not systemd yet. You still have Arch and Gentoo at least. Out of curiosity, what do you mean by this? Arch has used systemd as the default for over six years now ( https://wiki.archlinux.org/index.php/systemd ), and switching to something else is not officially supported (although technically possible).

It is possible, indeed. (-:

* https://framagit.org/taca/archnosh

Re: A word about systemd

#14

Post by JdeBP » Tue, Feb 05, 2019, 11:14 AM UTC

nwmcsween wrote: post #11

theamk wrote: post #3

Earlier quoted context omitted.

How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know? I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry abou…

You are somewhat confused, systemd doesn't do priv sep, systemd doesn't do 'logging' and there are already tools that do what you want via chain loading

systemd very much does do logging. systemd-journald is a compulsory part of the system. It is one big daemon that is a huge fan-in point for all log output streams. It is also the locus of the well-publicized security holes which hit the headlines recently that allowed one to gain superuser access by subverting it.

It is not how I would do logging. I wouldn't have the fan-in, only to have to filter it all back out into individual streams again in most of my use cases. I wouldn't run log services as the superuser, or as the same user accounts as other services, or as user accounts that owned anything other than the log files that they create. (Subvert an instance of cyclog, which does not use alloca(), and all that you'll gain is write access to one service's log files and log directory. You won't get superuser access. You won't get access to the logged service process, which is running as another user. You won't get access to any other service's loggers, which are running as other users. You won't even get owner access to the log directory, and the rights to alter its permissions, as the logger only has has a non-owner ACL on the directory.)

* http://jdebp.eu./Softwares/nosh/guide/log-service-security.h...

But systemd does do logging.

Re: A word about systemd

#15

Post by boomlinde » Tue, Feb 05, 2019, 11:35 AM UTC

theamk wrote: post #3

taylodl wrote: post #2

I have a quibble with the following statement: "It's as if we had learned nothing from the mistakes of the past 20 years." My quibble is it's as if we had learned nothing from the mistakes of the last 40 years, not 20. The problem I see with the whole discussion/argument around systemd is it ignores there's two philosophies in computer science, which for convenience sake I'll call the Unix way and the Windows way. I…

How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know? I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry abou…

> (yeah, we could do it with daemontools as well.. but no one did the hard job of converting thousands of packages to daemontools)

Void Linux is close. It uses runit as its init/service supervision and implements the daemontools uid/env commands with its chpst command. Logging is managed through svlogd which can timestamp output, rotate files etc. I couldn't be happier with a Linux distribution.

You really don't need to convert anything, unless it's explicitly written to interact directly with some specific supervision mechanism, which I don't think is the case for "thousands of packages".

Re: A word about systemd

#16

Post by ilayn » Tue, Feb 05, 2019, 1:38 PM UTC

Software people will never learn to argue to the point and to provide comparisons without sprinkling insults to the other party.

Re: A word about systemd

#17

Post by theamk » Tue, Feb 05, 2019, 4:08 PM UTC

saghm wrote: post #10

theamk wrote: post #9

Earlier quoted context omitted.

I am not sure who said that systemd was just an init system. While the very first blog post did call it so, it is certainly not described as such now: Package: systemd Description-en: system and service manager "systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1" (from https://www.freedesktop.org/wiki/Software/systemd/ ) In any case, Linux is no…

> In any case, Linux is not systemd yet. You still have Arch and Gentoo at least. Out of curiosity, what do you mean by this? Arch has used systemd as the default for over six years now ( https://wiki.archlinux.org/index.php/systemd ), and switching to something else is not officially supported (although technically possible).

oops, my bad. I've seen some people write, "I don't care about systemd, I am running arch" and made a bad assumption

Re: A word about systemd

#18

Post by theamk » Tue, Feb 05, 2019, 4:17 PM UTC

JdeBP wrote: post #12

theamk wrote: post #3

Earlier quoted context omitted.

How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know? I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry abou…

> How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"? You are predicating your argument upon a fallacy. AT&T Unix had a service manager from 1988 onwards. * http://jdebp.eu./FGA/unix-service-access-facility.html Indeed Laurent Bercot's s6 is one of the very toolsets where all of those things are done by the toolsets. Arguing that the idea is having each progra…

If I am reading this right, it looks like you are agreeing with me? We both think that centralized service managers are good, and are consistent with Unix way; and having each daemon implement chroot and logging manually is bad.

Re "nosh": this looks pretty good. I like that it can read systemd's unit files as well -- this means it provides a feasible systemd alternative for those who don't like systemd, but are not ready to rewrite all service files manually.