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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090709/70be3dea/attachment.pgp
John Marshall wrote:> 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 > > > 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?you are correct, There was a thread on -CURRENT about this recently see http://lists.freebsd.org/pipermail/freebsd-current/2009-July/008968.html I think there was discussion of a patch to mergemaster.> > PROBLEM 2 - Default ntp.conf uses LOCAL clock >Again much discussed, a new improved version using freebsd.pool.ntp.org and commenting out the LOCAL option was posted to the freebsd-net list not long ago by David MAlone, hopefully to be applied soon. Vince
> Date: Thu, 9 Jul 2009 12:11:19 +1000 > From: John Marshall <john.marshall@riverwillow.com.au> > Sender: owner-freebsd-stable@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 MarshallJohn, 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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751