Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Failed 32-bit to 64-bit Server Migration

  1. #1
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default Failed 32-bit to 64-bit Server Migration

    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

  2. #2
    Join Date
    Mar 2006
    Location
    Beaucaire, France
    Posts
    2,322
    Rep Power
    13

    Default

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

  3. #3
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by Klug View Post
    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

  4. #4
    Join Date
    Mar 2006
    Location
    Beaucaire, France
    Posts
    2,322
    Rep Power
    13

    Default

    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).

  5. #5
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    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

  6. #6
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,285
    Rep Power
    10

    Default

    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.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  7. #7
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    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

  8. #8
    Join Date
    Dec 2006
    Location
    Minneapolis MN
    Posts
    777
    Rep Power
    9

    Default

    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.
    01 Networks, LLC / Cybernetik.net
    Zimbra NE and OSS Cloud Hosting
    Shared Web Hosting
    Consulting Services

  9. #9
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by Krishopper View Post
    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

  10. #10
    Join Date
    Apr 2009
    Location
    Willemstad, Curacao
    Posts
    39
    Rep Power
    6

    Default

    Did you check this out: http://www.zimbra.com/forums/adminis...bit-64bit.html

    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 :-)

Similar Threads

  1. LDAP Cannot bind on migration to new server
    By neekster in forum Migration
    Replies: 23
    Last Post: 03-09-2009, 02:08 AM
  2. LDAP failed after i changed my server
    By crowley in forum Installation
    Replies: 3
    Last Post: 02-03-2009, 02:37 AM
  3. Replies: 1
    Last Post: 03-31-2008, 08:24 PM
  4. Replies: 2
    Last Post: 09-09-2007, 04:27 PM
  5. Error 256 on Installation
    By RuinExplorer in forum Installation
    Replies: 5
    Last Post: 10-19-2006, 09:19 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •