OpenDJ – online schema modification
I wrote before about schema conversion to LDIF format and how to add schemas offline by uploading them to config/schema directory in OpenDJ. Now I will describe how to extend schema online, without restart LDAP server. Most if not all LDAP servers now have possibility to modify configuration and schemas due LDIF files and ldapmodify tool. Let’s prepare our LDIF file, attributes first:
# cat us-newattrs.ldif
dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.XXXX.1.1.11 NAME 'usTypeOfStudies' DESC 'Type of studies' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.XXXX.1.1.12 NAME 'usSystemOfStudies' DESC 'System of studies' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Explanation about those numbers you can find in LDAP documentation and RFC. In place of XXXX is OID, that means unique number, which should be registered for your institution.
Now is part which modifies existing in schema object class (first delete then add):
# cat us-modclass.ldifdn: cn=schema changetype: modify delete: objectClasses objectClasses: ( 1.3.6.1.4.1.XXXX.1.2.2 NAME 'useduplStudAccount' DESC 'us.edu.pl account extension for students' SUP useduplAccount AUXILIARY MAY ( usUsosId $ usUsosLogin $ usUsosPass $ usIndexNum $ usAccountActive ) ) - add: objectClasses objectClasses: ( 1.3.6.1.4.1.XXXX.1.2.2 NAME 'useduplStudAccount' DESC 'us.edu.pl account extension for students' SUP useduplAccount AUXILIARY MAY ( usUsosId $ usUsosLogin $ usUsosPass $ usIndexNum $ usAccountActive $ usTypeOfStudies $ usSystemOfStudies ) )
Files are prepared, but I suggest to backup LDAP directory before change.
# cd /data/var/OpenDJ
# mkdir ../backup
# ./bin/backup --backUpAll --compress --backupDirectory ../backup
[19/Jun/2012:10:11:18 +0200] category=TOOLS severity=NOTICE msgID=10944792 msg=Starting backup for backend config
[19/Jun/2012:10:11:19 +0200] category=TOOLS severity=NOTICE msgID=10944792 msg=Starting backup for backend userRoot
[19/Jun/2012:10:11:21 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000000.jdb
[19/Jun/2012:10:11:24 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000001.jdb
[19/Jun/2012:10:11:27 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000002.jdb
[19/Jun/2012:10:11:30 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000003.jdb
...
[19/Jun/2012:10:13:01 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 000004cb.jdb
[19/Jun/2012:10:13:01 +0200] category=TOOLS severity=NOTICE msgID=10944792 msg=Starting backup for backend replicationChanges
[19/Jun/2012:10:13:03 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000005.jdb
[19/Jun/2012:10:13:04 +0200] category=JEB severity=NOTICE msgID=8847446 msg=Archived: 00000006.jdb
[19/Jun/2012:10:13:04 +0200] category=TOOLS severity=NOTICE msgID=10944792 msg=Starting backup for backend schema
[19/Jun/2012:10:13:04 +0200] category=TOOLS severity=NOTICE msgID=10944792 msg=Starting backup for backend tasks
[19/Jun/2012:10:13:04 +0200] category=TOOLS severity=NOTICE msgID=10944795 msg=The backup process completed successfully
Let’s add new attributes:
# ./bin/ldapmodify -D cn=dirmgr -h localhost -X -f ../us-newattrs.ldif
Password for user 'cn=dirmgr':
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema
Now we are checking dry run of objectClass modification (option -n means “dry run”):
# ./bin/ldapmodify -D cn=dirmgr -h localhost -X -n -f ../us-newclass.ldif
Password for user 'cn=dirmgr':
Processing MODIFY request for cn=schema
No errors occured, so we can modify objectClass (without -n)
# ./bin/ldapmodify -D cn=dirmgr -h localhost -X -f ../us-newclass.ldif
Password for user 'cn=dirmgr':
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema
If replicas are properly configured then schema changes will automatically imitated on them. You can check this by reviev config/schema dir on other server:
# less 99-user.ldif
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
attributeTypes: ( 1.3.6.1.4.1.XXXX.1.1.12 NAME 'usSystemOfStudies' DESC 'System of studies' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributeTypes: ( 1.3.6.1.4.1.XXXX.1.1.11 NAME 'usTypeOfStudies' DESC 'Type of studies' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
ds-sync-generation-id: 8408
modifiersName: cn=Directory Manager,cn=Root DNs,cn=config
ds-sync-state: 00000132f753ae9a5d4900000001
ds-sync-state: 000001316b1b6be44a1a00000001
ds-sync-state: 0000013803e4be617c7400000004
modifyTimestamp: 20120619083838Z
Notice: I wrote that you can modify schema without restart, but you can hit a bug during adding new attribute for existing entry which have modified objectClass. This is caused by server’s cache, where compressed schema is stored, and leading to error 65:
Result Code: 65 (Object Class Violation) Additional Information: Entry xxx cannot not be modified because the resulting entry would have violated the server schema: Entry xxx violates the Directory Server schema configuration because it includes attribute testattr which is not allowed by any of the objectclasses defined in that entry
Bug is already reported and should be fixed in 2.5. Workaround in 2.4.x versions is to restart LDAP server. More about this you can read on this page:
