Cleanup httpd configuration files at removal nethserver-module

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:

if [ $1 == 0 ]; then
  /usr/bin/rm -f /etc/httpd/conf.d/zz_gitea.conf > /dev/null 2>&1

Syntax reference of [ $1 == 0 ]

Id’ like to introduce to consider removal of httpd configuration files at module removal being good practice.

What do you think?


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.

1 Like

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.

Any ideas how to solve this?

I’m not sure I understand well …Could you provide an example with a real module?

As examples sogo and roundcubemail packages install a configuration file in /etc/hhtpd/conf.d/

Examine (at the Files section) the roundcubemail-1.1.12-2.el7.noarch.rpm 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
1 Like

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.

yum autoremove nethserver-roundcubemail removes the underlying package roundcubemail.

1 Like

I can try this, but is this not an maintaining nightmare?

(I mean always needing to check it this is this true?)

would love this!, but it failed in the past to do this by default in the service manager

1 Like

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 :blush:

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?

Just out of curiosity, what are your concerns with: ?

if [ $1 == 0 ]; then
  /usr/bin/rm -f ...

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.


No concerns at all. If RPM can’t do the cleanup for us that seems the only available solution…

Generally I prefer a “declarative” approach, instead of adding runtime code. But here the code is trivial so I think it is acceptable too.

We do overwrite them with templated content (some expeditions…) , so “who” owns the file?

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.

I agree with @dnutan, if the .conf was installed by sogo we have to consider the sogo removal!

Anyway we have also some cases like zzz_whatever.conf that we have to clean up by ourselves

1 Like

roundcubemail is a nice example:
removing nethserver-rouncubemail basically does not do much:
the dashboard widget and the rewrite rules in are removed .

because /etc/httpd/conf.d/roundcubemail.conf “stays behind” apache keeps reloading this config and rounscubemail actually stays functional.

thats true, but dislike to introduce a extra reason to keep this sub-optimal solution. :sunglasses:

This is the real solution, but as said quite complex