Promoting Replica to LDAP Master

 - This is certified documentation and is protected for editing by Zimbra Employees & Moderators only.

Article Information
This article applies to the following ZCS versions. ZCS 7.0 ZCS 6.0

Only one master LDAP server can exist and this LDAP server is authoritative for user information, server configuration, etc. The instructions that follow explain how to promote a replica LDAP server to master and disable the previous LDAP master.

Promoting a Replica Server – Demoting the Master Server

Before you can promote a replica LDAP server to become the master LDAP server, your LDAP replication servers must be up and working correctly; that is the replica LDAP server(s) must be receiving LDAP updates from the master. See the Multi-Server Installation Guide, LDAP Replication Installation chapter.

To promote a replica server to be master

1. Shut down all services on all ZCS servers by running zmcontrol stop.
2. On the replica LDAP server that will be the new master LDAP server, do the following as the zimbra user:

a. Start ldap: ldap start

b. Note the ldap root password, as it will be used extensively: zmlocalconfig -s ldap_root_password

c. Update the main ldap database to be a master:

ldapmodify -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcDatabase={2}hdb,cn=config changetype:modify delete: olcSyncrepl ldapmodify -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcDatabase={2}hdb,cn=config changetype:modify delete: olcUpdateRef ldapmodify -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config changetype:modify add: olcSpCheckpoint olcSpCheckpoint: 20 10 ldapmodify -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config changetype:modify add: olcSpSessionLog olcSpSessionlog: 500

d. Prepare the accesslog database for the new master:

ldap stop cd /opt/zimbra/data/ldap mkdir -p accesslog/db mkdir -p accesslog/logs

e. Copy in the relevant DB_CONFIG file. For a custom DB_CONFIG:

cp /opt/zimbra/conf/custom/ldap/DB_CONFIG.accesslog /opt/zimbra/data/ldap/accesslog/db/DB_CONFIG

For the default DB_CONFIG:

cp /opt/zimbra/openldap/var/openldap-data/DB_CONFIG.accesslog /opt/zimbra/data/ldap/accesslog/db/DB_CONFIG

Start ldap again:

ldap start

f. Add the accesslog database:

ldapadd -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcDatabase={2}hdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /opt/zimbra/data/ldap/accesslog/db olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 10000 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 ldapadd -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE ldapadd -x -H ldapi:/// -D "cn=config" -w "ldap root password" dn: olcOverlay=accesslog,olcDatabase={3}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 00+04:00

g. Update the localconfig values for this server:

zmlocalconfig –e ldap_master_url= <new_master_directory_address> zmlocalconfig –e ldap_url= <new_master_directory_address> zmlocalconfig –e ldap_is_master= true zmlocalconfig –e ldap_host= <newmaster_directory_host>

h. On all other servers, update the localconfig values:

zmlocalconfig –e ldap_master_url= <new_master_directory_address> zmlocalconfig –e ldap_host= <newmaster_directory_host>

i. On all the other servers, update zmlocalconfig -e ldap_url to remove the old master server. It should already include the new one.

j. Use the tool zmldapreplicatool to update the LDAP Master URI in the syncrepl configuration for each replica (ZCS 7.x only)

k. Update the passwords stored in localconfig for the amavis, postfix, and nginx users to match the values stored in localconfig on the old master. This will ensure that if you run a ZCS upgrade on the new master, the passwords are preserved correctly.

3. Now you run zmmtainit to edit the ldap*.cf files in /opt/zimbra/conf to set the new master LDAP server as the authority for the MTA.These files tell Postfix how to connect to the LDAP server for various commands. If you are moving the directories, you might have Postfix pointing to a server that no longer runs LDAP, which will cause mail delivery to stop.

Note: zmmtainit should be run on the hosts that are running an MTA, but is not required on the other hosts.

As zimbra, type the following. The "XX" is a dummy value. The zmmtainit command will use the ldap_url value from localconfig in spite of this.

/opt/zimbra/libexec/zmmtainit XX

4. Start the new LDAP master, type zmcontrol start. Then start up the services on all the other servers. At this point, services should be up and running on all hosts, and they should all be working off the new Master LDAP server.

Note: After the replica is promoted to Master, you should verify that the backup schedule is correctly set. Run zmschedulebackup -q. The schedule should match the backup schedule on the Mail Stores. If the backup schedule does not, run the zmschedulebackup command to set the backup schedule.

Shut down the previous master

The old LDAP master must be disabled.

Related Articles

LDAP

---