On Tue, Aug 4, 2020 at 1:28 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. The libeconf library[0][1] makes it easy to implement the systemd-like drop-in and override configuration behavior. This is how PAM does it[2], and util-linux[3] will as well. I would suggest considering implementing it in chrony by using this library, as it simplifies the effort required to implement this behavior. [0]: https://github.com/openSUSE/libeconf [1]: https://fosdem.org/2020/schedule/event/ilbsclte/ [2]: https://github.com/linux-pam/linux-pam/commit/65d6735c5949ec233df9813f734e918a93fa36cf [3]: https://github.com/karelzak/util-linux/commit/d5e8818e03e581e2e4fab8942a13a4c6731f5da9 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
