[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back-meta: possible bug in the handling of the candidate targets (ITS#2935)
Hi,
I think it's not a matter of adding overhead, the thing is that if
some target is not candidate, it shouldn't be considered like that when
processing an LDAP operation, because this can drive to errors. I'll try
to describe a very easy way to reproduce error caused by this:
Imagine the following configuration of the meta backend: "o=company" is
the root of the DIT, and under it, we have 4 branches:
ou=users,o=company
ou=services,o=company
ou=administrators,o=company
ou=providers,o=company
We have 2 LDAP servers: The "users" branch is in one server, and all
the rest of the branches are in the other server, so in slapd.conf we
have the following configuration:
database meta
suffix "o=company"
uri "ldap://localhost:40389/ou=users,o=company";
uri "ldap://localhost:30389/ou=services,o=company";
uri "ldap://localhost:30389/ou=administrators,o=company";
uri "ldap://localhost:30389/ou=providers,o=company";
rootdn "cn=Manager,o=company"
rootpw secret
I think this is a valid meta backend configuration, isn't it? Now,
consider that under the "ou=administrators,o=company" branch, I have the
following branches:
cn=admin,ou=administrators,o=company
cn=internal,ou=administrators,o=company
Then if I do the following search operation:
ldapsearch -H ldap://localhost:20389 -b "ou=administrators,o=company" -s
one "(objectclass=*)"
What I obtain with this is correct:
-------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base <ou=administrators,o=company> with scope one
# filter: (objectclass=*)
# requesting: ALL
#
# admin, administrators, company
dn: ou=admin,ou=administrators,o=company
ou: admin
objectClass: top
objectClass: organizationalUnit
# internal, administrators, company
dn: ou=internal,ou=administrators,o=company
ou: internal
objectClass: top
objectClass: organizationalUnit
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
--------------------------------------------------------------------
But if the search operation uses the configured rootdn as
distinguished name for the binding:
ldapsearch -H ldap://gordo:20389 -D "cn=Manager,o=company" -w secret -x
-b "ou=administrators,o=company" -s one "(objectclass=*)"
Then what I obtain is the following:
-------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base <ou=administrators,o=company> with scope one
# filter: (objectclass=*)
# requesting: ALL
#
# admin, administrators, company
dn: ou=admin,ou=administrators,o=company
ou: admin
objectClass: top
objectClass: organizationalUnit
# admin, administrators, company
dn: ou=admin,ou=administrators,o=company
ou: admin
objectClass: top
objectClass: organizationalUnit
# admin, administrators, company
dn: ou=admin,ou=administrators,o=company
ou: admin
objectClass: top
objectClass: organizationalUnit
# internal, administrators, company
dn: ou=internal,ou=administrators,o=company
ou: internal
objectClass: top
objectClass: organizationalUnit
# internal, administrators, company
dn: ou=internal,ou=administrators,o=company
ou: internal
objectClass: top
objectClass: organizationalUnit
# internal, administrators, company
dn: ou=internal,ou=administrators,o=company
ou: internal
objectClass: top
objectClass: organizationalUnit
# search result
search: 2
result: 0 Success
# numResponses: 7
# numEntries: 6
--------------------------------------------------------------------
So, as you can see, I got repeated items in this case, which is not
correct, I think... The difference between both search operations is
that in the second one the previous bind operation has marked as
candidates all the targets, and then all of them are considered in the
search operation. As 3 of the targets are in the same server, the search
suceeds in the 3 of them (of course it fails in the other one, the one
for "ou=subscribers,o=company"), and this is the cause for the
repetition in the search result.
To avoid this problem I've added this in meta_back_getconn(), in the
part that deals with op_type=META_OP_ALLOW_MULTIPLE:
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;
}
}
/**** ADDED to avoid "false" candidates !! ****/
else {
( void )meta_clear_one_candidate( &lc->conns[ i ], 1);
}
/**** END of ADDED ****/
}
This solves the problem, ad after adding it, the search works
property, I don't know if something more should be done...
I hope this long message has clarified something more the problem,
which I still consider it's an error that should be fixed.
Kind regards,
Aníbal.
Pierangelo Masarati wrote:
>AFAIR,
>
>the only case when multiple candidates are legal is when
>doing a search. Without re-reading too much the code
>(which, I admit, is a bit obscure), targets that were
>candidates for earlier operations in the same connection
>are preserved in the hope they can return something useful,
>without strictly checking if they're still candidates.
>
>If they don't, theyre adding a minimal overhead, because
>they're returning nothing and, in the meanwhile, other
>targets are served. It is likely thaat at some point,
>while reviewing the code, this gets fixed (if it is an
>error; if there's a good reason for it, better leave it
>in place).
>
>p.
>
>
>
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.