Bug 75773 - dhclient-script generates incorrect ntp.conf
dhclient-script generates incorrect ntp.conf
Product: Red Hat Linux
Classification: Retired
Component: dhcp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2002-10-12 00:32 EDT by Paul Gear
Modified: 2007-04-18 12:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-01 16:03:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix dhclient-script ntp.conf generation (346 bytes, patch)
2002-10-12 00:33 EDT, Paul Gear
no flags Details | Diff
additional patch to fix dhclient-script ntp.conf generation (322 bytes, patch)
2002-10-30 10:06 EST, Need Real Name
no flags Details | Diff
Security enhanced and combined version of the two previous patches (497 bytes, patch)
2002-12-09 02:46 EST, Need Real Name
no flags Details | Diff
patch to correct destroying of /etc/ntp.conf (938 bytes, patch)
2003-01-24 15:09 EST, Daniel Walsh
no flags Details | Diff

  None (edit)
Description Paul Gear 2002-10-12 00:32:52 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):

How Reproducible:
Every time

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 has a matching 'restrict' entry
5. Wait 10 mins
6. Run 'ntpq -p'

Actual Results:
No NTP servers are synchronised

Expected Results:
NTP servers synchronised

Additional Information:
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.
Comment 1 Paul Gear 2002-10-12 00:33:40 EDT
Created attachment 80086 [details]
Patch to fix dhclient-script ntp.conf generation
Comment 2 Elliot Lee 2002-10-13 11:59:52 EDT
bug component is source package not binary package
Comment 3 Need Real Name 2002-10-30 10:02:55 EST
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."
Comment 4 Need Real Name 2002-10-30 10:06:38 EST
Created attachment 82705 [details]
additional patch to fix dhclient-script ntp.conf generation
Comment 5 Habig, Alec 2002-11-04 10:45:19 EST
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).
Comment 6 Need Real Name 2002-12-09 02:46:59 EST
Created attachment 87945 [details]
Security enhanced and combined version of the two previous patches
Comment 7 Daniel Walsh 2003-01-24 15:09:27 EST
Created attachment 89589 [details]
patch to correct destroying of /etc/ntp.conf
Comment 8 Daniel Walsh 2003-01-24 15:11:10 EST
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?

Comment 9 Paul Gear 2003-01-25 15:24:38 EST
With all due respect to Alec, i think that just mangling the ntp.conf that is
there is a bad idea.

Alec writes:

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?

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.

Comment 10 Habig, Alec 2003-01-25 16:00:21 EST
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 :)
Comment 11 Daniel Walsh 2003-02-03 11:43:22 EST
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
Comment 12 Paul Gear 2003-02-03 15:45:36 EST
Are my eyes bad?  What's this supposed to do?

+      grep -v "^server|^server" /etc/ntp.conf > /tmp/ntp.conf$$
Comment 13 Daniel Walsh 2003-02-03 16:09:21 EST
No turns out my fingers are bad :^). Tt should be 
      grep -v "^server|^restrict" /etc/ntp.conf > /tmp/ntp.conf$$

Note You need to log in before you can comment on or make changes to this bug.