Re: forwarding search queries + auth across multiple backends

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

> On Thu, 2004-03-04 at 12:00, Pierangelo Masarati wrote:
>
> hi,
>
>> You can glue the local and the sql backend
>> together; this solves the auth propagation
>> problem; otherwise, if the sql database is
>> remote, you can glue the local database and
>> a back-ldap together, with the back-ldap
>> pointing to the server where the back-sql
>> is active.  Back-ldap supports proxyAuth
>> propagation (there has been some traffic
>> on the subject, I'll need to write a FAQ
>> entry for that).
>
> ok - tnx. auth propagation seems to work :)  (at least when testing with
> ldapsearch, there are still some issues with pam-ldap together with
> back-ldap which i have to look into (it works with back-ldbm though).)
>
> i still got another strange problem which i already mentioned in my
> other mail to the list (where i thought the reason for the problem was,
> that my data doesn't conform to a schema).
>
> the problem occurs when i use a ldbm and a subordinate sql backend. when
> i do a ldapsearch and cancel it, the next time i run the ldapsearch no
> objects are returned (and i get a result 32 - no such object).

how do you cancel the search?

>
> when i wait until the size limit is exceeded or ldapsearch has finished
> & then restart ldapsearch it works fine. it works fine too when starting
> 2 parallel ldapsearch'es.
>
> when i remove the sql database from my slapd.conf there's no problem if
> i cancel the ldapsearch process & start another one.
>
> this problem is reproduceable on my machine with openldap 2.2.6.
>
> when using the ldap backend instead of ldbm i get a similiar behaviour.
> (when i don't cancel the ldapsearch (all?) subsequent queries fail too).
>
> could this be a configuration problem? a bug in openldap? i'll generate
> some testdata which conforms to a schema and check if the problem is
> still there.

It could be a problem in back-sql, I need to check
how it behaves when when searches are abandoned or
when a connection is lost.  Can you detail what you
exactly do to cause the problem with back-sql
in the glue sequence?  Does the problem persist
if you use back-sql by itself, without glueing it
to another database?

p.

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