DHCP-received NTP servers override the configuration of the NTP charm

Bug #1758775 reported by Paul Gear on 2018-03-26
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
NTP Charm
Medium
Haw Loeung

Bug Description

Example from GCE, but could be seen in MAAS/OpenStack or any other environment where NTP server addresses are supplied via DHCP: https://pastebin.ubuntu.com/p/TkjfzgbBhW/

When a user configures NTP with this charm, they should reasonably expect their configuration to be reliably applied rather than overridden by their cloud provider.

Related branches

Paul Gear (paulgear) wrote :

I intend to integrate a fix for this with the work to enable chrony support for bionic.

Changed in ntp-charm:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Paul Gear (paulgear)
Jacek Nykis (jacekn) wrote :

I saw the same problem on GCE instances after reboot:
/usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 112:116

 I restarted ntp and it came back fine:
/usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:116

Paul Gear (paulgear) wrote :

Just restarting ntp may not fix this; it's recommended to touch /etc/ntp.conf before doing so.

Junien Fridrick (axino) wrote :

Indeed got hit by this bug today on GCE.

Paul Gear (paulgear) on 2019-02-25
Changed in ntp-charm:
assignee: Paul Gear (paulgear) → nobody
Haw Loeung (hloeung) wrote :

This is actually LP: #1823098. I don't think this is a charm problem, I mean, it could touch ntp.conf on update-status hook but that's ugly.

Paul Gear (paulgear) wrote :

I don't think this is really the same problem. The init script for NTP is designed to honour the settings provided by the DHCP client. In most cases, this is expected, but when the charm is configured, users expect the charm to manage the local settings for them without needing to override the DHCP client. I think the preferred solution would be for the charm to disable the DHCP client from modifying the NTP configuration by removing "ntp-servers" from the "request" entry in /etc/dhcp/dhclient.conf.

Haw Loeung (hloeung) wrote :

Even with removing 'ntp-servers' from /etc/dhcp/dhclient.conf, /var/lib/ntp/ntp.conf.dhcp is written out. Steps to reproduce:

Current:

| ubuntu@juju-dca1e3-12:~$ ls -la /var/lib/ntp/ntp.conf.dhcp
| -rw-r--r-- 1 ntp ntp 2804 Feb 23 2018 /var/lib/ntp/ntp.conf.dhcp

Update removing 'ntp-servers':

| ubuntu@juju-dca1e3-12:~$ sudo vi /etc/dhcp/dhclient.conf
| (edit edit edit)

Restart networking:

| ubuntu@juju-dca1e3-12:~$ sudo service networking restart

Confirm dhclient restarted:

| ubuntu@juju-dca1e3-12:~$ ps afxuww | grep dhcl
| root 2864 0.0 0.0 16132 928 ? Ss 04:41 0:00 /sbin/dhclient -1 -v -pf /run/dhclient.ens4.pid -lf /var/lib/dhcp/dhclient.ens4.leases -I -df /var/lib/dhcp/dhclient6.ens4.leases ens4

Check timestamp / date:

| ubuntu@juju-dca1e3-12:~$ ls -la /var/lib/ntp/ntp.conf.dhcp
| -rw-r--r-- 1 root root 2804 Oct 28 04:41 /var/lib/ntp/ntp.conf.dhcp

It's actually because ntp_servers_setup_add() in /etc/dhcp/dhclient-exit-hooks.d/ntp writes that out no matter what.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ntp (Ubuntu):
status: New → Confirmed
Haw Loeung (hloeung) on 2020-01-07
Changed in ntp-charm:
assignee: nobody → Haw Loeung (hloeung)
status: Triaged → In Progress
no longer affects: ntp (Ubuntu)
Haw Loeung (hloeung) on 2020-01-07
Changed in ntp-charm:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers