Novell eDirectory has a lot of great features. Its replication and partitioning are fairly unique in the industry. Performance is pretty good overall.

There are many tricks available to boost performance, and one of them is the use of an Index.

Indexes in eDirectory come in four flavours.

• System
• Value
• Presence
• Substring

You can see the indexes several different ways. There is a snapin for Console One that shows the indexes set when you look at the properties of the Server object. There is a plugin for iManager as well, that in fact has several features that make it much nicer than the Console One snapin.

If you do not have the Console One snapin, you can still see the Indexes defined in the indexDefinition attribute of the server object in the Other tab. You can see this the same basic way via an LDAP browsing tool.

Substring is a very very powerful index, but it is expensive to maintain and expensive in terms of size, thus it is best to avoid unless you really need it. This index leads to very fast searching for sub strings of a value, such as a search for Bob* in the CN field. (It happens CN and UniqueID get Substring indexes by default in all eDirectory installs). This is why searches for object by sub strings is so fast in eDirectory by default.

Presence is an index with just enough info to tell you the attribute exists with a value on the object, but does not store the value itself. I am not really clear on the realistic use cases for this.

Value is the most commonly used index, and probably the most useful. The values of the attribute indexed is stored and searchable in the index. For example, if you are storing say the users employee ID in the workforceID attribute it probably makes a lot of sense to index it as a Value index. Very likely your rules in Identity Manager or perhaps in tools that let you login, you will be looking for a specific object based on workforceID.

System indexes are obviously those created by the system. Many of them come with the eDirectory product, and every install has them. Like the Substring indexes for CN and UniqueID. However it turns out the system will add them for you automatically without your knowing it.

Recently I ran into an interesting case of this, where a custom attribute I was using to store informational messages in a multi valued attribute, suddenly showed up as a System index. I actually wanted to remove it, because it is a long text string, that has almost no value to me for searching, and because it is a series of long strings, I imagined it would be relatively expensive to maintain. Why add the overhead, when I get no value out of it, and actually do not want it in the first place.

Turns out, eDirectory is pretty smart, and if you have an attribute that has a bunch of values, then in order to add another value to it, when you try to add or modify one of those values, the system needs to test to be sure it does not already exist. The eDirectory engineers in their infinite wisdom have decided that the threshold for the benefit for adding new values, outweighing the cost of maintaining the index is 25 values in an attribute. I assume there is some real world values behind that, but it is what it is.

When you get into the hundreds of values range, the cost of adding a value to a multi valued attribute can be quite punitive, and the index really pays off.

You can find the official word from Novell at TID 10069109 which says:

NOTE: In eDirectory 8.7 and higher a new functionality has been added:

If any object in the tree has an attribute with more than 25 values, an index for the attribute will be automatically added by the system. The resulting index will be of type "system" and not of type "auto-added" as it may be expected.

Normally I am a little bit hard on the iManager snapin designers, since I usually like the way it was done in Console One or some older tool better. I have to be fair and say that the Index interface for the iManager snapins are much nicer than in Console One.

The primary issue is that an index is server specific. This is both a very powerful and limiting feature. The power is nice, since you might have an eDirectory replica acting as an LDAP server, that really cares about two special attributes, and nothing else in your tree. Oh lets say you are pointing your Unix or Linux servers at an LDAP directory for logins via pam_ldap and you really want fast performance on lookups of uidNumber, gidNumber and so on... You could tell this specific server to index the attributes to boost performance. Then on another server being used for LDAP for different purposes, you might not want those indexed, after all, why add the overhead. Thus the flexibility can be very useful.

The downside is that while you can copy an index from server to server, in Console One it was a bit of a pain, as you had to browse the tree and select each server one by one, which could be very time consuming, and make you click weary.

The iManager snapins are much nicer than Console One in this case, as when you get to the Index definition page, you see the list of Index definitions, and there is a selection on the tab bar, for Modify Index Location.

Click to view.

On the modify index location page, you get shown all available servers that can have the attribute indexed (Which should be all servers in the tree, since schema is global for entire tree), and you can see which servers have the index defined and which do not, and adjust as appropriate.

Click to view.

This makes it very easy to push out index definitions to multiple servers at once.

If this is something you do often, you might want to define it once by hand, and use LDAP to read the indexDefinitions attribute off the server object to get the index definition in an LDIF file, then use that against the multiple servers. There is a very old article (How to Supercharge LDAP Searches with NDS eDirectory Indexes) that has some good information (still relevant!) about index definitions via LDAP.

It is worth mentioning that if you KNOW you are going to have a value with more than 25 values, and it might cause a system index, it turns out, in the underlying FLAIM DB it stores it in a 'Container' which has some consequences that are beyond the scope of this article to explain.