Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client for observing state and dynamically changing configuration #119

Closed
folkertdev opened this issue May 31, 2022 · 5 comments
Closed

Comments

@folkertdev
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link

djc commented May 31, 2022

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
Copy link
Member

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants