Config file format - (Was: [ntp:hackers] FreeBSD serial ports)
David L. Mills
mills at udel.edu
Thu Feb 17 18:12:29 PST 2005
I have found the remote configuration ability rarely useful and then
only if you can't log on and edit a file. However, there is often a need
to enable/disable something, throw a switch or change a value. The
original intent was to use ntpq to do that and scrap ntpdc. However,
there is a problem for such things as monlist, reslist and system
statistics and also with authentication. Gottas start somewhere.
John Pettitt wrote:
>Harlan Stenn wrote:
>>If I'm implementing this, that is where I'll be working from.
>Thoughts on config files.
>I read the config file format page
>http://ntp.isc.org/bin/view/Dev/NewNtpConfFormat and would like to offer
>some thoughts and questions for discussion.
>1) Do we need remote config? I ask this because the more complex the
>message ntpd is asked to interpret the more probability of a security
>bug. In my experience ntpd is the only network connected program I run
>that can be remotely configured. Would the world end if remote config
>via ntpdc were dropped and ntp adopted an edit the file and send a
>SIGHUP model like everything else?
>2) IMHO the new format clearly needs to be block structured with per
>server/peer/clock settings and global settings clearly distinguished.
>3) Are we starting from scratch with the format? If so I’d like to
>suggest that the isc-dhcpd-server config file syntax is clear, easy to
>understand and isc owns the code to parse it.
>4) if remote config is retained are remote changes to be persistent? If
>so how do they get represented – does ntpd have to rewrite its config
>file (a bad thing in my view).
More information about the hackers