Bug 1956320
Summary: | RFE: Enable /etc/chrony.d/*.conf by default | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jakub Hrozek <jhrozek> |
Component: | chrony | Assignee: | 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
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. (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. (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. (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! |