On 03/06/2019 13.50, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of
my talk about this topic from openSUSE Conference:
https://youtu.be/ony0ajC0PWA
The slides can be found here:
https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here:
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite
the config, move it away and write the new config or write the new config
in a different file (*.rpmsave and *.rpmnew).
If the rpm contains a configuration file marked as %config, and the
packager fixes a typo in a comment, RPM will move the by the admin
modified and adjusted configuration file away and put's the default
configuration file there, which means, your service will not work until
you merge the configuration files.
This is already bad, but it's getting really worse if you think about
atomic updates (transactional-updates on openSUSE):
- admin modifies configuration files
- admin starts an transactional update, the configuration file will
be modified
- admin makes changes to the configuration file
- admin reboots to active the changes
-> admin needs to find out which changes where done by whom and needs to
merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens,
it's really bad. Especially, if you think about big clusters with many
machines and not only a few workstations.
I have a routine, but it is not trivial.
Basically I scan the output of "rpmconfigcheck", and use meld on every
file pair, deciding what to apply and what not.
So I started looking into different solutions.
The first thing is: we are not alone with the problem, every distribution
with atomic updates has it, but every distribution has their own solution.
Which reminds me on the pre-FHS times, when you had to learn for every
distribution again where the configuration files and other tools could
be found.
So we need something, which helps everybody and is good enough specified,
that people will use this solution.
The second thing is: people want to have the configuration files in one
place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything,
for some I even have no idea, but for others we make big improvements
compared to today.
The goal is to provide a concept working for all Linux Distributors (like
the FHS, preferred is to get this into the FHS). Short to midterm, it should
solve the problems with atomic updates. Midterm to longterm, the result
should be, that no package installs anything in /etc, it should only contain
changes made by the system administrator or configuration files managed by
the system administrator.
But this makes harder to read the actual configuration, because we then
need to read two files: the one put by rpm, and the one we modified.
It would be fine if someone creates an special admin editor that
automatically loads both files, merging them into one visual result for
us to see and decide what to adapt, so that modifications go to the
proper site.
As to the configs going to somewhere under /usr, I'm not sure I like
that. Maybe a directory under etc, or /etc.something
--
Cheers / Saludos,
Carlos E. R.
(from 15.0 x86_64 at Telcontar)