we don't use it any more.
(I've Bcc'd the Debian NTP Team because it seemed appropriate to stay
connected and for them to be aware of this discussion, but I don't
expect any action from Debian on this - this is mostly a discussion for
Ubuntu. This thread can be followed at
https://lists.ubuntu.com/archives/ubuntu-devel/)
There are a bunch of outstanding bugs[1][2][3] in the behaviour of the
ntpdate package. When Christian merged ntp this cycle[4], he found/wrote
fixes for these bugs. He has sent patches to Debian, but they're pushed
for time at the moment, so I don't expect these patches to be processed
by Debian any time soon[5].
Please note that nothing in this post applies to bugs or maintenance of
ntpd itself, just ntpdate. ntpdate is actually deprecated in favour of
options to ntpd to run in "ntpdate mode", but that also has no real
bearing on my discussion here. The bugs apply when using "ntpdate mode"
functionality (single shot, jump time) from the ntpdate package in
particular conditions. Various behaviour changes when the ntp package is
installed, but the bugs all relate to ntpdate-like behaviour. The bugs
would generally remain even if we switch from using ntpdate directly to
"ntpd in ntpdate mode".
Since we switched to systemd, we use systemd-timesyncd by default if the
ntp package (shipping ntpd) isn't installed, and we no longer seed
ntpdate*. So nothing ntp gets installed by default†, only
systemd-timesyncd to provide a basic time sync service. Users can
install the ntp (for ntpd) or ntpdate packages if they wish. This
applies to both desktop and server in Xenial. On Precise and Trusty,
ntpdate is seeded and thus installed by default, there is no
systemd-timesyncd, and users can of course still install ntpd if they
wish.
From the server perspective, we think that there is almost no
circumstance in which a user would want the ntpdate package, since that
could cause server time to jump around. Unless a server is mostly
offline, we think that systemd-timesyncd or ntpd (in regular,
non-jumping mode) make far more sense.
Since we seem to be heading away from ntpdate, I don't want to introduce
new deltas in Ubuntu relating to ntpdate bugs, unless some other team
volunteers to maintain them. I think Christian's patches all look good,
but some of them necessarily introduce new configuration directives or
otherwise assign extra meaning to them, which could be different to what
Debian ends up doing. So this could lead to a maintenance and upgrade
path headache if we end up diverging from Debian as a consequence. If we
SRU them, then I think there's a risk that the consequent change in
behaviour may surprise or regress some users, even though for other
users the bugfix is supposed to change that behaviour.
For the development release: I asked Christian to drop these fixes from
his merge, and to leave it to Debian to pick up his patches in their own
time. If consensus from this thread is to introduce deltas, we can of
course upload anyway.
For the stable releases: Precise and Trusty are still supported, so with
ntpdate installed there by default, this does have consequences if we
want to SRU these bugfixes. I propose that SRUs are not necessary.
Since, going forward, we don't think ntpdate is necessary in most use
cases, I propose that affected users on Precise and Trusty just disable
ntpdate (it can't easily be removed as it is seeded and ubuntu-minimal
depends on it). Where MAAS deploys Precise or Trusty and if MAAS users
are affected by ntpdate bugs, I propose that MAAS arranges for ntpdate
to be disabled on install via cloud-init.
To disable ntpdate, depending on the exact functionality that needs to
be disabled (which depends on the bug you're hitting), users can set
NTPOPTIONS="-q" in /etc/default/ntpdate (it will still query but not
change the system time). Alternatively,
/etc/dhcp/dhclient-exit-hooks.d/ntpdate and /etc/network/if-up.d/ntpdate
can be disabled, for example by deleting them. Since these are
conffiles, modifications should be preserved correctly.
If correct ntpdate behaviour in relation to these bugs does really
matter to some users, I'd love to hear from them to understand their use
cases, and see which team might be appropriate to maintain any
additional delta from Debian as might be necessary. In the meantime, I
propose to "Won't Fix" these bugs with reference to this thread.
Any objections?
* dovecot-core recommends ntpdate for some reason; perhaps we should
consider dropping this.
† though ceph recommends ntp, and mythbuntu-desktop and
ubuntu-mate-desktop also pull ntp in.
[1] https://launchpad.net/bugs/427775
[2] https://launchpad.net/bugs/1129696
[3] https://launchpad.net/bugs/1206164
[4] https://code.launchpad.net/~paelzer/ubuntu/+source/ntp/+git/ntp/+merge/299122
[5] https://lists.alioth.debian.org/pipermail/pkg-ntp-maintainers/2016-June/004282.html
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
