Re: creating directory tree from scratch

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

At 04:24 PM 3/31/2006, Brandon McCombs wrote:
>I have the following LDIF:
>
>dn: dc=mydomain,dc=com
>dc: mydomain
>objectClass: dcObject
>objectClass: organization
>o: testdomain
>
>That works fine if I use ldapadd to add it as the first entry in my empty directory tree. I can then use my custom java client to add users or OUs or whatever.  The problem arises when I use that same set of data in my custom client to create that directory entry as the first entry. I get the error "no global superior knowledge".

The common reasons for this additional information being returned
is discussed in the FAQ at:
  http://www.openldap.org/faq/index.cgi?file=1322
  http://www.openldap.org/faq/index.cgi?file=157

>I'm adding the entry as a single entry with a dn attribute of dc=mydomain,dc=com.  Is the ldapadd program splitting the dc items apart

no.  It's requesting the entry named by the DN (as provided
in the LDIF) be added to the directory.

>and adding them separately in order to not produce the same error I get through my GUI?

ldapadd(1) just processes LDIF per the LDIF specification.
You should be able to produce the same error using ldapadd(1)
by representing the entry your code is attempting to add
in LDIF and handling that to ldapadd(1).

But a better approach in writing clients is to demonstrate
success of the LDAP requests you want to perform via the
command line tools and than translate that into code for
your client.  But I digress.

>If I attempt to create the two dc items separately I can add dc=com with my GUI as the first entry using the following:
>dn: dc=com
>objectClass: dcObject
>objectClass: organization
>dc: com
>o: testdomain
>
>But then if I try to add dc=mydomain with my GUI as a second entry it doesn't end up getting put at the same level but ends up as an actual OU under dc=com instead.

Seems you have some incorrect assumptions about how the API
you are using works.  Most LDAP APIs, including all OpenLDAP
LDAP APIs, expect the calling program to provide a DN (not an RDN)
for the target entry.  But, again, I digress.

Seems you need to do better your understanding of LDAP in general,
as well as with the particular LDAP client API you are using.

Kurt