Re: Switching package to fragmented default configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 04, 2020 at 04:32:35PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> 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.

That's possible (the paths could be hardcoded in the systemd unit
file), but is it a good idea to force the users to use the new system?
If someone has a modified config, or is using one of the many ansible
roles for configuring NTP for example, why should it stop working? We
don't have to break configuration tools that just generate a config
from scratch.

> > 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.

The trouble is that a fragment having a different name cannot disable
servers specified in a different fragment. If anaconda wanted to
override the default servers, it would need to know the name of the
fragment. In some cases users/vendors/products may want to specify
additional servers, sometimes replace them.

> 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.

I was following the liboverdrop logic, which probably adopted the
systemd convention. For printing the whole configuration there is now
a "chronyd -p" command. The systemd cat-config command seems to expect
the ini-style syntax. That's not going to work here.

-- 
Miroslav Lichvar
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux