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

Glueing to back-dnssrv in 2.2



(Note: this may not apply to 2.3, however we're not ready to use 2.3 yet
because we need to ship "stable" code.)

I'd like to glue N backends to back-dnssrv, such that the following will
work:

(a) searches within physical naming contexts
(b) sub/one searches at root DSE (search all physical naming contexts)
(c) searches outside physical naming contexts (return DNS SRV referrals)

with all physical naming contexts being listed as values of namingContexts
in the root DSE.

(By "physical naming context" I mean one which is instantiated by slapd as
a real database backend.)

Now, for N = 1, the following works (although it does print a warning):

defaultsearchbase	"dc=example1,dc=com"
...

database		bdb
suffix			"dc=example1,dc=com"
...

database		dnssrv
suffix			""

However, for N > 1, its gets trickier. One would hope that the following
would work (note no defaultsearchbase):

database		bdb
suffix			"dc=example1,dc=com"
subordinate
...

database		bdb
suffix			"dc=example2,dc=com"
subordinate
...

database		dnssrv
suffix			""

However, this fails for both cases (a) and (b).

Fixing (a) is trivial:

diff -u -r1.11.2.3 referral.c
--- back-dnssrv/referral.c      20 Jan 2005 17:01:11 -0000      1.11.2.3
+++ back-dnssrv/referral.c      28 Jan 2005 07:03:32 -0000
@@ -42,6 +42,10 @@
        BerVarray urls = NULL;

        if( op->o_req_dn.bv_len == 0 ) {
+               if( SLAP_GLUE_INSTANCE(op->o_bd) ) {
+                       return LDAP_SUCCESS;
+               }
+
                rs->sr_text = "DNS SRV operation upon null (empty) DN disallowed";
                return LDAP_UNWILLING_TO_PERFORM;
        }

Fixing (b) appears a bit trickier: any ideas? Also, glueing a backend removes
it from the list of naming contexts.

Is there any other way of doing this? Will using the glue overlay in 2.3 fix
this? Or am I simply trying to do something that glue was not designed for?

-- Luke

--