openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8526) Slapd dies when subjected to heavy load
by hyc＠symas.com 01 Nov '16

01 Nov '16

kwetlesen(a)mac.com wrote: > Full_Name: Kai M Wetlesen > Version: 2.4.40 > OS: RHEL 7.2 Maipo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.4.83.52) > > > Hi All, > > For some reason slapd crashes with a segmentation fault when subjected to a TLS > heavy connection load. It looks like the segmentation fault originates in > libnss3.so, but I cannot tell anything more than that. Issues with OpenLDAP builds shipped in RHEL must be directed to RedHat support. The OpenLDAP Project does not endorse the use of libnss. -- -- 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#8526) Slapd dies when subjected to�heavy load
by kwetlesen＠mac.com 01 Nov '16

01 Nov '16

Full_Name: Kai M Wetlesen Version: 2.4.40 OS: RHEL 7.2 Maipo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.4.83.52) Hi All, For some reason slapd crashes with a segmentation fault when subjected to a TLS heavy connection load. It looks like the segmentation fault originates in libnss3.so, but I cannot tell anything more than that. AOAOct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2259 fd=26 closed (TLS negotiation failure) Oct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2260 fd=26 ACCEPT from IP=XXX.XXX.205.98:49696 (IP=0.0.0.0:636) (about 800 more lines like this)AOAOct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2671 fd=33 ACCEPT from IP=XXX.XXX.205.98:60921 (IP=0.0.0.0:636) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2670 fd=34 closed (TLS negotiation failure) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 ACCEPT from IP=XXX.XXX.205.98:60926 (IP=0.0.0.0:636) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 closed (TLS negotiation failure) Oct 28 11:53:51 ldap-primary.domain kernel: slapd[32180]: segfault at 10 ip 00007f83554fcc65 sp 00007f83367fc550 error 4 in libnss3.so[7f83554b6000+11e000] Oct 28 11:53:51 ldap-primary.domain systemd[1]: slapd.service: main process exited, code=killed, status=11/SEGV The traffic originates from a penetration test machine running Nessus which is used where this server resides as part of a security sweep. Unfortunately I don't have visibility as to what exact tests the Nessus server performs, but I do know that the probes the server a couple hundred times to try and discover what service is running. The machine is running on a lightly configured but dedicated VM as this server was never expected to serve more than 400 clients. Is this expected behavior? Steps to reproduce: - Install OpenLDAP - Configure any DIT - Configure OpenLDAP only to service ldaps:// using TLS - Start the server - Confgure Nessus scanner - Run a Nessus vulnerability scan against the server Thanks, Kai Wetlesen

1 0

