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

[Kurt@OpenLDAP.org]

At 07:45 PM 2/2/99 GMT, 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!

Of course, the crash shouldn't occur, however:

Returning an error is expected in this case.  I would
suspect either an LDAP_ALIAS_PROBLEM (or
LDAP_ALIAS_DEREF_PROBLEM).  In OpenLDAP, each backend is
considerred to be a virtual DSA.  Aliases across backends
cannot be followed as the software is currently designed.

As far as the crash is concerned, please followup with a
relevant logs (-d 133) and a debugger backtrace from the core
file.

Kurt