Questioning corporate involvement in GNOME development

Posted Jun 3, 2014 16:58 UTC (Tue) by zblaxell (subscriber, #26385)
In reply to: Questioning corporate involvement in GNOME development by nix
Parent article: Questioning corporate involvement in GNOME development

There is little or no documentation of the form "I liked legacy behavior X, how do I get it from systemd?". Or, if there is, it's buried under pages of diatribe saying how evil X was, how progress and sanity will make behavior X difficult to support in the future, and how subtly-different-in-critical-ways-behavior Y is better. It's certainly not in the official documentation--you have to take your chances with Google and the deranged ramblings of thousands of other confused users as they stumble through unrelated problems that are described by the same six words.

No, the legacy support for /etc/init.d/ and /etc/fstab doesn't count. I need to know how to make post-systemd components behave the same way pre-systemd components did after their upstream maintainers have changed the component's architecture to fit systemd's view of the world. It wouldn't be a problem if post-systemd sshd was the same thing as pre-systemd sshd, but it's very much not.

It is possible, after reading all the documentation and filling in the gaps from the systemd source code, to get the legacy behavior back; however, busy admins want documents like "how to make the new WiFi behave just like the old WiFi by editing two config files."

Questioning corporate involvement in GNOME development

Posted Jun 3, 2014 17:14 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> No, the legacy support for /etc/init.d/ and /etc/fstab doesn't count. I need to know how to make post-systemd components behave the same way pre-systemd components did after their upstream maintainers have changed the component's architecture to fit systemd's view of the world. It wouldn't be a problem if post-systemd sshd was the same thing as pre-systemd sshd, but it's very much not.

I don't understand why support for /etc/init.d scripts or /etc/fstab doesn't count as compatibility options?

Also I don't understand what is different about the behavior of sshd that you are referring to, I'm looking at the sshd.service file and it seem pretty straight forward, even including compatibility with environment variables in /etc/sysconfig/sshd. It seems to do the same thing the old startup script did, make sure ssh-keygen is run before sshd starts and starting sshd after the network, audit and syslog are up, with whatever options are stored in the environment file. Alternately there is an on-demand config available if you want it with an sshd.socket file to listen on port 22 that will spawn an sshd@.service and ssh-keygen.service if you set it up that way, which I have not.