- openldap-bugs - openldap.org

Re: (ITS#6176) cachesize vs dncachesize
by hyc＠symas.com 18 Jun '09

18 Jun '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.16 > OS: > URL: http://www.openldap.org/lists/openldap-software/200906/msg00021.html > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > The referred openldap-software message says: >> From: Howard Chu<hyc(a)symas.com> >> >> dncachesize must always be>= cachesize > > This is not documented, neither in manpage nor admin guide. > > Also slapd should preferably catch attempts to set them wrong, and > either adjust them or fail the change. That's so for many config > options, but more important for interactions between options. The details here are unimportant. Since entry cache items hang off of dncache items, the only consequence of a "wrong" configuration here is that the entry cache could only ever grow to the size of the dncache. At any rate, the code has been patched to set dncachesize >= cachesize, and the manpage updated correspondingly, but there's no critical problem without this patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6177) bdb delete locking issue
by richton＠nbcs.rutgers.edu 18 Jun '09

18 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/test039-bt-200906170640.txt Submission from: (NULL) (67.85.182.223) 2.4.17 prerelease testing revealed SEGVs in test039's slapd.1. libumem revealed a deadbeef (previously freed) ei. umem transaction logs, slapd logs, and logical deduction are currently leaning toward an issue with deletions. umem transaction log of ei: https://www.nbcs.rutgers.edu/~richton/test039-umem-200906170640.txt -d -1 (26MB): https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906170640.txt

1 0

(ITS#6176) cachesize vs dncachesize
by h.b.furuseth＠usit.uio.no 17 Jun '09

17 Jun '09

Full_Name: Hallvard B Furuseth Version: 2.4.16 OS: URL: http://www.openldap.org/lists/openldap-software/200906/msg00021.html Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The referred openldap-software message says: > From: Howard Chu <hyc(a)symas.com> > > dncachesize must always be >= cachesize This is not documented, neither in manpage nor admin guide. Also slapd should preferably catch attempts to set them wrong, and either adjust them or fail the change. That's so for many config options, but more important for interactions between options. If that's fixed by adjusting the input values, then cachesize configuration can be simplified for users: Given cachesize, calculate the recommended defaults for the other cache size variables (idlcachesize, dncachesize, cachefree). Keep the real variables used by the backend separate, copied/defaulted from input variables that are set by cn=config and not defaulted.

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by hyc＠symas.com 17 Jun '09

17 Jun '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> I cannot reproduce it all the time. >> >> Can you add SYNC to your debug level and get the logs from one of these incidents? > > What would be the best place to set the debug level when running > test054? And only set it to "loglevel sync" or also other flags? set the SLAPD_DEBUG environment variable, the default value is 5. Add sync to the default... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6175) Slapd crashes when using accesslog
by michael＠stroeder.com 17 Jun '09

17 Jun '09

openldap-bugs(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.11 > OS: Debian Lenny running under Xen > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.3) > > Slapd dies whenever the accesslog is enabled with the following BT. Please let > me know what additional information you might need. I am also in #openldap as > bpgoldsb. Does this also happen when running recent OpenLDAP release 2.4.16 built from source? Ciao, Michael.

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 17 Jun '09

17 Jun '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> I cannot reproduce it all the time. > > Can you add SYNC to your debug level and get the logs from one of these incidents? What would be the best place to set the debug level when running test054? And only set it to "loglevel sync" or also other flags? Ciao, Michael.

1 0

(ITS#6175) Slapd crashes when using accesslog
by openldap-bugs＠gleim.com 17 Jun '09

17 Jun '09

Full_Name: Ben Goldsbury Version: 2.4.11 OS: Debian Lenny running under Xen URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.3) Slapd dies whenever the accesslog is enabled with the following BT. Please let me know what additional information you might need. I am also in #openldap as bpgoldsb. #0 0x00002b4ae5a45552 in ber_dupbv_x () from /usr/lib/liblber-2.4.so.2 #1 0x0000000000439a2e in attr_valadd (a=0x8ac4f0, vals=0x48, nvals=0x0, nn=1) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/attr.c:423 #2 0x00002b4aea39bf8d in accesslog_entry (op=0x407ffde0, rs=0x407fff50, logop=<value optimized out>, op2=0x4067f1d0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1200 #3 0x00002b4aea39c40f in accesslog_response (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1363 #4 0x00000000004907a8 in over_back_response (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:235 #5 0x00000000004402ef in slap_response_play (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:307 #6 0x0000000000442e0d in send_ldap_response (op=0x87b7e0, rs=0x48) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:381 #7 0x00000000004439ab in slap_send_ldap_result (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:642 #8 0x00002b4ae9f5e3b3 in bdb_search (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/back-bdb/search.c:928 #9 0x0000000000490a07 in overlay_op_walk (op=0x407ffde0, rs=0x407fff50, which=op_search, oi=0x7f3100, on=0x0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:646 #10 0x0000000000491473 in over_op_func (op=0x407ffde0, rs=0x2b4ae763ca50, which=op_bind) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:698 #11 0x00002b4aea1903f9 in syncprov_findcsn (op=<value optimized out>, mode=<value optimized out>) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/syncprov.c:704 #12 0x00002b4aea191a7e in syncprov_db_otask (ptr=0x87b7e0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/syncprov.c:2672 #13 0x00002b4ae70d8fc7 in start_thread () from /lib/libpthread.so.0 #14 0x00002b4ae73bd5ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Relevant part of slapd.conf: moduleload accesslog overlay accesslog logdb cn=log logops all # Scan the accesslog DB every day # Purge entries older than 7 days logpurge 07+00:00 01+00:00 database bdb suffix cn=log directory /var/lib/ldap/accesslog/ # Allow manager to read the Monitor information access to dn.subtree="cn=log" by dn.exact="cn=Manager,dc=example,dc=com" read by * none

1 0

Re: (ITS#6173) Error while making
by battery＠writeme.com 17 Jun '09

17 Jun '09

--001e680f175823722e046c8c2226 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You are using a deprecated version of OpenLDAP. Consider upgrading to a recent version... preferrably 2.4. On Wed, Jun 17, 2009 at 4:42 AM, <bipin.nair(a)iflexsolutions.com> wrote: > Full_Name: Bipin > Version: OpenLDAP2.2.29 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.127.116.93) > > > Hi, > > While trying to install OpenLDAP 2.2.29 ,I getting the following error > during > the 'make' step. > > > --------------------------------------------------------------------- > Notes:- > > 1)I have installed OpenSSL 0.9.7 and Berkley DB 4.5.20 > > 2)Also,the follwing variables are set > CPPFLAGS > LDFLAGS > LIBPATH > > 3)THe follwoing commands were used as steps to install Openldap > cd openldap-2.2.29 > ./configure --enable-ldbm > make depend > make (During this step it fails) > > ------------------------------------------------------------------- > > > acl.c:85: error: conflicting types for 'acl_get' > /usr/include/sys/access.h:86: error: previous declaration of 'acl_get' was > here > make: 1254-004 The error code from the last command is 1. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > > > Please help with this issue. > > Thanks. > > --001e680f175823722e046c8c2226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are using a deprecated version of OpenLDAP. =A0Consider upgrading to a = recent version... preferrably 2.4. <div class=3D"gmail_quote">On Wed= , Jun 17, 2009 at 4:42 AM, <<a href=3D"mailto:bipin.n= air(a)iflexsolutions.com">bipin.nair(a)iflexsolutions.com</a>> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Full_Name: Bipin Version: OpenLDAP2.2.29 OS: AIX 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (203.127.116.93) Hi, While trying to install OpenLDAP 2.2.29 ,I getting the following error duri= ng the 'make' step. --------------------------------------------------------------------- Notes:- 1)I have installed OpenSSL 0.9.7 and Berkley DB 4.5.20 2)Also,the follwing variables are set CPPFLAGS LDFLAGS LIBPATH 3)THe follwoing commands were used as steps to install Openldap cd openldap-2.2.29 ./configure --enable-ldbm make depend make (During this step it fails) ------------------------------------------------------------------- acl.c:85: error: conflicting types for 'acl_get' /usr/include/sys/access.h:86: error: previous declaration of 'acl_get&#= 39; was here make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. Please help with this issue. Thanks. </blockquote></div> --001e680f175823722e046c8c2226--

