ClearFoundation

If you are in a migration strategy or if disaster strikes your master ClearOS server, you may need to promote your OpenLDAP replicate server to a master. This guide will show you how to easily make the switch.

First, validate that the organizational information is the same between your master and the replicate (all but the Internet Hostname). If your master server is not available, you can glean this information from the replicate by running:

slapcat -n3 > /tmp/ldapdumpfile

Then edit /tmp/ldapdumpfile and locate a default user. The information in the following attributes is pertinent:

• o
• ou
• street
• l
• st
• c
• postalCode

This information can be entered into Webconfig on the replicate by navigating to Directory > Setup > Organization.

Second, validate the the directory (which is currently read only) on the replicate server is complete and viable. You can do this by validating the user list in Webconfig or by perusing the directory.

Next, locate a copy of /etc/openldap/slapd.conf from the old master server. You will need to either get this from the live server (migration scenario) or from a backup source (disaster recovery scenario). Backup the replicate settings as well.

cp /etc/openldap/slapd.conf /etc/openldap/slapd.conf.old.replicate

Stop the LDAP services.

service ldap stop

Manually change the mode in /etc/cleardirectory/config from 'replicate' to 'master' or to 'standalone'.

vi /etc/cleardirectory/config

The file should look something like this now:

mode = master

Next, copy the configuration file from the master over the config for the replicate. If the master config file was copied to /root your command may look like this:

cp /root/slapd.conf /etc/openldap/slapd.conf

Confirm the overwrite.

Finally, ensure that the permissions on the slapd.conf are correct:

chown root:ldap /etc/openldap/slapd.conf
chmod 640 /etc/openldap/slapd.conf

Now, start the LDAP server by running the following:

service ldap start

It should execute without errors. Ensure that the database is viable by creating a test group or user.

Replication of the directory causes Samba elements to be migrated between servers. This does not, however, ensure a proper migration of Samba. If your replicate was NOT a backup domain controller then you may have issues causing the replicate server to authenticate requests properly without some major command line tweaking. If the server was a backup domain controller you will need to go through an additional process of migration for the Samba elements.