Aidas Kasparas wrote:
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.
Pierangelo Masarati wrote:
Aidas Kasparas wrote:
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.Hi,
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.
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?
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support