Moving default configuration out of /etc - handling user modifications
Hi, The suse-module-tools package ships a couple of (default) configuration files that are currently installed under /etc/modprobe.d. I want to migrate them to /lib/modprobe.d (to be further migrated to /usr/lib when the usr merge happens). These files were meant to be user-modifyable, and were labelled with %config(noreplace) for that reason. How should I deal with modified files? The files under /etc aren't owned by the new package any more, as it now owns the corresponding files under /lib only. In the upgrade process, when the old version is uninstalled, rpm will notice the %config(noreplace) files being removed, and will rename them to .rpmsave. That's bad, because user modifications won't be applied any more. The system may fail to boot or otherwise misbehave. rpm will log these renames: warning: /etc/modprobe.d/60-blacklist_fs-nilfs2.conf saved as /etc/modprobe.d/60-blacklist_fs-nilfs2.conf.rpmsave but these messages might be easily overlooked, in particular if the user works with packagekit or the like. I've considered to detect these ".conf.rpmsave" files in a %posttrans script and rename them back to ".conf". That would work AFAICS, but I'm not sure if I can exclude weird side effects; in particular, I must take care not to restore previously created .rpmsave files, and I should only do this once, when upgrading from a previous version that still owned the files under /etc (I don't know how to detect that). In general, this approach feels pretty much like a hack. Another option I've tried is to add the /etc/modprobe.d/ files to the new package as %ghost files. That "works", too, the files aren't renamed to .rpmsave any more, and no immediate damage is done. The drawback is that every conf file is preserved, even those that were unchanged by the user (the "normal" case being that the user didn't modify any of these files). Thus my newly installed files under /lib wouldn't take effect. Future changes of the default configuration would be silently masked. What would be the preferred approach? Or is there another, better solution that I am overlooking? Hints welcome, Martin
On Fr, 2021-05-28 at 16:41 +0000, Martin Wilck wrote:
I've considered to detect these ".conf.rpmsave" files in a %posttrans script and rename them back to ".conf". That would work AFAICS, but I'm not sure if I can exclude weird side effects; in particular, I must take care not to restore previously created .rpmsave files, and I should only do this once, when upgrading from a previous version that still owned the files under /etc (I don't know how to detect that). In general, this approach feels pretty much like a hack.
I think I've worked it out. I can check in %post whether the previously installed version of my package owned files under /etc/modprobe.d, and if yes, restore the modified .conf files from .conf.rpmsave in %posttrans. Regards, Martin
On Fri, 2021-05-28 at 21:46 +0000, Martin Wilck wrote:
On Fr, 2021-05-28 at 16:41 +0000, Martin Wilck wrote:
I've considered to detect these ".conf.rpmsave" files in a %posttrans script and rename them back to ".conf". That would work AFAICS, but I'm not sure if I can exclude weird side effects; in particular, I must take care not to restore previously created .rpmsave files, and I should only do this once, when upgrading from a previous version that still owned the files under /etc (I don't know how to detect that). In general, this approach feels pretty much like a hack.
I think I've worked it out. I can check in %post whether the previously installed version of my package owned files under /etc/modprobe.d, and if yes, restore the modified .conf files from .conf.rpmsave in %posttrans.
Regards, Martin
hi Martin, sorry for the late reply on this topic; The wiki actually has some hints about how to handle this case: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi... Hope that helps, Dominique
On Sa, 2021-05-29 at 00:02 +0200, Dominique Leuenberger / DimStar
hi Martin,
sorry for the late reply on this topic;
The wiki actually has some hints about how to handle this case: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...
Hope that helps,
Thanks! I should have found that page :-/ Fortunately, it's pretty close to what I'd figured out, except that I moved away the old .rpmsave files in %post, not %pre. AFAICS %post is sufficient - no? Regards, Martin
On Sat, 2021-05-29 at 00:09 +0200, Martin Wilck wrote:
On Sa, 2021-05-29 at 00:02 +0200, Dominique Leuenberger / DimStar
hi Martin,
sorry for the late reply on this topic;
The wiki actually has some hints about how to handle this case: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...
Hope that helps,
Thanks! I should have found that page :-/
Fortunately, it's pretty close to what I'd figured out, except that I moved away the old .rpmsave files in %post, not %pre. AFAICS %post is sufficient - no?
in %post you already don't know anymore if the .rpmsave was there prior to the update, or not. So you risk to re-enable old moved config files. Cheers, Dominique
On Sa, 2021-05-29 at 00:11 +0200, Dominique Leuenberger / DimStar wrote:
On Sat, 2021-05-29 at 00:09 +0200, Martin Wilck wrote:
On Sa, 2021-05-29 at 00:02 +0200, Dominique Leuenberger / DimStar
hi Martin,
sorry for the late reply on this topic;
The wiki actually has some hints about how to handle this case: https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...
Hope that helps,
Thanks! I should have found that page :-/
Fortunately, it's pretty close to what I'd figured out, except that I moved away the old .rpmsave files in %post, not %pre. AFAICS %post is sufficient - no?
in %post you already don't know anymore if the .rpmsave was there prior to the update, or not. So you risk to re-enable old moved config files.
In my experiments (which just involved updating suse-module-tools alone), rpm created the (new) .rpmsave files after invoking %post. Is that dependent on the rpm version, or some properties of the transaction, or just some random ordering? Regards, Martin
On Mon, May 31, Martin Wilck wrote:
In my experiments (which just involved updating suse-module-tools alone), rpm created the (new) .rpmsave files after invoking %post. Is that dependent on the rpm version, or some properties of the transaction, or just some random ordering?
Defined order ;) Look at pam.spec: %pre test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i}.rpmsave.old %posttrans test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i} ||: Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Mo, 2021-05-31 at 11:01 +0200, Thorsten Kukuk wrote:
On Mon, May 31, Martin Wilck wrote:
In my experiments (which just involved updating suse-module-tools alone), rpm created the (new) .rpmsave files after invoking %post. Is that dependent on the rpm version, or some properties of the transaction, or just some random ordering?
Defined order ;)
Look at pam.spec:
%pre test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i}.rpmsave.old
%posttrans test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i} ||:
Thorsten
I thought I needed to add another test to check if I was updating from a version with config files in /etc to one with files in (/usr)/lib. I realize now that after this update (i.e. once none of the files under /etc are owned by my package any more), no more files will be renamed to .rpmsave. That means I can simplify my code. Thanks, Martin
On Mo, 2021-05-31 at 11:01 +0200, Thorsten Kukuk wrote:
On Mon, May 31, Martin Wilck wrote:
In my experiments (which just involved updating suse-module-tools alone), rpm created the (new) .rpmsave files after invoking %post. Is that dependent on the rpm version, or some properties of the transaction, or just some random ordering?
Defined order ;)
Look at pam.spec:
%pre test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i}.rpmsave.old
%posttrans test -f %{_sysconfdir}/${i}.rpmsave && mv -v %{_sysconfdir}/${i}.rpmsave %{_sysconfdir}/${i} ||:
Thorsten
I thought I needed to add another test to check if I was updating from a version with config files in /etc to one with files in (/usr)/lib. I realize now that after this update (i.e. once none of the files under /etc are owned by my package any more), no more files will be renamed to .rpmsave. That means I can simplify my code. Thanks, Martin
participants (4)
-
Dominique Leuenberger / DimStar -
Martin Wilck -
Martin Wilck -
Thorsten Kukuk