Now that the server UI has recording controls and other things, there have been some posts on the forum relating to managing headless servers.
So for the purposes of discussion at least, I thought I'd raise this ticket to propose having the ability for the server GUI to be put into a "remote mode" enabling you to control a headless server.
There are currently only three things you can tell Jamulus server headless, as far as I'm aware:
Assuming the server is managed by systemd, then the first case is simply "stop the service unit".
The second and third cases just require a small script written (if systemd needs assistance) and executed from separate service units.
So, assuming whoever is running the server has a remote management console already, nothing else would be needed.
Thanks pljones for clarifying this. Maybe we should add these informations in the Wiki.
The second and third cases just require a small script
Could you create an example script for this which we could add to the Wiki page?
Thanks pljones for clarifying this too.
What though do people think of the feasibility of the proposal in the ticket?
Looks like it doesn't need a script. A unit type oneshot with systemctl kill -s SIGUSR1 Jamulus-server should do the trick. I'll write up a couple of unit files and paste them here.
OK. Results first :)
root@fs-peter:/etc/systemd/system# systemctl start newRecording-Jamulus-server.service
root@fs-peter:/etc/systemd/system# systemctl start toggleRecording-Jamulus-server.service
root@fs-peter:/etc/systemd/system# systemctl start toggleRecording-Jamulus-server.service
Jul 24 22:39:14 fs-peter Jamulus-server[1521]: Server Registration Status update: Registration requested
Jul 24 22:39:14 fs-peter Jamulus-server[1521]: Server Registration Status update: Registered
Jul 24 22:40:49 fs-peter Jamulus-server[1521]: OnHandledSignal: 10
Jul 24 22:41:02 fs-peter Jamulus-server[1521]: OnHandledSignal: 12
Jul 24 22:41:02 fs-peter Jamulus-server[1521]: Recording state disabled
Jul 24 22:41:05 fs-peter Jamulus-server[1521]: OnHandledSignal: 12
Jul 24 22:41:05 fs-peter Jamulus-server[1521]: Recording state enabled
md5-a9e7e580cd46bdbd6d52f2e871ffcabc
root@fs-peter:/etc/systemd/system# cat newRecording-Jamulus-server.service
[Unit]
Description=Start a new recording on Jamulus-server
Requisite=Jamulus-server
[Service]
Type=oneshot
ExecStart=/bin/systemctl kill -s SIGUSR1 Jamulus-server
md5-842ad2d426cc2a377ecbe96c8160d342
root@fs-peter:/etc/systemd/system# cat toggleRecording-Jamulus-server.service
[Unit]
Description=Toggle recording state on Jamulus-server
Requisite=Jamulus-server
[Service]
Type=oneshot
ExecStart=/bin/systemctl kill -s SIGUSR2 Jamulus-server
No "enable" for the above! Just put them (or symlinks) into /etc/systemd/system (or wherever you put them) and daemon-reload to let systemctl know about them.
Of course, if you want something more deterministic than "toggle", you would need to determine the current state of the recorder. There's currently nothing providing that, though. There's a separate issue for more "health check" information, I think, which would cover this.
You could also have a systemd timer unit that triggers the "newRecording" unit say once an hour, with the timer only enabled whilst there are people on the server. And that would need a further unit to monitor the server state (at which point, it might need a script - I've not looked into how systemd can use inotify).
it'd be super nice if any client connected to the server could signal to initiate/stop the recording tho, so that there doesn't have to be anyone actively managing that at the server. thoughts?
That would mean in turn that anybody could trun off pljones's recording on his server which he does not want I assume. This calls for some small "third party" tool which sends the SIGUSR via SSH to the server. Only the one who has access to the SSH shell has the rights to manage the recording.
I do not want to introduce any password protection in the client (if you suggest to force a password for this setting in the client).
I do not want to introduce any password protection in the client
OK so changing the title of this ticket to avoid confusion :-)
I'll add the unit files and explanation to the wiki.
OK done that (and tested it on my server which is also running the same unit file as in the docs): https://github.com/corrados/jamulus/wiki/Server---Linux#controlling-recordings let me know if there's mistake.
BTW I don't know if this line is correct though:
"The Jamulus process name in the ExecStart line needs to be the same as that of the server."
Is it the process name or some systemctl "name"? When I tried making it the same as the Requires name, it failed.
It's the systemd service unit name, for pedantry :)
Absolutely do not use Requires= - it has to be Requisite=.
So I use "systemctl status Jamulus-server" etc, hence "Jamulus-server" as the "kill" target and requisite unit. Requisite is basically saying "if Jamulus-server isn't started, it's a not appropriate to do this". (Requires would be "if Jamulus-server isn't started, start it!")
That would mean in turn that anybody could trun off pljones's recording on his server which he does not want I assume. This calls for some small "third party" tool which sends the SIGUSR via SSH to the server. Only the one who has access to the SSH shell has the rights to manage the recording.
I do not want to introduce any password protection in the client (if you suggest to force a password for this setting in the client).
Got it, thx
OK done that (and tested it on my server which is also running the same unit file as in the docs): https://github.com/corrados/jamulus/wiki/Server---Linux#controlling-recordings let me know if there's mistake.
BTW I don't know if this line is correct though:
"The Jamulus process name in the ExecStart line needs to be the same as that of the server."
Is it the process name or some systemctl "name"? When I tried making it the same as the Requires name, it failed.
And this looks great
OK, having got the "simple" versions working, I just had to do this. I've be trying to get "systemd templates" working for _anything_ for ages and ages. So I thought: "What if I had multiple servers?" They need the same controls - don't want multiple unit files all over the place, though...
[Unit]
Description=Start a new recording on Jamulus-%i
Requisite=Jamulus-%i
[Service]
Type=oneshot
ExecStart=/bin/systemctl kill -s SIGUSR1 Jamulus-%i
systemctl start newRecording@server would trigger the /bin/systemctl kill -s SIGUSR1 Jamulus-server.
And so, for the toggle, similarly:
[Unit]
Description=Toggle recording state on Jamulus-%i
Requisite=Jamulus-%i
[Service]
Type=oneshot
ExecStart=/bin/systemctl kill -s SIGUSR2 Jamulus-%i
The "Jamulus-" in front of the "%i" restricts the scope to just those service units to which these signals are appropriate.
It's the systemd service unit name, for pedantry :)
Where does it take that name from though? The actual unit file name in /etc/systemd/system?
(On the use of systemd templates, it's a pity it doesn't do the upstart thing of enabling "commands" in the unit file so you can't do service Jamulus-Server toggleRecording or something. At least I'm pretty sure it doesn't do that.)
Jamulus-Server.service would be the file name for the systemd service unit named Jamulus-Server. And that would have to be located in a "system" slice rather than a "user" slice to actually be a service, as I understand it. So /etc/systemd/system would be one place to put it.
The other thing I'd like to be able to do is:
I could write a bit of bash quite easily to do that (similar to my existing jam archiver). I've yet to try with a "pure" systemd solution...
@gilgongo - is anything else needed here or can the request be considered complete? If it can, please close :)