-
Here is a brief synopsis of the problem.
System: FC4
Previous install: zcs-4.0.2_GA_362.FC4.tgz
This upgrade: zcs-4.0.3_GA_406.FC4.tgz
My system state is that I have a failed install due to a zimbra-core rpm being broken (most probably due to tar -zxvf). The initial upgrade has failed as the 'rpm' failed after the rpm md5sum did not equate true.
I subsequently (because the real error rpm was not sent to the term) re-tried the install. I simply re-ran install.sh, accepted the prompts to install and make changes. Installer then deleted /opt/zimbra and I lost my entire installation. This I believe is very wrong.
####### My fix #########
The problem as I see it is that the installer does checks to see what is installed based soley on rpm (or dpkg/conary) and the results of this alone dictate if this is a new install or upgrade.
The files involved are in the zimbra tarball and can be found at:
zcs/util/globals.sh
zcs/util/utilfunc.sh
globals.sh details the three following variables:
OPTIONAL_PACKAGES
PACKAGES
CORE_PACKAGES
which contain the packages which the package manager will query to determine if zimbra is installed and ultimately if it should delete /opt/zimbra .
I strongly believe that this decision should have a safety net as in the case of a failed upgrade, the packages have most likely been removed fooling the installer to think a new install is being deployed. This is what happened to me and is wrong behaviour.
I think that as a minumum, the installer should check for the existence of a message store and possible any other directory found within a normal zimbra install. For the purpose of testing, I used the /opt/zimbra/{bin,store} to test for existence and added the following block of code into:
zcs/util/utilfunc.sh
Using diff:
313a314,323
> echo ""
> echo "Checking for existing message store..."
> INSTALLSTORE="store bin"
> for i in $INSTALLSTORE; do
> echo -n " $i..."
> if [ -d "/opt/zimbra/$i" ]; then
> echo "FOUND $i"
> INSTALLED="yes"
> fi
> done
This simply performs the required check and sets the $INSTALLED variable so that the installer correctly detects the existence of a possible install, albeit a rudimentary check. Improvements could be to check for database files and messages etc.
The above type check along with a 'do you really want to delete the /opt/zimbra/ directory?' prompt would probably solve the main issue.
####### How to recover from backup ########
I created a mirror install of FC4 on a VMWare instance, confgured the installation of the OS to suit zimbra and rsync'd over a cold backup of my currently running restored (albeit missing 3 months email) live zimbra server. So, for purposes of testing, I am running the installer on a different machine/hardware albeit with same hostname (differing IP).
When I ran my tweaked installer, it correctly detected the installation and allowed me to start the services after the installer had completed. The final installation however had not retained my settings for https and different https port numbers. This was the only issue.
Instead, in the case of a failed upgrade, I found it better to start afresh.
* Backup if not already done so *
Backup your (you should already have anyway) /opt/zimbra somewhere safe (not inside /opt/zimbra/). Once you are sure you have a good cold backup, remove zimbra via:
% ./install.sh -u
then, carry out a fresh install (*same version* as cold backup) whereby configuration of admin password etc is obligatory albeit needless as we will delete the /opt/zimbra once installation is complete.
After a completed install, move /opt/zimbra out of the way *after* first stopping any zimbra services.
Then, install your backup. You should now be able to start your services and test things are working. If everything is ok, re-attempt to upgrade after fixing whatever broke the original upgrade (bad md5sums etc).
Hopefully this will be enough to stop this happening again (even if it saves one install).
I must admit thouh, I feel a whole lot better knowing I understand the backup/restore process so this whole saga was not for nothing. Just hope my users understand though...
-
I've filed a bugzilla report on your behalf to track this issue.
http://bugzilla.zimbra.com/show_bug.cgi?id=11499
-
I am looking into moving my trusted QmailToaster install over to Zimbra. I am testing testing Zimbra on CentOS4.4, but after going through the install and encountering some problems, and then encountering this thread, I am wondering if this is even something to consider.
The problem is not 'why did the upgrade fail', or 'why did /opt/zimbra get deleted'. The real question is 'Why is there user data stored in /opt/zimbra?' The opt directory is storage for large static application and support data. Not user data. Please consult http://www.pathname.com/fhs.
-
/var/mail/...
Just to make sure, you'd prefer /var/mail or some variant under /var?
-
isn't /var/opt or /var/lib the usual place for this sort of data?
i use /srv/zimbra but i'm not sure if thats technically correct
-
fyi: Bug 12525 - "move zcs data from /opt/zimbra/ to /var/opt/zimbra/ to conform to Filesystem Hierarchy Standard"
-
Same
I have had 2 or 3 upgrades fail the first one I tried to do it again and it erased every thing, the other times I restored from backup and fixed what was wrong then tried again, this was my fault not Zimbras.
I would like it to back up before it starts to upgrade if it fails it should just put every thing back and print out an error. This would save a lot problems with failed upgrades. I also think it would be easy to put into the installer. Give an option in the beginning to skip this step for those that don't want to wait for the files to copy.
