[Date Prev][Date Next]
Re: Potential bug (schema or ldap add?)
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
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.