Suse10.2 Upgrade problem

[ardan]

Hi, I have had Zimbra 4.5.0 working well for several weeks now on test and yesterday decided to upgrade to the latest version.
During the install most things went OK apart from messages such as "Module syslog-ng does not exist" and "..failed to initialize documents..".

However, when I try to login to a user mailbox, the login screen appears OK and after login the following error appears:-

msg - mountpoint loop detected
code - service.TOO_MANY_HOPS
method - ZmCsfeCommand.prototype.invoke
detail - soap:Sender

Login to the Admin interface hangs after login.

Any ideas? many thanks

[dkarp]

Can you post the stack trace from mailbox.log?

Did you change the server name during the upgrade?

[ardan]

Hope this is what you need. I am trying to re-install my earlier version at present and hopefully restore my data.

2007-04-25 23:37:35,026 INFO [http-7071-Processor48] [ip=192.168.0.7;name=admin@immodicus.com;] SoapEngine - handler exception
com.zimbra.common.service.ServiceException: mountpoint loop detected
at com.zimbra.common.service.ServiceException.TOO_MAN Y_HOPS(ServiceException.java:230)
at com.zimbra.soap.ZimbraSoapContext.(ZimbraSoapContext.java:157)
at com.zimbra.soap.DocumentHandler.proxyRequest(Docum entHandler.java:254)
at com.zimbra.soap.DocumentHandler.proxyIfNecessary(D ocumentHandler.java:246)
at com.zimbra.cs.service.account.AccountDocumentHandl er.proxyIfNecessary(AccountDocumentHandler.java:38 )
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:267)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:168)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:90)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:223)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:541)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

Many thanks

[ardan]

Hi, Unfortunately I made the classic mistake of not making a backup before upgrading so you can call me an idiot if you like!
Your question regarding server name change - I changed the server name to reflect the correct mail server name rather than my original machine name when I upgraded.
could this be the root of the problem.
Thanks

[toricred]

Did you get this fixed? I'm having the same problem and am in the same situation you were in. I forgot to backup and changed names during the upgrade.

My wife's going to kill me if I don't get this fixed.

[cvidal]

Hi, Unfortunately I made the classic mistake of not making a backup before upgrading so you can call me an idiot if you like!
Your question regarding server name change - I changed the server name to reflect the correct mail server name rather than my original machine name when I upgraded.
could this be the root of the problem.
Thanks

Hi:

The stack suggest you have an infinite loop in your file system, the question is where. There is probably a soft-link that sends you upwards in the file system to get back to the same place later on.

A "ls -lR | less" may help you find the problem ("ls" should iterate forever also).

If you can't find this, I would proceed in the following way:

- Export your LDAP database with the command:

su - zimbra
openldap/sbin/slapcat -f /opt/zimbra/conf/slapd.conf -l /tmp/ldap.ldif

This will preserve the very essence of your Zimbra system

- Stop Zimbra and move all your /opt/zimbra to a safe place. Your data is still there!

- Rename the server to the old name. It is used to contact LDAP. It seems to work, as your tomcat is running, but you can change it later, once you get it up and running again.

- Look carefully your upgrade log to see if the MySQL data was updated. If it was, do a clean install of the new version. If it wasn't, make a clean Zimbra install using the old version.

- Verify that the new (and empty!) Zimbra works normally. If it doesn't then there is something wrong with the Zimbra SuSE distribution.

- Stop Zimbra and do a backup of the fresh installation in case you need to start all over again (for instance with:
rsync -av /opt/zimbra /somewhere/zimbra.fresh. If you need to restore it later on, you do rsync -av --delete /somewhere/zimbra.fresh/ /opt/zimbra/, do not forget the "/" at the end of the paths!).

Now comes the tricky part. To recover your data you need to copy it back to the right place in the right way. Let start with LDAP.

With the system stopped, you do:

su - zimbra
rm -f openldap-data/*
openldap/slapadd -f /opt/zimbra/conf/slapd.conf -l /tmp/ldap.ldif
exit

This should restore your LDAP database. You can do "openldap/slapcat -f /opt/zimbra/conf/slapd.conf" to verify that it works.

Then you need to copy the following directories (as root):

cd /your/backup/directory
rsync -av --delete db/ /opt/zimbra/db/
rsync -av --delete index/ /opt/zimbra/index/
rsync -av --delete logger/db/ /opt/zimbra/logger/db/
rsync -av --delete ssl/ /opt/zimbra/ssl/
rsync -av --delete store/ /opt/zimbra/store/
rsync -av --delete conf/ /opt/zimbra/conf/

Finally, light a black candle, kiss your right knee, jump 3 times and start Zimbra!

Carlos

[ardan]

Hi Carlos - many thanks for taking the time to help. I will try this as soon as I can get to my pc. However, i think i will light a black candle first :-). Let you know.

[dkarp]

Hi, Unfortunately I made the classic mistake of not making a backup before upgrading so you can call me an idiot if you like!
Your question regarding server name change - I changed the server name to reflect the correct mail server name rather than my original machine name when I upgraded.
could this be the root of the problem.

Make sure that the zimbraMailHost attribute of your accounts match the new name you've applied to your mail server.

[ardan]

Hi Carlos. I tried following your solution but it looks as though the LDAP was a bit more messed up that I thought.

I encountered a few different problems from Reverse Lookup issues (probably because of the initial server name change) as well as some Catalina errors where it said files were missing.

In anycase, I have re-installed a fresh server and got everything running perfectly with recreated users etc. and will now put the disabled install on my development server and try and sort out the LDAP manually etc.

Once I have a clear idea of what went wrong I will endeavour to post here as an update if that is OK so that if anyone else does something dumb like this again then there is an answer!

Many thanks,

Ardan

[dkarp]

Make sure that the zimbraMailHost attribute of your accounts match the new name you've applied to your mail server. This is most likely the problem, and it's a simple fix.