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

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



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?