Bug 640686

RHEL6 package has:

preuninstall scriptlet (using /bin/sh):
# clean tempdir and workdir on removal or upgrade
/bin/rm -rf /var/cache/tomcat6/work/* /var/cache/tomcat6/temp/*

Which is better, though still strikes me as overly destructive.  No %postun rm's.

I don't agree. The temp, and work directories are created by tomcat at runtime.  The content is a production of jsp compilation, and other internal processing. The tempdir, workdir, the contents of appdir, the contents of confdir, and the contents of libdir can change from version to version. When tomcat6 is uninstalled, these directories become marginal in use.

After a clean install, (tomcat6-6.0.26-13.fc14) without the proposed change:

[dknox@78-97-42-72 fc14]$ rpm -Va tomcat6\*
S.5..U.T.    /var/log/tomcat6/catalina.out
......G..    /usr/share/java/tomcat6/log4j-6.0.26.jar
......G..    /usr/share/java/tomcat6/log4j.jar

However, I'll make the change in master and f14 because it's simple. 

%postun
%update_maven_depmap
#%{__rm} -rf %{appdir}
#%{__rm} -rf %{confdir}
#%{__rm} -rf %{libdir}

will now leave these directories intact as does the RHEL-6 tomcat6.spec. There's very little reason to preserve the temp and work directories. The logdir will be preserved as it always has (and should be). I'll push the change later today.

tomcat6-6.0.26-14.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-14.fc14

Is there a reason to not apply the same change to 6.0.26 updates for F12/F13 that introduce the same %postun and are still only in testing?

Hi Tomas,
Yes. There are two reasons:

First, I don't agree with this change (see comment 2). I want to be empirically sure there are no side-effects.

Second, the fedora tomcat6 package has always removed those directories; until now. Simply because RHEL-6 handles it differently does not imply that the fxx packages should handle it in the same way. I've seen no other related complaint and I don't think this change is necessary. 

If there are no side-effects and no complaints on rawhide and f14 after a time I'll propogate the change to other branches when I update them to tc-6.0.30. 

-- dave

I have no strong opinion about:

/bin/rm -rf /var/cache/tomcat6/work/* /var/cache/tomcat6/temp/*

But this:

/bin/rm -rf /var/lib/tomcat6/webapps
/bin/rm -rf /etc/tomcat6
/bin/rm -rf /usr/share/java/tomcat6

is absolutely broken.  Any upgrade of the tomcat6 package will destroy itself and anything that installs into those directories (e.g. tomcat6-admin-webapps, tomcat6-webapps, user install webapps).

(In reply to comment #5)
> Second, the fedora tomcat6 package has always removed those directories;
> until now.

What do you refer to as "those directories"?

$ rpm -qp --scripts tomcat6-6.0.20-2.fc13.noarch.rpm | grep rm
/bin/rm -rf /var/cache/tomcat6/work/* /var/cache/tomcat6/temp/*

$ rpm -qp --scripts tomcat6-6.0.26-11.fc13.noarch.rpm | grep rm
/bin/rm -rf /var/cache/tomcat6/work /var/cache/tomcat6/temp
#    /bin/rm -f /usr/share/java/tomcat6/\[commons-collections-tomcat5\].jar \
/bin/rm -rf /var/lib/tomcat6/webapps
/bin/rm -rf /etc/tomcat6
/bin/rm -rf /usr/share/java/tomcat6

tomcat6-6.0.26-14.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tomcat6'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tomcat6-6.0.26-14.fc14

tomcat6-6.0.26-14.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

See comment #7.

The update apparently does nothing to prevent the previous version's postuninstall script from doing its damage since /var/lib/tomcat6/webapps and /etc/tomcat6 are still removed (I didn't check /usr/share/java/tomcat6 but it, too, was presumably removed).  The update also leaves a stale lock file which seems to prevent the init script from working since it kept giving me an awk error.

The update should deal with the previous version's directory deletion by, say, saving the directories in a temporary location and restoring them in %posttrans.

I have just been hit twice on the same server since sunday! 

I did a preupgrade Fedora 13 to 14 on sunday. At the yum distro-sync command it reported ad downgrade to tomcat6-6.0.26-8.fc14 - and then two live sites dissappeared! 

I erased all tomcat6 packages and re-installed with yum install tomcat6*.

Tonight the tomcat6-6.0.26-14.fc14 update came and did the same thing! Luckily I have moved the live sites to another server.

I have secured output from rpm -Va tomcat6\* and a list of all installed tomcat6 packages and can upload as attachment, if requested.

The server was the 3. upgrade to 14 in a row. The two others showed no problems with tomcat6 upgrades. The tomcat server was not running on those two at the time, though. Could that be significant?

My preupgrade from Fedora 13 to 14 also wiped out my install. I will have to recover from backups...very nasty behavior. My server was running during the preupgrade process if that is an indicator.

Just to note, that the same stuff happened to me yesterday when 
I upgraded a server with yum from f12 to f13. So the %postun was broken also in
this case. (I am not sure if the uninstall is in this case run from f12 or f13 rpm.) THANKS to all you bug-reporters, I could recover the situation quickly, and only received one WTF-mail from service users :).

David, Please fix this bug ASAP. This is too critical bug to let it stay for so long.

My preupgrade from F13 to F14 just blew away my Tomcat6 install. Sadly I didn't notice before doing a preupgrade on a second box. Now I have two destroyed Tomcat installs to fix :(

Maybe we should get this bug some publicity before it happens to even more people?

tomcat6-6.0.26-12.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-12.fc13

tomcat6-6.0.26-4.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-4.fc12

Sorry everyone,
I've updated builds in f12 and f13 so the postun does not remove anything.The f14 and f15 builds were also checked but didn't require changing.  

<snip>
%postun
%update_maven_depmap
</snip>

(In reply to comment #19)
> Sorry everyone,
> I've updated builds in f12 and f13 so the postun does not remove anything.The
> f14 and f15 builds were also checked but didn't require changing.  
> 
> <snip>
> %postun
> %update_maven_depmap
> </snip>

How so?
Looking at git there are the same deletes in postun!

I mean in rawhide and F-14

(In reply to comment #19)
> Sorry everyone,
> I've updated builds in f12 and f13 so the postun does not remove anything.The
> f14 and f15 builds were also checked but didn't require changing.  
> 
> <snip>
> %postun
> %update_maven_depmap
> </snip>

The problem that is being ignored here is that the postun of the _previous_ version is what is doing the damage.  This supposed upgrade to fix the bug is what triggers the bug in the first place.  The upgrade should deal with the previous version's flawed postun but does not.

Yes some sort of sequence like this is needed...

1) new package 
mv /var/lib/tomcat6/webapps /var/lib/tomcat6/webapps-backup
etc..

2) old-package uninstall:
/bin/rm -rf /var/lib/tomcat6/webapps
etc..

3) new package
mv /var/lib/tomcat6/webapps-backup /var/lib/tomcat6/webapps
etc..

I wasn't sure this was possible before, but according to http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Ordering the following might work:


%pre
[ -d /var/lib/tomcat6/webapps ] && mv /var/lib/tomcat6/webapps /var/lib/tomcat6/webapps.bak

%posttrans
if [ -d /var/lib/tomcat6/webapps.bak ]
then
   mv /var/lib/tomcat6/webapps.bak/* /var/lib/tomcat6/webapps
   rmdir /var/lib/tomcat6/webapps.bak
fi


Expanded for the other directories as well.  Fun part is to decide how long to carry this stuff forward for.

It may be possible to use triggers to make that backup and restore only happen when upgrading from certain package versions.

Hi everyone. 

I don't know about triggers, but am reading.

I propose the following:

%pre
# add the tomcat user and group
%{_sbindir}/groupadd -g %{tcuid} -r tomcat 2>/dev/null || :
%{_sbindir}/useradd -c "Apache Tomcat" -u %{tcuid} -g tomcat \
    -s /bin/sh -r -d %{homedir} tomcat 2>/dev/null || :
# Save the conf, app, and lib dirs
# due to rbgz 640686. Copy them to the _tmppath so we don't pollute 
# the tomcat file structure
[ -d  %{appdir} ] && %{__cp} -r %{appdir} %{_tmppath}/%{name}-webapps.bak || :
[ -d %{confdir} ] && %{__cp} -r %{confdir} %{_tmppath}/%{name}-confdir.bak || :
[ -d %{libdir}  ] && %{__cp} -r %{libdir} %{_tmppath}/%{name}-libdir.bak || :

# move the temporary backups to the correct tomcat directory
# due to rhbz 640686
%posttrans
if [ -d %{_tmppath}/%{name}-webapps.bak ]; then
  %{__cp} -r %{_tmppath}/%{name}-webapps.bak/* %{appdir}
  %{__rm} -f %{_tmppath}/%{name}-webapps.bak
fi
if [ -d %{_tmppath}/%{name}-libdir.bak ]; then
  %{__cp} -r %{_tmppath}/%{name}-libdir.bak/* %{libdir}
  %{__rm} -f %{_tmppath}/%{name}-libdir.bak
fi
if [ -d %{_tmppath}/%{name}-confdir.bak ]; then
  %{__cp} -r %{_tmppath}/%{name}-confdir.bak/* %{confdir}
  %{__rm} -f %{_tmppath}/%{name}-confdir.bak
fi

tomcat6-6.0.26-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tomcat6'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tomcat6-6.0.26-4.fc12

tomcat6-6.0.26-13.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-13.fc13

tomcat6-6.0.26-5.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-5.fc12

tomcat6-6.0.26-15.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-15.fc14

I've applied the following:

%pre
# Save the conf, app, and lib dirs
# due to rbgz 640686. Copy them to the _tmppath so we don't pollute 
# the tomcat file structure
[ -d %{appdir} ] && %{__cp} -rp %{appdir} %{_tmppath}/%{name}-webapps.bak || :
[ -d %{confdir} ] && %{__cp} -rp %{confdir} %{_tmppath}/%{name}-confdir.bak || :
[ -d %{libdir}  ] && %{__cp} -rp %{libdir} %{_tmppath}/%{name}-libdir.bak || :

.....

# move the temporary backups to the correct tomcat directory
# due to rhbz 640686
%posttrans
if [ -d %{_tmppath}/%{name}-webapps.bak ]; then
  %{__cp} -rp %{_tmppath}/%{name}-webapps.bak/* %{appdir}
  %{__rm} -rf %{_tmppath}/%{name}-webapps.bak
fi
if [ -d %{_tmppath}/%{name}-libdir.bak ]; then
  %{__cp} -rp %{_tmppath}/%{name}-libdir.bak/* %{libdir}
  %{__rm} -rf %{_tmppath}/%{name}-libdir.bak
fi
if [ -d %{_tmppath}/%{name}-confdir.bak ]; then
  %{__cp} -rp %{_tmppath}/%{name}-confdir.bak/* %{confdir}
  %{__rm} -rf %{_tmppath}/%{name}-confdir.bak
fi

tomcat6-6.0.26-5.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tomcat6'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tomcat6-6.0.26-5.fc12

tomcat6-6.0.26-16.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tomcat6-6.0.26-16.fc14

tomcat6-6.0.26-16.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

This is still bad on fc13.
Update has completely removed /etc/tomcat6 from the system despite the directory are still listed by rpm -ql tomcat6
Initscript are broken without at least /etc/tomcat6/tomcat6.conf

(In reply to comment #31)
> I've applied the following:

> %pre
> # Save the conf, app, and lib dirs
> # due to rbgz 640686. Copy them to the _tmppath so we don't pollute 
> # the tomcat file structure
...

I just upgraded to the latest fc14 tomcat6 package (6.0.26-16) and unfortunately I must report that this "workaround" totally did not work, I still ended up without my tomcat6 configs and webapps.

Would have been nice if somebody actually tried the workaround, I guess (by trying to update e.g. from the latest tomcat6 in fc13 updates that still has broken postun script)

I have a feature request, let's add "rm -rf /*" (as rm -rf / no longer works) as postinstall script for glibc. That way we'll get rid of whiny users.

Now, let's get serious, let *users* decide what to wipe or what not to wipe in application directories.

BTW, I have disabled `tmpwatch` crond job for the same reason: I hate when the system decides that some of the necessary files that I keep for reference in /tmp and /var/tmp are deleted because they are more than 30 days old.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

changed to CURRENTRELEASE to reflect this is fixed in f18