Switching package to fragmented default configuration

[Miroslav Lichvar]

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

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

Thanks,

-- 
Miroslav Lichvar

[Zbigniew Jędrzejewski-Szmek]

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

[Miroslav Lichvar]

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

[Chris Adams]

Once upon a time, Miroslav Lichvar <mlichvar(a)redhat.com&gt; said:
>  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. 
So, that brings up something I've been meaning to file a bug about:
anaconda has behavior around NTP that nothing else does.  If anaconda
gets NTP servers from DHCP, it deletes the pool entries from the default
config and replaces that with the DHCP-provided servers.  This is wrong;
it assumes that the installation network is the same as the production
network, and overrides default config without any prompt or kickstart
config.

When an operational system gets NTP servers from DHCP (e.g. via
NetworkManager), it does not touch the config in /etc; it instead
notifies the NTP service to add the server.

IMHO anaconda is just wrong to do this, and it breaks using an
installation network.  Right now, I have to hack around it in a
kickstart by telling anaconda to not configure NTP at all, but the
enable the service and add the package.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
>  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. 
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.

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

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

[Miroslav Lichvar]

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

[Neal Gompa]

On Tue, Aug 4, 2020 at 1:28 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; 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..... 
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/65d6735c5949ec233df9813f734...
[3]:
https://github.com/karelzak/util-linux/commit/d5e8818e03e581e2e4fab8942a1...



--
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

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.

[Samuel Sieb]

On 8/28/20 9:40 PM, John M. Harris Jr wrote:
>  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 
System defaults go in /usr/share/<app>.  Admin overrides go in /etc.

>  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. 
It should.  If not, that's where they want to get to.

[John M. Harris Jr]

On Saturday, August 29, 2020 1:00:17 AM MST Samuel Sieb wrote:
>  On 8/28/20 9:40 PM, John M. Harris Jr wrote:
>  
>  > 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
>  
>  System defaults go in /usr/share/<app>.  Admin overrides go in /etc. 
If you're going to put defaults anywhere, /etc is the most logical place. When 
admins want to override, they'll modify the files that are there. See, for 
example, /etc/resolv.conf, the file used to tell the system resolver what DNS 
servers to use. By default, it's generated by your installer or by 
NetworkManager. When modified, it's now using "admin overrides".

>  > 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.
>  
>  
>  It should.  If not, that's where they want to get to. 
What is the actual benefit of this? Needlessly breaking existing 
configuration, making it impossible to cleanly upgrade systems, 
or write logic that takes into account the existing configuration of a given 
program? If you blow away /etc/, you will have a well and truly broken system. 
If you want to start a configuration from scratch, re-install. There's nothing 
wrong with that approach, and it works very well. This has been the case for 
nearly three decades now.

-- 
John M. Harris, Jr.

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, 2020-08-29 at 11:02 -0700, John M. Harris Jr wrote:
>  On Saturday, August 29, 2020 1:00:17 AM MST Samuel Sieb wrote:
>  > On 8/28/20 9:40 PM, John M. Harris Jr wrote:
>  > 
>  > > 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
>  > 
>  > System defaults go in /usr/share/<app>.  Admin overrides go in
>  > /etc.
>  
>  If you're going to put defaults anywhere, /etc is the most logical
>  place. When 
>  admins want to override, they'll modify the files that are there.
>  See, for 
>  example, /etc/resolv.conf, the file used to tell the system resolver
>  what DNS 
>  servers to use. By default, it's generated by your installer or by 
>  NetworkManager. When modified, it's now using "admin overrides". 
And only way to get to the distribution defaults is to download RPM
with matching version, unpack it and get its /etc/foo.conf. When
default distribution configs are in /usr, then you can easily remove
config from /etc and that's it.

>  > > 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.
>  > 
>  > 
>  > It should.  If not, that's where they want to get to.
>  
>  What is the actual benefit of this? Needlessly breaking existing 
>  configuration, making it impossible to cleanly upgrade systems, 
>  or write logic that takes into account the existing configuration of
>  a given 
>  program? If you blow away /etc/, you will have a well and truly
>  broken system. 
>  If you want to start a configuration from scratch, re-install.
>  There's nothing 
>  wrong with that approach, and it works very well. This has been the
>  case for 
>  nearly three decades now. 
First of all, as long as /etc/foo.conf location stays same, it takes
precedence over the /usr configuration, so nothing will be broken on
the update.

