On 09/29/2012 05:12 AM, Mark Jaffe wrote:
Hi, 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 <http://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 %{buildroot}%{_sysconfdir}/sysconfig/ install -m 0644 server/sysconfig/gwy-tomcat6.dev %{buildroot}%{_sysconfdir}/sysconfig/ install -m 0644 server/sysconfig/gwy-tomcat6.perf %{buildroot}%{_sysconfdir}/sysconfig/ install -m 0644 server/sysconfig/gwy-tomcat6.qa <http://gwy-tomcat6.qa> %{buildroot}%{_sysconfdir}/sysconfig/ install -m 0644 server/sysconfig/gwy-tomcat6.stg %{buildroot}%{_sysconfdir}/sysconfig/ In the %post section, logic determines the environment, and does this (for example): cd /etc/sysconfig rm -f gwy-tomcat6.prod gwy-tomcat6.perf rm -f gwy-tomcat6.stg rm -f gwy-tomcat6.qa <http://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 ignores. Is there something I could do to solve this dilemma?
Rpm doesn't do anything by itself in %postun, your scripts do. Sounds like your scripts are not upgrade-aware: if %postun needs to clean up things when the package is actually removed but leave everything alone on upgrades, you need to do something like
%postun if [ $1 -eq 0 ]; then # remove stuff... but only on erase, not upgrade fi - Panu - _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list