8.0-BETA1 Source Upgrade breaks NTP configuration

[Kevin Oberman]

> Date: Thu, 9 Jul 2009 12:11:19 +1000
> From: John Marshall <john.marshall at riverwillow.com.au>
> Sender: owner-freebsd-stable at freebsd.org
> 
> Yesterday I source-upgraded a 7.2-RELEASE-p2 test i386 server to
> 8.0-BETA1.  I have just discovered that it broke that server's NTP
> service.
> 
> PROBLEM 1 - Existing /etc/ntp.conf overwritten
> 
> For source upgrades I run "mergemaster -iCPU" and it has served me well
> until now.  Mergemaster appeared to run "as normal" for this upgrade,
> prompting me for decisions on how to deal with the handful of usual
> files.  It didn't tell me that it had decided to overwrite my existing
> /etc/ntp.conf with the new default version from the source tree!  (OK,
> perhaps it told me in the big, long list at the end but it didn't prompt
> me to supersede my existing file).
> 
> Looking at the mergemaster(8) man page, I can't see how the options I
> use would have resulted in my existing /etc/ntp.conf being overwritten
> with the version from the source tree - but obviously there is a woops
> factor there, either with me or mergemaster.
> 
> Digging deeper, it looks like it may be due to the fact that this is a
> new supplied file and an entry for /etc/ntp.conf didn't exist in
> /var/db/mergemaster.mtree from the previous (7.2-RELEASE) run.  How
> should this be handled?
> 
> PROBLEM 2 - Default ntp.conf uses LOCAL clock
> 
> So, having had the FreeBSD upgrade magically re-configure my NTP server
> (no, I wasn't prompted to overwrite ntp.conf), I find that my NTP server
> is now synchronizing with it's own (potentially wrong) local system
> clock!  Our firewall is configured to allow NTP traffic between our
> internal NTP servers and specific upstream NTP servers.  The default
> configuration file specifies different servers which we don't use, so
> this NTP server couldn't "see" them.
> 
> The new default configuration file includes "127.127.1.0" as a
> configured server.  Because we could see no "real" NTP servers, we
> synchronized with our local system clock.  That means that we think we
> are synchronized to a reliable upstream source.  Rather than losing
> synch and discovering the problem, we think we are synchronized to a
> reliable source and we and our clients drift away from reality in
> blissful ignorance.  Surely this violates POLA!
> 
> Could we *please* at least comment out the LOCAL server config in the
> supplied ntp.conf?  Personally I would rather see it removed.  It is one
> thing to tell people where the gun is if they want to shoot themselves
> in the foot; it's another thing to load it and fire it for them.
> 
> I think it is good to have a default ntp.conf to help new users get
> started.  I think it is a bad thing to include potentially dangerous
> elements in that configuration which could cause grief to a novice NTP
> administrator.  If the default configuration provides scope for such
> surprises, they will (rightly) blame FreeBSD.
> 
> -- 
> John Marshall

John,

Both of these problems have been reported and Doug is working on a fix
for mergemaster to deal with the case where a new file is added to /etc
but a file of the same named already exists.

I also reported the issue with LOCAL and a fix for this is also in the
pipe. When 8.0 is released, I'm pretty sure that ntp.conf will look a
bit different from what you see and it won't overwrite the existing file
(at least without asking).
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751