| 2024-01-10 12:21:37 |
Ankush Pathak |
bug |
|
|
added bug |
| 2024-01-10 16:14:31 |
Catherine Redfield |
bug |
|
|
added subscriber Catherine Redfield |
| 2024-01-23 15:15:23 |
Launchpad Janitor |
chrony (Ubuntu): status |
New |
Confirmed |
|
| 2024-01-24 19:12:22 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Ubuntu Server |
| 2024-01-24 19:12:29 |
Sergio Durigan Junior |
chrony (Ubuntu): status |
Confirmed |
Triaged |
|
| 2024-02-14 18:37:15 |
Ankush Pathak |
attachment added |
|
lp-2048876-disallow-name-conf.debdiff https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2048876/+attachment/5746318/+files/lp-2048876-disallow-name-conf.debdiff |
|
| 2024-02-14 20:17:34 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2024-02-14 20:17:37 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2024-02-16 17:51:42 |
Robie Basak |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2024-02-22 00:02:29 |
Ankush Pathak |
attachment added |
|
lp-2048876-move-ntp-sources.debdiff https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2048876/+attachment/5748271/+files/lp-2048876-move-ntp-sources.debdiff |
|
| 2024-02-28 02:06:54 |
Bryce Harrington |
tags |
patch |
patch server-todo |
|
| 2024-02-28 02:07:24 |
Bryce Harrington |
chrony (Ubuntu): assignee |
|
Ankush Pathak (ankushpathak) |
|
| 2024-02-28 02:07:28 |
Bryce Harrington |
chrony (Ubuntu): importance |
Undecided |
High |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
bug task added |
|
chrony (Ubuntu Mantic) |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
nominated for series |
|
Ubuntu Focal |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
bug task added |
|
chrony (Ubuntu Focal) |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
nominated for series |
|
Ubuntu Bionic |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
bug task added |
|
chrony (Ubuntu Bionic) |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-02-28 02:07:45 |
Bryce Harrington |
bug task added |
|
chrony (Ubuntu Jammy) |
|
| 2024-02-28 02:07:58 |
Bryce Harrington |
nominated for series |
|
Ubuntu Noble |
|
| 2024-02-28 02:07:58 |
Bryce Harrington |
bug task added |
|
chrony (Ubuntu Noble) |
|
| 2024-02-28 02:09:05 |
Bryce Harrington |
description |
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/chrony.conf. This will possibly lead to a prompt during an Ubuntu release upgrade and during an unattended chrony security upgrade.
We are trying to move all configuration changes to their respective *.d directories. See: https://bugs.launchpad.net/livecd-rootfs/+bug/1968873
We test for modified chrony config file by invoking `sudo md5sum --quiet --check /var/lib/ucf/hashfile`.
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/chrony.conf. There doesn't seem to be an alternative way to reset the pool set used by chrony through a configuration in *.d directory.
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/chrony.conf with another file that has required server entry and no pool entries. I believe this cannot be done through an override in *.d directory without touching /etc/chrony/chrony.conf.
This request perhaps can be extended to ensure that "negating" a configuration in the default /etc/chrony/chrony.conf should be possible through a configuration in /etc/chrony/*.d directory. |
[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/chrony.conf. This will possibly lead to a prompt during an Ubuntu release upgrade and during an unattended chrony security upgrade.
We are trying to move all configuration changes to their respective *.d directories. See: https://bugs.launchpad.net/livecd-rootfs/+bug/1968873
We test for modified chrony config file by invoking `sudo md5sum --quiet --check /var/lib/ucf/hashfile`.
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/chrony.conf. There doesn't seem to be an alternative way to reset the pool set used by chrony through a configuration in *.d directory.
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/chrony.conf with another file that has required server entry and no pool entries. I believe this cannot be done through an override in *.d directory without touching /etc/chrony/chrony.conf.
This request perhaps can be extended to ensure that "negating" a configuration in the default /etc/chrony/chrony.conf should be possible through a configuration in /etc/chrony/*.d directory. |
|
| 2024-05-22 15:13:42 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-07-09 23:14:32 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ankushpathak/ubuntu/+source/chrony/+git/chrony/+merge/469064 |
|
| 2024-07-10 21:34:24 |
Ankush Pathak |
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/chrony.conf. This will possibly lead to a prompt during an Ubuntu release upgrade and during an unattended chrony security upgrade.
We are trying to move all configuration changes to their respective *.d directories. See: https://bugs.launchpad.net/livecd-rootfs/+bug/1968873
We test for modified chrony config file by invoking `sudo md5sum --quiet --check /var/lib/ucf/hashfile`.
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/chrony.conf. There doesn't seem to be an alternative way to reset the pool set used by chrony through a configuration in *.d directory.
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/chrony.conf with another file that has required server entry and no pool entries. I believe this cannot be done through an override in *.d directory without touching /etc/chrony/chrony.conf.
This request perhaps can be extended to ensure that "negating" a configuration in the default /etc/chrony/chrony.conf should be possible through a configuration in /etc/chrony/*.d directory. |
[Impact]
Currently, the default chrony.conf configures a set of pools. If a user wishes to use only a specific server/server pool or not use the default servers at all, they will need to modify /etc/chrony/chrony.conf. This will possibly lead to a prompt during an Ubuntu release upgrade and during an unattended chrony security upgrade.
There is an effort to move all configuration changes to their respective *.d directories. See: https://bugs.launchpad.net/livecd-rootfs/+bug/1968873. This is also aimed at potentially supporting automated distro upgrades.
CPC test for modified ucf tracked chrony config file by invoking `sudo md5sum --quiet --check /var/lib/ucf/hashfile`. This test fails at the moment due to required changes made at image build-time or during instance boot to chrony time source in /etc/chrony/chrony.conf configuration.
Listing the cases where moving required chrony configuration changes to a *.d config is not possible
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/chrony.conf. There doesn't seem to be an alternative way to reset the pool set used by chrony through a configuration in *.d directory.
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/chrony.conf with another file that has required server entry and no pool entries. This cannot be done through an override in *.d directory without touching /etc/chrony/chrony.conf.
[Workaround]
No known workaround
[Test Case]
* Upgrade a GCE Ubuntu instance from any supported release to Noble and the upgrade produces a chrony.conf ucf prompt.
* Run `sudo md5sum --quiet --check /var/lib/ucf/hashfile` on a GCE noble instance.
[Where Problems Could Occur]
A case where debconf configuration that overrides default values prevents package installation scripts from configuring any chrony time sources.
This unlikely to happen without user intention in non-cloud environments.
Some cloud image builds are likely to do this on purpose to be able to configure cloud provider appropriate time sources.
CPC run tests on Ubuntu images for most cloud providers to ensure that chrony is configured with time sources.
----------------------------------------
There is no request at this time to SRU the fix for this bug. Current intention is to land this in devel. The description follows the SRU template, just to better organize the bug summary.
----------------------------------------
[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/chrony.conf. This will possibly lead to a prompt during an Ubuntu release upgrade and during an unattended chrony security upgrade.
We are trying to move all configuration changes to their respective *.d directories. See: https://bugs.launchpad.net/livecd-rootfs/+bug/1968873
We test for modified chrony config file by invoking `sudo md5sum --quiet --check /var/lib/ucf/hashfile`.
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/chrony.conf. There doesn't seem to be an alternative way to reset the pool set used by chrony through a configuration in *.d directory.
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/chrony.conf with another file that has required server entry and no pool entries. I believe this cannot be done through an override in *.d directory without touching /etc/chrony/chrony.conf.
This request perhaps can be extended to ensure that "negating" a configuration in the default /etc/chrony/chrony.conf should be possible through a configuration in /etc/chrony/*.d directory. |
|
| 2024-07-16 18:50:50 |
Brian Murray |
chrony (Ubuntu Mantic): status |
New |
Won't Fix |
|
