[Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

Robie Basak 1257082 at bugs.launchpad.net
Thu Sep 11 15:52:50 UTC 2014


Thanks Jorge.

The way I imagined a fix going that might also be acceptable to Debian
would be to treat NTPDATE_USE_NTP_CONF as no if ntp.conf doesn't exist,
even if it says yes. Would this work for you?

Then I imagine addition of something like (untested):

if [ ! -f /etc/ntp.conf ]; then
    NTPDATE_USE_NTP_CONF=no
fi

and then no other changes. I think this would cause the DHCP setting to
be used in our failure case, and it shouldn't cause unexpected an
behaviour change since it doesn't make sense to request to use ntp.conf
if it doesn't exist.

How does this sound to you? I'm not saying it's definitely the right
way. I'm just not sure, so I'd like to propose it as an alternative.

What I think we're missing is a list of use cases, and without that I
don't think it's possible to definitely state the right thing to do. I'm
just trying to think of the most unobtrusive fix that would be
acceptable to all and that minimises the risk of breaking some unknown
use case.

Debian did say that they'd consider patches, so I think we should
definitely first try to get their review (if that doesn't take too long)
to avoid sending Ubuntu down a path that diverges from Debian.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1257082

Title:
  MAAS does not use NTP servers specified in DHCPD options

Status in MAAS:
  Invalid
Status in “isc-dhcp” package in Ubuntu:
  Invalid
Status in “ntp” package in Ubuntu:
  Confirmed
Status in “isc-dhcp” source package in Precise:
  New
Status in “ntp” source package in Precise:
  In Progress
Status in “isc-dhcp” source package in Trusty:
  New
Status in “ntp” source package in Trusty:
  In Progress
Status in “ntp” package in Debian:
  New

Bug description:
  [Impact]

  MAAS-deployed systems *that do not have persistent RTCs* (unusual)
  have difficulty with time and authentication, generally making these
  nodes unusable.

  [Workaround]

  See comment #8.

  [Original Description]

  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:

  root at maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;

  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name "mgmt";
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;

    pool {
      range 192.168.0.1 192.168.255.253;
      deny unknown-clients;
    }
  }

  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name "maas";
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;

    pool {
      range 10.255.1.0 10.255.255.254;
      deny unknown-clients;
    }
  }

  I have also verified the parameter is being sent to a client’s DHCP
  lease:

  ubuntu at sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface "eth0";
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name "maas";
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }

  Even so, the date on the target node is still incorrect.

  ubuntu at sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000

  The ntpdate defaults are the following (unchanged from MAAS defaults):

  ubuntu at sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.

  # Set to "yes" to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes

  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS="ntp.ubuntu.com"

  # Additional options to pass to ntpdate
  NTPOPTIONS=""

  And the DHCP generated NTP server file is correct:

  ubuntu at sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'

  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).

  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.

  -------------------------------------------------------------------------
  (contents of /var/log/maas/* is 125MB in size, will post data from there if requested)

  # dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name                               Version                                Architecture Description
  +++-==================================-======================================-============-==========================================================================
  ii  maas                               1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Server
  ii  maas-cli                           1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Client Tool
  ii  maas-cluster-controller            1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Cluster Controller
  ii  maas-common                        1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Server
  un  maas-dhcp                          <none>                                              (no description available)
  un  maas-dns                           <none>                                              (no description available)
  ii  maas-region-controller             1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Server
  ii  python-django-maas                 1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Server - (django files)
  ii  python-maas-client                 1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS API Client - (python files)
  ii  python-maas-provisioningserver     1.3+bzr1461+dfsg-0ubuntu2.2+tay.8      all          Ubuntu MAAS Server

  [Test Case]:

  1) Configure a MAAS server to pass via DHCP the following options:
      option ntp-servers your-ntp-server-address.
  2) Boot a new MAAS node that do not have persistent RTC.
  3) Check that the contents of /var/lib/ntpdate/default.dhcp exists after boot and has the correct ntp-servers value.
  3) Check that the `date` is correct according to your DHCP defined ntp-servers.
  4) If the date is correct according to your DHCP defined ntp-servers, the problem is fixed.

  Regression :

  None expected since if NTPDATE_USE_NTP_CONF is set to YES, and some of
  the default ntp.conf files is found that will be used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1257082/+subscriptions



More information about the Ubuntu-sponsors mailing list