1 0

(ITS#6174) Permanent high CPU Load with Multimaster
by Frank.Offermanns＠caseris.de 17 Jun '09

17 Jun '09

Full_Name: Frank Offermanns Version: 2.4.16 OS: Windows XP/Ubuntu 9.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) Hello everyone, I compiled the LDAP Version 2.4.16 from CVS at 16 June with MINGW/MSYS on Windows. I used the latest version because every previous 2.4.16 version had similar problems. I have two systems working together as multimasters. After a random time (less than a day) it can happen, that a core of a CPU uses 100 % CPU Load. Both System seems to be working correctly, but the High CPU Load slows down everything. No matter how long i wait, this core stays at 100 % CPU load. On another test a test write operation never returned and I also had the high CPU load. After i killed my test write process, the slapd.exe crashed. (The write procees was on a another PC) I also tested the original/downloadable 2.4.16 with a Windows Cygwin build and a Ubuntu build. But i had similar problems with each build. I have not tested the latest Version with Ubuntu or Cygwin. I tried to compile it with Ubuntu 9.04 to check if this problem is still OS independent but got this error when calling configure (CPPFLAGS=-D_GNU_SOURCE ./configure --enable-hdb=mod --enable-bdb=mod --enable-modules=yes --enable-syncprov=mod): "bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory" Here is my slapd.conf which i converted with "slapdtest -f slapd.conf -F slapd" I am not interested in configuration replication. I know, that for security reasons i should not take the superuser for the replication, but i did this to simplify my tests. Personcaesar and ConfigObjects are selfdefined shemas. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth access to * by dn.one="ou=Admins,o=caesar" write by * read ServerID 1 "ldap://CAS-WS090309.ub2.cae.local" ServerID 2 "ldap://franktestxp.ub2.cae.local" # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### database config rootdn cn=config rootpw config ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory "c:/all/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 10000 syncrepl rid=001 provider="ldap://CAS-WS090309.ub2.cae.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" syncrepl rid=002 provider="ldap://franktestxp.ub2.cae.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" MirrorMode On sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited

1 0

(ITS#6173) Error while making
by bipin.nair＠iflexsolutions.com 17 Jun '09

17 Jun '09

Full_Name: Bipin Version: OpenLDAP2.2.29 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.127.116.93) Hi, While trying to install OpenLDAP 2.2.29 ,I getting the following error during the 'make' step. --------------------------------------------------------------------- Notes:- 1)I have installed OpenSSL 0.9.7 and Berkley DB 4.5.20 2)Also,the follwing variables are set CPPFLAGS LDFLAGS LIBPATH 3)THe follwoing commands were used as steps to install Openldap cd openldap-2.2.29 ./configure --enable-ldbm make depend make (During this step it fails) ------------------------------------------------------------------- acl.c:85: error: conflicting types for 'acl_get' /usr/include/sys/access.h:86: error: previous declaration of 'acl_get' was here make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. Please help with this issue. Thanks.

1 0

