Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is the rationale for changing OpenSSH into a socket activated service? Given that it comes with issues, I assume the benefits outweigh the downsides.


> Given that it comes with issues, I assume the benefits outweigh the downsides.

Any change can introduce regressions or break habits. The move toward socket activation for sshd is part of a larger change in Debian. I don't think the Debian maintainers changed that just for the fun of it. I can think of two benefits:

+ A service can restart without interruption, since the socket will buffer the requests during the restart.

+ Dependencies are simpler and faster (waiting for a service to start and accept requests is costly).

My experience is that these points largely outweigh the downsides (the only one I can think of is that the socket could be written in two places).


> Dependencies are simpler and faster (waiting for a service to start and accept requests is costly)

Yeah, but requiring a service's response is why its a dependency in the first place, no?


I also have a hunch that socket activation allows for more predictability around what a not-running/listening-for-activation service's port is doing at the syscall/kernel level, which in turn makes power saving and/or sleep states a little more predictably efficient.

Total guess, mind you.


> Given that it comes with issues, I assume the benefits outweigh the downsides.

I think it doesn't outweight the downside. Let's not forget this:

"OpenSSH normally does not load liblzma, but a common third-party patch used by several Linux distributions causes it to load libsystemd, which in turn loads lzma."

The "XZ utils backdoor" nearly backdoored every single distro running systemd.

People (including those who tried to plant this backdoor) are going to say: "systemd has nothing to do with the backdoor" but I respectfully disagree.

systemd is one heck of a Rube-Goldberg piece of machinery: the attack surface is gigantic seen that systemd's tentacles reaches everywhere.

With a tinfoil hat on one could think the goal of systemd was, precisely, to make sure the most complicated backdoors could be inserted here and there: "Let's have openssh use a lib it doesn't need at all because somehow we'll call libsystemd from openssh".

Genius idea if you ask me.

What could possibly go wrong with systemd "now just opening a port for openssh" uh? Nothing I'm sure.

Now that said I'm very happy that we've now got stuff like the Talos Linux distribution (ultra minimal, immutable, distro meant to run Kubernetes with as few executables as possible and of course no systemd) and then containers using Alpine Linux or, even if Debian based, minimal system with (supposedly) only one process running (and, once again, no systemd).

Containerization is one way out of systemd.

I can't wait for a good systemd-less hypervisor: then I can kiss Microsoft goodbye (systemd is a Microsoft technology, based on Microsoftism, by a now Microsoft employee).

Thanks but no thanks.

Talos distro, systemd-less containers: I want more of this kind of mindset.

The future looks very nice.

systemd lovers should just throw the towel in and switch to Windows: that's what they actually really want and it's probably no better than they deserve.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: