openldap-bugs February 2007

openldap-bugs@openldap.org

32 participants
125 discussions

Leaks from test050 in re24
by Pierangelo Masarati 15 Feb '07

15 Feb '07

I see some small leaks in test050; I'm posting valgrind's output below, unfortunately I have no time to investigate them right now. p. ==23984== 71,251 (5,744 direct, 65,507 indirect) bytes in 153 blocks are definitely lost in loss record 7 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821A879: ber_memrealloc_x (memory.c:307) ==23984== by 0x821B178: ber_bvreplace_x (memory.c:706) ==23984== by 0x80F5734: slap_queue_csn (ctxcsn.c:168) ==23984== by 0x80F582D: slap_get_csn (ctxcsn.c:191) ==23984== by 0x8088AE3: slap_add_opattrs (add.c:601) ==23984== by 0x8123546: ldif_back_add (ldif.c:799) ==23984== by 0x806C426: config_setup_ldif (bconfig.c:3495) ==23984== by 0x806C7CD: read_config (bconfig.c:3573) ==23984== by 0x80622ED: main (main.c:747) ==23984== 65,507 bytes in 497 blocks are indirectly lost in loss record 8 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821ABD7: ber_dupbv_x (memory.c:504) ==23984== by 0x80C5A80: objectClassPretty (schema_prep.c:100) ==23984== by 0x80A09D6: ordered_value_pretty (value.c:496) ==23984== by 0x809BACA: slap_mods_check (modify.c:577) ==23984== by 0x8087AD0: do_add (add.c:160) ==23984== by 0x807F866: connection_operation (connection.c:1129) ==23984== by 0x807FD33: connection_read_thread (connection.c:1257) ==23984== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==23984== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==23984== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24033== 183 (60 direct, 123 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 7 ==24033== at 0x4004405: malloc (vg_replace_malloc.c:149) ==24033== by 0x821A75F: ber_memalloc_x (memory.c:226) ==24033== by 0x821A7B2: ber_memalloc (memory.c:242) ==24033== by 0x809FB6C: value_add_one (value.c:96) ==24033== by 0x80F5EFC: slap_parse_sync_cookie (ldapsync.c:238) ==24033== by 0x81CD1EA: syncprov_parseCtrl (syncprov.c:2768) ==24033== by 0x80B7266: slap_parse_ctrl (controls.c:580) ==24033== by 0x80B7A0D: get_ctrls (controls.c:749) ==24033== by 0x80822C2: do_search (search.c:165) ==24033== by 0x807F866: connection_operation (connection.c:1129) ==24033== by 0x807FD33: connection_read_thread (connection.c:1257) ==24033== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24033== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24033== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24000== 70,778 (5,176 direct, 65,602 indirect) bytes in 142 blocks are definitely lost in loss record 8 of 9 ==24000== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24000== by 0x821A7F0: ber_memcalloc_x (memory.c:280) ==24000== by 0x809F775: ch_calloc (ch_malloc.c:104) ==24000== by 0x8088695: slap_mods2entry (add.c:472) ==24000== by 0x80E8A14: syncrepl_message_to_entry (syncrepl.c:1723) ==24000== by 0x80E5840: do_syncrep2 (syncrepl.c:790) ==24000== by 0x80E6C23: do_syncrepl (syncrepl.c:1164) ==24000== by 0x807FD51: connection_read_thread (connection.c:1259) ==24000== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24000== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24000== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so)

1 0

Re: (ITS#4420) Hanging CLOSE_WAIT connections in ldap-backend
by aar＠cpan.org 15 Feb '07

15 Feb '07

I'm experiencing the CLOSE_WAIT problem with slapd 2.3.32 on MacOS X (PPC). Cached connections aren't being leaked but they aren't closed on idle-timeout and they remain in CLOSE_WAIT state after the remote host has gone. Compile options: ./configure --enable-rewrite --enable-ldap --enable-meta --enable-proxycache --enable-spasswd slapd.conf: =========== database ldap suffix "dc=AddressBooks,dc=example,dc=com" uri ldap://localhost:8080 idle-timeout 2 idassert-bind bindmethod=none binddn="cn=Administrative Identity,dc=sssss" credentials="admin_password" authzID="dn:cn=Sandbox,dc=local,dc=example,dc=com" mode=self authz=proxyAuthz (The problem appears also without idle-timeout.) Steps to reproduce: 1. start slapd 2. connect to slapd and do some queries 3. disconnect the proxied server (for example by killing it) 4. netstat -a still shows the connection as CLOSE_WAIT Debug: when running slapd with "-d 5", nothing is printed when the connection is closed by the remote host (i.e. when I kill it), so slapd isn't probably catching the event at all. - alessandro ranellucci.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by hyc＠symas.com 14 Feb '07

14 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >> symbol lookup error: >> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >> ldap_back_proxy_authz_ctrl > > Howard debugged this on IRC and it turns out that our (mine and > _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd > without the unixodbc lib fixes it. Yes, so there are two potential issues - the unixodbc shared library seems to be statically linked with an older version of libltdl. I didn't run into this problem on my build because I don't have that odbc library. Anyway, due to the link order of the libraries, the lt_dlopen in this library gets used before the linker resolves to the system's libltdl.so, and it seems that this version of lt_dlopen doesn't automatically export the symbols of modules that it loads. I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is because there is a new dependency in 2.3.33 between back-meta and back-ldap. The other part of this is that the slapd binary should not be getting linked against -lodbc when back_sql is built as a module. Although, if back-sql is built statically, and other backends are dynamic, this problem may still crop up. It seems that fixing -lodbc would be required then. -- -- Howard Chu Chief Architect, 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#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 14 Feb '07

14 Feb '07

On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: > ==> rewrite_context_apply [depth=1] string='(objectClass=*)' > ==> rewrite_context_apply [depth=1] res={0,'NULL'} > [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" > /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: > symbol lookup error: > +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: > ldap_back_proxy_authz_ctrl Howard debugged this on IRC and it turns out that our (mine and _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd without the unixodbc lib fixes it.

1 0

(ITS#4843) test023-refint fails
by michael＠stroeder.com 14 Feb '07

14 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.2.127) >>>>> Starting test023-refint ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd referential integrity operations... Searching unmodified database... Testing modrdn... Using ldapsearch to check dependents new rdn... Comparing ldapsearch results against original... comparison failed - modify operations did not complete correctly >>>>> ./scripts/test023-refint failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: Can slapd run with only one thread to operate (ITS#4842)
by hyc＠symas.com 13 Feb '07

13 Feb '07

seuler.shi(a)gmail.com wrote: > ------=_Part_100396_21317226.1171418508303 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > What I want to do is to do operations in OpenLDAP server serially, not > concurrency > in the server. If the back database is configured to load all data in > memory, then overhead > of executing a operation is approximately equal the overhead of lock > relevant overhead in > database. So if requests are serially handled in openldap server, the lock > subsystem can > be remove from backend database. The lock subsystem can only be removed if you only permit read operations. I've done a number of tests with the locks commented out of the backend; certainly it is faster, by about 20% for single threaded operation. But that's not much of a gain considering the reduction in utility. Meanwhile, turning off threads means you cannot take advantage of multiple-processor systems, which is definitely a loss. All in all there is no benefit to pursuing this. You can spend your time exploring as you wish, but none of us will spend any of our time retreading ground that we've already studied extensively. > I just want to compare difference on performance under these two strategy. > > Although I use ./configure --without-threads, there are still two work > threads,(info thread in > gdb: there are two pthread_cond_wait records.) > > Would you give me some suggestion to reach the goal, serially handle the > received requests > in openldap server? > > Thanks a lot! > > 2007/2/14, Pierangelo Masarati <openldap-its(a)openldap.org>: >> Slapd by design needs at least 2 threads to work. That code is there >> exactly to >> avoid silly configurations with less than 2 threads. You're free to >> modify it, >> but then you shouldn't complain. Otherwise, if you don't want slapd to >> use >> threads you can compile it --without-threads (not --without--threads like >> you >> typed). >> >> If you could tell us what your real problem is with threads, maybe we >> wouldn't >> both waste time in this rather pointless issue. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Can slapd run with only one thread to operate (ITS#4842)
by seuler.shi＠gmail.com 13 Feb '07

13 Feb '07

------=_Part_100396_21317226.1171418508303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What I want to do is to do operations in OpenLDAP server serially, not concurrency in the server. If the back database is configured to load all data in memory, then overhead of executing a operation is approximately equal the overhead of lock relevant overhead in database. So if requests are serially handled in openldap server, the lock subsystem can be remove from backend database. I just want to compare difference on performance under these two strategy. Although I use ./configure --without-threads, there are still two work threads,(info thread in gdb: there are two pthread_cond_wait records.) Would you give me some suggestion to reach the goal, serially handle the received requests in openldap server? Thanks a lot! 2007/2/14, Pierangelo Masarati <openldap-its(a)openldap.org>: > > Slapd by design needs at least 2 threads to work. That code is there > exactly to > avoid silly configurations with less than 2 threads. You're free to > modify it, > but then you shouldn't complain. Otherwise, if you don't want slapd to > use > threads you can compile it --without-threads (not --without--threads like > you > typed). > > If you could tell us what your real problem is with threads, maybe we > wouldn't > both waste time in this rather pointless issue. > > p. > ------=_Part_100396_21317226.1171418508303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>What I want to do is to do operations in OpenLDAP server serially, not concurrency</div> <div>in the server. If the back database is configured to load all data in memory, then overhead</div> <div>of executing a operation is approximately equal the overhead of lock relevant overhead in </div> <div>database. So if requests are serially handled in openldap server, the lock subsystem can</div> <div>be remove from backend database. </div> <div> </div> <div>I just want to compare difference on performance under these two strategy.</div> <div> </div> <div>Although I use ./configure --without-threads, there are still two work threads,(info thread in</div> <div>gdb: there are two pthread_cond_wait records.)</div> <div> </div> <div>Would you give me some suggestion to reach the goal, serially handle the received requests</div> <div>in openldap server?</div> <div> </div> <div>Thanks a lot!</div> <div> </div> <div><span class="gmail_quote">2007/2/14, Pierangelo Masarati <<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>>:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Slapd by design needs at least 2 threads to work.  That code is there exactly to<br>avoid silly configurations with less than 2 threads.  You're free to modify it, <br>but then you shouldn't complain.  Otherwise, if you don't want slapd to use<br>threads you can compile it --without-threads (not --without--threads like you<br>typed).<br><br>If you could tell us what your real problem is with threads, maybe we wouldn't <br>both waste time in this rather pointless issue.<br><br>p.<br></blockquote></div><br> ------=_Part_100396_21317226.1171418508303--

1 0

Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by ando＠sys-net.it 13 Feb '07

13 Feb '07

hyc(a)symas.com wrote: > Hi, > I have not been paying attention to these changes since Ando was working > on them. You'll have to ask him for their update status. Sorry for overlooking yur previous message. Yes, I'm keeping that patch sort of updated, but keeping it in sync with HEAD was a pain due to the many changes that occurred in that code. I'm not sure it's ready for commit right now, and I'm not sure it works as intended, given the lack of specs (every implementor seem to have their own idea of haw that's supposed to work, and willing to interoperate, despite claims, seems to be their last concern). Preserving compatibility with re23 might not be an option, and I don't think we want that stuff to go in re23 right now. > Since you've already posted a query to the ITS, I think that would be the > appropriate place to continue the conversation. > > Looking over the ITS just now, I would say the tweak to register the > changelog overlay type is unnecessary. Nor can you fairly deprecate the > LogStyle parameter, since that appears to be the only way to invoke the > SunOne workaround. > > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. I'll be committing something workable soon. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by hyc＠symas.com 13 Feb '07

13 Feb '07

hyc(a)symas.com wrote: > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. While this is hardly the place for commercial endorsements, I should note that while Neil Dunbar wrote that changelog overlay for HP's purposes, we (Symas) convinced HP to adopt the accesslog format instead and HP does not rely on the changelog any more. If you're looking for software that actually conforms to open specs with some degree of technical merit, you might consider looking there, if you can't convince your current vendors to fix their products. > > Rieger, Sebastian wrote: >> Hi, >> >> I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP >> 2.3. It works for our identity management (using Novell IDM 3.01) - see >> ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like >> to ask, wether the patch to your accesslog that offers changelog >> functionality (ITS#4656) is likely to be committed to CVS HEAD in the near >> future. In this case I won't maintain a separate overlay. Thanks in advance >> for a quick reply, we really need changelog functionality as Novell, Sun and >> Oracle seem to depend on it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

AW: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by sebastian.rieger＠gwdg.de 13 Feb '07

13 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C74F6A.DE443C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the quick reply, I'd continue the conversation with Ando and = via IST, thanks for putting them on CC:. Can you name the IdM packages you = refer to, that implement a replication mechanism that is compatible with = OpenLDAP? We tested: - Microsoft Identity Integration Server: only flat-file LDAP support = (using LDIF) (until Gemini version ~2008) - no replication, just full synchronization - Siemens DirX: using a full search over all objects (Novell Identity Manager can do so either, but you're unable to detect moved objects = then, as it looks like a delete and add of the object, and performance is low, as = for every sync cycle a full search over the tree is necessary) Oracle and Sun using changelog were already mentioned... Maybe IBM? or do you refer to the meta backend module for OpenLDAP? Thanks in advance for the advice... -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der -----Urspr=FCngliche Nachricht----- Von: Howard Chu [mailto:hyc@symas.com]=20 Gesendet: Dienstag, 13. Februar 2007 12:20 An: Rieger, Sebastian Cc: Heuer, Konrad; ando(a)OpenLDAP.org; openldap-its(a)OpenLDAP.org Betreff: Re: ITS#4656 OpenLDAP accesslog overlay using "changelog = dialect" Hi, I have not been paying attention to these changes since Ando was = working on them. You'll have to ask him for their update status. Since you've already posted a query to the ITS, I think that would be = the appropriate place to continue the conversation. Looking over the ITS just now, I would say the tweak to register the changelog overlay type is unnecessary. Nor can you fairly deprecate the LogStyle parameter, since that appears to be the only way to invoke the SunOne workaround. All in all I understand your motivations for pursuing this feature. = Despite my dislike for broken specs and broken code, I will not prevent this = patch from going in. But you should realize that wrong is wrong, and just = because Novell, Sun, and Oracle software is broken doesn't mean we should be = broken too. There are other IdM packages out there. Rieger, Sebastian wrote: > Hi, >=20 > I submitted a patch to update the old overlay of Neil Dunbar to=20 > OpenLDAP 2.3. It works for our identity management (using Novell IDM=20 > 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP=20 > HEAD I would like to ask, wether the patch to your accesslog that=20 > offers changelog functionality (ITS#4656) is likely to be committed to = > CVS HEAD in the near future. In this case I won't maintain a separate=20 > overlay. Thanks in advance for a quick reply, we really need changelog = > functionality as Novell, Sun and Oracle seem to depend on it. >=20 > -- > MfG >=20 > Sebastian Rieger >=20 > Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen = Am=20 > Fassberg - 37077 G=F6ttingen > Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 >=20 > Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des=20 > DFN =FCberpr=FCft werden:=20 > https://ca.gwdg.de/certs/root-classic/root-ca-cert.der >=20 --=20 -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/ ------=_NextPart_000_00AD_01C74F6A.DE443C50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMTMxMTMxMjFaMCMGCSqGSIb3 DQEJBDEWBBSwSnJ1bnf4txKRhhP5cPI5qmC8oDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYBrUMIWY8INUcy7LXqf14+Xlac8VcW5yqtR62zQzlQckIioP+K7t1EGe30zRc+ouMPC Z/03XAqTzk2CV9oI9fSIjwkN6Q9dTCiO5jbDiIGDqcF2k5Zkcwk5ebXkiWu51XjtBvj9zFvDUJmd DZXSmr5/oz2pK+GXv5kQVKlCeF9hqwAAAAAAAA== ------=_NextPart_000_00AD_01C74F6A.DE443C50--

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2007