Re: Re: Slapd search process

[mark.macdonald.100@strath.ac.uk]

I am working on an undergraduate project to fetch data from a second slapd
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 a
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 understanding
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 a
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:

>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" );
>        }
>  
>
1) what do you mean by "design time"?  I'm not quite getting your point.
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