After some experiments / research it looks like nethserver-modules leave their (httpd, apache) configurations files behind after removal. I checked with SOGo, Webtop, Roundcube and Statistics.
Not strange if you take in account RPM is unaware of most of those files: they are created at template expansion. Interesting exception is webtop5-webdav.conf it is static ( non templated ) nevertherless stays behind too after removing nethserver-webtop.
It is removed if you (auto)remove webtop5* completely (that is an other story…)
From own experience with nethserver-gitea the httpd (apache) configuration files are worrying. IMO other configuration files, sometimes left behind as .rmpsave, do not harm.
Reloading the httpd configuration of removed module(s) does compromise the stability of our systems.
In the nethserver-gitea module it is solved in the SPEC by explicit removal of this file:
%postun
if [ $1 == 0 ]; then
/usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1
fi
That’s a good idea as old config files will keep unneeded apache configs even if they don’t put apache down.
I didn’t test but maybe it’s enough to define these apache .conf files as %config file in the spec file to force deletion or .rpmsave method?
This is a possible solution which at the end did not choose to implement:
A “dummy placeholder” configuration file (which is overwritten by template-expand event) is needed for the rpm packager to prevent “file not found error”. This file can be created in the spec-file or in the code. (although for the latter it probably needs to be excluded from the automated file list creation)
This being said:
Disliked the configuration file(s) being overwritten with the dummy placeholder every update. Intorducing the chance to break httpd if expanding is interrupted for some reason.
So considered to use %config(noreplace) to prevent overwriting of the former (expanded template) config file(s), ending up with empty .rpmnew files.
I back the use of RPM features, like config(nore place) to implement the wanted behavior. The %postun hook could be redundant if the config file is renamed .rpmsave
IIRC the template-expand command attempts to remove that suffix along with .rpmnew, to keep the dir tidy.
Worked on this implementation a bit and not able to sort one thing out:
If an application installs a apache configuration by its self (ie /etc/httpd/conf.d/package.conf), which will be overwritten with our own templated version, it turns out to be difficult to get rid of it.
(AFAIK now) It is impossible to add a placeholder in the nethserver-module package; at install this throws a transition error because you try to install one file 2 times. And removing the nethserver-module does not remove the underling package.
The nethserver-roundcubemail package overwrites this default configuration installed by the “underlying” roundcubemail package
Adding a placeholder for roundcubemail.conf in nethserver-roundcubemail would (1) throw:
Transaction check error:
file /etc/httpd/conf.d/roundcubemail.conf conflicts between attempted installs of .....
removing nethserserver-roundcubemail does not remove roundcubemail -…rpm , hence /etc/httpd/conf.d/roundcubemail.conf stays present / will not be renamed until you remove this “underlying” package manually.
(1) translation of a test case done with nethserver-gitea
Transaction check error:
file /etc/gitea/app.ini conflicts between attempted installs of nethserver-gitea-0.1.0-1.7.g953d0b5.ns7.noarch and gitea-1.5.1-2.ns7.x86_64
Instead of a “placeholder” (like an empty file), please try with a file with the same contents (same md5), owner and permissions. RPM could not raise the conflict if all of them are the same across the conflicting packages.
Yes: every time the upstream package changes the config file we must change it too. Luckily it should happen rarely, and if it happens it means that our templates are likely to be affected by a new feature.
It can be considered a safety guard
If we can’t rely on RPM to do the job, we have to implement and maintain something else by ourselves…
Yes, package removal is a really complex matter and we avoided to deal with it: is it worth the effort?
Should not be the upstream package (or the package owning the file) responsible of the conf file removal? nethserver-* should not remove the conf file if it doesn’t own it.
the package creating the file in first place. If the file is created by nethserver-*, then remove it. Otherwise, leave it even if modified from templates. But I could be missing something on the conversation.
roundcubemail is a nice example:
removing nethserver-rouncubemail basically does not do much:
the dashboard widget and the rewrite rules in default-virtualhost.inc are removed .
because /etc/httpd/conf.d/roundcubemail.conf “stays behind” apache keeps reloading this config and rounscubemail actually stays functional.