[Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options
Robie Basak
1257082 at bugs.launchpad.net
Thu Sep 11 15:56:50 UTC 2014
One catch with my approach is that setting NTPDATE_USE_NTP_CONF=yes
might mean "use /var/lib/ntp/ntp.conf.dhcp", and that would break. But
maybe this file won't exist or is not useful if /etc/ntp.conf doesn't
exist?
--
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