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

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



Good morning,


here is the requested log with "loglevel 4" when doing a "getent
passwd". In my understanding, the client submitted value of 0 for
sizelimit, which means unlimited. Or am I wrong here?

Maybe I was a bit unclear when I opened the case. This behaviour can
only be seen with Sun's LDAP client authenticating against OpenLDAP
2.2.x with back-bdb when submitting "getent passwd". 
Apart from the above problem everything is fine with back-bdb. The basic
things like user authentication, automount, etc. are working for
Solaris. Linux clients do not show any problems. Regular LDAP tools are
always behaving as expected, and I have never been able to reproduce
this behaviour with ldapsearch. 
Note that Solaris authenticating against OpenLDAP 2.1.x with back-bdb is
not affected.


Mar 23 08:33:31 tcl2 last message repeated 1 time
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 121414 local4.debug] ==>
bdb_bind: dn: cn=proxyagent,dc=parlament,dc=gv,dc=at
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 291653 local4.debug]
send_ldap_result: err=0 matched="" text=""
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 525477 local4.debug]
connection_get(12)
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 829381 local4.debug] SRCH
"ou=people,dc=parlament,dc=gv,dc=at" 2 3
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 998714 local4.debug]     0 30 0
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 141783 local4.debug]     filter:
(objectClass=posixAccount)
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 503656 local4.debug]     attrs:
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  cn
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  uid
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  uidnumber
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  gidnumber
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  gecos
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  description
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]
homedirectory
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 823470 local4.debug]  loginshell
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 100000 local4.debug]
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 187165 local4.debug]
bdb_idl_fetch_key: [01872a84]
Mar 23 08:33:31 tcl2 slapd[28676]: [ID 187165 local4.debug]
bdb_idl_fetch_key: @ou=people,dc=parlament,dc=gv,dc=at
Mar 23 08:33:32 tcl2 slapd[28676]: [ID 187165 local4.debug]
bdb_idl_fetch_key: [b49d1940]
Mar 23 08:33:32 tcl2 slapd[28676]: [ID 187165 local4.debug]
bdb_idl_fetch_key: [5941c014]
Mar 23 08:33:32 tcl2 slapd[28676]: [ID 174679 local4.debug]
send_paged_response: lastid=0x0000043b nentries=1000
Mar 23 08:33:32 tcl2 slapd[28676]: [ID 291653 local4.debug]
send_ldap_result: err=0 matched="" text=""
Mar 23 08:33:32 tcl2 slapd[28676]: [ID 525477 local4.debug]
connection_get(12)


kind regards,
Reinhard



On Tue, 2005-03-22 at 21:15 +0100, Pierangelo Masarati wrote: 
> 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
>