King0770-Notes-Merge Two Independent Machines: Difference between revisions

No edit summary
No edit summary
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{WIP}}
{{BC|Community Sandbox}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=King Notes Merge two Independent Machines=
{{KB|{{Unsupported}}|{{ZCS 7.0}}|{{ZCS 6.0}}|}}
{{Archive}}{{WIP}}


'''Summary of steps'''
'''Summary of steps'''
Line 7: Line 12:
* Configure servers
* Configure servers
* Test
* Test
* Potential Issues


Scenario: You have two ZCS machines, but they are independent of each other. Now a decision has been made to join the machines together.  
Scenario: You have two ZCS machines, but they are independent of each other. Now a decision has been made to join the machines together.  
Line 49: Line 55:
This is actually pretty straight forward. Basically we're going to export the ldap info into a file. Normally we can use the zmslapcat tool to export ldap info, however, we will need to parse out some superfluous info that zmslapcat would include.
This is actually pretty straight forward. Basically we're going to export the ldap info into a file. Normally we can use the zmslapcat tool to export ldap info, however, we will need to parse out some superfluous info that zmslapcat would include.


Here's a small script to help facilitate this step. Basically, this will export all info the ldap-master will need to import.
Here's a small script to help facilitate this step. Basically, this will export all info ServerB will need to import.


<code><pre>
<code><pre>
Line 63: Line 69:


echo "Creating file in /tmp."
echo "Creating file in /tmp."
ldapsearch -x -h `zmhostname` -D $zimbra_ldap_userdn -w $zimbra_ldap_password -LLL \
ldapsearch -x -h `zmhostname` -D $zimbra_ldap_userdn -w $zimbra_ldap_password -LLL "(|(objectClass=*))" >> /tmp/`zmhostname`_`date +%F`.ldif
"(|(objectClass=zimbraDomain)(objectClass=zimbraAccount)(objectClass=zimbraServer)(objectClass=zimbraCOS))" >> /tmp/`zmhostname`_`date +%F`.ldif




Line 78: Line 83:
ldapadd -x -h `zmhostname` -D uid=zimbra,cn=admins,cn=zimbra -c -w `zmlocalconfig -s -m nokey zimbra_ldap_password` -f /tmp/temp.ldif"
ldapadd -x -h `zmhostname` -D uid=zimbra,cn=admins,cn=zimbra -c -w `zmlocalconfig -s -m nokey zimbra_ldap_password` -f /tmp/temp.ldif"
</pre></code>
</pre></code>
Or you can use the alternative method.
<code><pre>
Example:
source /opt/zimbra/bin/zmshutil
zmsetvars
ldapadd -x -h `zmhostname` -D $zimbra_ldap_userdn -c -w $zimbra_ldap_password -f /tmp/temp.ldif"
</pre></code>


Once the data is imported, restart ZCS services.
Once the data is imported, restart ZCS services.
Line 122: Line 140:
</pre></code>
</pre></code>


<strong>ZCS-6.0</strong>
<code><pre>
ldap stop


Or you can script it.
cd /opt/zimbra/data/ldap/hdb/db
<code><pre>


#!/bin/bash
~/bdb/bin/db_recover


echo "What is the hostname of the ldap master?"
rm -rf alock *.bdb ../logs/*
read MAST


zmlocalconfig -e ldap_is_master=false
cd /opt/zimbra/data/ldap/accesslog/db/
zmlocalconfig -e ldap_master_url="ldap://$MAST:389"
zmlocalconfig -e ldap_url="ldap://`zmhostname`:389 ldap://$MAST:389"
zmlocalconfig -e ldap_host=$MAST


sleep 1
~/bdb/bin/db_recover


echo "Running zmldapenablereplica"
rm -rf alock *.bdb ../logs/*
/opt/zimbra/libexec/zmldapenablereplica


ldap start
</pre></code>
</pre></code>


After making the changes for ldap replication, be sure to restart ZCS services.  
After making the changes for ldap replication, be sure to restart ZCS services.  
Line 151: Line 168:
</pre></code>
</pre></code>


'''Note: You may need to run /opt/zimbra/libexec/zmldapenablereplica on both machines. If one of the machines can't connect to the other, try running zmldapenablereplica on both machines.'''


=== Server B ===
=== Server B ===
Line 181: Line 199:
zmprov gaa
zmprov gaa
</pre></code>
</pre></code>
Try making a slight change to one of the users from the ldap-master machine, and see if you see the change from the ldap-replica machine.


==Section VI - Undocumented / Potential Issues==
==Section VI - Undocumented / Potential Issues==
Will document any known issues as I am made aware. More to follow I am sure.
=== Default COS ===
One of the issues that you should be aware of is the fact that both machines will likely have the "default" COS. It may be advantageous to make the default COS from both machines to match as close as possible. Specifically, find out if the same options/features are enabled one both machines. You could run the command below from each machine into a file, and run a diff on the files from each machine. This should give you an idea of what are the differences are in the default COS between the two machines. Basically you want to make sure users are not losing any features in the default COS.
 
<code><pre>
/opt/zimbra/openldap/sbin/slapcat -f ~/conf/slapd.conf -s cn=default,cn=cos,cn=zimbra
</pre></code>
 
<strong>ZCS-6.0</strong>
<code><pre>
/opt/zimbra/openldap/sbin/slapcat -F ~/data/ldap/config/ -s cn=default,cn=cos,cn=zimbra
</pre></code>


{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}
[[Category:Community Sandbox]]
[[Category:Community Sandbox]]
[[Category:LDAP]]
[[Category:LDAP]]
[[Catagory:King0770-Notes]]

Latest revision as of 22:23, 5 December 2018

King Notes Merge two Independent Machines

   KB 2837        Last updated on 2018-12-5  




0.00
(0 votes)


Summary of steps

  • Prepare ZCS machines
  • Export ldap data from ServerA
  • Import ldap data into ServerB
  • Configure servers
  • Test
  • Potential Issues

Scenario: You have two ZCS machines, but they are independent of each other. Now a decision has been made to join the machines together.

Why merge two different Zimbra machines?

Possible reasons:

Section I - Prepare ZCS Machines

ZCS Versions

Be sure both machines have the same ZCS version.

LDAP Passwords

LDAP passwords need to be same on both machines.

Run the following command on both machines.

zmlocalconfig -s | grep pass | grep ldap

If the passwords do not match between the two machines, you will need to change the passwords so the passwords match between both machines. After changing the passwords, you will need to restart ZCS services.
(See http://wiki.zimbra.com/index.php?title=Resetting_LDAP_and_MySQL_Passwords#Resetting_the_LDAP_Password)

zmldappasswd -h
Usage: /opt/zimbra/bin/zmldappasswd [-h] [-r] [-p] [-l] newpassword
        -h: display this help message
        -a: change ldap_amavis_password
        -l: change ldap_replication_password
        -n: change ldap_nginx_password
        -p: change ldap_postfix_password
        -r: change ldap_root_passwd
        Only one of a, l, n, p, or r may be specified
        Without options zimbra_ldap_password is changed

Section II - Export ldap data from ServerA

This is actually pretty straight forward. Basically we're going to export the ldap info into a file. Normally we can use the zmslapcat tool to export ldap info, however, we will need to parse out some superfluous info that zmslapcat would include.

Here's a small script to help facilitate this step. Basically, this will export all info ServerB will need to import.

#!/bin/bash

if [ `whoami` != "zimbra" ]; then
        echo "You must be the zimbra user to run this script."
exit 0
fi

source /opt/zimbra/bin/zmshutil
zmsetvars

echo "Creating file in /tmp."
ldapsearch -x -h `zmhostname` -D $zimbra_ldap_userdn -w $zimbra_ldap_password -LLL "(|(objectClass=*))" >> /tmp/`zmhostname`_`date +%F`.ldif


Note: The ldapsearch command is on one line.

Section III - Import ldap data into ServerB

After generating the ldif file on ServerA, transfer it to ServerB. And run ldapadd to import the data into ServerB.

Example: 
ldapadd -x -h `zmhostname` -D uid=zimbra,cn=admins,cn=zimbra -c -w `zmlocalconfig -s -m nokey zimbra_ldap_password` -f /tmp/temp.ldif"

Or you can use the alternative method.

Example:
source /opt/zimbra/bin/zmshutil

zmsetvars

ldapadd -x -h `zmhostname` -D $zimbra_ldap_userdn -c -w $zimbra_ldap_password -f /tmp/temp.ldif"


Once the data is imported, restart ZCS services.

zmcontrol stop

zmcontrol start

Section IV - Configure servers

Deciding which machine will be a ldap-master/replica

Up to this point, we were using "ServerA" and "ServerB" in generic terms. We haven't used "ldap-master" and "ldap-replica" terms yet. But now, it is important to be cognizant of which machine will be an ldap-master and which machine will be an ldap-replica. In this article, ServerA exported it's ldap data, and ServerB imported ServerA's ldap data, for our purposes here, ServerA will be an ldap-replica, and ServerB will be an ldap-master once this operation is complete.

ServerA

At this point, we will need to configure ServerA to be an actual ldap-replica.

For this step do the following:

ldap stop

cd /opt/zimbra/openldap-data

/opt/zimbra/sleepycat/bin/db_recover

rm alock *.bdb logs/*

cd /opt/zimbra/openldap-data/accesslog/db

/opt/zimbra/sleepycat/bin/db_recover

rm -rf /opt/zimbra/openldap-data/accesslog

ldap start

Change the server’s local config file to designate it as a replica. Here's an example to go by.

zmlocalconfig –e ldap_master_url="ldap://ServerB:389"
zmlocalconfig –e ldap_url="ldap://ServerA:389 ldap://ServerB:389"
zmlocalconfig –e ldap_is_master=false
zmlocalconfig -e ldap_host=ServerB
/opt/zimbra/libexec/zmldapenablereplica

ZCS-6.0

ldap stop

cd /opt/zimbra/data/ldap/hdb/db

~/bdb/bin/db_recover

rm -rf alock *.bdb ../logs/*

cd /opt/zimbra/data/ldap/accesslog/db/

~/bdb/bin/db_recover

rm -rf alock *.bdb ../logs/*

ldap start


After making the changes for ldap replication, be sure to restart ZCS services.

zmcontrol stop

zmcontrol start

Note: You may need to run /opt/zimbra/libexec/zmldapenablereplica on both machines. If one of the machines can't connect to the other, try running zmldapenablereplica on both machines.

Server B

If you haven't restarted ZCS services in Section III by now, go ahead and restart ZCS services.

zmcontrol stop

zmcontrol start

Update SSH keys

Don't forget to run "zmupdateauthkeys" on both machines to update their SSH keys

zmupdateauthkeys

Section V - Test

After both machines have been rebooted, each machine should be able to see each other.

Run the following command from the ldap-replica, both machines should be displayed. If you can see both machines, the merge was successful.

zmprov gas

And run the following to see all the users from the ldap-replica

zmprov gaa

Try making a slight change to one of the users from the ldap-master machine, and see if you see the change from the ldap-replica machine.

Section VI - Undocumented / Potential Issues

Default COS

One of the issues that you should be aware of is the fact that both machines will likely have the "default" COS. It may be advantageous to make the default COS from both machines to match as close as possible. Specifically, find out if the same options/features are enabled one both machines. You could run the command below from each machine into a file, and run a diff on the files from each machine. This should give you an idea of what are the differences are in the default COS between the two machines. Basically you want to make sure users are not losing any features in the default COS.

/opt/zimbra/openldap/sbin/slapcat -f ~/conf/slapd.conf -s cn=default,cn=cos,cn=zimbra

ZCS-6.0

/opt/zimbra/openldap/sbin/slapcat -F ~/data/ldap/config/ -s cn=default,cn=cos,cn=zimbra
Verified Against: Zimbra Collaboration 8.0, 7.0 Date Created: 04/16/2014
Article ID: https://wiki.zimbra.com/index.php?title=King0770-Notes-Merge_Two_Independent_Machines Date Modified: 2018-12-05



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Catagory:King0770-Notes

Jump to: navigation, search