[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3604) different behaviour with back-bdb and back-ldbm



On Linux Whitebox EL3 I cannot reproduce the problem using regular 
OpenLDAP tools, that is sizelimits are honored as expected.  I'm trying 
with > 2000 users and a sizelimit of 2000 is honored by the current 
release (2.2.24) with either bdb or ldbm.   So I strongly suspect some 
other boundary condition might be changing when you change the backend.  
The fact that despite rising the server's sizelimit beyond 1000  results 
in no more than 1000 entries being returned really sounds like a 
client-side imposed limit.  To check it out, you can add log level 4 to 
slapd; for each search, in the logs should appear a string like

SRCH "<base>" <scope> <deref>     <sizelimit> <timelimit> <attrsonly>

The <sizelimit> field should tell you if any client-side size limit was 
requested.

p.

reinhard.sojka@parlament.gv.at wrote:

>Full_Name: Reinhard Sojka
>Version: 2.2.23
>OS: Solaris 9
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (161.110.1.12)
>
>
>Hi,
>
>we are running OpenLDAP on Solaris 9 with Sun's native ldapclient. At the moment
>we run OpenLDAP 2.2.13 with back-ldbm and 1765 users in the directory. 
>
>While testing OpenLDAP 2.2.23 with back-bdb, I ran into a curios problem with
>getent passwd. If sizelimit is set to unlimited, or any value >1000, "getent
>passwd" will return only 1000 entries (plus /etc/passwd). The log file says, to
>my surprise, "nentries=1000". A smaller sizelimit, e.g. 500, is honoured and
>will return 500 entries. 
>A switch to back-ldbm as database backend will solve this issue completely and
>return all 1765 entries from the directory server.
>
># here is a typical snippet of the logs (loglevel 256, sizelimt 3000,
>back-bdb):
>
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 848112 local4.debug] conn=14668 fd=12
>ACCEPT from IP=161.110.14.32:51144 (IP=0.0.0.0:389)
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 347666 local4.debug] conn=14668 op=0 BIND
>dn="cn=proxyagent,dc=parlament,dc=gv,dc=at" method=128
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 992945 local4.debug] conn=14668 op=0 BIND
>dn="cn=proxyagent,dc=parlament,dc=gv,dc=at" mech=SIMPLE ssf=0
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 217296 local4.debug] conn=14668 op=0
>RESULT tag=97 err=0 text=
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 998954 local4.debug] conn=14668 op=1 SRCH
>base="ou=people,dc=parlament,dc=gv,dc=at" scope=2 deref=3
>filter="(objectClass=posixAccount)"
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 706578 local4.debug] conn=14668 op=1 SRCH
>attr=cn uid uidnumber gidnumber gecos description homedirectory loginshell
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 362707 local4.debug] conn=14668 op=1
>SEARCH RESULT tag=101 err=0 nentries=1000 text=
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 338319 local4.debug] conn=14668 op=2
>UNBIND
>Mar 22 17:18:02 tcl2 slapd[12646]: [ID 952275 local4.debug] conn=14668 fd=12
>closed
>
>
>
># a few other notes on this topic:
>Linux clients do not care about the database backend
>ldapsearch is always working as expected
>OpenLDAP 2.1.x doesn't share these Problems
>  
>




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497