Red Hat Bugzilla – Bug 75773
dhclient-script generates incorrect ntp.conf
Last modified: 2007-04-18 12:47:29 EDT
Description of Problem:
The dhclient script generates an incorrect ntp.conf when NTP servers are
provided by the DHCP server.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Include an 'option ntp-servers' line in a subnet definition in
/etc/dhcpd.conf on your DHCP server.
2. Start a dhcp client
3. Look at ntp.conf - default is 'restrict default ignore'
4. Look at server definitions - only 127.0.0.1 has a matching 'restrict' entry
5. Wait 10 mins
6. Run 'ntpq -p'
No NTP servers are synchronised
NTP servers synchronised
Under 7.3 dhcpcd would write the ntp.conf with a restrict entry for each server,
but not under 8.0. Attached is the earth-shattering patch. :-)
This bug should be under 'dhclient' component, but that doesn't exist.
Created attachment 80086 [details]
Patch to fix dhclient-script ntp.conf generation
bug component is source package not binary package
There is another thing that I'm missing in the generated ntp.conf file:
It's the "Undisciplined Local Clock". Cite: "This is a fake driver intended for
backup and when no outside source of synchronized time is available."
Created attachment 82705 [details]
additional patch to fix dhclient-script ntp.conf generation
My $0.02 (colored by wasting a fair amount of time getting ntp to actually
work): The whole method dhclient uses to deal with ntp servers is heavy-handed
and functionally broken. Why should it completely nuke whatever
carefully-crafted ntp.conf you might have in favor of some hard-coded options
buried deep within a script belonging to an unrelated package? "cat <<EOF >
/etc/ntp.conf" is a pretty large sledgehammer to apply to a config file.
For example, the current dhclient setup says "authenticate yes". With this set,
ntp will only work if you go out and load in the ntp server keys, a non-trivial
operation. The average user will activate the ntpd service thinking he's going
to get time synched - but he won't (and it will fail silently too, the only way
to notice the problem is to notice that your system clock has drifted and to
fire up ntpq to find out why). If you're going to trust your dhcp server to
give you a secure DNS (certainly, much bad foo can happen if this isn't true!),
why not trust that it will give you a secure ntp server too (where the worst
that can happen is that your system time gets munged).
To take advantage of dynamic ntp servers via dhcp, it would make more sense to
have dhclient-script change only the server IP definition lines in ntp.conf.
Leave whatever other options there are alone, and add a comment saying "these
lines updated by /sbin/dhclient-script, here's how you can disable this updating
if you want".
As it stands now, anyone using RH8 in conjunction with a dhcp server that is
helpfully supplying ntp information is getting a default setup that doesn't
work, fails silently, and provides no clues as to how to make it work.
Apologies for the ranting tone, hope the suggestions are useful anyway (my
workaround - I just commented out the offending part of dhclient-script).
Created attachment 87945 [details]
Security enhanced and combined version of the two previous patches
Created attachment 89589 [details]
patch to correct destroying of /etc/ntp.conf
What do you think of the above patch. It will basically just replace all server
and restrict lines in the /etc/ntp.conf.
Would that satisfy this bug and work correctly?
With all due respect to Alec, i think that just mangling the ntp.conf that is
there is a bad idea.
Why should it completely nuke whatever carefully-crafted ntp.conf you might have
in favor of some hard-coded options buried deep within a script belonging to an
The answer to this is "because that's what autoconfiguration is supposed to do".
dhclient does this with resolv.conf, and it should do it with ntp.conf also.
What is needed is an option to tell it to leave ntp.conf alone, just as there is
one for resolv.conf.
Consider the following sequence of events:
- A machine is installed using Red Hat 8.0.
- It is booted on a network that uses DHCP to set NTP servers, so ntp.conf is
- Red Hat 8.1 is released, which makes changes to the default ntp.conf generated
by dhclient. The machine is upgraded and rebooted, however because the ntp.conf
already exists (i can't see anywhere that it is removed when dhclient shuts
down), only the server/restrict entries are changed.
- This change in default options possibly results in a non-working NTP
configuration, leaving the system administrator the cleanup job of manually
fixing the config file (which ne would have done in the first place if ne had
wanted to manually configure it). [Shameless plug: http://www.lippart.com/ne.html]
Here's what i think should happen:
- If ntp.conf doesn't exist, it should be created by dhclient-script.
- If it does exist, it should be renamed and a new one created.
- Dhclient should also somehow restore the previous state of affairs for
ntp.conf when it exits. (In case one wants to move from static to dynamic
configuration and back again.)
- There should be an option to avoid all of the above behaviour.
Haven't tried Dan's patch yet (am on the road), but it looks like it would
satisfy my problem.
However, I agree that Paul's scenario for a 8.0->8.1 breakage for people living
with the defaults could cause problems.
Would splitting the config file into some sort of ntp.conf and ntp.conf.local
work? If ntp.conf.local exists, dhclient can include it when generating
ntp.conf. If not, you get the default behavior. An option to entirely stifle
dhclient's handling of things would also be important.
Whatever is done, please add a note to the ntp package explaining where one can
look in event of problems :)
I have added a patch and restrict line to fix problems, since there is no
concensus on the creation of the /etc/ntp.conf. I have decided to go with the
status quo until the next release.
Fix in dhcp-3.0pl1-23
Are my eyes bad? What's this supposed to do?
+ grep -v "^server|^server" /etc/ntp.conf > /tmp/ntp.conf$$
No turns out my fingers are bad :^). Tt should be
grep -v "^server|^restrict" /etc/ntp.conf > /tmp/ntp.conf$$