OpenLDAP syncrepl Replication
From Notes
Based on OpenLDAP 2.3.34.
Contents |
Overview
Replication is performed using OpenLDAP's syncrep overlay which allows the provider to request updates from the consumer. Clients are able to modify entries when addressing the consumer through referrals which inform the client they need to communicate with the provider and allow the client to do so by passing the request and credentials to the provider (take not for ACL revisions).
All communication is secured through SSL/TLS between the LDAP clients and servers. Although the LDAP servers are listening on ports 389 and 636, each requires at least 128 bit encryption for client communication when using the proper security settings.
The provider is setup to provide updates to any number of consumers through the following entries in the /etc/openldap/slapd.conf file:
moduleload /usr/lib/openldap/syncprov.la overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index entryCSN eq index entryUUID eq
Once the provider is configured, the consumers must be configured to pull from the provider and have appropriate permissions to read all attributes that they will replicate. An example follows:
referral ldaps://provider.example.com/ moduleload /usr/lib/openldap/syncprov.la syncrepl rid=123 provider=ldaps://provider.example.com/ type=refreshOnly interval=00:00:05:00 searchbase="dc=example,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicator,ou=People,dc=example,dc=com" credentials=<password>
To configure any additional consumers, the same attributes may be used as long as the rid is unique among the consumers. Note that a database must be defined on the consumer.
No additional steps are required. When started the consumer will fully populate the database and maintain a synchronized directory tree. If there are ever errors in replication (mis-matched schema, etc..) stop the consumer, remove all database and logs and restart the consumer LDAP process. This will repopulate the DIT entirely.
- ldapsearch and the rest of the LDAP command line commands work from all clients.
- Password changes are possible from all clients by issuing the 'passwd' command.
New Consumer Setup
Install openldap-servers.
rpm -ivh openldap-servers-2.3.34-centos4.i686.rpm
Resolve any dependencies, [=rpm -qR <package>] lists dependencies.
Generate an SSL certificate and key for the new consumer.
Copy the slapd.conf from existing consumer host and change the rid to a unique rid.
Copy all schemas from the provider to ensure they are all present. (I have added a few custom schemas.)
scp provider.example.com:/usr/share/openldap/schema/* /usr/share/openldap/schema/
Start the ldap service on the new consumer -- it should load completely from the provider with no intervention and be open for business.
LDAP Directory Recovery from Backup
Copy slapd.conf from master or cfengine to new master.
Copy all schemas from master to new master (or verify existence). /(These will be in cfengine soon.)/
scp provider.example.com:/usr/share/openldap/schemas/* /usr/share/openldap/schemas/
Copy backup from backup location to /tmp:
scp backup.example.com:/svr/backup/ldap-backups/YYYYMMDD.ldap-backup.tgz /tmp
Un-compress the archive and move to proper location:
tar xzvf /tmp/20070508.ldap-backup.tgz -C / mv /var/lib/ldap/backup/dc_example_dc_com/* /var/lib/ldap/
Create and/or verify certs. I have begun creating all LDAP certs with the following subject alternative names to make provider/consumer swaps seamless:
<fqdn of host> ldap-master.example.com ldap-slave.example.com
Start the LDAP provider.
Note: the above procedure worked flawlessly with OpenLDAP 2.3.34.
Command Line Primer
Search a directory anonymously:
ldapsearch -x -H ldaps://<host>/
Search a directory, bind as user (will get password prompt):
ldapsearch -x -H ldaps://<host>/ -D "<bind DN>" -W
Search a directory, anonymous bind, retrieve specific user (or other object):
ldapsearch -x -H ldaps://<host>/ [<attributes>]
Troubleshooting
- The most common problem with connections will be err=49 which is invalid credentials, and TLS/SSL errors with insufficient level of security. Note the level of security presented in the log and either adjust the client to a higher level or consider lowering the requirement on the server. It would be much better to increase the level on the client, if possible.
- To adjust the log level for troubleshooting, consider setting the log level to [=any] which will log all possible information and give the clearest (most verbose) picture of the situation. This change is made in the [=/etc/openldap/slapd.conf] file. If the [=cfexecd] process is not halted then the change will not persist very long so it is recommended that this process be halted prior to troubleshooting and started after troubleshooting is over.
/etc/openldap/slapd.conf loglevel any
