[ntp:questions] What to do for clients less than 4.2.8?
martin.burnicki at meinberg.de
Mon Dec 22 16:10:37 UTC 2014
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> And of course, the information flow was really bad here, so that it is
>> very hard to figure out which systems are affected.
> Indeed. Only after 3 days there was a statement on the pool mailing list
> that the problem only affected servers that can be queried. Well, that
> had better be stated in the original release, so that 99.9% of the users
> of ntpd could immediately move it to "not for me" and not be worried.
Yes. I agree that this information should have been available
immediately with the first alert. This would have avoided much trouble.
>>> So for now I presume it is on by default... also because of what I saw
>>> in the OpenSUSE example config. (or would the "keys" config directive
>>> be the magic enable crypto directive?)
>> Unfortunately openSUSE has (symmetric keys) crypto enabled to be able to
>> change ntpd's configuration at runtime via ntpq and/or ntpdc commands.
>> E.g. if the dhcp client receives a DHCP option with the IP of an an NTP
>> server it configures ntpd dynamically to use this server.
> Ok, I always immediately cut out such behaviour after installing a system.
That's also what I do. I't interesting to see how the different ways to
fiddle with the NTP configuration automatically evolve over time. ;-)
> I don't want DHCP to modify my NTP settings, or to restart ntpd.
> (of course the neat thing about the above solution is that it is not
> required to restart ntpd. in Debian, for example, ntpd is restarted when
> a DHCP lease with changed ntp option is received)
For standard deployments on a huge number of clients the DHCP way very
much simplifies installation since you only have to configure the DHCP
On the other hand, it would be good if there was a simple (easy-to-find)
switch where you could disable such automatics.
More information about the questions