[Date Prev][Date Next]
Re: slapd-relay and slapo-rwm questions
--On Thursday, October 12, 2006 6:33 AM +0200 Pierangelo Masarati
That __should__ do it.
My understand is that is the point of this bit of configuration?
relay cn=people,dc=stanford,dc=edu massage
but that doesn't do it.
Well, I think I've tracked this down to this line:
If I take that line out, the rewriting occurs -- But I get no data from the
entries, just the DN's.
If I keep the line, then the DN's are rewritten, but I get to see the entry
data. I'm guessing that's an ITS if there isn't one on it already...
We got to a point where schema is essential for all internal operations
-- and I wouldn't back off --; for this purposes, we rather developed
tools to munch and digest the worst schema sources ever. I rather prefer
having control on what is getting in, and especially on what's pushed
out. Note that in order to push out search results you don't need to
know matching rules for attributes; but you will to accept filters. So a
best practice consists in knowing the schema for all items, and generate
dummy schema for unknown items with something like "octetStringMatch" as
equality rule, so that it smoothly passes frontend filter validation.
Any overlay would be useless at this point, since overlays cannot take
control __before__ filter validation, or when determining if an attribute
was requested. I can share some of those tools if you want to try them
(too busy to release them "officially", sorry).
Hm, I guess in my case, the issue is, I don't care about the filters,
because the filters are using normal attributes. What I care about is what
is on the return, and I honestly care less whether or not they even exist
in a schema. But, I could always load in some schemas if necessary, it
shouldn't hurt anything.
Overall though, it seems the functionality just isn't stable enough at this
point to deploy onto my production servers. :/
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html