[Date Prev][Date Next]
Re: cross-DB aliases leave me dangling (ITS#65)
At 07:45 PM 2/2/99 GMT, firstname.lastname@example.org wrote:
>Full_Name: Larry Bartz
>OS: Linux 2.0.35 (Redhat 5.1)
>Submission from: (NULL) (220.127.116.11)
>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
> 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
> 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