Re: The general problem with multiple databases

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:00 PM 6/2/00 -0700, Terry Lambert wrote:
>Phil Dodderidge wrote:
>> 
>> I am trying to partition my data into multiple databases
>> for ease of administration and I have run into a problem
>> with group access control across databases.
>> 
>> I have something like the following in my slapd.conf
>> 
>> ...
>> database ldbm
>> suffix        "dc=domain,dc=com"
>> directory    /usr/local/ldap/db
>> ......
>> database ldbm
>> suffix         "ou=div1,o=company a,dc=domain,dc=com"
>> directory    /usr/local/ldap/db/div1
>
>This begs the question of whether or not "dc=" naming
>shouldn't have explicit use of dots so that root references
>can be made

Root references are already possible.  "dc=." refers to the
root.  However, note, "dc=." should only be used if the
domain has no components.  That is:
	.		<-> dc=.
	example.net.	<-> dc=example,dc=net

The latter is per RFC 2247.  The former, hopefully, we be
added as a clarification in a subsequent revision.  In that
clarification, it should be noted that 'dc=.' should only be
used to a form DN representing the root of the DNS tree.
That is, "dc=foo,dc=." is invalid and not necessary.

>	suffix "dc=domain.,dc=com.,dc=."

Implementations should use RFC 2247 mapping of domains to
DNs.

>I expect that this would require changing the free referral
>service somewhat, but what do people think about this?

It would require a shitload more change than that.  RFC 2247
naming is in fairly wide use.

>Right now, I can't have both:
>
>	suffix "dc=foo,dc=com"
>
>and:
>
>	suffix "dc=foo,dc=net"
>
>easily in one database without redirection through a
>referral server.

Same would be true for true with the addition of dc=..
That is, you still need glue between subordinates and
their common superior.

>Alternately, is anyone interested in working on a draft
>to define the interaction of DNS SRV records (which do not
>like to be used with a protocol without a per-protocol-RFC
>on the subject) with LDAP?

LDAPext WG already has an I-D on the subject.
  http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-02.txt

You are welcome to comment.

The "root" server is an "experimental" service based, in
part, upon this draft.  We'll soon be publishing an separate
I-D, intended for publication as an "Experimental" RFC, describing
the service.

>In particular, it seems that it would be difficult to
>require clients to forage for the base DN.

I don't think it will be a MUST... but it should be RECOMMENDED
for both clients and servers.   It's all rather straight forward
to implement.