4 Jun
2019
4 Jun
'19
5:23 a.m.
Hello,
I do not see how the actual issue could be solved
by storing config files at a different location.
I think the actual issue is the conflict between
what the admin wants to have in his config files versus
what a Linux distributor wants to have in his config files.
I think the actual issue is the conflict who has the
final say in what the config files content is.
Because I think there is no automated way to solve that conflict
I think the functionality that RPM provides is basically all
what can be done in practice.
Files not marked:
The Linux distributor has the final say in the files content
(and admin changes get overwritten/lost).
Files marked as %config:
The Linux distributor has the final say in the files content
(and admin changes are saved as file.rpmsave).
Files marked as %config(noreplace):
The admin has the final say in the files content
(and Linux distributor content is provided as file.rpmnew).
When files got changed the admin must manually solve things
as he needs it in his particular case.
I think the crucial point is that the admin can reliably
determine all that has changed.
On Jun 3 13:50 Thorsten Kukuk wrote (excerpt):
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.
Offhandedly this looks like a packaging issue because when
only a cosmetic typo in a comment was fixed the new config file
should be marked as '%config(noreplace)' - but I don't know
what happens if the old RPM has '%config' and the new one
has '%config(noreplace)' and vice versa.
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
But
https://users.suse.com/~kukuk/SUSE-CaaSP-Docu/transactional-update.8.html
reads:
"Changes made to the running root filesystem after transactional-update
was started are lost after the next reboot"
so it is documented what happens when "admin makes changes to
the configuration file" after he "starts an transactional update".
I do not understand the "overlay filesystem" part in
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#rpm…
that reads
"RPM does not see, that there are modified versions of the
config file (e.g. they are stored in an overlay filesystem)"
I guess what is meant is that in the running system
there is an overlay filesystem e.g. for /etc/
but that does not get included in the snapshot
(i.e. the snapshot contains old/outdated files
underneath the overlay filesystem).
Offhandedly this looks like an issue with creating
the snapshot of the running system which is in this
special case not a valid snapshot of the running system.
Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - HRB 21284 (AG Nuernberg)
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org