Expanded status/state of server via file or message

[Rob-NY]

As a server admin, I'd like to be able to get more information about the running state of a server in a programmatic way. For example, I'd like to be able to know the current recording state as well as the IP's of the connected clients. Keeping security in mind (with respect to IP's), I believe there are two ways to accomplish this.

First would be to create a new set of connection-less messages to provide this information. The messages would be 'secured' by only responding if requestor is localhost (or even perhaps an IP specified as authorized via cmd line arg). (Pros: on-demand query; Cons: Not as extendable, security)

Alternatively, create a file similar to the HTML status file that would generate machine readable (txt, xml, json, whatever) output to reflect various server information. (Pros: easier, extendable; Cons: always updated even when no one is looking; unpredictable update frequency)

I've experimented by modifying the HTML status file code to generate the information I'm looking for. Is there an appetite for this type of functionality and, if there is, what would the preferred implementation method be?

[ann0see]

Hi!

Thanks for raising this. I think #1789 might be worth a look.

[npostavs]

The HTML method is surely an option but more of a hack (at least in my opinion): Writing something volatile to a disk doesn't feel clean.

Something like a UNIX-Socket might be a bit more common but doesn't work on Windows probably.

Named pipes are sort of middle ground between file and socket; I believe Windows supports those.

[Rob-NY]

I chose JSON so that the server status can be extended over time without breaking existing implementations. I’m a little fuzzy on whether the potential length of the json string could be problematic over UDP.

To restate my original goal — I was looking for a way to get client IP’s and the recorder status without actually connecting as a client to the server. Beyond that, I wouldn’t really need any changes to the core code as the rest is already there (signals, logs, etc).

I will try and connect with @cdmahoney. I need to learn more about MQTT.

[cdmahoney]

Hi all, got @ann0see's heads-up to look at this. I implemented the mqtt code for similar reasons - to enable a band leader to connect to the server using a web application, and view and control the state of the server from the application.

Here are some of the reasons for choosing mqtt:

1. It's standard, available on all platforms, reasonably simple to implement, and not prone to platform specific variations in behaviour.
2. Uses an external broker, so Jamulus code just connects to broker, and doesn't need to worry about managing connections.
3. It's a natural choice for the kind of applications I was thinking of connecting to the jamulus server - nodejs or python web applications.
4. Jamulus doesn't need to worry about security - the mqtt broker can be run on the server without opening external ports. My idea is to implement OAuth2 authorization on the web application and authorize by comparing the user email address with a configured set of authorizations. The web application would communicate with the client html/javascript using a Rest API and mqtt over a web socket. (note that this would no be using the mqtt broker Jamulus is connected to - the web application connects to that broker to communcate with Jamulus, but implements it's own mqtt connection over websockets, sharing the OAuth2 authentication with the Rest API.

I'm happy to answer any further questions there might be.

[Rob-NY]

I'm going to start a different thread to discuss remote administration from a requirements and capabilities perspective. Once those are sorted through, the most appropriate technical approach can be chosen. Thank you for the follow-up.

[vdellamea]

My Jamulus Recording Remote implements a web frontend to the most useful things, i.e., toggling and starting new recordings, by sudo-calling systemctl,and it could also implement server start and stop if needed. In principle, the frontend could be on a different machine, because the real work is done by a separate PHP script.
However, the server status is "blind": when the system starts, it is expected that recording is not active, and then any action will change a locally maintained status. This means only one admin must access the system at the same time, and no fiddling via ssh should be done at the same time. At some point I also found a way to extract the recording status from Jamulus status, but I never implemented it (it's just another hack).
Said that, I would be glad to have a way to do the same things more cleanly, that avoids the lot of little tricks currently needed to ensure some decent level of security. Regarding the approach, I am slightly leaning towards anything that could be called "standard", unless its implementation is too heavy.

[hoffie]

First would be to create a new set of connection-less messages to provide this information. The messages would be 'secured' by only responding if requestor is localhost (or even perhaps an IP specified as authorized via cmd line arg). (Pros: on-demand query; Cons: Not as extendable, security)
This would certainly be an option.

Personally, I think the line is a bit blurry regarding what should be done where:

• We have the current Jamulus-specific protocol which is focused on ordinary Jamulus client/server communication. It could be extended to allow for other functionality as well, but it doesn't have any security built-in.
• We have the abstract idea of adding a management API (@pljones), without any specific details how it would look like.
• We have a mqtt-based proposal to add a management interface for specific things (Proposal to add inter process communication using mqtt protocol to Jamulus #1789). There hasn't been agreement whether mqtt is the best choice and if/when that will be merged.
• There is a lingering topic of adding TCP support for Jamulus protocol messages. This would require introducing message framing (which is provided by UDP for free, today). This would be another place where decisions have to be made regarding "invent your own" vs. "wrap in something known" (thinking of Protobuf, Thrift, etc.).

I'm a bit vary of introducing too many concurrent techniques which do similar but not quite identical things. At the same time, I'm well aware that there is your rather simply, specified wish for a specific feature with a workable implementation idea (protocol extension). Countering that with "but some arbitrary time in the future we may have a better way to do that" would not seem logical either.
This would allow for iterative development as well.
Based on that, I'd personally say: Go for the simple direction now (depending on what other main developers say).

Alternatively, create a file similar to the HTML status file that would generate machine readable (txt, xml, json, whatever) output to reflect various server information. (Pros: easier, extendable; Cons: always updated even when no one is looking; unpredictable update frequency)

I think the current HTML file is non-optimal. It would have been better, if this was structured data in the first place.
On the other hand, updating file contents might add unpredictable latency in case of slow IO. So maybe this is something which should not further be extended?

So,

Is there an appetite for this type of functionality

I'd say yes.

If there is, what would the preferred implementation method be?

That's the harder part, I guess. :/

[pljones]

Volker wanted rid of the HTML status file because it wrote to disk. I think at the time I was the only user of it and I've stopped now, too (I still write it, just don't read it any more - it doesn't have the information I need).

As server admins, we need:

• to see what's going on
• to make changes to state based on that

Currently, neither has an elegant solution. I don't want a file on disk and to send signals (which doesn't work on Windows).