Andrew Seguin writes:
I'm not too sure of the details yet, I wanted to check with this
first, but here's the story.
In general, I'm using phpLDAPadmin to work with the ldap directory.
I added the iaaa-radius.schema from Interlink. I found it was missing the
EQUALITY statements, so phpLDAPadmin couldn't "add" new aaaReply items
once the first one was added. Via import and adding a user all at once was
not a problem.
I modified the iaaa-radius.schema file, found the aaaReply attribute and
added the lines "EQUALITY caseIgnoreMatch" and "SUBSTR
It's usually a bad idea to modify a published schema that way, since
your app will be incompatible with servers which use the correct schema.
Without an EQUALITY rule the Modify operation can't add a new value to
an existing attribute in an entry, but it can "replace" all attribute
values with a new set of attribute values (which you construct from the
old set + the new value). No idea if phpLDAPadmin supports that though
- if not I suggest sending an enhancement request.
I went into phpLDAPadmin, created a new aaaPerson with one initial
aaaReply attribute, then added a second aaaReply value without problem. To
date all is good.
I went to a user which already exists, which already has three aaaReply
attributes/values, and tried to add a new aaaReply value - at which point
it would seem that slapd either crashed or shutdown. I turned on logging
and couldn't see anything really abnormal... nor did I find any core dump
Any ideas if this is a bug or possibly just some kind of internal
consistency check on records created before the Schema was modified?
Modifying the schema definition of an attribute which exists in your
directory is definitely a bad idea. I didn't know that you can crash
slapd by merely adding an EQUALITY rule, but it doesn't surprise me
either. The safe way is to slapcat the database before the schema
change and slapadd it back afterwards.