openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#7252)
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

This is a multipart message in MIME format. --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT regarding the first answer of my mail in the mailinglist applying the patch does not change the behavior! Patch: diff --git a/servers/slapd/back-sql/search.c b/servers/slapd/back-sql/search.c index cadd036..92d3f82 100644 --- a/servers/slapd/back-sql/search.c +++ b/servers/slapd/back-sql/search.c @@ -325,7 +325,7 @@ backsql_init_search( rc = rs->sr_err = LDAP_REFERRAL; rs->sr_ref = referral_rewrite( erefs, &bsi->bsi_e->e_nname, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , scope ); ber_bvarray_free( erefs ); @@ -2336,7 +2336,7 @@ backsql_search( Operation *op, SlapReply *rs ) if ( refs ) { rs->sr_ref = referral_rewrite( refs, &e->e_name, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , op->ors_scope ); ber_bvarray_free( refs ); } --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DDE link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>regarding the first answer of my mail in the = mailinglist<o:p></o:p>applying the patch does not change the = behavior!<o:p></o:p><o:p> </o:p><o:p> </o:p>Patch:<o:p></o:p><o:p> </o:p>diff --git = a/servers/slapd/back-sql/search.c = b/servers/slapd/back-sql/search.c<o:p></o:p>index cadd036..92d3f82 = 100644<o:p></o:p>--- = a/servers/slapd/back-sql/search.c<o:p></o:p>+++ = b/servers/slapd/back-sql/search.c<o:p></o:p>@@ -325,7 +325,7 @@ = backsql_init_search(<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rc =3D rs->sr_err =3D = LDAP_REFERRAL;<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rs->sr_ref =3D referral_rewrite( = erefs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       = &bsi->bsi_e->e_nname,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       scope );<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   ber_bvarray_free( erefs );<o:p></o:p>        = <o:p></o:p>@@ -2336,7 +2336,7 @@ backsql_search( = Operation *op, SlapReply *rs )<o:p></o:p> =             &= nbsp;         if ( refs ) = {<o:p></o:p> =             &= nbsp;           &n= bsp;     rs->sr_ref =3D referral_rewrite( = refs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        &e->e_name,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp; &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp; NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        op->ors_scope = );<o:p></o:p> =             &= nbsp;           &n= bsp;     ber_bvarray_free( refs = );<o:p></o:p> =             &= nbsp;         }<o:p></o:p><o:p> </o:p></div></body></html>= --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg)--

1 0

(ITS#7252) Referral Problem with SQL Backend
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

Full_Name: Robert Eikermann Version: 2.4.23 OS: Ubuntu 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.226.168.114) Hi, regarding my mail to the mailinglist: http://www.openldap.org/lists/openldap-technical/201204/msg00053.html I'm using openldap with SQL-Backend (Postgres). The configured referral on this server behaves not the way it should. The bind dn of the referral is overwritten by the bind dn (of ldapsearch). Following are the configuration and the Log files of the LDAP Server with SQL Backend at Loglevel -1. In the Logfile you can see the starting of the server + the search ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de. I think at line 4114 one can see how the referral is used. Slapd.conf : http://pastebin.com/tvtdNaZ6 sql attribute mappings: http://image-upload.de/image/WcDeaB/fd191aa422.png sql entries: http://image-upload.de/image/qGiBOY/51496a9462.png sql object classes: http://image-upload.de/image/Rei0X3/4f6b2b43f5.png sql oc mapping: http://image-upload.de/image/TRscIQ/7141e04af6.png sql referral: http://image-upload.de/image/LGxZKQ/28773fadf7.png ldap Log: http://pastebin.com/N8NCyLzt To demonstrate the behavior: Search for the referral Object: user@user-desktop:~$ ldapsearch -M -xLLL -h localhost:389 "(objectClass=referral)" '*' ref dn: dc=tim,dc=sselab,dc=de objectClass: referral objectClass: extensibleObject dc: tim ref: ldap://localhost:390/dc=tim,dc=sselab,dc=de# which is exactly what I want! But searching all objects: user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de dn: dc=sselab,dc=de objectClass: dcObject dc: sselab # refldap://localhost:390/dc=sselab,dc=de??sub Results with the wrong dn in refldap! Search with the dc=tim DN : user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=tim,dc=sselab,dc=de Referral (10) Referral: ldap://localhost:390/dc=tim,dc=sselab,dc=de??sub If you need more Information please let me know. Best regards Robert Eikermann

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 19 Apr '12

19 Apr '12

On Thu, 19 Apr 2012 06:16:16 GMT, masarati(a)aero.polimi.it wrote: > A definitive and simple solution, although invasive, would be to: > > - add a o_internal flag to the Operation structure > > - add a macro BE_INTERNAL(op, rs, op_type) like > > #define BE_INTERNAL(op, rs, op_type, rcp) \ > { > int save_o_internal = op->o_internal; > op->o_internal = 1; > *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); > op->o_internal = save_o_internal; > } I imagine connection.c:operation_fake_init() should set op->o_internal and any callers which disagree should unset it > fix all calls to internal operations (brrr....) I do have a patch+Perl script which wraps all operation(op, rs) calls, but it doesn't know which ops are "internal". I want it for the SlapReply cleanup (ITS#6758). The only way to make a hunt for dirty SlapReplies feasible. I suggested it when I was doing the cleanup, but IIRC nobody replied - except there were related complaints that my cleanup was too invasive. http://www.openldap.org/lists/openldap-devel/201101/msg00039.html http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt Anyway, here's me trying agin again:-) -- Hallvard

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 19 Apr '12

19 Apr '12

>> Thanks. The explanation is always simple, after one finds it. The DN >> of >> accesslog entries is generated using the reqStart AVA. When logops all >> and internal operations take place, multiple entries are generated with >> the same reqStart AVA. So an internal search which is logged because of >> some overlay eats up the DN of the modrdn, and be_add() called by >> slapo-accesslog(5) fails because the entry already exists. >> >> Although logging internal entries could be of some use, I see two >> solutions: >> >> - modify the value of reqStart (e.g. instead of using o_tincr for the >> fractional part of the timestamp, we could use an incremental counter >> initialized with o_tincr and incremented at each logging within the same >> operation. The counter could be stored somewhere in the operation >> structure (e.g. in o_extra) >> >> - prevent logging of internal ops; again, this could be achieved by >> setting a dedicated o_internal_op field in the Operation structure. >> >> Since this modification could be intrusive, I'd like to gather some >> comments before proceeding with a fix. > > Hm, we've run into this similar problem before with syncprov and > introduced > op->o_dont_replicate. As a general rule, accesslog is meant to log user > operations, not internal operations. Currently accesslog checks > (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. > I > guess we need a more general flag instead. A definitive and simple solution, although invasive, would be to: - add a o_internal flag to the Operation structure - add a macro BE_INTERNAL(op, rs, op_type) like #define BE_INTERNAL(op, rs, op_type, rcp) \ { int save_o_internal = op->o_internal; op->o_internal = 1; *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); op->o_internal = save_o_internal; } fix all calls to internal operations (brrr....) p.

1 0

(ITS#7251) MDB shared mutexes ambiguous on Apple/Windows
by hyc＠OpenLDAP.org 19 Apr '12

19 Apr '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.151.244.127) Submitted by: hyc Currently since MacOSX and Windows don't support process-shared mutexes residing in shared memory, MDB uses global named semaphores instead on these platforms. The semaphore name is derived from a hash of the pathname of the lock file. This approach was quick and dirty and is prone to failure if relative paths and absolute paths are mixed, or if a file can be accessed thru multiple paths (e.g. symlinks, loopback mounts, whatever). Instead of the pathname, a unique file identifier of the lock file should be used. For MacOSX we can obtain (device,inode) using fstat(). For Windows we can obtain (dwVolumeSerialNumber,nFileIndexLow,nFileIndexHigh) using GetFileInformationByHandle().

1 0

Re: ITS#7239: testbed
by hyc＠symas.com 19 Apr '12

19 Apr '12

masarati(a)aero.polimi.it wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms020801020604080509050502 >> Content-Type: text/plain; charset=ISO-8859-15 >> Content-Transfer-Encoding: quoted-printable >> >> masarati(a)aero.polimi.it wrote: >>> =20 >>> The attachment is unreadable; can you ftp it somewhere? Thanks, p. >> >> http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 > > Thanks. The explanation is always simple, after one finds it. The DN of > accesslog entries is generated using the reqStart AVA. When logops all > and internal operations take place, multiple entries are generated with > the same reqStart AVA. So an internal search which is logged because of > some overlay eats up the DN of the modrdn, and be_add() called by > slapo-accesslog(5) fails because the entry already exists. > > Although logging internal entries could be of some use, I see two solutions: > > - modify the value of reqStart (e.g. instead of using o_tincr for the > fractional part of the timestamp, we could use an incremental counter > initialized with o_tincr and incremented at each logging within the same > operation. The counter could be stored somewhere in the operation > structure (e.g. in o_extra) > > - prevent logging of internal ops; again, this could be achieved by > setting a dedicated o_internal_op field in the Operation structure. > > Since this modification could be intrusive, I'd like to gather some > comments before proceeding with a fix. Hm, we've run into this similar problem before with syncprov and introduced op->o_dont_replicate. As a general rule, accesslog is meant to log user operations, not internal operations. Currently accesslog checks (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. I guess we need a more general flag instead. -- -- 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#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

> This is a cryptographically signed message in MIME format. > > --------------ms020801020604080509050502 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >>=20 >> The attachment is unreadable; can you ftp it somewhere? Thanks, p. > > http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 Thanks. The explanation is always simple, after one finds it. The DN of accesslog entries is generated using the reqStart AVA. When logops all and internal operations take place, multiple entries are generated with the same reqStart AVA. So an internal search which is logged because of some overlay eats up the DN of the modrdn, and be_add() called by slapo-accesslog(5) fails because the entry already exists. Although logging internal entries could be of some use, I see two solutions: - modify the value of reqStart (e.g. instead of using o_tincr for the fractional part of the timestamp, we could use an incremental counter initialized with o_tincr and incremented at each logging within the same operation. The counter could be stored somewhere in the operation structure (e.g. in o_extra) - prevent logging of internal ops; again, this could be achieved by setting a dedicated o_internal_op field in the Operation structure. Since this modification could be intrusive, I'd like to gather some comments before proceeding with a fix. p.

1 0

Re: ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020801020604080509050502 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >=20 > The attachment is unreadable; can you ftp it somewhere? Thanks, p. http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 --------------ms020801020604080509050502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxODIwNTAyOFowIwYJKoZIhvcNAQkEMRYE FO5TfD14PMXVNCzh4rtO6MQEgfVNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAWC2ZU3Z19tk5FafFmH93ox5VIq85YoZoKvQEjiZC/aWis578hUnfkJXS/Dh+Ltt+dyj/ t3DzDSlJHBbvjyAoReVO54SwPKpJZE8SadEXNLK31Cs6J0QJFHt3gW9nW2wr/sXcNnLHqxxm fq8Ofn3ztGC5bxBa2BYTKGq/23Oa6zDK/5GfG7BTw4KZ4JlpGat0/12z9oqDgNkYCEEHFmVa bXNGpFnV5e0+ngjIqBvdRt80iuV9et3vXRBWrJWJMC0uA5NfKWldOh3Ov4WL/GKl2PtCWRo0 Q3twLoa88WPMWDdZzKeKRLvxQxMtYCh2ZIk74aNAATNXPznIDyMnlWPqOAAAAAAAAA== --------------ms020801020604080509050502--

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

The attachment is unreadable; can you ftp it somewhere? Thanks, p.

1 0

ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a multi-part message in MIME format. --------------000704030300080804030201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit See openldap-testbed-its7239.tar.bz2 attached. You have to adjust paths in the config of course. ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f initial.ldif ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f modrdn.ldif Now look at the accesslog DB: ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" => no results. Now repeat that with "logops writes" instead of "logops all": rm db/*/* ldapadd... ldapmodify... $ ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope oneLevel # filter: (objectClass=auditModRDN) # requesting: ALL # # 20120418194545.000001Z, accesslog dn: reqStart=20120418194545.000001Z,cn=accesslog objectClass: auditModRDN reqStart: 20120418194545.000001Z reqEnd: 20120418194545.000002Z reqType: modrdn reqSession: 1001 reqAuthzID: uid=diradm,ou=schulung,dc=stroeder,dc=local reqDN: uid=test1,ou=schulung,dc=stroeder,dc=local reqResult: 0 reqMod: entryCSN:= 20120418194545.412289Z#000000#000#000000 reqMod: modifiersName:= uid=diradm,ou=schulung,dc=stroeder,dc=local reqMod: modifyTimestamp:= 20120418194545Z reqNewRDN: uid=test2 reqDeleteOldRDN: TRUE reqEntryUUID: 86014e61-7c47-4062-931f-39526f738016 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------000704030300080804030201 Content-Type: application/x-bzip2; name="openldap-testbed-its7239.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7239.tar.bz2" QlpoOTFBWSZTWUmYCwUAHGV/pf7wIiB//////+///v////4AQEABQAAACGAYTc+5LsPvZ6D5 S0u9988PvuzvWcErt3vmfHtqpub6fXnZrqotFaNWzWqBSlaalKe2+3rXQclH00F7PXeEkhBG mIU9pMnpMTRT8ieptUep6ZTyjaTNQep6mnqPUwmmgeobU0yHqCSITEAJpKeanqbSpptG0j1G iDaTxTQep6hhAMaNAgMQBiJqZBU2p6g9qjRo9QGmajQBoaABoAAZAaAaaDCTUiECRmk9KP0R ogyNNDIekMmgGjQAA0AGmgAEVET1CmnjU0mhiab1TENMmTJkMgyDaIPU0NGIeoMQGjAkSCAE ARkI0yaT0A0KnkhsoaHqaBoNNGQaGgAPShWelmPPk8yZHbmS0CkHt1gnOGQDrIJCM+7nzfOc Z72Sqn4gqiDACCJRBhlQZGTF3hTvhTvZsGMJikIgTnLCIQGUJJIZUVEREUIJEJ3/vXuwnL7p h3znhR3iv2MqIbboLeIBa0NpJjEKAunYNEppc/8z2oXvOhXcOtedrYOHXT4cOK+BIpwcvGhh 3rpNlphr7KbU4qZBqPd5JTP4b5kzQsRFrYeTYoyPyO2pMXZeuz3bMfqwXrYiphmDAdn3jf+O qu/IsCyfb+1mfpLOPWlcNDaA2J95Jrz8+3sfZOWNO7R9/fXyupdZdO27I5jOHhB4NNpNtMsj 3eQM98bZDYslevmFrskMW6HaOzD3qoqlC/zVcT/aUU2KORwxAnm50pFOzZbZqCFbDKcVOyWC lHkKw+R2kr0ZbuEjc2mVeLq69FdhfdFiC08bNU1Azp2+uPze6MAxeP5Ll2vd7SO4JxeO6fCQ jeAwGqU3mugGJ6g6TI82RW0Z0ehKN+Dm9RmdFORarbZkLW0xmfbq9mHPbZl/xsI8ZhSzlsPo JMSEH0ZqDugLWjzoTQghG4wFUhiGcVicNgXpyDAhYPoSZgqkT4zA5QWBQ1EtyVOi79Orq4m8 26fG2+bvViPZTLw+GqXWeFK98VtI8mG38E38EC/H9aYxChiGNTQtqf64f2g11kkgmJ7zbgT4 ++vXWu17abfMoXxNUh4Q2gQhTxw0aURDyMaKROl4U4w4bT072Vhso7qWsOMXF7+pIMPsHQE2 r8TqlkfLIXuKn5zSCDE+nX4eesv9xhEz3Skw458ZIfd3Ekc4IwHyKBcEl+nvrv+dFLkcsydz DGkDrBP1WcfzmZSofJoL77NROzH25fZH13e8Wt/I0I45rlhL09SsK2TIL+cHvlx+JMxYYhjx lLHixxdze1zRXjdw0Ia5T2DYfWcTI9JYHxRXXrxE69qnPFsYWUNFZE02shprwKa1+bGyBtJ4 MWWubpGPnILszMj24321nWdN/a2zO5np27zmuibmxyTkOKuic8s7eC8SoHOb3wYZOHJb4OfL DGYWxt037dQqLa7hql0EBcZ4E/5zLurQ1Y4u9HdoZG6K7lePA8dbMe2BbrsG12cdoX2rYa9s 7zu6i2K2naGeGebxh5i7LRdunRDgrkRYUto+yeJSgykk3ulSGTy4XGXCPMo6+6tnnOOWGSwZ jGnfWRkdlxFweYw5C9LXKtvHbJeRsGfBnJbFtp3iJIEGbd3opT0RGKq2HBIGxRyl+zFLXtvV Z/5bdCW/ZIz5bB1dxotZoXnZ3XSMEwLdakUtJULO7NTVWcsSTnuZMmplpyYJI4iQJccNiiP0 nDuSST7zyjAX/EzxqK8tmedVfcEKqn1pD/UgsCLAgLAUIcsFfDFWIrACoCkmBG7Wybdrq42H Iptw6k2jiRJFemKBLGK5iy/fhg8M1zhMFoTG9HLFofMpI0ENdP6Wz6PBUt6BAB822kqtrN9W NzLrhTdRp8164pkzLVvMwsoOALx/JdV8cNs/gqIbufg8vXf1rv79IHwys9CJulGHpPhhzyT0 er2NM3iursXVdQtfwmC4VEVTnX2wpGFIzS0QrYZs7rVnvS4jTLppJX2pzSWj2uLm5yoS0pL0 efh4DzfjBeWMj6WJi1oVv0FVvwdx/iJjn2BFrygHR9EARWCDdLmkcT2EI3jOJJ9OaOylyRQQ A2zn9xO6xnsIRSWtBglmZyjbfsxz5i9ekNi+SQQoYJsfkAiIckIgKuEKovIDwSAkheN6Z5zy XhL2qQIMxNkkSAQxNo/G9Tw70sFmRyhGO/m3a05XdH67x++8Oh21wKRnoqZdP5Zauj8X4wYw fT00Pws13lqHUB+P3tEKb1qn9W5KdGbeAjelKQF96DQnYFUNNDWXXJWITNGsKU16eYNtLHjB ZGEhYoGV8ULrfPA5oEw4gd3s/oPdWwSSN6IE06OY9dgHaJTgkGFRSSQgJCbbQqeSSHX1YeX9 9/P1dU6StjJDFxVPETsTfDZObiu6RfrIKnC+CRa5j6+O8lhfZzt/vJx+LOOtf0Wu+WR7656J BACIAQ0kBoPHXaSBFG9s2PzmL+YeytHBHz2CHjF0gspGOe2fVKFUKYbQuuSCsFOFUggc8lEw Z6tNlNIaGTEscMyBOjvdCHNtUg2+evYSkCMOeCygfmOT5RxbQvSB8xNI/Jx3IRIxGwhshDrw pGfPMljZE/QOUm4sfrRi7Eb7nLCErW3kUCM8GYqhEmhWq21iQSjQmWwQiMEKiSvrRUpWoOeB VAi2QjZnN3ZUMEjAmILW6qAQ2oI2isrY7IsxusKY0mO/E+ZJIJnF1he0S+hSoIm2FIONiTuE eimQiJ1E5y0u0h5X4lAEUSCtsM0DUZjnqRvZFl4UCcqEFUFTGCQLgWQiU5pRhe2JuDdYTUIp XjywERi117pFg7vmqoVd9hYX44wxbQ6ZTIGNOaVTp2jU0ThBRa7i5+rovnwtjNfU+HRBy6eJ Kevi49xJmx5HQaRmiiKjzThO1oPlvc3vL+yje9UHX29FQLO5IOx2RJlJ26CV9LLPAe0vr+3s TXme5p5pjq/MAmETgGyFYT9V5OiZz3xnvKnsWN/tHqJiN0Y9GL0CZ+1oTu/cN95lQmMwxPjF UCUlfrOseHL8X9nWb0eWfUi+UhWVJE4xS0wSn9IqOL3lkQZRkJmXVJPicOdrTZ2SlLYkdohD RkAYJHI3wbfzGmgMBvy3hRgk8Qyz+w9wTPXtjaPM9YcDP9rquUGLKhyObtkAUvU9RcYMx4iN CxNnDoZ8pBL3b+4PmIvDiAeSgcC8+wxSVTQ9Zv2aoqbjsOwgcgYZmV07txlDerMwBWIiSXR8 zgDgMncLJtZdw0GdmYuEI1kSDgtvcH86biJQ2H5Mc/IMEce2HHd9MwTUJJyFcDWBG4WvwSQ/ m37zZdB4+DbaD4oSOi2o5k6ksic5ScXHSzaH1Hr31XmR3d2S9OhoWLGOuXboRMhajlhqSWQx HCONorkG5bNdmh1MqWRATzq2kd8sEN6MGaCNlza8VrWf0vNw7wS8DoR6QGsep94agtVajEMg hQDGhpkH2sOI+Blslm/HUa7ZncGvPmdKSGG9raBspqEEl3Ly0ZMjQXVpluYM6FB/FcnrAGEU K4tjNCyYANqgpAMdpCROyL4giYMRKI5ZQBUWFlWFpUnCsUFjuaDOl65tPzPqOXrO8+AxQQzs JGKF8Uc22ga+cZ0hQEMugQ7I+lEASBgAdfHpysThPJ+JZzSsi8zHQZwKYBmfeesR++uL/UbD 6H6EdKYwxLVdf9ZRoRB8Mgd4uA3Ky0WVRx7icSnClxkUiYpqIIJr33ej9B3A3CbpNO7JWBfk DQiKCCQVgiKDhM1UvQ84Y20ldJaay1PTzi4FAGhW2UCHOIkg2EdL4IVIzDQ6SiXl4HKyoSe7 OCWvqPYYBmwcENChkJFlp6RDusbrrDodIIbAcRB7gi9SOHbYYtmGOV2xUMIVzreFg8mRGDSW Ikl206i3N8/AcrDALQPjvCNcxMbbDcu486AIFkgCD1LOiYbG31bf7BdpO8QxGSETAjJIMTkT u7sCxL3et28QWMhgQytBaLUY4DUpSqEFpI9rDaTMWte19G0B0o0TSRFgZGfQ39DXaKwYJMoN iS5EGSqJZOhDQgaSBsMSQr+3fnO4MZkwR9G2gHMVqtngMFaGUtQDkKZQuUWLGqBlJqyIUdN7 ilSkqiz0iAckmRwaJJ9viIg8zPeMKnAQf16v+9+UlvNpIlJKGBsElkmwsVeFkvRje3YW9obX x8qhiicwwuN8GxhQMG+aiwwRzDnzlOYpQhhUsniGNpMlcZxCUD41FSX0rpkkDXkKPmPt+B63 wRUR9DsEh3ngI3Gj7Gd5wWaOLWjvtVd4wGFNWU3iQfYSFsGEbEwFj2DEeOBHlkVWDWsvzwHw Mqjb/UXRUmqmZjGlJgUN+2xoGuZi1C7Hp4hq6+ulYJe2JqQJtIL5KQ0oYWB1GjNQTylYYmyh 6Cmlca0kMpZpF8WyBsvcMtRlFnHZN00sa1rna57rqQlAg6yvearR6FyzxcM74LajeDTJLGpT CTzsrPZpWU0r8LjOTnIq7GrSxlqLBoHLLEDsrDpFHXM+VtTrmoP7JJaOY3Z000Ik0WxFrJDo juKFN6EWKwnwFLoEhbr0Y3Efdpl5DbTncjAVhJp3Go5oWnyiGlw2bZiyRgzYZI2gI/he8kjk qqQWAaM1cYrXdrmeoakBw1N5tRAjBbmFEekE7JzBY4CGXhZGO1la6y/JMbtT9kd0gL7L3kQQ tQ9KbaZZxVkWitmRZmlOEEhg1pAEEhkog8RRFX4DlzeDD0SpdNUHT7rAExDcjjCM9I7JygFV ejrxmPi1XRxlj1WKpEFpbPmNVXFbRV4JgxoNdQvaEUTOdi7GSi1sjIRf4AYl6rVJLCfUe70y lVGV+DS5ip3rjtoy2LTb1WEk/G/2zlMiYOdQ2jAUEGdZloFpQke5i6IkS+bQSunkocEPwgRC knYwlh61zRaGB4BEloXuTPtSZ8CVCyqvFVLL60Xpx+d81UpWdp5KDGbxTHZHymEg2cu1ChkB tSpmoqMJcoCdM6/YMLlFUCNTt0YwYCP42g8nUKtphr+PQluPZ68K2FzZ1KQQCa1zVT2EHCod bZCSD1kMbvAj3+2aESmHSGz7ZnpeURfHsaUhwODhz0FsMS76y27V6vUY2OANWYOh9ozdmBFR Jpw1otrN2c147aS22m8Te7UeMGAVtYN+BhsA4CLPYQKv4s8W63MKezzwcdmORshtG+6QY6rz Y5I6Dhl9QxD2RZzuvSMBoJDA7XDA1w5fDE8zf5GLJuHEIIKpljvbNugMsIhks8Zp6XFS+KQX qb4pSJtHUXpMgLztQiasCVegrgmJgZiZqQBiTA2DfGEKBtYl6gzUVSba5vEU+9VLZpVVtVKq rpz86RcqbzKQdeqD2DCwlCbbFDNtkS0IrgQTSYi1NLvRgZNN+kPUFbRF3jgkNjXcQfDcZ8wu jmN4vz219m1IMhGEOohtRY9WXN/bOAz08R9QdR2aEBJjJkSZJGs1JE0Qhwxl9mgq4lCmd5IW xaZaUkll43RQYDOiMfxt+FI4LVkcfLtI7UbsdNOJSUG4RQgFPaD2ViHNQQcqyEIkbAEaI+D7 aT6EXDEqtSZgci0CqFRg7TSQM7JuDKQiBRGsdDCplkRV8G2QokvFC7epKlsQRYrwlfIc6bxQ su4MAk8WlejQUUO9gosVVc9GWvfOlmOFmdil+CjSF3UsLQslgq1oJzLlrKhRlje+RTTzMUqF EKiFaVUMYw4NZJB6GfsEz7bCRgIPdDNVqKvoblpYuNwtFuTkGGkEdDW7jJQaWUHBhCGRczID IJM8Ka0oaJsq7hDZ27QLgiiEsBCJAehXa7phadcJWKWQ4o2EDKFgsUVRgqXZuQvAtMCrwFnh VWscHJLMXQbCsTcgJ1DqcZINbTjuc2HWO0VOfYJYZmQVpWSnMZFUop7JBmUxhRnIVBWqK8F5 T/28nx+NeGeVqYhHlK4RpNjQ39hPpNEyCHKRiVRUUYC9Ayu2xIHYHf9ddlBgXQGRMNvfJSLY N1C1dv6P5mbQ3+PHcbndtPbBBf+ChniH5nUQDFpLrn8wpu+KmKpSiIOIPALbWps2XfcOLr7t 6cbxD5HKuKvSDCKpX3HfrO8Msr/EVI5Hf91PaNIS+bhJiW8GfUZ8wKIhe3NwOojxBBJ4PHOg RIzIMbRyymaqeYiDicqCtEHcZNB44pb5S2o7J+25R0Sjsdu5C2joAE+KiLQT1ohUHuRGSUio KrGFUQWEApkMYX46sS+qwVkZKmxbEAQTONXKAkSUda9GVFVhBQM0aPSN5ZOqjTUVPwlTbUrJ U8wfGVS9QVX4MtYxsNAwoZIQQw+dzFBWaiesN5BNFGJDTCgkJvvXPrRW8qeaRH2pgGTEDBnB CiQ9eC61VZASKMIiFedSF1V7cmWydInBFmudiCxcfv1uWeY/Vyrgjk5g07xzqrERbkO0rHwt ng05jESw8EVAla9ubomONIsulV5CRAishTcgpk4HhxpO3vDixHhBEPoQEjkkWGBuxghjV8Ih ruzxJ9LRvZX7DEffMlhiokhsSfc5jSHhq1TMkNMFvLoLCIPiSitTAW4zV1GGYbXvZgQ1y4Tn XVGgA14Fi1LFIzYNJpm1wEoAiYMT17CbYSHCFqu0CaEVKosJKKcEhggsT3K9UqZ0PyldYbiq opBkQWk7oITjX54bBjMCGBnDhBaWObgxaWxIbcStsNRh7WtSToVSpXSk6kzrETRRILkXVIGT GpDGkTQZYSupUS+9PiWTUkTkvumiaEWAXCC9BIzMjOhDyZE2RQWnD0EsKZzJip5bsOyQSVMA oreC4oR6xqVSSoVzkmrYIGNKYSBoZ0zUFRYAemqieYXFjA6Bq1lAbcnerUrV0lUiJ3q8qJGQ yq0eC7Q4qxcTC7z1BBSYcobEhQ00Gl5K/gTJsYI2UNA9VG0AcS6LEakktbd0a0L1QtCH/Nkc BJNNayNQjTKsiYQHioMl0d3wJLnh/rnqvTDd4DjsBniuAJ0x7SOAwDFgtahmvJeBTvy9F95I CMBSpFkK7kiJGA2zZHaWP+QtSD7mbDmQW//IV5KYIMEHbHd0x2uD2ZngVb6sGw/WifgqUHH0 CRIodpSZaDaTOQRVtlgbAuL7oNVJSmSFpaWTzy5ViizNJyuhw2Diw1yyXSZKxkJVGWBMKUUO xlFU7ZFS/uNSfmIZaeQqADMULa7HJtBWMANsf+PrPP53/oN8o+Q3V0xPWVg+TayXv9HhJAGy LuSKcKEgkzAWCg== --------------000704030300080804030201--

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