openldap-bugs November 2012

openldap-bugs@openldap.org

30 participants
100 discussions

(ITS#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 08 Nov '12

08 Nov '12

Full_Name: Barry Lance Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.226) Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using syncrepl. Replication is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the master, it works exactly as expected allowing both normal users and the rootdn to make appropriate changes. However, once I either reboot the replica server or restart slapd, the chain overlay fails to allow any changes on the master. Looking at syslog shows that before the reboot/restart the requesting users' dn is proxied over as expected. After the restarting slapd or rebooting Replica, all changes are proxied anonymously (dn=""). I am using simple binds at this point in the project, but it doesn't seems to matter if I proxy in the clear, ldaps, or TLS the result is the same. All three methods can successfully negotiate a connection. I've even tried switching between using the rootdn and a different user as the binddn in my overlay, but the result is still the same no matter what I use for the binddn. When I look at my config, I notice that "chain-idassert-bind" appears to be hashed or encrypted in thew config. Is that normal? Just seems really odd that my config would work immediately when added, but fail after the the daemon has been restarted. Am I missing something really silly? Hopefully, someone can assist me on this. I've been driving myself crazy trying to figure out why this behavior is occurring. Disclaimer: I am using openldap as part of my capstone project for graduation. I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one issue that I would love to resolve so I can move on to the Kerberos phase of my project (and maybe even study for an exam coming up in my algorithms class next week). Here is my overlay config using the rootDN and TLS (on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self starttls=critical tls_cacert=/etc/ssl/certs/cacert.pem tls_reqcert=demand And without TLS (also on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 08 Nov '12

08 Nov '12

Jan Synacek wrote: > On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >> FYI: I sent output of bt full to Jan with some data stripped because of >> privacy concerns. >> >> Note that the entry for which constraint checking is done is added to the >> database. So something might be wrong *after* the check. > > Can you please try the attached patch? It seems to work. But I will test it during the next days more thoroughly. Ciao, Michael.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 08 Nov '12

08 Nov '12

This is a multi-part message in MIME format. --------------000604070905040801090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: > FYI: I sent output of bt full to Jan with some data stripped because of > privacy concerns. > > Note that the entry for which constraint checking is done is added to the > database. So something might be wrong *after* the check. > > Ciao, Michael. > > Can you please try the attached patch? If it doesn't fix the issue (or breaks something else that I'm not aware of) I will need a reproducer config and data. Thank you, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat --------------000604070905040801090708 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index ee8911b..f2c645c 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -935,10 +935,6 @@ constraint_update( Operation *op, SlapReply *rs ) /* Do we need to count attributes? */ for(cp = c; cp; cp = cp->ap_next) { - if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { - continue; - } - if (cp->count != 0) { if (rc != 0 || target_entry == NULL) { Debug(LDAP_DEBUG_TRACE, @@ -950,6 +946,10 @@ constraint_update( Operation *op, SlapReply *rs ) goto mod_violation; } + if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { + continue; + } + is_v = constraint_check_count_violation(m, target_entry, cp); Debug(LDAP_DEBUG_TRACE, --------------000604070905040801090708--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 07 Nov '12

07 Nov '12

FYI: I sent output of bt full to Jan with some data stripped because of privacy concerns. Note that the entry for which constraint checking is done is added to the database. So something might be wrong *after* the check. Ciao, Michael.

1 0

Re: (ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by quanah＠zimbra.com 06 Nov '12

06 Nov '12

--On Tuesday, November 06, 2012 5:36 PM +0000 vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.76.64.65) > > > We have been facing frequent memory utilization issues with OpenLDAP > 2.4.32 in our production environment (multi-master mode, 6 servers), > which requires OpenLDAP server instances to be restarted almost every > week. Utilization starts at a lower percentage to start with (2-3%), but > then gradually moves up and never comes down. We have been using OpenLDAP > 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux > Server release 5.5 (Tikanga). Are there any known issues with this > version? Are you using the default glibc malloc, instead of tcmalloc? That would be a common mistake that results in this sort of behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by vb4607＠att.com 06 Nov '12

06 Nov '12

Full_Name: Venkatesh Baglodi Version: 2.4.32 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.76.64.65) We have been facing frequent memory utilization issues with OpenLDAP 2.4.32 in our production environment (multi-master mode, 6 servers), which requires OpenLDAP server instances to be restarted almost every week. Utilization starts at a lower percentage to start with (2-3%), but then gradually moves up and never comes down. We have been using OpenLDAP 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). Are there any known issues with this version?

1 0

Re: (ITS#7432) slapd crashes when removing members from a large group
by hyc＠symas.com 05 Nov '12

05 Nov '12

marvin.mundry(a)uni-hamburg.de wrote: > Full_Name: Marvin Mundry > Version: 2.4.33 > OS: Ubuntu 12.10 > URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz > Submission from: (NULL) (134.100.2.183) > Thanks for the report. The crash has been fixed in git, but your test runs into another (known) issue in MDB. You're working with a very large entry, which libmdb stores in overflow pages. In the current version of libmdb, freespace management for overflow pages is not fully implemented, so every time you update the entry libmdb will always use new pages (instead of reusing old pages). Thus, after a few hundred operations, your 1GB map will be exhausted. It looks like you won't be able to use back-mdb until this feature is fully implemented in libmdb. > i have slapcat'ed my production environment and slapadded it into an back_mdb > database. > > when deleting members one by one from a large group (48428 Members), after some > transactions slapd crashes. > when i slapadd my dit to an mdb without having an eq index configured for > "member" the removal of members works fine. > > when doing the same thing (member indexed, slapadding members, starting slapd, > removing group members one by one) on a hdb, slapd does not crash. > > sortvals is set for members as otherwise deletion operations would take a very > long time > > i failed to reproduce the problem without initially slapadding the data from my > production environment into the mdb. > > i have removed all configuration settings not neccessary to reproduce the bug > > the debug.tar.bz should contain everything that is neccessary (including a > description) to reproduce the problem. additionally the file contains a coredump > and the full trace output > > slapd.conf: > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/rfc2307bis.schema > pidfile /usr/local/var/run/slapd.pid > argsfile /usr/local/var/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_mdb.la > sortvals member > database mdb > suffix "dc=test,dc=com" > rootdn "cn=admin,dc=test,dc=com" > rootpw secret > directory /usr/local/etc/openldap/test123db/AL > index member eq > maxsize 1000000000 > > > last lines of slapd -d Trace: > 5096b5ae oc_check_allowed type "modifyTimestamp" > 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times > 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > > build options: > CFLAGS=-O0 -d > ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes > --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye > s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod > --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl > > --enable-debug > > (gdb) bt: > #0 0x000002fc000002fa in ?? () > #1 0x000002ff000002fd in ?? () > #2 0x0000030200000300 in ?? () > #3 0x0000030500000303 in ?? () > #4 0x0000030800000306 in ?? () > #5 0x0000030b00000309 in ?? () > #6 0x00007f1400000312 in ?? () > #7 0x0000009cffffffbf in ?? () > #8 0x00007f1400000011 in ?? () > #9 0x00000000000102a3 in ?? () > #10 0x00007f140c101880 in ?? () > #11 0x00007f140883c200 in ?? () > #12 0x0000000000000891 in ?? () > #13 0x00007f14155ef060 in ?? () > #14 0x00007f14523dd5a6 in ?? () > #15 0x00007f1451fa1010 in ?? () > #16 0x00000000523dd2a7 in ?? () > #17 0x00007f14155ef390 in ?? () > #18 0x0000000000000000 in ?? () > > -- -- 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#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 05 Nov '12

05 Nov '12

On 11/04/2012 05:33 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 > OS: openSUSE 12.2 x86_64 > URL: > Submission from: (NULL) (79.227.185.139) > > > I get a seg fault when adding group entries with some regex-constrained > attributes. This is RE24 with the recent fixes for slapo-constraint. The > constraint setup works with 2.4.31. > > Strange thing is that the entry is added to the database. So it seems to me that > the seg fault happens after that while checking constraints for what > slapo-memberof does? > > As often this is a complex customer setup. So it's not that easy to narrow down > the config and strip aways private customer data in a full traceback. I will do > if really necessary. > > Maybe this gives a first hint where to look: > > No symbol "info" in current context. > (gdb) info threads > Id Target Id Frame > 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () > from /lib64/libc.so.6 > 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () > from /lib64/libpthread.so.0 > 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in > constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at > constraint.c:713 > Hello Michael, can you please provide a full backtrace of thread 1? A quick look suggest that there's something wrong, because constraint_check_restrict probably should not be called with e=0x0, but I'm unable to tell anything else with such restricted information. Also, if the problem is in my fix, it should be fairly easily reproducible with just a few slapadds with the right data. Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7432) slapd crashes when removing members from a large group
by marvin.mundry＠uni-hamburg.de 05 Nov '12

05 Nov '12

Full_Name: Marvin Mundry Version: 2.4.33 OS: Ubuntu 12.10 URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz Submission from: (NULL) (134.100.2.183) i have slapcat'ed my production environment and slapadded it into an back_mdb database. when deleting members one by one from a large group (48428 Members), after some transactions slapd crashes. when i slapadd my dit to an mdb without having an eq index configured for "member" the removal of members works fine. when doing the same thing (member indexed, slapadding members, starting slapd, removing group members one by one) on a hdb, slapd does not crash. sortvals is set for members as otherwise deletion operations would take a very long time i failed to reproduce the problem without initially slapadding the data from my production environment into the mdb. i have removed all configuration settings not neccessary to reproduce the bug the debug.tar.bz should contain everything that is neccessary (including a description) to reproduce the problem. additionally the file contains a coredump and the full trace output slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/rfc2307bis.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_mdb.la sortvals member database mdb suffix "dc=test,dc=com" rootdn "cn=admin,dc=test,dc=com" rootpw secret directory /usr/local/etc/openldap/test123db/AL index member eq maxsize 1000000000 last lines of slapd -d Trace: 5096b5ae oc_check_allowed type "modifyTimestamp" 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com build options: CFLAGS=-O0 -d ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl --enable-debug (gdb) bt: #0 0x000002fc000002fa in ?? () #1 0x000002ff000002fd in ?? () #2 0x0000030200000300 in ?? () #3 0x0000030500000303 in ?? () #4 0x0000030800000306 in ?? () #5 0x0000030b00000309 in ?? () #6 0x00007f1400000312 in ?? () #7 0x0000009cffffffbf in ?? () #8 0x00007f1400000011 in ?? () #9 0x00000000000102a3 in ?? () #10 0x00007f140c101880 in ?? () #11 0x00007f140883c200 in ?? () #12 0x0000000000000891 in ?? () #13 0x00007f14155ef060 in ?? () #14 0x00007f14523dd5a6 in ?? () #15 0x00007f1451fa1010 in ?? () #16 0x00000000523dd2a7 in ?? () #17 0x00007f14155ef390 in ?? () #18 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7418) slapo-constraint are broken
by michael＠stroeder.com 04 Nov '12

04 Nov '12

This is a cryptographically signed message in MIME format. --------------ms020504060001080007040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The recent fix for ITS#7418 might have caused another regression causing = a seg fault. Please have a look at http://www.openldap.org/its/index.cgi?findid=3D7431 Ciao, Michael. --------------ms020504060001080007040306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA0MTcxNTA3WjAjBgkq hkiG9w0BCQQxFgQU2S6ujsV//DKe24vs3qNZa3mUkuEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAR/l43ew8i8amA4dE9byAvbfTT50nLLLVOMrTVoCFZk2trkOiFPhWPY3QcsEYncUPTrpI GHaDDCvnrsOp0S5bW3QOXkt0thuE95BFHoOsk6LQATGuCp6hz2WskWx8sJsLQ72zfoJY9Zne H8+0BkBF/otrgACAGEGJgSTiM/ay4IMAmt7JLyGdVSUQZErjP+GbSv7p+wFbQTdMyiUTTGuG OihXeKuKkiZ9CLKdYpjlVQYw5/cxzDWV27Iba0XylKDx1FyhjoWoHaKNpW6BgDSy2xTjWa/I GH2wb4CzyhDkjc3pHmgTSdtIVZ7fqvwgsssWfVV/BeDV4tUH2OZwflJrCgAAAAAAAA== --------------ms020504060001080007040306--

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2012