Re: cross-DB aliases leave me dangling (ITS#65)

[Will.Ballantyne@gems1.gov.bc.ca]

Hi Larry, please keep in mind there are at least two issues currently
with the alias code and the way you are trying to use it:  it was not
written with multiple databases in mind, and there are locking problems
I am trying to work through. I wrote the code before the locking was
implemented in the id2entry calls so there are incompatibilities.  

I have created a patch (not yet committed) that fixes some of the
locking issues but not all.  The remaining problem is that alias
dereferencing requires looking at other entries in the directory, but
all calls to id2entry are blocking calls.  This means there can always
be deadlock situations since we may need to look at the same entry more
than once, whether for alias dereferencing or other comparison
operations.  This may be due to my imperfect understanding of the
locking code, I am reviewing it and have sent Kurt a couple of
questions.  It seems to me there needs to be a non-blocking call to read
an entry.

The alias code was meant to work with a single suffix associated with a
single database, but I'll take a look at dereferencing across multiple
databases.  While the slapd code is geared to using a single db it
should be possible to scan through the backend list and pick out the db
based on the suffix and then search through the other db by switching
backends.  Comments anyone?

Neither of those issues should lead to a core dump though, please send
me the full debug log, it may be due to a missing NULL check in the
current code. Thanks.

lbartz@parnelli.indy.cr.irs.gov wrote:
> 
> Full_Name: Larry Bartz
> Version: 1.2beta
> OS: Linux 2.0.35 (Redhat 5.1)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.49.118.18)
> 
> I've configured and loaded multiple databases (Sleepycat 2.3.16) under a
> single slapd instance. As per required practice, the slapd and the DB are
> compiled without threads, and with the define for alias dereferencing.
> 
> The suffix(s) of the databases are all siblings under a common parent DN.
> The parent of all the siblings has its own DB, which is (per the UMICH Admin
> Guide) last in the list.
> 
> The databases contain alias entries in which the aliasedObjectName is
> the DN of an entry in another database.
> 
> BEHAVIOR I GOT:
> 
>     "ldif2ldbm -n [dbnumber]" loads the separate databases just fine
> 
>     slapd starts and runs just fine
> 
>     client access, using any of the defined rootdn(s) as base is fine, until...
> 
>     ALIAS DEREFERENCING:
>                          slapd, as observed via "-d 255"
> 
>                          1. checks current database (in which the alias
> resides)
>                             for the ID of the referenced DN
>                             - finds nothing - dn2id NOID
>                          2. parses back through the RDNs of the referenced DN,
>                             checking each against the current DB, looking for
>                             a branch to follow
>                             - finds no match, because the DN couldn't possibly
>                               be in this DB - dn2id NOID, until the RDNs are
>                               exhausted
>                          3. returns "DANGLING ALIAS" error AND dumps core!
> 
> BEHAVIOR I EXPECTED:
> 
>     I expected 1 & 2, above. But instead of 3, I expected that slapd would:
> 
>     parse back through the DN of the aliasedObjectName,
>     evaluate the suffix(s) of the OTHER databases it is holding,
>     choose an appropriate DB to continue the search,
>     and at least give it a try.
> 
> My expectation is entirely naive, since I have not inspected the code. But
> whether or not it's designed to work this way, shouldn't it?

-- 
Will Ballantyne     GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca