Good App - Bad Install / Upgrade Process

[bonoboslr]

True it is a bug - but by the looks of it - it has been there forever and there seems no urgency to have it resolved. So when the following happens - (see below) How does the installer handle this? It can't. RPM would allow for much better management.

This is not a bug. This is a complete failure to work. There is no way that the installer can actually upgrade a multi node cluster version of ZCS. As you can see from below - shutdown the zimbra application (as per the infromation on the support site indicated by klug) results in the cluster trying to fail over - thus unmounting the filesystems and borking the installation.

Also - I don't understand how the 'platform independence' angle can be thrown about as it looks like it is built solidly around RHEL. If I am being told what is and what is not supported on NE, and it seems to be RHEL is the favoured OS, then there is no argument about platform independence.

The system will be modified. Continue? [N] Y

Shutting down zimbra mail

Removing existing packages

zimbra-logger...done
zimbra-mta...done
zimbra-snmp...done
zimbra-convertd...done
zimbra-store...done
zimbra-spell...done
zimbra-proxy...done
zimbra-cluster...done
zimbra-apache...done
zimbra-core...done

Removing deployed webapp directories
Installing packages

zimbra-core......zimbra-core-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm...done
zimbra-logger......zimbra-logger-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm...done
zimbra-mta......zimbra-mta-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm...done
zimbra-snmp......zimbra-snmp-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm...done
zimbra-store......zimbra-store-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm...FAILED
###ERROR###

zimbra-store-5.0.10_GA_2638.RHEL5_64-20081003025450.x86_64.rpm installation failed

Installation cancelled

[dijichi2]

I think you have a fundamental misunderstanding of Zimbra. It is not built solidly around RHEL, NE versions support multiple platforms, OSS supports even more (with more in the pipeline), rpm is not the only packaging. Zimbra is multi-platform, therefore it needs platform-independent structure. Get over it.

Your installer is failing while *installing RPMs*, probably a pre or post script of the store *RPM* is failing and returning an error code. This is either because your system is setup wrongly and tripping the install or because there is a bug in the package, or both. The failure is a bug/setup issue, nothing to do with platform independence, installation methods or whatever.

If you're an NE customer, log a support issue.

[bonoboslr]

I fail to see how this is setup wrongly - when Zimbra professional services assisted in the installation. I am not sure you understand what I am describing to you. There is NO WAY that you can upgrade zimbra 5.0.9 to 5.0.10 using the install.sh script on a multi cluster installation if you do not implement some kind of hack. If you follow any of the documentation - either the PDFs (that are out of date and are logged as a bug) or follow the update in https://support.zimbra.com portal then it WILL bork your setup.

I do not have a 'fundamental misunderstanding of zimbra'. I understand enough to have 500,000 multi server, multi cluster setup. The fundamental problem lies in the zimbra cluster ideology of having shared binaries across the cluster. This is compounded by an unintelligent install.sh script trying to do everything in its power to unmount the shared filesystem that the binaries live on. Your assumption that the RPM is failiing is spot on. You cannot install rpms in a target directory that has been unmounted due to the cluster or the cluster service being stopped.

While we are on it - why does the install.sh insist on removing the RPMs and not UPGRADING rpms?? Has no one ever explained rpm -Uvh ?

Support issue logged. Resolution suggested to support team. Probably will wait until version 6.5 until it is fixed. My gripe is that there is no way that the install.sh script was ever tested properly and that worries me immensly.

Just to add to this. Professional services also noted the same issue in August this year while on site with us.

[brian]

bonoboslr

The cluster service can either be disabled prior to starting the upgrade or install.sh --cluster active will disable it for you. You are correct this will stop the cluster service, which includes unmounting the SAN partitions. This is a necessary step in order to prevent failover and the standby node taking control of the SAN volume during upgrade.

The cluster preupgrade script as called from install.sh will then automatically add the service IP and remount the SAN volumes as defined in /etc/cluster/cluster.conf. (there is a is known issue with bond0 interfaces not working)

It sounds like this step is not happening properly on your system but it's unclear from your partitial install log.

Please work with support, have them forward me the case notes and/or private message me the case number.

[bonoboslr]

Hi Brian - I will pm you the case number - thanks.

Using the method described by myself above, I was able to upgrade my 4 other clusters.

But here is what I was wondering: Does the script mount ALL of the SAN volumes? I have seven volumes - base,index,log,redolog,db/data,store,secondary. From what I can tell it does not. I will have to build another cluster to test this theory though.

My thoughts are and it seems like a much more straight forward process - why not have the script just fake the output of : /opt/zimbra-cluster/bin/zmcluctl during upgrade ?

This way, the zimbra application can be stopped without the need to touch the san volumes, cluster IP address or relocate the cluster service.
Then it does not matter what type of cluster setup you have, as long as you are using the zmcluctl script.

I am working with support to get some sort of bug/s logged.

[brian]

Yes it mounts /opt/zimbra-cluster/mountpoints/ first and then all the remaining fs's listed in /etc/cluster/cluster.conf.

This is done with the cluster upgrade script
bin/zmclusterupgrade.pl --nodetype active --action preupgrade --cluster

[bonoboslr]

Just to add to this thread... Upgrade to 5.0.10 from 5.0.9 overides the zmmta.conf and the postfix/conf/main.cf.

So if you have made modifications, they will not be maintained during the upgrade. The modifications that we made were to enable qmqpd for our split domain - as suggested in the zimbra wiki.

RPM has the ability to prevent the above. Why it is not being utilized is beyond me.

[phoenix]

Originally Posted by bonoboslr

Just to add to this thread... Upgrade to 5.0.10 from 5.0.9 overides the zmmta.conf and the postfix/conf/main.cf.

So if you have made modifications, they will not be maintained during the upgrade. The modifications that we made were to enable qmqpd for our split domain - as suggested in the zimbra wiki.

We do not guarantee that any modifications made to the configuration files wll survive and upgrade. If you wish to see certain changes made to the installation or changes you've made remain (or be exposed in Zimbra) then feel free to file an enhancement request. Posting questions/comments in the forums is good for discussions but won't get the developers attention, that's one of the things bugzilla is used for - f you file any RFEs then don't forget to vote on them.