Red Hat Bugzilla – Bug 57843
dateconfig ntp.conf misconfiguration
Last modified: 2008-05-01 11:38:01 EDT
Description of Problem:
When dateconfig adds a server to /etc/ntp.conf, it also incorrectly sets up
a fudge line --
server ntp.example.com # Correct
fudge ntp.example.com stratum 10 # ERROR
Only local drivers should have a fudge line, and this fudge line is trying
to force NTP to treat that server as if it were at stratum 10 rather than
its real stratum. The stock ntp.conf file uses a 127.127.1.n LCL clock
driver which needs this fudge line to tell the world that it's a not using
a good quality time source.
Luckily, NTP currently ignores this misconfiguration.
In addition, the program silently uncomments the 'multicastclient' line,
which probably should be used with authentication to avoid possible clock
skew attacks from rogue multicast servers. It might make sense to make
activation of 'multicastclient' a checkbox option.
When setting a remote server with dateconfig(8), the fudge line should be
I'll look into this.
Sorry that it's taken so long to address this bug. I have been porting
dateconfig to Python2.2/GTK2, so that's taken the focus lately. I have reworked
the way dateconfig writes the ntp.conf file so that changes made to the file by
hand will be preserved. I have modified dateconfig so that the "fudge" line
will not be written, so that should address the first part of the bug report.
As for the multicastclient part, I can't think of a good way to present it
without complicating the interface. There are lots of things you can do
manually in ntp.conf that dateconfig won't let you do, and I think that if you
need to do those kind of customizations, it's better to edit the file by hand.
The ntp.conf file that the ntp RPM installs has the multicastclient line
commented out, so dateconfig will leave that line commented out.
I've pushed a new dateconfig through the build system, so a new dateconfig will
appear in Rawhide soon. Of course, you'll need Python2.2, Gtk2, pygtk2, and a
whole bunch of other packages to get it to run. All this package churn should
be fixed by the next Red Hat Linux release, so all this will run smoothly
someday soon. Thanks for your report.