4 ms·

I honestly have no idea why people find OpenRC and such things appealing. Literally any supervision based option is better than leaking your PIDs, storing them

I honestly have no idea why people find OpenRC and such things appealing. Literally any supervision based option is better than leaking your PIDs, storing them in PID-files and hoping that the value in the PID file still refers to the daemon you ran after 3 weeks. To top it off, in some cases some service management tasks are handled by pgrepping for a specific process name. I can somewhat sympathise with the idea that not everything should be auto-restarted by default but that's literally the only thing these kinds of things have going for them. Also, inevitably these things heavily rely on syslog, which is the most 80s technology ever invented. I agree that multilog/svlogd/whatever could be improved to add an easy centralised view (when you need to know the sequence of events from multiple tools) but grouping logs by some vaguely defined category which you always get wrong, and letting anyone log anywhere with any name are such strange features.

traverseda 3y ago
Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. There's just way too much going on in PID1, written in a memory unsafe language. I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. Aside from it making it possible to run systemd inside a docker container, which I presume redhat/IBM is strongly against, preferring you to use their in-house containerization tools like systemd-nspawn. It's just never going to be viable from a security point of view with how it's architected.
- blueflow 3y ago
  > I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.
- Arch-TK 3y ago
  There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.
- pelasaco 3y ago
  > Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.
  - traverseda 3y ago
    https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
  - b112 3y ago
    Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit. I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. Systemd is a step backwards.
    - TacticalCoder 3y ago
      > Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.
frankjr 3y ago
FWIW Alpine has been trying to replace OpenRC for years but has not found the right match. There's also an attempt to try to become init agnostic. https://mastodon.social/@ariadne@treehouse.systems/112044942335692169 https://mastodon.social/@ariadne@treehouse.systems/112044942... https://mastodon.social/@ariadne@treehouse.systems/112214386005557494 https://mastodon.social/@ariadne@treehouse.systems/112214386...
- wkat4242 3y ago
  They were also trying to find sponsorship to turn S6 into a full dodged fledged service manager. I don't think they were successful though.
  - generalizations 3y ago
    Last I heard the S6 guy did manage to find a sponsor, but the project itself is slow going. https://old.reddit.com/r/AlpineLinux/comments/ug3ipr/any_news_about_migration_from_openrc_to_s6/ https://old.reddit.com/r/AlpineLinux/comments/ug3ipr/any_new...
    - wkat4242 3y ago
      Oh cool! I'm glad. I have high hopes for this one because s6 is much more sane than systemd. PS: She's a "she" according to her linkedin profile.
      - adamomada 3y ago
        The guy who got a sponsor in order to do the s6 work is a he, Laurent Bercot https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
        wkat4242 3y ago
        Oops you're right I mixed them up.

traverseda 3y ago

Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. There's just way too much going on in PID1, written in a memory unsafe language. I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. Aside from it making it possible to run systemd inside a docker container, which I presume redhat/IBM is strongly against, preferring you to use their in-house containerization tools like systemd-nspawn. It's just never going to be viable from a security point of view with how it's architected.

blueflow 3y ago
> I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.
Arch-TK 3y ago
There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.
pelasaco 3y ago
> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.
- traverseda 3y ago
  https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
- b112 3y ago
  Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit. I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. Systemd is a step backwards.
  - TacticalCoder 3y ago
    > Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.

frankjr 3y ago

FWIW Alpine has been trying to replace OpenRC for years but has not found the right match. There's also an attempt to try to become init agnostic. https://mastodon.social/@ariadne@treehouse.systems/112044942335692169 https://mastodon.social/@ariadne@treehouse.systems/112044942... https://mastodon.social/@ariadne@treehouse.systems/112214386005557494 https://mastodon.social/@ariadne@treehouse.systems/112214386...

wkat4242 3y ago
They were also trying to find sponsorship to turn S6 into a full dodged fledged service manager. I don't think they were successful though.
- generalizations 3y ago
  Last I heard the S6 guy did manage to find a sponsor, but the project itself is slow going. https://old.reddit.com/r/AlpineLinux/comments/ug3ipr/any_news_about_migration_from_openrc_to_s6/ https://old.reddit.com/r/AlpineLinux/comments/ug3ipr/any_new...
  - wkat4242 3y ago
    Oh cool! I'm glad. I have high hopes for this one because s6 is much more sane than systemd. PS: She's a "she" according to her linkedin profile.
    - adamomada 3y ago
      The guy who got a sponsor in order to do the s6 work is a he, Laurent Bercot https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
      - wkat4242 3y ago
        Oops you're right I mixed them up.