OpenLDAP includes a driver that allows it to store and access data held in MySQL Cluster. It uses the NDB-API to access the database and so the performance is extremely good. One of the great things about the solution is that it lets you simultaneously access the same data through both LDAP and SQL (or the NDB-API or any of the MySQL connectors). This article gives an example of how this can be done.

Prerequisites:

This article assumes that you’ve already installed MySQL Cluster  – if that isn’t the case then please first refer to “Creating a simple Cluster on a single LINUX host” or “Deploying MySQL Cluster over multiple hosts“.

Once MySQL Cluster has been installed, you need to build and configure OpenLDAP to use MySQL Cluster (alternatively, you can engage Symas to provide you pre-built binaries); Johan provides a good walkthrough of this in his Blog “OpenLDAP for MySQL Cluster“. One extra note is that slapd must be run as root due to the ports it accesses. That Blog entry also explains how to test that everything is working – do that before proceeding to the next step.

Example 1 Extending the LDAP Data Schema and reading/writing the data through LDAP and SQL:

The standard schemas that come with OpenLDAP will be suitable for lots of scenarios that have typically used directories. In this article, we’re interested in other applications where we need to store and access additional attributes.

We create a new schema file “x-clusterdb-hlr.schema” that represents some of the data that would be needed for an HLR application:

One thing to note is that the identifier for each objectclass or attributetype has to be globally unique and you should apply for a unique prefix for your organization from the Internet Assigned Numbers Authority – the enterprise ID for clusterdb.com is  33913 and so any identifier starting with 1.3.6.1.4.1.33913 has been defined by clusterdb.com. This article does not attempt to explain exactly how to define your own schema; you can use this example as a starting point and then refer to the OpenLDAP chapter on extending schemas.

To use this schema, you need to copy the schema file to the ‘schema’ directory in the OpenLDAP installation directory – for example “/usr/local/openldap/etc/openldap/schema”. The “slapd.conf” file also needs updating/replacing to include the new schema (and in our case, change the domain and database name to clusterdb):

For this to take effect, you now need to stop and restart the slapd process.

To test that everything is working as intended, we need some test data covering the new schema – create a file called “add_clusterdb_hlr.txt“:

Use the slapadd tool to load the data:

Behind the scenes, OpenLDAP has now created the “clusterdb” database as well as a number of tables:

Again, this article doesn’t attempt to explain all of details around all of these tables but the 2 key ones here are OL_dn2id and clusterdbhlrrecord. The OL_dn2id table is used to map from a distinguished name to an entry-id (eid) which is then used a key into the table that actually holds the data (in our example, clusterdbhlrrecord). A table is created for each objectclass in the LDDAP schema that we’ve added data to (in this example, that means organization and clusterdbhlrrecord:

Clearly, the application can now use LDAP or SQL to read and modify these same fields.

Example 2 Only exposing a subset of the data through LDAP

There are some restrictions on the schema created in MySQL Cluster by OpenLDAP – for example, all columns are varchars. It could be that your application needs a richer data schema when using SQL to access the data, including data that doesn’t need accessing through LDAP. The simplest way to do this would be to have some tables in the data base that aren’t included in the LDAP schema – OpenLDAP just won’t see them.

Another option is to have OpenLDAP only see a subset of the columns in a table (it only sees those fields that are in the LDAP schema). This is fairly straightforward to acheive as OpenLDAP only creates the database and tables if they don’t already exist and it is happy to ignore any columns that are not included. For simplicity, we assume that you’ve executed Example 1 and then we remove the database and then recreate it by hand (and then you should restart slapd):

and then add the same data (which doesn’t contain “contractstart”) as in Example 1 and then use LDAP to check that it has been stored correctly and can be retrieved:

As you can see, the ‘contractstart’ field is ignored by OpenLDAP but we can work with it through SQL:

Example 3 Making rows added through SQL visible through OpenLDAP

This example builds upon  Example 2 by showing how rows can be added to the clusterdbhlrrecord and then be accessed using LDAP.

The first step is to just add the row:

When we try to read this entry through LDAP, it can’t be found:

The reason for this is that this row doesn’t yet have a corresponding entry in the OL_dn2id table; that can now be fixed:

If you want to hide this extra step from the application then you can of course use stored procedures to automatically add the extra row to OL_dn2id.