Comment 14 for bug 2048876

It's going to have to land in Ubuntu directly regardless of what's done. The package already has delta so even if this is done in Debian it'd have to get patched in for Ubuntu.

This fix probably needs to be thought of in several discrete chunks. The moving of the config snippet out of chrony.conf to a file in sources.d/ is one component; this one is what I was referring to in that the sources.d/ directory is already provided for in the Debian directory, and our config snippet isn't upstreamable to them, so at least this particular component is not something they'd be interested in.

Another component here is the addition of debconf questions, which came up in discussion with my teammates today. The essence of the prompt desiring to be solved here, as I understand it, is to enable configuration customization to work more seamlessly and in particular to reduce interactive prompting. Adding interactive debconf questions feels not in that spirit, maybe just shifting the prompting from one use case to others or moving it from upgrade time to installation time. If that's true, wouldn't it be better to look for ways to avoid prompts at all, at least for use cases we understand well?

Robie shared one idea, which I hope he won't mind me quoting verbatim:

> I would add a debconf + ucf mechanism to maintain a file in there called /etc/chrony/sources.d/from-debconf. By debconf, this could either be disabled (don't attempt to create the file), Ubuntu's default (make it the same as our defaults), or cloud-specific (use some cloud-specific file). Then ucf would maintain the same file but with different contents depending on debconf configuration, defaulting to Ubuntu's default.
> If a user customises the file using debconf, then great that'll work. If the user customises the file by hand, or deletes it, then ucf would do the right thing.
> Especially as ucf is used already, this shouldn't be burdensome.
> In this case, the debconf would be a multi-select against things like "do nothing", "ubuntu", "gce", "aws region a defaults" or whatever, and there would only need to be a single setting.
> However, we'd need to figure out how that would interact with what cloud-init might be doing already. And separately, if cloud-init does support customisation, then surely clouds should be using that via vendordata rather than doing something custom at image generation time?
> Here's cloud-init's implementation documentation: https://cloudinit.readthedocs.io/en/latest/reference/modules.html#ntp
> Looks like that has chrony support, too, and it expects to overwrite chrony.conf.

Unfortunately, we don't know of an existing package following this ucf + debconf style; most rely on straight ucf only.

Also, it sounds like if cloud-init relies on modifying chrony.conf for it's settings, then your fix for this bug will also break them. So for example cloud-init's ntp module configuration would need to be considered in this.