4 ms·
It wasn't literally today, but about 2 days ago I discovered the -H (and --host) arguments to systemctl. These allow you to pass a hostname of a remote server,
by mindcrime 9mo ago
It wasn't literally today, but about 2 days ago I discovered the -H (and --host) arguments to systemctl. These allow you to pass a hostname of a remote server, so you can use systemctl to manage systemd services on remote machines. It layers over ssh, so the cleanest way to do it is to have passwordless ssh with certificates set up to the remote host. If you do, running systemctl commands remotely is totally seamless.
https://www.tecmint.com/control-systemd-services-on-remote-linux-server/ https://www.tecmint.com/control-systemd-services-on-remote-l...
- yjftsjthsd-h 9mo agoWhat's the advantage to systemctl --host foo status httpd.service vs ssh -t foo systemctl status httpd.service ?
- Aachen 9mo agoWas wondering the same. "Do one thing and do it well" philosophy... If I want to run remote commands, I know how to do that already (namely, as you've shown), why learn to use a new tool for it? It's like these options to tar for compression: if I want to have a gzipped tar I'll run the tar c /sdcard output through |gzip thank you very much! (and drop in zstd instead)
- mindcrime 9mo ago> What's the advantage to ... For me personally, I'd say "not much". I'm used to using the latter form, and it's fine. But I will say that now that I know about this, I see using it in scenarios where I'm running a lot of systemctl commands over and over again in close proximity and have the "muscle memory" of typing "systemctl" more in mind. For example, when working with a new service that isn't quite working right yet, and doing many iterations of: $> systemctl start something.service $> systemctl status something.service $> journalctl -xeu something.service $> emacs whatever $> systemctl start something.service $> systemctl status something.service lather, rinse, repeat Especially if I'm testing on my laptop AND a remote deployment, I think it's easier from a cognitive viewpoint to always "think systemctl" instead of having to "think systemctl" sometimes and "think ssh systemctl" in others. To be fair though, it's all a pretty minor point. But I do think it's cool that systemctl has that option. shrug
- yjftsjthsd-h 9mo agoBut that seems worse? If all your commands are systemctl, then you just have to ^p and edit/rerun, but there isn't a `systemctl $EDITOR /some/file`, so you'll have to ssh to run emacs (or use TRAMP, if using emacs), at which point you might as well just have a shell on the other end and do everything without having to tack --host onto your commands
- mindcrime 9mo agoI don't know. Maybe. It seems like something that could be handy, but I don't yet know how much I'll wind up using it. For what it's worth, I was working on a scenario exactly like this earlier tonight, and I wound up just ssh'ing into a shell on the remote box to do stuff. But that might just be inertia from being used to doing that, or maybe it was because I had a lot of other stuff to do on that box at the same time...
- dapperdrake 9mo agoFinally a tool that accepts the greatness of sh, rsh, and ssh. For fun look at telefork(2) https://thume.ca/2020/04/18/telefork-forking-a-process-onto-a-different-computer/ https://thume.ca/2020/04/18/telefork-forking-a-process-onto-...
- mindcrime 9mo agoTelefork reminds me of my days writing MPI code on Beowulf clusters! I even took a stab at a similar'ish idea, that was meant to make running code on distributed clusters in Java "just a library" that (somewhat) emulated the existing Threads API. I actually got it to work, but I don't think it was practically useful for anything. More of a learning project. Still, it was fun. :-)