Ldap – How to modify/add a new objectClass to an entry in OpenLDAP

I've been struggling with the same thing, the openldap documentation is minimalist and hardly helpful at all. When they went over to a config database (not a bad idea in principle) all the options changed so when people are giving example from /etc/ldap/slapd.conf it is useless with a modern slapd config (such as Ubuntu).

I finally got this working. Here's the summary... first LDIF file:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof

Second LDIF file:

dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Add them into the config database using ldapadd (same as normal config stuff).

It does not automatically update the existing data in the database, so I needed to use slapcat to copy everything out into a temporary file, and visit each group, delete the group and add the same group back in again (forces the memberOf attributes to update correctly). If you are starting with an empty database, then it will correctly update the attributes as objects are added.

Also, note that "olcDatabase={1}hdb" is very typical, but not guaranteed to match your setup. Be sure to check that one.

I use OpenLDAP supporting a user-base of about 10,000 active users who rely on it throughout the day for everything. Problems are rare. Many services rely on it, for authentication and other things.

However, we have 4 read-only replicas (slaves/consumers) behind a load-balancer, a hidden master and a hot standby master. Used to be 2 front-end servers, but we had load problems during certain peak times (when 4,000 or so of those users were desperately trying to hit it at the same second). All write access to LDAP is via our code.

That equipment and OS is all old and we're working on replacing it with a new setup that will go back to only 2 replicas (that aren't doing as many other things) and "mirror mode" replication between a pair of masters in an HA configuration. Again, problems are rare.

We used to have some problems with replication failing, but that's mostly from when we were using slurpd instead of syncrepl. Also, unclean shutdowns of a server can corrupt the data.

Keys to running OpenLDAP in a large-scale production environment, in my experience:

1. Somebody that understands LDAP and OpenLDAP well. Preferably more than one somebody.
2. Somebody that understands all the other directly related parts of the infrastructure well.
3. Somebody that understands how OpenLDAP replication works.
4. A reasonable understanding of the BerkeleyDB options (or whatever backend you're using), since the defaults aren't quite right.
5. Highly available slaves. More than 1. Better: really load-balanced.
6. **Active-passive masters (active-active master replication is inherently tricky)
7. We back up LDAP data to LDIF every hour and keep a few days worth of those on disk. (the whole server gets backed up nightly)
8. We have scripts to quickly bring a broken slave back to a clean current data replica
9. We have scripts to quickly restore a broken master from the LDIF backups (via slapadd)
10. We can quickly switch to the standby master. (scripts)
11. We monitor that the replication connections are alive
12. We monitor that the replications IDs are current on all slaves
13. We monitor (less often) that the entire contents of the slaves match the master.

Basically, though, if it's a key part of your infrastructure, somebody on your team should really understand it well.

Addendum: By request, the DB_CONFIG file from my openldap DB directory. Look at http://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.html for details.

set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728