On Tue, Jun 04, Johannes Meixner wrote:
Hello,
I do not see how the actual issue could be solved by storing config files at a different location.
It's not by storing config files at a different location, it's about separating the original configuration files from user made changes.
I think the actual issue is the conflict who has the final say in what the config files content is.
No, the actual issue is, how to merge the changes the admin made to the configuration files with the changes upstream made to the configuration files.
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.
And many people don't agree here, we think there must be something better.
Files not marked: The Linux distributor has the final say in the files content (and admin changes get overwritten/lost).
This is the worst a packager can do and hopefully nobody does this on openSUSE.
Files marked as %config: The Linux distributor has the final say in the files content (and admin changes are saved as file.rpmsave).
And until the admin finds out, his system is not functional/insecure/... And this only because the package fixed e.g. a typo in a comment. Why not store the admin change somewhere else and merge it at runtime? Then the fixed typo in a comment would not cause any trouble. And I have seen this often enough on openSUSE Tumbleweed...
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.
Correct, nobody wants to change that always, and you never know what the admin had installed.
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".
Sorry, but that is a lame excuse to not solving problems. Only because we don't have a better solution today does not mean, we should not try to fix the problem.
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.
No, this is the result of "atomic updates" and the definition, what that means. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org