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

On behalf of "Perece" <ntb@mts.ru>: more bugs in back-meta (ITS#2310)



Full_Name: Pierangelo Masarati
Version: 2.1/HEAD
OS: Linux RH 7.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.56)


Resumbitted on behalf of "perece" <ntb@mts.ru> as a new ITS
instead of a continuation of ITS#2289

Greetings.

Pierangelo Masarati wrote:
>
> > ---
> > database        meta
> > suffix          "dc=mts,dc=ru"
> > lastmod         off
> > uri             "ldapi:///dc=mts,dc=ru"
> > uri             "ldap://somehost/dc=spb,dc=mts,dc=ru";
> > ---
> >
> > i.e. one's suffix is inside another's suffix.
> > It handles searches well until both targets running.
> > When slapd-meta receives TCP RST as reply to TCP SYN
> > (attempting to estabilish connection to target)
> > it core dumps.
>
> You're likely to result in an endless loop, since
> one of the targets is the meta itself (unless
> you're using two different instances of slapd
> one listening to a device and the other to the socket).
>
> Are you sure this is not the case?
 
Yes, I'm aware of endless loop in this setup.
moreover, when I use back-ldap with rewrite to refer
_different_ naming context and database in _same_ slapd,
deadlock will be in place (altough it isn't endless loop
and theprethically can be handled by single process, may
be threaded...)
but now this isn't the case.
so, I'm using multiple slapds. (even more than two)

and as I say already, it worked fine until one of targets goes down.

----
There is another problem with slapd-meta and such setup:

when searching with base in dc=mts,dc=ru and not in dc=spb,dc=mts,dc=ru
all searches return correct results;
when searching in dc=spb,dc=mts,dc=ru with scope one or scope sub
results are correct too;
but when searching in dc=spb,... with scope base "noSuchObject" is
returned
even if object exists; performing same search directly on target server
returns existing object.

this problem hurt much more than coredump with non-functioning target.


SMTP /Perece/.