>  -- 
>  John M. Harris, Jr.
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9KnEoACgkQEV1auJxc
> Hh7/lg/9HGg1AQL/xLQbYqq7iyta/dMxEoPslIMuMFo5q2Q5c4WkvIWRXBXTYdRU
> hPE9KeM2byOcQU6q3OVg6Rs6XsBDX9uCjPNYjLcMf/tOLBZ5YjGXqXcotbGRpj2q
> dJK4J8skSW2VybaFO0Gm7gygFZwJoWQqK/G/n3tfhNp4C2PFE//PJDzUP0hsZlgM
> S5K5qnpIW3JPIk9bnDBK8AUeJwZIXoDkzPX+rLUXv4RjmB+/vnNk5Qupbewq8uRT
> WHu+YdZNeFdq4PpUvb1zVZgbXBgg+kHpdd75Rmf2hgFsl33ZGTkjgNYFkSzxYaPt
> vY7728B5Y951dYASvlL/V0yWjtTplTOxySPTgCTMrOgBjvQQZW2cdGINSXT5UmHn
> tHlAGh+lrSIorLLN8tGHKr4nDAEv2VUIb87/K3rGABEQ41yXiSul+vDR/hdiXqai
> 3l5ksSu4hvNwU1R5kPjfFEW6soIjP8smplbyDXjSfzO5rUhZbxA+YjEcwOVBOtuv
> CJgKham4RXmVbPtXPHnsBL9YsDvhcH3SIzVZkpzPFCbJDYzJFbfI78n1J4cacxnF
> UWJN/+9HGvRSFAa9oiNR6Lprx3dX3Uo1DCT4+TL8aZsRFSd9UrblJ/loUALwxkpz
> QEYNRSH8c3SpPUhr8xsJZBKHbHQrX27L7Pyz1v9u/HoXBTb4HEQ=
> =mzaL
> -----END PGP SIGNATURE-----

[Colin Walters]

On Sat, Aug 29, 2020, at 2:19 PM, Igor Raits wrote:

>  And only way to get to the distribution defaults is to download RPM
>  with matching version, unpack it and get its /etc/foo.conf.  
On ostree-based systems, the defaults for /etc are in /usr/etc, so
you always have them - it needs this to do the "3 way merge" upgrade
for config files.

>  > What is the actual benefit of this? Needlessly breaking existing
>
>  > configuration, making it impossible to cleanly upgrade systems, 
>  > or write logic that takes into account the existing configuration of
>  > a given 
>  > program? If you blow away /etc/, you will have a well and truly
>  > broken system. 
>  > If you want to start a configuration from scratch, re-install.
>  > There's nothing 
>  > wrong with that approach, and it works very well. This has been the
>  > case for 
>  > nearly three decades now 
https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-an...
touches on some of the benefits of "fragmented" configs.

[John M. Harris Jr]

On Saturday, August 29, 2020 3:36:33 PM MST Colin Walters wrote:
>  On Sat, Aug 29, 2020, at 2:19 PM, Igor Raits wrote:
>  
>  
>  > And only way to get to the distribution defaults is to download RPM
>  > with matching version, unpack it and get its /etc/foo.conf. 
>  
>  
>  On ostree-based systems, the defaults for /etc are in /usr/etc, so
>  you always have them - it needs this to do the "3 way merge" upgrade
>  for config files.
>  
>  
>  > > What is the actual benefit of this? Needlessly breaking existing 
>  > > configuration, making it impossible to cleanly upgrade systems, 
>  > > or write logic that takes into account the existing configuration of
>  > > a given 
>  > > program? If you blow away /etc/, you will have a well and truly
>  > > broken system. 
>  > > If you want to start a configuration from scratch, re-install.
>  > > There's nothing 
>  > > wrong with that approach, and it works very well. This has been the
>  > > case for 
>  > > nearly three decades now
>  
>  
>  https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-an...
> hysteresis/
>  touches on some of the benefits of "fragmented" configs. 
Perhaps this should be done for the ostree-based systems, so it doesn't much 
up the ones people use commonly. Have the hip new way along the side, while 
doing things the simple, robust way elsewhere. This way, everyone benefits. 
Sysadmins don't have to deal with that nightmare, packagers don't have to deal 
with it, upstream software devs don't get patches flying in from all around to 
apply this to their software, and folks that want to give it a go can play 
around with the idea in a sandbox environment with little ramifications if it 
changes.

-- 
John M. Harris, Jr.

[David Tardon]

On Mon, 2020-08-31 at 00:08 -0700, John M. Harris Jr wrote:
>  On Saturday, August 29, 2020 3:36:33 PM MST Colin Walters wrote:
>  > https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-an...
>  > hysteresis/
>  > touches on some of the benefits of "fragmented" configs.
>  
>  Perhaps this should be done for the ostree-based systems, so it
>  doesn't much 
>  up the ones people use commonly. Have the hip new way along the side,
>  while 
>  doing things the simple, robust way elsewhere. 
The problem with this way is that it is simple, but *not* robust.
That's why I have to look for .rpmnew files after every update.

D.

[John M. Harris Jr]

On Monday, August 31, 2020 11:24:57 PM MST David Tardon wrote:
>  On Mon, 2020-08-31 at 00:08 -0700, John M. Harris Jr wrote:
>  
>  > On Saturday, August 29, 2020 3:36:33 PM MST Colin Walters wrote:
>  > 
>  > > https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-a
>  > > nti-> hysteresis/
>  > > touches on some of the benefits of "fragmented" configs.
>  > 
>  > 
>  > Perhaps this should be done for the ostree-based systems, so it
>  > doesn't much 
>  > up the ones people use commonly. Have the hip new way along the side,
>  > while 
>  > doing things the simple, robust way elsewhere.
>  
>  
>  The problem with this way is that it is simple, but *not* robust.
>  That's why I have to look for .rpmnew files after every update. 
That's to be expected. The package manager shouldn't destroy your config when 
the package has a different one, and it doesn't. You don't need to look for 
them though, just look at the output from `dnf` during the update.

-- 
John M. Harris, Jr.

[David Tardon]

Hello,

On Mon, 2020-08-31 at 23:46 -0700, John M. Harris Jr wrote:
>  On Monday, August 31, 2020 11:24:57 PM MST David Tardon wrote:
>  > On Mon, 2020-08-31 at 00:08 -0700, John M. Harris Jr wrote:
>  > 
>  > > On Saturday, August 29, 2020 3:36:33 PM MST Colin Walters wrote:
>  > > 
>  > > > https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-a
>  > > > nti-> hysteresis/
>  > > > touches on some of the benefits of "fragmented" configs.
>  > > 
>  > > Perhaps this should be done for the ostree-based systems, so it
>  > > doesn't much 
>  > > up the ones people use commonly. Have the hip new way along the
>  > > side,
>  > > while 
>  > > doing things the simple, robust way elsewhere.
>  > 
>  > The problem with this way is that it is simple, but *not* robust.
>  > That's why I have to look for .rpmnew files after every update.
>  
>  That's to be expected.  
Expected by whom? I for one don't see why I should have to manually
merge configuration changes to the end of times just because I have
changed a single option. I'd rather waste my time in other ways.

>  The package manager shouldn't destroy your config when 
>  the package has a different one, and it doesn't.  
It wouldn't have to care about my modifications if I could do them
separately from the distro-installed configuration file... IOW,
fragmented configuration allows me to do my own small modifications
while following the upstream/distro configuration changes. Which is
exactly the thing I want most of the time. It's a pity many projects
don't support it (yet).

>  You don't need to look for 
>  them though, just look at the output from `dnf` during the update. 
Gee, thank you very much for your advice... I'll certainly do just that
when I'll be upgrading my machines to F-33... But for the time being
I'll stick to running "git status" in /etc .-)

D.

[John M. Harris Jr]

On Wednesday, September 2, 2020 8:03:03 AM MST David Tardon wrote:
>  Hello,
>  
>  On Mon, 2020-08-31 at 23:46 -0700, John M. Harris Jr wrote:
>  
>  > On Monday, August 31, 2020 11:24:57 PM MST David Tardon wrote:
>  > 
>  > > On Mon, 2020-08-31 at 00:08 -0700, John M. Harris Jr wrote:
>  > > 
>  > > 
>  > > > On Saturday, August 29, 2020 3:36:33 PM MST Colin Walters wrote:
>  > > > 
>  > > > 
>  > > > > https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionab
>  > > > > le-a
>  > > > > nti-> hysteresis/
>  > > > > touches on some of the benefits of "fragmented" configs.
>  > > > 
>  > > > 
>  > > > Perhaps this should be done for the ostree-based systems, so it
>  > > > doesn't much 
>  > > > up the ones people use commonly. Have the hip new way along the
>  > > > side,
>  > > > while 
>  > > > doing things the simple, robust way elsewhere.
>  > > 
>  > > 
>  > > The problem with this way is that it is simple, but *not* robust.
>  > > That's why I have to look for .rpmnew files after every update.
>  > 
>  > 
>  > That's to be expected. 
>  
>  
>  Expected by whom? I for one don't see why I should have to manually
>  merge configuration changes to the end of times just because I have
>  changed a single option. I'd rather waste my time in other ways. 
Your system should never randomly change a configuration file you've modified. 
Have you read the RHEL System Administrator's Guide? It's not strictly 
relevant to Fedora, but is a very good resource to understand why we don't 
want config files randomly updated to include changes we didn't intend to 
make. If I haven't configured a service, I likely don't have reason to, and am 
trusting the distro to provide sane defaults. Otherwise, I don't want the 
distro to change it, I've already configured it.

>  > The package manager shouldn't destroy your config when 
>  > the package has a different one, and it doesn't. 
>  
>  
>  It wouldn't have to care about my modifications if I could do them
>  separately from the distro-installed configuration file... IOW,
>  fragmented configuration allows me to do my own small modifications
>  while following the upstream/distro configuration changes. Which is
>  exactly the thing I want most of the time. It's a pity many projects
>  don't support it (yet). 
Currently, this has been implemented in several ways, depending on the 
software. With some software, defaults are patched in the source, and, with 
some others, the distro leaves the defaults to the upstream default.

If you're going to change the defaults, change the defaults. Don't try to hide 
where the configuration files actually are.

>  > You don't need to look for 
>  > them though, just look at the output from `dnf` during the update.
>  
>  
>  Gee, thank you very much for your advice... I'll certainly do just that
>  when I'll be upgrading my machines to F-33... But for the time being
>  I'll stick to running "git status" in /etc .-) 
You're welcome. I'm kind of surprised that somebody working for Red Hat 
wouldn't know that yum/dnf provided output when it creates rpmnew files. Some 
people also use tools such as `rpmconf`, which provides you with a similar 
interface to Debian's update process.

How would `git status` there work? You'd have to blacklist more files than you 
have IN git. For example:

/etc/passwd, /etc/shadow, /etc/shadow-, /etc/passwd-, /etc/gshadow, /etc/
gshadow-, /etc/group, /etc/group-, /etc/aliases, /etc/binfmt.d/, /etc/
certmonger, /etc/cron.d, /etc/cron.daily, /etc/cron.deny, /etc/cron.hourly, /
etc/cron.monthly, /etc/crontab, /etc/crypttab, /etc/cups, /etc/cupshelpers, /
etc/dbus-1, /etc/dconf, /etc/depmod.d, /etc/dhcp, /etc/dnfdragora, /etc/
dracut.conf, /etc/exports, /etc/exports.d, /etc/fedora-release, /etc/
filesystems, /etc/firewalld, /etc/fonts, /etc/foomatic, /etc/fstab, /etc/
fuse.conf, /etc/gconf, /etc/gcrypt, /etc/gdbinit, /etc/gdbinit.d, /etc/
geoclue, /etc/gimp, /etc/gnupg, /etc/GREP_COLORS, /etc/DIR_COLORS*, /etc/
grub2.cfg, /etc/grub.d, /etc/gss/, /etc/gssproxy/, /etc/host.conf, /etc/
hostname, /etc/hosts, /etc/idmapd.conf, /etc/init.d, /etc/inittab, /etc/
inputrc, /etc/iproute2, /etc/ipsec.conf, /etc/ipsec.d/, /etc/ipsec.secrets, /
etc/iscsi, /etc/issue, /etc/issue.d, /etc/issue.net, /etc/login.defs, /etc/
localtime, /etc/logrotate.conf, /etc/logrotate.d, /etc/lsb-release.d/, /etc/
lvm/, /etc/machine-id, /etc/machine-info, /etc/magic, /etc/mailcap, /etc/
mail.rc, /etc/man_db.conf, /etc/mcelog, /etc/memtest86+.conf, /etc/mime.types, 
/etc/mke2fs.conf, /etc/modprobe.d, /etc/modules-load.d, /etc/motd, /etc/
motd.d, /etc/mtab, /etc/mtools.conf, /etc/multipath, /etc/my.cnf, /etc/
my.cnf.d, /etc/nanorc, /etc/ndctl/, /etc/netconfig, /etc/NetworkManager/, /
etc/networks, /etc/nfs.conf, /etc/nfsmount.conf, /etc/nftables/, /etc/
nilfs_cleanerd.conf, /etc/nsswitch.conf, /etc/odbc.ini, /etc/oddjob/, /etc/
oddjobd.conf, /etc/openldap/, /etc/opensc.conf, /etc/opensc-x86_64.conf,  /
etc/openvpn/, /etc/opt/, /etc/os-release, /etc/pam.d/, /etc/papersize, /etc/
passwdqc.conf, /etc/pdfpcrc, /etc/pinforc, /etc/pipewire/, /etc/pkcs11/, /etc/
pkgconfig/, /etc/pki, /etc/plymouth/, /etc/pm/, /etc/polkit-1/, /etc/popt.d/, 
/etc/ppp/, /etc/prelink.conf.d/, /etc/printcap, /etc/protocols, /etc/pulse/, /
etc/qemu, /etc/qemu-ga, /etc/rc[0-6].d, /etc/rc.d/, /etc/reader.conf.d/, /etc/
redhat-lsb/, /etc/redhat-release, /etc/request-key.conf, /etc/request-key.d/, 
/etc/resolv.conf, /etc/rhashrc, /etc/rpc, /etc/rpm/, /etc/rpmdevtools/, /etc/
rpmlint/, /etc/rsyncd.conf, /etc/rsyslog.conf, /etc/rsyslog.d/, /etc/rwtab.d/, 
/etc/rygel.conf, /etc/samba/, /etc/sane.d/, /etc/sasl2/, /etc/screenrc, /etc/
sddm/, /etc/sddm.conf, /etc/security/, /etc/selinux/, /etc/services, /etc/
sestatus.conf, /etc/sgml/, /etc/shells, /etc/signond.conf, /etc/skel/, /etc/
smartmontools/, /etc/smi.conf, /etc/sos.conf, /etc/speech-dispatcher/, /etc/
ssh/, /etc/ssl/, /etc/sssd/, /etc/statetab.d/, /etc/strongswan/, /etc/subgid, 
/etc/subuid, /etc/subversion/, /etc/sudo.conf, /etc/sudoers.d/, /etc/sudoers, 
/etc/swid, /etc/sysconfig, /etc/sysctl.conf, /etc/systemd/, /etc/system-
release, /etc/system-release-cpe, /etc/tcsd.conf, /etc/terminfo/, /etc/
texlive/, /etc/tmpfiles.d/, /etc/Trolltech.conf, /etc/trusted-key.key, /etc/
udev/, /etc/udisks2/, /etc/updatedb.conf, /etc/UPower/, /etc/
usb_modeswitch.conf, /etc/vconsole.conf, /etc/vdpau_wrapper.cfg, /etc/virc, /
etc/vpnc/, /etc/vulkan/, /etc/wgetrc, /etc/wpa_supplicant/, /etc/wvdial.conf, 
/etc/X11/, /etc/xattr.conf, /etc/xdg/, /etc/xl2tpd/, /etc/xml/, /etc/
yum.repos.d/

-- 
John M. Harris, Jr.