NTP Charm

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

Bug #1758775 reported by Paul Gear
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
NTP Charm
Fix Released
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

~hloeung/ntp-charm:master
Joel Sing (community): Approve (+1)
Canonical IS Reviewers: Pending requested
Diff: 32 lines (+21/-0)
1 file modified
reactive/ntp.py (+21/-0)
Revision history for this message
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)
Revision history for this message
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

Revision history for this message
Paul Gear (paulgear) wrote :

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

Revision history for this message
Junien F (axino) wrote :

Indeed got hit by this bug today on GCE.

Paul Gear (paulgear)
Changed in ntp-charm:
assignee: Paul Gear (paulgear) → nobody
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.