| Re: [chrony-dev] Runtime refclock management |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On 2017-10-04 6:15 AM, Miroslav Lichvar wrote:
On Tue, Oct 03, 2017 at 02:30:09PM -0400, Will Miles wrote:
I've recently adapted my company's data acquisition platform to use chrony
to manage the local clock. However, one of the platform features was the
ability to add, remove, or reconfigure time sources such as GPS receivers or
PPS hookups at any time -- so rather than set up some predefined refclock
inputs (SOC0, SOC1, SHM0, etc.) and come up with some external mechanism to
track which ones were in use and by whom, it seemed more straightforward to
extend chrony to allow for "add refclock" and "delete refclock" operations
via chronyc. I don't know if this will be generally useful - I've only
really tested it with the SOCK refclock - but I thought I'd post it up in
case anyone else was interested.
I think there are cases where this could be useful.
However, there is a problem with permissions. In the current code,
reference clocks are opened before root privileges are dropped, which
means adding refclocks via chronyc would work differently than the
config file. That's not a good user experience. There was a reason why
the SOCK refclock didn't try to remove the socket on exit.
If all refclocks were opened after dropping root privileges, users
would have change permissions/ownership of the devices even if they
were not planning to add them via chronyc. Or, in a worse case, they
would decide to run chronyd with root privileges.
Hm, you are absolutely correct - for refclocks that require specialized
kernel IO interfaces like phc or pps, it may not be possible to open
them after dropping root privileges. For "software pipe" refclocks
like shm or sock, it's probably less of an issue to limit ownership to a
non-root user, but it would still be a breaking change.
To be honest, I hadn't actually tried dropping privileges in my target
environment. I'm actually targeting QNX, albeit a modified kernel where
I've hacked in ntp_adjtime() support, so unfortunately the OS support
patch set is not helpful for other users. I know, I know, skipping the
security is why we embedded developers have such a poor reputation -
shame on me.
What is the best way to submit a patch sequence? Currently I've got it up
on github at
https://github.com/willmmiles/chrony/commits/client-refclock-add , but I can
do something like git format-patch/git send-email if that's more practical.
Sending patches to the list is prefered.
OK, I will do that in the future. For a commit chain of several
patches, do you prefer one email per patch, or a single message with
each patch as an attachment? I looked through a few months of mailing
list history but couldn't find any examples.
Comments are very welcome - if this is a feature you'd be interested in
adopting upstream, but there's further work to do or a different approach
you'd prefer to see, please let me know and I'd be happy to improve it in
whatever way I can.
I had a quick look at the patches and I think the idea is well
implemented. I think I'd have just few comments about coding style,
memory leaks and maybe try to deduplicate some of the code in cmdmon.c
and client.c.
Ah, figures I'd miss a style cleanup somewhere. Re memory leaks, I
didn't thoroughly audit the refclock drivers to ensure everything was
freed, but is there something specific you spotted? Re deduplication,
I agree it's an annoyingly large block of marshalling/demarshalling
code; I was trying to be consistent with the approach taken for other
large packet structures, but I'm definitely open to any opportunity to
clean it up.
The parser of the delete command should be able to
handle "refclock" as a hostname for compatibility.
! Yes, of course. I could use the presence of a third argument to
disambiguate.
The Linux seccomp
filter would probably need to be updated to allow all syscalls that
can be made when opening refclocks.
Right. I don't know much about the current state of security tools in
Linux, but that makes sense.
With the permission issue, I'm not sure if this is really worth it.
I'll need to think about it.
Before you implemented the new commands, have you tried modifying the
config file and restarting chronyd? With the dumpdir directive and the
-r option, the timekeeping service should be restored very quickly.
If it didn't work well for you, I'm wondering if it wouldn't be better
to focus on improving this feature instead of adding refclock specific
commands.
To work via the config file, I'd have to:
-> Modify the boot scripts to create a ramdisk and place a base config
file in there before starting the daemon, since I don't want to make
persistent changes;
-> Come up with some kind of mutexing arrangement (lockfiles? another
single-threaded daemon processing messages serially?) to avoid multiple
time source drivers trying to edit the file in parallel;
-> Ensure that the tracking state was preserved across restarts so that
esterror and maxerror aren't disturbed -- my application depends not
just on accurate time, but also uses the esterror and maxerror values to
indicate how much we can trust it; adding a new source shouldn't degrade
the existing estimates. This may already be solved, but I haven't
tested it.
From here it seemed to be a lot more straightforward to try and use the
existing client message handling framework rather than have to solve
parallelism issues via the filesystem, write an additional config file
management daemon, and/or fix up any tracking state continuity issues.
But honestly, I agree with you about the permissions -- there be dragons
there, and I don't know if there's a solution that doesn't add more
complexity than it's worth. I'm happy to file this under "works for me
in my environment, but isn't of use to the general community".
In that vein, I also have a patch stream that adds TAI offset tracking
for sources, and implements
https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00 to
communicate TAI offset information between nodes. I definitely
wouldn't recommend it for use on the public internet, but the
foundational patches to transmit and receive NTPv4 extensions might be
useful at some future date. Would it be of any use to post them up
here for posterity, even though there's not really much point in merging
anything like it now?
Thanks for the review,
-Will
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.