3 ms·

Yes. I used to use runit/daemontools/inittab. My favourite thing about systemd is that it is increasingly available, and while it has it's faults, it has insta

by geocar 10y ago

Yes. I used to use runit/daemontools/inittab. My favourite thing about systemd is that it is increasingly available, and while it has it's faults, it has instances (macros you can use to kickoff a fleet of services easily) and pretty good isolation features. It also has a "systemctl-over-ssh" feature which is quite nice, and which allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks.

arjie 10y ago
Interesting. Thank you! Would you mind sharing some of the faults? By instances, are you referring to template unit files like this[0]? Do you use it with the `--user` option or do you just access it with `sudo systemctl`? 0: https://fedoramagazine.org/systemd-template-unit-files/ https://fedoramagazine.org/systemd-template-unit-files/
- geocar 10y ago
  Yes, I do use --user where possible. Because resource limits are per-user on UNIX, I tend to run every program and every instance of a service as a separate user. cgroups/containers make this less necessary, but old habits die hard. The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem. When runit/daemontools, you "debug" a service by typing: /path/to/service/run into the terminal. Everything is sensible: grep the output just works. You can use tools familiar like strace/dtruss to "look inside". A unix user can easily leverage their experiences to administer a small unix site, and grow their experiences into larger sites. With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that. Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes. Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.
  - arjie 10y ago
    Ah, hmm. Thank you very much for sharing. Looks like it's got some way before I can use it instead of `monit`. This helps a lot.
thwarted 10y ago
allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks. Another way to do this is pam_ssh_agent_auth. Been using it to authenticate to sudo for years on systems that only maintain keys and no passwords.

by geocar 10y ago

arjie 10y ago

Interesting. Thank you! Would you mind sharing some of the faults? By instances, are you referring to template unit files like this[0]? Do you use it with the `--user` option or do you just access it with `sudo systemctl`? 0: https://fedoramagazine.org/systemd-template-unit-files/ https://fedoramagazine.org/systemd-template-unit-files/

geocar 10y ago
Yes, I do use --user where possible. Because resource limits are per-user on UNIX, I tend to run every program and every instance of a service as a separate user. cgroups/containers make this less necessary, but old habits die hard. The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem. When runit/daemontools, you "debug" a service by typing: /path/to/service/run into the terminal. Everything is sensible: grep the output just works. You can use tools familiar like strace/dtruss to "look inside". A unix user can easily leverage their experiences to administer a small unix site, and grow their experiences into larger sites. With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that. Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes. Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.
- arjie 10y ago
  Ah, hmm. Thank you very much for sharing. Looks like it's got some way before I can use it instead of `monit`. This helps a lot.

thwarted 10y ago

allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks. Another way to do this is pam_ssh_agent_auth. Been using it to authenticate to sudo for years on systems that only maintain keys and no passwords.