Re: Looks like a bug 8'(

[jmong@adobe.com]

Hi I can try to answer the stuff about the version (haven't read much 
of the thread... but here goes).

Try starting your ldap server with debug flag 1

/path/to/libexec/slapd -d 1 -h "ldap://127.0.0.1:389/"; [etc]

For a solaris build that I have, it comes up as (/etc/init.d/slapd is 
a wrapper script I wrote)

root@myserver[4] /etc/init.d/slapd debug
starting slapd in debug mode: 1
@(#) $OpenLDAP: slapd 2.0.27-Release (Mon Jan  6 13:05:15 PST 2003) $
        root@pinnacle:/work/openldap-2.0.27/servers/slapd
daemon_init: listen on ldap://myserver:389/
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://myserver:389/)
daemon: initialized ldap://myserver:389/
daemon_init: 1 listeners opened
slapd init: initiated server.
TLS: PRNG not been seeded with enough data
slapd startup: initiated.
slapd starting

Check your DB as well (I've compiled mine against bdb.3.3.11)

HTH

Jan-Michael


----- Original Message -----
From: "Emmanuel Blot" <emmanuel.blot@free.fr>
Date: Sunday, February 2, 2003 3:48 pm
Subject: Re: Looks like a bug 8'(

> > Don't let the folks on the list guess:
> > what exaclty were the circumstances ?
> > - exact OpenLDAP version
> 
> I wish I know how to get the version - I would have reported it if 
> I knew how to obtain it for
> sure.
> I know it's OpenLDAP 2.1.x, but I'm not sure of the build. Perhaps 
> 2.1.4I'm surprised slapd daemon does not have a -v or --version 
> command line swtich: it will help.
> 
> > - Hardware (CPU)
> 
> AMD Athlon 1.1GHz on an AsusTech A7M266 motherboard as far as I 
> remember (this is from a remote
> server)
> 
> > - OS
> 
> Linux 2.4.18 SuSE 8.0 - but I've recompiled OpenLDAP from the 
> source (SuSE 8.0 comes with
> OpenLDAP 2.0.x and I need <= & >= comparison operators in filters)
> I may have the configure log files somewhere. Would that help ?
> 
> > - your input
> 
> Something really basic with ldapsearch:
> 
> ldapsearch -D "uid=<login>,<baseDN>" -b "<baseDN>" -x -W 'cn=<aCN>'
> 
> I guess the problem comes from a specific ACL rule with cn and uid 
> attributes involved
> 
> Something like:
> 
> loglevel 992
> access to attr=uid,cn
>       by group="cn=administrators,<baseDN>" write
>       by users read
>       by * read
> 
> The last-but-one line is useless, but I was trying different 
> syntax at that time: I discovered
> the problem by looking at the syslog output file some seconds later.
> 
> > Is the error reproduceable ?
> 
> Probably, but I did not keep the ACL that led to this issue. I 
> should have, but I'm trying to
> get the ACL to work for over than 1 month, so I focus on this main 
> point since this is getting
> really annoying: I wish I could focus on other issues than ACLs 
> 8') ...
> If I can reproduce this issue, I will keep the ACL.
> 
> Regards,
> Emmanuel.
> 
>