[Date Prev][Date Next]
Re: matching on inherited attributes
Maykel Moya writes:
> I had created a custom attribute sldMailForwardTo describe mail
> recipients for a given alias. As sldMailForwardTo is just an email
> address I made it inherits from mail.
> The problem is that now, whenever I do a search on mail=foo, entries
> having foo on sldMailForwardTo are matched too.
That is how the LDAP standard says it should work. Also if the client
includes mail in the list of attributes to return, the server will
return sldMailForwardTo attributes too.
I suggest you (1) stop slapd, (2) dump your database with slapcat, (3)
remove the inheritance and copy the meat of 'mail's definition into
'sldMailForwardTo' instead, (4) slapadd the database back, and (5)
restart slapd. Or if you don't want slapd to be down that long, you can
rebuild the database in a separate directory - and change the database
directory on the fly too, if you are using the config backend.
It might be sufficient to run slapindex instead of slapcat-slapadd in
this case, I don't know. The simplest rule to remember is that if you
mess with the definition of attributes that already exist in your
database, you need to dump first and reload afterwards.
> Do exists a way to avoid that? If no, what are the effective benefits
> then of having inherited attributes?
That _is_ one of the benefits of inheritance. Except RFC 4519 says
"Client implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping", so you are still limiting yourself to
implementations that do support it. Anyway:
It rarely makes sense to inherit from an attribute which is itself
intended to be used in directory entries, because of the problem you've
You can define an attribute which is _only_ intended as a supertype of
other attributes. That gives you a group of attributes with the same
properties (syntaxes, matching rules) unless you override those, and you
can search for them all at once by searching for the supertype.
Examples in the standard are 'name' (supertype of 'cn', 'o', 'ou',
'title' and some more standard attributes), and 'distinguishedName'.
See RFC 4519.