Andrew Seguin writes:
I'm not too sure of the details yet, I wanted to check with this list 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 caseIgnoreSubstringsMatch".
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 file.
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.