First time I've seen this happen...
The 32-bit server is running 6.0.8 on SLES10. The target server is running 64-bit SLES11-SP1.
We used the technique:
- Run install.sh -s on the new server.
- Copy /opt/zimbra/zimbramon to /opt-zimbramon-64bit (we'll copy it back later to avoid the "wrong ELFCLASS" error).
- Export LDAP from the 32-bit server and rsync ldap.bak to the 64-bit server.
- Shut down Zimbra on the 32-bit server and rsync the whole /opt/zimbra tree to the new server.
- On the 64-bit server move the 32-bit zimbramon directory aside and move the 64-bit zimbramon directory back in place.
- Update DNS to point to the new server and test.
- Wipe the appropriate openldap data directories on the new server and import the ldap data exported from the 32-bit server back in.
- Rerun on the 64-bit server install.sh but without the "-s" switch.
- LDAP as started by the installer starts and runs fine, but the installer pauses after throwing NO SUCH SERVER error and prompts me to confirm the amavis and postfix LDAP passwords, which verification fails, so we quit the installer.
- Same thing happens if we run zmsetup.pl.
The only thing I can think of after searching the forums is that the 32-bit server has only one domain on it: myclient'sdomain.com and the fqdn of the server is webmail.myclient'sdomain.com -- the domain the installer says it cannot find.
I've checked localconfig.xml by hand, and the LDAP import went fine with no errors. And we know that when you do the very first fresh install, Zimbra prompts you to create the default domain as the whole fqdn of the server, instead of the domain you really intend to use.
Is the solution therefore as simple as adding webmail.myclient'sdomain.com as an alias domain on the 32-bit server and then doing it all again?
I'm asking here first because with almost half a terabyte of data, rerunning those rsyncs takes more than two hours alone, and the client is sensitive to downtime.