mark.macdonald.100@strath.ac.uk wrote:
I am working on an undergraduate project to fetch data from a second slapdback-ldap has been part of the OpenLDAP code base since ... version 1.2.xx and is generally pretty reliable.
server and pass it back to the client via my original slapd server. I understand
that back-ldap is the way to do this, but I am going round in circles trying to
make something happen, so I began looking for a quick-but-nasty way to avoid
using this. The system I was given came with 2.2.13, hence the old version.
I would be happy in the first instance if I could just force slapd to return aSounds like this choice of undergrad project isn't really suitable for you. You would probably be better off by starting with the code for back-null, and branching out from there.
couple of attribute/values that were hard coded into the source. Obviously this
is useless for a deployed server, but I'm a little out my depth here and it
would help my understanding.
I had hoped that I could do this in server/slapd/search.c to avoid understandingViolating the abstraction layers like this will not help you understand anything.
the back-bdb I am using. I noticed that I can still perform a search by
replacing "(op->o_bd->be_search)( op, rs );" with "bdb_do_search( op, rs, op,
NULL, 0);"
It had occured to me to get the data from the second server by inserting aIt is possible to use the client APIs from inside slapd, but most of the time there is already a slapd internal API that does the job more efficiently. Actually slapd uses quite a bit from libldap, but it actually uses libldap_r which is the re-entrant library. back-ldap is of course an extreme example of using both client and slapd APIs together. And it already provides functions for converting an LDAPMessage into a slapd Entry. It doesn't seem like there's anything to gain from your current line of attack; re-inventing the wheel is seldom very satisfying.
client into slapd (including ldap.h), but I know this is not recommended. Are
there specific reasons for not doing this? I had thus hoped that there would be
a simple way to change a client LDAPMessage type into a server Entry type.
Many thanks for assisting me.
mark.macdonald.100@strath.ac.uk wrote:
1) what do you mean by "design time"? I'm not quite getting your point.I am trying to understand the slapd search process such that I can experimentally fix the message returned by slapd at design time. At which point does the frontend search.c pass proceedings to the backends?
In particular how does the client-side LDAPMessage structure compare to the server-side SlapReply structure?
I have been trying to follow this code taken from line 398 of servers/slapd/search.c in version 2.2.13
/* actually do the search and send the result(s) */ if ( op->o_bd->be_search && limits_check( op, rs ) == 0 ) { (op->o_bd->be_search)( op, rs ); } else { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, "operation not supported within namingContext" ); }
2) the frontend search passes control to the backend when the
be->be_search hook is invoked (which actually is a macro that expands to
be->bd_info->bi_op_search). Note however that many changes occurred
since the piece of code you're looking at; currently, the control passes
to the hook in a BackendDB struct called frontendDB, which may be
overridden by an overlay layer called "global overlays" which, in turn,
ends up calling the analogous of the piece of code you're seeing above;
but that call, as well, could be intecepted by yet another layer of
overlays before processing gets to the actual backend.
3) 2.2.13 is pretty old, and things changed much with current code. Unless you have very specific needs, I suggest you develop based on 2.3
(or HEAD) code.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support