- openldap-bugs - openldap.org

(ITS#6865) delta-sync - contextCSN not updating on provider
by yuribank＠gmail.com 14 Mar '11

14 Mar '11

Full_Name: Yuri Bank Version: 2.4.23-24 OS: Linux Ubuntu 10.10 URL: http://yuri.easytospell.net/consumer.provider.txt Submission from: (NULL) (67.180.182.165) This issue exists in both versions 2.4.23 and 2.4.24 I've found an interesting problem with delta-sync replication in which the ContextCSN on my consumers is higher than the contextCSN on my provider. This is because the Provider does not properly update its contextCSN for its base suffix (dc=test,dc=com) when changes are made to group membership. Of couse, if it so happens that the last change in my database was not a group membership change, then the contextCSNs will be consistent between my consumers and provider. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 So we can see that the two consumers have matching contextCSNs: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 The providers CSN is smaller!? Lets take a closer look and search cn=accesslog These are the last two entries: ( first the user was added, and then the user was added to a group) # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z You can see that the consumers have the latest entryCSN (20110313041653.752098Z) as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) before that as its contextCSN: If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the same result as the consumers: 20110313041653.752098Z#000000#000#000000 As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Also notice that the last modification was to group membership. This problem only seems to exist when Adding/Removing users from a group. A side effect of this issue causes brand new consumers to get stuck in an infinite loop while syncing for the first time. A work around is to make a random change to a User/Person, such as injecting a random number into their description field AFTER making a change to a group membership. Such a change will: A. cause the Provider to correctly update its contextCSN, B. provider and all consumer[s] will have the same contextCSN C. brand new consumers can be added without getting stuck in an infinite loop when syncing the database. ( they seem to get stuck on the last entry which makes sense if the last entry has a higher entryCSN than that of the Providers contextCSN? ) Confgiuration: ( See URL ) http://yuri.easytospell.net/consumer.provider.txt Overlays: syncprov accesslog memberof Please feel free to email me about reproducing this problem. I have a lab with various configurations and would be happy to give access to anyone interested. - Yuri Bank

1 0

(ITS#6864) delta-sync - contextCSN not updating on provider
by yuribank＠gmail.com 14 Mar '11

14 Mar '11

Full_Name: Yuri Bank Version: 2.4.23-24 OS: Linux Ubuntu 10.10 URL: http://yuri.easytospell.net/consumer.provider.txt Submission from: (NULL) (67.180.182.165) This issue exists in both versions 2.4.23 and 2.4.24 I've found an interesting problem with delta-sync replication in which the ContextCSN on my consumers is higher than the contextCSN on my provider. This is because the Provider does not properly update its contextCSN for its base suffix (dc=test,dc=com) when changes are made to group membership. Of couse, if it so happens that the last change in my database was not a group membership change, then the contextCSNs will be consistent between my consumers and provider. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 So we can see that the two consumers have matching contextCSNs: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 The providers CSN is smaller!? Lets take a closer look and search cn=accesslog These are the last two entries: ( first the user was added, and then the user was added to a group) # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z You can see that the consumers have the latest entryCSN (20110313041653.752098Z) as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) before that as its contextCSN: If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the same result as the consumers: 20110313041653.752098Z#000000#000#000000 As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Also notice that the last modification was to group membership. This problem only seems to exist when Adding/Removing users from a group. A side effect of this issue causes brand new consumers to get stuck in an infinite loop while syncing for the first time. A work around is to make a random change to a User/Person, such as injecting a random number into their description field AFTER making a change to a group membership. Such a change will: A. cause the Provider to correctly update its contextCSN, B. provider and all consumer[s] will have the same contextCSN C. brand new consumers can be added without getting stuck in an infinite loop when syncing the database. ( they seem to get stuck on the last entry which makes sense if the last entry has a higher entryCSN than that of the Providers contextCSN? ) Confgiuration: ( See URL ) http://yuri.easytospell.net/consumer.provider.txt Overlays: syncprov accesslog memberof Please feel free to email me about reproducing this problem. I have a lab with various configurations and would be happy to give access to anyone interested. - Yuri Bank

1 0

Re: (ITS#6861) slapd and syncrepl performance problem
by quanah＠zimbra.com 14 Mar '11

14 Mar '11

--On Thursday, March 10, 2011 4:36 PM +0000 jeff_wheeler67(a)comcast.net wrote: > Full_Name: Jeff Wheeler > Version: 2.4.20 This release is significantly out of date, and missing numerous replication related patches. I advise attempting to reproduce with a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by h.b.furuseth＠usit.uio.no 14 Mar '11

14 Mar '11

dvladi(a)websense.com writes: > You are right, ldap_int_thread_mutex_(X) functions were introduced in > 2.3.8 on 10/06/2005. > > But there is NO declaration or function definition anywhere in the code. Fixed in HEAD to ldap_pvt_thread_mutex_init() after an overeager namespace cleanup. (I had confused it with some libldap_r debug stuff.) The other ldap_int_* stuff looks OK. -- Hallvard

1 0

(ITS#6863) possible null pointer dereference in NSS
by jvcelak＠redhat.com 14 Mar '11

14 Mar '11

Full_Name: Jan Vcelak Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jan-vcelak-nss-null-pointer-dereference-110… Submission from: (NULL) (209.132.186.34) Hello. Recent NSS patch, which adds full non-blocking semantics (ITS #6714), introduced possible NULL pointer dereference by mistake. This patch fixes the problem. Jan

1 0

(ITS#6862) Patch - Mozilla NSS - redux: disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 10 Mar '11

10 Mar '11

Full_Name: Rich Megginson Version: 2.4.24 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.24-use-strdup-for-nofork-envva… Submission from: (NULL) (76.113.111.209) There was still a problem with the fix for http://www.openldap.org/its/index.cgi?findid=6811 Under certain conditions, and with certain shells, the PR_SetEnv with the constant string was causing free() assertion failures in unrelated software. # su - foo free(0x173bd2) below bottom of memory. (memtop = 0x9898800 membot = 0x973e000) # gdb /bin/tcsh coredump (gdb) bt #0 0x00ed9416 in __kernel_vsyscall () #1 0x006e02f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x006e1d5e in abort () at abort.c:92 #3 0x08084e6a in free (cp=0x8f2bd2) at tc.alloc.c:313 #4 0x08063d83 in blkfree (av0=0x9e7d988) at sh.misc.c:158 #5 0x0805af6f in tsetenv (name=0x80a3420 L"GROUP", val=0x9e32608 L"valid_group") at sh.func.c:1725 #6 0x0804d910 in main (argc=<value optimized out>, argv=0xbfa7e4f4) at sh.c:561 Using PR_SetEnv with a strdup()ed string solved the problem. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (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.

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by masarati＠aero.polimi.it 10 Mar '11

10 Mar '11

hyc(a)symas.com wrote: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Klünter >> Version: 2.4.24 >> OS: SLES11_x64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.18.17) >> >> >> A ldif generator created out of a total of 100,000 entries 10,000 entries with >> duplicate objectclasses i.e. >> >> dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> cn: Al-BasiM >> sn: Al-Basi >> >> This ldif has been loaded by slapadd without any warnings. The only parameter >> applied where -l and -f. > > This is normal. slapadd doesn't do validation, you are expected to feed it > valid output from slapcat. This documented behavior has not changed in a decade. Let me add that in recent releases you can specify -o value-check=yes to enforce value checking (incurring in the related penalty). This would have revealed the error. p.

1 0

(ITS#6861) slapd and syncrepl performance problem
by jeff_wheeler67＠comcast.net 10 Mar '11

10 Mar '11

Full_Name: Jeff Wheeler Version: 2.4.20 OS: RHEL4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.103.136.179) Under ldapsearch/modify load of approximately 160 simultaneous sessions towards the First Master only, after several hours replication falls behind and searches and modifies that previously were <1 second now take 10 seconds+. We see also these messages continually every 5 seconds or so: Mar 10 04:02:05 auvhen2be01 slapd[29178]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Mar 10 04:02:05 auvhen2be01 slapd[29178]: conn=2249 op=13995: attribute "entryCSN" index add failure LDAP is configured in 2-way multi-master mirrormode on 2 Quad core HP blades with 72GB RAM each. Cache size set to 10GB, id2entry=18GB. The replication agreements are as such: olcSyncrepl: {0}rid=2 provider=ldap://auvhen4be05-traffic.vm.vodafone.net.au b indmethod=simple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=h 3gau" credentials="admin123" starttls=no filter="(objectclass=*)" searchbase= "o=h3gau" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" .. olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 .. Eventually, the syncrepl connection goes to TIME_WAIT state and replications stop. Restarting slapd does not fix and we have to reload from backup. We tuned the following and no longer does slapd repl connection go to TIME_WAIT, however it still falls hours behind on updates and performs slowly as before. Cache size set to 20GB, olcDbIDLcacheSize: 20000000000, olcThreads: 32 Restarting slapd results in the repl connection binding, searching, but then unbinds immediately: Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 ACCEPT from IP=10.176.77.23:50798 (IP=10.176.77.47:389) Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" method=128 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" mech=SIMPLE ssf=0 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 RESULT tag=97 err=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH base="o=h3gau" scope=2 deref=0 filter="(objectClass=*)" Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH attr=* + Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=2 UNBIND Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 closed

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by hyc＠symas.com 10 Mar '11

10 Mar '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Klünter > Version: 2.4.24 > OS: SLES11_x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.18.17) > > > A ldif generator created out of a total of 100,000 entries 10,000 entries with > duplicate objectclasses i.e. > > dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > cn: Al-BasiM > sn: Al-Basi > > This ldif has been loaded by slapadd without any warnings. The only parameter > applied where -l and -f. This is normal. slapadd doesn't do validation, you are expected to feed it valid output from slapcat. This documented behavior has not changed in a decade. Closing this ITS. -- -- 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#6860) slapadd accepts duplicate objectclasses
by dieter＠dkluenter.de 10 Mar '11

10 Mar '11

Full_Name: Dieter Klünter Version: 2.4.24 OS: SLES11_x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.18.17) A ldif generator created out of a total of 100,000 entries 10,000 entries with duplicate objectclasses i.e. dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Al-BasiM sn: Al-Basi This ldif has been loaded by slapadd without any warnings. The only parameter applied where -l and -f. -Dieter

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

--_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function. A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is m= y case, I could not find any definition or information on whether or not LD= AP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /************************************* * * * thread definitions for NT threads * * * *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long ldap_int_thread_t; typedef HANDLE ldap_int_thread_mutex_t; typedef HANDLE ldap_int_thread_cond_t; typedef DWORD ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \ ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi ----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org> Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24 To: "Vladi, Demian" <dvladi(a)websense.com> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6859. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6859) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6859) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6859 Please remember to retain your issue tracking number (ITS#6859) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. To report this as spam, please forward to spam(a)websense.com. Thank you. Protected by Websense Hosted Email Security -- www.websense.com=20 --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <style></style> </head> <body> <style>  </style> <div> You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function.<= br> A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is my case, I could not find any definition or = information on whether or not LDAP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /*************************************  *           &n= bsp;           &nbsp= ;           *  * thread definitions for NT threads *  *           &n= bsp;           &nbsp= ;           *  *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long   ldap_int_thread_t; typedef HANDLE  ldap_int_thread_mutex_t; typedef HANDLE  ldap_int_thread_cond_t; typedef DWORD   ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL        =      ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \             &nb= sp;   ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi <div id=3D"x_htc_header" style=3D"">----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org&g= t; Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24<= br> To: "Vladi, Demian" <dvladi(a)websense.com> </div> </div> <div class=3D"PlainText"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.  Your report has been assigned the tracking number ITS#6859. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.  They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.  Note that any mail sent to openldap-its(a)openldap.org with (ITS#6859) in the subject will automatically be attached to the issue report.         <a href=3D"mailto:openldap-its@o= penldap.org?subject=3D(ITS#6859">mailto:openldap-its@openldap.org?subject= =3D(ITS#6859</a>) You may follow the progress of this report by loading the following URL in a web browser:     <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid= =3D6859">http://www.OpenLDAP.org/its/index.cgi?findid=3D6859</a> Please remember to retain your issue tracking number (ITS#6859) on any further messages you send to us regarding this report.  If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported.         <a href=3D"http://www.OpenLDAP.o= rg/support/">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.  To report this as spam, please forward to spam(a)websense.com.  Th= ank you. </div> Protected by Websense Hosted Email Security &#8= 212; www.websense.com </body> </html> --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_--

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by hyc＠symas.com 09 Mar '11

09 Mar '11

dvladi(a)websense.com wrote: > Full_Name: Demian Vladi > Version: 2.4.24 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.15.64.155) > > > My program that uses openLdap fails to link for me due to unresolved > ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. > It looks like they were introduced in 2.4.24, but there is no definition or > declaration for them :( > You're mistaken, these definitions were introduced many years ago. Long before 2.4.24. Long before 2.3 even. Sounds like you're linking incorrectly. No bug here, this ITS will be closed. For help with usage questions please post on the openldap-technical mailing list. -- -- 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#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

Full_Name: Demian Vladi Version: 2.4.24 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.15.64.155) My program that uses openLdap fails to link for me due to unresolved ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. It looks like they were introduced in 2.4.24, but there is no definition or declaration for them :(

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 09 Mar '11

09 Mar '11

--On March 9, 2011 9:42:18 AM -0800 Howard Chu <hyc(a)symas.com> wrote: > Quanah Gibson-Mount wrote: >> >> >> --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >>> Tested, and working. Thanks for the fix. >> >> We're still seeing this happen sporadically with slapindex -q<attribute> >> >> i.e., reindexing a single attribute instead of the entire DB > > Can't reproduce it here, need a test case. It's hard to come up with one. We've only had this one instance on one machine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by hyc＠symas.com 09 Mar '11

09 Mar '11

Quanah Gibson-Mount wrote: > > > --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >> Tested, and working. Thanks for the fix. > > We're still seeing this happen sporadically with slapindex -q<attribute> > > i.e., reindexing a single attribute instead of the entire DB Can't reproduce it here, need a test case. -- -- 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#6461) back-sql quote characters in query
by hyc＠symas.com 09 Mar '11

09 Mar '11

atze_80(a)web.de wrote: > Can confirm this with openldap 2.4.24. Thanks, the bug was already confirmed. > > Using ldap search filters like this: > > (cn=blabla' or '1'='1) > > is at least causing my postgres to eat all CPU cycles it can get (LDAP > data is based on complex view). I do not have write access enabled for > that particular openLDAP installation, but I also assume that SQL > Injection is possible. Beside being an obviuos malfunction, this should > be considered a security issue. As the bug status says, "patches welcome." back-sql is not a priority for any of the core developers. -- -- 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#6858) segfault on schema modification in cn=config
by hyc＠symas.com 09 Mar '11

09 Mar '11

zerbe(a)phil.uni-duesseldorf.de wrote: > Full_Name: Sebastian Zerbe > Version: 2.4.23-7 > OS: Debian GNU/Linux 6.0 > URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz > Submission from: (NULL) (134.99.58.27) > > > Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the > given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D > cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with > kernel log entries like these: > > [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in > slapd[8048000+11b000] > [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in > slapd[8048000+11b000] > [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in > slapd[8048000+11b000] > > Further debugging is nearly impossible. If slapd is running in gdb it does not > crash (but the modifications do not take place either)... The crash has been fixed in HEAD, but your mod request will still fail because Delete is not supported for olcObjectIdentifier attributes. -- -- 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#6858) segfault on schema modification in cn=config
by zerbe＠phil.uni-duesseldorf.de 09 Mar '11

09 Mar '11

Full_Name: Sebastian Zerbe Version: 2.4.23-7 OS: Debian GNU/Linux 6.0 URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz Submission from: (NULL) (134.99.58.27) Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with kernel log entries like these: [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in slapd[8048000+11b000] [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in slapd[8048000+11b000] [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in slapd[8048000+11b000] Further debugging is nearly impossible. If slapd is running in gdb it does not crash (but the modifications do not take place either)...

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 08 Mar '11

08 Mar '11

--On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: > Tested, and working. Thanks for the fix. We're still seeing this happen sporadically with slapindex -q <attribute> i.e., reindexing a single attribute instead of the entire DB Thread 2 (Thread 0x96591ba0 (LWP 10652)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0xb776bf80, mutex=0xb776bf50) at thr_posix.c:277 No locals. #3 0xb77376f4 in bdb_tool_trickle_task (ctx=0x965912bc, ptr=0x82eb728) at tools.c:1242 env = 0x82eb728 wrote = -1208699249 #4 0xb7f4a33c in ldap_int_thread_pool_wrapper (xpool=0x81bda78) at tpool.c:685 pool = 0x81bda78 task = 0x82ee038 work_list = 0x81bdaf8 ctx = {ltu_id = 2522422176, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f9b049, ltk_free = 0xb7dcc732}, { ltk_key = 0x0, ltk_data = 0xb7fa7ff4, ltk_free = 0xb7bffd80}, {ltk_key = 0x0, ltk_data = 0x96591388, ltk_free = 0xb7f963d0 <do_lookup_x+640>}, {ltk_key = 0x0, ltk_data = 0xb7dcc75a, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0x69cb120}, {ltk_key = 0x0, ltk_data = 0xd696910, ltk_free = 0xe}, {ltk_key = 0x0, ltk_data = 0xb7a874a0, ltk_free = 0xb7a8ffe0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x2, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0xb7fa7ff4}, {ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0x96591428}, { ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0xb7fa8830}, {ltk_key = 0x0, ltk_data = 0xb7bf7dd8, ltk_free = 0x1}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f272a0, ltk_free = 0xb7dcb69d}, {ltk_key = 0x0, ltk_data = 0x1000000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7a8f000, ltk_free = 0xb7bf7508}, {ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0xb7f272a0}, {ltk_key = 0x0, ltk_data = 0xb7f9a24d, ltk_free = 0xb7f27448}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0x1}}} kctx = 0x0 i = 32 keyslot = 522 hash = 5777930 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0xb7dce35b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0xb7b43c0e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread 0xb7a826b0 (LWP 10610)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0x81bda94, mutex=0x81bda7c) at thr_posix.c:277 No locals. #3 0xb7f49fe7 in ldap_pvt_thread_pool_destroy (tpool=0xbf995780, run_pending=0) at tpool.c:582 pool = 0x81bda78 pptr = 0x81bda78 task = 0x0 #4 0xb7f49332 in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x81bda78 #5 0xb7f48aa0 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #6 0x080af918 in slap_destroy () at init.c:273 rc = 0 #7 0x080ff5f2 in slap_tool_destroy () at slapcommon.c:865 rc = 0 #8 0x080ffb9b in slapindex (argc=1, argv=0xbf9959bc) at slapindex.c:107 id = 4294967295 rc = 0 progname = 0x813ae0a "slapindex" ad = 0x8239440 adv = 0xbf9959bc __PRETTY_FUNCTION__ = "slapindex" #9 0x08057783 in main (argc=7, argv=0xbf9959a4) at main.c:403 i = 3 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = 0xbf9959a4 configfile = 0x0 configdir = 0x0 serverName = 0xbf997206 "slapindex" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x811c33f "" l = 134548137 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6461) back-sql quote characters in query
by atze_80＠web.de 08 Mar '11

08 Mar '11

Can confirm this with openldap 2.4.24. Using ldap search filters like this: (cn=blabla' or '1'='1) is at least causing my postgres to eat all CPU cycles it can get (LDAP data is based on complex view). I do not have write access enabled for that particular openLDAP installation, but I also assume that SQL Injection is possible. Beside being an obviuos malfunction, this should be considered a security issue. atze

1 0

Re: (ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by hyc＠symas.com 07 Mar '11

07 Mar '11

requate(a)univention.de wrote: > Full_Name: Arvid Requate > Version: 2.4.23 > OS: Debian Lenny > URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… > Submission from: (NULL) (82.198.197.8) > > > With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race > condition that can be triggered by concurrent ldapdelete and search_s > operations. > Though a bit simmilar, this condition does no quite match the details of > ITS#5707. The URL provides a tar archive containing three gdb traces and > corresponding slapd log output (loglevel: trace args stats) of three cases of > lockup, where slapd hangs consuming 100% of CPU after a couple of modifications > with the shell script contained in the tar archive and remains unresponsive > until restartet.The number of successful operations varies between the test > runs. > > Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 > and #16541 and configure options "--enable-posixmutexes > --with-mutex=POSIX/pthreads". > > The test machine is a single processor/single core 686 VM running Linux 2.6.32 > 686 bigmem. The concurrent searches are performed by a separate process that > gets informed about ldap modifications (via file) by an slapd overlay module > called 'translog'. To me the traces do not seem to indicate a problem in the > overlay code (i.e. there is no reference to the on_response function > "translog_response" in the traces). > > Maybe there is some obvious point here we are missing? More debug details can be > provided if necessary. Try again using 2.4.24. There was a bug with back-bdb delete fixed recently (ITS#6577) so the relevant code has changed since .23. Also try a newer BerkeleyDB. We've had other deadlocks with 4.7 that no longer occur in 4.8. -- -- 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#6857) chain overlay change FLAGS of underlying database
by rhafer＠suse.de 07 Mar '11

07 Mar '11

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.38.247) The chain-overlay adds SLAP_DBFLAG_NOLASTMOD to the flags of the database for which chaining is to be configured. Example: -------------------- database hdb suffix o=test rootdn o=test rootpw secret directory /tmp/ldap overlay chain chain-return-error TRUE chain-uri ldap://ldap.server ------------------- With the above configuration slapd will no longer maintain the "modifyTimeStamp", "modifiersName", etc. Attributes for write operations to the "o=test" database anymore. Note: This bug is only present when using a slapd.conf base configuration. Fix is almost ready.

1 0

(ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by requate＠univention.de 07 Mar '11

07 Mar '11

Full_Name: Arvid Requate Version: 2.4.23 OS: Debian Lenny URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_4.… Submission from: (NULL) (82.198.197.8) With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race condition that can be triggered by concurrent ldapdelete and search_s operations. Though a bit simmilar, this condition does no quite match the details of ITS#5707. The URL provides a tar archive containing three gdb traces and corresponding slapd log output (loglevel: trace args stats) of three cases of lockup, where slapd hangs consuming 100% of CPU after a couple of modifications with the shell script contained in the tar archive and remains unresponsive until restartet.The number of successful operations varies between the test runs. Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415 and #16541 and configure options "--enable-posixmutexes --with-mutex=POSIX/pthreads". The test machine is a single processor/single core 686 VM running Linux 2.6.32 686 bigmem. The concurrent searches are performed by a separate process that gets informed about ldap modifications (via file) by an slapd overlay module called 'translog'. To me the traces do not seem to indicate a problem in the overlay code (i.e. there is no reference to the on_response function "translog_response" in the traces). Maybe there is some obvious point here we are missing? More debug details can be provided if necessary.

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by apm＠one.com 07 Mar '11

07 Mar '11

I see this symptom too with both these versions: OpenLDAP 2.4.21, BDB 4.8.26 OpenLDAP 2.4.23, BDB 4.8.30 ldapdelete -r failes with: ldap_delete: Other (e.g., implementation specific) error (80) additional info: DN index delete failed I've copied the database files to a similar machine for debugging. Here's the output for slapd -d1 when doing so: ============================================================= do_bind: SASL/EXTERNAL bind: dn="cn=config" sasl_ssf=0 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 <== slap_sasl_bind: rc=0 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 86 contents: op tag 0x63, time 1299502775 ber_get_next conn=1001 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: => bdb_search bdb_dn2entry("o=xxx,dc=example,dc=com") search_candidates: base="o=xxx,dc=example,dc=com" (0x0025d3ca) scope=1 => bdb_dn2idl("o=xxx,dc=example,dc=com") <= bdb_dn2idl: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) bdb_search_candidates: failed (rc=-30988) bdb_search: no candidates send_ldap_result: conn=1001 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 49 contents: op tag 0x4a, time 1299502775 ber_get_next conn=1001 op=2 do_delete ber_scanf fmt (m) ber: >>> dnPrettyNormal: <o=xxx,dc=example,dc=com> <<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com> bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_dn2entry("o=xxx,dc=example,dc=com") bdb_entry_get: rc=0 bdb_dn2entry("o=xxx,dc=example,dc=com") => bdb_dn2id_delete 0x25d3ca: "o=xxx,dc=example,dc=com" => bdb_idl_delete_key: c_get lo failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) => bdb_dn2id_delete 0x25d3ca: subtree (o=xxx,dc=example,dc=com) delete failed: -30999 <= bdb_dn2id_delete 0x25d3ca: -30999 <=- bdb_delete: dn2id failed: DB_BUFFER_SMALL: User memory too small for return value (-30999) send_ldap_result: conn=1001 op=2 p=3 send_ldap_response: msgid=3 tag=107 err=80 ber_flush2: 36 bytes to sd 11 connection_get(11): got connid=1001 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1299502775 ber_get_next ber_get_next on fd 11 failed errno=0 (Success) conn=1001 op=3 do_unbind connection_get(11): got connid=1001 connection_get(11): got connid=1001 connection_close: conn=1001 sd=11 ============================================================================= Doing an ldapsearch for the entry takes some time, but does finish. Looking at the -d1 output there's a lot of "bdb_search: <number> scope not okay" messages. There's about 5 million objects in the database. I only know of this one object on this server which has this problem. I have another server with another object with the same problem. Other objects can be deleted just fine. Looking at the slapcat output, there's only the base "o=xxx" object. There's no subordinate objects to this object. /Peter

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 07 Mar '11

07 Mar '11

Hi, Le Ven 4 mars 2011 23:02, hyc(a)symas.com a écrit : > raphael.ouazana(a)linagora.com wrote: >> Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a ?crit : >>> >>>> The following patch >>> >>> Please upload patches according to >>> <http://www.openldap.org/devel/contributing.html#submitting>. >> >> Sorry, it seems to be my fault. Here it is: >> ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort… > > Thanks for the patch. While you're at it, would you be able to create a > test > script for sssvlv to use in our test suite? Sorry, no time for that for the moment. Furthermore I don't think this bug is reproducible with current OpenLDAP client tools. Regards, Raphaël Ouazana.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 04 Mar '11

04 Mar '11

On 03/04/2011 05:56 PM, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: >>> This indicates that the trickle task is still waiting for a signal on its >>> condition variable. Which is a bit odd since bdb_tool_entry_close() already >>> signals it before slap_tool_destroy() is called. >>> >>> It might be illuminating to run slapadd under gdb with a breakpoint on >>> bdb_tool_entry_close(), and singlestep through the first few lines of that >>> function where it issues the signal, and see if the trickle task actually >>> reacts or not. >> >> Setting a breakpoint on bdb_tool_entry_close() and then either >> continuing or stepping through the function allows slapadd to exit cleanly. > > A fix for this is now in HEAD, please test. > back-bdb/tools.c 1.140 > Tested, and working. Thanks for the fix.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 04 Mar '11

04 Mar '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2.40.14.92) >>> Submitted by: ando >>> >>> >>> When idassert-bind is configured to use SASL bind, an "authcID" needs to >>> be >>> provided, while the "binddn" is not needed. However, if a "binddn" is >>> not >>> provided as well, in some cases the proxiedAuthz control may be used >>> incorrectly. The need to configure the "binddn" is not documented, so >>> this ITS >>> is minimally addressed by documenting this requirement. >> >> I tripped over this change while investigating #6711. Adding this >> requirement >> is certainly not the right solution; SASL Binds ordinarily don't require a >> BindDN and requiring it here just makes things confusing. > > I understand the fix I'm suggesting can sound counter-intuitive. The > documentation should clearly indicate that the binddn in case of SASL is > for *local* and *internal* issues, and will not be part of the > authentication process. As an alternative, lc_bound_ndn could receive a > dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive > the actual identity from the remote server using the authid control along > with the bind or performing a whoami extop later, as already implemented). Using a dummy DN here sounds OK. -- -- 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#6855) Suggested improvements to OpenLDAP Admin Guide preface
by hyc＠symas.com 04 Mar '11

04 Mar '11

gerv(a)mozilla.org wrote: > Full_Name: Gervase Markham > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.45.122.200) > > > Following a discussion on the mailing list, I submit the following as a > suggestion for improvement to the Preface of the Admin Guide, to make it clear > that there are other documentation resources which should be read. Thanks. I've committed some of this suggestion to CVS HEAD. I would expect an experienced sysadmin to already know which manpage sections are relevant, and I don't believe a sysadmin needs to read the API documentation. > <snip> > This document is not a complete guide to its subject matter; the man pages are > the definitive documentation for OpenLDAP software. For best results, you should > use those installed on your system, which will match your version of OpenLDAP. > But they are also available on the web from the following links: > > OpenLDAP API: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> > </ul> > > OpenLDAP configuration: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> > </ul> > > OpenLDAP command line tools: > > <ul> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> > <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) > </ul> > > Gerv > -- -- 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#6853) slapadd/slapindex -q hang
by hyc＠symas.com 04 Mar '11

04 Mar '11

dhawes(a)vt.edu wrote: > On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: >> This indicates that the trickle task is still waiting for a signal on its >> condition variable. Which is a bit odd since bdb_tool_entry_close() already >> signals it before slap_tool_destroy() is called. >> >> It might be illuminating to run slapadd under gdb with a breakpoint on >> bdb_tool_entry_close(), and singlestep through the first few lines of that >> function where it issues the signal, and see if the trickle task actually >> reacts or not. > > Setting a breakpoint on bdb_tool_entry_close() and then either > continuing or stepping through the function allows slapadd to exit cleanly. A fix for this is now in HEAD, please test. back-bdb/tools.c 1.140 -- -- 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#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 04 Mar '11

04 Mar '11

On 03/04/2011 04:08 PM, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message "Closing >>>> DB..." is printed and then the application hangs indefinitely. Removing >>>> the -q option allows the application to complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, >> ptr=<value optimized out>) at tools.c:1253 >> #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> #4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> #5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() already > signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of that > function where it issues the signal, and see if the trickle task actually > reacts or not. Setting a breakpoint on bdb_tool_entry_close() and then either continuing or stepping through the function allows slapadd to exit cleanly.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 04 Mar '11

04 Mar '11

--On Friday, March 04, 2011 9:08 PM +0000 hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message >>>> "Closing DB..." is printed and then the application hangs >>>> indefinitely. Removing the -q option allows the application to >>>> complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1253 >> # 2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> # 3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> # 4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> # 5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() > already signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of > that function where it issues the signal, and see if the trickle task > actually reacts or not. > >> Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x0000000000506223 in ldap_pvt_thread_pool_destroy >> (tpool=0x7ffffffed658, >> run_pending=<value optimized out>) at tpool.c:582 >> # 2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at >> # tpool.c:181 3 0x00000000005050a9 in ldap_pvt_thread_destroy () at >> # threads.c:70 4 0x0000000000466059 in slap_destroy () at init.c:273 >> # 5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 >> # 6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) >> at slapadd.c:606 >> # 7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at >> # main.c:407 We are seeing numerous reports of this occurring with Zimbra after using OpenLDAP 2.4.23 + the multi-core fix (ITS#6660) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by hyc＠symas.com 04 Mar '11

04 Mar '11

raphael.ouazana(a)linagora.com wrote: > Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a écrit : >> >>> The following patch >> >> Please upload patches according to >> <http://www.openldap.org/devel/contributing.html#submitting>. > > Sorry, it seems to be my fault. Here it is: > ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort… Thanks for the patch. While you're at it, would you be able to create a test script for sssvlv to use in our test suite? -- -- 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#6853) slapadd/slapindex -q hang
by hyc＠symas.com 04 Mar '11

04 Mar '11

dhawes(a)vt.edu wrote: > On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: >> >>> Full_Name: David Hawes >>> Version: 2.4.24 >>> OS: Ubuntu 10.04 >>> URL: >>> Submission from: (NULL) (128.173.39.26) >>> >>> >>> When using slapadd or slapindex with the -q option, the message "Closing >>> DB..." is printed and then the application hangs indefinitely. Removing >>> the -q option allows the application to complete without issue. >>> >>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >> >> I would ask you provide a full backtrace of the slapadd process after it >> has hung. Otherwise, this report isn't of much use. >> >> Also, if you are using the Ubuntu patches for OpenLDAP with your >> OpenLDAP build, you are including a known database-corrupting patch. >> Since you don't say how you built OpenLDAP, it is impossible for us to >> know if you did this or not. > > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): > > (gdb) thread apply all bt > > Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1253 > #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( > xpool=<value optimized out>) at tpool.c:685 > #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 > #4 0x00007ffff677970d in clone () from /lib/libc.so.6 > #5 0x0000000000000000 in ?? () This indicates that the trickle task is still waiting for a signal on its condition variable. Which is a bit odd since bdb_tool_entry_close() already signals it before slap_tool_destroy() is called. It might be illuminating to run slapadd under gdb with a breakpoint on bdb_tool_entry_close(), and singlestep through the first few lines of that function where it issues the signal, and see if the trickle task actually reacts or not. > Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy > (tpool=0x7ffffffed658, > run_pending=<value optimized out>) at tpool.c:582 > #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 > #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 > #4 0x0000000000466059 in slap_destroy () at init.c:273 > #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 > #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) > at slapadd.c:606 > #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 -- -- 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#6854) When login from one application, "error=49" error show up, but other application's login are all right.
by quanah＠zimbra.com 04 Mar '11

04 Mar '11

--On Friday, March 04, 2011 11:01 AM +0000 mahaoboy(a)gmail.com wrote: > Full_Name: hao ma > Version: 2.3.43 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.161.106.50) > > > We have configured Openldap as our user info repository for all our > applications.(include Atlassian JIRA,Confluence,Fisheye,Crowd). Usage questions should be directed to openldap-technical(a)openldap.org. The ITS system is for reporting bugs only. I would also note that OpenLDAP 2.3 is no longer supported, so bug reports for that release will be ignored. OpenLDAP 2.4.23 is the current stable release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6855) Suggested improvements to OpenLDAP Admin Guide preface
by gerv＠mozilla.org 04 Mar '11

04 Mar '11

Full_Name: Gervase Markham Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.45.122.200) Following a discussion on the mailing list, I submit the following as a suggestion for improvement to the Preface of the Admin Guide, to make it clear that there are other documentation resources which should be read. <snip> This document is not a complete guide to its subject matter; the man pages are the definitive documentation for OpenLDAP software. For best results, you should use those installed on your system, which will match your version of OpenLDAP. But they are also available on the web from the following links: OpenLDAP API: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> </ul> OpenLDAP configuration: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> </ul> OpenLDAP command line tools: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) </ul> Gerv

1 0

(ITS#6854) When login from one application, "error=49" error show up, but other application's login are all right.
by mahaoboy＠gmail.com 04 Mar '11

04 Mar '11

Full_Name: hao ma Version: 2.3.43 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.161.106.50) We have configured Openldap as our user info repository for all our applications.(include Atlassian JIRA,Confluence,Fisheye,Crowd). Then we met an very strange user. This user can logged in confluence successfully, but when could not log in fisheye. And in a little chance, he could log in fisheye correctly. Firstly , we try to find problem from these applications. And all clue point to Openldap server. So we configure Openldap Loglever as -1. And we recorded two different log of logging in confluence and logging in fisheye. Log of confluence logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search daemon: activity on 1 descriptor >>> dnPrettyNormal: <ou=eejira,o=nsn> daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter daemon: epoll: listen=8 active_threads=0 tvp=NULL AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8052 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8052 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8052 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8053 tag=101 err=0 conn=5 op=8052 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=8 fd=20 ACCEPT from IP=87.254.208.143:42569 (IP=0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=8 connection_read(20): checking for input on id=8 do_bind >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=8 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) conn=8 op=0 BIND dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=jirasupport,ou=people,ou=eejira,o=nsn" to "cn=jirasupport,ou=People,ou=eejira,o=nsn" send_ldap_result: conn=8 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 conn=8 op=0 RESULT tag=97 err=0 text= daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL Log of fisheye logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search >>> dnPrettyNormal: <ou=eejira,o=nsn> <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8051 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 entry_decode: "cn=jirasupport,ou=People,ou=eejira,o=nsn" <= entry_decode(cn=jirasupport,ou=People,ou=eejira,o=nsn) => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8051 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8051 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8052 tag=101 err=0 conn=5 op=8051 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=7 fd=20 ACCEPT from IP=87.254.208.143:39622 (IP=0.0.0.0:389) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 do_bind daemon: activity on 1 descriptor daemon: activity on: >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=7 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") daemon: epoll: listen=7 active_threads=0 tvp=NULL => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested daemon: epoll: listen=8 active_threads=0 tvp=NULL => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) send_ldap_result: conn=7 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 conn=7 op=0 RESULT tag=97 err=49 text= daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 ber_get_next on fd 20 failed errno=0 (Success) connection_read(20): input error=-2 id=7, closing. connection_closing: readying conn=7 sd=20 for close connection_close: conn=7 sd=-1 daemon: removing 20 conn=7 fd=20 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL And other users are all right for logging in all applications. Do you have any advice for this problem? Thanks a lot.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 8:50 PM +0000 dhawes(a)vt.edu wrote: > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): My personal experience with gcc & openldap is that building an optimized version of OpenLDAP is an extremely bad idea, as gcc makes very bad choices. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 03 Mar '11

03 Mar '11

On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: > --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: > >> Full_Name: David Hawes >> Version: 2.4.24 >> OS: Ubuntu 10.04 >> URL: >> Submission from: (NULL) (128.173.39.26) >> >> >> When using slapadd or slapindex with the -q option, the message "Closing >> DB..." is printed and then the application hangs indefinitely. Removing >> the -q option allows the application to complete without issue. >> >> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. > > I would ask you provide a full backtrace of the slapadd process after it > has hung. Otherwise, this report isn't of much use. > > Also, if you are using the Ubuntu patches for OpenLDAP with your > OpenLDAP build, you are including a known database-corrupting patch. > Since you don't say how you built OpenLDAP, it is impossible for us to > know if you did this or not. Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu packages or code is used. Backtraces (I may need to recompile without optimization): (gdb) thread apply all bt Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff677970d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 #4 0x0000000000466059 in slap_destroy () at init.c:273 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 (gdb) thread apply all bt full Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 env = 0x886270 wrote = 0 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 pool = 0x844f00 task = 0x89dc30 work_list = <value optimized out> ctx = {ltu_id = 140732807526144, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdbc08, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0xa8428197, ltk_free = 0x7ffff7de7457}, {ltk_key = 0x0, ltk_data = 0x2a10a06, ltk_free = 0x17}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7fda0f0, ltk_free = 0x7ffff7fdb4c0}, { ltk_key = 0x0, ltk_data = 0x7ffff66a3660, ltk_free = 0x7ffff7631f50}, {ltk_key = 0x0, ltk_data = 0x1000003bb, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd868, ltk_free = 0x7ffee9002e10}, { ltk_key = 0x0, ltk_data = 0x7ffee9002e38, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7de7722, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd510, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9002dc0, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7633cef}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0x7ffff7fdb4c0}, {ltk_key = 0x0, ltk_data = 0xffffffff, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x218050, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9003700, ltk_free = 0x7ffff7631000}, { ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7638ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x800000 <hbuf+48096>}, { ltk_key = 0x0, ltk_data = 0x7ffff7df2325, ltk_free = 0x7ffee9003700}}} kctx = <value optimized out> keyslot = 285 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff677970d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 pool = 0x844f00 pptr = 0x844f00 task = <value optimized out> #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x844f00 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #4 0x0000000000466059 in slap_destroy () at init.c:273 rc = 0 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 rc = 0 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 buf = 0x89de00 "\240Љ" text = 0x0 textbuf = '\000' <repeats 255 times> maxcsn = {{bv_len = 0, bv_val = 0x0} <repeats 3928 times>, { bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7fffffffddc0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a0fb40 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0xffffffffa2000000 <Address 0xffffffffa2000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdb000 ""}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, { bv_len = 140737488343856, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737488346672, bv_val = 0x7 <Address 0x7 out of bounds>}, { bv_len = 140737353992808, bv_val = 0x7ffff7dea64d "H\213\205p\377\377\377\213\215\370\376\377\377L\213\205"}, {bv_len = 140737354127792, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6c2be00 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb000 ""}, {bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 140737488343856, bv_val = 0xffffffffa4000000 <Address 0xffffffffa4000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7de3dae "H\203\370\377\017\205a\373\377\377L\215\r\360>\001"}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdca68 ""}, {bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 140737488344096, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6c2bf70 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdca68 ""}, { bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, { bv_len = 140737488344096, bv_val = 0xffffffffa5e00000 <Address 0xffffffffa5e00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x218a88 <Address 0x218a88 out of bounds>}, { bv_len = 86016, bv_val = 0x3 <Address 0x3 out of bounds>}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc508 ""}, { bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, { bv_len = 140737488344336, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6fa2738 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353990144, bv_val = 0x7ffff7fdb4c0 ""}, { bv_len = 0, bv_val = 0x7ffff7fdc508 ""}, {bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 140737488344336, bv_val = 0xffffffffa7c00000 <Address 0xffffffffa7c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x1 <Address 0x1 out of bounds>}, {bv_len = 0, bv_val = 0x7ffff7de3bf5 "\366E\020\bu\016H\203\273\300"}, { bv_len = 8030813564919442479, bv_val = 0x7fffff00362e <Address 0x7fffff00362e out of bounds>}, { bv_len = 140737354129704, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7ffff720cee0 ""}, { bv_len = 140737353988792, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353992808, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0xffffffffa9c00000 <Address 0xffffffffa9c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x4d6fb0ac <Address 0x4d6fb0ac out of bounds>}, { bv_len = 331622242, bv_val = 0x4d3a077c <Address 0x4d3a077c out of bounds>}, { bv_len = 0, bv_val = 0x4d488e48 <Address 0x4d488e48 out of bounds>}, { bv_len = 530906511, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7415f40 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x7ffff7ffd9b0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 4294967296, bv_val = 0x7ffff762fc90 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0xffffffffabe00000 <Address 0xffffffffabe00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x0}, {bv_len = 832, bv_val = 0x10102464c457f <Address 0x10102464c457f out of bounds>}, {bv_len = 0, bv_val = 0x1003e0003 <Address 0x1003e0003 out of bounds>}, { bv_len = 126304, bv_val = 0x40 <Address 0x40 out of bounds>}, { bv_len = 1567688, bv_val = 0x38004000000000 <Address 0x38004000000000 out of bounds>}, {bv_len = 19703553316618250, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdd510 ""}, { bv_len = 1, bv_val = 0x7ffff7634dce "ld-linux-x86-64.so.2"}, { bv_len = 140737488345152, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff762fde0 ""}} sid = <value optimized out> bvtext = {bv_len = 256, bv_val = 0x7fffffffdd30 ""} attr = 0x0 ctxcsn_e = 0x0 ctxcsn_id = <value optimized out> id = <value optimized out> opbuf = {ob_op = {o_hdr = 0x7fffffffd9e0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x86ff40, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = { bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = { rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = { rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = { oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>}, ob_controls = { 0x0 <repeats 32 times>}} match = 32767 checkvals = 0 lineno = 7 nextline = 7 ldifrc = <value optimized out> lmax = 4115 rc = 0 enable_meter = 1 meter = {display = 0x589b80, display_data = 0x0, estimator = 0x589ba0, estimator_data = 0x0, start_time = 1299184379.2546861, last_update = 1299184379.2546861, goal_value = 88, last_position = 0} stat_buf = {st_dev = 21, st_ino = 6956686, st_nlink = 1, st_mode = 33188, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 88, st_blksize = 4096, st_blocks = 24, st_atim = {tv_sec = 1299166918, tv_nsec = 420393930}, st_mtim = { tv_sec = 1299166819, tv_nsec = 830383674}, st_ctim = { tv_sec = 1299166819, tv_nsec = 870399305}, __unused = {0, 0, 0}} __PRETTY_FUNCTION__ = "slapadd" #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 i = <value optimized out> no_detach = 32767 rc = 1 urls = <value optimized out> username = 0x374208 <Address 0x374208 out of bounds> groupname = 0x1 <Address 0x1 out of bounds> sandbox = 0x7fffffffdf1f "" syslogUser = 160 configfile = 0x4131e9 "__libc_start_main" configdir = 0xbf <Address 0xbf out of bounds> serverName = 0x7fffffffe380 "slapadd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 slapd_pid_file_unlink = <value optimized out> slapd_args_file_unlink = <value optimized out> firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.24 > OS: Ubuntu 10.04 > URL: > Submission from: (NULL) (128.173.39.26) > > > When using slapadd or slapindex with the -q option, the message "Closing > DB..." is printed and then the application hangs indefinitely. Removing > the -q option allows the application to complete without issue. > > This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. I would ask you provide a full backtrace of the slapadd process after it has hung. Otherwise, this report isn't of much use. Also, if you are using the Ubuntu patches for OpenLDAP with your OpenLDAP build, you are including a known database-corrupting patch. Since you don't say how you built OpenLDAP, it is impossible for us to know if you did this or not. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 03 Mar '11

03 Mar '11

Full_Name: David Hawes Version: 2.4.24 OS: Ubuntu 10.04 URL: Submission from: (NULL) (128.173.39.26) When using slapadd or slapindex with the -q option, the message "Closing DB..." is printed and then the application hangs indefinitely. Removing the -q option allows the application to complete without issue. This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. slapd.conf: ===== include /usr/local/openldap-2.4.24/etc/openldap/schema/core.schema pidfile /usr/local/openldap-2.4.24/var/run/slapd.pid argsfile /usr/local/openldap-2.4.24/var/run/slapd.args database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" directory /usr/local/openldap-2.4.24/var/openldap-data dbconfig set_lg_dir /usr/local/openldap-2.4.24/var/openldap-data/bdb-logs dbconfig set_lg_max 104857600 dbconfig set_lg_bsize 26214400 dbconfig set_cachesize 4 0 1 dbconfig set_flags DB_LOG_AUTOREMOVE ===== ldif: dn: dc=test,dc=com objectClass: dcObject objectClass: organization o: testorg dc: test

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 03 Mar '11

03 Mar '11

Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. Sorry, it seems to be my fault. Here it is: ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort…

1 0

Re: (ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Patch against current HEAD for this: Index: ./servers/slapd/schema_prep.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/schema_prep.c,v retrieving revision 1.189 diff -u -r1.189 schema_prep.c --- ./servers/slapd/schema_prep.c 4 Jan 2011 23:43:16 -0000 1.189 +++ ./servers/slapd/schema_prep.c 3 Mar 2011 11:25:59 -0000 @@ -934,6 +934,7 @@ "DESC 'RFC2307: An integer uniquely identifying a user " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL, @@ -944,6 +945,7 @@ "DESC 'RFC2307: An integer uniquely identifying a group " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL,

1 0

(ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.153.202.193) Please add ORDERING integerOrderingMatch to the declarations of attribute types uidNumber and gidNumber in schema_prep.c.

1 0

(ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 02 Mar '11

02 Mar '11

Full_Name: Ted C. Cheng Version: HEAD OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.80.56.88) We encountered a back-ldap assertion failure with the back-ldap as a proxy to a remote Active Directory on Windows 2003 R2. The assertion failure occurred when the slapd server was checking ACLs via the rwm overlay. Snippet of the stack trace: Thread 1 (Thread 32267): .... #2 0x0000003c354296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x00002ac57daaf6c1 in ldap_back_dobind_int (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_GETCONN, retries=0, dolock=1) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1389 #4 0x00002ac57daafda0 in ldap_back_dobind (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_DONTSEND) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1572 #5 0x00002ac57daac7a7 in ldap_back_entry_get (op=0x42f702f0, ndn=0x42f701d0, oc=0x0, at=0x135ad370, rw=0, ent=0x42f70a58) Analysis of the assertion failure: The ldap_back_entry_get() function, back-ldap/search.c, is called for ACL entries, via rwm overlay. The function sets op->o_do_not_cache to 1 before calling into ldap_back_dobind(): /* Tell getconn this is a privileged op */ do_not_cache = op->o_do_not_cache; tag = op->o_tag; /* do not cache */ op->o_do_not_cache = 1; /* ldap_back_entry_get() is an entry lookup, so it does not need * to know what the entry is being looked up for */ op->o_tag = LDAP_REQ_SEARCH; rc = ldap_back_dobind( &lc, op, &rs, LDAP_BACK_DONTSEND ); The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. ldap_back_dobind_int() { ... if (sendok & LDAP_BACK_GETCONN) { lc = ldap_back_getconn(op, rs, sendoff, &binddn, &bindcred); ... } if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); /* ldap_back_is_proxy_authz always returns 0 when op->o_do_not_cache is set, see below */ assert( rc == 1 );------> assertion failure } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); } } When the op->o_do_not_cache flag is set, the ldap_back_is_proxy_authz() function always returns 0. ldap_back_is_proxy_authz( ... ) { ... int dobind = 0; if ( op->o_conn == NULL || op->o_do_not_cache ) { goto done; } ... done:; return dobind; <--- always returns 0 } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Hi, Le Mer 2 mars 2011 17:51, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. As said in the post, no success: $ ftp ftp> open ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:raphael): ftp 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ascii 200 Type set to A. ftp> cd incoming 250 CWD command successful. ftp> put raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch local: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch remote: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> Regards, Raphael Ouazana.

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> The following patch Please upload patches according to <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

(ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, sssvlv support for multiple requests by conn (see ITS#6686) can segfault while releasing some connections. Indeed, the request to release can be searched by the ps_cookie. But as the ps_cookie is NULL at the end of the request (it points to so_tree), the same request can be freed multiple times. The following patch fix this issue and reinforce the rest of the code by using so to search for the matching request where it is possible. Sorry, no FTP upload, I get an error 425. It fixes a little error in the man page too. Index: doc/man/man5/slapo-sssvlv.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapo-sssvlv.5,v retrieving revision 1.4 diff -u -r1.4 slapo-sssvlv.5 --- doc/man/man5/slapo-sssvlv.5 4 Jan 2011 23:42:55 -0000 1.4 +++ doc/man/man5/slapo-sssvlv.5 2 Mar 2011 16:40:57 -0000 @@ -17,8 +17,8 @@ Since a complete result set must be generated in memory before sorting can be performed, processing sort requests can have a large impact on the server's memory use. As such, any connection is limited to having only -one sort request active at a time. Additional limits may be configured -as described below. +a limited number of sorts requests active at a time. Additional limits may +be configured as described below. .SH CONFIGURATION These Index: servers/slapd/overlays/sssvlv.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/sssvlv.c,v retrieving revision 1.29 diff -u -r1.29 sssvlv.c --- servers/slapd/overlays/sssvlv.c 4 Jan 2011 23:43:32 -0000 1.29 +++ servers/slapd/overlays/sssvlv.c 2 Mar 2011 16:40:58 -0000 @@ -342,6 +342,23 @@ } /* Return the session id or -1 if unknown */ +static int find_session_by_so( + int svi_max_percon, + int conn_id, + sort_op *so ) +{ + int sess_id; + if (so == NULL) { + return -1; + } + for (sess_id = 0; sess_id < svi_max_percon; sess_id++) { + if ( sort_conns[conn_id] && sort_conns[conn_id][sess_id] == so ) + return sess_id; + } + return -1; +} + +/* Return the session id or -1 if unknown */ static int find_session_by_context( int svi_max_percon, int conn_id, @@ -379,14 +396,13 @@ static void free_sort_op( Connection *conn, sort_op *so ) { int sess_id; - PagedResultsCookie ps_cookie = (PagedResultsCookie) so->so_tree; if ( so->so_tree ) { tavl_free( so->so_tree, ch_free ); so->so_tree = NULL; } ldap_pvt_thread_mutex_lock( &sort_conns_mutex ); - sess_id = find_session_by_context( so->so_info->svi_max_percon, conn->c_conn_idx, so->so_vcontext, ps_cookie ); + sess_id = find_session_by_so( so->so_info->svi_max_percon, conn->c_conn_idx, so ); sort_conns[conn->c_conn_idx][sess_id] = NULL; so->so_info->svi_num--; ldap_pvt_thread_mutex_unlock( &sort_conns_mutex ); @@ -492,7 +508,7 @@ sc->sc_nkeys * sizeof(struct berval), op->o_tmpmemctx ); sn->sn_vals = (struct berval *)(sn+1); sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, vc->vc_context, NO_PS_COOKIE ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); sn->sn_vals[0] = bv; for (i=1; i<sc->sc_nkeys; i++) { BER_BVZERO( &sn->sn_vals[i] ); @@ -731,7 +747,7 @@ op->o_tmpfree( sn, op->o_tmpmemctx ); sn = sn2; sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so->so_vcontext, (PagedResultsCookie) so->so_tree ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); /* Insert into the AVL tree */ tavl_insert(&(so->so_tree), sn, node_insert, avl_dup_error); Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2011 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme 02 Mar '11

02 Mar '11

Hi all, Platform is Sun Solaris x64 10 u8. Compiler used is Sun Studio 12u1. Version is openldap-2.4.23-stable-20100719. Configure was done with CFLAGS='-xO3 -KPIC -m64 -xtarget=generic' and CC="/usr/bin/cc" $ ./configure --prefix=/opt/app/damp64 --with-pic --with-tls=openssl Compilation in 64-bit (-m64) of libldap was succesfull and installed in /opt/app/damp64/lib. If I create a simple main.c file: int main(){ return 0; } I compile (also 64-bit) and link this main.c file with libldap as a test. $ /usr/bin/cc -o conftest -xO4 -m64 -KPIC -xtarget=generic -s -I/opt/app/damp64/include -L/opt/app/damp64/lib -R/opt/app/damp64/lib main.c -lldap When I try to run this exec linked to the newly build library libldap.so I get the following error: # ./conftest ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/app/damp64/lib/libldap-2.4.so.2: symbol (unknown): value 0xfffffd7fff2542f0 does not fit This is a relocation error from the linker on the libldap. But I compiled everything with -KPIC (position independent code) and gave the --with-pic option to configure. This is a serious issue, as I cannot link the library to anything else and thus it is unusable. Can I file a bug report? If I have a look in the libldap shared object, I can see .text relocations... # elfdump -d /opt/app/damp64/lib/libldap-2.4.so.2 | fgrep TEXTREL [18] TEXTREL 0 [27] FLAGS 0x4 [ TEXTREL ] Kind regards, Kristof Van Damme.

1 1

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon > > > > $ ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ > buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools > (LDAP library: OpenLDAP 20423) > ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Fixed in HEAD. Tools will refuse to start if incompatible password options are passed. I chose this solution since handling of credentials is security-related, and one would not want credentials to be handled incorrectly by a misused client. Please test. p.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. I understand the fix I'm suggesting can sound counter-intuitive. The documentation should clearly indicate that the binddn in case of SASL is for *local* and *internal* issues, and will not be part of the authentication process. As an alternative, lc_bound_ndn could receive a dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive the actual identity from the remote server using the authid control along with the bind or performing a whoami extop later, as already implemented). p. > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. > >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- 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#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. > > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. At the time I looked at this issue, there were places in the code where after an idassert-bind the lc_bound_ndn would receive a copy of idassert's authcDN. In case of SASL, this is empty/null; then back-ldap (and meta) would fail from recognizing the connection as successfully bound. I understand there are better solutions; for example, ldapconn_t could have a "bound" flag, or so. I understand that code may need some reworking, but I can't work at that now, sorry. p. >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- 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#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon You're passing both -W and -w, which are mutually exclusive. p.

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org 01 Mar '11

01 Mar '11

----- Original Message ----- > --GRPZ8SYKNexpdSJ7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > > > re: TLS Authentication Identity Format > > > > Strictly speaking, the order of components is not changed at all. > > The sequence of RDNs in the DN is what it is; just that the > > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > > the wording here will confuse people into thinking that the > > *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. > > Andrew Thanks for all this Andrew, much appreciated! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com 01 Mar '11

01 Mar '11

Full_Name: plop Version: OS: ubuntu last release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.206.236.129) This is what I got on a CLI: ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' failed. Abandon $ ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools (LDAP library: OpenLDAP 20423) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ apt-cache show ldap-utils Package: ldap-utils Priority: optional Section: net Installed-Size: 768 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: amd64 Source: openldap Version: 2.4.23-0ubuntu3 Replaces: openldap-utils, openldapd, slapd (<< 2.2.23-0.pre6) Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.4), libgnutls26 (>= 2.7.14-0), libgssapi-krb5-2 (>= 1.6.dfsg.2), libldap-2.4-2 (= 2.4.23-0ubuntu3), libsasl2-2 Recommends: libsasl2-modules Conflicts: ldap-client, openldap-utils, umich-ldap-utils Filename: pool/main/o/openldap/ldap-utils_2.4.23-0ubuntu3_amd64.deb Size: 343860 MD5sum: 5c7834714c933288181d660e34c0b3d6 SHA1: a18afe09abd61bcf6a722135bb82c308104fa15c SHA256: 1b2d43b4dc82843047d6930f8e1f4145a8cf40f9435d9d58389c7acd1a4d4b04 Description-fr: Utilitaires OpenLDAP

1 0

Re: (ITS#6848) wait timeout for slapd startup
by hyc＠symas.com 01 Mar '11

01 Mar '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > >> When LDAP is used as a dependency for other software during the init process (as >> a kerberos backend, for example), the fact that slapd exits with success prior >> to it being ready to accept connections can cause problems for the later >> services that depend on it. It would be useful to have an (optional) flag "-w >> <seconds>" that if provided, would have slapd wait up until<seconds> amount of >> time has passed for the daemon to fully initialize. > > Some distros already deal with this in other ways - e.g. OpenSuSE waits > until an ldapsearch on the null DN succeeds. This is done in the init.d > script. This is still by far the best solution. The current patch simply shifts the slapd parent process' exit a little later, to after the databases are started up. The listener thread still has not yet been created by this time. On a lightly loaded system the time till that is running should be trivial, but on a heavily loaded system who knows. > One advantage of putting explicit support into OpenLDAP for this is > that it may be possible to have an option to delay starting the > listners on a replication consumer until a full refresh has been done > from the master (this would need a timeout option too). There are > obvious deadlock issues in multi-master configs, but admins would at > least have the option of using this on pure consumers. We've discussed this option many times in the past but it generally seems to come out being more bad than good. Also it implies an expectation for consistency that simply isn't offered by the syncrepl spec. Best to leave this alone for now. When we get to LDAP Transactions, and figuring out how to represent them in a syncrepl exchange, then it would be meaningful. -- -- 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#6848) wait timeout for slapd startup
by andrew.findlay＠skills-1st.co.uk 01 Mar '11

01 Mar '11

On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > When LDAP is used as a dependency for other software during the init process (as > a kerberos backend, for example), the fact that slapd exits with success prior > to it being ready to accept connections can cause problems for the later > services that depend on it. It would be useful to have an (optional) flag "-w > <seconds>" that if provided, would have slapd wait up until <seconds> amount of > time has passed for the daemon to fully initialize. Some distros already deal with this in other ways - e.g. OpenSuSE waits until an ldapsearch on the null DN succeeds. This is done in the init.d script. One advantage of putting explicit support into OpenLDAP for this is that it may be possible to have an option to delay starting the listners on a replication consumer until a full refresh has been done from the master (this would need a timeout option too). There are obvious deadlock issues in multi-master configs, but admins would at least have the option of using this on pure consumers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

Andrew Elble wrote: > Howard Chu<hyc(a)symas.com> writes: > >>> It would seem that attr_merge() (in attr.c) should have something like this: >>> >>> if ( *a == NULL ) { >>> *a = attr_alloc( desc ); >>> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { >>> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; >>> } >>> } else { >> >> This is now fixed in HEAD in value.c. > > Tested, bad behavior still persists. The call path I've observed > is as follows: > > T@5 : | | | | |>bdb_modify_internal > T@5 : | | | | | |>modify_add_values > T@5 : | | | | | | |>attr_merge > T@5 : | | | | | | | |>attr_alloc > > ordered_value_add() doesn't seem to be involved (I can provide the > entire trace if necessary) Thanks, my mistake. Fixed now in HEAD attr.c (redundant code removed from add.c) -- -- 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#6848) wait timeout for slapd startup
by quanah＠OpenLDAP.org 28 Feb '11

28 Feb '11

Full_Name: Quanah Gibson-Mount Version: 2.4.24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When LDAP is used as a dependency for other software during the init process (as a kerberos backend, for example), the fact that slapd exits with success prior to it being ready to accept connections can cause problems for the later services that depend on it. It would be useful to have an (optional) flag "-w <seconds>" that if provided, would have slapd wait up until <seconds> amount of time has passed for the daemon to fully initialize. If it fails to initialize and be ready to accept connections by the end of the time period (when specified), slapd should exit with a new unique error code. This would allow for avoiding the startup problem. An example of this (and a terrible solution) can be found in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589915 Debian implemented a broken solution for this, but it is a general issue for anyone who has dependencies on slapd being ready.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 28 Feb '11

28 Feb '11

> On 02/28/2011 04:57 AM, Howard Chu wrote: >> Right, no problem. I've run your updated script against HEAD and see no >> errors, nor is there a duplicate result sent for the Bind operation. > > That's a good datapoint. I'll look into building HEAD on my system and > validate that the duplicate result messages are gone. I was able to build HEAD pretty quickly (much quicker than I've been able to in the past :-) ), and was able to validate that the test succeeds. -Kartik

1 0

Re: (ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu 28 Feb '11

28 Feb '11

Howard Chu <hyc(a)symas.com> writes: >> It would seem that attr_merge() (in attr.c) should have something like this: >> >> if ( *a == NULL ) { >> *a = attr_alloc( desc ); >> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { >> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; >> } >> } else { > > This is now fixed in HEAD in value.c. Tested, bad behavior still persists. The call path I've observed is as follows: T@5 : | | | | | >bdb_modify_internal T@5 : | | | | | | >modify_add_values T@5 : | | | | | | | >attr_merge T@5 : | | | | | | | | >attr_alloc ordered_value_add() doesn't seem to be involved (I can provide the entire trace if necessary) >> Further pursuing the issue, I started to focus on the index deletion >> code that was changed as a part of ITS#5183. Specifically, the >> portion of code within bdb_modify_internal() (in back-bdb/modify.c) >> that is commented: >> >> /* Move deleted values to end of array */ >> >> This code modifies save_attrs, which is actually apparently a pointer >> to memory that resides within the cache. If a deadlock occurs, these >> changes are not reverted, thereby corrupting the entry in the cache. I >> replaced this code with the pre-ITS#5183 code and I am no longer able >> to 'break' the object and insert duplicate member/memberUids. > > This is now fixed in HEAD. Looks good, thanks. -- Andrew W. Elble aweits(a)discipline.rit.edu Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 28 Feb '11

28 Feb '11

On 02/28/2011 04:57 AM, Howard Chu wrote: > Kartik Subbarao wrote: >> I'd like to add one clarification to this message. I named the attached >> test script that illustrates the two RESULT messages problem >> test099-ppolicy-update, per Howard's previous advice not to duplicate >> existing names. But I just realized that this script relies on the same >> data files that I previously submitted (slapd-ppolicy.conf, >> ppolicy.ldif) so when running this script please ensure that those files >> are in place. > > Right, no problem. I've run your updated script against HEAD and see no > errors, nor is there a duplicate result sent for the Bind operation. That's a good datapoint. I'll look into building HEAD on my system and validate that the duplicate result messages are gone. Alternatively, is there an easy way for you to run the script against 2.4.23 on your side? If so, and if you can reproduce the error that I got with 2.4.23, that would be a solid confirmation that the bug has since been fixed. Don't worry about it though if it would be too much of a hassle -- I appreciate all your help with this. Thanks, -Kartik

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 28 Feb '11

28 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > When idassert-bind is configured to use SASL bind, an "authcID" needs to be > provided, while the "binddn" is not needed. However, if a "binddn" is not > provided as well, in some cases the proxiedAuthz control may be used > incorrectly. The need to configure the "binddn" is not documented, so this ITS > is minimally addressed by documenting this requirement. I tripped over this change while investigating #6711. Adding this requirement is certainly not the right solution; SASL Binds ordinarily don't require a BindDN and requiring it here just makes things confusing. Also with the fixes that I made for #6711 I don't believe the issue exists any more. Please describe the conditions where the problem occurs. > If the "binddn" is provided, everything works as expected, with the only minor > issue that the DN of the user as it is known to back-meta may not match the > actual identity the "authcID" assumed on the remote server. The "right" way to > address this problem consists in performing a "WhoAmI" (RFC 4532) right after > the bind, or better use a "authorization identity control" (RFC 3829) along with > the bind operation. Both approaches should be implemented, but they should not > be used unless explicitly requested. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Feb '11

28 Feb '11

Kartik Subbarao wrote: > I'd like to add one clarification to this message. I named the attached > test script that illustrates the two RESULT messages problem > test099-ppolicy-update, per Howard's previous advice not to duplicate > existing names. But I just realized that this script relies on the same > data files that I previously submitted (slapd-ppolicy.conf, > ppolicy.ldif) so when running this script please ensure that those files > are in place. Right, no problem. I've run your updated script against HEAD and see no errors, nor is there a duplicate result sent for the Bind operation. There's a config error because back-ldap in HEAD now always requires the binddn to be set in the idassert-bind directive. I have a feeling that this new requirement is bogus, and I just patched your script to set binddn="" to get around it for the moment. > Thanks, > > -Kartik > > On 02/02/2011 11:50 AM, Kartik Subbarao wrote: >>>> Another problem is that bind operations to the consumer server start to >> >> return two result messages -- one with the error code of the chained >> >> operation, and one with the error code of the bind operation. >> >> I'm continuing to see this problem, even after I fix the acl-bind and >> the 'manage' ACL configuration. See the attached for an updated test >> script that illustrates the problem -- I've added a bind with an >> incorrect password which should return 49, but instead is returning 0 to >> the client. >> >> The last line of output from the test script is: >> >> ldap bind operation returned 0, expected 49 >> >> For the relevant operation in slapd.2.log, I see the following: >> >> conn=1003 op=0 RESULT tag=103 err=0 text= >> [...] >> conn=1003 op=0 RESULT tag=97 err=49 text= >> >> slapd is returning two RESULT messages for the BIND operation. Error 0 >> seems to be from the successful chained modification of the >> pwdFailureTime attribute, and Error 49 seems to be for the incorrect >> password. >> >> -Kartik > > -- -- 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#6847) slapd segmentation fault
by Howard Chu 28 Feb '11

28 Feb '11

The information you provided is useless. Please read http://www.openldap.org/faq/data/cache/59.html

1 0

Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

aweits(a)rit.edu wrote: > Full_Name: Andrew Elble > Version: 2.4.24 / CVS Head > OS: Solaris / MacOS > URL: > Submission from: (NULL) (129.21.6.207) > Thanks for the detailed report. > > We are using sortvals on both member and memberUid. We have been > seeing duplicate member/memberUid attributes on some objects that have > been modified (as well as a lack of sorting on those attributes). It > seemed that there was a correlation between modifies to objects that > experienced deadlocks and the objects that had duplicate > member/memberUid attributes on them. We put the seqmod overlay in > place - and this reduced the number of occurrences of the issue but > did not eliminate them. > > Upon further investigation, I discovered that it was possible to > bypass the sorting behavior if the object was not created with an > instance of the attribute with sorting enabled as a part of it. > > It would seem that attr_merge() (in attr.c) should have something like this: > > if ( *a == NULL ) { > *a = attr_alloc( desc ); > if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { > (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; > } > } else { This is now fixed in HEAD in value.c. > Further pursuing the issue, I started to focus on the index deletion > code that was changed as a part of ITS#5183. Specifically, the > portion of code within bdb_modify_internal() (in back-bdb/modify.c) > that is commented: > > /* Move deleted values to end of array */ > > This code modifies save_attrs, which is actually apparently a pointer > to memory that resides within the cache. If a deadlock occurs, these > changes are not reverted, thereby corrupting the entry in the cache. I > replaced this code with the pre-ITS#5183 code and I am no longer able > to 'break' the object and insert duplicate member/memberUids. This is now fixed in HEAD. > I also found it surprising that the call to bdb_idl_cache_del() in > bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to > the database? I see what you mean. I don't think this causes any harm though. > I can answer any questions about the specifics of the environment > in which where we are seeing this - it is a somewhat difficult problem to > reproduce outside of our production environment. I'm not terribly > familiar with the code - I'm looking to see if I have collected enough > data here to open an ITS to have this fixed. (or if I'm just way off base) > > > Thanks, > > Andy > > -- -- 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#6847) slapd segmentation fault
by dkastens＠uos.de 28 Feb '11

28 Feb '11

Full_Name: Dirk Kastens Version: 2.4.24 OS: Red Hat Enterprise Linux Server release 5.6 (kernel 2.6.18-238.1.1.el5xen) URL: Submission from: (NULL) (2001:638:508:3d0:74e8:28f7:184a:4cdf) I updated our openldap master and two replica servers to 2.4.24 (self-compiled) last week. Saturday morning, both replicas crashed at the same time with a segementation fault: kernel: slapd[2150]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 0000000042f9e630 error 4 kernel: slapd[9451]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 000000004563f630 error 4 Running slapd with valgrind --tool=memcheck --leak-check=full gives: ==31485== LEAK SUMMARY: ==31485== definitely lost: 0 bytes in 0 blocks ==31485== indirectly lost: 0 bytes in 0 blocks ==31485== possibly lost: 110,162 bytes in 4,698 blocks ==31485== still reachable: 6,942,591 bytes in 26,974 blocks ==31485== suppressed: 0 bytes in 0 blocks ==31485== Reachable blocks (those to which a pointer was found) are not shown. ==31485== To see them, rerun with: --leak-check=full --show-reachable=yes ==31485== ==31485== For counts of detected and suppressed errors, rerun with: -v ==31485== ERROR SUMMARY: 256 errors from 256 contexts (suppressed: 16 from 7) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (defined) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (noaccess) ==31485== Warning: invalid file descriptor -1 in syscall read()

1 0

(ITS#6846) Deadlock in back-meta
by jorge.perez.burgos＠ericsson.com 28 Feb '11

28 Feb '11

Full_Name: Jorge Perez Burgos Version: 2.4.15 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) There is a deadlock in back-meta code, the problem is that this thread get the lock two times, the first is the one that show the trace, but previous in the method meta_back_retry it has already the lock. (gdb) bt #0 0x00002b6e1a0706a8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b6e1a06c9fb in _L_mutex_lock_92 () from /lib64/libpthread.so.0 #2 0x00002b6e1a06c455 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004eb715 in meta_back_bind_op_result (op=0x2aab35d80020, rs=0x6eb6ad20, mc=0x2aab35e58be0, candidate=4, msgid=1, sendok=<value optimized out>) at bind.c:388 #4 0x00000000004eba9f in meta_back_proxy_authz_bind (mc=0x2aab35e58be0, candidate=4, op=0x2aab35d80020, rs=0x6eb6ad20, sendok=LDAP_BACK_SENDERR) at bind.c:1534 #5 0x00000000004ebc21 in meta_back_single_dobind (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR, nretries=276864893, dolock=0) at bind.c:600 #6 0x00000000004f3c4f in meta_back_retry (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR) at conn.c:721 #7 0x00000000004e9ffc in meta_back_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:184 #8 0x000000000044c196 in fe_op_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:334 #9 0x00000000004a4832 in overlay_op_walk (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add, oi=0x905850, on=0x0) at backover.c:669 #10 0x00000000004a4db5 in over_op_func (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add) at backover.c:721 #11 0x000000000044ca02 in do_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:194 #12 0x0000000000445bab in connection_operation (ctx=0x6eb6ae70, arg_v=<value optimized out>) at connection.c:1115 #13 0x0000000000446087 in connection_read_thread (ctx=0x6eb6ae70, argv=<value optimized out>) at connection.c:1241 #14 0x000000000052398a in ldap_int_thread_pool_wrapper (xpool=0x788e70) at tpool.c:663 #15 0x00002b6e1a06a193 in start_thread () from /lib64/libpthread.so.0 #16 0x00002b6e19814dfd in clone () from /lib64/libc.so.6

1 0

(ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu 25 Feb '11

25 Feb '11

Full_Name: Andrew Elble Version: 2.4.24 / CVS Head OS: Solaris / MacOS URL: Submission from: (NULL) (129.21.6.207) We are using sortvals on both member and memberUid. We have been seeing duplicate member/memberUid attributes on some objects that have been modified (as well as a lack of sorting on those attributes). It seemed that there was a correlation between modifies to objects that experienced deadlocks and the objects that had duplicate member/memberUid attributes on them. We put the seqmod overlay in place - and this reduced the number of occurrences of the issue but did not eliminate them. Upon further investigation, I discovered that it was possible to bypass the sorting behavior if the object was not created with an instance of the attribute with sorting enabled as a part of it. It would seem that attr_merge() (in attr.c) should have something like this: if ( *a == NULL ) { *a = attr_alloc( desc ); if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) { (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; } } else { Further pursuing the issue, I started to focus on the index deletion code that was changed as a part of ITS#5183. Specifically, the portion of code within bdb_modify_internal() (in back-bdb/modify.c) that is commented: /* Move deleted values to end of array */ This code modifies save_attrs, which is actually apparently a pointer to memory that resides within the cache. If a deadlock occurs, these changes are not reverted, thereby corrupting the entry in the cache. I replaced this code with the pre-ITS#5183 code and I am no longer able to 'break' the object and insert duplicate member/memberUids. I also found it surprising that the call to bdb_idl_cache_del() in bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to the database? I can answer any questions about the specifics of the environment in which where we are seeing this - it is a somewhat difficult problem to reproduce outside of our production environment. I'm not terribly familiar with the code - I'm looking to see if I have collected enough data here to open an ITS to have this fixed. (or if I'm just way off base) Thanks, Andy

1 0

(ITS#6844) AIX 6.1 | 7.1 not supported in "configure"
by joshua.taylor＠ubs.com 25 Feb '11

25 Feb '11

Full_Name: Joshua Taylor Version: 2.4.24 OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.134.254.26) the configure script has no support for aix6* or aix7*, resulting in assuming no shared libraries are supported. Simply going in after each reference to "aix5*" and adding, " | aix6* | aix7* " enables shared library support. Also, support for IA64 on aix is no more. I'm not even sure there was ever a version that *actually* ran on IA64 cpus.

1 0

Re: (ITS#6841) slapd segfault error 7
by quanah＠zimbra.com 24 Feb '11

24 Feb '11

--On Tuesday, February 22, 2011 10:54 AM +0000 tecnica(a)florasul.pt wrote: > This is the output from strace -o slapd strace is useless. Please have a core file generated, with debugging symbols, and send the full backtrace. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2.4.23 / Debian 6.0 i386: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd
by David Touzeau 24 Feb '11

24 Feb '11

Dear We have an problem using $OpenLDAP: slapd 2.4.23 (Nov 22 2010 23:39:34) $#012#011@biber:/build/buildd-openldap_2.4.23-7-i386-mi96UQ/openldap-2.4.23/debian/build/servers/slapd The same issue has been be replicated on 2.4.24 When we analyze the debug logs, the crash is performed each time we see this line : is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute How can we prevent this crash or fix it ? here it is a piece of logs that detect the crash. Feb 22 14:50:21 pm02 slapd[12126]: >>> dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: <<< dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>, <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: oc_check_required entry (cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com), objectClass "ArticaHostName" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "objectClass" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "cn" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "structuralObjectClass" Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute Feb 22 14:50:21 pm02 kernel: [13697.801217] slapd[13777]: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd[8048000+11b000] best regards

2 1

(ITS#6843) Can't slapadd cn=config LDIF with global chaining overlay
by rhafer＠suse.de 24 Feb '11

24 Feb '11

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.251.8) slapadd-ing the following LDIF (a stripped down slapcat output) fails: ------------------------- dn: cn=config objectClass: olcGlobal cn: config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcChainDatabase objectClass: olcLDAPConfig olcDatabase: {0}ldap dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config --------------------------------------- The error message is: slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=20): Already exists The problem is the olcChainDatabase Entry. As it appears before the config-database entry config_tool_entry_put() will autocreate an olcDatabase={0}config,cn=config and after that choke up when trying to add the olcDatabase={0}config,cn=config that appears later in the LDIF file. I have a fix for this mostly ready. (Just skipping autocreation of the config-Database if child-entries of the frontendDatabase are added)

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 02:02:17PM +0000, hyc(a)symas.com wrote: > > A URI-based restriction specification could include/exclude based on > > suffix, filter and listed attributes with a unified syntax. > > Yes... But what does the filter *mean* in > a modify op? filter on the target entry before it was modified, or after? Hmm - I was thinking of matching on the *modified attributes* (just their presence, not taking account of value). However, I can see that pre- and post-conditions might matter so: logrecord <operations> prefilter|changefilter|postfilter <LDAP URL> logignore <operations> prefilter|changefilter|postfilter <LDAP URL> ... > a search op? match the search request's filter, or filter on the search base? Both if present. Again, I might restrict the filter to matching on the presence of attributes in the filter rather than their actual value. > a compare op? Whatever works for search should be very close. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 05:25:28AM -0800, Howard Chu wrote: > >Extending this idea slightly, would it be possible to have > >exclusions based on changes to specific attributes? The > >particular case I have in mind is where accesslog is used to > >keep a permanent audit log of changes, and ppolicy is also > >in use, resulting in one audit entry for every login > >failure. I have one site where a large proportion of the auditlog > >entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods > to be internal-only and bypass the accesslog overlay. (Currently it > does this already, if the server is a single-master replica.) There are all sorts of problems to do with ppolicy and replication... Bypassing accesslog is an interesting idea, but I can see that people who use n-failure-lockout might want the lockout events to be auditable. I wonder if there might be some benefit to giving such control on a per-operation basis. Then ppolicy might be configurable to have some automatic ops logged and others not. It could also be the start of a way to make ppolicy actions rather more global across a replication group (e.g. by putting in the ability to queue some ops for replication back to a master server). > So far you're talking about two different enhancements - the > original poster is trying to exclude a set of searches, and you're > talking about excluding modify ops. I'm not seeing any way yet to > generalize from here such that all operation types are addressed > meaningfully, and I don't want to introduce multiple special cases > to the config language. Rather than logbase <operations> <baseDN> how about logfilter <operations> <LDAP URL> where the whole clause may be repeated as many times as needed? The LDAP URL can then specify a search base, a filter, and a list of attributes of interest. Extending this to support both inclusion and exclusion clauses might be harder, as you would then need some way to give them an order of precedence. The case I mentioned before would need a rule of the form 'dont log this op if the only change concerns the atttribute pwdFailureTime'. Perhaps a simple list of rules: logrecord <operations> <LDAP URL> logignore <operations> <LDAP URL> ... and if anything is left at the end of the list then it gets logged. The filters would determine whether a log entry would be made at all, and the attribute lists would determine the content. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 23 Feb '11

23 Feb '11

Hi! Thanx for your reply. We have been able to reproduce the problem on a test system and found out that setting "idletimeout" seems to fix this issue for us. Note that we enabled gentlehup! We have now the new configuration on our production environment and everything seems stable. We are not able to change solaris versions. If there are still problems we will upgrade the openldap version. On another system we have the same ldap configuration (gentlehup and no idletimeout set) and do not experience any problem. Best regards, Thomas -------- Original-Nachricht -------- > Datum: Wed, 23 Feb 2011 02:26:01 GMT > Von: hyc(a)symas.com > An: openldap-its(a)openldap.org > Betreff: Re: (ITS#6833) LDAP hangs on Solaris > tombolala(a)gmx.de wrote: > > Hi Quanah! > > > > sorry for the wrong release, I meant 2.4.22 of course. > > I recall we also experienced hangs with Solaris 10 during the testing > leading > up to the 2.4.24 release. Yet with identical code, no such hangs were > reported > on Solaris 9 or Solaris 11. I suspect there's a bug in the implementation > of > select() on Solaris 10, causing it to fail to report the connection close > events. > > Some discussion of this problem occurred in this email thread > > http://www.openldap.org/lists/openldap-devel/201101/msg00033.html > > Try 2.4.24, and try a different Solaris release. Aside from that, we have > no > answers for you. > > > /Thomas > > > > -------- Original-Nachricht -------- > >> Datum: Wed, 16 Feb 2011 16:34:39 GMT > >> Von: quanah(a)zimbra.com > >> An: openldap-its(a)openldap.org > >> Betreff: Re: (ITS#6833) LDAP hangs on Solaris > > > >> --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de > wrote: > >> > >>> Full_Name: Thomas Bopp > >>> Version: 4.2.22 > >> > >>> I really need a solution for this problem. > >> > >> I suggest you list an actual OpenLDAP release. It's near impossible to > >> help you without that. > >> > >> --Quanah > >> > >> -- > >> > >> Quanah Gibson-Mount > >> Sr. Member of Technical Staff > >> Zimbra, Inc > >> A Division of VMware, Inc. > >> -------------------- > >> Zimbra :: the leader in open source messaging and collaboration > >> > >> > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

masarati(a)aero.polimi.it wrote: > hyc(a)symas.com wrote: >> Andrew Findlay wrote: >>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: >>> >>>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>>> to simplify this case. >>> Extending this idea slightly, would it be possible to have >>> exclusions based on changes to specific attributes? The >>> particular case I have in mind is where accesslog is used to >>> keep a permanent audit log of changes, and ppolicy is also >>> in use, resulting in one audit entry for every login >>> failure. I have one site where a large proportion of the auditlog >>> entries are login failures... >> >> Perhaps in that case, it would be simpler just to set ppolicy's mods to be >> internal-only and bypass the accesslog overlay. (Currently it does this >> already, if the server is a single-master replica.) >> >> So far you're talking about two different enhancements - the original poster >> is trying to exclude a set of searches, and you're talking about excluding >> modify ops. I'm not seeing any way yet to generalize from here such that all >> operation types are addressed meaningfully, and I don't want to introduce >> multiple special cases to the config language. > > A URI-based restriction specification could include/exclude based on > suffix, filter and listed attributes with a unified syntax. Yes... But what does the filter *mean* in a modify op? filter on the target entry before it was modified, or after? a search op? match the search request's filter, or filter on the search base? a compare op? -- -- 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#6815) Feature Request: Accesslog filter
by masarati＠aero.polimi.it 23 Feb '11

23 Feb '11

hyc(a)symas.com wrote: > Andrew Findlay wrote: >> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: >> >>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>> to simplify this case. >> Extending this idea slightly, would it be possible to have >> exclusions based on changes to specific attributes? The >> particular case I have in mind is where accesslog is used to >> keep a permanent audit log of changes, and ppolicy is also >> in use, resulting in one audit entry for every login >> failure. I have one site where a large proportion of the auditlog >> entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods to be > internal-only and bypass the accesslog overlay. (Currently it does this > already, if the server is a single-master replica.) > > So far you're talking about two different enhancements - the original poster > is trying to exclude a set of searches, and you're talking about excluding > modify ops. I'm not seeing any way yet to generalize from here such that all > operation types are addressed meaningfully, and I don't want to introduce > multiple special cases to the config language. A URI-based restriction specification could include/exclude based on suffix, filter and listed attributes with a unified syntax. p.

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

Andrew Findlay wrote: > On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: > >> Possibly we can extend the directive to handle exclusion as well as inclusion, >> to simplify this case. > > Extending this idea slightly, would it be possible to have > exclusions based on changes to specific attributes? The > particular case I have in mind is where accesslog is used to > keep a permanent audit log of changes, and ppolicy is also > in use, resulting in one audit entry for every login > failure. I have one site where a large proportion of the auditlog > entries are login failures... Perhaps in that case, it would be simpler just to set ppolicy's mods to be internal-only and bypass the accesslog overlay. (Currently it does this already, if the server is a single-master replica.) So far you're talking about two different enhancements - the original poster is trying to exclude a set of searches, and you're talking about excluding modify ops. I'm not seeing any way yet to generalize from here such that all operation types are addressed meaningfully, and I don't want to introduce multiple special cases to the config language. -- -- 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#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: > Possibly we can extend the directive to handle exclusion as well as inclusion, > to simplify this case. Extending this idea slightly, would it be possible to have exclusions based on changes to specific attributes? The particular case I have in mind is where accesslog is used to keep a permanent audit log of changes, and ppolicy is also in use, resulting in one audit entry for every login failure. I have one site where a large proportion of the auditlog entries are login failures... Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 23 Feb '11

23 Feb '11

--0016363b8528ec55d3049cef5b03 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc(a)symas.com> wrote: > Marco Pizzoli wrote: > >> Hi Howard, >> thanks for this work. >> >> I noticed that you give me a baseDN under which I can have operations >> logged. >> If I would like to exclude one subtree from my principal tree, I need to >> specify all the baseDN of other sibling-subtrees. >> To do this do I need to poli-invoke accesslog overlay? >> > > No, you can specify logbase multiple times in a single overlay. > Ok, thanks. > Possibly we can extend the directive to handle exclusion as well as > inclusion, to simplify this case. > This is effectively what I would need, in this case. --0016363b8528ec55d3049cef5b03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu = <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&gt= ; wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0= pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;= "> <div class=3D"im">Marco Pizzoli wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logge= d. If I would like to exclude one subtree from my principal tree, I need to<br= > specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? </blockquote> </div> No, you can specify logbase multiple times in a single overlay. </blockq= uote><div> Ok, thanks. =A0</div><blockquote class=3D"gmail_quote"= style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 2= 04); padding-left: 1ex;"> Possibly we can extend the directive to handle exclusion as well as inclusi= on, to simplify this case. </blockquote><div> This is effectively wha= t I would need, in this case. </div></div> --0016363b8528ec55d3049cef5b03--

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

Marco Pizzoli wrote: > Hi Howard, > thanks for this work. > > I noticed that you give me a baseDN under which I can have operations logged. > If I would like to exclude one subtree from my principal tree, I need to > specify all the baseDN of other sibling-subtrees. > To do this do I need to poli-invoke accesslog overlay? No, you can specify logbase multiple times in a single overlay. Possibly we can extend the directive to handle exclusion as well as inclusion, to simplify this case. > > Thanks again > Marco > > On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > marco.pizzoli(a)gmail.com <mailto:marco.pizzoli@gmail.com> wrote: > > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations > that match > some sort of filter, or, in particular, to not to log searches that > matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every > 30seconds do > a dummy ldap search only to keep alive their connection to the ldap > server. > These searches are frequent and I have many of these clients in my > deploy, so my > accesslog become full of not significant entries. > > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > _________________________________________ > Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. > Jim Morrison -- -- 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#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 23 Feb '11

23 Feb '11

--0016363b85287ec3a0049cef245f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logged. If I would like to exclude one subtree from my principal tree, I need to specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? Thanks again Marco On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc(a)symas.com> wrote: > marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: ALL >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.41.84.11) >> >> >> Hi, >> this is a feature request. >> >> I would like to have accesslog writing to his db only ldap operations th= at >> match >> some sort of filter, or, in particular, to not to log searches that >> matches a >> specific pattern. >> >> This request is spotted by some ldap clients that I have that every >> 30seconds do >> a dummy ldap search only to keep alive their connection to the ldap >> server. >> These searches are frequent and I have many of these clients in my deplo= y, >> so my >> accesslog become full of not significant entries. >> > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016363b85287ec3a0049cef245f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, thanks for this work. I noticed that you give me a bas= eDN under which I can have operations logged. If I would like to exclude= one subtree from my principal tree, I need to specify all the baseDN of ot= her sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? Thanks again<= br>Marco <div class=3D"gmail_quote">On Wed, Feb 23, 2011 at 3:15 AM,= Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc@syma= s.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><a href=3D"mailto= :marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli(a)gmail.com</a> wro= te: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Full_Name: Marco Pizzoli Version: ALL OS: URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (193.41.84.11) Hi, this is a feature request. I would like to have accesslog writing to his db only ldap operations that = match some sort of filter, or, in particular, to not to log searches that matches= a specific pattern. This request is spotted by some ldap clients that I have that every 30secon= ds do a dummy ldap search only to keep alive their connection to the ldap server.= These searches are frequent and I have many of these clients in my deploy, = so my accesslog become full of not significant entries. </blockquote> I've added a simple subtree-matching feature to accesslog in HEAD. Plea= se test and let us know if it addresses this request. -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- ________________= _________________________ Non =E8 forte chi non cade, ma chi cadendo ha = la forza di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morri= son --0016363b85287ec3a0049cef245f--

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by hyc＠symas.com 22 Feb '11

22 Feb '11

Andrew Findlay wrote: > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > >> re: TLS Authentication Identity Format >> >> Strictly speaking, the order of components is not changed at all. >> The sequence of RDNs in the DN is what it is; just that the >> convention for *displaying* it is ass-backwards in LDAP. I'm afraid >> the wording here will confuse people into thinking that the >> *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. Thanks, applied with formatting tweaks. > > Andrew > > > sasl-x509-dn-doc.patch > > > --- sasl.sdf.head 2011-02-18 23:03:07.000000000 +0000 > +++ sasl.sdf 2011-02-22 14:30:25.947887979 +0000 > @@ -1,4 +1,4 @@ > -# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.51 2011/02/18 23:03:07 hyc Exp $ > +# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.34.2.12 2011/01/04 23:49:40 kurt Exp $ > # Copyright 1999-2011 The OpenLDAP Foundation, All Rights Reserved. > # COPYING RESTRICTIONS APPLY, see COPYRIGHT. > > @@ -302,9 +302,9 @@ > > H4: TLS Authentication Identity Format > > -This is usually the Subject DN from the client-side certificate. > -The order of the components will be changed to follow LDAP conventions, > -so a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} > +This is the Subject DN from the client-side certificate. > +Note that DNs are displayed differently by LDAP and by X.509, so > +a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} > will produce an authentication identity of: > > > cn=A Person,o=The Example Organisation,c=gb -- -- 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#6833) LDAP hangs on Solaris
by hyc＠symas.com 22 Feb '11

22 Feb '11

tombolala(a)gmx.de wrote: > Hi Quanah! > > sorry for the wrong release, I meant 2.4.22 of course. I recall we also experienced hangs with Solaris 10 during the testing leading up to the 2.4.24 release. Yet with identical code, no such hangs were reported on Solaris 9 or Solaris 11. I suspect there's a bug in the implementation of select() on Solaris 10, causing it to fail to report the connection close events. Some discussion of this problem occurred in this email thread http://www.openldap.org/lists/openldap-devel/201101/msg00033.html Try 2.4.24, and try a different Solaris release. Aside from that, we have no answers for you. > /Thomas > > -------- Original-Nachricht -------- >> Datum: Wed, 16 Feb 2011 16:34:39 GMT >> Von: quanah(a)zimbra.com >> An: openldap-its(a)openldap.org >> Betreff: Re: (ITS#6833) LDAP hangs on Solaris > >> --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: >> >>> Full_Name: Thomas Bopp >>> Version: 4.2.22 >> >>> I really need a solution for this problem. >> >> I suggest you list an actual OpenLDAP release. It's near impossible to >> help you without that. >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> > -- -- 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#6815) Feature Request: Accesslog filter
by hyc＠symas.com 22 Feb '11

22 Feb '11

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations that match > some sort of filter, or, in particular, to not to log searches that matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every 30seconds do > a dummy ldap search only to keep alive their connection to the ldap server. > These searches are frequent and I have many of these clients in my deploy, so my > accesslog become full of not significant entries. I've added a simple subtree-matching feature to accesslog in HEAD. Please test and let us know if it addresses this request. -- -- 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#6841) slapd segfault error 7
by masarati＠aero.polimi.it 22 Feb '11

22 Feb '11

> Full_Name: André Bolinhas > Version: 2.4.24 > OS: ubuntu 10.4 x86 > URL: > Submission from: (NULL) (217.129.0.33) > > > Dear, > > My ldap crash every 2 minutes, I get this error on syslog > > kernel: [35483.930213] slapd[3892]: segfault at 8127238 ip 080c6fcc sp > b60ffb00 > error 7 in slapd[8048000+123000] > > How can help to solve this problem ? Usage help requests should be directed to openldap-technical mailing list. The ITS is for bug tracking. I infer you didn't read the instructions from the fact that you clicked the "Major Security Issue?" for ITS#6840). This ITS will be closed. p.

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by andrew.findlay＠skills-1st.co.uk 22 Feb '11

22 Feb '11

--GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > re: TLS Authentication Identity Format > > Strictly speaking, the order of components is not changed at all. > The sequence of RDNs in the DN is what it is; just that the > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > the wording here will confuse people into thinking that the > *semantics* of the DN are changed, when it's only a display issue. Good point. Updated wording attached. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- --GRPZ8SYKNexpdSJ7 Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="sasl-x509-dn-doc.patch" --- sasl.sdf.head 2011-02-18 23:03:07.000000000 +0000 +++ sasl.sdf 2011-02-22 14:30:25.947887979 +0000 @@ -1,4 +1,4 @@ -# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.51 2011/02/18 23:03:07 hyc Exp $ +# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.34.2.12 2011/01/04 23:49:40 kurt Exp $ # Copyright 1999-2011 The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. @@ -302,9 +302,9 @@ H4: TLS Authentication Identity Format -This is usually the Subject DN from the client-side certificate. -The order of the components will be changed to follow LDAP conventions, -so a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} +This is the Subject DN from the client-side certificate. +Note that DNs are displayed differently by LDAP and by X.509, so +a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} will produce an authentication identity of: > cn=A Person,o=The Example Organisation,c=gb --GRPZ8SYKNexpdSJ7--

1 0

Re: (ITS#6841) slapd segfault error 7
by tecnica＠florasul.pt 22 Feb '11

22 Feb '11

This is the output from strace -o slapd execve("/usr/sbin/slapd", ["slapd"], [/* 18 vars */]) = 0 brk(0) = 0x88b6000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7795000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7789000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libldap_r-2.4.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\274\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=982577, ...}) = 0 mmap2(NULL, 285892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7743000 mprotect(0xb7785000, 4096, PROT_NONE) = 0 mmap2(0xb7786000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42) = 0xb7786000 mmap2(0xb7788000, 3268, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7788000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/liblber-2.4.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300*\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=143488, ...}) = 0 mmap2(NULL, 49716, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7736000 mmap2(0xb7741000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0xb7741000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\20\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=14000, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7735000 mmap2(NULL, 16592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7730000 mmap2(0xb7733000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7733000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.6.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@}\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1230912, ...}) = 0 mmap2(NULL, 1234236, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7602000 mmap2(0xb772d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb772d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 J\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=117086, ...}) = 0 mmap2(NULL, 98792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75e9000 mmap2(0xb75fe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb75fe000 mmap2(0xb7600000, 4584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7600000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libiodbc.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300M\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=305108, ...}) = 0 mmap2(NULL, 308068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb759d000 mmap2(0xb75e6000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x48) = 0xb75e6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libslp.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P.\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=59008, ...}) = 0 mmap2(NULL, 61888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb758d000 mmap2(0xb759b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd) = 0xb759b000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2201\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=79676, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb758c000 mmap2(NULL, 92136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7575000 mmap2(0xb7588000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7588000 mmap2(0xb758a000, 6120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb758a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsasl2.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3602\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=91892, ...}) = 0 mmap2(NULL, 94764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb755d000 mmap2(0xb7573000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15) = 0xb7573000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libgnutls.so.26", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\334\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=629248, ...}) = 0 mmap2(NULL, 632024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb74c2000 mmap2(0xb7558000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x95) = 0xb7558000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\7\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=38360, ...}) = 0 mmap2(NULL, 201052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7490000 mmap2(0xb7499000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0xb7499000 mmap2(0xb749b000, 155996, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb749b000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000&\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=71432, ...}) = 0 mmap2(NULL, 79944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb747c000 mmap2(0xb748c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10) = 0xb748c000 mmap2(0xb748e000, 6216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb748e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libltdl.so.7", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\32\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=30168, ...}) = 0 mmap2(NULL, 32988, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7473000 mmap2(0xb747a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb747a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9736, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7472000 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb746e000 mmap2(0xb7470000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7470000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libwrap.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\"\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=31020, ...}) = 0 mmap2(NULL, 35868, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7465000 mmap2(0xb746c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb746c000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0 mmap2(NULL, 1415592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb730b000 mprotect(0xb745e000, 4096, PROT_NONE) = 0 mmap2(0xb745f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0xb745f000 mmap2(0xb7462000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7462000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libtasn1.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\21\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=62936, ...}) = 0 mmap2(NULL, 66180, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb72fa000 mmap2(0xb7309000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe) = 0xb7309000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\31\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=79512, ...}) = 0 mmap2(NULL, 82188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb72e5000 mmap2(0xb72f8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb72f8000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libgcrypt.so.11", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340M\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=470976, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb72e4000 mmap2(NULL, 470348, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7271000 mmap2(0xb72e1000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x70) = 0xb72e1000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libgpg-error.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\6\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=13604, ...}) = 0 mmap2(NULL, 16432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb726c000 mmap2(0xb726f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb726f000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb726b000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb726a000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb726a700, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb726f000, 4096, PROT_READ) = 0 mprotect(0xb72e1000, 4096, PROT_READ) = 0 mprotect(0xb72f8000, 4096, PROT_READ) = 0 mprotect(0xb7309000, 4096, PROT_READ) = 0 mprotect(0xb745f000, 8192, PROT_READ) = 0 mprotect(0xb746c000, 4096, PROT_READ) = 0 mprotect(0xb7470000, 4096, PROT_READ) = 0 mprotect(0xb747a000, 4096, PROT_READ) = 0 mprotect(0xb748c000, 4096, PROT_READ) = 0 mprotect(0xb7499000, 4096, PROT_READ) = 0 mprotect(0xb7558000, 16384, PROT_READ) = 0 mprotect(0xb7573000, 4096, PROT_READ) = 0 mprotect(0xb7588000, 4096, PROT_READ) = 0 mprotect(0xb759b000, 4096, PROT_READ) = 0 mprotect(0xb75e6000, 4096, PROT_READ) = 0 mprotect(0xb75fe000, 4096, PROT_READ) = 0 mprotect(0xb772d000, 8192, PROT_READ) = 0 mprotect(0xb7733000, 4096, PROT_READ) = 0 mprotect(0xb7741000, 4096, PROT_READ) = 0 mprotect(0xb7786000, 4096, PROT_READ) = 0 mprotect(0x816b000, 4096, PROT_READ) = 0 mprotect(0xb77b3000, 4096, PROT_READ) = 0 munmap(0xb7789000, 45329) = 0 set_tid_address(0xb726a768) = 13593 set_robust_list(0xb726a770, 0xc) = 0 futex(0xbfc2c7f0, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0xbfc2c7f0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, bfc2c800) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0xb75ed410, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb75ed8f0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 brk(0) = 0x88b6000 brk(0x88d7000) = 0x88d7000 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 open("/etc/resolv.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "search evora01.florasul.lan\nname"..., 4096) = 80 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=475, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 475 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7789000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \32\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=42572, ...}) = 0 mmap2(NULL, 45772, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb725e000 mmap2(0xb7268000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9) = 0xb7268000 close(3) = 0 mprotect(0xb7268000, 4096, PROT_READ) = 0 munmap(0xb7789000, 45329) = 0 open("/etc/host.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=92, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "# The \"order\" line is only used "..., 4096) = 92 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb7463b44, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat64(3, {st_mode=S_IFREG|0644, st_size=4050, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "192.168.2.103\tpm02.evora01.flora"..., 4096) = 4050 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=245, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "#\n# LDAP Defaults\n#\n\n# See ldap."..., 4096) = 245 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 geteuid32() = 0 getuid32() = 0 open("/root/ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/root/.ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0 time(NULL) = 1298368862 open("/etc/localtime", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=3439, ...}) = 0 fstat64(4, {st_mode=S_IFREG|0644, st_size=3439, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\v\0\0\0\v\0\0\0\0"..., 4096) = 3439 _llseek(4, -27, [3412], SEEK_CUR) = 0 read(4, "\nWET0WEST,M3.5.0/1,M10.5.0\n", 4096) = 27 close(4) = 0 munmap(0xb7794000, 4096) = 0 send(3, "<167>Feb 22 10:01:02 slapd[13593"..., 184, MSG_NOSIGNAL) = 184 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 open("/etc/resolv.conf", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "search evora01.florasul.lan\nname"..., 4096) = 80 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=4050, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "192.168.2.103\tpm02.evora01.flora"..., 4096) = 4050 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7794000, 4096) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 pipe([4, 5]) = 0 fcntl64(5, F_GETFL) = 0x1 (flags O_WRONLY) fcntl64(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 epoll_create(1024) = 6 socket(PF_NETLINK, SOCK_RAW, 0) = 7 bind(7, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(7, {sa_family=AF_NETLINK, pid=13593, groups=00000000}, [12]) = 0 time(NULL) = 1298368862 sendto(7, "\24\0\0\0\26\0\1\3^\211cM\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0^\211cM\0315\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0^\211cM\0315\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0^\211cM\0315\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(7) = 0 open("/etc/gai.conf", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=2987, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=2987, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(7, "# Configuration for getaddrinfo("..., 4096) = 2987 read(7, "", 4096) = 0 close(7) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb7462cf0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 7 connect(7, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 getsockname(7, {sa_family=AF_INET6, sin6_port=htons(48150), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 connect(7, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 connect(7, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(7, {sa_family=AF_INET6, sin6_port=htons(37782), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 close(7) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(7, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 8 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(8, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 bind(8, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 brk(0x88f8000) = 0x88f8000 getuid32() = 0 geteuid32() = 0 getgid32() = 0 getegid32() = 0 open("/etc/sasl/slapd.conf", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/sasl2/slapd.conf", O_RDONLY) = -1 ENOENT (No such file or directory) getuid32() = 0 geteuid32() = 0 getgid32() = 0 getegid32() = 0 open("/usr/lib/sasl2", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 9 fcntl64(9, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(9, /* 45 entries */, 32768) = 1212 open("/usr/lib/sasl2/libldapdb.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libdigestmd5.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libcrammd5.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=976, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(10, "# libcrammd5.la - a libtool libr"..., 4096) = 976 close(10) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb747106c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/usr/lib/sasl2/libcrammd5.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17764, ...}) = 0 mmap2(NULL, 20640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb778f000 mmap2(0xb7793000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb7793000 close(10) = 0 mprotect(0xb7793000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libldapdb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=983, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb778e000 read(10, "# libldapdb.la - a libtool libra"..., 4096) = 983 close(10) = 0 munmap(0xb778e000, 4096) = 0 open("/usr/lib/sasl2/libldapdb.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\20\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17648, ...}) = 0 mmap2(NULL, 20528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7789000 mmap2(0xb778d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb778d000 close(10) = 0 mprotect(0xb778d000, 4096, PROT_READ) = 0 time(NULL) = 1298368862 send(3, "<35>Feb 22 10:01:02 slapd[13593]"..., 79, MSG_NOSIGNAL) = 79 time(NULL) = 1298368862 send(3, "<39>Feb 22 10:01:02 slapd[13593]"..., 104, MSG_NOSIGNAL) = 104 open("/usr/lib/sasl2/libntlm.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libcrammd5.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libplain.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=970, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb725d000 read(10, "# libplain.la - a libtool librar"..., 4096) = 970 close(10) = 0 munmap(0xb725d000, 4096) = 0 open("/usr/lib/sasl2/libplain.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17760, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7259000 mmap2(0xb725c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb725c000 close(10) = 0 mprotect(0xb725c000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libsasldb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1001, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7258000 read(10, "# libsasldb.la - a libtool libra"..., 4096) = 1001 close(10) = 0 munmap(0xb7258000, 4096) = 0 open("/usr/lib/sasl2/libsasldb.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\17\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=21736, ...}) = 0 mmap2(NULL, 24620, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7252000 mmap2(0xb7257000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x4) = 0xb7257000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb7246000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.8.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320L\1\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1439772, ...}) = 0 mmap2(NULL, 1442512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70e5000 mmap2(0xb7243000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x15d) = 0xb7243000 close(10) = 0 mprotect(0xb7243000, 8192, PROT_READ) = 0 mprotect(0xb7257000, 4096, PROT_READ) = 0 munmap(0xb7246000, 45329) = 0 open("/usr/lib/sasl2/liblogin.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libanonymous.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libplain.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/liblogin.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=970, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7251000 read(10, "# liblogin.la - a libtool librar"..., 4096) = 970 close(10) = 0 munmap(0xb7251000, 4096) = 0 open("/usr/lib/sasl2/liblogin.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=13664, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb724d000 mmap2(0xb7250000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2) = 0xb7250000 close(10) = 0 mprotect(0xb7250000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libanonymous.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=990, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb724c000 read(10, "# libanonymous.la - a libtool li"..., 4096) = 990 close(10) = 0 munmap(0xb724c000, 4096) = 0 open("/usr/lib/sasl2/libanonymous.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=13668, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7248000 mmap2(0xb724b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2) = 0xb724b000 close(10) = 0 mprotect(0xb724b000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libsasldb.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libdigestmd5.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=999, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(10, "# libdigestmd5.la - a libtool li"..., 4096) = 999 close(10) = 0 munmap(0xb7247000, 4096) = 0 open("/usr/lib/sasl2/libdigestmd5.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\21\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=46712, ...}) = 0 mmap2(NULL, 49544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70d8000 mmap2(0xb70e3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0xa) = 0xb70e3000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb70cc000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libcrypto.so.0.9.8", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\334\3\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1364764, ...}) = 0 mmap2(NULL, 1380472, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6f7a000 mmap2(0xb70b2000, 90112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x137) = 0xb70b2000 mmap2(0xb70c8000, 12408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb70c8000 close(10) = 0 mprotect(0xb70b2000, 32768, PROT_READ) = 0 mprotect(0xb70e3000, 4096, PROT_READ) = 0 munmap(0xb70cc000, 45329) = 0 open("/usr/lib/sasl2/libntlm.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=964, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(10, "# libntlm.la - a libtool library"..., 4096) = 964 close(10) = 0 munmap(0xb7247000, 4096) = 0 open("/usr/lib/sasl2/libntlm.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\21\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=30048, ...}) = 0 mmap2(NULL, 32928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70cf000 mmap2(0xb70d6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x6) = 0xb70d6000 close(10) = 0 mprotect(0xb70d6000, 4096, PROT_READ) = 0 getdents(9, /* 0 entries */, 32768) = 0 close(9) = 0 stat64("/etc/ldap/slapd.d", 0xbfc2b020) = -1 ENOENT (No such file or directory) stat64("/etc/ldap/slapd.conf", {st_mode=S_IFREG|0644, st_size=2787, ...}) = 0 open("/etc/ldap/slapd.conf", O_RDONLY|O_LARGEFILE) = 9 fstat64(9, {st_mode=S_IFREG|0644, st_size=2787, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(9, "pidfile /var/run/slapd/s"..., 4096) = 2787 stat64("/etc/ldap/schema/core.schema", {st_mode=S_IFREG|0777, st_size=20346, ...}) = 0 open("/etc/ldap/schema/core.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=20346, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# OpenLDAP Core schema\n# $OpenLD"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.44{64} )\n\natt"..., 4096) = 4096 read(10, "C2256: supported application con"..., 4096) = 4096 read(10, "schema\n#objectclass ( 2.5.6.0 NA"..., 4096) = 4096 read(10, "Certificate )\n\nobjectclass ( 2.5"..., 4096) = 3962 brk(0x8919000) = 0x8919000 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/cosine.schema", {st_mode=S_IFREG|0777, st_size=14030, ...}) = 0 open("/etc/ldap/schema/cosine.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=14030, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# RFC1274: Cosine and Internet X"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.15{256} )\n\nat"..., 4096) = 4096 read(10, "1.1.15 )\n\nattributetype ( 0.9.23"..., 4096) = 4096 read(10, "$\n\t\tphysicalDeliveryOfficeName $"..., 4096) = 1742 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/mod_vhost_ldap.schema", {st_mode=S_IFREG|0777, st_size=2100, ...}) = 0 open("/etc/ldap/schema/mod_vhost_ldap.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=2100, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "##\n## OIDs are owned by Globe In"..., 4096) = 2100 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/nis.schema", {st_mode=S_IFREG|0777, st_size=7723, ...}) = 0 open("/etc/ldap/schema/nis.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=7723, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# $OpenLDAP: pkg/ldap/servers/sl"..., 4096) = 4096 read(10, "etype ( 1.3.6.1.1.1.1.18 NAME 'o"..., 4096) = 3627 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/inetorgperson.schema", {st_mode=S_IFREG|0777, st_size=6360, ...}) = 0 open("/etc/ldap/schema/inetorgperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=6360, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# inetorgperson.schema -- InetOr"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.15\n\tSINGLE-VA"..., 4096) = 2264 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/evolutionperson.schema", {st_mode=S_IFREG|0777, st_size=6659, ...}) = 0 open("/etc/ldap/schema/evolutionperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=6659, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# Depends upon\n# Definition "..., 4096) = 4096 read(10, "6.1.2.23\n\tNAME 'categories'\n\tEQU"..., 4096) = 2563 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/postfix.schema", {st_mode=S_IFREG|0777, st_size=142898, ...}) = 0 open("/etc/ldap/schema/postfix.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=142898, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# Extensions to support Postfix "..., 4096) = 4096 read(10, "butetype (1.1.2.1.1.10.1.21 NAME"..., 4096) = 4096 read(10, "Recipient'\n DESC 'Antivirus n"..., 4096) = 4096 read(10, ".3.6.1.4.1.1466.115.121.1.26 SIN"..., 4096) = 4096 read(10, "onf'\n EQUALITY caseIgnoreIA5M"..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, ".4.1.1466.115.121.1.26 SINGLE-VA"..., 4096) = 4096 read(10, "-------\nattributetype (1.1.2.1.1"..., 4096) = 4096 read(10, "caseIgnoreIA5Match\n SYNTAX 1."..., 4096) = 4096 read(10, "EQUALITY caseIgnoreIA5Match\n "..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 brk(0x893a000) = 0x893a000 read(10, "--------------------------------"..., 4096) = 4096 read(10, "-------------------------\nattrib"..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, "ALITY caseIgnoreIA5Match\n SYN"..., 4096) = 4096 read(10, "NTAX 1.3.6.1.4.1.1466.115.121.1."..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, ".1.26 SINGLE-VALUE)\n#-----------"..., 4096) = 4096 read(10, "E-VALUE)\n#----------------------"..., 4096) = 4096 read(10, "sDay'\n DESC 'How long the log"..., 4096) = 4096 read(10, "d the squid settings'\n# EQUAL"..., 4096) = 4096 read(10, "1.1.10.1.346 NAME 'AlternateSmtp"..., 4096) = 4096 read(10, "attributetype (1.1.2.1.1.10.1.36"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.7\n SINGLE-VA"..., 4096) = 4096 read(10, "---------------------\n\n\n#deleted"..., 4096) = 4096 read(10, "assList $ PostFixRestrictionClas"..., 4096) = 4096 read(10, "n distributions lists'\n\tSUP top\n"..., 4096) = 4096 read(10, "SC 'DansGuardian Master configur"..., 4096) = 4096 read(10, "inAccount $ ClamavMilterEnabled "..., 4096) = 4096 read(10, "ternet $ \n\tAlternateSmtpRelay $ "..., 4096) = 4096 read(10, "Infos'\n \tDESC 'Postfix smtp_s"..., 4096) = 4096 brk(0x895b000) = 0x895b000 read(10, "count'\n DESC 'master user Obj"..., 4096) = 4096 read(10, " ( 1.3.6.1.4.1.15312.2.2.1.21\n "..., 4096) = 4096 read(10, "ain'\n DESC 'OBM domain for th"..., 4096) = 4096 read(10, "69.1.1.1.6\n NAME 'myDesti"..., 4096) = 3634 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dhcp.schema", {st_mode=S_IFREG|0777, st_size=21482, ...}) = 0 open("/etc/ldap/schema/dhcp.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=21482, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 2.16.840.1.11371"..., 4096) = 4096 read(10, "N' \n\tEQUALITY distinguishedNameM"..., 4096) = 4096 read(10, "r) to this name.' \n\tSYNTAX 1.3.6"..., 4096) = 4096 read(10, "EQUALITY distinguishedNameMatch "..., 4096) = 4096 read(10, "ements $ dhcpComments $ dhcpOpti"..., 4096) = 4096 read(10, "13719.1.203.6.15 \n\tNAME 'dhcpFai"..., 4096) = 1002 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/samba.schema", {st_mode=S_IFREG|0777, st_size=19424, ...}) = 0 open("/etc/ldap/schema/samba.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=19424, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "##\n## schema file for OpenLDAP 2"..., 4096) = 4096 read(10, "ributetype ( 1.3.6.1.4.1.7165.2."..., 4096) = 4096 read(10, "4.1.7165.2.1.32 NAME 'sambaKicko"..., 4096) = 4096 read(10, "1.42 NAME 'sambaOptionName'\n\tDES"..., 4096) = 4096 read(10, "ds\n## compatibility with 2.2 ins"..., 4096) = 3040 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/ISPEnv.schema", {st_mode=S_IFREG|0777, st_size=1443, ...}) = 0 open("/etc/ldap/schema/ISPEnv.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1443, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.1104"..., 4096) = 1443 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/mozilla-thunderbird.schema", {st_mode=S_IFREG|0777, st_size=3380, ...}) = 0 open("/etc/ldap/schema/mozilla-thunderbird.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=3380, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# mozillaOrgPerson schema v. 0"..., 4096) = 3380 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/officeperson.schema", {st_mode=S_IFREG|0777, st_size=1029, ...}) = 0 open("/etc/ldap/schema/officeperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1029, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.4203"..., 4096) = 1029 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/pureftpd.schema", {st_mode=S_IFREG|0777, st_size=2548, ...}) = 0 open("/etc/ldap/schema/pureftpd.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=2548, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# pureftpd.schema\n#\n# Pure-FTP"..., 4096) = 2548 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/joomla.schema", {st_mode=S_IFREG|0777, st_size=1348, ...}) = 0 open("/etc/ldap/schema/joomla.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1348, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# Joomla Group Attribute; free f"..., 4096) = 1348 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/autofs.schema", {st_mode=S_IFREG|0777, st_size=830, ...}) = 0 open("/etc/ldap/schema/autofs.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=830, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# $id$\n#\n# Depends upon core.s"..., 4096) = 830 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dnsdomain2.schema", {st_mode=S_IFREG|0777, st_size=4044, ...}) = 0 open("/etc/ldap/schema/dnsdomain2.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=4044, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# A schema for storing DNS zones"..., 4096) = 4044 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/zarafa.schema", {st_mode=S_IFREG|0777, st_size=7268, ...}) = 0 open("/etc/ldap/schema/zarafa.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=7268, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.2627"..., 4096) = 4096 brk(0x897c000) = 0x897c000 read(10, ".4.1.1466.115.121.1.15\n\t)\n\nattri"..., 4096) = 3172 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dyngroup.schema", {st_mode=S_IFREG|0444, st_size=3376, ...}) = 0 open("/etc/ldap/schema/dyngroup.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0444, st_size=3376, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# dyngroup.schema -- Dynamic Gro"..., 4096) = 3376 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 open("/usr/lib/ldap/back_hdb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1106, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# back_hdb.la - a libtool librar"..., 4096) = 1106 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 open("/usr/lib/ldap/back_hdb-2.4.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 J\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=186696, ...}) = 0 mmap2(NULL, 239408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6f3f000 mmap2(0xb6f6c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2c) = 0xb6f6c000 mmap2(0xb6f6e000, 46896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f6e000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb6f33000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.7.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\204\1\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1386564, ...}) = 0 mmap2(NULL, 1389884, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6ddf000 mmap2(0xb6f30000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x150) = 0xb6f30000 close(10) = 0 mprotect(0xb6f30000, 8192, PROT_READ) = 0 mprotect(0xb6f6c000, 4096, PROT_READ) = 0 munmap(0xb6f33000, 45329) = 0 open("/var/lib/ldap/DUMMY", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 10 close(10) = 0 unlink("/var/lib/ldap/DUMMY") = 0 open("/var/lib/ldap/DB_CONFIG", O_RDONLY|O_LARGEFILE) = 10 close(10) = 0 time(NULL) = 1298368863 read(9, "", 4096) = 0 read(9, "", 4096) = 0 close(9) = 0 munmap(0xb7247000, 4096) = 0 access("/etc/gcrypt/fips_enabled", F_OK) = -1 ENOENT (No such file or directory) open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 9 fstat64(9, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(9, "0\n", 1024) = 2 close(9) = 0 munmap(0xb7247000, 4096) = 0 brk(0x899d000) = 0x899d000 access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 time(NULL) = 1298368863 open("/dev/urandom", O_RDONLY) = 9 fcntl64(9, F_GETFD) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999998}) read(9, "V\355n\346\250\277C\236\242\22\216\376\207\213\315#\220\177\300\200X\302\26097F-y\347V\33@"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\\hu\244\247j5^\374\5\250\316\227`F_\nU\302\244d\365\246\267\266\276\312\350\330%\tP"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\371\350I=\343\17_\222b\\\177U\236\341\256\333\212\215DP;\375|\366\7y4\257d\343\343="..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "7\307\214\372Ll\213\270\270\267\202\256c,\256\260\337(\\\210\202\234\313\267|Q/-\315\356\33\325"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\270\275\236\343\347O\226o\342gi\305i\300\3464?~\v\347\271\34\271\264\177\222\245u%&\222\7"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\372%\231\247i\222\\\6D\267\265mc\02159u\334P(\\~P\f\266\256\213\255\3267\3037"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "=u\216J|\267cm\345\356L\312\17`\215\304\227\220W\24\315}\315\227_-\245.tg{\366"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\256\r\323\304\233\362\34\334]w\232T\226\341|Ms\240G\261\361\374\364\v\256\304\260J\232fvQ"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\36%\300\25\340\210\231HP\304\300\227\6dm\270\33\22\367J\251\303(\231d\235ku\330\307\245["..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "k\244\242\6,!\0306\fZ\356\321\263s\35\17v,\350d\335_;\263d\265\343X-jcn"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\n\35\200Q:\226\22\226\33\340\322f\216`\350\210\316\277\4y\272\206uQ5#\342@\326B\236$"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\363\302E\334\357\355;\272\325\205MN_\261oX\216\26kpr\350s\302J0n\341\326\365J*"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\rY\301\t\34\334\200\275u\316\31\234\242b\336\246\264p\203>\261yq\2333\27\203/t\355\254\224"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "g\227[\233s%\34wI\245HE\3\347\200\32\364\20QF\4l7\7oD\240_\243j\0055"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\351o\341\235\247\375.\333\325\374\337\265\352\330\\\36\365\241\200\201\233 Z'g\304\312\326\222!\333\345"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\320\334\21\35\377s\353o\2745\313\200\263\305\253em\331dp\377e\267\323\26\32\202\211\7\262g\37"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\320\toN\301\312@;T\206\326\321s\321\244\244\216\341\350p\216=\277_$\26\331;K2\275\342"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\234\230\20686 \245i<\31~N\"ylw\262\307r6B\vg\243d\226\215E7\233\260u"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "1B\"%?J\343\6\206?\263\372\363 \316l\3059\36\251\2016\360\374[\225\236\35\321\313?_"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\323\6\325\222g\353\177\363\3725\250\271e\3309\235u\30\226\200\304\214\23\v\331m\23~N\205\245\346"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\252\f@\337\6\377\341\377\254 \212\253\216*\3244}I\261\257\352UV4%\30z\350\260\375\332\201"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\24\340jX\354(\257\236\363\275\217\341caE\376\n\307\253A\361\17\357\222{\0064\f\322\\@3"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\276\237\35\256\211z\203z\241\205\365\234\363\374\344T%\362\34\327iq5U\224\323\271Y\277\235n\220"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "~)\"\357\21$\222W\314\270\221\311\245\275\253N\351\341(\260\1W?\5\210-n\311\10\3\230f"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "Ilo\36\377i\v\rd\244\253j\2354\274\227\351\311D\31\201\305\\@\263\367\10\202Q\3750\305"..., 120) = 120 gettimeofday({1298368863, 23980}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 24001}, ru_stime={0, 8000}, ...}) = 0 time(NULL) = 1298368863 times({tms_utime=2, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1724596866 gettimeofday({1298368863, 24186}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 24001}, ru_stime={0, 8000}, ...}) = 0 time(NULL) = 1298368863 times({tms_utime=2, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1724596866 rt_sigaction(SIGUSR1, {0x8072800, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGUSR2, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGHUP, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTRAP, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGCHLD, {0x805d190, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb726a768) = 13602 exit_group(0) = ?

1 0

(ITS#6841) slapd segfault error 7
by andre.bolinhas＠hotmail.com 21 Feb '11

21 Feb '11

Full_Name: André Bolinhas Version: 2.4.24 OS: ubuntu 10.4 x86 URL: Submission from: (NULL) (217.129.0.33) Dear, My ldap crash every 2 minutes, I get this error on syslog kernel: [35483.930213] slapd[3892]: segfault at 8127238 ip 080c6fcc sp b60ffb00 error 7 in slapd[8048000+123000] How can help to solve this problem ? Best regards André Bolinhas

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began working again), the following entries popped up in the log: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get the following error on the CLI (and this is with a successful bind as the directory admin): ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid No such object (32) Matched DN: dc=example,dc=com Debugging logs generated by that query can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t…

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began working again), the following entries popped up in the log: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get the following error on the CLI (and this is with a successful bind as the directory admin): ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid No such object (32) Matched DN: dc=example,dc=com Debugging logs generated by that query can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t…

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Additionally, today I found myself in a situation where reversing the order of *just* the objectClasses in the filter - i.e., from (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) to (&(|(objectClass=bar)(objectClass=foo))(uid=jdoe1)) - didn't fix things, but changing the search base (from ou=Users,dc=example,dc=com to dc=example,dc=com) did. I was then able to issue the original search with searchbase ou=Users,dc=example,dc=com and filter (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) and it worked fine.

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Additionally, today I found myself in a situation where reversing the order of *just* the objectClasses in the filter - i.e., from (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) to (&(|(objectClass=bar)(objectClass=foo))(uid=jdoe1)) - didn't fix things, but changing the search base (from ou=Users,dc=example,dc=com to dc=example,dc=com) did. I was then able to issue the original search with searchbase ou=Users,dc=example,dc=com and filter (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) and it worked fine. Strange...

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

I just uploaded two log file snippets for consideration (also posted to ITS#6831, since there has not been a formal merge or acceptance of the two being one and the same). One is a failed query to the proxycache database exhibiting this problem, and the other is a successful query to the same proxycache database. A gzipp'ed tarball can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-logs-for-comp…. For reference, the queries issued and results for each were: ## Failed query ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid ## Successful query ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 The cache reported both to be "ANSWERABLE" before attempting to retrieve the data. Up until the point where the unsuccessful query fails to read the key for the UID equality candidate, both the failed query and the successful query lock the same exact QC index (0x7f50429860f0), attempt to fetch the exact same keys ([b49d1940], [807e234d], [8f951c4a]), and compare the exact same equality/filter/list candidates ("id=9, first=2699, last=2731"). This is what I would expect, since the values for the two objectClasses in the search filter are the same. However, once it gets to the point where it compares the bdb_equality_candidates for the UID, the values of the bdb_filter_candidates, bdb_equality_candidates, and bdb_list_candidates in logs for the unsuccessful query are a little confusing: ## UID portion of unsuccessful query Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:02:00 blog2 slapd[18797]: EQUALITY Feb 21 10:02:00 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:02:00 blog2 slapd[18797]: => key_read Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [efb8b856] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=0, first=0, last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: bdb_search_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: hdb_search: no candidates ## UID portion of successful query Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:06:22 blog2 slapd[18797]: EQUALITY Feb 21 10:06:22 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:06:22 blog2 slapd[18797]: => key_read Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [ea38ed84] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 1 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=1, first=2701, last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: bdb_search_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: => test_filter I gather that a value of "0" for id/first/last is normal when it cannot find the index in question (as it does for the UID value that it had deemed to be answerable), but the "first=2" and "first=2699" values seem a little strange, especially since the "first=2699" value supposedly matches the bdb_equality_candidates "first" value found at one of the indices searched for the objectClass attribute(s). I have no idea where the value "2" comes from, but it too seems incorrect if it couldn't find the index. Perhaps those values make more sense in the context of it thinking it could find the values, but then ultimately not being able to (though I admit that sounds like a pretty big stretch). Unfortunately, I don't understand enough about what's going here, or where things might be going awry in the codebase, to abstract something more meaningful from these logs, but hopefully this provides a little bit of framing/contextual information to someone else that does. Cheers

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

I just uploaded two log file snippets for consideration. One is a failed query to the proxycache database exhibiting this problem, and the other is a successful query to the proxycache database. A gzipp'ed tarball can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-logs-for-comp…. Up until the point where the unsuccessful query fails to read the key for the UID equality candidate, both the failed query and the successful query are locking the same exact QC index (0x7f50429860f0), trying to fetch the exact same keys ([b49d1940], [807e234d], [8f951c4a]), and comparing the same equality/filter/list candidates ("id=9, first=2699, last=2731"). This is what I would expect, since the values for the two objectClasses in the search filter are the same. However, once it gets to the point where it compares the bdb_equality_candidates for the UID, the values of the bdb_filter_candidates, bdb_equality_candidates, and bdb_list_candidates in logs for the unsuccessful query are a little confusing. I gather that a value of "0" for id/first/last is normal when it cannot find the index in question (as it does for the UID value that it said was "ANSWERABLE" but was unable to find), but the "first=2" and "first=2699" values seem a little strange, especially since the "first=2699" value supposedly matches the bdb_equality_candidates value found at one of the indices for the objectClass searches. I have no idea where the value "2" comes from, but it too seems out of place if it couldn't find the index. Perhaps those values make more sense in the context where it thought it *could* find the values, but then wasn't able to (though I admit that sounds like a pretty big stretch). ## UID portion of unsuccessful query Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:02:00 blog2 slapd[18797]: EQUALITY Feb 21 10:02:00 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:02:00 blog2 slapd[18797]: => key_read Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [efb8b856] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=0, first=0, last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: bdb_search_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: hdb_search: no candidates ## UID portion of successful query Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:06:22 blog2 slapd[18797]: EQUALITY Feb 21 10:06:22 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:06:22 blog2 slapd[18797]: => key_read Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [ea38ed84] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 1 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=1, first=2701, last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: bdb_search_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: => test_filter I unfortunately don't have enough knowledge about what's going here, or where things go awry in the codebase, to abstract something more meaningful from these logs, but hopefully this provides a little bit of framing/contextual information to someone else that does.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 18 Feb '11

18 Feb '11

masarati(a)aero.polimi.it wrote: > >> The cleanest solution would probably be to make olcChainDatabase >> structural, >> copying all of the attributes of olcLDAPConfig into it, and dropping >> olcLDAPConfig itself from this situation. Too bad changing that now would >> break existing deployments. > >> From a protocol point of view, olcChainDatabase could be derived from > olcLDAPConfig; at this point the two could coexist in existing > deployments. back-config could take care of objectClass inheritance while > selecting configuration tables. back-config already uses inheritance to order the objectClasses. But I think it may be happening too late to address this. Still looking, probably a simple fix in that case. -- -- 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#6837) slapd doesn't start anymore after adding olcChainDatabase
by masarati＠aero.polimi.it 18 Feb '11

18 Feb '11

> The cleanest solution would probably be to make olcChainDatabase > structural, > copying all of the attributes of olcLDAPConfig into it, and dropping > olcLDAPConfig itself from this situation. Too bad changing that now would > break existing deployments. >From a protocol point of view, olcChainDatabase could be derived from olcLDAPConfig; at this point the two could coexist in existing deployments. back-config could take care of objectClass inheritance while selecting configuration tables. p.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 18 Feb '11

18 Feb '11

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.243.151) > > > After adding the following LDIF to cn=config (via ldapadd), slapd does not start > anymore: > ------------------------------------ > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcChainConfig > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcLDAPConfig > objectclass: olcChainDatabase > olcDbUri: ldap://ldap.server > olcDatbase: {0}ldap > ------------------------------------ > > To add some fun. Everything works as expected if I reorder the "objectClass" > Values so that "olcLDAPConfig" appears after "olcChainDatabase". > > Additionally the error messages I get in the log when slapd fails to start with > the above config seem to be completely unrelated: > ------ > olcRootPW: value #0:<olcRootPW> can only be set when rootdn is under suffix > config error processing olcDatabase={0}config,cn=config:<olcRootPW> can only be > set when rootdn is under suffix > ------ > > The underlying problem seems to be that, when the "olcLDAPConfig" objectclass > appears first slapd seems to choose the wrong ConfigTable for the olcDatabase > attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as > defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the > LDAP Database as if it were in "normal" database, including adding it to the > backendDB list. As I configured the chain overlay as a global overlay this > back-ldap database is put to the front of the backendDB list leading to problems > when initializing the cn=config database itself, because the code assumes that > the config database is always the first one, which will than lead to the strange > error message above. > > (... that's how far I got with analyzing the problem, I have no idea yet how to > fix it though. Suggestions are welcome.) > The cleanest solution would probably be to make olcChainDatabase structural, copying all of the attributes of olcLDAPConfig into it, and dropping olcLDAPConfig itself from this situation. Too bad changing that now would break existing deployments. I'll look into this some more. -- -- 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#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by hyc＠symas.com 18 Feb '11

18 Feb '11

Andrew Findlay wrote: > On Thu, Feb 17, 2011 at 04:21:35PM -0800, Howard Chu wrote: > >>> URL: ftp://ftp.openldap.org/incoming/afindlay-slapi-doc-patch-20110217a > >> This patch fails to apply to HEAD. Please re-read the contributing >> guidelines; all patches must be against HEAD. > > It applies perfectly to the copy of HEAD that I downloaded this > morning: Strange. Must have had some end-of-line issues here. re: TLS Authentication Identity Format Strictly speaking, the order of components is not changed at all. The sequence of RDNs in the DN is what it is; just that the convention for *displaying* it is ass-backwards in LDAP. I'm afraid the wording here will confuse people into thinking that the *semantics* of the DN are changed, when it's only a display issue. > andrew@slab:~/src/openldap-head> cvs -z3 checkout -P -rHEAD openldap > ... much logging deleted ... > andrew@slab:~/src/openldap-head> cd openldap > andrew@slab:~/src/openldap-head/openldap> patch -b -p0< ../afindlay-slapi-doc-patch-20110217a > patching file doc/man/man8/slapd.8 > patching file doc/guide/admin/runningslapd.sdf > patching file doc/guide/admin/sasl.sdf > patching file doc/guide/preamble.sdf > > Andrew -- -- 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#6838) TLS client will not accept certificate for 'localhost'
by Kurt＠OpenLDAP.org 18 Feb '11

18 Feb '11

And, for the OP, I suggest issuing your test certificates for the FQDN = "test" and then setting up name service to resolve this to local host. = Using "test" indicates that the scope of name is limited to some = infrastructure used for testing (and is not a name used on the public = Internet). -- Kurt=

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs