Is it possible to somehow add a statically defined attribute to all search results. For example, if I wanted to add "authAuthority: ;Kerberosv5;;" to all entries with "(objectClass=posixAccount)". I've looked at slapo-rwm, and its rwm-map directive, but that only seems to map one attribute to another. I'm thinking there must be a way to do this, or perhaps it would be simple enough add this functionality to slapo-rwm. It seems like this is something that could be fairly useful, so perhaps this should be considered a feature request. Note: I don't control the upstream ldap server in my organization (I'm using a local proxying server with the translucent overlay). I could add this attribute to every entry in the upstream server, but that's several tens of thousands of entries that I would need to locally modify.

At 2008-04-30, Howard Chu told me: > Andy Cobaugh wrote: >> Is it possible to somehow add a statically defined attribute to all search >> results. For example, if I wanted to add "authAuthority: ;Kerberosv5;;" to >> all entries with "(objectClass=posixAccount)". I've looked at slapo-rwm, >> and its rwm-map directive, but that only seems to map one attribute to >> another. I'm thinking there must be a way to do this, or perhaps it would >> be simple enough add this functionality to slapo-rwm. >> >> It seems like this is something that could be fairly useful, so perhaps >> this should be considered a feature request. >> >> Note: I don't control the upstream ldap server in my organization (I'm >> using a local proxying server with the translucent overlay). I could add >> this attribute to every entry in the upstream server, but that's several >> tens of thousands of entries that I would need to locally modify. > If all of your posixAccount entries reside in a single subtree, you could use > the collect overlay for this purpose. That's almost exactly what I need, though I've had to make some modifications. First, obviously slapo-collect doesn't have a build target, perhaps there should be? I had to add some pre-processor directives to portable.h, and add collect.c to a couple of places in Makefile.in to get it to compile with make.

Second, because my users live right under the root of the DIT (not my choice, this decision was made long ago), and because I'm using slapo-translucent on that part of the tree, I couldn't modify the parent to contain the attribute I need. A quick comment of the dnIsSuffix() bits in collect.c allowed me to specify an entry anywhere in the tree. Thanks for pointing me in the right direction. -- Andy

Howard Chu<hyc(a)symas.com> wrote: > Those items are intentionally omitted; collect.c is a piece of demo code and > is not intended for real use. In fact, it's intended for exactly what you've > done - modifying it to fit a real use, and teaching how overlays are written. I tend to be unconfortable with running with such custom code, because it can be troublesome to maintain through OpenLDAP updates, if the API used by the overlay changes. Is there a set of stable API that an overlay can use without the fear to break on the next update?