Bug 640686 - Upgrade of tomcat6 wipes out directories
Summary: Upgrade of tomcat6 wipes out directories
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tomcat6
Version: 18
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: David Knox
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-06 15:39 UTC by Orion Poplawski
Modified: 2015-11-02 00:15 UTC (History)
12 users (show)

Fixed In Version: tomcat6-6.0.36-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-28 11:55:04 UTC
Type: ---


Attachments (Terms of Use)

Description Orion Poplawski 2010-10-06 15:39:40 UTC
Description of problem:

Why on earth is this in the tomcat6 %postun script:

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

At the very least it would need to be wrapped with:

if [ $1 = 0 ] ; then
...
fi

But even then that's bad juju.

There is also:

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 doesn't appear to be doing what you think it should

I just upgraded to tomcat6-6.0.26-11.fc14 and now:

# rpm -Va tomcat6\*
missing     /usr/share/java/tomcat6
missing     /usr/share/java/tomcat6/annotations-api-6.0.26.jar
....
missing     /etc/tomcat6
missing     /etc/tomcat6/Catalina
.....
missing     /var/cache/tomcat6/temp
missing     /var/cache/tomcat6/work
missing     /var/lib/tomcat6/webapps

And it wiped out my install of a tomcat6 webapp.

This appears to be the case for F13+, and unfortunately makes the issuance of any tomcat6 update very destructive.

Comment 1 Orion Poplawski 2010-10-06 16:10:25 UTC
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.

Comment 2 David Knox 2010-10-14 16:49:12 UTC
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.

Comment 3 Fedora Update System 2010-10-14 21:05:28 UTC
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

Comment 4 Tomas Hoger 2010-10-15 07:09:27 UTC
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?

Comment 5 David Knox 2010-10-18 16:24:03 UTC
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

Comment 6 Orion Poplawski 2010-10-18 16:43:30 UTC
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).

Comment 7 Tomas Hoger 2010-10-18 17:03:54 UTC
(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

Comment 8 Fedora Update System 2010-10-20 03:08:26 UTC
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

Comment 9 Fedora Update System 2010-11-14 21:33:13 UTC
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.

Comment 10 Tomas Hoger 2010-11-15 08:08:46 UTC
See comment #7.

Comment 11 Danny Ciarniello 2010-11-15 17:20:06 UTC
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.

Comment 12 Leif E. Andersen 2010-11-16 18:47:01 UTC
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?

Comment 13 Mick Smothers 2010-11-20 05:46:17 UTC
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.

Comment 14 Ari Tilli 2010-11-23 11:58:15 UTC
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 :).

Comment 15 Alexander Kurtakov 2010-11-23 12:08:45 UTC
David, Please fix this bug ASAP. This is too critical bug to let it stay for so long.

Comment 16 Leif Gruenwoldt 2010-11-25 00:19:00 UTC
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?

Comment 17 Fedora Update System 2010-11-29 20:07:45 UTC
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

Comment 18 Fedora Update System 2010-11-29 20:07:52 UTC
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

Comment 19 David Knox 2010-11-29 20:17:18 UTC
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>

Comment 20 Alexander Kurtakov 2010-11-29 20:27:41 UTC
(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!

Comment 21 Alexander Kurtakov 2010-11-29 20:28:01 UTC
I mean in rawhide and F-14

Comment 22 Danny Ciarniello 2010-11-29 21:37:52 UTC
(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.

Comment 23 Ari Tilli 2010-11-30 07:20:14 UTC
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..

Comment 24 Orion Poplawski 2010-11-30 15:55:18 UTC
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.

Comment 25 Tomas Hoger 2010-11-30 16:24:31 UTC
It may be possible to use triggers to make that backup and restore only happen when upgrading from certain package versions.

Comment 26 David Knox 2010-11-30 18:17:56 UTC
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

Comment 27 Fedora Update System 2010-11-30 22:16:27 UTC
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

Comment 28 Fedora Update System 2010-12-01 19:52:18 UTC
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

Comment 29 Fedora Update System 2010-12-01 19:52:30 UTC
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

Comment 30 Fedora Update System 2010-12-01 19:52:40 UTC
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

Comment 31 David Knox 2010-12-01 20:52:41 UTC
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

Comment 32 Fedora Update System 2010-12-02 05:26:23 UTC
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

Comment 33 Fedora Update System 2010-12-03 09:32:04 UTC
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

Comment 34 Fedora Update System 2010-12-13 20:13:17 UTC
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.

Comment 35 Nicolas Chauvet (kwizart) 2010-12-20 17:24:24 UTC
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

Comment 36 Oleg Drokin 2011-01-17 07:01:59 UTC
(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)

Comment 37 Artem S. Tashkinov 2011-01-17 20:09:17 UTC
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.

Comment 38 Bug Zapper 2011-05-31 11:51:38 UTC
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

Comment 39 Bug Zapper 2011-06-28 11:55:04 UTC
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.

Comment 40 David Knox 2013-03-25 19:23:17 UTC
changed to CURRENTRELEASE to reflect this is fixed in f18


Note You need to log in before you can comment on or make changes to this bug.