Failed 32-bit to 64-bit Server Migration

[LMStone]

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:

1. Run install.sh -s on the new server.
2. Copy /opt/zimbra/zimbramon to /opt-zimbramon-64bit (we'll copy it back later to avoid the "wrong ELFCLASS" error).
3. Export LDAP from the 32-bit server and rsync ldap.bak to the 64-bit server.
4. Shut down Zimbra on the 32-bit server and rsync the whole /opt/zimbra tree to the new server.
5. On the 64-bit server move the 32-bit zimbramon directory aside and move the 64-bit zimbramon directory back in place.
6. Update DNS to point to the new server and test.
7. Wipe the appropriate openldap data directories on the new server and import the ldap data exported from the 32-bit server back in.
8. Rerun on the 64-bit server install.sh but without the "-s" switch.
9. 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.
10. 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.

Thanks!
Mark

[Klug]

It might not be related, but SLES11-SP1 is only supported with 6.0.9.

[LMStone]

It might not be related, but SLES11-SP1 is only supported with 6.0.9.

Thanks for the fast reply!

I don't think SLES11-SP1 s related here because it's not that things don't run, it's that portions of the ZCS configuration are not being read/interpreted correctly by the installer.

I am curious where you saw that SLES11-SP1 is not supported though; we run a number of ZCS 6.0.8 systems on this platform with no issues and I believe I recall an interchange with Quanah somewhere that this was OK.

I'm also curious when you do your initial ZCS installs on a new server if you accept the installer's prompt to create the default domain as the FQDN of the server, instead of altering the default domain to be the domain name portion of the FQDN, sans hostname?

Typically, we change the default domain the installer suggests to be the domain name portion of the server's FQDN, sans hostname. This has worked for us OK so far, and I can think of two previous 32-bit > 64-bit migrations where I have had no problems when the system was configured in this way.

We did not do the initial install on this server however, and this failed migration is a first for us.

When running the installer the final time (without the "-s" switch), many of the domain related configuration elements have the full FQDN instead of just the default domain, and while it is clear the installer successfully picked up much of the migrated configuration successfully, many things default-domain related were not picked up. For example, although the installer starts LDAP successfully and is able to verify some of the LDAP passwords, the Postfix and amavis passwords are unverifiable. The installer also prompts to create new spam and ham accounts on the FQDN instead of seeing the existing accounts on the default domain. Things like that...

None of that seems at all related to a service pack level to me, at least at the moment. On the other hand, the migration isn't working so I'm open to investigating any suggestions! :-)

Does that help clarify things? Any other ideas where this might be going so wrong?

Thanks again!

Best regards,
Mark

[Klug]

zmhostname on the 32 bits server is set to webmail.myclient'sdomain.com or stg else (myclient'sdomain.com)?

About the SP, I don't think it's related. It's part of the 6.0.9 features, that's where I saw it as "new" (and so thought it's not supported on previous releases).

[LMStone]

When I do dig `zmhostname`, nslookup `zmhostname` and zmprov gas on the 32-bit server I get back webmail.myclient'sdomain.com from the DNS server, and that matches what's in /etc/hosts.

When I do zmprov gad I get back myclient'sdomain.com.

Does that help clarify the current config?

Thanks!
Mark

[quanah]

SLES11 SP0 is not supported. SLES11 SP1 is most definitely supported. This is due to a snafu by Novell where the updated the glibc version in SLES11 SP1, making it so software built on SLES11 SP1 is not compatible with SP0.

[LMStone]

Thanks Quanah for clarifying where things stand with Zimbra and SLES.

While we have you... :-)

Any ideas on the LDAP errors we are experiencing with this attempted migration?

With best regards, and TIA,
Mark

[Krishopper]

For what its worth, when I went from 32 to 64-bit, I set up the new 64-bit server as a second server (second MTA, LDAP, mailbox server, etc.). I promoted the 64-bit LDAP server to primary, and slowly migrated all of the mailboxes over from the 32-bit mailbox server to the 64-bit mailbox server (Network Edition required for this, obviously). Saved a lot of pain and downtime. The only downtime experienced was to promote the secondary (64-bit) LDAP server to the primary.

[LMStone]

For what its worth, when I went from 32 to 64-bit, I set up the new 64-bit server as a second server (second MTA, LDAP, mailbox server, etc.). I promoted the 64-bit LDAP server to primary, and slowly migrated all of the mailboxes over from the 32-bit mailbox server to the 64-bit mailbox server (Network Edition required for this, obviously). Saved a lot of pain and downtime. The only downtime experienced was to promote the secondary (64-bit) LDAP server to the primary.

We discussed that option with the client, but it was not practicable as too many users have hard-coded the server name in various weblinks, Outlook configuration files, etc. (there is no proxy server).

IOW, we needed to do a migration which required no changes on the client end.

Thanks for the suggestion though!

All the best,
Mark

[acesuares]

Did you check this out: From 6.04 -> 6.08, Ubuntu 8.04 -> 10.04, 32bit -> 64bit

Your errors where exactly the same as mine.

Form your description I see you follow a slightly different way then I did. The zimbramon, I only linked one directory to avoid the ELFCLASS error. You moved away the whole directory.

Also I don't see you move the DB_CONFIG file from the old to the new server.

Also, you first install the new zimbra,. the rsync the old over the new.
I didn't do that; I first copied and then installed (i.e. upgraded).

I also ran fixperms frequently :-)

Maybe you could follow my (trial & error) recipe and let us know if it improved the situation?

Cheers
ace

By no means claiming that I know what I do :-)