Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

[Danny Mayer <[e-mail]>]

David W. Hankins wrote:
> On Fri, Nov 23, 2007 at 10:46:12PM -0500, Danny Mayer wrote:
>> That's currently the situation with the reference implementation of
>> ntpd. It gets its configuration information and doesn't go back. You can
> 
> You can classify this as an ntpd problem, or a system integration
> problem.
> 

It's an ntpd problem though we have several methods of updating the
server using ntpdc and ntpq.

> In the former, you might want to accept a HUP sometimes.  In the
> latter, all the tools to restart the daemon are already available.
> 
> Whichever one you choose, you'll still get the job done.  If ntpd
> accepts HUPs, maybe you can optimize 'keeping your clock synched'
> across reconfiguration events.
> 

We really do *not* want to use HUP since that causes a restart and
that's a bad idea for ntpd which is designed to be long-running. It
frequently takes several hours for it to settle now into a stable state
and disciplining the clock. A HUP would disrupt this. Rereading the
configuration file is not straightforward either as you could well be
changing its operational behavior and not just changing server settings.
For what you are talking about with the DHCP provided NTP server
addresses you really only need something like ntpdc -c "add server ..."
comands.

>> now. So for the DHCP client to have an influence on what it uses for
>> servers it either needs to use ntpdc, send private mode 7 NTP packets,
>> restart ntpd, or have some sort of interface for ntpd to get updated
>> values from the DHCP client.
> 
> The client itself has no need to do this.  The operating system's
> configuration management system which accepts DHCP input needs to
> solve this problem.

Sorry, that's what I meant.

> For ISC, we call this "dhclient-script", and although we package
> several examples with our software I know of no actual operating
> systems that use them...they all cook their own scripts that
> integrate with their configuration management.
> 
> Still, it is trivial;
> 
> 	if [ x$new_ntp_servers != x$old_ntp_servers ] ; then
> 		rewrite_ntp_conf()
> 		rcntp force-reload
> 	fi
> 
>> Well, if ntpd can poke the DHCP client for new values, presumably it can
>> request new values from the DHCP server to pass back to ntpd. That's not
>> even defined.
> 
> Presently, all the poking is in the opposite direction.  What I was
> referring to here is that there are Server->Client messages that can
> suggest the client needs to update its config, rather than wait for
> the usual lease renewal timer to expire.

If the address provided by DHCP is not providing NTP service ntpd will
drop it. So in this case it has no recourse.

Danny

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg