- openldap-bugs - openldap.org

(ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 03 Mar '08

03 Mar '08

Full_Name: Ali Pouya Version: 2.4.8 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) Hi, I am testing OpenLdap 2.4.8 in mirrormode. I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with a retry interval of 10 seconds : retry="10 +". An injector writes data to A. The data is replicated in B. But this server UNBINDs then reBINDs to A every 10 seconds ! This continues until slapd on A crashes with a SIGIOT. More investigation in the slapd log shows that the crash is caused by the losing of the client syncrepl connection coming from B ! If instead of B I configure an ordinary replica everything is OK. I think there are two distinct problems : 1) Contrarily to an ordinary replica, a mirror ends the persistent search, 2) slapd crashes (very scarcely) after losing the client syncrepl connection to which it was going to send data. Below you find the backtrace after slapd crash. See also more protocol details after the backtrace. If required I can send any detailed information about my configurations. Thanks for your help Best Regards Ali ============================ (gdb) bt #0 0x009b47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00138815 in raise () from /lib/tls/libc.so.6 #2 0x0013a279 in abort () from /lib/tls/libc.so.6 #3 0x00131d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0805ecb2 in connection_state_closing (c=0xa272585c) at connection.c:680 #5 0x0806c444 in send_ldap_ber (conn=0xa272585c, ber=0x9f7f3c00) at result.c:153 #6 0x0806f192 in slap_send_search_entry (op=0x9f7f3f50, rs=0x9f7f3de0) at result.c:1187 #7 0x08134038 in syncprov_qtask (ctx=0x9f7f4210, arg=0x8e21498) at syncprov.c:809 #8 0x081472df in ldap_int_thread_pool_wrapper (xpool=0x8cbf880) at tpool.c:625 #9 0x00a4e3cc in start_thread () from /lib/tls/libpthread.so.0 #10 0x001da1ae in clone () from /lib/tls/libc.so.6 ============================ More protocol details : 1) As an answer to the SearchAndPersist Request, A sends to B an LDAP message [OPERATION 25] (which I do not know). But this message is not sent to an ordinary replica. 2) I also noticed that after sending UNBIND, B sends a [FIN, ACK] TCP packet. As A does not ack this packet B sends a [RST, ACK] packet 30 micro-seconds later.

1 0

ITS#5145 [Fwd: Corrections for the autogroup README]
by postmaster＠altkom.pl 03 Mar '08

03 Mar '08

-------- Original Message -------- Subject: Corrections for the autogroup README Date: Mon, 03 Mar 2008 11:48:16 +0100 From: Aleksander Adamowski <aleksander.adamowski(a)altkom.pl> Reply-To: postmaster(a)altkom.pl To: hyc(a)symas.com Hi! I'd like to add some grammatical corrections to the README file for the autogroup contrib module: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/a… The description section should read: DESCRIPTION The autogroup overlay allows automated updates of group memberships which meet the requirements of any filter contained in the group definition. The filters are built from the LDAP URI-valued attributes. Any time an object is added/deleted/updated, it is tested for compliance with the filters, and its membership in autogroups is accordingly updated. For searches and compares it behaves like a static group. -- Aleksander Adamowski Administrator systemów korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. +48 601-318-080 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message. -- -- 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#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by ando＠sys-net.it 01 Mar '08

01 Mar '08

kurt(a)OpenLDAP.org wrote: > IIRC, it's not listed because it only to be used in certain > (extensible) matching rules cases and slapd(8) doesn't support any of > those cases. Technically, I note it's skipped by syn_schema_info() because it has no validator (like many other known syntaxes). I don't recall the reason of this behavior, though. Perhaps it could be relaxed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by ando＠sys-net.it 01 Mar '08

01 Mar '08

michael(a)stroeder.com wrote: > Take note of this: > > authz-regexp > "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" > "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" > [..] > access to > dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" > by * auth > > > See test of recent RE23 (port 2003) vs. recent RE24 (port 2004): As indicated in OpenLDAP 2.4's man page, now the LDA search operation requires "search" privileges on the "entry" pseudo-attribute of the searchBase. This was introduced to be able to honor the "disclose" privilege (or, at least, in conjunction with code that is used to honore the "disclose" privilege). The man page is erroneous in stating that this requirement and that feature were introduced in OpenLDAP 2.3: the code is indeed present in OpenLDAP 2.3, but actually #ifdef'd; it only became the default behavior in OpenLDAP 2.4. This requirement, as usual, is downgraded to "auth" when performing authc/authz related lookups. I'd take this ITS as a request to fix the documentation (indicate the change since 2.4 and not since 2.3) and to better notify the different behavior since 2.3. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by michael＠stroeder.com 01 Mar '08

01 Mar '08

This is a multi-part message in MIME format. --------------080909030908010602050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Follow-up on openldap-software repeated here... Gavin Henry wrote: > Michael Ströder wrote: >> >> I tried to migrate an existing server from 2.3.39 to 2.4.7 (or also >> CVS RE24). I'm making use of authz-regexp to map user entries when >> they do a SASL Bind with DIGEST-MD5. Also some ACLs are in effect. >> This together used to work on 2.3.x with the existing ACLs. >> >> With 2.4.7 this worked no longer. The user wasn't found. In the ACL >> debug log I've noticed that access to the search root database entry >> (suffix) is requested. When I explicitly grant auth access to this >> entry it works. But why is that needed? Was this an intended change? > > Can you paste them? I've prepared a simplified slapd.conf and a LDIF file (both attached) for this particular migration issue. Take note of this: authz-regexp "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" [..] access to dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" by * auth See test of recent RE23 (port 2003) vs. recent RE24 (port 2004): ----------------------------- snip ----------------------------- $ /opt/openldap-RE24/bin/ldapwhoami -H "ldap://localhost:2003" -Y DIGEST-MD5 -w testsecret SASL/DIGEST-MD5 authentication started SASL username: michael SASL SSF: 128 SASL data security layer installed. dn:uid=michael,ou=users,ou=authz-test,dc=stroeder,dc=local $ /opt/openldap-RE24/bin/ldapwhoami -H "ldap://localhost:2004" -Y DIGEST-MD5 -w testsecret SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) m ----------------------------- snip ----------------------------- If I grant auth access to the database root entry ou=authz-test,dc=stroeder,dc=local it works (see comment of this particular ACL in attached slapd.conf). With RE23 it also works without this ACL! Ciao, Michael. --------------080909030908010602050105 Content-Type: text/x-ldif; name="initialload.ldif" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="initialload.ldif" dn: ou=authz-test,dc=stroeder,dc=local objectClass: organizationalUnit ou: authz-test dn: ou=Users,ou=authz-test,dc=stroeder,dc=local objectClass: organizationalUnit ou: Users dn: uid=michael,ou=Users,ou=authz-test,dc=stroeder,dc=local uid: michael objectClass: account objectClass: simpleSecurityObject userpassword: testsecret --------------080909030908010602050105 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" include /opt/openldap-RE24/etc/openldap/schema/core.schema include /opt/openldap-RE24/etc/openldap/schema/cosine.schema # Define global ACLs to disable default read access. pidfile /home/michael/temp/openldap-authzto-testbed/RE24/run/slapd-1.pid argsfile /home/michael/temp/openldap-authzto-testbed/RE24/run/slapd-1.args modulepath /opt/openldap-RE24/libexec/openldap moduleload back_hdb.la authz-regexp "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" database hdb suffix "ou=authz-test,dc=stroeder,dc=local" directory /home/michael/temp/openldap-authzto-testbed/RE24/data # Index-Konfiguration index objectClass,uid eq sizelimit -1 # User entries # ------------------------ access to dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" by * auth # Why the hell is this ACL needed for SASL Bind with authz-regexp with OpenLDAP 2.4? access to dn.base="ou=authz-test,dc=stroeder,dc=local" by * auth --------------080909030908010602050105--

1 0

(ITS#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by michael＠stroeder.com 01 Mar '08

01 Mar '08

Full_Name: Michael Ströder Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.104) A configuration using authz-regexp fully functional with appropriate ACLs was working in RE23 but does not work in 2.4.8 anymore. http://www.openldap.org/lists/openldap-software/200802/msg00373.html More to follow...

1 0

Re: (ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by kurt＠OpenLDAP.org 29 Feb '08

29 Feb '08

On Feb 29, 2008, at 1:56 AM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.114.177) > > > Although implemnted since 2.0 the LDAP Syntax with > 1.3.6.1.4.1.1466.115.121.1.58 > (Substring Assertion) is not listed in subschema subentry. IIRC, it's not listed because it only to be used in certain (extensible) matching rules cases and slapd(8) doesn't support any of those cases. I noticed that this came up because someone was trying to use this syntax an attribute description. That attribute description is likely bogus.

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by ando＠sys-net.it 29 Feb '08

29 Feb '08

jclarke(a)linagora.com wrote: > jclarke(a)linagora.com a écrit : >>>> When slapcat is writing it's output to disk, it ignores any errors >>>> (with slapcat -l output_file or slapcat > output_file). If an error is >>>> encountered, such as "No space left on device", slapcat then exits >>>> normally with a return code of 0. > > Thanks for commiting this to HEAD. > > Is there any chance of seeing it a future maintenance release of 2.3? As soon as one is planned, if ever. I can't say anything right now, since this issue is not a showstopper, and 2.3.41 has just been released. Unless 2.4 becomes stable any soon, there'll probably be another 2.3 at some point. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 29 Feb '08

29 Feb '08

jclarke(a)linagora.com a écrit : >>> When slapcat is writing it's output to disk, it ignores any errors >>> (with slapcat -l output_file or slapcat > output_file). If an error is >>> encountered, such as "No space left on device", slapcat then exits >>> normally with a return code of 0. Thanks for commiting this to HEAD. Is there any chance of seeing it a future maintenance release of 2.3? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

ITS#5396
by ecizaguirre＠gmv.com 29 Feb '08

29 Feb '08

Another update about this problem. Connections between slpad and the remote active directory servers remains in ESTABLISHED state for a long time and changes to CLOSE_WAIT state in the slapd server. In the active directory servers the connections then changes to FIN_WAIT_2, so it seems the slapd server is not sending the FIN packet to close the socket. Cheers. Eduardo ________________________________ De: Eduardo Izaguirre Pazos Enviado el: jueves, 28 de febrero de 2008 13:21 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 An update about the case, the problem seems to be related with the connections which remains in CLOSE_WAIT state, as an example: [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

(ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by michael＠stroeder.com 29 Feb '08

29 Feb '08

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.114.177) Although implemnted since 2.0 the LDAP Syntax with 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) is not listed in subschema subentry.

1 0

(ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times
by ssnet＠ua.es 29 Feb '08

29 Feb '08

Full_Name: maria saez Version: 2.4.8 OS: debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.145.230.2) An account locked in a consumer needs two password changes in the provider to be unlocked. The first time that we change the password in the provider the password change is replicated in the consumer but the account remains locked. Can you help us? We have openldap-2.4.7 and openldap-2.4.8 Is this situation normal? We have the following configuration: Provider ------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq # define the replica provider for this database # (last directives in database section) overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Consumer ---------------------------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" ppolicy_use_lockout syncrepl rid=123 provider=ldaps://xx.xx.es:xx/ binddn="cn=config" bindmethod=simple credentials=xx searchbase="dc=xx,dc=es" schemachecking=on type=refreshAndPersist retry="60 +" overlay syncprov ------------------------------------------------------------------- The policy we have defined: dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es cn: Standard Policy objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: 2.5.4.35 pwdLockout: TRUE pwdLockoutDuration: 0 pwdInHistory: 6 pwdCheckQuality: 2 pwdExpireWarning: 10 pwdMaxAge: 120 pwdMinLength: 5 pwdGraceAuthnLimit: 3 pwdAllowUserChange: TRUE pwdMustChange: TRUE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: TRUE pwdMinAge: 120 -------------------------------------------------------------

1 0

RE: (ITS#5397) syncrepl badly processes modify rdn operation
by emmanuel.duru＠atosorigin.com 28 Feb '08

28 Feb '08

OK I have tested it, it works fine. Thank you. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 28 février 2008 16:24 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5397) syncrepl badly processes modify rdn operation > > emmanuel.duru(a)atosorigin.com wrote: > > > When the provider server receives a modify RDN operation, syncrepl > replicates it > > with the full new DN as new RDN. > > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets > the newrdn > > from a call to dnRdn() function, which only modifies the bv_len of the > ber > > struct, but not the value itself. Following this, the > backend:be_modrdn() > > function does not check the length, and gets the full DN as RDN value > (at least > > back_ldap does this). > > Fixed in HEAD (the patch should apply more or less to 2.3 as well). I > note that slapo-auditlog might siffer from the same problem; other > overlays could print the incorrect newRDN in log messages. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > 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#5397) syncrepl badly processes modify rdn operation
by ando＠sys-net.it 28 Feb '08

28 Feb '08

emmanuel.duru(a)atosorigin.com wrote: > When the provider server receives a modify RDN operation, syncrepl replicates it > with the full new DN as new RDN. > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn > from a call to dnRdn() function, which only modifies the bv_len of the ber > struct, but not the value itself. Following this, the backend:be_modrdn() > function does not check the length, and gets the full DN as RDN value (at least > back_ldap does this). Fixed in HEAD (the patch should apply more or less to 2.3 as well). I note that slapo-auditlog might siffer from the same problem; other overlays could print the incorrect newRDN in log messages. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5397) syncrepl badly processes modify rdn operation
by ando＠sys-net.it 28 Feb '08

28 Feb '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > When the provider server receives a modify RDN operation, syncrepl replicates it > with the full new DN as new RDN. > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn > from a call to dnRdn() function, which only modifies the bv_len of the ber > struct, but not the value itself. Following this, the backend:be_modrdn() > function does not check the length, and gets the full DN as RDN value (at least > back_ldap does this). I see. In fact, while slapd internally uses bervals consistently, and honors their length, it is usually accepted that string bervals are NUL-terminated. Probably the "right" fix is in syncrepl code, although the real right fix would consist in rewriting the client API to consistently use bervals. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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

