** Description changed: [Impact] - * An explanation of the effects of the bug on users and - justification for backporting the fix to the stable release. + 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. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + 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] - * 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. + No known workaround [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. + * 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] - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + 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. - * 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 + ---------------------------------------- + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2048876 Title: Allow server and pool sources to be overridden through a conf.d or sources.d configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2048876/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
