Re: Problems getting LDAP to work (thanks)
Tim Howes (howes@netscape.com)
Tue, 18 Jun 1996 17:01:34 -0700
Russell Fulton wrote:
>
> From: "Tim Hahn" <tjh@VNET.IBM.COM>
>
> > This is most likely, as all have indicated before, a limitation using
> > the ndbm interfaces. The SLAPD code builds some index constructs
>
> Thanks to all those who responded to my query and Paul's followup.
> In my case the problem was, in deed, the use of ndbm. I had noted the
> warings in the manual but expected more 'obvious' signs of
> failure. That the indexing would fail silently and thus cause all
> searches to to fail simply had not occurred to me. Sigh...
>
> I have rebuilt with gdbm and all is now working fine.
>
> I now have another problem:
>
> I am trying to get Simeon mail to work with the U Michigan
> server. Here is the log of a typical request:
>
> slapd[20261]: conn=3 op=0 BIND dn="" method=128
> slapd[20261]: conn=3 op=0 RESULT err=0 tag=97 nentries=0
> slapd[20261]: conn=3 op=1 SRCH base="" scope=1 filter="(&(objectclass=COUNTRY)(friendlycountryname=*NZ*))"
> slapd[20261]: conn=3 op=1 RESULT err=9 tag=101 nentries=0
> slapd[20261]: conn=3 op=2 UNBIND
It's trying to do a search starting at the "root" entry,
which your database does not hold. Looks to me like it's
looking for new zealand. The error code slapd is returning
is LDAP_PARTIAL_RESULTS, which means that slapd did not
hold the data in question. It's referring you to the
"referral" server specified in the config file.
I don't know why the siemen mail product is doing this
search, but you might see if there's any way to get it
to start its searching directly at the subtree your slapd
holds (o=..., c=NZ). -- Tim