[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Slapd search process

mark.macdonald.100@strath.ac.uk wrote:

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.

back-ldap has been part of the OpenLDAP code base since ... version 1.2.xx and is generally pretty reliable.

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.

Sounds 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.

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);"

Violating the abstraction layers like this will not help you understand anything.

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.

It 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.

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.


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