Client for observing state and dynamically changing configuration

[folkertdev]

we have two unix sockets, by default

/run/ntpd-rs/log-level
/run/ntpd-rs/config

the log level is unprotected, the config needs additional permissions.

---

we can use https://docs.rs/tokio/latest/tokio/net/struct.UnixStream.html

for sending data over the socket, use https://docs.rs/postcard/latest/postcard/ ? (or send json as bytes?)

---

client --set-log-level=debug

client --step-if-bigger=1000 --step-first-updates=10

then we also need some observability features, some ideas

client peers list # lists all remotes we are connected to
client peers watch # show for each connected peer its `PeerStatus`

[davidv1992]

I would suggest moving the changing of log-level into config as well, as it can have availability impact depending on what is done with the log output (trace may overwhelm log storage).

Furthermore, I'm missing socket for observing in the list of sockets.

[folkertdev]

well we discussed that the configuration that actually changes how the clock behaves (e.g. when to step) should be separate from the logging configuration. These two can then get different permissions (e.g. with user groups). My impression was that you can control the permissions on the socket (it's just a file, after all) and hence there are two sockets: one with minimal permissions that adjusts logs (and perhaps other behavior that does not impact the clock steering), and one with more restrictive permissions that can actually change how clock steering operates (changing peers, when to jump, ect).

[djc]

I'd probably try to find a more generic name for log-level, so that it's easier to extend to other low-permission stuff later. I'd probably not go with Postcard, I don't think its value add is very important in this case, JSON seems like a fine choice (either newline-delimited or length-delimited, maybe check out the tokio-util codec stuff).

[davidv1992]

According to my notes and what i remember the discussion was more on splitting the interactive (configuration-changing) part from the non-interactive readout part (e.g. the measurements) so that things like node-exporter don't need excessive permissions to get statistics.

[davidv1992]

I also don't really see the value in splitting of one part of the interactive socket from another to be honest