(ITS#5397) syncrepl badly processes modify rdn operation
by emmanuel.duru＠atosorigin.com 28 Feb '08

28 Feb '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) When the provider server receives a modify RDN operation, syncrepl replicates it with the full new DN as new RDN. Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn from a call to dnRdn() function, which only modifies the bv_len of the ber struct, but not the value itself. Following this, the backend:be_modrdn() function does not check the length, and gets the full DN as RDN value (at least back_ldap does this).

1 0

ITS#5396
by ecizaguirre＠gmv.com 28 Feb '08

28 Feb '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C87A04.71821EC6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C87A04.71821EC6" ------_=_NextPart_002_01C87A04.71821EC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline An update about the case, the problem seems to be related with the connecti= ons which remains in CLOSE_WAIT state, as an example: =20 [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. =20 Cheers. =20 Eduardo. =20 ________________________________ =20=09=20=20=09=20 Eduardo Izaguirre Pazos Administrador de Sistemas /=20 Systems Administrator =20=09=20 GRUPO TECNOL=D3GICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com =20 ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la=20 Informacion siendo para uso exclusivo del destinatario, quedando=20 prohibida su divulgacion copia o distribucion a terceros sin la=20 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.= =20 Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential=20 information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ------_=_NextPart_002_01C87A04.71821EC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.6000.16608" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DVerdana size=3D2><SPAN class=3D196321812-28022008>An=20 update about the case, the problem seems to be related with the connec= tions=20 which remains in CLOSE_WAIT state, as an example:</SPAN></FONT></DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN=20 class=3D196321812-28022008></SPAN></FONT> </DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN class=3D196321812-28022008>[root@m= etaldap=20 openldap]# netstat -an | grep -i close | wc -l<BR>11361<BR></SPAN></FONT></= DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN class=3D196321812-28022008>all the= se=20 connections are to the remote ldap servers.</SPAN></FONT></DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN=20 class=3D196321812-28022008></SPAN></FONT> </DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN=20 class=3D196321812-28022008>Cheers.</SPAN></FONT></DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN=20 class=3D196321812-28022008></SPAN></FONT> </DIV> <DIV><FONT face=3DVerdana size=3D2><SPAN=20 class=3D196321812-28022008>Eduardo.</DIV></SPAN></FONT> <DIV> </DIV> <DIV align=3Dleft> <HR align=3Dleft width=3D900 color=3D#c0c0c0> </DIV> <TABLE=20 style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; WORD-SPACING: 0px; LINE-HEIGH= T: 100%; TEXT-ALIGN: left"=20 cellSpacing=3D0 cellPadding=3D0 width=3D1144 border=3D0> <TBODY> <TR> <TD style=3D"VERTICAL-ALIGN: top" width=3D190 cellpadding=3D"0"=20 cellspacing=3D"0"><IMG src=3D"cid:196321812@28022008-1AAC" border=3D0= ></TD> <TD style=3D"VERTICAL-ALIGN: top" width=3D52 cellpadding=3D"0"=20 cellspacing=3D"0"> </TD> <TD vAlign=3Dtop width=3D397 cellpadding=3D"0" cellspacing=3D"0"><BR> <P=20 style=3D"MARGIN: 0px; WORD-SPACING: 0px; TEXT-INDENT: 0px; LINE-HEIGH= T: 100%"=20 align=3Dleft><FONT face=3DVerdana size=3D2><B>Eduardo Izaguirre=20 Pazos</B></FONT></P> <P=20 style=3D"MARGIN: 0px; WORD-SPACING: 0px; TEXT-INDENT: 0px; LINE-HEIGH= T: 100%"=20 align=3Dleft><FONT face=3DVerdana size=3D1>Administrador de=20 Sistemas / </FONT></P> <P=20 style=3D"MARGIN: 0px; WORD-SPACING: 0px; TEXT-INDENT: 0px; LINE-HEIGH= T: 100%"=20 align=3Dleft><FONT face=3DVerdana size=3D1>Systems Administrator</FON= T></P></TD> <TD vAlign=3Dtop noWrap align=3Dleft width=3D41 cellpadding=3D"0"=20 cellspacing=3D"0"> </TD> <TD vAlign=3Dtop noWrap align=3Dleft width=3D454 cellpadding=3D"0"=20 cellspacing=3D"0"><BR> <P class=3DMsoNormal=20 style=3D"MARGIN: 0pt; WORD-SPACING: 0pt; LINE-HEIGHT: 100%"><FONT=20 face=3DVerdana size=3D1><SPAN style=3D"COLOR: rgb(24,21,18)">GRUPO=20 TECNOL=D3GICO<BR>E INDUSTRIAL GMV,S.A.<BR>Isaac Newton, 11<BR>P.T.M. = Tres=20 Cantos<BR>E-28760 Madrid<BR>Tel. +34 91 807 21 00<BR>Fax +34 91 807 2= 1=20 99<BR>www.gmv.com</SPAN></FONT></P></TD></TR></TBODY></TABLE> <DIV> </DIV><p><font size=3D1 color=3Dgray face=3DAri al><span style=3D'font-size: 8.0pt;font-family:Arial;color:gray'><hr size=3D2 width=3D'100%' align=3Dcen= ter> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informaci=F3n clasificada por su emisor como confidencial en el marco de su Sistema de Gesti=F3n de Seguridad de la Informaci=F3n siendo para uso exclu= sivo del destinatario, quedando prohibida su divulgaci=F3n copia o distribuci=F3= n a terceros sin la autorizaci=F3n expresa del remitente. Si Vd. ha recibido es= te mensaje err=F3neamente, se ruega lo notifique al remitente y proceda a su b= orrado. </span></font><font size=3D1 color=3Dgray face=3DArial><span lang=3DEN-GB style=3D'font-size:8.0pt;font-family:Arial;color:gray'>Gracias por su colaboraci=F3n.<o:p></o:p></span></font> <font size=3D1 color=3Dgray face=3DArial><span style=3D'font-size: 8.0pt;font-family:Arial;color:gray'><hr size=3D2 width=3D'100%' align=3Dcen= ter> This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you ha= ve received this transmission in error, please notify the sender immediately a= nd delete it. </span></font> <hr size=3D2 width=3D'100%' align=3Dcenter></p> </BODY></HTML> ------_=_NextPart_002_01C87A04.71821EC6-- ------_=_NextPart_001_01C87A04.71821EC6 Content-Type: image/jpg; name="logo-firma-digital-2.jpg" Content-Transfer-Encoding: base64 Content-ID: <196321812@28022008-1AAC> Content-Description: logo-firma-digital-2.jpg Content-Location: logo-firma-digital-2.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAgEAZABkAAD/4QwKRXhpZgAATU0AKgAAAAgABwESAAMA AAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAEx AAIAAAAVAAAAcgEyAAIAAAAUAAAAh4dpAAQAAAABAAAAnAAAAMgAAABkAAAA AQAAAGQAAAABQWRvYmUgUGhvdG9zaG9wIDcuMCAAMjAwNjowOTowMSAwOToy OToxNwAAAAOgAQADAAAAAQABAACgAgAEAAAAAQAAALegAwAEAAAAAQAAAGoA AAAAAAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABFgEbAAUAAAABAAABHgEo AAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAK3AAAAAAAAABIAAAA AQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAf/u AA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4N EA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDP/AABEIAEoAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAAB BQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEA AgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEy BhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV 4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/ 2gAMAwEAAhEDEQA/APVUkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSU/wD/0PVUkkklLOc1jS95DWtBLnEwABySVwfXP8ZD22uo6LWxzGyDlXAk O/4moFnt/wCEs/7aVz/GP1izFwKumUOLX5pJuIOvpMiWf9ee7/MrsYsn6hfV fF6iLOqdQYLaKn+nRQ7Vrnthz7LW/Rexu7Yxn/GKKcpGXBH6uxyPKcvj5Y87 zceON1ix/vfo/wDSaWP/AIxPrHVaH2WVZDO9b6w0R5Oq2OXSdV/xhYuP07Ft wavVzMuv1PSeTsqEuY71nN2+o71WPY2tn/Gfo/0fqW/rv03pv/NvJudRWx+M Gmh7Whpa4vYwNaW/mv3bFwH1X6O3rHWqcO2fQE25Ec7Gfm/9cfsrTCZxPDxX dNzFi+H83hPNHB7MOXMvchH5cgjHi/Q4W47/ABgfWd1u8ZNbRP8ANNqZt/6Q dZ/4Iuh6X/jJxzg2u6pVty6hNbaQdt0mNrd+70XN/P3v/wDSa3+r9I6O3oeV S7Fqroqose3axo2FrXO9RkD2vb+8vK+h9NPVeq4vT5LRe/8ASOGhDGg2XFvP u9NjtiR44EDiu04I/D+dw5JnlxgjgNmUKjLgj6/mh/V+Z2c3/GJ9YL7S7GfX h1g+2tjGvMdt77g/c7+oyta/1f8A8Yr7L24vW2sY1/tZl1jaAf8Auwwn2t/4 Vn0P9H/hF1n7C6KzAOCcOluJt2uZtHAH0zZ9P1P+G3+r/hF4rpHl5pSM4EEy u08pj5Dn8eWEeWGH26AmP5z18XDLj/e9H6fG+9JLi/8AF59YTk456NlPm7Gb uxXE6uqGnpf+g/5n/A/8Sup6r1PF6VgW52UYrqGjRy5x+hWz+W9ymjMGPF9r hcxymXDzB5cjinYEK/ynF8hj/ecn62fWuvoNTKqWNuzrwXV1uPta0aeraG+/ bu9rG/4T3rP+qf1j+s3Wn5D7KKHYtLXD1Q1zSbYmumvdZss/4T/z4uNop6l9 a+vGT+nynb7XgS2qoaT/AMXSzbXX+/8A216103p+L0zCqwsRu2mlsCeSfznv /lvd7nqOBlOV3UQ6POYeW5Llo4TCOXm8g4pzOvtjw/6EGPS3578RruoNDb5M wI0/qy5W0klM48pcUiaEbN1H5Q//0fVUkkklPnP+M7Fub1LEzCD6FlPoh3YP Y59hB/rMtRfqX9cOldN6Z+z+oudQanudXaGue1zXHftPpB7/AFN2781dnl09 K6sy/puSK8n0i316CfcwuG+t/t/SV7mO9ljVzx/xZdDL5+0ZQZ+5uZ/1XoqE wkJ8UKNu1i53lcnJx5XmxOHt0YygPmHzQkP8GTzv1x+uDOttZhYLXMwq3b3v fo6xw0Z7B9Gpv0vf/wCi1pf4sMGbM7qLhwG49bvj+luH/nhYH1qt6VXlM6b0 dobhYIIdYDuNlzv56x1p91u3Yytv/XPS/Rr0L6mdNPTvq9jMeNtt4ORb8bPc yf5TKfSYmwuWSzrTa56WPB8LjjxQOIZiBGM/5zhv3DOf9aUY+pH9e837J9Ws kB21+SW0M895/SD/ALYbauU/xaYXq9YyMsiW4tO0HwfaYb/4HXcuh/xg9L6l 1HpuOMGt14ot320s1cRtLWva38/ZP5v76X+L3pWT0/pd9mXS+jIyLj7LAWu2 MAbXLXe76ZtTiCco00DVw5ceL4RlEZD3M0+Exv1Di4Y7f7OLqfWvM+x/V3Pu /ONRqb47rf0DT/Z9Rcj/AItek4+Q/Mz8iptorAoqDwHNlwLr/a4fS9P02f1L LF0f156Z1DqfQ/RwG+pZXa219QMF7Gh4c1k/Sducyzb/ACEP6gdPycDoTmZV T6Lbb32Guxpa4CGVj2u/4tEgnKLGgFsWHLHF8Ky8MwMuXKIyAPrjD+XE8d9Y unX/AFW+sVeT0+a6XH18N2sD827Gd9Hcxu7Zs/7j2sQPrF9Zc/6yZNNbajXS 0htGIwl5dY727zDW+ra6dlXs/wDRi9B+t/Qf230l1VTQcyg+rinQS4fTp3O/ NuZ/4J6axPqJ9U7cV37X6nU6vIEtxaHiCwfRfdYw+71HfQr/AJH9dMOOXEYj 5Za+DewfEOXPLR5nMBPmuXBxRv8AnJmXyH/C/f8A9q7f1S+rjOhdP2vh2bkQ /Jf4H8yln/B1T/nrcSSU4AAAHRwM2WebJLJkPFOZslSSSSLG/wD/0vVUkkkl Pmn1w6N13C67f1fFFzqryHsyccu3V+1tbq7fS99W3b9L+b2LH/a31p6mw4jM jLymuBa6qvcZBEObZ6Q9zf669jSURw6kiRF606+L41w44Qny+PLPHEQhkOmk Pl/Rk+f/AFX/AMX93rMzeuMDa6yHV4UhxcR3yYlnp/8AA/4T/C/6Ozq+sdZv 6dZUynCszN43vFZO4Ma5nrbG7H+payl1l1dO79P6Xos99i1Uk+MBEUGjzfOZ uayceU7aRjH5ID+q8ufrlkbXT091EsbZVfc5zaNjvsjHX3W+juprxrMyz7Tv Z6jK6q7/AOYttsxpWfXDJqoF1nSr9W1PNbN73llwFm6praPd6ePT1G6yt/pf 0bHqs9OzN/Q9MknNZ56z6zZ1DN9vTjcBda0+g9zj6NLntsyGtfSz1H+lU/Ir x2O/Ss/R02WWqWL9ZrMh2a0YzRbi47shlJe5v0RO3KyLamY+K3J3b8R+/wB+ L+sf6WqrfSSU8sPro8AWPxR6Po13OJNjHhjmV225rqbKPZ05nqWUNv3eq/Ip /mdn6Su036y5N+Q6jFxA51WSzHuL3vADbLMiuq1myizdvxaKM79z0Myn9L/h LN9JJTzNX1vyrbdtfTnPltR9FryLmeo7GbuvY+plVbLmZdjsH9L+s/ZbP5j9 N9kvdE687qt9tbqPQDKaL69XOJbe0v8A0vsY2iz/ALr2fp/8N/N2MWwkkpSS SSSn/9P1VJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP8A/9n/ 7RD8UGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAA OEJJTQPtAAAAAAAQAGQAAAABAAIAZAAAAAEAAjhCSU0EJgAAAAAADgAAAAAA AAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0EGQAAAAAABAAAAB44QklN A/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoA AQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgAB AKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAA AAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA /////////////////////////////wPoAAAAAP////////////////////// //////8D6AAAAAD/////////////////////////////A+gAADhCSU0EAAAA AAAAAgABOEJJTQQCAAAAAAAEAAAAADhCSU0ECAAAAAAAPQAAAAEAAAJAAAAC QAAAAAkAAANQAQAACfABAAAGoAEAAANLAAAAE5UAAAAAAAAAAAAAAQAADUAB AAAW4AAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADYQAAAAYAAAAAAAAA AAAAAGoAAAC3AAAAFgBsAG8AZwBvAC0AZgBpAHIAbQBhAC0AZABpAGcAaQB0 AGEAbAAtADEANQAwAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AAC3AAAAagAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAA AAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3Qx AAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21s b25nAAAAagAAAABSZ2h0bG9uZwAAALcAAAAGc2xpY2VzVmxMcwAAAAFPYmpj AAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3Jv dXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAA DWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJ bWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxv bmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAGoAAAAAUmdo dGxvbmcAAAC3AAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAA AAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxs VGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZl cnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUA AAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAA DGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAA OEJJTQQUAAAAAAAEAAAAAzhCSU0EDAAAAAAK+AAAAAEAAACAAAAASgAAAYAA AG8AAAAK3AAYAAH/2P/gABBKRklGAAECAQBIAEgAAP/tAAxBZG9iZV9DTQAB /+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMT FRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwM/8AAEQgASgCAAwEiAAIRAQMRAf/dAAQACP/EAT8A AAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX 0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3 h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEU obFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi 8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3 x//aAAwDAQACEQMRAD8A9VSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJT/AP/Q9VSSSSUs5zWNL3kNa0EucTAAHJJXB9c/xkPba6jotbHMbIOV cCQ7/iagWe3/AISz/tpXP8Y/WLMXAq6ZQ4tfmkm4g6+kyJZ/157v8yuxiyfq F9V8XqIs6p1Bgtoqf6dFDtWue2HPstb9F7G7tjGf8YopykZcEfq7HI8py+Pl jzvNx443WLH+9+j/ANJpY/8AjE+sdVofZZVkM71vrDRHk6rY5dJ1X/GFi4/T sW3Bq9XMy6/U9J5OyoS5jvWc3b6jvVY9ja2f8Z+j/R+pb+u/Tem/828m51Fb H4waaHtaGlri9jA1pb+a/dsXAfVfo7esdapw7Z9ATbkRzsZ+b/1x+ytMJnE8 PFd03MWL4fzeE80cHsw5cy9yEflyCMeL9Dhbjv8AGB9Z3W7xk1tE/wA02pm3 /pB1n/gi6Hpf+MnHODa7qlW3LqE1tpB23SY2t37vRc38/e//ANJrf6v0jo7e h5VLsWquiqix7drGjYWtc71GQPa9v7y8r6H009V6ri9PktF7/wBI4aEMaDZc W8+702O2JHjgQOK7Tgj8P53DkmeXGCOA2ZQqMuCPr+aH9X5nZzf8Yn1gvtLs Z9eHWD7a2Ma8x23vuD9zv6jK1r/V/wDxivsvbi9baxjX+1mXWNoB/wC7DCfa 3/hWfQ/0f+EXWfsLorMA4Jw6W4m3a5m0cAfTNn0/U/4bf6v+EXiukeXmlIzg QTK7TymPkOfx5YR5YYfboCY/nPXxcMuP970fp8b70kuL/wAXn1hOTjno2U+b sZu7FcTq6oael/6D/mf8D/xK6nqvU8XpWBbnZRiuoaNHLnH6FbP5b3KaMwY8 X2uFzHKZcPMHlyOKdgQr/KcXyGP95yfrZ9a6+g1MqpY27OvBdXW4+1rRp6to b79u72sb/hPes/6p/WP6zdafkPsoodi0tcPVDXNJtia6a91myz/hP/Pi42in qX1r68ZP6fKdvteBLaqhpP8AxdLNtdf7/wDbXrXTen4vTMKrCxG7aaWwJ5J/ Oe/+W93ueo4GU5XdRDo85h5bkuWjhMI5ebyDinM6+2PD/oQY9LfnvxGu6g0N vkzAjT+rLlbSSUzjylxSJoRs3UflD//R9VSSSSU+c/4zsW5vUsTMIPoWU+iH dg9jn2EH+sy1F+pf1w6V03pn7P6i51Bqe51doa57XNcd+0+kHv8AU3bvzV2e XT0rqzL+m5IryfSLfXoJ9zC4b63+39JXuY72WNXPH/Fl0Mvn7RlBn7m5n/Ve ioTCQnxQo27WLneVycnHlebE4e3RjKA+YfNCQ/wZPO/XH64M621mFgtczCrd ve9+jrHDRnsH0am/S9//AKLWl/iwwZszuouHAbj1u+P6W4f+eFgfWq3pVeUz pvR2huFggh1gO42XO/nrHWn3W7djK2/9c9L9GvQvqZ009O+r2Mx4223g5Fvx s9zJ/lMp9JibC5ZLOtNrnpY8HwuOPFA4hmIEYz/nOG/cM5/1pRj6kf17zfsn 1ayQHbX5JbQzz3n9IP8Athtq5T/Fpher1jIyyJbi07QfB9phv/gddy6H/GD0 vqXUem44wa3Xii3fbSzVxG0ta9rfz9k/m/vpf4velZPT+l32ZdL6MjIuPssB a7YwBtctd7vpm1OIJyjTQNXDlx4vhGURkPczT4TG/UOLhjt/s4up9a8z7H9X c+7841Gpvjut/QNP9n1FyP8Ai16Tj5D8zPyKm2isCioPAc2XAuv9rh9L0/TZ /UssXR/XnpnUOp9D9HAb6lldrbX1AwXsaHhzWT9J25zLNv8AIQ/qB0/JwOhO ZlVPottvfYa7GlrgIZWPa7/i0SCcosaAWxYcscXwrLwzAy5cojIA+uMP5cTx 31i6df8AVb6xV5PT5rpcfXw3awPzbsZ30dzG7tmz/uPaxA+sX1lz/rJk01tq NdLSG0YjCXl1jvbvMNb6trp2Vez/ANGL0H639B/bfSXVVNBzKD6uKdBLh9On c7825n/gnprE+on1TtxXftfqdTq8gS3FoeILB9F91jD7vUd9Cv8Akf10w45c RiPllr4N7B8Q5c8tHmcwE+a5cHFG/wCcmZfIf8L9/wD2rt/VL6uM6F0/a+HZ uRD8l/gfzKWf8HVP+etxJJTgAAAdHAzZZ5sksmQ8U5myVJJJIsb/AP/S9VSS SSU+afXDo3XcLrt/V8UXOqvIezJxy7dX7W1urt9L31bdv0v5vYsf9rfWnqbD iMyMvKa4Frqq9xkEQ5tnpD3N/rr2NJRHDqSJEXrTr4vjXDjhCfL48s8cRCGQ 6aQ+X9GT5/8AVf8Axf3eszN64wNrrIdXhSHFxHfJiWen/wAD/hP8L/o7Or6x 1m/p1lTKcKzM3je8Vk7gxrmetsbsf6lrKXWXV07v0/peiz32LVST4wERQaPN 85m5rJx5TtpGMfkgP6ry5+uWRtdPT3USxtlV9znNo2O+yMdfdb6O6mvGszLP tO9nqMrqrv8A5i22zGlZ9cMmqgXWdKv1bU81s3veWXAWbqmto93p49PUbrK3 +l/Rseqz07M39D0ySc1nnrPrNnUM329ONwF1rT6D3OPo0ue2zIa19LPUf6VT 8ivHY79Kz9HTZZapYv1msyHZrRjNFuLjuyGUl7m/RE7crItqZj4rcndvxH7/ AH4v6x/paqt9JJTyw+ujwBY/FHo+jXc4k2MeGOZXbbmupso9nTmepZQ2/d6r 8in+Z2fpK7TfrLk35DqMXEDnVZLMe4ve8ANssyK6rWbKLN2/Foozv3PQzKf0 v+Es30klPM1fW/Ktt219Oc+W1H0WvIuZ6jsZu69j6mVVsuZl2Owf0v6z9ls/ mP032S90Trzuq321uo9AMpovr1c4lt7S/wDS+xjaLP8AuvZ+n/w383YxbCSS lJJJJKf/0/VUkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU/wD/ 2ThCSU0EIQAAAAAAVQAAAAEBAAAADwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAAABMAQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAIAA3 AC4AMAAAAAEAOEJJTQQGAAAAAAAHAAgAAAABAQD/4RJIaHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJz IGVzYz0iQ1IiPz4KPHg6eGFwbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRh LycgeDp4YXB0az0nWE1QIHRvb2xraXQgMi44LjItMzMsIGZyYW1ld29yayAx LjUnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMu YWRvYmUuY29tL2lYLzEuMC8nPgoKIDxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9 J3V1aWQ6ODVjNGZkOWMtMzk4Yi0xMWRiLTg3MTktOTg2OTZjMDU3NjIyJwog IHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0v Jz4KICA8eGFwTU06RG9jdW1lbnRJRD5hZG9iZTpkb2NpZDpwaG90b3Nob3A6 MjZmMTBlMzctMzk4Yi0xMWRiLTg3MTktOTg2OTZjMDU3NjIyPC94YXBNTTpE b2N1bWVudElEPgogPC9yZGY6RGVzY3JpcHRpb24+Cgo8L3JkZjpSREY+Cjwv eDp4YXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pv/iDFhJQ0NfUFJPRklM RQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BN U0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIE AAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1 bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAI DGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJz UkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4x AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAA WFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAA AAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVj LmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAA AAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0g c1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAA AAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYt Mi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGlu IElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmlldwAA AAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAA AABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcA OwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACp AK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHB AckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQC jgKYAqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+ A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoE qAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2 BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QH hgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6 CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyIL OQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1a DXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJk EoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQV VhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhl GIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib 2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9p H5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6 J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9Es BSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1 wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrv Oy07azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRA pkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZn RqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJM uk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MT U19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbha B1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8 YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9o lmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4 bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4Co gQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJ mYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6 kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+c HJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uw ALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7 urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5 0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724Dc BdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep 6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0 NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////u AA5BZG9iZQBkQAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEB AQEBAQICAQICAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDA//AABEIAGoAtwMBEQACEQEDEQH/3QAEABf/xAGiAAAA BgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAAAAAAAAYF BAMHAggBCQAKCxAAAgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEy IxUJUUIWYSQzF1JxgRhikSVDobHwJjRyChnB0TUn4VM2gvGSokRUc0VGN0dj KFVWVxqywtLi8mSDdJOEZaOzw9PjKThm83UqOTpISUpYWVpnaGlqdnd4eXqF hoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbHyMnK1NXW19jZ2uTl5ufo 6er09fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEHMmEU cQhCgSORFVKhYhYzCbEkwdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OT RnTC0uLyVWV1VjeEhaOzw9Pj8ykalKS0xNTk9JWltcXV5fUoR1dmOHaGlqa2 xtbm9md3h5ent8fX5/dIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6 ipqqusra6vr/2gAMAwEAAhEDEQA/AN/j37r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/Q3+Pfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691/9Hf 49+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3X/0t/j37r3Xvfuvde9+691737r3RF/nJ/MM+O3wE2PS7m7kztT Xbq3DBWHYnV22Fp67fG856RSJJqWimmhp8RgaecqlRkqx4qWJm0KZJisTE28 b7YbJCJLt6yN8KD4m/zD1Jx+eOsifu8/dh90fvKcwzbTyJtyx7Nasv1m4XGp LS1DcAzAFpJmFSkEQaRgNRCoC41Qu7f+FI3zU3tnKxumdr9X9I7VEkq42kfB DsbdQgLN4nymd3OI8HU1IQgnwYinQEWseSY1vOft3mc/SRxwx+WNR/MnH/GR 12d9v/7qj2C5f2+Ac+bxu/MG80HiMJvobevmI4besyrX+O5c/MeQbbB/4UQ/ zGNq5mjrt17i6v7OxMVQj1uC3L1pgsHHWUwZTJTx5HYq7WraSRkBCyXk0k3K t9PaeDnrfo3DSyRyL6FAP5rToV8y/wB1991rebCe32ba942i9ZSEmgv5pire TFLv6hGHqMV8iOtr74lfzRvj58lPiBuP5bbkydJ1Bg+rhVY/u3BbiyS1x2Du Ghp6SoSlo62CnhqNxUG446+A4doaZamulnWmWH7lWiEl7ZzHY7htcm5yMIkj xICa6T/lBqNOKnhSuOuMPvX9z/3N9p/fHavZTarR983HeNL7TNAmj6yF2YFm QsVgeAo/1QZykKoZTJ4JDnXz+V3/AApV7jz+48lgviD13trr/ZNFVzU9Dvvs zGDde+NwU8TsseRh21HWQ7Z2vDUABlp5v4rKF5Z0YlFA+5+4F08jJtcCpCDh nGpj86cB9nd1019mP7p/kXbdqtNx98OaLvc+YJEDPZ2En09pCxGUM5U3FwV4 F0+nWvBWA1Eh2O/n6/zQaLIitqe89tZimDlzh8j011FFjmUm4iMuJ2Zi8toU cC1UGt9SfZKvOvMQbUbxSPQxpT+Sg/z6yOuv7tj7oVxam3h9u7uCWlPFTdNy L/bSS6kjr/zbp8ur6P5Y/wDPrwnyc3tgOgvlNt7bfWfa+5po8bsbsDbUtVR9 e74zTqfDtzKY3K1NZU7O3HkWXTRsauooq6ZhCDTzNDHMNOXudE3GZLLco1ju WwrD4WPoQfhJ8skHhg0rzf8Avcf3b24e0fL+5e5Ps7ul3u/Jlope7spwrXtp EOM8ckaqt1AnGUeGksKDxD4iB2jZ/wCYP/woW2J0duXcHUHxE21ge4994Gpq sTuDtPcVVVP1ZgMvTNLT1dBtygxU1Jkd/wBVQ1C6ZKpKujxqyL+1JVqTprvn PMNnJJa7XGssy4Ln4AfkBlqetQPt6Xfdk/uxOY/cPads5497t2udi5cuUWSH b4FUbhNE1GV53kDJZq65EZjlnIPesJpWjer/AJ/f8z2pzX8Uh7p2nj6HyiT+ 7dJ051Y+F0A3MHnr9q1u4vERxf7/AF2/tewceduYi+oXahfTw0p/MV/n10Ng /u1PuiRWH0cnIN7LcaaeO257gJa+tEuEgr/zZp8urZ/gr/wo+pt0biw/XPzh 2lgNoxZWopsfQ95dfUuQptv0FTPKIY339suebKVGPx7M4MuSxs7xwAXejWPV Kgm2bn0SSJBvESoDjxFrQf6Zc0HzB/Lz6ws+8V/dWy7Rtd9zT93re7m9eFWd 9pvWRpnUCpFndARq747YJ0DP+GctRG2r8XlMZnMZjs1hcjQ5fD5ehpMpicrj KuCvxuTxtfBHVUOQx9dSyS01ZRVlLKskUsbMkiMGUkEH3JKsrqrowKEVBGQQ fMHrjVeWd3t13dbff2skF9BI0ckcilJI5EJV0dGAZXVgVZWAKkEEAjqf7t0m 697917pj3NuXb+zNuZ7d+68xQbf2xtfD5LcG4c7laiOkxmHwuIpJq/J5Ovqp SI4KSio4Hkkc8Kqk+6SSJFG8srhY1BJJ4ADJJ6MNp2nc9+3Tbdk2axlut3vJ 0hghjUtJLLKwSONFGSzsQqgcSetPv5Xf8KWOz6jfWUwPw9622ViuvMRXTUlB vztfF5jO7k3lDA7xjLUu2KHL4Gj2rjKsjVDBUPWVZj0tIYXZoUi3c/cC4MzJ tVuggBwzgkt86AjSPkan1pw67kezH907yhFy7Z7j75c1383M88YZ7PbpIoYL UkA+G1w8czXEi8GdBFHqqE1qBI1j/wDLB/mafM35j9Qd3dg9mdB7Jg2z1jhJ Ytu9u7Rj3JjMXuLfAkpZarbg6+mqM7ktyR7dwlU2SyE2MrYWijiiphE09UjI fcu8w7tutreT3FknhxjDrUAt6ack0GTQ+gpU9Yq/e8+6V7DexPPHt9yzyl7k 7g277vcAz7bcmCSSC0owWf60LDHAZ5VEEK3ETBmZ5S4jhYNZB8Ie8+1u7dsb yq+0oMFLVYLJY1MZltv0QpqSRMlJmjJiKqpoqmuwNbXUeNx9DkP8knkenp8t DDUhKlJI1P8AZ7y5vI5TcgVUihHzrjFRWgBxwDAHPWK33g/bzkz2/wB32KDk +S5WG5ikMkcz6mHhiKkqq6pMiM7yw/qoA72zyQlomRieH2cdY9de9+691//T 3+Pfuvde9+691737r3RfflR8i9lfE34/9n/IHf7GTAdc7bqMpFi4po4Kzcee qJI8ftna2OkkDKtfuPP1dPRxsQVi8pkf0IxCHcr+HbLG4vp/gjWtPU8AB8ya DqTfZz2t3/3p9zOUfbPloU3LdbtYzIQSsEKgvPcOB+CCFXlYVBbTpHcw6+Zv 8lvkb2h8r+6N695du52fNbu3lkpahYTLIcZtvCRSSDCbS27SuxXH7e29RMIK aFeSAZJC80kkj4+7hf3O53c15dPWVz+QHko9APL/AD9fWj7T+1nKHsxyFsHt 5yRty2+yWEQWtB4k8pA8W5nYfHPM9XkY+oVQqKqi9D+Xn/wn03x8jdg4Dur5 Qb0z3S2xN20FNmNl7A25jKKbsvcOCrY4qjH7hzdVmkqMZszG5OlcSUtPJSVl dPC4kdKYFNYx2Lkea/gS73GZoYWFVUDvI8ia4UHyFCT8uud33nv7zTl72s5l 3LkH2h2C23/mOykaK6vJ5GFhBMhKvDEsREl1JGw0yOskUSMCqtKdWkVf5j38 gDrj46/HLfPyC+NnZXYWcqOqsWu5d57E7HfA5dsvtGllijz2V29m8DhdvPQ5 HA00prZKeognjnpYZArpIqiRTv3JNvYWE19t9w7GIVZWoar5kEAUI40pkdAz 7q395bzV7o+6fL3tn7r8qbZbx7zN4FreWImi8K5YEwxzRTSz60mYCIOjoySM hKspJXWhxnaG+sP1tuvqLGbirqLr3fG6Np7x3VtyCQpR5rPbIotx0O2ausAs ZExsO6qxljPoaRkdgWijKx+tzMlvLarIRA7KxHqVqB+yp66zXfKHLl9zXsvO 93tccnM+3Wdza285FWihu2gedV9DIbeIFuIUMoIDsDbB/Kw/k/74/mDnMdk7 x3RX9VfHrbGVkwNRuqhxsOQ3RvnccEMc9bgdk01cy46ngxEU8RrsnUrNDDJK kMUM8nl8Al5b5Wm3zVcSyGOxU0qBUsfRfLHmT9gBzTC/74v34+XvuyfQ8qbF s8e8+515CJlt3kKW9pASQk12yd7GQhvCgQqzqrO8ka6PEs5+c3/Cdvqjqb46 9idv/Gzs/szJbx6r2llN75TZ/Y0+2szjd24DbVFLlNyQYzIYTA7cqcLmYMRT TVFMHWqhmeIQsE8glQQ7zyLbWthPdbfcSGWNSxVqEMBk0IAoaZHH0+fWI/3d /wC9D5z5090eV+R/dflDaYti3m9jtI7qxE8UltNOwjgMiSzTrLEZWVJKGNlD eIC2nQ2pSrMjK6MyOjBlZSVZWU3VlYWIYEXBHuMuu1hAYFWFVPV3n8qz+TZu 35+4vKdu9i7tyfVfx+w2XnwFBl8Tjqat3f2LnaED+LUO01yN8bjcPhHdI6rJ zxVKGpJp4YZHSdoBfy3ypLvatdTymOxBoCB3MRxC1wAPM5zgDjTnz98j79uy /dqvLPkjlfZId59zJ4BM8UjsltYwv/Zvc6O+SWUAtHAjIfDpK7orRiSwb5+f 8J6erelPjh2J3d8a+zOysruPqXa+R3xuLZfY0u3s3Sbm2rt2kkyG6HwuSwGB 27VYrM47EwS1cMckdVHUCAw+hnWQHm98jW1nYT3m33EhkiUsVahqBk0IAoQM +daU6xl+7V/ed848/wDupyv7fe6/KW0w7XvV4lpBdWImiaC4nYJbiVJpp1ki eQrExDRsmsSdwUqdTv3GnXaHraX/AJAP8znIbN3Xhvgt3huOWp2Ru6rli+Pu 5MxVNI20t3VLGZusJaqoc+Pbu65db4lCbU2Vb7dAy1iCGR+SeYWilTZryT9F j+kT+Fv4Psb8Po2PPHHj+8s+6Nbb7s1/94n292oJzBYoDvUES0+ptlx+8Ao4 z2woLk0/Utx4rEGBi+5X7lbrhD1737r3Wov/AMKHP5jvlkb4F9ObgYRwtj8x 8j83iashZJQKfJ7b6nFRCfUkV4snmkU21/a0zG61UXuMOet+r/ultX9DKR+0 J/lb8h6jrtt/dg/dX0Kv3kOetsGpg8WxxSLwHdHPuND5nugtSRw8aUDML9a/ XwH+E/Ynzx+Qu2umNkpU4zAoUz3Zu+hSmox+wdh0dTDHlM1UaisM2Uq2kWlx tKWBqq2VFOmJZZIwRsu0T71fR2kNQnF28lXzP2+QHmflXrpj95L3/wCV/u4+ 2O7c+8wMku5GsNhaatL3l4ykxxDzEa0Mk8gH6cSsRVyit9Jfo/pTrn469U7J 6X6n2/T7a2FsHC0+FweNhCtNKI9UtZlMpUhEfIZvM10klXW1TjyVFVM8jct7 n2ztLewtobS2TTAgoB/lPqSck+Z6+Uv3C5/5p90ec+YOfedNza75k3K4aWZz wFcLHGtToiiQLHFGMJGqqMDoU4444lCRRpGgLEJGqooLMWYhVAALMST/AFJ9 qegczM51OxLepz1z9+6r1737r3X/1N/j37r3Xvfuvde9+691qg/8Kd+/cljd tfHX4z4qtmp6Hc1dn+4N5U8UpRa2Db5G1tlU9QqsDLSityGWmKNdDNBG36kB Eae4d6yx2G3qcMS7flhf8LfsHXZ7+6L9tbS63b3R92r2BWuLSOHbLViK6DN/ jF0y+jaEtlqM6XccGPVCv8pv48bf+Tvz66B603hQ0uU2XS5/Ib93fia0a6PM 4PrzD127mwlZFpYVFDm6/FwUlRGbCSCZ1JAN/YL5ZsU3He7K3lUGEMWYeoUF qfmQAfl10g++l7n7n7R/ds9yubNjuHh397ZLO2kTDRS3sqW3iqfwvEkjyI34 XVT19KZVVFVEVURFCoigKqqosqqosFVQLAD6e5/6+UIksSzElicnqsn+cX3F hemP5dHyUymUq4IMhvnZrdT7YpJdJlymf7GqI9u/bUkTMvlmosLUVtc4FysF JI9iFt7D3NV0lpsO4Mx7nTQPmXx/gqfy6y3+4tyLf8+/ek9qLOzgZrbbr/8A eNww4Rw2KmfUx8g8qxQj1eRR59fN3VWdlRFZ3dgqqoLMzMbKqqLksSeB7gPr 6rCQoLMaKOvqF/BDo6i+OHw8+O/TlLj48bWbT6v2y+5IEhELybzz1Eu496VV QojjZqmq3Tlqt3LANc2/FveRWzWYsNqsbQLQrGK/6Y5b+ZPXyDfeN9w7j3U9 8/dDnqa6M0F7vE4gNagWsLeBaquT2rbxxgUNOk1/Mj7Pounvgd8rt91xj00v Su8tvUSSsVSfM76x7bFwVOSvqH3GZ3JAlx9L39t7/cC12Xc5m8oWA+1hpH8y Ojb7qnKFxzz9472Y5ct61ff7WdyOIitH+rmb8ooHP5dfMajjkmkSKJHllldY 4oo1Z5JJHYKiIigs7uxAAAuT7x544HHr64mZUVndgEAqScAAcST5AdfUk+F/ S1L8d/ih8femKejSiqNh9V7RxmcijRYxJuupxcOU3hVuoSMmWv3TX1kzEjUW kJPN/eRm02gsdssbQChSJQf9NSrfzJ6+Pj375+m90Pef3N59lnMkW5bzcyRE mtLdZDHbKMnCW6RIKYoMY6Bv+ad2pR9Ofy9/lfu6qmhinruo9xbExKy6T5c3 2XHH1/i1jjZ08rxVW5BKVFzojY2IFvaXmS5Fpse5yk5MRUfa/aP8PQ6+51yb Pz195z2Y2SGNmjj3uC8kp5RWBN7JU0NAVgK19WArnr5sey9l7t7G3Zt7Ymw9 uZjd28t2ZajwW2ts4ChnyWZzeXyEqwUdBj6GmR5p55pG+gFlFySACRAMUUs8 qQwxlpWNAAKkk+Q6+rjft/2XlbZd05j5j3SCy2KyhaaeeZxHFFEgqzu7EAAD 9vAVJA6WXZvVXcfxs7Kn2R2js/d3U/Z+0qnGZYYrN01Rhs5jJSY8hhs1jKqJ 9M0DsizUtZSyvExXVG5I4duLa62+4MNzE0VwtDQ4I8wR/kI6IuUucuRfdblS PmDk/fLLeuUL1JI/EiZZYZBlJYpFIwRUrJFIoYA0Zc9fQy/lOfOik+dnxR21 vPN1tIe4evWpev8AufGxMsc0m6MbQwtQbvjpNWuLG76xYWuRgBClZ91ToT9u 1pz5Z3kbztkcrkfVR9sg+Y4N9jDP21Hl18wv30fu7T/d095922Hb4H/qNuga 92uQ5At3c67YtwMlpJWIg9xi8GVv7UddfzUv5g+3PgF8dcluWgqsfX94dgxZ HbPSe1KkJUmbPfbqK/eeWodQZ9sbJhqY6io1WSpqnp6W485Zfcyb5Hslg0ik G8eojX5+bEei8T6mg8+t/c4+7Juv3lfdG02m5hlj9vdsZJ91uVqtIdXZaxv5 XF2VKJTKRiWah8Oh+d9iMR2d8g+2KPEYunz/AGT2529vXxQRapMjuHd+9d3Z ZpJZ6ieVgZazJZOsaWaaRlRLs7sqAkQWq3F9chVDSXUr/aWZj/lPX1BX17yj 7Zclz315LbbTyTse31JwkFta20dAFA4LHGoVVUEmgVQWIB+jB/LJ+AOz/wCX 98eMVsKnTH5jtreC0W5O6d8U0as+e3WadxDgsZUvGlR/dLZ8NQ9Jjo20iQma qZElqZAJ35e2SLZLFYBQ3TZkb1b0H9FeA/M8T18tX3tvvLb595f3QvOZJWlg 5KsS8G1WjH+xt65mkUEr9TclRJMRWg0QhmSJT1Yz7PusWuve/de697917r3v 3Xuv/9Xf49+691737r3XvfuvdadH/Cn/AKp3JD2P8Zu8I6OebaGQ2RuPqqsy CRs1NjtyYbPVW7sdR1UgGmKfM4zPVTwKTeRaCUj9B9xX7iW0guNvvKfpFClf Qg6h+0E0+w9d0v7obnPan5V92vb1p1XfItwg3FUJ7nglhW2dlHmIpIYw5HAz JX4h1RB/L/8AljP8J/lh1Z8hmwtTuTCbUrcpjN37fonp48jltnboxFbt/cUO Lkqmjply9LQ15qaQSPHG9TAiu6IxYAzZNzO0bnbX2gsikhgOJUihp86Go+fX Rr7y/svH94D2Y5x9sBfpabhexxyW0zhikd1byJNAZAtW8NnTRJpBYRuxVWIA O7pP/Pd/lmQbIj3mO9clPVSUf3A2PB11vxt7pUeLyfw2THtgUxEdZ5P29Zrv tdfPm0ev3Lx5z5eEPi/WGtPh0tq+ylKfzp8+vn2j/u5vvaycwvsP+t1EsIfT 9Wb6zFoVrTxA/jGUrTup4PiUxo1dvWpX/NW/ml7u/mJ78wWMweEyGwPj/wBc 1VZUbA2RkKmGbOZrM1kZparfO9nopZsec9PQ3gpaSB5YMbTPIiSyvNNLJGXM nMcu+zIqIUsYz2qeJP8AE3lXyA4AfaT12r+5r9zzZPuu8ubjebhuEW5e5e6o q3l2ikRRRKdS2loHAfwQ/fJI4V53CsyIqRopWv5fPSbfIj5rfGvqN6VqzG7l 7U25W7igWPyhtpbVmfd+7vItmAj/ALtYGqDE8AH2W7HZ/X7vt9rSqtIK/wCl Xub+QPUxfeb9wB7X+wPuvzsswju7TZp0gNaf4zcD6a2p8/Hmjp19Pv3kR18h /Wu9/wAKTe4f7lfCrZPVNLUGPId1dvYaGrp1kKGo2x17Q1O6skWQf5yKLcbY e4/DFT7AvP8AdeDtENsD3TSj9i9x/np66g/3UnI37/8Af3mDnOaKttsGxylW pwuL11t48+RMH1X5A9alH8vTp7/T383PjF1ZLTPWY7cPbu1a7PU6Q+cPtfat X/e7dPkjKOjQjb2BqdeoadN7kDn3GOxWv1u77dbEVVpQT9g7j/IHrtb957nr /W2+777uc4pMEurXZLhIWrSlxcL9Nb0NRnx5o6UzXh19Pj6e8iOvkR61sv8A hTH3Cdq/FTp/pqjq0iru2+2mzuTp1ltLUbZ60wk1VURvCrhmgbcm5cZICwK6 4P6j2APcG68LbbW0BzLLU/Yg/wA5HXVv+6X5GG8+8vPPPk8JNvsmyeDG1MC4 v5QqkH18CC4GM0f06rg/4TR9AY/e/wAlu3O/s3jo6ym6S2BRYDass8SOlFvT syrq6RspTMwYrV0O0sBkqfixC5C9+PZD7f2SzbhdXrrUQpQf6Z/P/eQR+fWV X97J7l3PL3tNyT7a7fdGOXmDc2muACQWtbBVbw2/ovczQP8AbDTq43+fV8FK L5M/Fyv7z2XgRVd2fHDHVm56WegpteU3R1TCZKzfO1phDC9RW/wOmLZqhQ6j HJS1EUQ1Vb3FXOmzDcNua8hSt5biuOJT8Q+dPiH2EDj1gr/dvfeLuPaX3gtv bvf9y0e3/NUq27B2pHb7iaLaXAqQqeM1LWY41CSJ3NIV61BfgB8+O1/5fXc7 9pddUlJufA5/Fnb3YfXGYramhwW9sEsjVFGstXTR1EuLzeErW89BXJFK9OzS RskkM00bxdsm9XOx3f1MADIwoyHgw/yEeR8vsJHXcD7y33beTPvNchLydzRO 9nuVtN41lfRIrzWk1NLUViokilTsmhLKHAVgyyRo6oD5kfMLt/5vd3Z/u3uD JRtkK5Ri9rbVxr1A21sLaVLNNLi9qbapqiSR4qOlad5ZpnJmrKqWSeUl3NmN 13W63i8e8um7jgAcFXyA/wBWTk9CX2J9jeR/u+e322+3/I9qRaxnxLi4kC+P eXLACS4nZQAWagVFHbFGqRoNK52sf5BX8sc9ObOofmn3ft7xdp9iYQ/6F9t5 ekKVnX3X2XgkSbeFRT1CB6XdG/8AHyj7YgCSlwr2vqrZY45K5K5e+kiXd7xP 8ZkX9MH8Kn8X2sOHov2nrjT/AHk/3uP69b7c+wft9uerk7a7j/dpPG3be3sR BFsrKaNb2bjv8pLocKW6M2zP7kHrkr1737r3Xvfuvde9+691737r3X//1t/j 37r3Xvfuvde9+690X/5PfGbqf5ddMbs6L7lwj5jZ26oYpEqKORKXN7bztEXk w26dtZB4phjs9haltcMhR43UvDMkkEssbodx2+23S0ls7tKxN+0HyIPkR/sH HUl+0Xu1zp7I8+7L7ich7gIN9s2IKsC0U8L4lt50BGuGVcMtQwIV0ZJER10z PkH/AMJyfmt15uXJnoyv2J33sZp6iXCVkW48ZsHesVCJT4IM9t7dtVRYRK5Y SAWocnVpIVJtHcJ7ii+5D3eCRvo2SeHyyFb8w2K/YT13j9sv7032B5n2m0/1 xLbceW+YtKiVTBJeWpemTDNbK8pStcS28ZUECrZbpH9Sf8J2/wCYPv3L0MG/ sZ1r0rt+V1bIZnde+sXufIU9Nr0yGhwGwn3HJWVun1JFPUUcbf2pU9tWvIu+ TsBOscKeZZgT+QWv8yPt6POdv70P7snLdjcSctXm7b/uYHZFb2klujNTGua8 EAVPIsiSsPJG6KV/M++PfSHxB7p2r8V+nstPvTN9SbEx83dPZeSWKHK7v7W3 pK24auiFBS1NVRYPBbZ2nJioKPHxtI9M8s5mlmnkkclnMVjZ7Xdx7batreJB 4jniztnh5ALpoPLNST1Nf3RPc73B98OQd594+ebJbDb973FxtVglTHbbdajw VbWyq801xci4eWZgokCxiNEjVVFmn/CZ7oWTd3yT7g+QWRoWkxPTvXkG0sFW SIRGm8ezauaJ3pXIs89HtPb1fHLY3RK5Lj1j2IPb6y8XcLq+YdsSaR/pn/6F B/b1iV/ez+5C7J7U8j+2VrcgXu+7obmZQcm1sFBAYeQa5mhZfUxNT4et2T3L vXz/APWlB/wpz3xmMn8nugOvJlmjwG0OlK7dGODX8M+W3vvPK0GYqI+ACRSb LoozybFPxf3EfuHM7bjZQH4FhqPtZiD/AMdHXf3+6N5esbT2i9y+aIyp3K+5 gS3f1EdpaxvEp/211K359B9/wmx6dO9vmnvfterphLjulOosvNSVDR61p909 hV1PtfFqrFGEcku3I8zY3DWUgXF7McgWvjbtNckdsMR/axoP5auhN/et89f1 f9g+XuS4ZaXW/wC9xhlrTVb2SNcSeeQJza+RGR8ut6D3MfXzudaPH/CmLf2a zXzI6l68qYZYMBsTobGZrElzJ46vJb33huj+NVkSsBHbw7Zo4CVJu0BB+nuH /cGZ33W1gI7EhBH2sxr/AIB+zr6FP7pfluwsPYnnXmeKQNuW48ySRSUpVUtL a38JT58biV6HyfHHq07/AITObETCfDTtrfroVq999/5bHqxjCl8Xs3ZW0Kej ZZLBpUGRzdaPqQrA25v7Eft9Do2m6m83nI/JVX/KT1h3/e0cxtuHvxyVy2rV g27lqN+PCS6urlmx5HRFF8yKfLrYzqKenrKeekq4IamlqoZaeppqiNJoKinn RopoJopA0csMsbFWVgQwJB49jwgEEEYPXLOKWWCWOaGRkmRgysCQVYGoIIyC DkEZB6+bN/NX+Fld8IPl9vzr7HUE8PVu855+xum68pIaV9jbir6p126tSyKk tdsnKJPi5luZGjp4Z2AWdLwFzLtJ2fdJoFX/ABZ++M/0SeH+1NR+QPn19Wv3 Nffy3+8J7H8uczXVyrc4WCix3RKjULuBFHj6a1CXcZS4U/CGd4wSY2obz+SH /LMk+Yvbo7x7cwMkvxt6azdJNU0WQp2FD2r2FSiKvxuyIvIBHWbdwoaKszhG pXieCkIIqnaI05Q5e/et19ZdJ/uviPnwduIX7Bxb8h54hD+8G+9qvsXyR/re 8k7kF91t+t2Cujd+3WTVSS7NMrPL3RWnAhhJOD+ioffgjjjhjSKJEiiiRY4o o1VI440UKiIigKiIoAAAsB7mrhgcOvm3Zmdmd2JcmpJySTxJPmT1z9+6r173 7r3Xvfuvde9+691737r3X//X3+Pfuvde9+691737r3WtjvX+f5tjoL53fIf4 +d3bGqMt0Rsbf67I2p2FsSm8+8NoZXbmKx2J3jDuXb9TUpDuvDtvCnrSktLJ T1tJGpURVQKrGAJudo7Leb6xvIa2SPpVl+JSAA1R+Iaq8KEfPrq5sH92pu3u T93L2w9zfb7mJYfcbcds+ruLK8altcxzyPJamCZVJt5fpjECsivFITUvDQlr TdjfzUv5eHYWEp89gflv05RU08MczUW7dyJsXN03kjWTx1mB3lDgsvTyoDZg 0NtQIBNvYkh5k2KdA6bnEB/SOk/sah6w65i+5x96DljcJNt3L2T32SZWI1W0 Bu4moaVWa1M0TA8RRuGeiE/Ob+fp8V+jNj5/BfGjdWL+Qfd1dRVFFt19v01d P1ltOunjliiz2590zQ0dFn4MfIPIlBipKl6p1CSy0yN5PZJvPOu22cLpt8gn vCMU+BT6k8DT0Fa+o49ZI/d4/u2feP3E5h23cfdnZpuWPb6ORXnEzIL+5QEE w29uCzwlx2ma4EYjBLIkrDR1o0bp3Nvft3f+d3buWuzG9ew+xt1VuZy9c8c2 Qze5t17nyb1NQ6U9PG0tTXZPJVhEcMScswRFtYe4dkkmup3lkYvPI1SeJLE/ 5T19D2z7Ry/yRy1t2ybTbwbfyvtVmkUSAhIoLe3jCqCzGipHGvczHgCzHiev ok/yg/hflfhL8Ndo7H3pQRUHbHYGTrO0O1KVRG02J3DuGloqXF7VnnjeRZZt q7bx9HSVGlmjFcKgoSrAmdeVtpbaNpihmWly51v8ieA/2oAB+devl5+/B792 f3gPffe+YdguWk5L2yFdv29s0khhZ2kuACBQXE7yyJUBvCMQahBAtF9iPrD/ AKIf83P5cnxl+feI21Sd5YDNQbj2YKyLam/tlZWPAbxw9DkGWSuw5rJ6LJY7 KYWpqI1l+2rKadIpQXi8bPIXJd32Hb97SMXiHxE+FlNGAPEeYI+RB+XWRv3f fvT+7f3a77dpvbzcrdtqv9JuLO6jM1rK6YSXSHjeOVVJXXFIhZaK+oKoDd8C /wCXD0Z/Lyw/ZGJ6ZzO/dwHtDJ7dyW4slv8AyWDyeRiXa9Jk6XFUFBLg9vbf iioomzNTIVkSRjJKfUBx71suw2exJcLaO7eIQSWIJxWgFAPU9K/vIfep9xPv P33Kt7z5YbbbDZ4Z0gjs45o0P1DRtI7iaaYlz4Ua1BUUUYrnqwH2d9Yz9EM+ bP8ALf8AjB8+cftxO89uZqHc+z4auk2tv/ZWXXb+8cTjq5/NVYd6yajyWNyu GkqrTLT1lLOsMup4vG0khcl3fYNu3tY/rIz4icGU0YD08wR8iD8usj/u/wD3 qvd77tl1ure3e6W7bRfMrXFndReNayOgosoUMjxyhe0vFIhZaK+oKoUSvht8 Ret/hD0hjOhuqsruvNbTxef3FuOLI70rcZkM/PX7lrfvaxaipxGJwlE0MBVU iAp1YIo1Fjz7UbVtdvs9mtlbMxiDE1ahNT9gH+DoKe+/vdzV94P3Bu/cfnKz srfepraCApapIkISBNC6VlklepyWq5FTgAY6NT7Muob6JT82/gL8fvn1sTb+ yO88Xm45doZmTN7Q3jtDIUuH3htuoq4o6fL0dBkazH5SklxOcpoY1q6Wenlh kaGKQBZYY3Uo3fZLHe4UhvFNUNVZTRh60NDg+YI9PMdT99377yfuZ92zmPc+ YPbu8tyl9AIrm1uUaW2nVSWjZ0V42EkLFjHIjqyhnQko7qR+6O6S62+OXVOy uluo9uwbX2BsHDw4fBYyJjNPIFZ563KZStcCbJ5vM18stVW1Ul5KipmeRuW9 rrOzt7C2htLWPTAgoB/lPqSck+Z6jX3D9wOa/dPnPf8An7nbdGvOZdynMs0h wBwCRxqMRxRIFjijXtSNVUYHQse1PQL697917r3v3Xuve/de697917r3v3Xu v//Q3+Pfuvde9+691737r3WlN/OI/k3fIeg777Q+Unxx2bmO4utu2Nx5fsPe e19qw/xPf2w945+onyu7HG2Yf9ye5dtZXLyzVsE+PjqJqXzvDPEiRJPLEnNX Kl8L253GwiMtvKxZgMsrHLY4kE5FK04EeZ78/cY+/Z7YXPtvyh7P+6m/QbFz XstrFZWtxcHw7O8tYVEdsPHP6cE8cYWJ0mZFk0K8bsztGmt9lNj71weUfB5v aG6MPmo5PC+Hym38tj8okuor4nx9XSQ1ayahbSUvf2AWhmRtDxMH9CCD+zrq pZ8w7BuNmNw2/fLOfbyKiWOaN4yPXWrFafOvRvvj7/LX+b3ybydJR9W/HjsC TFVEyRzbx3hiJ9h7IoYmJ11M+593LicfUxxKpJjpTU1D6SEjdvT7NbHl/eNx YC2sX0/xMNKj82oP2VPUH+5v3r/u+e0lpNPzh7obYLxVJFrbSC8u3Pkot7bx HUnA1SBEFas6jPW31/LJ/kgdXfC/KYXujufK4vuT5F0Mf3GEqIaOQdedXVkq Wao2fQ5CJKzObngUsq5msjhaEN/ktPA4Mryjy9yfbbSyXd2wlvxw/hT/AEoP E/0j+QHHrh997b+8I5w9+rS/5C5Cs5ti9rZDplBYfW7goPC5dCVitzgm1iZg 1P1pZFIRbTfmN2J2B1J8W+9ey+qqcVXY2yuu89n9m07YOfcwmztFCr0SHAU1 6jLAuf8AMJ6n9jPrnH1Sx2Z/MB/mGbCz3dm15tkRVGPnzv8AMz3h8fOxsH0x m8xijsD4tbR7m291/wBa77xaSSEdiYLszZ+3MzjqsNFT7629n1ipV89HVs3u t9O0Pz4+azvmtmd61H+yvUGwO3Oj+lvkJ8g8R0lWbz2p1suU6G7P7AzHb3Wf 8Zo87gMr1x33vzD7QocVlszSV9Hs4bkkoMjEa6HWnuvdKvZPzn+btFN0snZe 3qhti9x7ayvbFN3FRdEbnwtFtzob4n9j9r1fyB3xubZsxrsxtfdfyi6GxfXm V2TgqxDW0WS3jXJBHKKDxRe690ldgfMf+YR3TtvrrGbli3/8We2H+XvU+1t6 bWyfxpx9bTZL4wfKWhye8evcvC+9Is1HSbg6WqNs5vZeTy8E609ZXYd8hVUs K1lKg917pO9r/wAwz+Yb1/Lu7dOH2DHuvrfBbC3dt/NnEdNZyr3lsvsjdPzf +QvRvSfZtLjI5FXdnXmL2Z1VhsbumghjeqpYdw0m4UYUcVSr+690bT47/Mju TePzky3SHZOd3dPW5jdfytwGS6NxPU+JwG1vj/s7pjfVHj+jd9bs3xlMcu+N 0x98dammzlFnKfIVO3shVZkUdNTUr0ba/de8ugC3T87vlHht/fLbZdf2C1Bt rrz5M9b7OzHeOyul4t89UfGD45bx332Tt2TONj6nbeP3nk+88DSbWxNDuin3 DFnNuYj+Lw7mppJsGWpE917py6z/AJhnyMfK02y947gpc7L2F0V8uofifvir 6R3Ds2p+TvaHW3a2K218ct6QYCWkTH7dq+x9oVM8n8MkOOx2c8AydCkFDUwR J7r3TbQfMz5hfITrWXfPS3Z+U2LhsL2f/L26krtz4744Q5lMlvHvOfaG0Plp hXxHYmIp6mKu6Yzu70rJZIYxTYaugeirGdYamOL3Xuuu6fnD8rtn128MPuHt OXonEbVy/wAxKPqrfS/GfJ9oTfIXtDpjuKo2T070NNhKLH1UWPG5tnU0GRkh xiUed3gcl/uErKVcfVa/de64P88v5iGK7nwu1N4dXYja2yez/kbsTrzbWUXr Hc248f0vUYD4f4Ttnu/q7tfK4WV58tgJ9/7mgq9vbooFDVC4bM4liahKNpPd e6sE/lid/wDZHyN+Mq727azmX3Xv7Db+3Ns3cO8JNubewWxt25HC0OCqq7N9 NV23cFtePdPULZDKTU+Ir67HUeZjME1FkUato55ZPda6sQ9+691737r3Xvfu vdf/0d/j37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvdf/S3+Pfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691/9Pf49+691737r3Xvfuvde9+6917 37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X/1N/j37r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917 37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv df/Z ------_=_NextPart_001_01C87A04.71821EC6--

1 0

(ITS#5396) Too much open connections
by ecip＠gmv.es 28 Feb '08

28 Feb '08

Full_Name: Eduardo Izaguirre Pazos Version: 2.4.8 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.0.110.2) Hi all, using openldap 2.4.8 as a metadirectory server in front of a couple of Active Directory Servers and a local database we have found an issue with the number of ESTABLISHED connections. This is a part of the slapd configuration file: backend meta database meta ## Sufijo del arbol mostrado por el metadirectorio y usuario ## administrador del mismo(superusuario de ldap). suffix "dc=gmv,dc=es" rootdn "cn=diradmin,dc=gmv,dc=es" ## Password del superusuario, pasar a texto cifrado con slappasswd. rootpw secret ############################################## ### Opciones comunes a todo el metadirectorio. ############################################## ######################################### #### Directivas comunes de configuracion. ## TTL para tirar una conexion, aunque no este inactiva (6 minutos). conn-ttl 360 ## Version del protocolo LDAP a utilizar. protocol-version 3 ## Accion ante un referral. chase-referrals no ## TTL para tirar una conexion inactiva (5 minutos). idletimeout 300 ##################################################################### ### Definicion del LDAP remoto para las consultas de informacion de ### usuario y grupos UNIX desde maquinas que son clientes LDAP. ##################################################################### ## Definicion de los servidores target remotos a consultar. ## Se consultara el primer servidor remoto que responda. ## Defino una lista de dcs que pueden responder para el contexto de ## nombre dc=gmv,dc=es. Primer target con sus parametros de configuracion. uri "ldap://gmvdc1.gmv.es/DC=gmv,DC=es ldap://gmvdc2.gmv.es/" idle-timeout 300 ## Habilitamos el sistema de reescritura para las consultas. rewriteEngine on overlay rwm and the output of the netstat -an command shows too much ESTABLISHED connections between the metadirectory and the remote servers. After a while, the process runs out of file descriptors. Thanks an regards. Eduardo

1 0

signal 6 caught by ldap_init
by Olivier Germain 28 Feb '08

28 Feb '08

Good moring List, I am using the following openldap release openldap/2.3.36_64. I am experiencing a signal 6 in the ldap_init during coonection to my LDAP server. I would like to know if someone of you has already got this problem. If yes could it be possible to know how this has been solved new release of openldap? Thanks very much for any kind of response. Best regards -- Olivier GERMAIN Email : olivier.germain(a)kabira.fr

4 5

Re: (ITS#5395) Patch for test system
by ando＠sys-net.it 28 Feb '08

28 Feb '08

Andrew Bartlett wrote: > On Thu, 2008-02-28 at 10:02 +0100, Pierangelo Masarati wrote: >> abartlet(a)samba.org wrote: >>> Full_Name: Andrew Bartlett >>> Version: CVS HEAD >>> OS: Fedora 8 >>> URL: http://abartlet.net/patches/memberof-refint.patch >>> Submission from: (NULL) (59.167.251.137) >>> >>> >>> I've added a patch to show that refint and memberof work together. >> Your patch seems to be missing some (trivial) modification to >> tests/scripts/define.sh (the MEMBEROFREFINTOUT env var). Thanks. In the meanwhile I figured it out (easy enough ;), and it seems to work fine. I'm going to commit it, unless there's any IPR issue (which I'd delegate to Howard or Kurt). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5395) Patch for test system
by abartlet＠samba.org 28 Feb '08

28 Feb '08

--=-EClFEzQujUbhDNVbokiu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-02-28 at 10:02 +0100, Pierangelo Masarati wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 8 > > URL: http://abartlet.net/patches/memberof-refint.patch > > Submission from: (NULL) (59.167.251.137) > >=20 > >=20 > > I've added a patch to show that refint and memberof work together. >=20 > Your patch seems to be missing some (trivial) modification to > tests/scripts/define.sh (the MEMBEROFREFINTOUT env var). Index: tests/scripts/defines.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /repo/OpenLDAP/pkg/ldap/tests/scripts/defines.sh,v retrieving revision 1.162 diff -u -r1.162 defines.sh --- tests/scripts/defines.sh 11 Feb 2008 16:29:55 -0000 1.162 +++ tests/scripts/defines.sh 28 Feb 2008 09:05:29 -0000 @@ -335,6 +335,7 @@ DYNLISTOUT=3D$DATADIR/dynlist.out DDSOUT=3D$DATADIR/dds.out MEMBEROFOUT=3D$DATADIR/memberof.out +MEMBEROFREFINTOUT=3D$DATADIR/memberof-refint.out SHTOOL=3D"$SRCDIR/../build/shtool" =20 # Just in case we linked the binaries dynamically Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-EClFEzQujUbhDNVbokiu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHxnl4z4A8Wyi0NrsRAlC3AJ0VXuGhuDO25kBOPLEgTWgRmcQUoQCfUAW2 L1ELbty7Q5zRu/v9SN4umlo= =ZjP1 -----END PGP SIGNATURE----- --=-EClFEzQujUbhDNVbokiu--

1 0

Re: [JunkMail] (ITS#5393) syncrepl push based replication with back-ldap fails
by hyc＠symas.com 28 Feb '08

28 Feb '08

Please direct all followups to the ITS. Emmanuel Duru wrote: > >> -----Message d'origine----- >> De : Howard Chu [mailto:hyc@symas.com] >> emmanuel.duru(a)atosorigin.com wrote: >>> Full_Name: Emmanuel Duru >>> Version: 2.3.39 >>> OS: Windows >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (195.68.44.148) >>> I'm trying to set a directory architecture with a syncrepl push based >>> replication, as (partly) stated in the admin guide, chapter 16.1.1. >>> I have a provider slapd with bdb, an intermediate slapd with back-ldap, >> which >>> points to a consumer slapd with bdb. >>> First, I have to set an updateDN on the consumer slapd, else back-ldap >> gets a >>> "no user modification allowed" error on operational attributes >>> (structuralobjectclass, contextcsn) when it tries to update the consumer >> slapd >> >> That is expected. >> >>> (the admin guide says the opposite). >> I guess the Admin Guide has a bug then. What exact section are you >> referring to? >> > > Section 16.1.1, the configuration example says twice :" # without the need > to write the UpdateDN before starting replication" That is not what that comment means. That comment means that we *are* using an updateDN. But, the entry corresponding to the updateDN we used in our example doesn't need to be created in advance, because we already know that it's a valid user on the target server. It was unfortunately taken out of context; i.e. it was copied directly from test045 and without the other test045 config file you have no way to see what it means. Definitely we should fix the example here. >>> Then this does not work at all when modifying an entry, because back- >> ldap gets a >>> "modify/delete: hasSubordinates: no such attribute" error when it tries >> to >>> update the entry. >> That's also expected, since hasSubordinates is a dynamically generated >> operational attribute (and also read-only, as I recall). You need to >> exclude >> any dynamically generated operational attributes from the syncrepl search. >> E.g. 2.4's test045 specifically tests this scenario, and the syncrepl spec >> uses: >> syncrepl rid=1 >> provider=ldap://localhost:9011/ >> binddn="cn=Manager,dc=example,dc=com" >> bindmethod=simple >> credentials=secret >> searchbase="dc=example,dc=com" >> filter="(objectClass=*)" >> >> attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimes >> tamp,modifiersName,modifyTimestamp" >> schemachecking=off >> scope=sub >> type=refreshAndPersist >> retry="5 5 300 5" >> > > OK, my mistake. > >> In general, while this is known to work in 2.3, you're better off using >> 2.4. >> (We intentionally did not include test045 in 2.3...) > I'm using 2.3 because I want to use "stable" version. I will keep on using > it, until 2.4 becomes stable (which may occur before the end of my project). > In fact, my real need is this one: I have a backbone network with non > OpenLDAP synchronized directories, and I want to use OpenLDAP directories in > front of this network, on each computer (at least for performance reasons, > until the network fully migrates to OpenLDAP directories). On the master > computer, I will use a master OpenLDAP directory, which replicates to the > non OpenLDAP directory with this syncrepl/back-ldap mechanism (all I need to > do is update the schema of the non OpenLDAP directory, I suppose). On the > slave computers, the non OpenLDAP directory should be provider, and the > OpenLDAP directory should be consumer, but I don't know yet how I will > manage to do this (of course the non OpenLDAP directory does not implement > syncrepl). It seems that syncrepl replication with back-ldap as provider > does not work, is it supposed to? No. back-ldap doesn't know anything about syncrepl itself, it merely passes requests thru from one server to another. Whatever server ultimately answers the request must know how to act as a syncrepl provider, otherwise you get nothing. -- -- 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#5395) Patch for test system
by ando＠sys-net.it 28 Feb '08

28 Feb '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 8 > URL: http://abartlet.net/patches/memberof-refint.patch > Submission from: (NULL) (59.167.251.137) > > > I've added a patch to show that refint and memberof work together. Your patch seems to be missing some (trivial) modification to tests/scripts/define.sh (the MEMBEROFREFINTOUT env var). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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: [JunkMail] (ITS#5393) syncrepl push based replication with back-ldap fails
by hyc＠symas.com 28 Feb '08

28 Feb '08

Please direct all followups to the ITS. Emmanuel Duru wrote: > >> -----Message d'origine----- >> De : Howard Chu [mailto:hyc@symas.com] >> emmanuel.duru(a)atosorigin.com wrote: >>> Full_Name: Emmanuel Duru >>> Version: 2.3.39 >>> OS: Windows >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (195.68.44.148) >>> I'm trying to set a directory architecture with a syncrepl push based >>> replication, as (partly) stated in the admin guide, chapter 16.1.1. >>> I have a provider slapd with bdb, an intermediate slapd with back-ldap, >> which >>> points to a consumer slapd with bdb. >>> First, I have to set an updateDN on the consumer slapd, else back-ldap >> gets a >>> "no user modification allowed" error on operational attributes >>> (structuralobjectclass, contextcsn) when it tries to update the consumer >> slapd >> >> That is expected. >> >>> (the admin guide says the opposite). >> I guess the Admin Guide has a bug then. What exact section are you >> referring to? >> > > Section 16.1.1, the configuration example says twice :" # without the need > to write the UpdateDN before starting replication" That is not what that comment means. That comment means that we *are* using an updateDN. But, the entry corresponding to the updateDN we used in our example doesn't need to be created in advance, because we already know that it's a valid user on the target server. It was unfortunately taken out of context; i.e. it was copied directly from test045 and without the other test045 config file you have no way to see what it means. Definitely we should fix the example here. >>> Then this does not work at all when modifying an entry, because back- >> ldap gets a >>> "modify/delete: hasSubordinates: no such attribute" error when it tries >> to >>> update the entry. >> That's also expected, since hasSubordinates is a dynamically generated >> operational attribute (and also read-only, as I recall). You need to >> exclude >> any dynamically generated operational attributes from the syncrepl search. >> E.g. 2.4's test045 specifically tests this scenario, and the syncrepl spec >> uses: >> syncrepl rid=1 >> provider=ldap://localhost:9011/ >> binddn="cn=Manager,dc=example,dc=com" >> bindmethod=simple >> credentials=secret >> searchbase="dc=example,dc=com" >> filter="(objectClass=*)" >> >> attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimes >> tamp,modifiersName,modifyTimestamp" >> schemachecking=off >> scope=sub >> type=refreshAndPersist >> retry="5 5 300 5" >> > > OK, my mistake. > >> In general, while this is known to work in 2.3, you're better off using >> 2.4. >> (We intentionally did not include test045 in 2.3...) > I'm using 2.3 because I want to use "stable" version. I will keep on using > it, until 2.4 becomes stable (which may occur before the end of my project). > In fact, my real need is this one: I have a backbone network with non > OpenLDAP synchronized directories, and I want to use OpenLDAP directories in > front of this network, on each computer (at least for performance reasons, > until the network fully migrates to OpenLDAP directories). On the master > computer, I will use a master OpenLDAP directory, which replicates to the > non OpenLDAP directory with this syncrepl/back-ldap mechanism (all I need to > do is update the schema of the non OpenLDAP directory, I suppose). On the > slave computers, the non OpenLDAP directory should be provider, and the > OpenLDAP directory should be consumer, but I don't know yet how I will > manage to do this (of course the non OpenLDAP directory does not implement > syncrepl). It seems that syncrepl replication with back-ldap as provider > does not work, is it supposed to? No. back-ldap doesn't know anything about syncrepl itself, it merely passes requests thru from one server to another. Whatever server ultimately answers the request must know how to act as a syncrepl provider, otherwise you get nothing. -- -- 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

(ITS#5395) Patch for test system
by abartlet＠samba.org 28 Feb '08

28 Feb '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 8 URL: http://abartlet.net/patches/memberof-refint.patch Submission from: (NULL) (59.167.251.137) I've added a patch to show that refint and memberof work together.

1 0

Re: [JunkMail] (ITS#5393) syncrepl push based replication with back-ldap fails
by hyc＠symas.com 27 Feb '08

27 Feb '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > I'm trying to set a directory architecture with a syncrepl push based > replication, as (partly) stated in the admin guide, chapter 16.1.1. > I have a provider slapd with bdb, an intermediate slapd with back-ldap, which > points to a consumer slapd with bdb. > First, I have to set an updateDN on the consumer slapd, else back-ldap gets a > "no user modification allowed" error on operational attributes > (structuralobjectclass, contextcsn) when it tries to update the consumer slapd That is expected. > (the admin guide says the opposite). I guess the Admin Guide has a bug then. What exact section are you referring to? > Then this does not work at all when modifying an entry, because back-ldap gets a > "modify/delete: hasSubordinates: no such attribute" error when it tries to > update the entry. That's also expected, since hasSubordinates is a dynamically generated operational attribute (and also read-only, as I recall). You need to exclude any dynamically generated operational attributes from the syncrepl search. E.g. 2.4's test045 specifically tests this scenario, and the syncrepl spec uses: syncrepl rid=1 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" filter="(objectClass=*)" attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp" schemachecking=off scope=sub type=refreshAndPersist retry="5 5 300 5" In general, while this is known to work in 2.3, you're better off using 2.4. (We intentionally did not include test045 in 2.3...) -- -- 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

(ITS#5393) syncrepl push based replication with back-ldap fails
by emmanuel.duru＠atosorigin.com 27 Feb '08

27 Feb '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) I'm trying to set a directory architecture with a syncrepl push based replication, as (partly) stated in the admin guide, chapter 16.1.1. I have a provider slapd with bdb, an intermediate slapd with back-ldap, which points to a consumer slapd with bdb. First, I have to set an updateDN on the consumer slapd, else back-ldap gets a "no user modification allowed" error on operational attributes (structuralobjectclass, contextcsn) when it tries to update the consumer slapd (the admin guide says the opposite). Then this does not work at all when modifying an entry, because back-ldap gets a "modify/delete: hasSubordinates: no such attribute" error when it tries to update the entry.

1 0

(ITS#5392) Some traces are lost
by emmanuel.duru＠atosorigin.com 27 Feb '08

27 Feb '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) Traces related to connections are not logged on file (either default file, or specified file). Examples of traces which are not logged : conn=0 fd=2160 ACCEPT from IP=127.0.0.1:1299 (IP=0.0.0.0:4800) conn=0 op=0 BIND dn="cn=manager,c=fr" method=128 conn=0 op=0 BIND dn="cn=manager,c=fr" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="c=fr" scope=2 deref=0 filter="(o=soc)" conn=0 op=1 SRCH attr=* conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=2 UNBIND conn=0 fd=2160 closed These traces appear on screen but not on file. The problem is that when starting slapd as a Windows service, these traces are lost.

1 0

Bug in Proxy mode..
by K C, Sachin (Sachin) 26 Feb '08

26 Feb '08

OpenLDAP Team, Seems to be a bug in OpenLDAP 2.4.8 configured in Proxy mode with --enable-ldap and --enable-rewrite The proxy config is database ldap suffix "o=<O>" # List of proxy servers delimited by space # uri <Server List> uri "ldap://<Main>:<port>/ ldap://<Secondary>:<port>/" When the "Main" was running, all requests were passed onto Main. I brought it down and saw that the requests were sent to "Secondary" server. After sometime, I brought the Main server back to live simulating a recovery from crash. The requests were still redirected to "Secondary" despite the "Main" server being accessible. I brought down the "Secondary" server and the requests were directed to Main server.!! Is this the correct behaviour? ( I believe that the server in the head of the list should be contacted everytime a request comes to proxy! ) ThanX Sachin

2 1

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 26 Feb '08

26 Feb '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > One hdb backend on one slave died ~21:58 yesterday... > > current thread: t@5 > [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in > "config.c" > [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > (dbx) where > current thread: t@16 > [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in > "delete.c" > [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), > modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, > syncCookie_req = 0xffffffff46fff360, syncCSN = > 0xffffffff46fff390), line 2006 in "syncrepl.c" > [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in > "syncrepl.c" > [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in > "syncrepl.c" > [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > > I can't get db_stat to join the environment. If there's anything else that can > be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, > I'm off to rm/slapadd... > > "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of > the changes (to my eye) looked locking related. Unfortunately no, nothing familiar here. There's nothing in the BDB documentation that says two threads are not allowed to call txn_checkpoint concurrently, but I suppose it may be excessive to make multiple calls in rapid succession. One thing that I've started doing recently in my configs is to skip the #bytes option (leave it zero), so that only time-based checkpoints occur. Since they're done in a dedicated task, only one thread at a time can trigger a checkpoint. -- -- 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

(ITS#5391) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Feb '08

26 Feb '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) One hdb backend on one slave died ~21:58 yesterday... current thread: t@5 [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in "config.c" [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" (dbx) where current thread: t@16 [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in "delete.c" [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, syncCookie_req = 0xffffffff46fff360, syncCSN = 0xffffffff46fff390), line 2006 in "syncrepl.c" [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in "syncrepl.c" [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in "syncrepl.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" I can't get db_stat to join the environment. If there's anything else that can be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, I'm off to rm/slapadd... "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of the changes (to my eye) looked locking related.

1 0

Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > Emmanuel Lecharny wrote: >> Howard Chu wrote: >>> There's no bug here, and the schema parser isn't causing your problem. >>> As documented in slapd.conf(5), directives must form a single logical >>> line. Lines that are split must be continued by a leading space >>> character. > >> Assuming this is not a bug, this is still really painfull... It would be >> much better to consider that the AttributeType, being parenthesed, can >> be scanned without taking into account the leading white space, until >> the closing ')'. > > The config file parser breaks the input into lines before scanning to > see what keywords are actually on those lines. The syntax of the > config file has been documented to behave this way for over 10 years. > Nobody else has cared to change it until now... FYI, before having RTFM, I thought that the only possible "include" I can use was for schema file. It made sense to me then that OpenLDAP was using a specific parser for schema, but I was wrong. It seems that I have missed the part of the doc where this 'first space requirement' is mentionned... We were lucky enough in ADS to be able to use a contextfull parser for those schema file (we support the same format), so we were able to relax this constraint. Supposing that ADS behavior is to be expected by OpenLDAP is obviously a mistake ... I wish I have some time to provide some patch for OpenLDAP to relax such a constraint, but, eh, if I say so, that would be a damn lie ! > > Of course, all of that is going to be phased out as we move to pure > LDIF in the future. (Which again, requires a leading space character > for line continuations. And again, is a well documented feature of the > format.) Yeah, the problem will remain, but at least, there is a RFC for idiot like me who don't do their homeworks... The *big* advantage to have LDIF formatted schemas is that you won't have anymore to care about ordering the elements inside attributeTypes and objectClasses... Btw, we do have some LDIF format for Shcema, and I was wondering if it won't be a good idea to try to define a common format ? I would really appreciate if a LDIF schema file could be directly injected in both ADS and OpenLDAP ! Thanks. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

Emmanuel Lecharny wrote: > Howard Chu wrote: >> There's no bug here, and the schema parser isn't causing your problem. >> As documented in slapd.conf(5), directives must form a single logical >> line. Lines that are split must be continued by a leading space >> character. > Assuming this is not a bug, this is still really painfull... It would be > much better to consider that the AttributeType, being parenthesed, can > be scanned without taking into account the leading white space, until > the closing ')'. The config file parser breaks the input into lines before scanning to see what keywords are actually on those lines. The syntax of the config file has been documented to behave this way for over 10 years. Nobody else has cared to change it until now... Of course, all of that is going to be phased out as we move to pure LDIF in the future. (Which again, requires a leading space character for line continuations. And again, is a well documented feature of the format.) > That being said, as soon as I have fixed the schema file, I'm not > suffering anymore. I was just thinking about the poor other users ;) > > Thanks Howard ! You're welcome ;) -- -- 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#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > There's no bug here, and the schema parser isn't causing your problem. > As documented in slapd.conf(5), directives must form a single logical > line. Lines that are split must be continued by a leading space > character. Assuming this is not a bug, this is still really painfull... It would be much better to consider that the AttributeType, being parenthesed, can be scanned without taking into account the leading white space, until the closing ')'. That being said, as soon as I have fixed the schema file, I'm not suffering anymore. I was just thinking about the poor other users ;) Thanks Howard ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

There's no bug here, and the schema parser isn't causing your problem. As documented in slapd.conf(5), directives must form a single logical line. Lines that are split must be continued by a leading space character. elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.39 (stable) > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.245.116.110) > > > Trying to load a schema, I got an error because the schema parser is expecting a > WSP before the closing parenthese. Here is the attributeType : > > attributetype ( 1.3.6.1.4.1.30267.0.1 > NAME 'ApplicationName' > SUP name > EQUALITY caseIgnoreMatch > ORDERING caseIgnoreOrderingMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE > ) > ^ > | > +--- note that there is no space here. > > If I add a spece before the ')', the schema is parsed correctly. > > This is breaking RFC 4512 : This has nothing to do with RFC 4512. -- -- 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

(ITS#5390) Error while parsing a schema
by elecharny＠apache.org 26 Feb '08

26 Feb '08

Full_Name: Emmanuel Lecharny Version: 2.3.39 (stable) OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.245.116.110) Trying to load a schema, I got an error because the schema parser is expecting a WSP before the closing parenthese. Here is the attributeType : attributetype ( 1.3.6.1.4.1.30267.0.1 NAME 'ApplicationName' SUP name EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ^ | +--- note that there is no space here. If I add a spece before the ')', the schema is parsed correctly. This is breaking RFC 4512 : WSP = 0*SPACE ; zero or more " " AttributeTypeDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oid ] ; supertype [ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SINGLE-VALUE" ] ; single-value [ SP "COLLECTIVE" ] ; collective [ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "USAGE" SP usage ] ; usage extensions WSP RPAREN ; extensions The main problem with this kind of parsing error is that some users may spent _hours_ finding out what's going on... I just spoilt one full hour myself :/ Also the logs are not really self-explanatory... : ... AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other ; AttributeType [ "EQUALITY" woid ] ; Matching Rule name [ "ORDERING" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "USAGE" whsp AttributeUsage ]; default userApplications ; userApplications ; directoryOperation ; distributedOperation ; dSAOperation whsp ")" /opt/ldap/openldap/etc/openldap/schema/sofinco.schema: line 13: <attributetype> handler exited with 1! ...

1 0

(ITS#5389) Contribution: JLDAP support for password policy response control
by t2tre＠skyblue.eu.com 26 Feb '08

26 Feb '08

Full_Name: Raymond Edah Version: JLDAP CVS HEAD OS: Windows URL: http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz Submission from: (NULL) (81.3.106.202) Hi, I have written a class for handling the password policy response control as described in draft-behera-ldap-password-policy-09.txt. I would like to contribute it to the OpenLDAP project. A copy of the code can be found at http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz. Regards, Ray Edah

1 0

(ITS#5388) NULL pointer dereference
by dhen42＠yahoo.co.uk 25 Feb '08

25 Feb '08

Full_Name: Dennis Henriksen Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.10) In server/slapd/oc.c(oc_next) suffers from a potential NULL pointer dereference in the statement '*oc = LDAP_STAILQ_NEXT(*oc,soc_next);'. Perhaps this should read (if *oc != NULL) *oc = LDAP_STAILQ_NEXT(*oc,soc_next);'

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 25 Feb '08

25 Feb '08

h.b.furuseth(a)usit.uio.no a écrit : > jclarke(a)linagora.com writes: >> When slapcat is writing it's output to disk, it ignores any errors >> (with slapcat -l output_file or slapcat > output_file). If an error is >> encountered, such as "No space left on device", slapcat then exits >> normally with a return code of 0. > > Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() > have no way to return error. At best they can set an "error" flag > in the internal database structure, and API calls which are able > to return errors can react to that. Hmmm. I may have misunderstood, but it seems this concerns internal errors, whereas I was referring to the output (writing the data to stdout or to a file) errors. The patch I attached addresses this issue, is there any chance of seeing it included in OpenLDAP, or does it need some more work? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by h.b.furuseth＠usit.uio.no 20 Feb '08

20 Feb '08

jclarke(a)linagora.com writes: > When slapcat is writing it's output to disk, it ignores any errors > (with slapcat -l output_file or slapcat > output_file). If an error is > encountered, such as "No space left on device", slapcat then exits > normally with a return code of 0. Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() have no way to return error. At best they can set an "error" flag in the internal database structure, and API calls which are able to return errors can react to that. -- Hallvard

1 0

(ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 20 Feb '08

20 Feb '08

Full_Name: Jonathan Clarke Version: 2.3, HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20080220.patch.3 Submission from: (NULL) (213.41.243.192) Hi all, When slapcat is writing it's output to disk, it ignores any errors (with slapcat -l output_file or slapcat > output_file). If an error is encountered, such as "No space left on device", slapcat then exits normally with a return code of 0. This seems pretty dangerous to me - if you back up your database with slapcat, but don't get an error on failure, it could easily lead to data loss. Please find at the address below a patch to stop on such errors. It may require some cleaning up - apologies if so. Regards, Jonathan

1 0

Re: ITS#5375
by quanah＠zimbra.com 20 Feb '08

20 Feb '08

I suggest you download and build OpenLDAP 2.4.8. ;) <http://www.openldap.org/software/download/> --Quanah --On Monday, February 18, 2008 12:10 PM +0000 ecizaguirre(a)gmv.com wrote: > > Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version > with the fix under heavy worload and it seems to be working correctly so > the problem is fixed. > > I'm still not able to compile 2.4.7 version with the fix applied. > > Thanks for all and for this great software. > > Cheers. > > Eduardo > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > ______________________ > > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 19 Feb '08

19 Feb '08

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> In RE24 the config schema are only exposed for DEVEL builds. >> >> Why that? Especially why was it changed compared to RE23? > > They were probably exposed in RE23 by mistake. Another option would be to completely disable the subschema subentry for back-config. In this case users of web2ldap could work around it by using a locally stored schema LDIF file for back-config. Ciao, Michael.

1 0

Re: (ITS#5386) Bad value of entryUUID in filter crashes slapd
by ando＠sys-net.it 18 Feb '08

18 Feb '08

silk(a)boktor.net wrote: > If client sends a filter that lookups entries based on entryUUID, and the value > of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Fixed in HEAD (servers/slapd/filter.c 1.148->1.149) Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist
by hyc＠symas.com 18 Feb '08

18 Feb '08

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.15.129.131) > > > One of our environments does cascading replication of one database (the master > for the other databases in this environment is a syncrepl refreshAndPersist > syncrepl client to a database in another environment). > > We monitor the replication status of all our slaves by comparing the contextCSN > on each database with the contextCSN of the updateref, and I have noticed that > the contextCSN on the cascaded replicas is not being updated, even though the > entries have been replicated (according to logging at sync level on these > slaves). All other replication (including non-cascaded refreshAndPersist > databases) works fine. All the servers in question are currently on 2.3.40. > > It seems that the issue can be reproduced with current REL_ENG_2_3, with a > slight modification to test019 (see patch below) to include the contextCSN in > the comparison, which will then fail as follows: I've reproduced this issue in RE23 as well. I note that there's no such problem with RE24. If we can't track this down easily I'm inclined to just ignore 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

(ITS#5386) Bad value of entryUUID in filter crashes slapd
by silk＠boktor.net 18 Feb '08

18 Feb '08

Full_Name: Grzegorz Sobanski Version: 2.4.7(-5) OS: Debain unstable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.254.130.134) If client sends a filter that lookups entries based on entryUUID, and the value of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Example filter: (entryUUID=baka) Steps to reproduce: ldapsearch -x "(entryUUID=baka)" Reproducible: always Error logged by slapd: slapd: /home/devel/openldap/build-area/openldap2.3-2.4.7/servers/slapd/schema_init.c:2537: UUIDNormalize: Assertion `val->bv_len == 16' failed. Expected behaviour: Server does not dies, and: - backwards compatible: filter on entryUUID is skipped - not backward compatible: client is informed about malformed search filter If any more information or tests are needed, please ask.

1 0

ITS#5375
by ecizaguirre＠gmv.com 18 Feb '08

18 Feb '08

Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version with the fix under heavy worload and it seems to be working correctly so the problem is fixed. I'm still not able to compile 2.4.7 version with the fix applied. Thanks for all and for this great software. Cheers. Eduardo ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com 18 Feb '08

18 Feb '08

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> In RE24 the config schema are only exposed for DEVEL builds. >> >> Why that? Especially why was it changed compared to RE23? > > They were probably exposed in RE23 by mistake. The config schema uses an > OID from the OpenLDAP Experimental arc and the Project's policy is not > to publish experimental OIDs for general use, only for Development. But then back-config SHOULD be hidden by DEVEL as well. Frankly no-one will ever recognize when you change an OID arc. There would be no issues with LDAP clients at all. > Given that things in cn=config have pretty much stabilized, we probably > ought to have migrated to a non-experimental arc for RE24. Yes, please. Given that back-config is endorsed to be deployed in production schema-aware LDAP clients must have the chance to retrieve required information for processing the data. > Note that the cn=config schema still relies on an unfinished spec > (draft-chu-ldap-xordered) and that needs to be finalized still. Whatever "unfinished" means. From the IETF point-of-view this is simply a proprietary feature not documented anywhere in the IETF process so far. From OpenLDAP project point-of-view it is yet another not fully documented feature. This is not a real issue which should hold back providing the schema to the client. But if back-config is activated in normal builds then the interface definition SHOULD be complete which includes providing the relevant schema information in subschema subentry. Ciao, Michael.

1 0

(ITS#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist
by bgmilne＠staff.telkomsa.net 18 Feb '08

18 Feb '08

Full_Name: Buchan Milne Version: OPENLDAP_REL_ENG_2_3 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) One of our environments does cascading replication of one database (the master for the other databases in this environment is a syncrepl refreshAndPersist syncrepl client to a database in another environment). We monitor the replication status of all our slaves by comparing the contextCSN on each database with the contextCSN of the updateref, and I have noticed that the contextCSN on the cascaded replicas is not being updated, even though the entries have been replicated (according to logging at sync level on these slaves). All other replication (including non-cascaded refreshAndPersist databases) works fine. All the servers in question are currently on 2.3.40. It seems that the issue can be reproduced with current REL_ENG_2_3, with a slight modification to test019 (see patch below) to include the contextCSN in the comparison, which will then fail as follows: $ ./run test019 Running ./scripts/test019-syncreplication-cascade... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=23363) is running... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=23370) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=23376) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=23382) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=23388) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=23395) is running... Using ldapadd to populate the master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... Using ldapsearch to read all the entries from the P1 slave... Using ldapsearch to read all the entries from the P2 slave... Using ldapsearch to read all the entries from the P3 slave... Filtering master ldapsearch results... Filtering R1 slave ldapsearch results... Filtering R2 slave ldapsearch results... Filtering P1 slave ldapsearch results... Filtering P2 slave ldapsearch results... Filtering P3 slave ldapsearch results... Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... Comparing retrieved entries from master and P1 slave... Comparing retrieved entries from master and P2 slave... test failed - master and P2 slave databases differ $ diff -u testrun/server{1,5}.flt --- testrun/server1.flt 2008-02-18 12:00:52.000000000 +0200 +++ testrun/server5.flt 2008-02-18 12:00:52.000000000 +0200 @@ -108,7 +108,7 @@ postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com -contextCSN: 20080218100027Z#000002#00#000000 +contextCSN: 20080218100027Z#000000#00#000000 dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= com Index: scripts/test019-syncreplication-cascade =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/tests/scripts/test019-syncreplication-cascade,v retrieving revision 1.13.2.7 diff -u -r1.13.2.7 test019-syncreplication-cascade --- scripts/test019-syncreplication-cascade 11 Feb 2008 23:24:28 -0000 1.13.2.7 +++ scripts/test019-syncreplication-cascade 18 Feb 2008 10:02:51 -0000 @@ -331,7 +331,7 @@ echo "Using ldapsearch to read all the entries from the master..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \ - 'objectclass=*' > $MASTEROUT 2>&1 + 'objectclass=*' '*' contextCSN > $MASTEROUT 2>&1 RC=$? if test $RC != 0 ; then @@ -342,7 +342,7 @@ echo "Using ldapsearch to read all the entries from the R1 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \ - 'objectclass=*' > $SERVER2OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER2OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -353,7 +353,7 @@ echo "Using ldapsearch to read all the entries from the R2 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \ - 'objectclass=*' > $SERVER3OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER3OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -364,7 +364,7 @@ echo "Using ldapsearch to read all the entries from the P1 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT4 \ - 'objectclass=*' > $SERVER4OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER4OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -375,7 +375,7 @@ echo "Using ldapsearch to read all the entries from the P2 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT5 \ - 'objectclass=*' > $SERVER5OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER5OUT 2>&1 RC=$? if test $RC != 0 ; then @@ -386,7 +386,7 @@ echo "Using ldapsearch to read all the entries from the P3 slave..." $LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT6 \ - 'objectclass=*' > $SERVER6OUT 2>&1 + 'objectclass=*' '*' contextCSN > $SERVER6OUT 2>&1 RC=$? if test $RC != 0 ; then

1 0

Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com 18 Feb '08

18 Feb '08

Michael Ströder wrote: > Howard Chu wrote: >> In RE24 the config schema are only exposed for DEVEL builds. > > Why that? Especially why was it changed compared to RE23? They were probably exposed in RE23 by mistake. The config schema uses an OID from the OpenLDAP Experimental arc and the Project's policy is not to publish experimental OIDs for general use, only for Development. Given that things in cn=config have pretty much stabilized, we probably ought to have migrated to a non-experimental arc for RE24. I suppose we can take this ITS as a reminder to do that. Note that the cn=config schema still relies on an unfinished spec (draft-chu-ldap-xordered) and that needs to be finalized still. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs