I cannot figure out how to prevent removal of configuration files...

Mark Jaffe jaffe.mark at gmail.com
Sat Sep 29 02:12:41 UTC 2012


This might be a little long-winded, but I am tearing my hair out over this
problem. Here's the situation: we run our services under tomcat, and we
have detailed configurations for each environment. At one time, before I
got myself involved, all configs were managed "by hand", being checked-out
from source control and placed in the required directory. There is a single
file, "gwy-tomcat6" which gets sourced during startup, and in some cases an
additional file "gwy-tomcat6.env" may also exist.

Based on some work I had done in another establishment, I realized we could
manage these configs within the rpm, so I added some logic to determine
which environment was being installed, and to make sure the correct configs
were in place. Here is the strategy:

source control contains:  gwy-tomcat6.dev, gwy-tomcat6.qa, gwy-tomcat6.stg,
gwy-tomcat6.perf, gwy-tomcat6.prod

these are put in place in the rpm %install section:
install -m 0644  server/sysconfig/gwy-tomcat6.prod
install -m 0644  server/sysconfig/gwy-tomcat6.dev
install -m 0644  server/sysconfig/gwy-tomcat6.perf
install -m 0644  server/sysconfig/gwy-tomcat6.qa
install -m 0644  server/sysconfig/gwy-tomcat6.stg

In the %post section, logic determines the environment, and does this (for
      cd /etc/sysconfig
      rm -f gwy-tomcat6.prod  gwy-tomcat6.perf
      rm -f gwy-tomcat6.stg
      rm -f gwy-tomcat6.qa
      mv gwy-tomcat6.dev  gwy-tomcat6

All should then be well when the application starts up. But here's the
kicker: during %postun, rpm does a removal of what it believes are
artifacts from the previous version, and the carefully managed
configuration file disappears!

I've tried numerous tricks like setting %config attributes:
%config %attr(644,root,root) %{_sysconfdir}/sysconfig/gwy-tomcat6

But then I just end up with a gwy-tomcat6.rpmnew which the application

Is there something I could do to solve this dilemma?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20120928/0919ae05/attachment.html>

More information about the Rpm-list mailing list