[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: So close and yet so annoyed...

To: openldap-software@OpenLDAP.org
Subject: Re: So close and yet so annoyed...
From: Ken Ingram <kingram@sdl.org>
Date: Fri, 14 Dec 2001 11:17:38 -0800 (PST)
In-reply-to: <009701c18446$1b6510f0$090ba8c0@winnie>
Thanks Peter.
Thanks Boris.

I looked in schema/core.schema and was able to fix a small
error with the last entry. The person object class requires
("MUST") the cn and sn attributes to be filled.

All the entries added properly. I still don't grasp the flow
of hierarchy for LDAP but I have a start so I'll look through
it a bit more.

Thanks again guys.

On Fri, 14 Dec 2001, Peter Lavender wrote:

> Ken,
>
> You are trying to add root as an organization:
>
> dn: cn=root,dc=sdl,dc=org
> objectclass: dcobject
> objectclass: top
> objectclass: organization
> dc: sdl
>
>
>
> Directories are a heirarchy, so you need to make sure that the top part of
> the tree exists before you start moving further down.
>
> So try:
>
> dn: dc=sdl,dc=org
> objectclass: top
> objectclass: organization
> o: sdl
>
> dn: ou=Admin,dc=sdl,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Admin
>
> dn: cn=root,ou=Admin,dc=sdl,dc=org
> objectclass: person
> cn: root
> userPassword: <your password>
>
> So what I have done here is create the organization level, then created an
> Admin OU (becuase I like to keep this away from the rest of the DIT and you
> can prevent access to accounts here easier.  I then created the root person.
>
> Your slapd.conf would have to be modified to suit the the different lay out
> too.
>
> This LDIF can then be used with ldapadd to create the start of your DIT.
>
> Pete
>
>
> ----- Original Message -----
> From: "Ken Ingram" <kingram@sdl.org>
> To: <openldap-software@OpenLDAP.org>
> Sent: Thursday, December 13, 2001 5:04 PM
> Subject: So close and yet so annoyed...
>
>
> > Thanks Boris for your comments. They have been helpful in understanding
> > LDAP a little better. Unfortunately I seem to be making some really stupid
> > mistakes.
> >
> > The really annoying part is all these damn error messages with no useful
> > translation source so I can track down the problem.
> >
> > Here's the latest wall I've run into:
> >
> > >>>>>>>>>>>>>>>>>>>
> > [1748] ldapadd -v -x -D "cn=root,dc=sdl,dc=org" -f ldifs/root.ldif -w
> > secret
> > ldap_initialize( <DEFAULT> )
> > add objectclass:
> >         dcobject
> > add dc:
> >         sdl
> > adding new entry "dc=sdl,dc=org"
> > ldap_add: Invalid syntax
> >         additional info: value contains invalid data
> >
> > ldif_record() = 21
> > ==========================================
> > The slapd.conf says:
> >
> > # See slapd.conf(5) for details on configuration options.
> > # This file should NOT be world readable.
> > #
> >
> > include         /usr/local/etc/openldap/schema/core.schema
> > pidfile         /var/run/slapd.pid
> > argsfile        /var/run/slapd.args
> >
> > #######################################################################
> > # ldbm database definitions
> > #######################################################################
> >
> > #access to attr=userPassword
> > #        by self write
> > #        by * compare
> >
> >
> > database        ldbm
> > suffix          "dc=sdl,dc=org"
> > rootdn          "cn=root,dc=sdl,dc=org"
> > rootpw          secret
> > directory       /usr/local/var/openldap-ldbm
> > index           objectClass     eq
> > =============================================
> > And the file containing the entry looks like this:
> > [1750] cat ldifs/root.ldif
> > dn: cn=root,dc=sdl,dc=org
> > objectclass: dcobject
> > objectclass: top
> > objectclass: organization
> > dc: sdl
> > =============================================
> > The log entry for this (slapd -d 2207)
> >
> > dn2entry_r: dn: "DC=SDL,DC=ORG"
> > => dn2id( "DC=SDL,DC=ORG" )
> > => ldbm_cache_open( "/usr/local/var/openldap-ldbm/dn2id.dbb", 7, 600 )
> > <= ldbm_cache_open (cache 0)
> > <= dn2id NOID
> > send_ldap_result: conn=13 op=1 p=3
> > send_ldap_result: 21::value contains invalid data
> > send_ldap_response: msgid=2 tag=105 err=21
> > ber_flush: 41 bytes to sd 9
> >   0000:  30 27 02 01 02 69 22 0a  01 15 04 00 04 1b 76 61
> > 0'...i".......va
> >   0010:  6c 75 65 20 63 6f 6e 74  61 69 6e 73 20 69 6e 76   lue contains
> > inv
> >   0020:  61 6c 69 64 20 64 61 74  61                        alid data
> > ldap_write: want=41, written=41
> >   0000:  30 27 02 01 02 69 22 0a  01 15 04 00 04 1b 76 61
> > 0'...i".......va
> >   0010:  6c 75 65 20 63 6f 6e 74  61 69 6e 73 20 69 6e 76   lue contains
> > inv
> >   0020:  61 6c 69 64 20 64 61 74  61                        alid data
> > daemon: select: listen=6 active_threads=1 tvp=NULL
> > daemon: activity on 1 descriptors
> > daemon: activity on: 9r
> > daemon: read activity on 9
> > connection_get(9)
> > connection_get(9): got connid=13
> > connection_read(9): checking for input on id=13
> > ber_get_next
> > ldap_read: want=1, got=1
> >   0000:  30                                                 0
> > ldap_read: want=1, got=1
> >   0000:  05                                                 .
> > ldap_read: want=5, got=5
> >   0000:  02 01 03 42 00                                     ...B.
> > ber_get_next: tag 0x30 len 5 contents:
> > ber_dump: buf=0x080e5710 ptr=0x080e5710 end=0x080e5715 len=5
> >   0000:  02 01 03 42 00                                     ...B.
> > ber_get_next
> > ldap_read: want=1 error=Resource temporarily unavailable
> > ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable)
> > daemon: select: listen=6 active_threads=1 tvp=NULL
> > do_unbind
> > connection_closing: readying conn=13 sd=9 for close
> > daemon: activity on 1 descriptors
> > daemon: select: listen=6 active_threads=1 tvp=NULL
> > daemon: activity on 1 descriptors
> > daemon: select: listen=6 active_threads=1 tvp=NULL
> > connection_resched: attempting closing conn=13 sd=9
> > connection_close: conn=13 sd=9
> > daemon: removing 9
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > In the meantime I continue to try and make sense of the explanations
> > that exist.
> >
> > Thank You folks.
> >
> >
> >
> > On Wed, 12 Dec 2001, Boris Shpungin wrote:
> >
> > > Ken,
> > >
> > > In case nobody has resolved the problem for you yet, here's some
> > > instructions/explanations given the info you provided:
> > >
> > > [1643] ldapadd -x -D "cn=root,o=Solution Design
> Laboratory,dc=sdl,dc=org" -f
> > > ldifs/root.ldif -w secret
> > > adding new entry "dc=sdl,dc=org"
> > > ldap_add: No such object
> > >
> > > <snip>
> > >
> > > suffix "o=Solution Design Laboratory,dc=sdl,dc=org"
> > > rootdn "cn=root,o=Solution Design Laboratory,dc=sdl,dc=org"
> > > rootpw secret
> > >
> > > <snip>
> > >
> >
> > --------------------------------------------------------------------------
> > > root.ldif
> > >
> > >
> > > dn: dc=sdl,dc=org
> > > objectclass: dcobject
> > > dc: sdl
> > >
> > > dn: o=Solution Design Laboratory,dc=sdl,dc=org
> > > objectclass: top
> > > objectclass: organization
> > > o: "Solution Design Laboratory"
> > >
> > > dn: cn=root,o=Solution Design Laboratory,dc=sdl,dc=org
> > > objectclass: organizationalRole
> > > cn: root
> >
> > --------------------------------------------------------------------------
> > >
> > > The "suffix" you provide in your slapd.conf is a sort of a root node
> from
> > > which your ldap tree grows.  Once you specified the suffix, even if it
> > > appears to consist of several components, it is treated as a monolithic
> > > reference point.  IOW, since your suffix is "o=Solution Design
> > > Laboratory,dc=sdl,dc=org", you cannot add entries that are
> hierarchically
> > > above your suffix string (e.g. "dc=sdl,dc=org").  Since you apparently
> want
> > > "dc=sdl,dc=org" to be your topmost entry, you should make your suffix
> > > accordingly to be "dc=sdl,dc=org".
> > >
> > > By the way, note that now your authentication actually succeeded (since
> you
> > > got to the point of actually trying to add an entry), which means you
> are
> > > now using the correct DN and password -- no more "invalid credentials"
> :)
> > > The "no such object" error results because when you try to add the entry
> > > under DN "dc=sdl,dc=org" there is no spot in the database to attach the
> new
> > > entry under (remember that the suffix you defined is the starting point,
> and
> > > this DN does not fit under your specified suffix.)  Basically, think of
> the
> > > DN as a chain of pointers forming a linked list.  The linked list must
> have
> > > a well-defined starting node (i.e. the suffix).  From the suffix, you
> should
> > > be able to traverse the linked list to your desired node that you want
> to
> > > retrieve or attach a new node under, by going from node to an existing
> node
> > > (by incrementally prepending name components on the left of the DN)
> until
> > > you get there.
> > >
> > > Hope this helps.
> > > -Boris
> > >
> >
> > My opinons aren't fit for public consumption
> >
> >
> >
>

My opinons aren't fit for public consumption
Prev by Date: Re: slurpd with kerberos working config
Next by Date: Migrating from 1.2 to 2.0.12?
Index(es):
- Chronological
- Thread