ntp: changing the default config from server to pool broke the dhcp hook
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ntp (Debian) |
Fix Released
|
Unknown
|
|||
ntp (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Unassigned |
Bug Description
In 1:4.2.8p3+dfsg-1, the default config was changed to
"Use pool instead of server". This needs a corresponding
update to /etc/dhcp/
DHCP specified servers now get added to the default pool
config instead of replacing them.
This affects Xenial only as the Yakkety build includes the upstream fix (1:4.2.8p7+dfsg-1).
Original Debian busg https:/
& https:/
[Test Case]
philroche: This surfaced for me initially while testing on GCE. On GCE NTP servers are provided via DHCP so the easiest test case is to launch an instance on GCE without our workaround configured.
One such image is "daily-
To start an instance of this image:
`gcloud compute instances create daily-ubuntu-
Then run `ntpq -p` which should, once ntp is patched, return only one entry 'metadata.google' and should not return any of the ubuntu NTP pools.
[Regression Potential]
As noted in comments #1 and #2, this SRU might surface an issue if the user is receiving a broken set of NTP servers.
And as noted in comment #4, some people might be hackishly using the distinction between spaces and tabs in the config file to trick our current hook. Debian has gotten rid of that distinction, so that hack will stop working on distro-upgrade anyway. The fix is *probably* going to help more people who unintentionally mixed the two up rather than the few that are relying on that bug. But that bit can be easily dropped from the SRU if ya like.
Changed in ntp (Ubuntu): | |
importance: | Undecided → Medium |
Changed in ntp (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in ntp (Debian): | |
status: | Unknown → Fix Released |
description: | updated |
description: | updated |
tags: | added: id-58e22b4afdee5f97b3bfbfd7 |
Thank you for identifying this. I agree it makes sense to fix it in Xenial. Though I wonder about how the change might adversely impact existing users.
For example, if a DHCP user is receiving a broken set of NTP servers that doesn't work, currently his NTP won't be broken because the default set will be used
But with this fixed, the default set will stop being used, and his NTP will appear to break. Though the root cause is that his DHCP or network was misconfigured, it would be the SRU that causes the problem to emerge.
In principle I think this is OK, but we should point it out in "Regression Potential", and I appreciate more opinions.