Allow server and pool sources to be overridden through a conf.d or sources.d configuration
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chrony (Ubuntu) |
Triaged
|
High
|
Ankush Pathak | ||
Bionic |
New
|
Undecided
|
Unassigned | ||
Focal |
New
|
Undecided
|
Unassigned | ||
Jammy |
New
|
Undecided
|
Unassigned | ||
Mantic |
New
|
Undecided
|
Unassigned | ||
Noble |
Triaged
|
High
|
Ankush Pathak |
Bug Description
[Impact]
* An explanation of the effects of the bug on users and
justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Workaround]
* If available, steps users can take to avoid the issue while waiting
for a fix. Emphasize whether the workaround sometimes or always
works, and any side effects or other caveats that may exist.
[Test Case]
* Detailed instructions how to reproduce the bug
* These should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Where Problems Could Occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
and address these questions in advance
[Original Report]
Currently, the default chrony.conf configures a set of pools. Confirmed this on a focal and jammy instance on GCP. If one wishes to use only a specific server/server pool or not use a server at all they will need to modify /etc/chrony/
We are trying to move all configuration changes to their respective *.d directories. See: https:/
We test for modified chrony config file by invoking `sudo md5sum --quiet --check /var/lib/
Listing the cases that I know where we are not able to move chrony configuration changes to a *.d config
1. Azure: Azure needs all default pool entries in chrony.conf disabled. This is currently done by commenting out the pool entries in /etc/chrony/
2. Google: GCP images need to set a single server source entry. This is done indirectly through the ntp cloud-init module configuration. The ntp module replaces the default /etc/chrony/
This request perhaps can be extended to ensure that "negating" a configuration in the default /etc/chrony/
tags: | added: server-todo |
Changed in chrony (Ubuntu): | |
assignee: | nobody → Ankush Pathak (ankushpathak) |
importance: | Undecided → High |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.