Re: Possible bug in meta backend??

["Pierangelo Masarati" <ando@sys-net.it>]

>     Hi list,
>     First of all, I want to say this is a code question, so perhaps I
> should send it to the bug or development mailing lists instead of
> sending it to this one. If this is the case, please, let me know, and I
> apologize for the mess.

Yes, openldap-bugs would be more appropriate; if you really
think you have a bug, file an ITS, otherwise simply discuss
the issue on the list; anywey ...

>     Im using OpenLDAP 2.1.25, and I've detected a strange behaviour in
> the meta backend: in some LDAP "search" operations it takes as
> candidates to send the operation some targets whose naming context has
> nothing to do with the base of the "search", then it sends to them the
> "search" operation, but they shouldn't have to receive it. The cause for
>  this is in the "bind" operation previous to the "search" one: this
> operation marks its candidate targets, and this targets still remain
> marked for the next operation: the "search" one.
>     I think the reason for all this is in the function
> meta_back_getconn() from the conn.c source file in the meta backend:
> This function, depending on its argument op_type marks the different
> candidate targets for each LDAP operation. In the "search" operation
> case, op_type=META_OP_ALLOW_MULTIPLE, and in this case
> meta_back_getconn() does the following "for" loop:
>
>         for ( i = 0; i < li->ntargets; i++ ) {
>             if ( i == cached
>         || meta_back_is_candidate( &li->targets[ i ]->suffix, ndn ) ) {
>
>                 /*
>                  * The target is activated; if needed, it is
>                  * also init'd
>                  */
>                 int lerr = init_one_conn( conn, op,
>                         li->targets[ i ],
>                         &lc->conns[ i ] );
>                 if ( lerr != LDAP_SUCCESS ) {
>
>                     /*
>                      * FIXME: in case one target cannot
>                      * be init'd, should the other ones
>                      * be tried?
>                      */
>                     ( void )meta_clear_one_candidate( &lc->conns[ i ], 1
> ); err = lerr;
>                     continue;
>                 }
>             }
>         }
>
>     This loop looks for every target if it is a candidate, and if it is,
>
> it is marked as candidate, but if the target is not a candidate, then
> nothing is done... but the list of targets is the same as in the
> previous LDAP operation, so the candidates marked for that one remain
> marked, even if they are not good candidates for the "search"
> operation... Then I think the "if " in the "for" loop must be followed
> by an "else" where the candidate is unmarked if it was marked before (I
> supposse the meta_clear_one candidate() function can be used for this).
>     So, I would know what do you think about this, am I right?, or I'm
> missing something somewhere?
>     Any kind of help would be appreciated. Thank you very much.
>     Kind regards,

I think this needs some investigation, so I suggest you file
an ITS.  If you can provide an example of the faulty behavior,
this could be of help in tracing down the problem and in
testing if changes do fix it.  In general, back-meta tries to
do its best to narrow operations to the minimum number of
targets; this partially explains the "strange" loop you see
there.  If a target is searched with a DN it cannot contain
(e.g. a search for "ou=People,dc=example,dc=com" in a target
whose suffix is "ou=Groups,dc=example,dc=com") that's
a harmless error; it should be fixed, but it does no bad
(except if the target replies with a referral, of course :)

If a target is NOT searched for a DN it might contain, that's
an error.

Please file an ITS with a reasonably simple example (only
what's really needed to cause the error, e.g. slapd.conf
of both meta and target, .ldif for each target, and operation
you consider faulty.  I also suggest you check whether the
same error occurs with 2.2; not all fixes are backported to
2.1, and, if already fixed, we might consider porting the
appropriate fix to 2.1 in a future release.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it