Config file format - (Was: [ntp:hackers] FreeBSD serial ports)

David L. Mills mills at udel.edu
Thu Feb 17 18:12:29 PST 2005


John,

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.

Dave

John Pettitt wrote:

>
>Harlan Stenn wrote:
>
>
>>Please see:
>>
>>http://ntp.isc.org/Dev/NewNtpConfFormat
>>
>>If I'm implementing this, that is where I'll be working from.
>>
>>H
>>_______________________________________________
>>
>> 
>>
>>
>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).
>
>John
>




More information about the hackers mailing list