OpenLDAP Best Practices Summary

Date: 10-05-2022

How to Direct Write/Update Traffic

It is technically acceptable to direct write traffic to any master in a multi-master replication (MMR) environment. To do so causes increased replication processing and network traffic. It is better to direct writes to only one master at a time and keep the others as standbys for failover or roll-over for maintenance.

On replica servers that do not replicate changes, chaining should be configured so that unexpected write requests are chained (resubmitted) to a/the master. If a load-balancer is used to set up a Virtual IP VIP) address for write traffic, chaining should be to that VIP.

For more information, see the discussion below.

Only use the "quiet" ("-q") option on "slapadd" for testing

Many people see the "-q" option on "slapadd", the database load utility. The documentation says it can speed up the loading of data. If you use "-q", any errors in the input file will be loaded. All checking is off. That guarantees operational problems in production. Nobody needs operational problems. Don't use "-q" on anything but a backup file from a "known-good" server.

Make sure servers are configured to use network time

Replication depends heavily on accurate timing. Make sure that system clocks on all servers in the cluster are synchronized with NTP or similar service.

Do not modify standard schema files

The standard schema files in "/opt/symas/etc/openldap/schema" are overwritten during upgrades of OpenLDAP and any changes made will be lost.  Instead, all changes should be made in custom .schema files.

Separate custom schemas from standard schemas

Custom schemas should be stored in a separate folder from the standard schema files.  Separating schemas will ensure the custom ones aren't deleted/overwritten during OpenLDAP upgrades.  We recommend storing custom schemas in the following path:

• Unix/Linux: "/opt/symas/etc/openldap/local-schema"
• Windows: 

Replication basics

Producers = Masters
Consumers = Slaves/Replicas

MMR = Multi-Master Replication

Non-MMR Providers do not require a syncrepl section
Non-MMR Providers require the following:

moduleload syncprov.la
index entryCSN eq
index entryUUID eq
overlay syncprov

MMR Providers (aka MMR Cluster Members) do require a syncrepl section and the "mirrormode on" ("multiprovider on" in SOLD 2.5+) option:

• If syncrepl is present no writes are allowed.
• If syncprov is present writes are allowed.
• If syncprov and syncrepl are present writes are allowed if mirrormode is set to on.

The overlay syncprov stanza should be located below (after) the syncrepl section on MMR producers
    
Non-MMR and MMR consumers do not require the syncprov module or overlay.

Non-MMR and MMR consumers do require the following:

index entryCSN eq
index entryUUID eq
syncrepl section

Indexing should be the same on providers and consumers.

MMR and Non-MMR consumers and MMR providers syncrepl sections can be identical since slapd overlooks any RID that points to the server itself.

The replication account must have access to all attributes in the directory. Create ACLs that will give the replication user access to the required attributes:

access to *
  by dn.exact="cn=replicator,dc=example,dc=com" read