On Tuesday, August 4, 2020 9:32:35 AM MST Zbigniew Jędrzejewski-Szmek 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.
Why would you move configuration files from /etc? If this is to be done, please leave the files in /etc and symlink at the new location, or the reverse, so sysadmins don't have to update all of our carefully written scripts and learn yet another location across the various versions of systems used. This wouldn't make things easier for admins, it would make it more difficult. Right now, we know where the config file currently being read by the software is. It's easy to check for it, and see what's in it. Defaults go in /etc/default or just the default config file, so that it's there only if the admins don't change it. Please don't change this, this is really easy to work with. > 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. Anaconda doesn't need to parse existing config, as far as I know, it just writes out new config. Anaconda is run at install-time, where the existing config doesn't really matter. > 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. Please don't invent a new logic, especially the one that systemd does. This makes it very difficult to figure out where in the world the configuration file for a given program is. With systemd, sure, it's not so bad, as the command will tell you where the unit file is. There's no such command for, for example, chronyd, httpd or any other program that itself isn't using such a convoluted configuration system. Even systemd wouldn't work if you blew away / etc. > > 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. Who does this make things easier for? How does added complexity make this more robust? -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
