[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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