- openldap-bugs - openldap.org

(ITS#6247)
by daniel＠pluta.biz 12 Aug '09

12 Aug '09

Hi, I've just uploaded an updated version. Changes regarding schema: - Added EQ-Matching rule to both nowNot{Before|After} attributes - changed attribute nowNotAfter from single- into multi-value ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz Best regards Daniel

1 0

(ITS#6251) GnuTLS cipher suite failure
by quanah＠zimbra.com 12 Aug '09

12 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256 OpenLDAP+gnutls worked fine for me for more than a year, but now I have TLS problems again. It started on my unstable client when libnss-ldap reported: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1 Then I upgraded gnutls and ldap on my server from lenny to unstable and now even slapd doesn't start: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1. main: TLS init def ctx failed: -1 If I comment out line which defines cipher: TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1 it works again. $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 ...so I don't see why it shouldn't work.

1 0

Re: (ITS#6248) Support multiple CA Cert directories
by hyc＠symas.com 11 Aug '09

11 Aug '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.x > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Both openssl and gnutls support loading CA certs from multiple directories. It > would be handy to be able to do this for slapd and the ldap clients. For > example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is > installed upon is going to have a different default destination for where its > ldap clients look for CA certs. By having support for the multiple paths, the > configuration can be adjusted to look in both the system location, and any > number of specialized ones. > In light of ITS#5582, this should probably wait until 2.5. I.e., we probably also want to require the OpenSSL default paths to be explicitly enabled when we allow multiple paths to be configured. E.g. we could allow "DEFAULT" to be a specially recognized token for enabling the default path. -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by Kurt＠OpenLDAP.org 11 Aug '09

11 Aug '09

RFC 3062 specifically says: This operation SHALL NOT be used anonymously. -- Kurt

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD >>>>> OS: >>>>> URL: >>>>> Submission from: (NULL) (84.163.50.194) >>>>> >>>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>>> password. >>>>> >>>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>>> setting a new password in case of an expired password. >>>> Adding this feature would open up the pwdModify exop as a mechanism for >>>> password guessing attacks. >>> There could be still the bad password counter in effect just like when >>> processing bind requests. >> >> But there is no corresponding lockout action to take when a maxfailure limit >> is reached. I.e., it is impossible to lockout "anonymous". You thus open a >> security hole that cannot be closed. > > The password modify ext.op. request contains the DN (or username) of the entry > to which the old password belongs. > > Since the old password is really checked you could apply the lockout to the > entry for which the password is going to be changed. (It fails with Server is > "unwilling to perform: unwilling to verify old password." even if the user is > bound on that connection.) You're still not thinking this through. One of the basic principles of security design is to reduce the number of possible attack surfaces. You are deliberately opening up a new attack vector with no real benefit. Since grace logins are already supported, your proposal doesn't benefit any real users. It only benefits potential attackers. 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

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. Since the ppolicy overlay already provides the facility for hashing plaintext passwords on Add and Modify, there's no reason you couldn't have just created the objects correctly in the first place. >> You should have chosen an >> objectclass (or set of objectclasses) that supports authentication from >> the outset. To me this is analogous to the usual prohibition against >> changing an object's structural class - you cannot change a car into a >> pencil. You cannot change a non-user into a user. > > Please don't compare apples with pies. It was an analogy, not a literal comparison. Don't lose the main point, which is that changing a non-user into a user is a significant change in the purpose of an object. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. I agree with Hallvard that this should be made configurable. So the admin could specify whether and which AUXILIARY object class is added. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Howard Chu wrote: > Michael Ströder wrote: >> Let's assume the policy for a deployment is that password changes MUST be >> applied by using password modify ext. op. (e.g. because smbk5pwd is >> used or >> similar) and you want to use object class 'account' for user entries. How >> could the attribute 'userPassword' be added to the user entry then? >> It's kind >> of a dead-lock situation. > > Then you made a mistake in your data design. Nope. Since with a modify request I can achieve the goal by adding object class 'simpleSecurityObject'. IMO password modify ext.op. should result in userPassword being added. One could view it as a hen-and-egg problem because 'simpleSecurityObject' is mandating 'userPassword'. > You should have chosen an > objectclass (or set of objectclasses) that supports authentication from > the outset. To me this is analogous to the usual prohibition against > changing an object's structural class - you cannot change a car into a > pencil. You cannot change a non-user into a user. Please don't compare apples with pies. 'account' is STRUCTURAL so the user entry represents already a user. 'simpleSecurityObject' is AUXILIARY (not STRUCTURAL) which adds another attribute. The STRUCTURAL object class of the entry is not altered, so no magic change from a car into a pencil here. Ciao, Michael.

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: >>>> URL: >>>> Submission from: (NULL) (84.163.50.194) >>>> >>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>> password. >>>> >>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>> setting a new password in case of an expired password. >>> Adding this feature would open up the pwdModify exop as a mechanism for >>> password guessing attacks. >> There could be still the bad password counter in effect just like when >> processing bind requests. > > But there is no corresponding lockout action to take when a maxfailure limit > is reached. I.e., it is impossible to lockout "anonymous". You thus open a > security hole that cannot be closed. The password modify ext.op. request contains the DN (or username) of the entry to which the old password belongs. Since the old password is really checked you could apply the lockout to the entry for which the password is going to be changed. (It fails with Server is "unwilling to perform: unwilling to verify old password." even if the user is bound on that connection.) Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> >>> If one trys to set the userPassword with a Password Modify ext. op. request but >>> the object classes of the entry does not allow userPassword slapd could add >>> automagically AUXILIARY object class simpleSecurityObject to the entry. >>> >>> (I'm doing this in web2ldap since years when changing the userPassword with a >>> normal modify operation which client-side hashing.) >> >> This request sounds like a mistake to me. The DSA is supposed to enforce the >> data model, not automagically enable you to bypass the model. What clients do >> is a completely separate matter... > > Let's assume the policy for a deployment is that password changes MUST be > applied by using password modify ext. op. (e.g. because smbk5pwd is used or > similar) and you want to use object class 'account' for user entries. How > could the attribute 'userPassword' be added to the user entry then? It's kind > of a dead-lock situation. Then you made a mistake in your data design. You should have chosen an objectclass (or set of objectclasses) that supports authentication from the outset. To me this is analogous to the usual prohibition against changing an object's structural class - you cannot change a car into a pencil. You cannot change a non-user into a user. -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> I'd like to request that a Password Modify ext. op. request should succeed on a >>> LDAP connection as anonymous if the LDAP client provides the correct old >>> password. >>> >>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>> setting a new password in case of an expired password. >> >> Adding this feature would open up the pwdModify exop as a mechanism for >> password guessing attacks. > > There could be still the bad password counter in effect just like when > processing bind requests. But there is no corresponding lockout action to take when a maxfailure limit is reached. I.e., it is impossible to lockout "anonymous". You thus open a security hole that cannot be closed. Again - No. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> >> If one trys to set the userPassword with a Password Modify ext. op. request but >> the object classes of the entry does not allow userPassword slapd could add >> automagically AUXILIARY object class simpleSecurityObject to the entry. >> >> (I'm doing this in web2ldap since years when changing the userPassword with a >> normal modify operation which client-side hashing.) > > This request sounds like a mistake to me. The DSA is supposed to enforce the > data model, not automagically enable you to bypass the model. What clients do > is a completely separate matter... Let's assume the policy for a deployment is that password changes MUST be applied by using password modify ext. op. (e.g. because smbk5pwd is used or similar) and you want to use object class 'account' for user entries. How could the attribute 'userPassword' be added to the user entry then? It's kind of a dead-lock situation. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

Sorry, sent too early. > It makes sense if you add a config parameter with an LDAP URL or > something describing entries which can be so modified (subject to > ordinary access controls). I imagine one would typically filter for objectClass, e.g. ldap:///???(objectClass=person)

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> I'd like to request that a Password Modify ext. op. request should succeed on a >> LDAP connection as anonymous if the LDAP client provides the correct old >> password. >> >> E.g. OpenDS implements it like this and it makes sense to me regarding a user >> setting a new password in case of an expired password. > > Adding this feature would open up the pwdModify exop as a mechanism for > password guessing attacks. There could be still the bad password counter in effect just like when processing bind requests. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

hyc(a)symas.com writes: > This request sounds like a mistake to me. The DSA is supposed to > enforce the data model, not automagically enable you to bypass the > model. What clients do is a completely separate matter... It makes sense if you add a config parameter with an LDAP URL or something describing entries which can be so modified (subject to ordinary access controls). -- Hallvard

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.50.194) > > > If one trys to set the userPassword with a Password Modify ext. op. request but > the object classes of the entry does not allow userPassword slapd could add > automagically AUXILIARY object class simpleSecurityObject to the entry. > > (I'm doing this in web2ldap since years when changing the userPassword with a > normal modify operation which client-side hashing.) This request sounds like a mistake to me. The DSA is supposed to enforce the data model, not automagically enable you to bypass the model. What clients do is a completely separate matter... -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.50.194) > > > I'd like to request that a Password Modify ext. op. request should succeed on a > LDAP connection as anonymous if the LDAP client provides the correct old > password. > > E.g. OpenDS implements it like this and it makes sense to me regarding a user > setting a new password in case of an expired password. Adding this feature would open up the pwdModify exop as a mechanism for password guessing attacks. In fact, in the next draft of the ppolicy spec I was intending to explicitly forbid this type of usage, to prevent such attacks. http://www.openldap.org/lists/ietf-ldapext/200908/msg00006.html The ppolicy spec provides for grace logins after a password is expired, to give users a few last opportunities to change their password. If they don't take advantage of those grace logins, then they are out of luck and must get help from a password administrator. I'm going to reject 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.50.194) If one trys to set the userPassword with a Password Modify ext. op. request but the object classes of the entry does not allow userPassword slapd could add automagically AUXILIARY object class simpleSecurityObject to the entry. (I'm doing this in web2ldap since years when changing the userPassword with a normal modify operation which client-side hashing.)

1 0

(ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.50.194) I'd like to request that a Password Modify ext. op. request should succeed on a LDAP connection as anonymous if the LDAP client provides the correct old password. E.g. OpenDS implements it like this and it makes sense to me regarding a user setting a new password in case of an expired password.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 11 Aug '09

11 Aug '09

On 08/11/2009 04:44 AM, Howard Chu wrote: > Ed(a)vanGasteren.net wrote: >> Full_Name: Ed van Gasteren >> Version: 2.4.12 and 2.4.15 >> OS: linux (Fedora 10, 11) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.223.76.221) >> >> >> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >> and clients. >> The configuration is such that things work as expected even with security >> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >> ldaps or with >> -ZZ), nss and gq with TLS work like a charm. >> >> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >> gq and >> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >> run slapd >> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >> trace: >> SSL_connect:SSLv3 read server certificate A". >> >> Seems as if the normal code path has a flaw which gets >> corrected/bypassed by the >> debugging code. > > Doesn't sound familiar, I've never had this problem. However, the TLS > code was refactored in rev 2.4.14, and it's always possible we missed > something in the churn. How does openssl s_client react under the same > conditions? If it hangs the same way, then that points to a bug on the Should have mentioned that. It indeed hangs the same way, in the middle of getting over the "Acceptable client certificate CA names". The last debug info from s_client suggests it is getting less of the list then in expects: read from 0x8c13300 [0x8c19915] (16384 bytes => 10395 The last one coming across correctly is: /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network The one not coming is: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com > server, and the answer is just to upgrade since .12 is rather out of Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 repo's running on lt2 first. > date now. If s_client works, then we probably have to look at our client > code. >

1 0

(ITS#6248) Support multiple CA Cert directories
by quanah＠zimbra.com 11 Aug '09

11 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.x OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Both openssl and gnutls support loading CA certs from multiple directories. It would be handy to be able to do this for slapd and the ldap clients. For example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is installed upon is going to have a different default destination for where its ldap clients look for CA certs. By having support for the multiple paths, the configuration can be adjusted to look in both the system location, and any number of specialized ones.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 11 Aug '09

11 Aug '09

Ed(a)vanGasteren.net wrote: > Full_Name: Ed van Gasteren > Version: 2.4.12 and 2.4.15 > OS: linux (Fedora 10, 11) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.223.76.221) > > > On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. > The configuration is such that things work as expected even with security > tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with > -ZZ), nss and gq with TLS work like a charm. > > On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and > Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd > with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: > SSL_connect:SSLv3 read server certificate A". > > Seems as if the normal code path has a flaw which gets corrected/bypassed by the > debugging code. Doesn't sound familiar, I've never had this problem. However, the TLS code was refactored in rev 2.4.14, and it's always possible we missed something in the churn. How does openssl s_client react under the same conditions? If it hangs the same way, then that points to a bug on the server, and the answer is just to upgrade since .12 is rather out of date now. If s_client works, then we probably have to look at our client code. -- -- 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#6247) slapd-modules/now: New matching rules that enable comparisone slapd's current server time against timestamp attributes
by daniel＠pluta.biz 10 Aug '09

10 Aug '09

Full_Name: Daniel Pluta Version: CVS OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090810.tgz Submission from: (NULL) (91.12.197.171) Please see the README for details. Currently only a DUMMY_OID is assigned to the matching rules and the limited internal attribute and objectclass definitions. I would appreciate your feedback. Thanks!

1 0

(ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 10 Aug '09

10 Aug '09

Full_Name: Ed van Gasteren Version: 2.4.12 and 2.4.15 OS: linux (Fedora 10, 11) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.223.76.221) On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. The configuration is such that things work as expected even with security tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with -ZZ), nss and gq with TLS work like a charm. On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: SSL_connect:SSLv3 read server certificate A". Seems as if the normal code path has a flaw which gets corrected/bypassed by the debugging code. What puzzels me is that I find few references (google) to these kind of problems as if nobody uses it this way. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412706 There they blame it on GnuTLS. Here the symptoms are similar but GnuTLS is not in the picture. - I have searched the openldap Mailing Lists archives for "ssl;client;server;-d 2". That gives a few hits with very similar problems but the threads provide no solution. I can provide loads of additional detail about my configuration and debug output of the server and the ldapsearch client but I prefer to get some pointers about what to test, look for or provide.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristo-jose.camarero＠ericsson.com 10 Aug '09

10 Aug '09

=20 It looks that I sent an email that was unreadable. Sorry for that. I recap the content: The traffic model we are testing contains search and modify operations. = The search response contains usually a single entry about 3KB in LDIF = format. There is only a reduce number of LDAP clients (usually one or = two), that are using async LDAP API and sending a lot of operations per = second (> 1000 TPS per client). The client side is an OS Delta box. Under these conditions we have tested that increasing the sending buffer = of the server has improved the performance. That's the reason I am = proposing this feature request. Pierangelo's proposal allowing hard-set the buffer sizes looks ok. Regards, Evaristo ----- Mensaje reenviado ---- De: Pierangelo Masarati <masarati(a)aero.polimi.it> Para: evaristojosec(a)yahoo.es CC: openldap-its(a)openldap.org Enviado: martes, 4 de agosto, 2009 9:54:19 Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST Your message was unreadable, you should use text form for messages sent = to the ITS. In any case, according to many sources, the default values for TCP = buffers can be pretty small. Usually, they can be configured = system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the = buffer sizes to values one considers appropriate for the intended use of = slapd. Since the optimal size roughly depends on latency and bandwidth, = this may probably need to be configured on a per-listener basis, = actually. However, in deployments where this problem becomes critical, usually = hardware dedicated to slapd is used, so system-wide tuning (and = auto-tuning) would be the preferred option anyway. Manual setting = should be used only when system-wide or auto-tuning is not available or = accessible for some reason. p. =20

1 0

Re: (ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 09 Aug '09

09 Aug '09

--On Saturday, August 08, 2009 10:07 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) I guess they may be liberally legal.. It also updates the contextCSN and the accesslog database. dn: reqStart=20090808223406.000005Z,cn=accesslog objectClass: auditModify reqStart: 20090808223406.000005Z reqEnd: 20090808223409.000000Z reqType: modify reqSession: 214 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: entryCSN:= 20090808223406.630393Z#000000#000#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20090808223406Z Seems janky to me. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 09 Aug '09

09 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) [zimbra@freelancer ~]$ ldapmodify -x -H ldapi:/// -D cn=config -W Enter LDAP Password: dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" Log shows it happening, too: Aug 8 15:08:50 freelancer slapd[1937]: conn=16 fd=23 ACCEPT from PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi) Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" method=128 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 RESULT tag=97 err=0 text= Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 RESULT tag=103 err=0 text= Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 RESULT tag=103 err=0 text= Aug 8 15:09:33 freelancer slapd[1937]: conn=16 fd=23 closed (connection lost)

1 0

Re: (ITS#6215) liblber problems
by Kurt＠OpenLDAP.org 07 Aug '09

07 Aug '09

On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: >> - decode.c is quite lax about what it accepts. Should we tighten >> that when feasible, or remain "liberal in what we accept"? Decoding needs to be liberal here. Otherwise interoperability will suffer as it is well established that there exists many implementations which are not strict in what they send. -- Kurt

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 07 Aug '09

07 Aug '09

Fixed the above, including malformed bitstrings and set/sequences. Except: Need decision on decode(bad INTEGER/BOOLEAN) and encode(bad tag): > - decode.c is quite lax about what it accepts. Should we tighten > that when feasible, or remain "liberal in what we accept"? > > E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and > wrong CONSTRUCTED/PRIMITIVE encoding bit. > > - encode.c willingly stores broken identifier octets if passed an > invalid tag, e.g. a single octet with low bits 0x1F implying long tag > format. I'm inclined to leave that alone, caller's responsibility. API matters: I'll export the new function ber_peek_element(). And if nobody disagrees, the matching function ber_skip_element() even though that is nearly a duplicate of ber_get_stringbv(,, LBER_BV_NOTERM). -- Hallvard

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by ryans＠aweber.com 07 Aug '09

07 Aug '09

I can confirm that the segfault on slapadd, slapcat, and friends were in fact a result of this bug. I don't have the strace handy which confirmed it, but after applying Howard's patch and repackaging the .deb (Ubuntu Jaunty), I see none of the aforementioned segfaults. Regards, Ryan -- Ryan Steele ryans-at-aweber-dot-com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 07 Aug '09

07 Aug '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > I think it is corruption because when such a fail appears it is not cleaned by slapd restart - after starting it continues to give wrong answers. The fail cleans after deleting the cache between slapd stop and start. Luben

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 07 Aug '09

07 Aug '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > > Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay > > This should not happen, since your search is performed with exactly the > same parameters used for the original one, and the scope is 1 (onelevel). > > I wonder what happens there. Could you walk through the failing request > with a debugger, and print some values? I'd like to see, from within > bdb_search(), line 780 of back-bdb/search.c of re23, the value of > > op->o_request->oq_search > > base > > *ei->ei_parent > > p. > > OK, I will try to attach a debugger when it happens. Next time I will also copy the BDB database and dump it in order to see the failing record. Luben

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> http://purgatory.spnet.net/~karavelov/faillog There is no corruption. What happens is that back-bdb, when returning the entry from the cache, correctly locates it based on the indexed attrs used in the filter, but at some point decides that the entry is outside the scope of your search: Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay This should not happen, since your search is performed with exactly the same parameters used for the original one, and the scope is 1 (onelevel). I wonder what happens there. Could you walk through the failing request with a debugger, and print some values? I'd like to see, from within bdb_search(), line 780 of back-bdb/search.c of re23, the value of op->o_request->oq_search base *ei->ei_parent p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 06 Aug '09

06 Aug '09

--On August 6, 2009 7:25:16 PM +0200 masarati(a)aero.polimi.it wrote: >> I'm also curious why back-monitor develops stats for the other caches but >> specifically not for entry cache. > > I haven't looked in detail, but it makes sense that some operation occurs > within the glue database which requires caching something, but not > entries. > > - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; > > - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which > should be the number of entryinfo structures used; > > - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. > > In my very simple tests, I only saw something populating the DN cache, > which means some internal operation required to allocate some entryinfo > structures that remain 'round. > > In any case, it's only showing information related to its database > structure, it is by no means collecting info from the glued databases. Ok, this makes sense, as the numbers it was reporting definitely seemed smaller than I was expecting. I bet they are for pieces in the rootDSE. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> > > --On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: > >>> This may be specific to glued databases (databases rooted at ""). >> >> The problem could be partially addressed by telling back-bdb (who's >> maintaining this data in the monitor backend) to check subordinates as >> soon as it discovers it's a glue instance. However, this poses two >> different problems: >> >> - is the aggregate information resulting from adding all glued databases >> cache usage still useful? >> >> - what happens if heterogeneous databases are glued? Significantly, >> what >> if the superior database is not bdb/hdb? >> >> Probably, the monitor database should also present subordinate databases >> as separate entries. > > Interestingly, in my case, there's only one real database in play for the > glue as it is, since it's rooted at "". All other database definitions > come before it (cn=config, cn=accesslog, cn=monitor). but... are you actually gluing something? In any case, this is not specific to the case of empty suffix in the glue database. I could easily reproduce it with a "normal" glued setup, and I was about to start fixing things when the two above questions came to my mind. > I'm also curious why back-monitor develops stats for the other caches but > specifically not for entry cache. I haven't looked in detail, but it makes sense that some operation occurs within the glue database which requires caching something, but not entries. - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which should be the number of entryinfo structures used; - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. In my very simple tests, I only saw something populating the DN cache, which means some internal operation required to allocate some entryinfo structures that remain 'round. In any case, it's only showing information related to its database structure, it is by no means collecting info from the glued databases. p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 06 Aug '09

06 Aug '09

--On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: >> This may be specific to glued databases (databases rooted at ""). > > The problem could be partially addressed by telling back-bdb (who's > maintaining this data in the monitor backend) to check subordinates as > soon as it discovers it's a glue instance. However, this poses two > different problems: > > - is the aggregate information resulting from adding all glued databases > cache usage still useful? > > - what happens if heterogeneous databases are glued? Significantly, what > if the superior database is not bdb/hdb? > > Probably, the monitor database should also present subordinate databases > as separate entries. Interestingly, in my case, there's only one real database in play for the glue as it is, since it's rooted at "". All other database definitions come before it (cn=config, cn=accesslog, cn=monitor). I'm also curious why back-monitor develops stats for the other caches but specifically not for entry cache. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 06 Aug '09

06 Aug '09

masarati(a)aero.polimi.it wrote: >> Here are slapd.conf and proxycache.conf as attachments. > > I just wanted to feed back before I leave for a few days. I don't see > anything critical in your files. You explicitly give the rootdn write > permissions, which is useless, but apart from this everything looks fine. > > I've tested a simple setup and it works as expected. I used HEAD and re24 > code; the latter is nearly identical to 2.4.17. I also tested with TLS. > > At this point, I'm a bit clueless. There must be something we're > overlooking. > > p. > Here is some more info, that I just discovered. If my filter rule is '(&(objectClass=sambaSamAccount)(uid=wvk))' the data is cached the first time, but not returned the second and later time. However when my filter rule is (&(objectClass=posixAccount)(uid=wvk))' it works as expected. Jim

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> Here are slapd.conf and proxycache.conf as attachments. I just wanted to feed back before I leave for a few days. I don't see anything critical in your files. You explicitly give the rootdn write permissions, which is useless, but apart from this everything looks fine. I've tested a simple setup and it works as expected. I used HEAD and re24 code; the latter is nearly identical to 2.4.17. I also tested with TLS. At this point, I'm a bit clueless. There must be something we're overlooking. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 06 Aug '09

06 Aug '09

This is a multi-part message in MIME format. --------------050103000202040305030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: > > This tells us you have some ACLs in place. Could you show them? > Actually, could you post your whole slapd.conf, if you're using any, or > the contents of your cn=config database? Of course, after removing any > sensitive information, like passwords. > > p. > Here are slapd.conf and proxycache.conf as attachments. regards, Jim vK --------------050103000202040305030502 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" # oOpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.5 2002/11/26 18:26:01 kurt Exp $tdn # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/opt/openldap/schema/DUAConfig.schema include /etc/opt/openldap/schema/misc.schema include /etc/opt/openldap/schema/core.schema include /etc/opt/openldap/schema/cosine.schema include /etc/opt/openldap/schema/inetorgperson.schema include /etc/opt/openldap/schema/solaris-nis.schema include /etc/opt/openldap/schema/solaris.schema include /etc/opt/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://feathercraft.few.vu.nl logfile /var/log/openldap threads 8 pidfile /var/opt/openldap/slapd.pid argsfile /var/opt/openldap/slapd.args # Load dynamic backend modules: modulepath /opt/openldap/openldap-2.4.16/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la #moduleload back_ldbm.la # # Sample security restrictions # # Disallow clear text exchange of passwords #disallow bind_simple_unprotected # # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! gentlehup on #TLSCipherSuite ALL:!EXP:!LOW:!ADH:@STRENGTH #TLSCACertificateFile /usr/local/ssl/certs/few-ca-cert.pem #TLSCACertificatePath /usr/local/ssl/certs #TLSCertificateFile /usr/local/ssl/certs/flits.few.vu.nl-cert.pem #TLSCertificateKeyFile /etc/opt/openldap/private/flits.few.vu.nl-key.rsa #TLSVerifyClient never ####################################################################### # ldbm database definitions ####################################################################### database config rootdn "uid=Admin,cn=config" rootpw * access to dn.subtree="cn=config" by dn.exact="uid=Admin,cn=config" write by * read database monitor rootdn "uid=Admin,cn=Monitor" rootpw * access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,cn=Monitor" write by * read include /etc/opt/openldap/proxycache.conf --------------050103000202040305030502 Content-Type: text/plain; name="proxycache.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxycache.conf" database ldap suffix "dc=few,dc=vu,dc=nl" rootdn cn=Manager,dc=few,dc=vu,dc=nl rootpw * tls start uri ldap://klondike.few.vu.nl acl-bind bindmethod=simple binddn="cn=sambaLdapManager,ou=Special Users,dc=few,dc=vu,dc=nl" credentials=* sizelimit unlimited #loglevel 4095 overlay pcache proxycache bdb 100000 10 1000 100 proxyAttrset 0 uid cn proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(uid=)(objectClass=)) 0 1800 cachesize 10000 directory /var/opt/openldap/openldap-data/proxy access to * by * read ## required to support pdb_getsampwnam ## required to support pdb_getsambapwrid() ## uncomment these if you are storing posixAccount and ## posixGroup entries in the directory as well ### required by OpenLDAP index objectclass eq index cn pres,sub,eq index sn pres,sub,eq ### required to support pdb_getsampwnam index uid pres,sub,eq ### required to support pdb_getsambapwrid() index displayName pres,sub,eq ### uncomment these if you are storing posixAccount and ### posixGroup entries in the directory as well index uidNumber eq index gidNumber eq index memberUid eq index sambaSid eq index sambaPrimaryGroupSID eq index sambaDomainName eq index queryId eq index default sub --------------050103000202040305030502--

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

> This may be specific to glued databases (databases rooted at ""). The problem could be partially addressed by telling back-bdb (who's maintaining this data in the monitor backend) to check subordinates as soon as it discovers it's a glue instance. However, this poses two different problems: - is the aggregate information resulting from adding all glued databases cache usage still useful? - what happens if heterogeneous databases are glued? Significantly, what if the superior database is not bdb/hdb? Probably, the monitor database should also present subordinate databases as separate entries. p.

1 0

(ITS#6244) "now" dynacl module
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

Full_Name: Pierangelo Masarati Version: re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c Submission from: (NULL) (93.149.38.247) Submitted by: ando This simple module implements a dynacl that allows to compare a given generalizedTime-valued attribute with "now", according to generalizedTimeOrderingMatch (greater-or-equal, less-or-equal). p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 05 Aug '09

05 Aug '09

--On August 5, 2009 5:35:57 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.235.224.133) > > > Querying back monitor to examine the values of the various caches reports > the entry cache as empty: > ># Frontend, Databases, Monitor > dn: cn=Frontend,cn=Databases,cn=Monitor > structuralObjectClass: monitoredObject > creatorsName: cn=config > modifiersName: cn=config > createTimestamp: 20090805044038Z > modifyTimestamp: 20090805044038Z > monitoredInfo: frontend > monitorIsShadow: FALSE > namingContexts: > readOnly: FALSE > olmBDBEntryCache: 0 > olmBDBDNCache: 592 > olmBDBIDLCache: 502 > olmDbDirectory: /opt/zimbra/data/ldap/hdb/db/ > entryDN: cn=Frontend,cn=Databases,cn=Monitor > subschemaSubentry: cn=Subschema > hasSubordinates: FALSE This may be specific to glued databases (databases rooted at ""). I see that it's reporting the caches as under the Frontend database, instead of the actual BDB database, which is database 3, and shows no cache information: # Database 3, Databases, Monitor dn: cn=Database 3,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: readOnly: FALSE monitorOverlay: accesslog monitorOverlay: syncprov entryDN: cn=Database 3,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE I see the same behavior on the replica, where it is Database 2 instead of database 3, as it has no accesslog DB. On the master, the accesslog DB caches are correct: # Database 2, Databases, Monitor dn: cn=Database 2,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: syncprov olmBDBEntryCache: 297 olmBDBDNCache: 517 olmBDBIDLCache: 9 olmDbDirectory: /opt/zimbra/data/ldap/accesslog/db/ entryDN: cn=Database 2,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 05 Aug '09

05 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.235.224.133) Querying back monitor to examine the values of the various caches reports the entry cache as empty: # Frontend, Databases, Monitor dn: cn=Frontend,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: frontend monitorIsShadow: FALSE namingContexts: readOnly: FALSE olmBDBEntryCache: 0 olmBDBDNCache: 592 olmBDBIDLCache: 502 olmDbDirectory: /opt/zimbra/data/ldap/hdb/db/ entryDN: cn=Frontend,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

masarati(a)aero.polimi.it wrote: > I'll look at your links later. I assume you mean libdb-4.6; is it > patched with official Oracle patches? > > p. > Yes, it is libdb-4.6.21 provided by Debian . I am not sure for the patches from Oracle. I ecounter the same corruption problem with libdb-4.7.25 and also with older verstions. luben

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

karavelov wrote: > First, thanks for the suggestions. > I have updated my config file and you could find it here: > > http://purgatory.spnet.net/~karavelov/slapd.conf.clean > > But the problem I have desctribed still persist. You could find a log here: > > http://purgatory.spnet.net/~karavelov/faillog > > the logging is set to: trace stats stats2 pcache (I believe that 0x1000 > is pcache) > > It consists of 3 parts: > > 1. First query for "justillusion.net", it is not in the cache. It hits > the SQL database and is reported to be > stored in dbd cache > 2. Some seconds later the same query fails > 3. An analogous query succeed > > I could cut more form the log file if somebody needs it. > > I do not think that the fails depend on the data being stored (no > NULLs). Some different records get corrupted > and I do not see nothing common that could be the cause of the > corruption. Just in differend times, differend > records get corrupted. > > This is slapd-2.4.17 + patch from head (back-sql/search.c), libdbd-4.6 I'll look at your links later. I assume you mean libdb-4.6; is it patched with official Oracle patches? p.

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

First, thanks for the suggestions. I have updated my config file and you could find it here: http://purgatory.spnet.net/~karavelov/slapd.conf.clean But the problem I have desctribed still persist. You could find a log here: http://purgatory.spnet.net/~karavelov/faillog the logging is set to: trace stats stats2 pcache (I believe that 0x1000 is pcache) It consists of 3 parts: 1. First query for "justillusion.net", it is not in the cache. It hits the SQL database and is reported to be stored in dbd cache 2. Some seconds later the same query fails 3. An analogous query succeed I could cut more form the log file if somebody needs it. I do not think that the fails depend on the data being stored (no NULLs). Some different records get corrupted and I do not see nothing common that could be the cause of the corruption. Just in differend times, differend records get corrupted. This is slapd-2.4.17 + patch from head (back-sql/search.c), libdbd-4.6 Thanks in advance

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 05 Aug '09

05 Aug '09

--=-797W8K2OMmXVapcbJp3G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > [Resending because I forgot the ITS number in the subject] >=20 > I have a simple prototype that on add/modrdn populates/maintains an > attribute (rdnValue) with the distinguished values of the naming > attributes of the RDN. While doing this, it also checks for uniqueness o= f > the rdnValue value within siblings. >=20 > You can find it here > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.= c> >=20 > Please test and comment. I hope it does what intended. Can you please remind me in a few days if I don't get to this? I'm keen to try it out, but I'm also busy with other things, so liable to forget. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-797W8K2OMmXVapcbJp3G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKeXCFz4A8Wyi0NrsRAnciAJ0W4oCBgFTi9hZ9kRZhYV2HVhYY5QCfb5pG YmV71t4D3eYdAPwunBt5clU= =ZZGj -----END PGP SIGNATURE----- --=-797W8K2OMmXVapcbJp3G--

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

I see a few configuration issues that may be related to the problem you describe. See below for details. > karavelov(a)spnet.net wrote: >> This is a multi-part message in MIME format. >> --------------000408020401050805090402 >> > The attachment did't work. So here is the conf file: You should provide an URI to data you want to share. You can upload data to OpenLDAP's public FTP site. > # This is the main slapd configuration file. See slapd.conf(5) for more > # info on the configuration options. > > ####################################################################### > # Global Directives: > > # Schema and objectClass definitions > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > include /etc/ldap/schema/mailrouter.schema > > # Where the pid file is put. The init.d script > # will not stop the server if you change this. > pidfile /var/run/slapd/slapd.pid > > # List of arguments that were passed to the server > argsfile /var/run/slapd/slapd.args > > # Read slapd.conf(5) for possible values > loglevel 4864 ^^^ This is equivalent to 0x100 + 0x200 + 0x1000, which means stats, stats2 and an undefined log level. > # Where the dynamically loaded modules are stored > modulepath /usr/lib/ldap > moduleload back_bdb > moduleload back_sql > moduleload pcache > > # The maximum number of entries that is returned for a search operation > sizelimit 500 > > # The tool-threads parameter sets the actual amount of cpu's that is used > # for indexing. > tool-threads 8 > threads 2 This may be nonsense. The default is 16 threads, and you should not use less unless you know what you're doing. Slapo-pcache uses internal threads for cache maintenance; slapd may need to use other threads for internal purposes. Setting threads to 2 you risk starvation as soon as multiple internal tasks need to be done at the same time. > # Ensure read access to the base for things like > # supportedSASLMechanisms. Without this you may > # have problems with SASL not knowing what > # mechanisms are available and the like. > # Note that this is covered by the 'access to *' > # ACL below too but if you change that as people > # are wont to do you'll still need this if you > # want SASL (and possible other things) to work > # happily. > access to dn.base="" by * read > > # The admin dn has full write access, everyone else > # can read everything. > > access to dn.subtree="dc=hosting,dc=spnet,dc=net" > by dn="cn=nss,dc=ldapaccess" read > > > access to * > by * auth > > # LDIF for bind creditials > database ldif > suffix "dc=ldapaccess" > rootdn "dc=ldapaccess" > directory "/etc/ldap/ldif" > rootpw some-secret > #readonly on > > ####################################################################### > ## sql database definitions > ######################################################################## > # > database sql > suffix "dc=spnet,dc=net" > rootdn "cn=admin,dc=spnet,dc=net" > rootpw bind-secret > dbname ISP > dbuser ldap > dbpasswd sql-secret > aliasing_quote \" > subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" > # actiualy it is read only db - it is never used > insentry_stmt "INSERT INTO ldap_entries > (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" > upper_func UPPER > has_ldapinfo_dn_ru no > > ########## > # chache > ########## > overlay pcache > proxycache bdb 67108864 2 16384 60 Are you seriously going to cache up to 67M entries in a database with 16MB of Berkeley DB cache? (see below) > proxyAttrset 0 cn uid uidNumber gidNumber loginShell homeDirectory > userPassword description gecos memberUid dc spamassassin > proxyAttrset 1 spamassassin uid cn userPassword dc mailMessageStore > mailQuota uidNumber gidNumber mailAliasedName > > proxytemplate (&(objectClass=)(uidNumber=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(gidNumber=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(uid=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(memberUid=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) > 0 3600 3600 > proxytemplate (&(objectClass=)(dc=)) > 0 3600 3600 > proxytemplate (&(objectClass=)(cn=)) > 0 3600 3600 > proxytemplate (objectClass=) > 0 3600 3600 > proxytemplate (uid=) > 0 3600 3600 > proxytemplate (cn=) > 0 3600 3600 > proxytemplate (dc=) > 0 3600 3600 > > > proxytemplate (&(objectClass=)(uidNumber=)) > 1 600 300 > proxytemplate (&(objectClass=)(gidNumber=)) > 1 600 300 > proxytemplate (&(objectClass=)(uid=)) > 1 600 300 > proxytemplate (&(objectClass=)(dc=)) > 1 600 300 > proxytemplate (&(objectClass=)(cn=)) > 1 600 300 > proxytemplate (objectClass=) > 1 600 300 > proxytemplate (uid=) > 1 600 300 > proxytemplate (cn=) > 1 600 300 I hope line wraps are related to cut'n'paste in the mailer. Continuation lines need to start with a blank in slapd.conf > > # dbd backend config > > directory /var/tmp/ > > index objectClass eq > index uid eq > index uidNumber eq > index gidNumber eq > index memberUid eq > index dc pres,eq,sub > index cn pres,eq,sub > > checkpoint 128 60 > cachesize 163840 > idlcachesize 163840 > dirtyread ^^^ you shouldn't use this parameter if you look for search result consistency > dbconfig set_cachesize 0 16777216 1 as mentioned earlier, this value makes little sense, since a 16MB cache is going to perform poorly as soon as your database is less than minimal. Read Berkeley DB documentation for details about the meaning of this configuration. A sane starting value, also depending on the amount of RAM of your system, is 256MB. > dbconfig set_lg_regionmax 262144 > dbconfig set_lg_bsize 2097152 In conclusion, there is nothing blatantly wrong, but some tuning might improve your configuration. As per the issue you're complaining about, you should investigate it a little further, before we can determine whether it's caused by a bug in the software and, in case, track it. For example, you should determine whether it repeats with a given data set, and possibly provide logs at stats, stats2, pcache level of a malfunctioning event. p.

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

karavelov(a)spnet.net wrote: > This is a multi-part message in MIME format. > --------------000408020401050805090402 > The attachment did't work. So here is the conf file: # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/mailrouter.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel 4864 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload back_sql moduleload pcache # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 8 threads 2 # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to dn.subtree="dc=hosting,dc=spnet,dc=net" by dn="cn=nss,dc=ldapaccess" read access to * by * auth # LDIF for bind creditials database ldif suffix "dc=ldapaccess" rootdn "dc=ldapaccess" directory "/etc/ldap/ldif" rootpw some-secret #readonly on ####################################################################### ## sql database definitions ######################################################################## # database sql suffix "dc=spnet,dc=net" rootdn "cn=admin,dc=spnet,dc=net" rootpw bind-secret dbname ISP dbuser ldap dbpasswd sql-secret aliasing_quote \" subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" # actiualy it is read only db - it is never used insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no ########## # chache ########## overlay pcache proxycache bdb 67108864 2 16384 60 proxyAttrset 0 cn uid uidNumber gidNumber loginShell homeDirectory userPassword description gecos memberUid dc spamassassin proxyAttrset 1 spamassassin uid cn userPassword dc mailMessageStore mailQuota uidNumber gidNumber mailAliasedName proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 3600 proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 3600 proxytemplate (&(objectClass=)(uid=)) 0 3600 3600 proxytemplate (&(objectClass=)(memberUid=)) 0 3600 3600 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 3600 3600 proxytemplate (&(objectClass=)(dc=)) 0 3600 3600 proxytemplate (&(objectClass=)(cn=)) 0 3600 3600 proxytemplate (objectClass=) 0 3600 3600 proxytemplate (uid=) 0 3600 3600 proxytemplate (cn=) 0 3600 3600 proxytemplate (dc=) 0 3600 3600 proxytemplate (&(objectClass=)(uidNumber=)) 1 600 300 proxytemplate (&(objectClass=)(gidNumber=)) 1 600 300 proxytemplate (&(objectClass=)(uid=)) 1 600 300 proxytemplate (&(objectClass=)(dc=)) 1 600 300 proxytemplate (&(objectClass=)(cn=)) 1 600 300 proxytemplate (objectClass=) 1 600 300 proxytemplate (uid=) 1 600 300 proxytemplate (cn=) 1 600 300 # dbd backend config directory /var/tmp/ index objectClass eq index uid eq index uidNumber eq index gidNumber eq index memberUid eq index dc pres,eq,sub index cn pres,eq,sub checkpoint 128 60 cachesize 163840 idlcachesize 163840 dirtyread dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

This is a multi-part message in MIME format. --------------000408020401050805090402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit karavelov(a)spnet.net wrote: > Full_Name: Luben Karavelov > Version: 2.4.11-CVS-HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.34.104.18) > Attached is the current configuration file (cleaned from sensitive info). The queries that exhibit the cache corruption are like: ldapsearch -h work -vLx -D "cn=nss,dc=ldapaccess" -w bind-secret -s one -b "dc=HOSTING,dc=SPNET,dc=NET" "(&(objectClass=mailDomain)(dc=example.com))" spamassassin I have saved some corrupted cache databases. I could answer questions about them. --------------000408020401050805090402 Content-Type: text/plain; name="slapd.conf.clean" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="slapd.conf.clean" IyBUaGlzIGlzIHRoZSBtYWluIHNsYXBkIGNvbmZpZ3VyYXRpb24gZmlsZS4gU2VlIHNsYXBk LmNvbmYoNSkgZm9yIG1vcmUKIyBpbmZvIG9uIHRoZSBjb25maWd1cmF0aW9uIG9wdGlvbnMu CgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwojIEdsb2JhbCBEaXJlY3RpdmVzOgoKIyBTY2hlbWEgYW5k IG9iamVjdENsYXNzIGRlZmluaXRpb25zCmluY2x1ZGUgICAgICAgICAvZXRjL2xkYXAvc2No ZW1hL2NvcmUuc2NoZW1hCmluY2x1ZGUgICAgICAgICAvZXRjL2xkYXAvc2NoZW1hL2Nvc2lu ZS5zY2hlbWEKaW5jbHVkZSAgICAgICAgIC9ldGMvbGRhcC9zY2hlbWEvbmlzLnNjaGVtYQpp bmNsdWRlICAgICAgICAgL2V0Yy9sZGFwL3NjaGVtYS9pbmV0b3JncGVyc29uLnNjaGVtYQpp bmNsdWRlICAgICAgICAgL2V0Yy9sZGFwL3NjaGVtYS9tYWlscm91dGVyLnNjaGVtYQoKIyBX aGVyZSB0aGUgcGlkIGZpbGUgaXMgcHV0LiBUaGUgaW5pdC5kIHNjcmlwdAojIHdpbGwgbm90 IHN0b3AgdGhlIHNlcnZlciBpZiB5b3UgY2hhbmdlIHRoaXMuCnBpZGZpbGUgICAgICAgICAv dmFyL3J1bi9zbGFwZC9zbGFwZC5waWQKCiMgTGlzdCBvZiBhcmd1bWVudHMgdGhhdCB3ZXJl IHBhc3NlZCB0byB0aGUgc2VydmVyCmFyZ3NmaWxlICAgICAgICAvdmFyL3J1bi9zbGFwZC9z bGFwZC5hcmdzCgojIFJlYWQgc2xhcGQuY29uZig1KSBmb3IgcG9zc2libGUgdmFsdWVzCmxv Z2xldmVsICAgIDQ4NjQKCiMgV2hlcmUgdGhlIGR5bmFtaWNhbGx5IGxvYWRlZCBtb2R1bGVz IGFyZSBzdG9yZWQKbW9kdWxlcGF0aAkvdXNyL2xpYi9sZGFwCm1vZHVsZWxvYWQJYmFja19i ZGIKbW9kdWxlbG9hZAliYWNrX3NxbAptb2R1bGVsb2FkCXBjYWNoZQoKIyBUaGUgbWF4aW11 bSBudW1iZXIgb2YgZW50cmllcyB0aGF0IGlzIHJldHVybmVkIGZvciBhIHNlYXJjaCBvcGVy YXRpb24Kc2l6ZWxpbWl0IDUwMAoKIyBUaGUgdG9vbC10aHJlYWRzIHBhcmFtZXRlciBzZXRz IHRoZSBhY3R1YWwgYW1vdW50IG9mIGNwdSdzIHRoYXQgaXMgdXNlZAojIGZvciBpbmRleGlu Zy4KdG9vbC10aHJlYWRzIDgKdGhyZWFkcyAyCgojIEVuc3VyZSByZWFkIGFjY2VzcyB0byB0 aGUgYmFzZSBmb3IgdGhpbmdzIGxpa2UKIyBzdXBwb3J0ZWRTQVNMTWVjaGFuaXNtcy4gIFdp dGhvdXQgdGhpcyB5b3UgbWF5CiMgaGF2ZSBwcm9ibGVtcyB3aXRoIFNBU0wgbm90IGtub3dp bmcgd2hhdAojIG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJsZSBhbmQgdGhlIGxpa2UuCiMgTm90 ZSB0aGF0IHRoaXMgaXMgY292ZXJlZCBieSB0aGUgJ2FjY2VzcyB0byAqJwojIEFDTCBiZWxv dyB0b28gYnV0IGlmIHlvdSBjaGFuZ2UgdGhhdCBhcyBwZW9wbGUKIyBhcmUgd29udCB0byBk byB5b3UnbGwgc3RpbGwgbmVlZCB0aGlzIGlmIHlvdQojIHdhbnQgU0FTTCAoYW5kIHBvc3Np YmxlIG90aGVyIHRoaW5ncykgdG8gd29yayAKIyBoYXBwaWx5LgphY2Nlc3MgdG8gZG4uYmFz ZT0iIiBieSAqIHJlYWQKCiMgVGhlIGFkbWluIGRuIGhhcyBmdWxsIHdyaXRlIGFjY2Vzcywg ZXZlcnlvbmUgZWxzZQojIGNhbiByZWFkIGV2ZXJ5dGhpbmcuCgphY2Nlc3MgdG8gZG4uc3Vi dHJlZT0iZGM9aG9zdGluZyxkYz1zcG5ldCxkYz1uZXQiCiAgICAgICBieSBkbj0iY249bnNz LGRjPWxkYXBhY2Nlc3MiIHJlYWQKCgphY2Nlc3MgdG8gKgogICAgICAgYnkgKiBhdXRoCgoj IExESUYgZm9yIGJpbmQgY3JlZGl0aWFscwpkYXRhYmFzZSBsZGlmCnN1ZmZpeCAgICAgICJk Yz1sZGFwYWNjZXNzIgpyb290ZG4gICAgICAiZGM9bGRhcGFjY2VzcyIKZGlyZWN0b3J5CSIv ZXRjL2xkYXAvbGRpZiIKcm9vdHB3ICAgICAgc29tZS1zZWNyZXQKI3JlYWRvbmx5CQlvbgoK IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMKIyMgc3FsIGRhdGFiYXNlIGRlZmluaXRpb25zCiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIwojCmRhdGFiYXNlIHNxbApzdWZmaXggICAgICAiZGM9c3BuZXQsZGM9bmV0 Igpyb290ZG4gICAgICAiY249YWRtaW4sZGM9c3BuZXQsZGM9bmV0Igpyb290cHcgICAgICBi aW5kLXNlY3JldApkYm5hbWUgICAgICAgICAgSVNQCmRidXNlciAgICAgICAgICBsZGFwCmRi cGFzc3dkICAgICAgICBzcWwtc2VjcmV0CmFsaWFzaW5nX3F1b3RlCSBcIgpzdWJ0cmVlX2Nv bmQgICAgIlVQUEVSKGxkYXBfZW50cmllcy5kbikgTElLRSBDT05DQVQoJyUnLFVQUEVSKD8p KSIKIyBhY3RpdWFseSBpdCBpcyByZWFkIG9ubHkgZGIgLSBpdCBpcyBuZXZlciB1c2VkCmlu c2VudHJ5X3N0bXQgICAiSU5TRVJUIElOVE8gbGRhcF9lbnRyaWVzIChpZCxkbixvY19tYXBf aWQscGFyZW50LGtleXZhbCkgVkFMVUVTIChsZGFwX2VudHJ5X2lkcy5uZXh0dmFsLD8sPyw/ LD8pIgp1cHBlcl9mdW5jICAgICAgVVBQRVIKaGFzX2xkYXBpbmZvX2RuX3J1IG5vCgojIyMj IyMjIyMjCiMgY2hhY2hlCiMjIyMjIyMjIyMKb3ZlcmxheSBwY2FjaGUKIyNwcm94eWNhY2hl ICAgIGJkYiAxMDAwMDAgMyAxMDAwIDEwMApwcm94eWNhY2hlICAgIGJkYiA2NzEwODg2NCAy IDE2Mzg0IDYwCgpwcm94eUF0dHJzZXQgIDAgY24gdWlkIHVpZE51bWJlciBnaWROdW1iZXIg bG9naW5TaGVsbCBob21lRGlyZWN0b3J5IHVzZXJQYXNzd29yZCBkZXNjcmlwdGlvbiBnZWNv cyBtZW1iZXJVaWQgZGMgc3BhbWFzc2Fzc2luIG9iamVjdENsYXNzCnByb3h5QXR0cnNldCAg MSBzcGFtYXNzYXNzaW4gdWlkIGNuIHVzZXJQYXNzd29yZCBkYyBtYWlsTWVzc2FnZVN0b3Jl IG1haWxRdW90YSB1aWROdW1iZXIgZ2lkTnVtYmVyIG1haWxBbGlhc2VkTmFtZSBvYmplY3RD bGFzcwoKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkodWlkTnVtYmVyPSkpICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgm KG9iamVjdENsYXNzPSkoZ2lkTnVtYmVyPSkpICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkodWlkPSkpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0 ZSAgICgmKG9iamVjdENsYXNzPSkobWVtYmVyVWlkPSkpICAgICAgICAgICAgICAgICAgICAg ICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkofCht ZW1iZXJVaWQ9KSh1bmlxdWVNZW1iZXI9KSkpICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0 ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkoZGM9KSkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNz PSkoY249KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAK cHJveHl0ZW1wbGF0ZSAgIChvYmplY3RDbGFzcz0pICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgICh1aWQ9KSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAw IDM2MDAKcHJveHl0ZW1wbGF0ZSAgIChjbj0pICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMCAzNjAwIDM2MDAKcHJveHl0ZW1wbGF0ZSAgIChk Yz0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAzNjAwIDM2MDAKCgpwcm94eXRlbXBsYXRlICAgKCYob2JqZWN0Q2xhc3M9KSh1aWROdW1i ZXI9KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAxIDYwMCAzMDAKcHJveHl0ZW1wbGF0 ZSAgICgmKG9iamVjdENsYXNzPSkoZ2lkTnVtYmVyPSkpICAgICAgICAgICAgICAgICAgICAg ICAgICAgMSA2MDAgMzAwCnByb3h5dGVtcGxhdGUgICAoJihvYmplY3RDbGFzcz0pKHVpZD0p KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgNjAwIDMwMApwcm94eXRlbXBs YXRlICAgKCYob2JqZWN0Q2xhc3M9KShkYz0pKSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxIDYwMCAzMDAKcHJveHl0ZW1wbGF0ZSAgICgmKG9iamVjdENsYXNzPSkoY249 KSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSA2MDAgMzAwCnByb3h5dGVt cGxhdGUgICAob2JqZWN0Q2xhc3M9KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEgNjAwIDMwMApwcm94eXRlbXBsYXRlICAgKHVpZD0pICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIDYwMCAzMDAKcHJveHl0 ZW1wbGF0ZSAgIChjbj0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMSA2MDAgMzAwCgojIGRiZCBiYWNrZW5kIGNvbmZpZwoKZGlyZWN0b3J5 IC92YXIvdG1wLwoKaW5kZXggICAgICAgICAgIG9iamVjdENsYXNzIGVxCmluZGV4ICAgICAg ICAgICB1aWQgZXEKaW5kZXggICAgICAgICAgIHVpZE51bWJlciBlcQppbmRleCAgICAgICAg ICAgZ2lkTnVtYmVyIGVxCmluZGV4ICAgICAgICAgICBtZW1iZXJVaWQgZXEKaW5kZXggICAg ICAgICAgIGRjIHByZXMsZXEsc3ViCmluZGV4ICAgICAgICAgICBjbiBwcmVzLGVxLHN1YgoK Y2hlY2twb2ludCAgICAgIDEyOCA2MApjYWNoZXNpemUgICAgICAgMTYzODQwCmlkbGNhY2hl c2l6ZSAgICAxNjM4NDAKZGlydHlyZWFkCgpkYmNvbmZpZyAgICAgICAgc2V0X2NhY2hlc2l6 ZSAwIDE2Nzc3MjE2IDEKZGJjb25maWcgICAgICAgIHNldF9sZ19yZWdpb25tYXggMjYyMTQ0 CmRiY29uZmlnICAgICAgICBzZXRfbGdfYnNpemUgMjA5NzE1Mgo= --------------000408020401050805090402--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs