On Tue, Aug 04, 2020 at 06:26:37PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
> > 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.
>
> Backwards compatiblity should be kept obviously. In systemd we look at
> {/usr,/usr/local,/etc,/run}/foo.conf and
> {/usr,/usr/local,/etc,/run}/foo.conf.d/*.conf, so foo.conf is the main
> config file, while the "drop-ins" in /etc/ have higher priority and
> server as overrides. This is backwards compatible with having just
> /etc/foo.conf.
I don't see how that works. If I hardcoded the paths and split
/etc/foo.conf into several /usr/lib/foo.conf.d/*.conf fragments, or
any other package dropped a file in that directory, there would be
additional settings applied from those fragments even if the user
had an old /etc/foo.conf file, right? The user would need to figure
out what are those additional settings and revert them in /etc. That
would not be a great experience.
If the fragments were explicitly loaded from the new default
/etc/foo.conf, it would be obvious to a user merging the
configuration, and it wouldn't change anything for users keeping their
old config not loading the fragments.
Also, dropping /etc/foo.conf from the package would cause rpm to
rename it to .rpmsave, which would need to be worked around in a
scriptlet I guess.
> > 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.
>
> This can be handled by having a directive that means "wipe previous
> config for this setting". In systemd we handle this by treating an
> empty assignment as special:
> SystemCallFilter=open
> SystemCallFilter=
> SystemCallFilter=write
> SystemCallFilter=read close
> is equivalent to SystemCallFilter=write read close.
That looks hackish to me. We would need new directives to remove
previous settings in chrony. I thought the point of splitting the
default configuration was to get logical groups of settings that can
be overriden by adding a file to /etc/chrony.d, replacing a group of
related settings at once, which will work even when a newer package
adds more settings there. If I need to override individually each
directive from the default configuration, which I cannot predict for
future packages, then I don't see much of a point in this.
systemd doesn't seem to have fragmented configs. Maybe dovecot is a
better example. It has configuration split like this:
/etc/dovecot/conf.d/10-auth.conf
/etc/dovecot/conf.d/10-director.conf
/etc/dovecot/conf.d/10-logging.conf
/etc/dovecot/conf.d/10-mail.conf
/etc/dovecot/conf.d/10-master.conf
/etc/dovecot/conf.d/10-ssl.conf
/etc/dovecot/conf.d/15-lda.conf
/etc/dovecot/conf.d/15-mailboxes.conf
/etc/dovecot/conf.d/20-imap.conf
/etc/dovecot/conf.d/20-lmtp.conf
/etc/dovecot/conf.d/20-pop3.conf
/etc/dovecot/conf.d/20-submission.conf
/etc/dovecot/conf.d/90-acl.conf
/etc/dovecot/conf.d/90-plugin.conf
/etc/dovecot/conf.d/90-quota.conf
I was thinking about doing something similar for chrony, but move that
to /usr/lib. Maybe I'm mixing different incompatible ideas.
--
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
