1

I work on a platform which serves several different projects. For the most part, all of the projects install their web server using Red Hat's RPM. We never created a policy for this which would require the projects' application developers to install from either source or in-house binary/tarball.

This is causing issues now because as we patch servers with security updates, the Red Hat httpd package gets updated with configuration files that are either not originally part of the project's configuration or overwrite the configuration.

We need evidence or supporting documentation which points to a safer, more stable option which can be written into policy. Is there any documentation which can provide this support? I'm looking through Google results, but my Google-fu is weak so it requires sifting out the cruft. If someone here has a source they can point me to directly I would appreciate it.

theillien
  • 445
  • 3
  • 13
  • 28

1 Answers1

1

RedHat will deploy only security updates. In your case apache will change only the minor version. This means that the configuration will be compatible with all newer versions of apache.

To avoid the problem of some apache config files that are changed, I do not change the original configuration files at all, and add all my customization by adding files to the .../conf.d/ folder.

In this way my configuration is separated from original one, it will never be replaced, and if there are some "bad" defaults that are fixed by upgrading apache, they will be added to the final config.

2nd solution:
If you have a large pool of apache servers and you want to avoid the replacement of the apache config files that were changed, you can create your own repository where you will repackage the apache rpm and mark the configuration files as %config(noreplace). See: http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html

Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83
  • We're not looking to do the repackaging ourselves. We simply support the platform. Each project is responsible for installing and configuring the applications they run. As a result, we are left with a very inconsistent methodology across the numerous servers on the platform. With this in mind, maintaining our own repository of repackaged RPMs is out of the question. We simply need evidence that requiring the devs and admins to build in-house and deploy that is an effective and industry supported approach. – theillien Jun 05 '13 at 14:19
  • Then move all custom configs to `conf.d` folder. – Mircea Vutcovici Jun 05 '13 at 14:25
  • I've edited my answer to be clear. – Mircea Vutcovici Jun 05 '13 at 14:27