On Tue, Aug 04, 2020 at 05:11:49PM +0200, Miroslav Lichvar wrote: > I'm considering to split the default configuration file in the chrony > package to make it easier for vendors, products, and configuration > tools to override some specific settings (like the default NTP > servers) by dropping a file into a directory, instead of having to > modify a packaged config file. It seems to be a modern trend, used > by many packages in Fedora, and I have received some RFEs to adopt > in chrony. > > The default /etc/chrony.conf would just have a single directive > loading configuration fragments from /etc/chrony.d and > /var/lib/chrony.d (and maybe also /var/run/chrony.d). It's nice to not require any files in /etc (so for example the admin can do 'rm -rf /etc/*' to restore vendor defaults). So instead of using /etc/chrony.conf to load other files, please consider just building this logic directly into the code. There is also no need to make those config paths configurable. As to the locations to look at: /usr/lib or /usr/share (packaged distro defaults), /usr/local/lib or /usr/share (local installed defaults), /etc (admin overrides), /run (temporary overrides) are the standard prefixes to look at. /var/lib is for persistent application state, not config. > My concern is that it will basically break all existing tools that > need to check and/or modify the configuration (e.g. anaconda). They > will need to know the naming of the files which have specific settings > in order to override them, or implement a parser duplicating the > chronyd logic to figure out which files are loaded from where. The whole goal of the config-in-dropin-files-logic is that anaconda wouldn't parse existing config, it would just write /etc/chrony.d/50-anaconda.conf that would override only the parts it cares about. Also, please don't invent a new logic — just follow the same one that systemd does [1]. This has the advantage that if something *needs* to look all of config, it can reuse what an existing loader. Also, admins don't need to learn a new set of rules. Ideally, 'systemd-analyze cat-config chrony.conf' would just work. > Also, > I'm not sure how user-friendly this is for regular users who modify > the configuration manually. > > Are there any recommendations for switching an existing single-config > package to a fully fragmented configuration? Is it worth the trouble, > or do you have any other suggestions? Yes, it's definitely worth the trouble, it makes many things easier and more robust. Zbyszek [1] We don't have a nice description of the logic anywhere. systemd.unit(5) is the canonical source, but there there are many complications which don't matter in the general case. Actually zram-generator.conf(5) which was added recently seems to be a better reference: https://github.com/systemd/zram-generator/blob/master/man/zram-generator.conf.md. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