Re: (ITS#6094) test054 doesn't replicate an entry
by dieter＠dkluenter.de 17 Jun '09

17 Jun '09

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: 2.4.16 >> OS: Linux x86_64 >> URL: http://dkluenter.de/download/dkluenter_test054.tgz >> Submission from: (NULL) (87.154.44.82) > >> test054 doesn't replicate the entry dn: ou=3DInformation Technolgy >> Devision,ou=3Dpeople,dc=3Dexample,dc=3Dcom >> A tar archive containing the files >> server1.flt, server2.flt, server1.log, server4.log >> can be downloaded from the below URL > > To aid in reproducing this problem, please provide specific details on > your platform: OS version, CPU architecture, and whether single core > or multi-core. CPU model # may be helpful for comparison purposes. OS: openSUSE-11.1 Hardware Class: cpu Arch: X86-64 Vendor: "AuthenticAMD" Model: 15.31.0 "AMD Athlon(tm) 64 Processor 3000+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat= ,pse36,clflush,mmx,fxsr,sse,sse2,syscall,nx,mmxext,fxsr_opt,lm,3dnowext,3dn= ow,up,rep_good,nopl,lahf_lm Clock: 1800 MHz BogoMips: 3604.50 Cache: 512 kb single core As only Micheal and me reported this problem, it might be openSUSE-11-1 specific.=20 -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung http://www.dpunkt.de/buecher/2104.html sip: +49.180.1555.7770535 GPG Key ID:8EF7B6C6 53=C2=B008'09,95"N 10=C2=B008'02,42"E

1 0

Re: (ITS#6094) test054 doesn't replicate an entry
by hyc＠symas.com 16 Jun '09

16 Jun '09

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.16 > OS: Linux x86_64 > URL: http://dkluenter.de/download/dkluenter_test054.tgz > Submission from: (NULL) (87.154.44.82) > test054 doesn't replicate the entry dn: ou=Information Technolgy > Devision,ou=people,dc=example,dc=com > A tar archive containing the files > server1.flt, server2.flt, server1.log, server4.log > can be downloaded from the below URL To aid in reproducing this problem, please provide specific details on your platform: OS version, CPU architecture, and whether single core or multi-core. CPU model # may be helpful for comparison purposes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by hyc＠symas.com 16 Jun '09

16 Jun '09

michael(a)stroeder.com wrote: > I cannot reproduce it all the time. Can you add SYNC to your debug level and get the logs from one of these incidents? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

OpenLDAP 2.4.11 and bdb: malloc: Cannot allocate memory
by Florian Genaudet 16 Jun '09

16 Jun '09

Hi all, I've got a problem with OpenLdap since I'm trying to insert 1,5 Million of entries into LDAP. OpenLDAP crash with "bdb: malloc: Cannot allocate memory" when approximately 950 000 entries are inserted. My computer got 2GB of RAM and here is my slapd.conf : # This is the main slapd configuration file. See slapd.conf(5) for more > # info on the configuration options. > > ####################################################################### > # Global Directives: > > # Features to permit > #allow bind_v2 > > # Schema and objectClass definitions > > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > #include /etc/schema/samba.schema > include /etc/ldap/schema/bvs.schema > > # Where the pid file is put. The init.d script > # will not stop the server if you change this. > pidfile /var/run/slapd/slapd.pid > > # List of arguments that were passed to the server > argsfile /var/run/slapd/slapd.args > > # Read slapd.conf(5) for possible values > loglevel none > > # Where the dynamically loaded modules are stored > modulepath /usr/lib/ldap > moduleload back_bdb > moduleload syncprov > > # logout idle clients after 10 seconds > idletimeout 10 > > # The maximum number of entries that is returned for a search operation > sizelimit unlimited > > #Specify the maximum number of pending requests for an anonymous session > conn_max_pending_auth 300 > > # The tool-threads parameter sets the actual amount of cpu's that is used > # for indexing. > tool-threads 2 > > > ####################################################################### > # Specific Backend Directives for hdb: > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > backend bdb > > ####################################################################### > # Specific Backend Directives for 'other': > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > #backend <other> > > ####################################################################### > # Specific Directives for database #1, of type hdb: > # Database specific directives apply to this databasse until another > # 'database' directive occurs > database bdb > > dbnosync > # updates are allowed to remain pending > cachesize 1500000 > > index sn,givenName pres,eq > index ENTPersonJointure eq > > > #overlay syncprov > > #syncprov-checkpoint 100 10 > #syncprov-sessionlog 100 > > > # The base of your directory in database #1 > suffix "dc=bvs,dc=fr" > > # rootdn directive for specifying a superuser on the database. This is > needed > # for syncrepl. > rootdn "cn=Manager,ou=ENTPerson,dc=bvs,dc=fr" > rootpw collaba > > # Where the database file are physically stored for database #1 > directory /var/lib/ldap > > # The dbconfig settings are used to generate a DB_CONFIG file the first > # time slapd starts. They do NOT override existing an existing DB_CONFIG > # file. You should therefore change these settings in DB_CONFIG directly > # or remove DB_CONFIG and restart slapd for changes to take effect. > > # For the Debian package we use 2MB as default but be sure to update this > # value if you have plenty of RAM > dbconfig set_cachesize 0 1024000 0 > dbconfig set_flags DB_TXN_NOSYNC > > > # Sven Hartge reported that he had to set this value incredibly high > # to get slapd running at all. See http://bugs.debian.org/303057 for more > # information. > > # Number of objects that can be locked at the same time. > dbconfig set_lk_max_objects 1500 > # Number of locks (both requested and granted) > dbconfig set_lk_max_locks 1500 > # Number of lockers > dbconfig set_lk_max_lockers 1500 > > # Indexing options for database #1 > index objectClass eq > > # Save the time that the entry gets modified, for database #1 > lastmod off > > # Checkpoint the BerkeleyDB database periodically in case of system > # failure and to speed slapd shutdown. > checkpoint 512000 30 > > # Where to store the replica logs for database #1 > # replogfile /var/lib/ldap/replog > > # Basic ACL (deprecated in favour of ACLs in > /etc/openldap/slapd.access.conf) > #access to attr=userPassword > # by self write > # by anonymous auth > # by dn="uid=root,ou=People,dc=example,dc=com" write > # by * none > > # ACL for "Enseignant" profile only (=> can modify all "userPassword" of > its own College) > access to > dn.regex="^cn=(.*),ou=entperson,ou=(.*),ou=(.*),dc=bvs,dc=fr$" > attrs=givenName > by set.regex="user/entPersonProfils & > [cn=Enseignant_$2,ou=entgroup,ou=$2,ou=$3,dc=bvs,dc=fr]" write > by * read > > # ACL for "Administrateur" profile only (=> can modify all data of its own > College) > access to dn.regex="^(.*),ou=(.*),ou=(.*),dc=bvs,dc=fr$" > by set.regex="user/entPersonProfils & > [cn=Administrateur_$2,ou=entgroup,ou=$2,ou=$3,dc=bvs,dc=fr]" write > by * read > > # ACL for "Eleve" profile only (=> can modify only its own "userPassword") > access to attrs=entPersonDateNaissance > by self write > by * read > > access to * > by * read > > ####################################################################### > # Specific Directives for database #2, of type 'other' (can be hdb too): > # Database specific directives apply to this databasse until another > # 'database' directive occurs > #database <other> > > # The base of your directory for database #2 > #suffix "dc=debian,dc=org" > > What am I doing wrong ? Regards.

2 1

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by hyc＠symas.com 15 Jun '09

15 Jun '09

Gavin Henry wrote: > > ----- hyc(a)symas.com wrote: > >> Gavin Henry wrote: >>> Thanks, I'll review and let you know. >>> >>> Gavin. >>> >> And while you're at it, please move the slapd config examples back to >> the end >> of the slapd config chapters where they originally came from. You can >> insert >> references like "for more detailed discussion of access controls go >> -there-" >> but the examples need to be in the config chapters. > > Do you mean like these: > > http://www.openldap.org/doc/admin23/slapdconf2.html#Configuration%20Example > http://www.openldap.org/doc/admin23/slapdconfig.html#Configuration%20File%2… Yes. > > What chapters have I stuck them in then? Will check and move them back. You moved them to Access Control. > Can't remember why I moved them at all. > > Thanks. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6172) Crash with baseObject in back-sql
by masarati＠aero.polimi.it 15 Jun '09

15 Jun '09

openssl(a)mkarcher.dialup.fu-berlin.de wrote: > slapd gets terminated by libc with an "invalid free" error message when using > the baseObject configuration option (whether with or without file) at the time > of the first query. > > This is caused by freeing an entry using "free" that has been allocated using > "entry_dup". This does not match (any more?). Essentially what the code was > trying to to is to duplicate the sql_baseObject to bsi_e. The fix I suggest adds > a function "entry_dup_to" to slapd so that backends can do this operation > cleanly without having to create a temporary dynamic object there is no obvious > clean way to get rid of. I'd rather have a function that returns the entry struct to the pool without calling entry_clean(), to avoid as much as possible code duplication. In any case, good catch. Thanks, p.

1 0

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by ghenry＠OpenLDAP.org 15 Jun '09

15 Jun '09

----- hyc(a)symas.com wrote: > Gavin Henry wrote: > > Thanks, I'll review and let you know. > > > > Gavin. > > > And while you're at it, please move the slapd config examples back to > the end > of the slapd config chapters where they originally came from. You can > insert > references like "for more detailed discussion of access controls go > -there-" > but the examples need to be in the config chapters. Do you mean like these: http://www.openldap.org/doc/admin23/slapdconf2.html#Configuration%20Example http://www.openldap.org/doc/admin23/slapdconfig.html#Configuration%20File%2… What chapters have I stuck them in then? Will check and move them back. Can't remember why I moved them at all. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6172) Crash with baseObject in back-sql
by openssl＠mkarcher.dialup.fu-berlin.de 14 Jun '09

14 Jun '09

Full_Name: Michael Karcher Version: 2.4.11 OS: Debian Linux (squeeze) URL: ftp://ftp.openldap.org/incoming/Michael-Karcher-090614.diff.1 Submission from: (NULL) (87.123.80.3) slapd gets terminated by libc with an "invalid free" error message when using the baseObject configuration option (whether with or without file) at the time of the first query. This is caused by freeing an entry using "free" that has been allocated using "entry_dup". This does not match (any more?). Essentially what the code was trying to to is to duplicate the sql_baseObject to bsi_e. The fix I suggest adds a function "entry_dup_to" to slapd so that backends can do this operation cleanly without having to create a temporary dynamic object there is no obvious clean way to get rid of. I provide a patch to fix that problem. As it is mostly rearranging things, I don't think that patch is copyrightable.

1 0

Re: (ITS#6154) response/cleanup callback mismatch
by h.b.furuseth＠usit.uio.no 12 Jun '09

12 Jun '09

Aha, cleanup handers cannot assume response handler was called, for other reasons too. Fixed back-relay. -- Hallvard

1 0

(ITS#6171) Kill or fix K&R support
by h.b.furuseth＠usit.uio.no 12 Jun '09

12 Jun '09

Full_Name: Hallvard B Furuseth Version: 2.0.0 and later OS: URL: http://www.openldap.org/lists/openldap-devel/200706/msg00009.html Submission from: (NULL) (129.240.6.233) Submitted by: hallvard openldap-devel thread "Kill K&R C support?" from jun 2007, edited into a single quote/response stream: Hallvard B Furuseth wrote: >Kurt Zeilenga wrote: >>Hallvard B Furuseth wrote: >>> As far as I can tell, OpenLDAP has been unusable with K&R C since >>> openldap-2.0: lber.h in that release had prototypes unprotected >>> by LDAP_P() in struct sockbuf_io. They've been there ever since. >>> So LDAP_P() can [edit: probably] go. >> >> I note that the intent was to allow use of -lldap/-llber in K&R C >> programs, but to require ISO C to build OpenLDAP Software. > > Which I think made sense. But now, apparently nobody has complained > about the problem for 7 years. Time to quit worrying about K&R? > >> Seems the former is broken (lber.h issues). Still broken today (jun 2009). >>> Don't know which other not-strict-ISO support is still useful - >>> I note lber.h has used <string.h> since openldap-2.2.4, for example. >>> libldap/open.c has used <limits.h> since 2.0.0. >> >> The latter isn't a problem with regard to the above intent. >> >>> HEAD wraps that >>> in HAVE_LIMITS_H, but it does not protect INT_MAX the same way. >> >> Likewise.

1 0

Re: (ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests> gdb -c core.22616 /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-slapd GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". For bug reporting instructions, please see: <http://bugs.opensuse.org/>... warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2...done. Loaded symbols for /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs/liblber-2.4-releng.so.2...done. Loaded symbols for /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs/liblber-2.4-releng.so.2 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /usr/lib/libdb-4.5.so...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.7...done. Loaded symbols for /usr/lib/libltdl.so.7 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so Reading symbols from /usr/lib/sasl2/liblogin.so...done. Loaded symbols for /usr/lib/sasl2/liblogin.so Reading symbols from /usr/lib/sasl2/libsasldb.so...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so Reading symbols from /usr/lib/sasl2/libotp.so...done. Loaded symbols for /usr/lib/sasl2/libotp.so Reading symbols from /usr/lib/sasl2/libplain.so...done. Loaded symbols for /usr/lib/sasl2/libplain.so Reading symbols from /usr/lib/sasl2/libgssapiv2.so...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so Reading symbols from /usr/lib/sasl2/libdigestmd5.so...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so Reading symbols from /usr/lib/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so Reading symbols from /usr/lib/sasl2/libntlm.so...done. Loaded symbols for /usr/lib/sasl2/libntlm.so Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-hdb/.libs/back_hdb-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-hdb/.libs/back_hdb-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-relay/.libs/back_relay-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-relay/.libs/back_relay-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-ldap/.libs/back_ldap-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-ldap/.libs/back_ldap-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-meta/.libs/back_meta-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-meta/.libs/back_meta-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-monitor/.libs/back_monitor-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-monitor/.libs/back_monitor-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays/.libs/rwm-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2.4-releng.so.2 [New Thread 22784] [New Thread 22616] [New Thread 22926] [New Thread 22646] [New Thread 22965] [New Thread 22892] [New Thread 22950] [New Thread 22909] [New Thread 22875] [New Thread 22939] [New Thread 22816] [New Thread 22953] [New Thread 22848] [New Thread 22818] [New Thread 22631] [New Thread 22765] [New Thread 22937] Core was generated by `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. Program terminated with signal 6, Aborted. #0 0xffffe430 in __kernel_vsyscall () (gdb) info threads 18 Thread 22937 0xffffe430 in __kernel_vsyscall () 17 Thread 22765 0xffffe430 in __kernel_vsyscall () 16 Thread 22631 0xffffe430 in __kernel_vsyscall () 15 Thread 22818 0xffffe430 in __kernel_vsyscall () 14 Thread 22848 0xffffe430 in __kernel_vsyscall () 13 Thread 22953 0xffffe430 in __kernel_vsyscall () 12 Thread 22816 0xffffe430 in __kernel_vsyscall () 11 Thread 22939 0xffffe430 in __kernel_vsyscall () 10 Thread 22875 0xffffe430 in __kernel_vsyscall () 9 Thread 22909 0xffffe430 in __kernel_vsyscall () 8 Thread 22950 0xffffe430 in __kernel_vsyscall () 7 Thread 22892 0xffffe430 in __kernel_vsyscall () 6 Thread 22965 0xffffe430 in __kernel_vsyscall () 5 Thread 22646 0xffffe430 in __kernel_vsyscall () 4 Thread 22926 0xffffe430 in __kernel_vsyscall () 3 Thread 22616 0xffffe430 in __kernel_vsyscall () 2 Thread 22784 0xffffe430 in __kernel_vsyscall () * 1 Thread 22800 0xffffe430 in __kernel_vsyscall () Thread 18 (Thread 22937): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590ec6 in ?? () from /lib/libc.so.6 #2 0x405100ba in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 17 (Thread 22765): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 16 (Thread 22631): #0 0xffffe430 in __kernel_vsyscall () #1 0x40584c56 in epoll_wait () from /lib/libc.so.6 #2 0x08073cf7 in slapd_daemon_task (ptr=0x0) at daemon.c:2325 #3 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #4 0x405843be in clone () from /lib/libc.so.6 Thread 15 (Thread 22818): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 14 (Thread 22848): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 13 (Thread 22953): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 12 (Thread 22816): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82a19d0, timeout=0x4235bb50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82a19d0, msgid=25, all=1, timeout=0x4235bbd0, result=0x4235bbd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82a1678, op=0x8289c10, rs=0x4235c0c8, msgid=25, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x4235c1cc, arg_v=0x8289c10) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x4235c1cc, argv=0x15) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 11 (Thread 22939): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 10 (Thread 22875): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x8289960, timeout=0x43362b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x8289960, msgid=5, all=1, timeout=0x43362bd0, result=0x43362bd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x8289920, op=0x82a0de0, rs=0x433630c8, msgid=5, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x82a0de0, rs=0x433630c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82a0de0, rs=0x433630c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x82a0de0, rs=0x433630c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82a0de0, rs=0x433630c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x433631cc, arg_v=0x82a0de0) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x433631cc, argv=0xe) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 9 (Thread 22909): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b21d8, timeout=0x43d65a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b21d8, msgid=1499, all=1, timeout=0x43d65a80, result=0x43d65a88) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82b1d28, op=0x82b2648, rs=0x43d670c8, msgid=1499, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dadb in ldap_back_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:111 #6 0x080e05fc in overlay_op_walk (op=0x82b2648, rs=0x43d670c8, which=op_modify, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b2648, rs=0x43d670c8, which=op_modify) at backover.c:721 #8 0x0809082d in fe_op_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:301 #9 0x080e05fc in overlay_op_walk (op=0x82b2648, rs=0x43d670c8, which=op_modify, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b2648, rs=0x43d670c8, which=op_modify) at backover.c:721 #11 0x0809136f in do_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:175 #12 0x080772ff in connection_operation (ctx=0x43d671cc, arg_v=0x82b2648) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x43d671cc, argv=0xf) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 8 (Thread 22950): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82732c8, timeout=0x4516e9e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82732c8, msgid=36, all=1, timeout=0x4516ea60, result=0x4516ea68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x8273658, op=0x82e4298, rs=0x4516f0c8, msgid=36, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82e4298, rs=0x4516f0c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82e4298, rs=0x4516f0c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82e4298, rs=0x4516f0c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82e4298, rs=0x4516f0c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82e4298, rs=0x4516f0c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82e4298, rs=0x4516f0c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82e4298, rs=0x4516f0c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x4516f1cc, arg_v=0x82e4298) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x4516f1cc, argv=0x2b) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 7 (Thread 22892): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82e47f8, timeout=0x43863a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82e47f8, msgid=17, all=1, timeout=0x43863a80, result=0x43863a88) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82e4648, op=0x82ab258, rs=0x438650c8, msgid=17, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dadb in ldap_back_modify (op=0x82ab258, rs=0x438650c8) at modify.c:111 #6 0x080e05fc in overlay_op_walk (op=0x82ab258, rs=0x438650c8, which=op_modify, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82ab258, rs=0x438650c8, which=op_modify) at backover.c:721 #8 0x0809082d in fe_op_modify (op=0x82ab258, rs=0x438650c8) at modify.c:301 #9 0x080e05fc in overlay_op_walk (op=0x82ab258, rs=0x438650c8, which=op_modify, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82ab258, rs=0x438650c8, which=op_modify) at backover.c:721 #11 0x0809136f in do_modify (op=0x82ab258, rs=0x438650c8) at modify.c:175 #12 0x080772ff in connection_operation (ctx=0x438651cc, arg_v=0x82ab258) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x438651cc, argv=0x19) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 6 (Thread 22965): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x83188d0, timeout=0x45b72b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x83188d0, msgid=2, all=1, timeout=0x45b72bd0, result=0x45b72bd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82ab5d0, op=0x8315870, rs=0x45b730c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x8315870, rs=0x45b730c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x8315870, rs=0x45b730c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x8315870, rs=0x45b730c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x8315870, rs=0x45b730c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x45b731cc, arg_v=0x8315870) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x45b731cc, argv=0x25) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 5 (Thread 22646): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b7d80, timeout=0x41054bc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b7d80, msgid=6, all=1, timeout=0x41054c40, result=0x41054c48) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82b7d40, op=0x825ea70, rs=0x410550c8, msgid=6, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d75a in ldap_back_delete (op=0x825ea70, rs=0x410550c8) at delete.c:62 #6 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #8 0x080917cb in fe_op_delete (op=0x825ea70, rs=0x410550c8) at delete.c:174 #9 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #11 0x08091d86 in do_delete (op=0x825ea70, rs=0x410550c8) at delete.c:95 #12 0x080772ff in connection_operation (ctx=0x410551cc, arg_v=0x825ea70) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x410551cc, argv=0x12) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 4 (Thread 22926): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82f0db8, timeout=0x442689e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82f0db8, msgid=2, all=1, timeout=0x44268a60, result=0x44268a68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82f0c30, op=0x82b5cb8, rs=0x442690c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82b5cb8, rs=0x442690c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82b5cb8, rs=0x442690c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82b5cb8, rs=0x442690c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x442691cc, arg_v=0x82b5cb8) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x442691cc, argv=0x1e) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 at bind.c:1704 #5 0x4078d75a in ldap_back_delete (op=0x825ea70, rs=0x410550c8) at delete.c:62 #6 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #8 0x080917cb in fe_op_delete (op=0x825ea70, rs=0x410550c8) at delete.c:174 #9 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #11 0x08091d86 in do_delete (op=0x825ea70, rs=0x410550c8) at delete.c:95 #12 0x080772ff in connection_operation (ctx=0x410551cc, arg_v=0x825ea70) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x410551cc, argv=0x12) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 4 (Thread 22926): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82f0db8, timeout=0x442689e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82f0db8, msgid=2, all=1, timeout=0x44268a60, result=0x44268a68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82f0c30, op=0x82b5cb8, rs=0x442690c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82b5cb8, rs=0x442690c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82b5cb8, rs=0x442690c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82b5cb8, rs=0x442690c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x442691cc, arg_v=0x82b5cb8) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x442691cc, argv=0x1e) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 ---Type <return> to continue, or q <return> to quit--- Thread 3 (Thread 22616): #0 0xffffe430 in __kernel_vsyscall () #1 0x4024a747 in pthread_join () from /lib/libpthread.so.0 #2 0x40030204 in ldap_pvt_thread_join (thread=1086671760, thread_return=0x0) at thr_posix.c:197 #3 0x080710f3 in slapd_daemon () at daemon.c:2700 #4 0x0805e205 in main (argc=8, argv=0xbf859b34) at main.c:950 Thread 2 (Thread 22784): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 22800): #0 0xffffe430 in __kernel_vsyscall () #1 0x404dd990 in raise () from /lib/libc.so.6 #2 0x404df2c8 in abort () from /lib/libc.so.6 #3 0x404d678e in __assert_fail () from /lib/libc.so.6 #4 0x4078a0eb in ldap_back_conn_delete (li=0x8202d90, lc=0x82a17e8) at bind.c:157 #5 0x4078af81 in ldap_back_freeconn (li=0x8202d90, lc=0x82a17e8, dolock=0) at bind.c:467 #6 0x4078b059 in ldap_back_release_conn_lock (li=0x8202d90, lcp=0x41f5ace8, dolock=1) at bind.c:1147 #7 0x4078cc2d in ldap_back_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:355 #8 0x080e05fc in overlay_op_walk (op=0x8289088, rs=0x41f5b0c8, which=op_bind, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #9 0x080e10f4 in over_op_func (op=0x8289088, rs=0x41f5b0c8, which=op_bind) at backover.c:721 #10 0x08095b5c in fe_op_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:383 #11 0x080e05fc in overlay_op_walk (op=0x8289088, rs=0x41f5b0c8, which=op_bind, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #12 0x080e10f4 in over_op_func (op=0x8289088, rs=0x41f5b0c8, which=op_bind) at backover.c:721 #13 0x08096692 in do_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:205 #14 0x080772ff in connection_operation (ctx=0x41f5b1cc, arg_v=0x8289088) at connection.c:1115 #15 0x08077c87 in connection_read_thread (ctx=0x41f5b1cc, argv=0x2c) at connection.c:1248 #16 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #17 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #18 0x405843be in clone () from /lib/libc.so.6

1 0

Re: (ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

tests/testrun/ available under: http://www.stroeder.com/temp/openldap/its6170_test039-testrun.tar.gz

1 0

(ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

Full_Name: Michael Ströder Version: RE24 synced recently OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.103.142) I cannot tell whether that's a dup of ITS#5733. ----------------------------- Console output ----------------------------------- >>>>> Starting test039-glue-ldap-concurrency ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... MONITORDB mod SRCDIR /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests/testrun/./testdata DSTDIR /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests/testrun pwd /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests Using tester for concurrent server access... PID=22677 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Barbara Jensen)" attrs=cn (more...). PID=22679 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22685 - Modrdn(50): entry="cn=Dorothy Stevens,ou=Alumni Association,ou=People,o=Example,c=US". PID=22690 - Modify(50): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22695 - Add/Delete(50): entry="cn=James A Jones 3,ou=Alumni Association,ou=People,o=Example,c=US". PID=22705 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-bind PID=22705: ldap_sasl_bind_s: Invalid credentials (49) PID=22715 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=22737 - Modrdn(50): entry="cn=John Doe,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22724 - Read(1000): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". PID=22746 - Modify(50): entry="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22758 - Add/Delete(50): entry="cn=James A Jones 5,o=Example,c=US". PID=22772 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22786 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=James A Jones 1)" attrs=cn (more...). PID=22801 - Read(1000): entry="ou=Groups, o=Example,c=US". PID=22817 - Modrdn(50): entry="cn=Ursula Hampster,ou=Alumni Association,ou=People,o=Example,c=US". PID=22833 - Modify(50): entry="cn=James A Jones 1,ou=Alumni Association,ou=People,o=Example,c=US". PID=22850 - Add/Delete(50): entry="cn=James A Jones 2,ou=Alumni Association,ou=People,o=Example,c=US". PID=22882 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=22863 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=22898 - Read(1000): entry="ou=Alumni Association, ou=People, o=Example,c=US". PID=22863 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. slapd-bind PID=22863: ldap_sasl_bind_s: Invalid credentials (49) slapd-search PID=22677: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Barbara Jensen)" PID=22677 - Search done (-1). slapd-read PID=22679: ldap_search_ext_s(cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US): Can't contact LDAP server (-1) PID=22679 - Read done (-1). slapd-modrdn PID=22685: ldap_rename_s: Can't contact LDAP server (-1) PID=22685 - Modrdn done (-1). slapd-modify PID=22690: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22690 - Modify done (-1). slapd-addel PID=22695: ldap_delete_ext_s: Can't contact LDAP server (-1) PID=22695 - Add/Delete done (-1). slapd-bind PID=22705: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22705 - Bind done (-1). slapd-modrdn PID=22737: ldap_rename_s: Can't contact LDAP server (-1) PID=22737 - Modrdn done (-1). slapd-search PID=22715: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=22715 - Search done (-1). slapd-read PID=22724: ldap_search_ext_s(cn=ITD Staff,ou=Groups,o=Example,c=US): Can't contact LDAP server (-1) PID=22724 - Read done (-1). slapd-modify PID=22833: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22833 - Modify done (-1). slapd-modify PID=22746: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22746 - Modify done (-1). slapd-addel PID=22758: ldap_add_ext_s: Can't contact LDAP server (-1) PID=22758 - Add/Delete done (-1). slapd-bind PID=22772: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22772 - Bind done (-1). slapd-search PID=22786: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=James A Jones 1 )" PID=22786 - Search done (-1). slapd-modrdn PID=22817: ldap_rename_s: Can't contact LDAP server (-1) PID=22817 - Modrdn done (-1). slapd-read PID=22801: ldap_search_ext_s(ou=Groups, o=Example,c=US): Can't contact LDAP server (-1) PID=22801 - Read done (-1). slapd-addel PID=22850: ldap_add_ext_s: Can't contact LDAP server (-1) PID=22850 - Add/Delete done (-1). slapd-bind PID=22863: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22863 - Bind done 1 in 3.719714 seconds. slapd-search PID=22882: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=22882 - Search done (-1). slapd-read PID=22898: ldap_search_ext_s(ou=Alumni Association, ou=People, o=Example,c=US): Can't contact LDAP server (-1) PID=22898 - Read done (-1). PID=22986 - Modrdn(50): entry="cn=James A Jones 2,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-modrdn PID=22986: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22990 - Modify(50): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". PID=22992 - Add/Delete(50): entry="cn=James A Jones 4,ou=People,o=Example,c=US". slapd-modify PID=22990: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-addel PID=22992: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22999 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=22999: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22999 - Bind done (-1). PID=23005 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). slapd-search PID=23005: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23013 - Read(1000): entry="cn=James A Jones 1, ou=Alumni Association, ou=People, o=Example,c=US". slapd-read PID=23013: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23022 - Bind(1000): dn="". slapd-bind PID=23022: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23022 - Bind done (-1). PID=23032 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=James*)" attrs=cn (more...). slapd-search PID=23032: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23041 - Read(1000): entry="ou=Meta,o=Example,c=US". PID=23053 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-read PID=23041: ldap_sasl_bind_s: Can't contact LDAP server (-1) stopping: child exited with status 1 ./scripts/test039-glue-ldap-concurrency: line 188: 22616 Aborted (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMI NG > $LOG3 2>&1 slapd-tester failed (1)! ./scripts/test039-glue-ldap-concurrency: line 193: kill: (22616) - No such process >>>>> ./scripts/test039-glue-ldap-concurrency failed (exit 1) make[2]: *** [hdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2 slapd-bind PID=23053: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23066 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=23053 - Bind done (-1). slapd-search PID=23066: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23091 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=23077 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". slapd-bind PID=23091: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23091 - Bind done (-1). slapd-read PID=23077: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23106 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap> slapd-search PID=23106: ldap_sasl_bind_s: Can't contact LDAP serv er (-1) bindDN="cn=Manager,o=Example,c=US" PID=23119 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". slapd-read PID=23119: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=23135: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23152 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). slapd-search PID=23152: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23181 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=23181: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23181 - Bind done (-1). PID=23165 - Read(1000): entry="cn=Entries,cn=Statistics,cn=Monitor". slapd-read PID=23165: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23194 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). slapd-search PID=23194: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US"

1 0

(ITS#6169) dds overlay bug(s) when expiring entries
by h.b.furuseth＠usit.uio.no 11 Jun '09

11 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Thinko in dds_expire(): Traversing a list chained on (struct dds_expire_t).de_next, it keeps dds_expire_t **dep == &(previous element).de_next. Before freeing (de = *dep), it points dep into de. Fixing. Suspicious code in same function: The 'default:' branch says "deferring" (deferring what? deletion?) and does not increment ndeletes, yet 'dds_expire_t *de' is deleted in that case as well. Is that intentional? I don't know dds. If it's not, we could just move the free() into 'case LDAP_SUCCESS:' and remove the 'de = NULL;' in the LDAP_NOT_ALLOWED_ON_NONLEAF case.

1 0

(ITS#6168) Account locked without associated ppolicy
by coudot＠linagora.com 10 Jun '09

10 Jun '09

Full_Name: Clement OUDOT Version: 2.4.16 OS: Linux 2.6.18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hello, I have a ppolicy overlay without default ppolicy: --- overlay ppolicy ppolicy_use_lockout ppolicy_hash_cleartext --- So only users with pwdPolicySubEntry should be submitted to password policy. But if I add "pwdAccountLockedTime: 000001010000Z" to an entry without pwdPolicySubEntry, this entry is locked.

1 0

OpenLDAP dynamic configuration prefomance issue
by Dmitry Korotkov 09 Jun '09

09 Jun '09

Dear OpenLDAP team, I made some OpenLDAP stress tests on our use cases and realized that time of registering new objectClass using OpenLDAP dynamic configuration grows linearly. It looks like slapd completely rewrites contents of cn=config folder on any configuration change. This issue makes OpenLDAP schema to be a bottleneck in our large scalable application. Do you plan to store OpenLDAP configuration in bdb or hdb database? Or another solution of this issue is planned? WBR, Dmitry V. Korotkov

2 2

(ITS#6167) back-ldap: TLS: uri list broken
by christian.fischer＠fischundfischer.com 09 Jun '09

09 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) back-ldap hangs on ldap_back_bind() while starting TLS if the first mirror in uri list is down ldap_pvt_thread_mutex_lock() in back-ldap/bind.c:1584 never returns and slapd hangs reproducible: always steps to reproduce: - configure a uri list with two mirrors, the first one offline, start TLS database ldap suffix "dc=foo,dc=bar" uri "ldap://mirror01.foo.bar ldap://mirror02.foo.bar" tls start tls_reqcert=never

1 0

(ITS#6166) Overlay/backend restructuring
by h.b.furuseth＠usit.uio.no 09 Jun '09

09 Jun '09

Full_Name: Hallvard B Furuseth Version: RE25/RE30 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some wishes/loose thoughts about overlay/backend code: * Remove backends internally, making them like overlays? (RE30) * Reduce copying of overlay data -op->o_bd->bd_info (RE25?) * Lose slap_overinst, move its members into BackendInfo. <hbf> Could we reduce complexity if there internally were no (programmable) backends, only overlays? Backends would be thinly disguised overlays. Maybe over a single fixed "core overlay" which intercepts all calls, or the opposite - a fixed empty backend. <hbf> .what do overlays cost compared to backends? Must reduce copying, but that seems already to be the plan. And slapd must repair some data structures which overlays are not required to clean up - must that stay? Am I talking sense at all? <hyc> eh, not sure what you're really talking about. turn all backends into overlays, to keep the API completely uniform? <hbf> yes. and return values the same way - SLAP_CB_CONTINUE when they don't know what to do, for example. <hbf> there seems to be code snippets around doing similar things for backends and overlays, and they mostly share the same data structure. so i wondered if the backend stuff could simply go away. <hyc> so we'd still need special cases in the frontend to handle SLAP_CB_CONTINUE falling out at the end <hyc> ideally, sure. <hyc> that seems like more of a 3.0 move than a 2.5 <hbf> yes, i suppose so <hbf> and it depends on overlays being as fast as backends <hyc> fast at what? <hyc> there's no measurable overhead for overlays on top of backends <hbf> handling a request. slapd does all this copying of overlay structures that I haven't even tried to figure out, I assume that costs time compared to a backend. <hyc> well, a lot of that copying can go away if we just rationalize the on_info stuff <hyc> I already mentioned that on -devel a while back <hyc> op->o_bd->bd_info <hyc> if we referenced those pointers from op instead of op->o_bd we'd need no copying at all <hyc> but i think that would require changes to a lot of existing backend code. <hyc> the copying approach was taken to allow overlays to be slotted in without modifying any backend code <hbf> oh well, we've more pressing problems in that case <hyc> actually come to think of it most backends don't care as it is. at this point it's the overlays and bconfig that would need to be changed <hyc> I guess we should have made that change sooner rather than later, as now the number of overlays is quite large :P <hyc> hindsight, oh well. <hyc> I wouldn't be opposed to attempting that change for 2.5. sooner is obviously better now. <hbf> related loose thought: overlays could lose all those (slap_overinst *)op->o_bd->bd_info casts if the slap_overinst members were inserted in BackendInfo and slap_overinst became an obsolete wrapper about just BackendInfo. Costs ~24 bytes/backend. <hyc> ok <hyc> that sounds smart

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 09 Jun '09

09 Jun '09

rein(a)OpenLDAP.org wrote: > michael(a)stroeder.com wrote: > >> Found 6 errors >>>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) > > Do you have the entire output from the test script? You mean the console output? Unfortunately not. As said I've generated a tar.gz of the whole testrun/ directory though: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz > [..] without it I'm tempted to assume it > failed due to some timing glitch within the test script itself.. Hmm, how to find out? Ciao, Michael.

1 0

(ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠OpenLDAP.org 09 Jun '09

09 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The slapmodify function already exists, but we've never built a tool around it. It would be useful to be able to have a utility that validates commands that users can use to modify cn=config while slapd is offline, rather than resorting to text editors that don't do validation of the changes being made.

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by rein＠OpenLDAP.org 08 Jun '09

08 Jun '09

michael(a)stroeder.com wrote: > Found 6 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) Do you have the entire output from the test script? It is required to tell what actually went wrong, and without it I'm tempted to assume it failed due to some timing glitch within the test script itself.. Rein

1 0

(ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 08 Jun '09

08 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard send_ldap_ber() has a suspicious-looking waitloop doing this: if ( ldap_pvt_thread_mutex_trylock( &conn->c_mutex )) { ldap_pvt_thread_mutex_unlock( &conn->c_write1_mutex ); ldap_pvt_thread_mutex_lock( &conn->c_write1_mutex ); Unlock does not mean a thread waiting for c_write1_mutex will acquire it immediately. Such a thread may have to wait until it is scheduled, at which time the looping thread has locked the mutex again. On the Linux box on my desk, a pure unlock-lock loop goes through 50000-100000 iterations before another thread waiting for the lock acquires it. OTOH, on a heavily used box it takes ~50 iterations. A sched_yield() between the unlock and lock reduces #iterations to 1. No idea if that is the right solution, nor how serious the problem is. The lock/unlock statements themselves are from result.c rev 1.323, but then with some more locking between them which disappeared in later revisions. My lock-unlock test program: #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <sys/select.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static unsigned count; static void *waiter(void *arg) { pthread_mutex_lock(&m); printf("Locked after %u iterations.\n", count); exit(0); } int main() { pthread_t t; pthread_mutex_lock(&m); pthread_create(&t, NULL, waiter, NULL); select(0, NULL, NULL, NULL, &(struct timeval){0, 100000}); for (count = 1 ;; ++count) { pthread_mutex_unlock(&m); pthread_mutex_lock(&m); } }

1 0

(ITS#6163) back-sql DoS when searching for empty attr
by karavelov＠spnet.net 08 Jun '09

08 Jun '09

Full_Name: Luben Karavelov Version: 2.4.11-15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.83.96.32) We use ldap for some user accounts authentication here and we have found that queries of this kind : ldapsearch -b "dc=users,dc=example,dc=com" "(&(objectClass=posixAccount)(uid=))" kill slapd. It exits on assert( 0 ) at line 1366 of back-sql/search.c It is even nastier because it could be remotely triggered with ssh -l "" server-with-ldap-accounts-in-nss.example.com or through ftp using the same technique.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 08 Jun '09

08 Jun '09

Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.

1 0

(ITS#6162) hexadecimal log levels are not recognized in configuration
by jonathan＠phillipoux.net 08 Jun '09

08 Jun '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-bconfig-20090608.patch Submission from: (NULL) (80.65.230.146) The slapd-config(5) and slapd.conf(5) man pages state: olcLogLevel: <integer> [...] The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation [...] as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, This is not the case. Integers and names (strings) are accepted, but hex notation is refused, with, from slapd.conf: /opt/openldap-RE24/etc/openldap/slapd.conf: line 10: <loglevel> unable to parse level "0x40" And using ldapmodify on cn=config: ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcLogLevel> unable to parse level Hexadecimal values are, however, accepted as arguments to the -d argument to slapd on the command line. The above patch fixes bconfig.c to accept hex values. On a side note, according to man strtol(3), this also means that loglevels can be typed in octal, for the more masochist among us :)

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Download content of directory testrun/ here: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz I cannot reproduce this within directory tests/. It usually ends with this message: ERROR: Entry not removed on central search! Race error found after 1 of 10 iterations Found 3 errors >>>>>> Exiting with a false success status for now

1 0

(ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.113.91) Found 6 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) make[2]: *** [hdb-mod] Error 6 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 05 Jun '09

05 Jun '09

Hrmph, the placement of the 'so->s_op->o_abandon = 1;' which I wanted to move out of the mutex lock derives from syncprov.c rev 1.20 commented "Fix abandon sequencing":-( -- Hallvard

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by quanah＠zimbra.com 05 Jun '09

05 Jun '09

--On Friday, June 05, 2009 9:25 PM +0100 Gavin Henry <gavin.henry(a)gmail.com> wrote: > Is there a SEE ALSO? > > Will check and amend. Regardless of SEE ALSO, it should note that it indexes the database while adding it. ;) SEE ALSO ldap(3), ldif(5), slapcat(8), ldapadd(1), slapd(8) Should probably have slapindex in the SEE ALSO as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by gavin.henry＠gmail.com 05 Jun '09

05 Jun '09

Is there a SEE ALSO? Will check and amend. On 05/06/2009, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The man page for slapadd does not note that it also performs indexing while > adding the database. While this is fairly obvious to those of us > experienced > with using OpenLDAP, it is non-obvious to new users. > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6160) slapadd man page doesn't note indexing
by quanah＠OpenLDAP.org 05 Jun '09

05 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The man page for slapadd does not note that it also performs indexing while adding the database. While this is fairly obvious to those of us experienced with using OpenLDAP, it is non-obvious to new users.

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 04 Jun '09

04 Jun '09

Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind), partly fixed cancel(cn=config update) problem, without doing this: > Suggested partual fix - add this possible value for o_cancel: > #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Still need something that to fix cancel(cn=config update) completely. syncrepl/syncprov, starttls not yet addressed. Also cancel(cancel) still behaves in a non-RFC way. Correct fix would require resetting o_abandon, which seems unsafe. Who knows what has already reacted to it. Will update this patch for the remaining issues later: > Something like this: > http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt -- Hallvard

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 04 Jun '09

04 Jun '09

Howard Chu wrote: > Andrew Bartlett wrote: >> I agree, we might be jumping at different shadows here, but your patches >> did fix something... > > I see what you're describing now, with the kvm set with 2 CPUs. It appears to > be a bug caused by the recent patch for connection_hangup() processing. > Running slapd with -d15 in your test shows that a connection is closed shortly > after being established and becoming readable. The bug is (probably) that we > queued the reader but processed the hangup immediately, thus closing the > connection before the reader executes. I'm not exactly sure why this is > causing the problem on your test, since it looks like your client is closing > the socket before waiting for the reply. But certainly this is the right area. > With the connection problem out of the way, the remaining slapd crash appeared to be due to some type of heap corruption, but the usual suite of tools (valgrind, efence, LBER_MEMORY_DEBUG, etc.) didn't ever reproduce the problem. On the assumption that this was related to a stack overwrite I recompiled libldap_r with a 12MB stack size instead of the default 8MB and that still didn't change the outcome. On the assumption that there was some other race condition involved, I set slapd to only 2 threads (from default of 16) to try and limit the possibilities there. This caused the crash to occur much more quickly, and using libumem it became obvious that refint was accessing already-freed memory. So it turns out that the patch for rev 1.41 (ITS#5428) to make this into a global overlay was incorrect; it moved the loop that processed its work queue into a new function so that it could be called multiple times, but it was still using that code basically as-is, which freed its queue as it operated. (Because originally the queue was only walked once.) Part of the reason the bug was so hard to reproduce is because it tended to only show up when the queue got fairly long, and that only happened if slapd was too busy. (Thus, forcing only 2 threads made it occur sooner.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 04 Jun '09

04 Jun '09

On Jun 4, 2009, at 9:15 AM, masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin- > friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many > times it > evaluated to answerable That's very useful. Any thoughts about how to determine pcache's overall 'hit rate'? > > > - "proxycache-" prefixed statements are passed to the private > database. > This allows to avoid ambiguities when applying general database > directives > in slapd.conf. In fact, it is not clear whether they apply to the > proxy > database or to the cache database. Also useful. > > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. I agree. > > > p. > > > -Matt

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 04 Jun '09

04 Jun '09

Just in case, before it becomes totally incompatible with HEAD code, I have a patch I never committed, it's about making pcache admin-friendly if it makes any sense. It adds: - a (persistent) counter that reports, for each query, how many times it evaluated to answerable - "proxycache-" prefixed statements are passed to the private database. This allows to avoid ambiguities when applying general database directives in slapd.conf. In fact, it is not clear whether they apply to the proxy database or to the cache database. If they make sense, I'd like to commit them before slapo-pcache enhancement begins. p.

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 03 Jun '09

03 Jun '09

On a related note, any solution using pcache for disconnected operation should also be able to cache bind operations. This is a digest of a conversation I had with Howard about that: Currently pcache always forwards binds to the db beneath it. These will fail in disconnected cases. One solution is to give the pcache identity read privs to the userpassword, but for security and design reasons that won't fly in most installations. Another solution is to add bind caching to pcache, and that is what is described below. Bind caching functionality can be integrated with pcache, provided that we can meet some conditions: 1. Guarantee that the object being bound against is already in pcache when it passes the bind through. 2. Have an attribute in the cached object where pcache can store a hashed version (e.g. SSHA) of the password it got from the user and verified against the underlying database. Remember that we must verify it against the underlying db before we can write it to cache. Most applications performing LDAP authentication will first search for the object to which they're intending to bind. This will cause condition (1) to be satisfied, but this is not good enough because it is not guaranteed that all applications will first search for the object to which they're binding- some applications build the bind DN 'blindly' using string substitution rules or even hard-coded bind DNs. This is wrong, but it's the way things are. Therefore, pcache itself should search for the object being being bound to and populate the cache with the search result. The details of how the object is added to the cache remain to be determined. Satisfying (1) provides the opportunity to construct an proxyattrset that includes a (possibly dummy) attribute in which the hashed validated password can be stored, thus satisfying condition (2). The userPassword attribute can probably be used most of the time for this, since it will either be returned form the server either empty or with a value of '*'. The "do bind caching directive" might refer to a proxyattrset constructed for this purpose. Bind caching will interact with TTR, but the details are as yet undetermined. To round out the solution, we should also process pwdModify exops as follows: For pwdModify exops, pcache would could operate as a 'write-through' cache, first making sure the object in the cache is current. If the write-through to the underlying database succeeds, then the object in the cache is also updated. Otherwise the exop fails and any cached copy is left unaltered. -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by quanah＠zimbra.com 03 Jun '09

03 Jun '09

--On Wednesday, June 03, 2009 7:22 AM +0000 jonathan(a)phillipoux.net wrote: > Will this patch make it into RE23 for a possible maintenance release of > 2.3? There will be no further releases of OpenLDAP 2.3. You should at this point be working on migrating to the OpenLDAP 2.4 release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 03 Jun '09

03 Jun '09

Suggested partual fix - add this possible value for o_cancel: #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Something like this: http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel with yet another value. That's ugly enough already, so I let that wait. connection_abandon() in particular isn't invalid client action, but it shouldn't be worse than causing a surprising result code or not response before closing the connection. Does not address syncprov's Cancel handler. I don't know if the bconfig.c pathces are correct, but need to reject cancel before (reacting to) thread pool pauses there and maybe in syncrepl/syncprov. -- Hallvard

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 03 Jun '09

03 Jun '09

On 02.06.2009 18:23, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> OK, I've spent some more time trying to understand this part of >> syncprov.c. From what I understand : >> >> - the assert failure in ldap_pvt_runqueue_resched is caused by the fact >> syncprov_qstart is trying to "reschedule" a task that is no longer in >> the task_list >> - the only time the task is removed from the task_list (via >> ldap_pvt_runqueue_remove) is when the task is being run, in >> syncprov_qtask, if syncprov_qplay returns !=0 >> - the next time syncprov_qstart is called, it finds "so->s_qtask" is not >> NULL, and tries to reschedule the task, but it's no longer in the >> task_list. >> >> I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, >> just after removing the task from the task_list. So that when >> syncprov_qstart is called again, it goes into >> ldap_pvt_runqueue_insert... The patch is attached. >> >> Unfortunately, I can't confirm it fixes the bug since I can't reproduce >> it... For those who understand the logic behind this, does this make any >> sense? :) > > Ah, you want rev 1.249 of syncprov.c. Closing this as a dup of ITS#5776. Indeed, that's great. Thanks a lot! > Of course, all of this code has been removed from RE24 as of 1.265. Will this patch make it into RE23 for a possible maintenance release of 2.3? Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

(ITS#6159) olcLimits has no replace/delete
by mbackes＠symas.com 02 Jun '09

02 Jun '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93) olcLimits only accepts modify ADD suboperations; replace and delete fail, making any changes to existing olcLimits specifications impossible without stopping and editing LDIF.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs