Request ntp-servers by default

Bug #74164 reported by Vincent Untz on 2006-12-02
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dhcp3 (Debian)
Fix Released
Unknown
dhcp3 (Ubuntu)
Wishlist
Unassigned

Bug Description

It might be a good idea to make the dhcp client request ntp-servers by default (just add "ntp-servers" to the request line in dhclient.conf): now that the ntp package installs a script to generate a conf file when we get a dhcp address, it makes things just work.

However, this might be non-intuitive for people who want to force another ntp server (I'm not sure there are a lot of cases where users want another ntp server than the one advertised by the dhcp server).

Related branches

Martin Pitt (pitti) on 2007-01-08
Changed in dhcp3:
importance: Undecided → Wishlist

If you want to override the NTP servers provided by the DHCP server you could use
prepend option ntp-servers ......
or
supersede option ntp-servers ......
in
/etc/dhcp3/dhclient.conf

This seems to be the Right Thing to do.
If you know enough to want to override settings supplied by the DHCP server then use the mechanism that's already in place for doing that.
If you don't know/care about DHCP/NTP then the system will do what you expect it to do, which is use the supplied servers.

The fix for this, and obvious intended behaviour is:

 - add 'ntp-servers' to the 'request' directive in /etc/dhcpd3/dhclient.conf
 - add 'default ntp-servers 91.189.94.4' (ntp.ubuntu.com) to /etc/dhcpd3/dhclient.conf

I confirm that where the DHCP server doesn't pass the 'ntp-servers' option, the default is used and written to /etc/ntp.conf.dhcp, which is then used by ntpd (and otherwise).

It would clearly be more ideal to use 'ntp.ubuntu.com' rather than it's IP address, but it is the lesser of the two evils, since firewalls may prevent contacting external NTP servers, causing clock drift and subsequent NFS issues (eg with 'make'). For this reason, I request that this report is escalated to a bug, rather than wishlist.

This is readily reproducible with Ubuntu 8.04 HH with stock installation, and dhcp3-client 3.0.6.dfsg-1ubuntu9.

Paul Smith (psmith-gnu) wrote :

Hrm, I just filed a bug about this under the "ntp" package: https://bugs.launchpad.net/bugs/246314

Note that the ntp package DOES come with dhclient-exit-hooks.d scripts to turn on/off NTP servers at appropriate times. As this bug mentions, all that's missing are the entries in dhclient.conf... without which those scripts are useless.

In my bug I suggested that the nis package should update the list of requested options, but in retrospect that seems difficult to do since that file is owned by the dhcp3-client package and there's no defined way to update it via dpkg config scripts as far as I know.

So, maybe the right answer is indeed to change the default dhclient.conf file to request this by default.

BTW, Daniel, is it really necessary to have a "default" entry here? Why not just request this value, and then if the DHCP server doesn't provide it nothing will happen and the default will be used. Right?

Indeed it is true - we don't need 'default ntp-servers xyz' in /etc/dhcp3/dhclient.conf, since the defaults in /etc/ntp.conf will be used, as /etc/ntp.conf.dhcp won't be created. That's half the changes then...

Incidentally, we should be requesting 'nis-servers' too, in case that needs to be configured for the environment, eg where on a different network segment, thus broadcasting for it won't find it.

Paul Smith (psmith-gnu) wrote :

Note you need both nis-servers AND nis-domain. And, there's nisplus-domain and nisplus-servers as well.

I opened a separate bug for NIS; the request for the "nis" package to create appropriate dhclient exit hooks is bug #246322

The bug for dhcp3-client to add these to dhclient.conf is bug #246343

Chris Jones (cmsj) wrote :

Without reference to any other comments/decisions on this bug...

"It would clearly be more ideal to use 'ntp.ubuntu.com' rather than it's IP address, but it is the lesser of the two evils"

It would not be *more* ideal to use the hostname, it's the only sane option. Using the IP address is simply broken and wrong. There is no guarantee whatsoever that the IP address will remain constant (and indeed it has already changed once in the lifetime of Ubuntu).

My solution for ntp-servers request from DHCP server (Ubuntu 8.04.1):

1) add 'ntp-servers' to the 'request' in /etc/dhcpd3/dhclient.conf;
2) change 'NTPDATE_USE_NTP_CONF=yes' to NTPDATE_USE_NTP_CONF=no in /etc/default/ntpdate;
3) execute 'sudo ntpdate-debian' for testing.

Re-testing this situation on jaunty alpha 6 in an enterprise environment with a Microsoft DHCP server, it's still not addressed.

The situation is therefore, one of:
 - NTP syncs to ntp.ubuntu.com and silently maintains a constant offset from our local timeserver
 - NTP tries to sync to ntp.ubuntu.com, but is blocked by our firewall (the case here), and time silently diverges

I feel this is more important than 'wishlist' though.

Jonathan Marsden (jmarsden) wrote :

This looks like a very small change, if we confine our attention to the
ntp-server issue (leaving the nis-* related issues for a separate bug).

A debdiff is attached that simply adds the ntp-servers option to the
requests configuration in dhclient.conf.

I have also put a version of the dhcp3 packages which includes this
change into my PPA, so anyone who is willing and able to test this
change is most welcome to download my packages and see how
well they work.

Jonathan

Changed in dhcp3 (Ubuntu):
status: New → Fix Committed

I can confirm this works as expected with the updated dhcpd3-common and -client packages from Jonathan's PPA - the DHCP lease now has the 'ntp-servers' option [1], consequently NTP has picked it up [2].

What else do we need to move this to the next step?

--- [1]

$ cat /var/lib/dhcp3/dhclient.eth0.leases
lease {
  interface "eth0";
  fixed-address 192.168.20.87;
  filename "linux-boot/pxelinux.0";
  option subnet-mask 255.255.255.0;
  option time-offset 0;
  option routers 192.168.20.254;
  option dhcp-lease-time 604800;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.20.2,192.168.20.5;
  option dhcp-server-identifier 192.168.20.2;
  option dhcp-renewal-time 302400;
  option ntp-servers 192.168.20.2;
  option dhcp-rebinding-time 529200;
  option netbios-name-servers 192.168.20.2;
  option domain-name "quadrics.com";
  renew 2 2009/03/24 10:05:00;
  rebind 2 2009/03/24 10:05:00;
  expire 2 2009/03/24 10:05:00;
}
lease {
  interface "eth0";
  fixed-address 192.168.20.87;
  filename "linux-boot/pxelinux.0";
  option subnet-mask 255.255.255.0;
  option time-offset 0;
  option routers 192.168.20.254;
  option dhcp-lease-time 604800;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.20.2,192.168.20.5;
  option dhcp-server-identifier 192.168.20.2;
  option dhcp-renewal-time 302400;
  option ntp-servers 192.168.20.2;
  option dhcp-rebinding-time 529200;
  option netbios-name-servers 192.168.20.2;
  option domain-name "quadrics.com";
  renew 5 2009/03/27 20:56:54;
  rebind 1 2009/03/30 13:05:41;
  expire 2 2009/03/31 10:05:41;
}

--- [2]

$ grep ^server /etc/ntp.conf.dhcp
server 192.168.20.2 iburst

Thierry Carrez (ttx) wrote :

You need sponsoring (see https://wiki.ubuntu.com/SponsorshipProcess)

All what's left here is to subscribe ubuntu-main-sponsors to attract attention of a core-dev willing to sponsor that change. The debdiff looks sane to me, but I can't sponsor it myself (yet).

Changed in dhcp3:
status: Fix Committed → Confirmed
Changed in dhcp3:
status: Unknown → New
Colin Watson (cjwatson) wrote :

Thanks, uploading now.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dhcp3 - 3.1.1-5ubuntu8

---------------
dhcp3 (3.1.1-5ubuntu8) jaunty; urgency=low

  * debian/dhclient.conf: Request ntp-servers by default (LP: #74164)

 -- Jonathan Marsden <email address hidden> Mon, 23 Mar 2009 19:42:32 -0700

Changed in dhcp3:
status: Confirmed → Fix Released
Changed in dhcp3 (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.