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): dhclient-3.0pl1-9 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 127.0.0.1 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.
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? Dan
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 created. - 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$$