Extending the OID 11g schema via ldapmodify

I recently said the following to someone in an IMversation:

ldapsearch and ldapmodify are about 10 times better than a stupid GUI because you can script everything.
it's like the difference between knowing SQL and having to use TOAD or Access (*shudder*) to add rows to a db table

I think if I had a personal motto it would be something like "if I can't script it then I'm not interested." (well that or "oh look, shiny!")

I recently had to extend my LDAP schema of an OID 11g directory and I didn't have access to the ODSM GUI (for reasons that aren't important). So I had to extend the schema via ldapsearch/ldapmodify (i.e. the hard way) and thought I'd write down my steps to save you the trouble of figuring it out for yourself.

Hat tip to OnlineAppsDBA for his work. I stood on his shoulders for this post.

First things first you need to figure out names for your attributes and objectclass. In my case I wanted the name customAttr1 and customAttr2 for the attributes and customClass1 for the objectclass.

To modify the schema you use ldapmodify and update the cn=schemasubentry object at the root of the directory and add the relevant attributes. Here's me adding the two attributes and the objectclass as three separate transactions.

$ ldapmodify -p $DIRLISTENPORT -D $DIRADMINDN -w $DIRADMINPASSWORD -a -c

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 99.99.99.99.01 NAME 'customAttr1' DESC 'Custom Attribute 1' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

modifying entry cn=subschemasubentry

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 99.99.99.99.02 NAME 'customAttr2' DESC 'Custom Attribute 2' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

modifying entry cn=subschemasubentry                                 

dn: cn=subschemasubentry
changetype: modify
add: objectClasses
objectClasses: ( 99.99.99.99.03 NAME 'customClass1' DESC 'custom objectclass 1' SUP top STRUCTURAL MUST cn MAY ( customAttr1 $ customAttr2 ) )

modifying entry cn=subschemasubentry

The important things to note are that each attribute and objectclass has a unique Object IDentifier (OID) (that's the 99.99.99.99.__ number) and that I used "1.3.6.1.4.1.1466.115.121.1.15" which tells OID that the attribute is a directory string. In Atul's post he had a different number there because OID 10g used a different number. The other possible data types are available in the "ldapsyntaxes" attribute of "cn=schemasubentry".