(ITS#8525) Use newer DES API so that smbk5pwd loads with newer OpenSSL
by manu＠netbsd.org 29 Oct '16

29 Oct '16

Full_Name: Emmanuel Dreyfus Version: 2.4.44 OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-161030.patch Submission from: (NULL) (213.41.141.172) OpenSSL removed old DES API which used des_* functions. https://github.com/openssl/openssl/commit/24956ca00f014a917fb181a8abc39b349… In order to link smbk5pwd with libcrypto from recent OpenSSL releases, we need to replace tholdeder API des_* functions by the newer API DES_* functions.

1 0

(ITS#8524) cn=config + ditContentRule
by dieter＠dkluenter.de 25 Oct '16

25 Oct '16

Full_Name: Dieter Kluenter Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.214.226.147) It seems that the config backend provides schema information only after configuration data, this leads to following error: ./slapd -h "ldap://:9007/ ldapi:///" -F ../etc/openldap/slapd.d -d256 580f76bd config error processing cn=config: olcDitContentRules: ObjectClass not found: "2.16.840.1.113730.3.2.2" 580f76bd slapd stopped. ile While the same process only with information based on slapd.conf is successful: ./slapd -h "ldap://:9007/ ldapi:///" -f ../etc/openldap/slapd.conf -d256 580f76e4 slapd starting The slapd.configuration: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc%2pepenldap/schema/nis.schema ditcontentrule ( 2.16.840.1.113730.3.2.2 NAME 'sys4Person' AUX ( posixAccount ) ) [more configuration parameter] slapd.d dn: cn=config objectClass: olcGlobal cn: config ... olcToolThreads: 1 olcWriteTimeout: 0 olcDitContentRules: {0}( 2.16.840.1.113730.3.2.2 NAME 'sys4Person' AUX posix Account ) ... -Dieter

1 0

Re: (ITS#8522) Incoming
by ryan＠nardis.ca 25 Oct '16

25 Oct '16

On Tue, Oct 25, 2016 at 09:37:22AM +0200, Ralf Mattes wrote: >> Can you please try with commit 2e60bf5e applied? > >There seem to be quite some changes in op.c, no way to just >apply that change. I'd have to swítch from debian to upstream >which I try to avoid. Are we looking at the same change? Should be just a one-line addition: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=2e60… It's already been pulled into RE24; in that branch it's http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=6b81… but the context doesn't appear to have changed at all.

1 0

(ITS#8523) Incoming
by rm＠mh-freiburg.de 25 Oct '16

25 Oct '16

Am Dienstag, 25. Oktober 2016 04:29 CEST, Ryan Tandy <ryan(a)nardis.ca> s= chrieb: > > I'm actually thinking this is a duplicate of ITS#8428, already fixed = in > RE24. Yes, that does look like the bug I'm experiencing. > Can you please try with commit 2e60bf5e applied? There seem to be quite some changes in op.c, no way to just apply that change. I'd have to sw=C3=ADtch from debian to upstream which I try to avoid. Thank's a lot, Ralf Mattes

1 0

Re: (ITS#8512) segfault for large entries
by ryan＠nardis.ca 24 Oct '16

24 Oct '16

This is probably a specific case of ITS#8435. There is a fix in git master already, commit id 23c5d6bb. Would you please test with that patch applied?

1 0

Re: (ITS#8522) Incoming
by ryan＠nardis.ca 24 Oct '16

24 Oct '16

On Mon, Oct 24, 2016 at 04:48:18PM +0000, rm(a)mh-freiburg.de wrote: >#0 0x00007f60dd7e0aa0 in ?? () >#1 0x00007f61650bca41 in slap=5Fwritewait=5Fplay (op=3D0x7f60c8002550)= > at ../../../../servers/slapd/result.c:294 >#2 send=5Fldap=5Fber (op=3D0x7f60c8002550, ber=3D0x7f60dd64f250) at ..= >/../../../servers/slapd/result.c:367 >#3 0x00007f61650bf651 in slap=5Fsend=5Fsearch=5Fentry (op=3D0x7f60c800= >2550, rs=3D0x7f60dd7e0aa0) at ../../../../servers/slapd/result.c:1430 >#4 0x00007f616003590b in mdb=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f6= >0dd7e0aa0) at ../../../../../servers/slapd/back-mdb/search.c:1086 >#5 0x00007f615f5f8cd6 in relay=5Fback=5Fop (op=3D0x7f60c8002550, rs=3D= >0x7f60dd7e0aa0, which=3D<optimized out>) > at ../../../../../servers/slapd/back-relay/op.c:210 I'm actually thinking this is a duplicate of ITS#8428, already fixed in RE24. Can you please try with commit 2e60bf5e applied?

1 0

(ITS#8522) Incoming
by rm＠mh-freiburg.de 24 Oct '16

24 Oct '16

I'm experiencing a suspiciously similar segfault on 2.4.44+dfsg-1 Here follows the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f60dd7e1700 (LWP 32510)] 0x00007f60dd7e0aa0 in ?? () (gdb) bt #0 0x00007f60dd7e0aa0 in ?? () #1 0x00007f61650bca41 in slap=5Fwritewait=5Fplay (op=3D0x7f60c8002550)= at ../../../../servers/slapd/result.c:294 #2 send=5Fldap=5Fber (op=3D0x7f60c8002550, ber=3D0x7f60dd64f250) at ..= /../../../servers/slapd/result.c:367 #3 0x00007f61650bf651 in slap=5Fsend=5Fsearch=5Fentry (op=3D0x7f60c800= 2550, rs=3D0x7f60dd7e0aa0) at ../../../../servers/slapd/result.c:1430 #4 0x00007f616003590b in mdb=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f6= 0dd7e0aa0) at ../../../../../servers/slapd/back-mdb/search.c:1086 #5 0x00007f615f5f8cd6 in relay=5Fback=5Fop (op=3D0x7f60c8002550, rs=3D= 0x7f60dd7e0aa0, which=3D<optimized out>) at ../../../../../servers/slapd/back-relay/op.c:210 #6 0x00007f616511aeea in overlay=5Fop=5Fwalk (op=3Dop@entry=3D0x7f60c8= 002550, rs=3D0x7f60dd7e0aa0, which=3Dop=5Fsearch, oi=3D0x7f6165d2c020,= on=3D<optimized out>) at ../../../../servers/slapd/backover.c:677 #7 0x00007f616511b044 in over=5Fop=5Ffunc (op=3D0x7f60c8002550, rs=3D<= optimized out>, which=3D<optimized out>) at ../../../../servers/slapd/backover.c:730 #8 0x00007f61650af071 in fe=5Fop=5Fsearch (op=3D0x7f60c8002550, rs=3D0= x7f60dd7e0aa0) at ../../../../servers/slapd/search.c:402 #9 0x00007f61650ae9ee in do=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f60= dd7e0aa0) at ../../../../servers/slapd/search.c:247 #10 0x00007f61650ac57c in connection=5Foperation (ctx=3D0x7f60dd7e0c10,= arg=5Fv=3D0x7f60c8002550) at ../../../../servers/slapd/connection.c:1158 #11 0x00007f61650ac867 in connection=5Fread=5Fthread (ctx=3D0x7f60c8002= 550, argv=3D0x7f60dd7df710) at ../../../../servers/slapd/connection.c:1294 #12 0x00007f6164c0df22 in ldap=5Fint=5Fthread=5Fpool=5Fwrapper (xpool=3D= 0x7f6165c8ffa0) at ../../../../libraries/libldap=5Fr/tpool.c:696 #13 0x00007f61631f20a4 in start=5Fthread (arg=3D0x7f60dd7e1700) at pthr= ead=5Fcreate.c:309 #14 0x00007f6162f2762d in clone () at ../sysdeps/unix/sysv/linux/x86=5F= 64/clone.S:111 To reliably trigger the segfault I need to request jpegImage attributes= . A few more (possibly important) facts: the server houses two databases, the first is a sync-repl slave unsing = the mdb backend, the second a relay backend that provides read-only access to the first database rewriting the data= base suffix. So far I could only trigger the segfault in the relay database, not in = the mdb-backend one. HTH Ralf Mattes

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by michael＠stroeder.com 23 Oct '16

23 Oct '16

This is a cryptographically signed message in MIME format. --------------ms060809020701010302070106 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable lists(a)steffen-moser.de wrote: > Today, I encountered a similar hang of our OpenLDAP 2.4.30 server on a > Solaris 11.3(.11.6.0) host. Note that 2.4.30 release is more than 4.5 years old. There have been *man= y* fixes since then. [1] Using free software it's best practice first trying to reproduce the erro= rnous behaviour with a recent release. Otherwise you're wasting developers' spa= re time. Ciao, Michael. (not a OpenLDAP developer) [1] CHANGES from RE24 branch: http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3DCH= ANGES;h=3D4914db12b0ab2fe2e4f2a91ea46df224a4532cdc;hb=3Drefs/heads/OPENLD= AP_REL_ENG_2_4 --------------ms060809020701010302070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDIzMDgyMjExWjAvBgkq hkiG9w0BCQQxIgQgehc9Y4gx28kcYczpRvC2Q2ABbnfsrL/miwx27k5rFD0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAHk9bj7goMwb2QRpeBL4Fbz1dMxtUpmSEUXavT0n5WuPSmk0lJJQLBMe5ghXUz8bzVID1 RZf2XpEVXIebI7mdLn/uXK/seRu0AKpBjySLP+i4olu38RULsB1SU1qoEtCuZrFbvvPZxzhm tmy3eRI/rt/uT9PY2de0MAE4kjH4gyC3NBUCnnVbh9xfIKrK40IwYAPdJfjdq+EfANQJSJ+C GUryJn2y5gbt59pgZ8aq6qgEZHWTMHGi6a0oNWtd4peC5dtSILTCZQQVVHd0YY3hBPAMuqwA gYpcjrR0ePx/N0T0JBYZYdf9tUHjVSexTbn1LIcfSbsFK0UgfOpFkxXzAwAAAAAAAA== --------------ms060809020701010302070106--

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