Default Ubuntu configuration violates the ntp pool policy

Bug #1754358 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chrony (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I was made aware by chrony upstream (Thanks Miroslav), that the current default we have in Bionic is violating the ntp pool projects policy.

The default config has:
pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst

This could be a problem as the client will use 16 servers from the
pool, which is against their policy from [1]:

        So don't use more than four time servers in your
        configuration, and don't play tricks with burst or minpoll -
        all you will gain is extra load on the volunteer time servers.

I'd suggest to either keep only one pool line (preferrably the one
starting with 2 as it provides also IPv6 addresses), or replace "pool"
with "server".

Please note that "pool" works differently in ntpd and chronyd. ntpd
counts all servers together (their number is limited by the tos
maxclock setting), but chronyd handles each pool as an independent set
of up to (by default) four servers.

We discussed on that a bit already, mostly what would be better.

1. I thought about reading the man page at least it seems it seems that only "pool" has the
feature of "trying different sources until it finds some working".
I'm afraid with 4 server entries that might not work as well in terms of reliability.
But it turns out that a server specified with "server" is functionally equivalent to a pool
with maxsources equal to 1. chronyd will try to replace it with
another address if it becomes unrechable, falseticker, etc.

2. I wondered having just one line as a pool, isn't that vulnerable to dns attacks/outages
more easily?
That would be rare but true, so more entries might be better

3. there is one drawback of
 server 0.ubuntu.pool.ntp.org iburst maxsources 1
 server 1.ubuntu.pool.ntp.org iburst maxsources 1
 server 2.ubuntu.pool.ntp.org iburst maxsources 1
 server 3.ubuntu.pool.ntp.org iburst maxsources 1

The maximum number of used IPv6 servers would be limited to one as currently only 2.ubuntu... serves ipv6.

But the fix for that is to finally make them available as intended - I'll bump the original bug on this.

[1] http://www.pool.ntp.org/en/use.html

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI - the more ipv6 bug for ubuntu pools is bug 715141

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

@paelzer: Rather than the config you've mentioned above (3), wouldn't it be:

 server 0.ubuntu.pool.ntp.org iburst
 server 1.ubuntu.pool.ntp.org iburst
 server 2.ubuntu.pool.ntp.org iburst
 server 3.ubuntu.pool.ntp.org iburst

or:

 pool 0.ubuntu.pool.ntp.org iburst maxsources 1
 pool 1.ubuntu.pool.ntp.org iburst maxsources 1
 pool 2.ubuntu.pool.ntp.org iburst maxsources 1
 pool 3.ubuntu.pool.ntp.org iburst maxsources 1

I personally don't feel that it's great to have a maximum of 4 hosts, but pool resources are very limited, and badly-behaved clients can cause massive problems [1], so I understand the restriction.

Perhaps a config which would balance the requirements of v4-only, v6-only, and dual-stack hosts would be:

 pool 0.ubuntu.pool.ntp.org iburst maxsources 1
 pool 1.ubuntu.pool.ntp.org iburst maxsources 1
 pool 2.ubuntu.pool.ntp.org iburst maxsources 2
 pool ntp.ubuntu.com iburst

Revision history for this message
Paul Gear (paulgear) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

You are right, I actually meant to go with

 server 0.ubuntu.pool.ntp.org iburst
 server 1.ubuntu.pool.ntp.org iburst
 server 2.ubuntu.pool.ntp.org iburst
 server 3.ubuntu.pool.ntp.org iburst

maxsources is only allowed on pools and servers are mostly like "pool maxsource 1".

I like the balanced approach you suggested.
We own ntp.ubuntu.com and if you recommend it I assume we are ok with getting all 4 of them.
I'd also add a comment why we do so, therefore my suggestion would be:

# This will use (up to) 4 sources from ntp.ubuntu.com which are ipv6 enabled
# It will further get (up to) 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# And further (up to) 1 source from [01].ubuntu.pool.ntp.org (ipv4 only atm)
# This means by default an overall of 6 ipv6/ipv4 and 2 more ipv4 only sources and at the same time some protection against one of the entries being down (compare to just using one of the lines). See (LP: #1754358) for the discussion.
 pool ntp.ubuntu.com iburst
 pool 0.ubuntu.pool.ntp.org iburst maxsources 1
 pool 1.ubuntu.pool.ntp.org iburst maxsources 1
 pool 2.ubuntu.pool.ntp.org iburst maxsources 2

Opinions on that?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Ok, there were no further discussions on this, so we will go go with the last suggestion.
It should at least be better than what we have atm.

Prepping this to be part of the next fix upload.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Further extended the comment and explicitly set maxsources 4 on ntp.ubuntu.com to be more readable.

Changed in chrony (Ubuntu):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package chrony - 3.2-4ubuntu2

---------------
chrony (3.2-4ubuntu2) bionic; urgency=medium

  * Set -x as default if unable to set time (e.g. in containers) (LP: #1589780)
    Chrony is a single service which acts as both NTP client (i.e. syncing the
    local clock) and NTP server (i.e. providing NTP services to the network),
    and that is both desired and expected in the vast majority of cases.
    But in containers syncing the local clock is usually impossible, but this
    shall not break the providing of NTP services to the network.
    To some extent this makes chrony's default config more similar to 'ntpd',
    which complained in syslog but still provided NTP server service in those
    cases.
    - d/p/lp1589780-sys_linux-don-t-keep-CAP_SYS_TIME-with-x-option.patch:
      When dropping the root privileges, don't try to keep the CAP_SYS_TIME
      capability if the -x option was enabled. This allows chronyd to be
      started without the capability (e.g. in containers) and also drop the
      root privileges.
    - debian/chrony.service: allow the service to run without CAP_SYS_TIME
    - debian/control: add new dependency libcap2-bin for capsh (usually
      installed anyway, but make them explicit to be sure).
    - debian/chrony.default: new option SYNC_IN_CONTAINER to not fall back
      (Default off).
    - debian/chronyd-starter.sh: wrapper to handle special cases in containers
      and if CAP_SYS_TIME is missing. Effectively allows to run NTP server in
      containers on a default installation and avoid failing to sync time (or
      if allowed to sync, avoid multiple containers to fight over it by
      accident).
    - debian/install: make chronyd-starter.sh available on install.
    - debian/docs, debian/README.container: provide documentation about the
      handling of this case.
  * debian/chrony.conf: update default chrony.conf to not violate the policy
    of pool.ntp.org (to use no more than four of their servers) and to provide
    more ipv6 capable sources by default (LP: #1754358)

 -- Christian Ehrhardt <email address hidden> Fri, 16 Mar 2018 12:25:44 +0100

Changed in chrony (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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