MAAS does not use NTP servers specified in DHCPD options
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Invalid
|
Undecided
|
Unassigned | ||
isc-dhcp (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Precise |
New
|
Undecided
|
Unassigned | ||
Trusty |
New
|
Undecided
|
Unassigned | ||
ntp (Debian) |
New
|
Unknown
|
|||
ntp (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
Precise |
In Progress
|
Undecided
|
Unassigned | ||
Trusty |
In Progress
|
Undecided
|
Unassigned |
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@maas01:
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@
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-
option ntp-servers 172.31.
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@
Thu Jan 6 19:52:29 UTC 2000
The ntpdate defaults are the following (unchanged from MAAS defaults):
ubuntu@
# 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_
# List of NTP servers to use (Separate multiple servers with spaces.)
# Not used if NTPDATE_
NTPSERVERS=
# Additional options to pass to ntpdate
NTPOPTIONS=""
And the DHCP generated NTP server file is correct:
ubuntu@
# NTP server entries received from DHCP server
NTPSERVERS=
The culprit seems to be in how ntpdate-debian is programmed. the logic ignores /var/lib/
After examining the script further my recommendation would be for the /etc/dhcp/
-------
(contents of /var/log/maas/* is 125MB in size, will post data from there if requested)
# dpkg -l '*maas*'|cat
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii maas 1.3+bzr1461+
ii maas-cli 1.3+bzr1461+
ii maas-cluster-
ii maas-common 1.3+bzr1461+
un maas-dhcp <none> (no description available)
un maas-dns <none> (no description available)
ii maas-region-
ii python-django-maas 1.3+bzr1461+
ii python-maas-client 1.3+bzr1461+
ii python-
[Test Case]:
1) Configure a MAAS server to pass via DHCP the following options:
option ntp-servers your-ntp-
2) Boot a new MAAS node that do not have persistent RTC.
3) Check that the contents of /var/lib/
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_
affects: | isc-dhcp (Debian) → ntp (Debian) |
Changed in ntp (Debian): | |
status: | Unknown → New |
tags: | added: cts |
I should also mention that Juju deployment of charms fails when the time on the Juju bootstrap node is too old. This bug had the surprising consequence of not being able to deploy any charms to other MAAS nodes.