[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back_meta: adding attribute to search result

Aidas Kasparas wrote:

Pierangelo Masarati wrote:

Aidas Kasparas wrote:


Is it possible to add an attribute to the result of search operation, which would depend on server from which entry was received? If possible, how?

An example:
Suppose I have configuration like this:

database    meta
suffix    "dc=mail"

uri    "ldap://example.org/dc=org";
suffixmassage "ou=org,dc=mail" "O=org"

uri    "ldap://example.com/dc=com";
suffixmassage "ou=com,dc=mail" "O=com"

I would like to achieve that every entry provided by example.org server have extra attribute "mailhost: smtp.example.org" and every entry provided by example.com have extra attribute "mailhost: mail.example.com". Adding such attributes to primary ldap servers is not an option.

Not out of the box, and this is by design: back-ldap/back-meta are designed to provide simple naming context virtualization by default, while the rewrite/remap capability gives further mucking capabilities but on DNs only. You need to write an overlay that mucks with searchEntry intermediate results; I'm not sure you can easily get that info - that is, who returned the entry, unless the entry's content can help you.

If I would extend meta backend to optionally append operational attribute sourceURI (or any better name), then maybe it would be easier to get to reporting server information in the overlay. Or would such extension ruin design too?

The collect overlay (collective attribute) in CVS can easily be modified to provide this feature, based on the DN of the entries. From your suffixmassage rules, clearly any entry under the branch "o=org" should get one value, while entries under the branch "o=com" should get the other value.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support