openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6412) compute loop in openldap 2.4.20
by aej＠wpi.edu 03 Dec '09

03 Dec '09

Full_Name: Allan E. Johannesen Version: 2.4.20 OS: RedHat Linux URL: http://users.wpi.edu/~aej/typescript.txt Submission from: (NULL) (130.215.36.68) In one server environment, I've found that slapd starts consuming CPU. I ran it -d-1 and it seemed to run ok. Then I tried -d1. That usually worked, but on one occasion it ran away, too. I think debugging affects the timing. My belief is that it's in a certificate retry loop of some sort. I'll attach a log of the -d1 output showing some cert retries. This run didn't go into the loop, though. The one debug -d1 which went into a compute loop was spewing these. I managed to ^C it, but also managed to delete the typescript, so I can't show the thousands of retries on the one connection which had kept it busy.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 03 Dec '09

03 Dec '09

--0016367f92e6a19d180479d1aa27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached to the configuration file server testing openldap squeeze. I made some changes to the file /etc/ldap/slapd.overlay.conf being included by /etc/ldap/slapd.conf and discovered that the problem is with the overlay rwm, because when I comment that overlay the problem does not appear. If I keep the following entries rwm overlay the problem happen again: moduleload rwm overlay rwm Even with the other settings overlay rwm commented the problem continues. Any ideas? 2009/12/2 Howard Chu <hyc(a)symas.com>: > jarbas.junior(a)gmail.com wrote: >> >> Full_Name: Jarbas Peixoto Junior >> Version: 2.4.11 / 2.4.17 / 2.4.20 >> OS: Gnu/Linux Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (200.152.34.143) >> >> >> Possible bug in Overlay pPolicy >> >> I have OpenLDAP installed via the Debian Lenny package functioning >> normally. >> >> Aiming to test the version of Debian Squeeze in the test machine install= ed >> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >> >> However, when testing the overlay pPolicy noticed that a wrong password >> authentication, runs all objects in the ldap database, causing a "delay" >> that >> does not exist in version Lenny. >> >> Below is some information that may be useful in detecting the problem: >> >> File: slapd.conf >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> moduleload =A0 =A0 =A0ppolicy >> overlay ppolicy >> ppolicy_default >> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,dc=3Dbr" >> ppolicy_use_lockout >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov,= dc=3Dbr >> '(cn=3Ddefault)' >> dn: >> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dpreviden= cia,dc=3Dgov,d >> =A0c=3Dbr >> objectClass: top >> objectClass: device >> objectClass: pwdPolicy >> pwdAttribute: userPassword >> description:: >> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >> pwdAllowUserChange: TRUE >> pwdFailureCountInterval: 3600 >> pwdGraceAuthNLimit: 5 >> pwdInHistory: 0 >> pwdLockoutDuration: 60 >> pwdMaxAge: 7776000 >> pwdMinAge: 0 >> pwdMinLength: 6 >> pwdSafeModify: FALSE >> pwdCheckQuality: 1 >> pwdExpireWarning: 600 >> cn: default >> pwdMustChange: FALSE >> pwdMaxFailure: 10 >> pwdLockout: FALSE >> >> date ; ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgo= v,dc=3Dbr -w >> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >> pwdAccountLockedTime modifyTimeStamp ; date >> Qua Dez =A02 16:14:56 AMST 2009 >> ldap_bind: Invalid credentials (49) >> Qua Dez =A02 16:15:36 AMST 2009 >> >> grep 'access_allowed: search access to' /var/log/debug | wc -l >> 83714 >> >> The question is: why access all entries in LDAP? > > Don't know. This would have to be the result of a search operation, but > there is no search code in ppolicy.c. Since ppolicy cannot be the culprit= , > we'll need to see the rest of your config to track down the issue. > > -- > =A0-- Howard Chu > =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ > --0016367f92e6a19d180479d1aa27 Content-Type: application/x-gzip; name="ldap-squeeze.tgz" Content-Disposition: attachment; filename="ldap-squeeze.tgz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2rgwh8a1 H4sIAISmF0sAA+1aW28bxxXWK/dXDCgjIhNSInVLakBAGUpKhFKXiLJjN06N4e6QnHh3Zz2zK4lu +hP6H5r2IciDn4K+9JV/rN+ZvZDUxVEQKgWKPZDBuZ4558y5ztr4PPLWXRUOVx4NWoDdVmultb2z s9napn4bf3Ycv+32p7sr7fZWa+fTzS1qt9o7ra3NFdZ6PJJmkJiYa8ZWvuN6wM16JOS1itXtdfsq 4DJkz4zQ5veg63eCVdbRbxN5qZ6yDRG7G77How1TKIWz6qyyAxNrHk9/GknOPMGO5Ujz6Y/Tfynm KYN/gQwlGl/L0FNXhkVcc9YjPH0eDPhTYNj7DeCkFAg2/YkpxlNqiQ6iT46SnJZIy9CVEfdBEbMc UCNI/Fg2Aw4EuvniBXA9F99xNuOwtlNPKVYDLGG4ZMNkOFQ6ILz/FmYdMnBWV9m+1CKWl9ywL3w1 wDIMLgWIwX0xhBDTA4m3vjsWAWcCVH0n3Ljrc2Mc8OcnmMxh7sLs8g1XabGeth+y2MiwWL76i+tD aR6MWw/dza3Wp4NfsQW0xEqPIpiXCh+86y3uy09gkw/eEY2j0RV3XZWE8a/bBG2JufvwTYa0/8Gr vUk40iqJHk5TpHzpTvL1UKJMaTzOzrS4lJ6APXBWi9A55rFuMGqdyDhtdKNhgwFp/ZeP8pXL/bmD TkOsFiae/sDslHzHYWoz41yLpLdWmKGD3lD6c/gvud7QSZj6mczbYBGh7kn4Y7IArkdJIMIYjuVt IpixJg4r4ORzUoNluHewqbSDxWb+iDtPoEV0xMn0/aXw6QxfjRjEBJfRZJfkFqz1i2DRPTirWOcL 2pMBSIwNw4HkMbjrO3cvoBkncxzTn7WEiHLBgRmwEUx/9hKffKgMp/8MJEzSCRSGRMTjcWUjMXrD lwN7F4TpOF/PiXXQ6XKtxYhEku3zFfcqA+6+eT32BlaeaqSGQ+sufQlxCvJuHH6MThWRktbdtHcY nHhCwq5ttVrAPkrgzA10w/Ph9QKhkphhhlB+lfAwlh7HPk2yI9xRsjZ3T0ksrU7w7KYQGMR16qad WCm/GY+x0zOVbau2ImbxWLAwCQaQpxqybJrFin22zlgPNyeyQXbJ/cQy4aJrbBSIwZdUIVDx0GOh iqUrB/6EySCCvTK4FOvOQ1c4+cGVz3Dyb4lKc/GJOKAwFE5/5FCki15/o9/vsdoFhkykdMx6Vjf6 wk20jCcbtgEfr9w3AmrS4xOh6w72dTtdoWM5lC6PxSHp85wpGn/DxazZ6Haa1ECqEthND9gSBDRw 37Y/ickdOxFPLzGZ730jJvnW50LL4aRr9Ylx31dXNkAekRux9w+NiBXdfqfbW16YLELUzUQF3lwY k+YrdBpJOs0JDkyE5ntiM9XEz2EaIrSZQSwjxWAlT5dF4KozSLFXKqnxfYgSeyrb5zEfkBavtpgb 7qUZzVNWO7/oPmXnSdi8gOk1u3miQ1peXx65jpcfnx7sOFqp2AsZq4IY7sElNAqqqnYyumLsr/3+ l52/vbDJVL9/SAbb3vyMKc1GMC5yiXAqiMke2a9JdT29ImzAUIHSMZlFMANT9cXrARzFHnD9Stm1 mefuRbOQ10B3pC7pZ6CXJq45eWX3yzrMEgCV9Aof75hkOJTXlUr1A0RVrR+NPbsXVqStr4RDD0RA WLjjckRbI9+JyiYVSXcthw5P34eedMX8Tjjw62qxu5qqPei1rnyGdddiBVoMuG8YAgFs+WosQrgq zXa33zBilg0mFDGucElwsrhibMhCBYbHRDMskK76aiyBifYqF5dK0VGb2LHYLfLK7nZlx7r7BA45 Mcn0B4qIYCKXaqZ9kBw05JiHfCR044NCTDWyUik08kWRnVCQTLMRG+A8mzZkkXcoDVSJkgtKMwL+ ToQ2hNIlukhCJ5WqTSDy0LtRtf5t+ncrbMNCQcps6Sfvxjo+oqVhtJTOyJWV8hTl4WqsSWR7PTlE 5CZevDQCw1/gTxEeW9MESKNAe4TcLitA2BAUBmSjBsUMZ9N/pGpns4Jl6bYN0chc5uqNRiK9ExuT G6OiBTXDD2ayVkNdhUJXxNsCA82ZsEGJOfZdijCEqBueNJHPJydoVypY3jDJoNji4tItpOMNHkVa XafTFZtG94/2G7aRluGEJu1/QTnzxSTKulhHGWRBT8Vm7p003bfL5gf6SNMSY88taPGED6L15BhX 1+Dz6xoqaagGkM/WV4jLDqWByKlEx/M0FMOyfqj0FdfI60bZ6MIhAu5OTYTIhFpk6HmCnuXni5Sl qyBVavRJb9INp3QDtrUvfGSDME277z6VTV2CmYQupHyJjOVc5NoG44AG2jmNwYxJ8jiTbv+kYRvP nh3tZ5d1M+xDceeL8qyWPX1+cN7rvFxeInBfHqBwb9CxIhFYzEj6L0+65wdnvYx/JCgQRV5BCIpN HSrvQ1vJrM2/G6w9fgqTS/whSczN8LdJEfVYhTJWy4x2s4IirWlsVRFkxxSRMB9w0ghP8d1D+Z4M Yi3EXnVGWdXJi6PBhH1MlQPqvf/t21cJKyu3LWf5Z9j33+3te95/W7tbm5vZ+y89/G6ttNq7O+1W +f77e8AH3n8X3Oky3oGX50bh//Kogvj14OYSX2xXbTw5Oz99Dvy2eqF80j5KJVTzC0rTrFeH+3uX iYmEyyJBLzgQ8aVYHkE3nXUe3Z3sEmcDeaM5S80ZrBH/ZlMGnhylJj2PtW2VsMrOzk57R92Xi8zS +47yp+9jhCYb6o0Ix2llstTk9CZ32dNnwVzez35fe2LIEb9tIZG1kbztkS6eIbG9Utqj/hlWW9Kp 83kiEfHDDxcc+QGobl/7yn2jkthK5/zg8OjkYkE2kKsY6fyZLE/6fWsqIw0debzL1/QxIS6kk3XT n9c8jrUc2PotzeDziVDFY6Sr7MHVl2X86+Ob+h/wSNjiymZdnfQ0yjpB4ezF9tF4vwpyxivUhtv6 kg8kLppoW9OCallxEI5kKNYcrGguDFVUaB9aCx6sWh9CNXTaPBMG7tLw+a1deoK8jsEc1+740D4L 51ikPTah9/AavY8ivRbTH3lg82xfxJSJixHmrbTC6X8CgZOyT1Jri3XCAr3nYJtVa+sf11+9qmH/ Xu0b3nzXaf75229azT98+wmG6zRbZdUn7doior0nm/UnW5h5Wr2PzpgsOUAditrY3KLr/k8Kv0Tj HbR9X3yhILpqGcaiDaTUvpvgm+Xd3miNKS2TMHsgEdcRFV8qp1sZeW1LxvvpvI1ygdq5Anlvhq7+ ZLOgrkfvzozPCnbvLkKTuwl9OFnJPFlzx8/dZihxlcfWytcyCQRZD1XfYTf7Rnf/lc0hwN39pX7z 6lJs96rTXdVxQQjm1hjMys1Krj/OeZr1gU6XLQzC92DiXmrvOm2vtv5J/QbmRQ6wCfTfcc7dLLlh zsDci0Z+lTYLYvE4odp8ILV3L62vXn2fUWwpBEnowvHOOvbphJDPjZm5BXUUVNXaR7CeBY0EG2f2 E2r91vhRaOLbo3145Nuj9IhSrwN5Jp86Efdkq16b45r69Xouo1X27OToq2cH0KwR5EOxQDAokJuG QPqilz6TqSSrvXkeGh4hGFRS1S1iYNZNf16nr7YfeDPO1s3HSsjBcnl8cPz5wfnpIfgMwKUICj5y 4zodrjGOfsDj/JnxMThMD1PDgsdiIG807QflpnKZbZwO6dbMbDptNBE6s0zA/jeHlye9o/4F2Nuf hDyQrv0kyxa+QTwGO94k9HFQwU3ez36bdBdGxAusMJ8PhC+8Z+dHBQvlm0IJJZRQQgkllFBCCSWU UEIJJZRQQgkllFBCCSWUUEIJJZRQQgkllFBCCSWUUEIJJZRQQgn/x/Bfxxv0fABQAAA= --0016367f92e6a19d180479d1aa27--

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by hyc＠symas.com 02 Dec '09

02 Dec '09

jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) > > > Possible bug in Overlay pPolicy > > I have OpenLDAP installed via the Debian Lenny package functioning normally. > > Aiming to test the version of Debian Squeeze in the test machine installed > package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). > > However, when testing the overlay pPolicy noticed that a wrong password > authentication, runs all objects in the ldap database, causing a "delay" that > does not exist in version Lenny. > > Below is some information that may be useful in detecting the problem: > > File: slapd.conf > ==================== > moduleload ppolicy > overlay ppolicy > ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" > ppolicy_use_lockout > ==================== > > ldapsearch -LLL -x -H ldap://squeeze -b > ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br > '(cn=default)' > dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d > c=br > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: userPassword > description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= > pwdAllowUserChange: TRUE > pwdFailureCountInterval: 3600 > pwdGraceAuthNLimit: 5 > pwdInHistory: 0 > pwdLockoutDuration: 60 > pwdMaxAge: 7776000 > pwdMinAge: 0 > pwdMinLength: 6 > pwdSafeModify: FALSE > pwdCheckQuality: 1 > pwdExpireWarning: 600 > cn: default > pwdMustChange: FALSE > pwdMaxFailure: 10 > pwdLockout: FALSE > > date ; ldapsearch -LLL -x -H ldap://squeeze -b > ou=usuarios,dc=previdencia,dc=gov,dc=br -D > uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w > wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime > pwdAccountLockedTime modifyTimeStamp ; date > Qua Dez 2 16:14:56 AMST 2009 > ldap_bind: Invalid credentials (49) > Qua Dez 2 16:15:36 AMST 2009 > > grep 'access_allowed: search access to' /var/log/debug | wc -l > 83714 > > The question is: why access all entries in LDAP? Don't know. This would have to be the result of a search operation, but there is no search code in ppolicy.c. Since ppolicy cannot be the culprit, we'll need to see the rest of your config to track down the issue. -- -- 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#6411) Possible bug in Overlay pPolicy
by quanah＠zimbra.com 02 Dec '09

02 Dec '09

--On Wednesday, December 02, 2009 8:25 PM +0000 jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) ppolicy doesn't execute searches. Please provide your entire slapd.conf, minus passwords. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by hyc＠symas.com 02 Dec '09

02 Dec '09

andreas(a)canonical.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I also just uploaded a new attachment to the launchpad bug entry with the > contents of the slapd.d/ directory. Thanks, a fix was committed to HEAD yesterday. -- -- 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#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 / 2.4.17 / 2.4.20 OS: Gnu/Linux Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.34.143) Possible bug in Overlay pPolicy I have OpenLDAP installed via the Debian Lenny package functioning normally. Aiming to test the version of Debian Squeeze in the test machine installed package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). However, when testing the overlay pPolicy noticed that a wrong password authentication, runs all objects in the ldap database, causing a "delay" that does not exist in version Lenny. Below is some information that may be useful in detecting the problem: File: slapd.conf ==================== moduleload ppolicy overlay ppolicy ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" ppolicy_use_lockout ==================== ldapsearch -LLL -x -H ldap://squeeze -b ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br '(cn=default)' dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d c=br objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: userPassword description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= pwdAllowUserChange: TRUE pwdFailureCountInterval: 3600 pwdGraceAuthNLimit: 5 pwdInHistory: 0 pwdLockoutDuration: 60 pwdMaxAge: 7776000 pwdMinAge: 0 pwdMinLength: 6 pwdSafeModify: FALSE pwdCheckQuality: 1 pwdExpireWarning: 600 cn: default pwdMustChange: FALSE pwdMaxFailure: 10 pwdLockout: FALSE date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:14:56 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:15:36 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z modifyTimestamp: 20091202191724Z date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:19:03 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:19:44 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z pwdFailureTime: 20091202192051Z modifyTimestamp: 20091202192133Z I tried to identify any problems that may be in the logs. I made the following: /etc/init.d/slapd stop Stopping OpenLDAP: slapd. > /var/log/debug /etc/init.d/slapd start Starting OpenLDAP: slapd. tail /var/log/debug -n 50 Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi807249521$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=douglas.dcosta,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149827$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149622$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808649957$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=apssc-fcn333$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808638963$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=mgapssba055$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808644351$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148464$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148430$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808643444$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.udsl,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.listas,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "cn=default,ou=ldappassword,ou=politicas,ou=builtin,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: <= acl_access_allowed: granted to database root Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 op=0 RESULT tag=97 err=49 text= Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 fd=15 closed (connection lost) grep 'access_allowed: search access to' /var/log/debug | wc -l 83714 The question is: why access all entries in LDAP? Does anyone have any tips, or it may be some as yet unidentified BUG? As tests, I installed the version 2.4.20 and had the same behavior. Best Regards, Jarbas

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 02 Dec '09

