Bug 1956320

Summary: RFE: Enable /etc/chrony.d/*.conf by default
Product: Red Hat Enterprise Linux 8 Reporter: Jakub Hrozek <jhrozek>
Component: chronyAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED NOTABUG QA Contact: rhel-cs-infra-services-qe <rhel-cs-infra-services-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3   
Target Milestone: beta   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-03 14:44:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jakub Hrozek 2021-05-03 13:23:25 UTC
Description of problem:
It would be nice to create the /etc/chrony.d directory, even if empty and include it from the main config file by default.

This would make configuring chrony on RHCOS/CoreOS much easier -- the way to configure RHCOS is to drop files through declarative objects called MachineConfigs and at the moment they only allow setting whole contents of files, not e.g. "make sure a file contains a line foo".

Having a mostly distribution-static chrony.conf with local overrides in the include directory would make life easier for us. We can create the chrony.conf file with "include /etc/chrony.d" ourselves, but because MachineConfig allows to only replace a whole file, this means we need to keep up with any changes to distribution chrony.conf just to add the include dir.

Version-Release number of selected component (if applicable):
whatever is the latest in RHEL-8

How reproducible:
always

Steps to Reproduce:
1. grep include /etc/chrony.conf
2.
3.

Actual results:
include not present

Expected results:
include is enabled by default

Additional info:
More detailed information on why this RFE would help us can be found at https://bugzilla.redhat.com/show_bug.cgi?id=1953277#c1

Comment 1 Miroslav Lichvar 2021-05-03 14:00:12 UTC
There was a similar request in bug #1828434.

The main problem is that this would be an incompatible change, requiring all tools that inspect or modify chrony configuration to be updated. Pretty much everything works only with that single chrony.conf file and ignores the includefile or the new confdir/sourcedir directives. For example, if you added a file to specify some NTP servers, they wouldn't be visible to the other tools, which could easily lead to unexpected configurations. The default servers and other default settings would need to be in separate files with well-known names, so the tools could disable them by adding files to a different directory using the same names.

This was discussed at different places, even the upstream list, but so far there was no consensus reached on what is the best way to do this.

Comment 2 Jakub Hrozek 2021-05-03 14:23:39 UTC
(In reply to Miroslav Lichvar from comment #1)
> There was a similar request in bug #1828434.
> 

Oops, sorry, I only checked for open bugs before filing this. In the bug you also said that this is not feasible for a minor release. Do you think a change like this might be better suitable for a major release?

> The main problem is that this would be an incompatible change, requiring all
> tools that inspect or modify chrony configuration to be updated. Pretty much
> everything works only with that single chrony.conf file and ignores the
> includefile or the new confdir/sourcedir directives. For example, if you
> added a file to specify some NTP servers, they wouldn't be visible to the
> other tools, which could easily lead to unexpected configurations. The
> default servers and other default settings would need to be in separate
> files with well-known names, so the tools could disable them by adding files
> to a different directory using the same names.
> 

I see the side of this argument, but it also seems like those tools are not well equipped to e.g. changing defaults or new options added. Wouldn't it be more systematic to add an argument like --dump-config to chronyd that would also print all the defaults?

> This was discussed at different places, even the upstream list, but so far
> there was no consensus reached on what is the best way to do this.

OK, I see. Feel free to close this bug as well, then.

Comment 3 Miroslav Lichvar 2021-05-03 14:44:51 UTC
(In reply to Jakub Hrozek from comment #2)
> Do you think a change like this might be better suitable for a major release?

Yes, that might be possible, but we would need the new concept of configuring chrony to be defined first and then modify all the existing tools to follow that.

> I see the side of this argument, but it also seems like those tools are not
> well equipped to e.g. changing defaults or new options added. Wouldn't it be
> more systematic to add an argument like --dump-config to chronyd that would
> also print all the defaults?

In latest chronyd there is the -p option to print the whole configuration from all files combined. That's great for users, but I'm not sure if helps tools intended to add, modify and remove NTP servers. They would need to know which files have precedence over others and which files they are supposed to modify. This might be different in different distributions.

My current recommendation is to write the config from scratch, like the ansible timesync role does for instance. An empty config is a safe config. If you need a template, use the packaged default chrony.conf with all server/peer/pool/refclock directives removed.

Comment 4 Jakub Hrozek 2021-05-03 15:19:07 UTC
(In reply to Miroslav Lichvar from comment #3)
> My current recommendation is to write the config from scratch, like the
> ansible timesync role does for instance. An empty config is a safe config.
> If you need a template, use the packaged default chrony.conf with all
> server/peer/pool/refclock directives removed.

Thanks, this sounds useful!