02 Dec '09

I have updated to 2.4.20 and this problem gone. So this ITS could be closed.

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I applied the diff from http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c.diff?r1=1.… to 2.4.20, rebuilt and retested, it works now. Thanks! - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksWY94ACgkQeEJZs/PdwpCkoACg4xdTEzYb1QuQhjUfjtLHxSBK 74IAoMnwcVdaHsIhaiwwm8fnbx0DDgx8 =jss8 -----END PGP SIGNATURE-----

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I also just uploaded a new attachment to the launchpad bug entry with the contents of the slapd.d/ directory. - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVMTMACgkQeEJZs/PdwpAN5wCgru6E73Ex1kKdrSpwxCq6zbR9 vzcAmwczNIFgUK5w+8cz2gniT9g1NG8X =IZTr -----END PGP SIGNATURE-----

1 0

(ITS#6409) ldap_init_fd and LDAPS
by viatly.kroivets＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Vitaly Kroivets Version: 2.4.20 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) It seems that function ldap_init_fd can not be used in LDAPS connection . I tried LDAP over SSL (without start-tls), but maybe with start-tls will be same.. I copied here my program. Use it this way : a.out -H ldaps://{IP}:636 -i {your src IP} -D {user} -w {password} Thanks! ====== #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <ldap.h> char* url = NULL; char* host_uri = NULL; char* bind_dn = NULL; char* password = NULL; char* out_file = NULL; LDAP* server = NULL; LDAPURLDesc* ludp = NULL; char* attribute = NULL; char* dn = NULL; BerElement* ber = NULL; LDAPMessage* result; void OnExitHandler(); void PrintUsage(); char src_ip [64]; int main(int argc, char* argv[]) { atexit(OnExitHandler); char c; while ((c = getopt(argc, argv, "H:w:D:o:i:")) != EOF) { switch (c) { case 'H': { url = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(url, optarg); break; } case 'D': { bind_dn = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(bind_dn, optarg); break; } case 'w': { password = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(password, optarg); break; } case 'o': { out_file = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(out_file, optarg); break; } case 'i': { strncpy(src_ip, optarg, sizeof (src_ip)); break; } default: { PrintUsage(); return 1; break; } } } if (url == NULL || (bind_dn == NULL && password != NULL)) { PrintUsage(); return 1; } int rc = ldap_url_parse(url, &ludp); if (rc != 0) { fprintf(stderr, "ldap_url_parse: %s\n", ldap_err2string(rc)); return 1; } // server = ldap_init(ludp->lud_host, ludp->lud_port); // ldap_initialize is undocumented call we use instead of ldap_init // it allows to work over TLS secured connection, i.e. using ldaps:// int host_uri_len = strlen(ludp->lud_scheme) + strlen(ludp->lud_host) + 16; host_uri = (char*)malloc(sizeof(char) * host_uri_len); sprintf(host_uri, "%s://%s:%d", ludp->lud_scheme, ludp->lud_host, ludp-> lud_port); int sockfd ; printf ("%s;\n",ludp->lud_host); { // struct hostent *gethostbyname(const char *name); struct hostent *he; struct sockaddr_in their_addr; // connector's address information if ( (he=gethostbyname( ludp->lud_host )) == NULL ) { // get the host info herror("gethostbyname"); exit(1); } if ((sockfd = socket(PF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } their_addr.sin_family = AF_INET; their_addr.sin_port = htons(ludp-> lud_port); their_addr.sin_addr = *((struct in_addr *)he->h_addr); memset(their_addr.sin_zero, '\0', sizeof their_addr.sin_zero); // { struct sockaddr_in my_addr; // my address information my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = 0; // short, network byte order my_addr.sin_addr.s_addr = inet_addr(src_ip); memset(my_addr.sin_zero, '\0', sizeof my_addr.sin_zero); if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof my_addr) == -1) { perror("bind"); exit(1); } } // if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof their_addr) == -1) { perror("connect"); exit(1); } //connect mysock... printf ("init=%d\n", ldap_init_fd (sockfd , 1 ,host_uri , &server)); } /* // rc = ldap_initialize(&server, host_uri); if (rc != 0) { fprintf(stderr, "ldap_initialize: %s", (*ldap_err2string)(rc)); return 1; } */ //server->ld_conns->lconn_server = 0;//ldap_url_dup ( ludp ); rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); if (rc != 0 && rc != LDAP_SIZELIMIT_EXCEEDED) { fprintf(stderr, "ldap_search_s: %s\n", (*ldap_err2string)(rc)); return 1; } int num = ldap_count_entries(server, result); fprintf(stderr, "Number of messages: %d\n", ldap_count_messages(server, result)); if (num == 0) { fprintf(stderr, "ldap_count_entries: no entries received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_entries: more than one entry received\n"); return 1; } LDAPMessage* entryIterator = ldap_first_entry(server, result); dn = ldap_get_dn(server, entryIterator); attribute = ldap_first_attribute(server, entryIterator, &ber); if (attribute == NULL) { fprintf(stderr, "ldap_first_attribute: no attriubutes received\n"); return 1; } else if (ldap_next_attribute(server, entryIterator, ber)) { fprintf(stderr, "ldap_first_attribute: more than one attriubute received\n"); return 1; } else { BerValue** vals = ldap_get_values_len(server, entryIterator, attribute); num = ldap_count_values_len(vals); if (vals == NULL || num == 0) { fprintf(stderr, "ldap_count_values_len :no values received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_values_len :more than one value received\n"); return 1; } FILE* fo = NULL; if (out_file) { fo = fopen(out_file, "wb"); } else { fo = stdout; } fwrite(vals[0]->bv_val, 1, vals[0]->bv_len, fo); fflush(fo); fprintf(stderr, "Responce received from '%s'\n", url); if (out_file) fprintf(stderr, "Stored into %s\n", out_file); /* Free memory used to store values */ ldap_value_free_len(vals); } return 0; } void OnExitHandler() { if (result) { ldap_msgfree(result); } if (dn) ldap_memfree(dn); if (attribute) ldap_memfree(attribute); if (ber) ber_free(ber, 0); if (ludp) ldap_free_urldesc(ludp); if (server) ldap_unbind_s(server); if (url) free(url); if (host_uri) free(host_uri); if (bind_dn) free(bind_dn); if (password) free(password); if (out_file) free(out_file); } void PrintUsage() { fprintf(stderr, "Usage: ldapget -H <LDAP URI> [-o <output_file>] [-D user [-w password]] [-i src_ip_addr ] \n"); }

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs