- openldap-bugs - openldap.org

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 16 Dec '09

16 Dec '09

The ldif code does not currently have knowledge of any of the higher level LDAP data types such as LDAPMod or LDAPControl - some of the proposals would have the ldif API return these objects - Do we really want to introduce this higher level knowledge into the relatively low level libldif, along with the dependency on libldap? I think in order to do this properly, we would have to introduce a new LDAP API e.g. ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or something like that - something that would parse the given ldif record into those higher level data types.

1 0

Re: (ITS#6403) crash with translucent + back-null
by h.b.furuseth＠usit.uio.no 16 Dec '09

16 Dec '09

I wrote: > I'll fix translucent for now, but I assume a saner fix would be to > change that "calling convention" - which I suspect exists in the first > place because I once gave a bug just like this the same minimal fix. [Reopening ITS...] And I have no idea why I didn't remove that back-null assert as well, though there was undoubtedly a reason. Anyway, it's gone now. -- Hallvard

1 0

Re: (ITS#6431) LDAP Server disabled
by quanah＠zimbra.com 15 Dec '09

15 Dec '09

--On Tuesday, December 15, 2009 3:32 AM +0000 yimnara(a)khaouchuly.com wrote: > Full_Name: Yim Nara > Version: 2.1.0 > OS: Window 2003 server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.248.180.59) > > > LDAP server Disabled I'm not sure why you think this is an OpenLDAP issue, nor do I see any indication of a bug report here. If you have questions about using OpenLDAP, please use the openldap-software(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 15 Dec '09

15 Dec '09

Forgot to enclose the URL. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft2.diff

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 15 Dec '09

15 Dec '09

[Copying some discussion from IRC, and adding some more] I'm a bit nervous about doing more than minimal fixes to this until we do something major, because it's so broken. Fix one bit and maybe something will pop up another place - i.e. a regression. Also following existing practice can mean fix one bug into a different bug, which Ando recently did for ITS#6423. (dynlist resets MUSTRELEASE but doesn't obey it, rwm works around a similar bug in rwm or dynlist.) Though he got other fixes right. Anyway: To repeat, the main problems with the current code: * Code does not always clean up properly, leaving e.g. flags behind. * Code which does clean up sometimes does it halfway, e.g. it resets MUSTBEFREED/MUSTRELEASE but not MODIFIABLE. So, no wonder there are unwanted MODIFIABLE flags hanging about (ITS#6423). Or it dup()s an entry but does not release the old one. * op_*() generally expects SlapReply to be preinitialized. That worked before overlays, but now modules (backends, overlays) inherit values that the previous module did not clean up during an operation. Howard suggested that we should restore that - code which puts something into a SlapReply should ensure it's taken out again. I've started on that in the enclosed patch, but on second thought I think that's not the right fix because it's the most fragile solution: Practically every module which depends on it can break if some other module gets it wrong. OTOH, modules can't just reset SlapReply since some of it is input values to op_*(): - Controls can be set in backend_check_restrictions() before the call to op_*(). - dynlist.c sets r.sr_attr_flags before calling o.o_bd->be_search(), I haven't looked at what effect that has. I'm thinking modules should instead initialize SlapReply.sr_u and maybe some sr_flags themselves instead of depending on preinit, but I don't know when I'll get back to doing something about that. Xmas coming... So anyway, here is a quick patch which actually tries to be rather conservative, sans a bunch of RS_ASSERT() lines which can be safely deleted in real code. It only addresses sr_entry and sporadically attrs, not sr_refs/ctrls. It passes make test for me. Please review. Where updates to flags are broken and needs fixing, I change to use the new function rs_ensure_entry_modifiable() etc, but I leave correct updates alone - as well as some updates where I don't know which overlay should be passed to these function. Description of changes: All over the place: Clear MUSTBEFREED/MUSTRELEASE by clearing all of REP_ENTRY_MASK, not just the particular flag. Reset attrs, entry, flags a number of places. (Not very consistently, sorry.) Lots of RS_ASSERT()s for debugging. Only defined when LDAP_DEVEL. proto-slap.h, result.c: Move RS_ASSERT(), add rs_flush_entry(). result.c: MODIFIABLE is independent of MUSTBEFREED - the modifiable entry can e.g. be on the stack. result.c, extended.c: When changing sr->sr_type to extended/sasl, flush sr_un (usually the entry) first, since another member of the union will be used. For this reason, updates to sr_type are "suspicious" code to be avoided, so some code elsewhere is changed to initialize it to REP_RESULT rather than setting it to that after initialization. bconfig.c, servers/slapd/syncrepl.c: Avoid reusing SlapReply a number of places where that's easy. slap.h: Cast the REP_... flags to slap_mask_t, so ~REP_... will work right. back-bdb/search.c: Delay setting rs->sr_entry until we know it'll be used. (IIRC made a difference around a paged results response.) back-shell/result.c, back-sock/result.c: Set MUSTBEFREED before sending, obey it afterwards. overlays/constraint.c, overlays/pcache.c: Drop nulling of fields that were just nulled by initialization. overlays/dynlist.c: When "stealing" an entry from SlapReply, grab and reset the flags that go with it, so it can be properly freed/released. Restore the flags and entry later, then obey the flags (release/free). Do this unconditionally, it happens only once per SlapReply anyway. overlays/pcache.c: Obey and reset entry flags properly. Remove unused SlapReply parameters to some functions - did this for readibility while trying to figure out what was going on. overlays/sssvlv.c: Since setting MUSTRELEASE before sending, obey it afterwards. overlays/translucent.c: Reset flags properly too when releasing/freeing entry. Streamline translucent_search() loop to clarify ownership of entry. overlays/rwm.c, servers/slapd/slapi/slapi_pblock.c: Obey flags properly.

1 0

Re: Re: (ITS#6426) slapd crash with 'Bus error'
by a.afzali2003＠gmail.com 15 Dec '09

15 Dec '09

--001485f6da5ee30006047ac04fe7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Regards, -- afshin On Dec 15, 2009 11:58am, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Afshin, > Copy openldap-its(a)openldap.org on all you replies so they go into the bug > tracker, so that others can see them. > --Quanah > --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali > a.afzali2003(a)gmail.com> wrote: > Hi Quanah, > Appreciate your help. Hope this be helpful. > -- afshin > [root@dc1 libexec]# gdb ./slapd core.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu"... > Reading symbols from /lib64/libuuid.so.1...done. > Loaded symbols for /lib64/libuuid.so.1 > Reading symbols from /lib64/librt.so.1...done. > Loaded symbols for /lib64/librt.so.1 > Reading symbols from /lib64/libcrypt.so.1...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libnsl.so.1...done. > Loaded symbols for /lib64/libnsl.so.1 > Reading symbols from /lib64/libm.so.6...done. > Loaded symbols for /lib64/libm.so.6 > Reading symbols from /lib64/libpthread.so.0...done. > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libstdc++.so.6...done. > Loaded symbols for /usr/lib64/libstdc++.so.6 > Reading symbols from /usr/lib64/libsasl2.so.2...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /lib64/libssl.so.6...done. > Loaded symbols for /lib64/libssl.so.6 > Reading symbols from /lib64/libcrypto.so.6...done. > Loaded symbols for /lib64/libcrypto.so.6 > Reading symbols from /lib64/libresolv.so.2...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /lib64/libgcc_s.so.1...done. > Loaded symbols for /lib64/libgcc_s.so.1 > Reading symbols from /lib64/libc.so.6...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > Reading symbols from /usr/lib64/libkrb5.so.3...done. > Loaded symbols for /usr/lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /usr/lib64/libk5crypto.so.3...done. > Loaded symbols for /usr/lib64/libk5crypto.so.3 > Reading symbols from /usr/lib64/libz.so.1...done. > Loaded symbols for /usr/lib64/libz.so.1 > Reading symbols from /usr/lib64/libkrb5support.so.0...done. > Loaded symbols for /usr/lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libsepol.so.1...done. > Loaded symbols for /lib64/libsepol.so.1 > Reading symbols from /lib64/libnss_files.so.2...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. > Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] > # 0 NdbTransaction::execute (this=0x15, > # aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:278 > 278 NdbTransaction.cpp: No such file or directory. > in NdbTransaction.cpp > (gdb) thr apply all bt > Thread 9 (process 12305): > # 0 0x000000370e8077e5 in pthread_join () from /lib64/libpthread.so.0 > # 1 0x000000000059affb in ldap_pvt_thread_join (thread=1107417408, > thread_return=0x0) at thr_posix.c:197 > # 2 0x00000000004ba2a8 in slapd_daemon () at daemon.c:2835 > # 3 0x000000000049bfad in main (argc=2, argv=0x7fff78fd91e8) at > # main.c:950 > Current language: auto; currently c++ > Thread 8 (process 12307): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > at my_sleep.c:34 > # 2 0x00000000006b3ff0 in TransporterFacade::threadMainReceive > # (this=0xc7a6530) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b4049 in runReceiveResponse_C (me=0x0) > at TransporterFacade.cpp:564 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc581620) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 7 (process 12308): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > ---Type to continue, or q to quit--- > at my_sleep.c:34 > # 2 0x00000000006b2d0f in TransporterFacade::threadMainSend > # (this=0xc7a6530) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b2d89 in runSendRequest_C (me=0x0) > at TransporterFacade.cpp:529 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc588670) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 6 (process 12309): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > at my_sleep.c:34 > # 2 0x00000000006b9740 in ClusterMgr::threadMain (this=0xc7b8ce0) > at ../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006b98d9 in runClusterMgr_C (me=0x0) at ClusterMgr.cpp:50 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc5888b0) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 5 (process 12310): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x000000000068a73b in my_sleep (m_seconds=) > ---Type to continue, or q to quit--- > at my_sleep.c:34 > # 2 0x00000000006c8738 in TransporterRegistry::start_clients_thread ( > this=0xc580c70) at > ../../../../../storage/ndb/include/portlib/NdbSleep.h:31 > # 3 0x00000000006c89e9 in run_start_clients_C (me=0x0) > at TransporterRegistry.cpp:1422 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc588a40) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 4 (process 12311): > # 0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > # 1 0x00000000006a82d6 in SocketServer::doAccept (this=0xc7b8bd0) > at SocketServer.cpp:189 > # 2 0x00000000006a8612 in SocketServer::doRun (this=0xc7b8bd0) > at SocketServer.cpp:279 > # 3 0x00000000006a8639 in socketServerThread_C (_ss=0x1) > at SocketServer.cpp:231 > # 4 0x00000000006a35de in ndb_thread_wrapper (_ss=0xc581710) at > # NdbThread.c:147 5 0x000000370e8064a7 in start_thread () from > # /lib64/libpthread.so.0 6 0x000000370e0d3c2d in clone () from > # /lib64/libc.so.6 > Thread 3 (process 12312): > # 0 0x000000370e0d4018 in epoll_wait () from /lib64/libc.so.6 > ---Type to continue, or q to quit--- > # 1 0x00000000004b9559 in slapd_daemon_task (ptr=0x0) at daemon.c:2460 > # 2 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 3 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > Thread 2 (process 12314): > # 0 0x000000370e80ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > # 1 0x000000000059b0a3 in ldap_pvt_thread_cond_wait (cond=0xc538bc0, > mutex=0xc538b98) at thr_posix.c:277 > # 2 0x0000000000599b63 in ldap_int_thread_pool_wrapper (xpool=0xc538b90) > at tpool.c:672 > # 3 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 4 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > Thread 1 (process 12313): > # 0 NdbTransaction::execute (this=0x15, > # aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:278 > # 1 0x0000000000561195 in NdbTransaction::execute (this=0x15, > execType=Rollback, abortOption=DefaultAbortOption, force=0) > at /usr/include/mysql/storage/ndb/ndbapi/NdbTransaction.hpp:343 > # 2 0x0000000000575926 in ndb_back_add (op=0xc58c5d0, rs=0x4283ec00) > at add.cpp:336 > ---Type to continue, or q to quit--- > # 3 0x00000000004c6489 in fe_op_add (op=0xc58c5d0, rs=0x4283ec00) at > # add.c:334 4 0x00000000004c5e13 in do_add (op=0xc58c5d0, rs=0x4283ec00) > # at add.c:194 5 0x00000000004bd06a in connection_operation > # (ctx=0x4283ed50, > arg_v=0xc58c5d0) at connection.c:1123 > # 6 0x00000000004bd5ef in connection_read_thread (ctx=0x4283ed50, > # argv=0xd) > at connection.c:1259 > # 7 0x0000000000599c01 in ldap_int_thread_pool_wrapper (xpool=0xc538b90) > at tpool.c:685 > # 8 0x000000370e8064a7 in start_thread () from /lib64/libpthread.so.0 > # 9 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > (gdb) > On Tue, Dec 15, 2009 at 4:01 AM, Quanah Gibson-Mount quanah(a)zimbra.com> > wrote: > --On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: > # 0=C2=A0 0x000000000066f891 in ?? () > (gdb) > So where's the thr apply all bt command inside gdb? You've just loaded > Please provide the backtrace as noted if you want this to be further > investigated. Thanks! > Again, after you run: > gdb > You then need to run: > thr apply all bt > To get a backtrace of all threads, and then submit that to the ITS. > --Quanah > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration --001485f6da5ee30006047ac04fe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regards, -- afshin On Dec 15, 2009 11:58am, Quanah Gibson-M= ount <quanah(a)zimbra.com> wrote: > Afshin, > &gt= ; > > Copy openldap-its(a)openldap.org on all you replies s= o they go into the bug tracker, so that others can see them. > > > > --Quanah > > > > --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali a.afzali= 2003(a)gmail.com> wrote: > > > > = > Hi Quanah, > > > > Appreciate your = help. Hope this be helpful. > > -- afshin > = > > > > > [root@dc1 libexec]# gdb ./= slapd core.12305 > > GNU gdb Fedora (6.8-37.el5) >= > Copyright (C) 2008 Free Software Foundation, Inc. > <br= />> License GPLv3+: GNU GPL version 3 or later > > htt= p://gnu.org/licenses/gpl.html> > > This is free softwar= e: you are free to change and redistribute it. > > There i= s NO WARRANTY, to the extent permitted by law.=A0 Type "show >= > copying" > > and "show warranty&quot= ; for details. > > This GDB was configured as "x86_64= -redhat-linux-gnu"... > > Reading symbols from /lib64= /libuuid.so.1...done. > > Loaded symbols for /lib64/libuui= d.so.1 > > Reading symbols from /lib64/librt.so.1...done.<= br />> > Loaded symbols for /lib64/librt.so.1 > &= gt; Reading symbols from /lib64/libcrypt.so.1...done. > > = Loaded symbols for /lib64/libcrypt.so.1 > > Reading symbol= s from /lib64/libnsl.so.1...done. > > Loaded symbols for /= lib64/libnsl.so.1 > > Reading symbols from /lib64/libm.so.= 6...done. > > Loaded symbols for /lib64/libm.so.6 &gt= ; > Reading symbols from /lib64/libpthread.so.0...done. > = > Loaded symbols for /lib64/libpthread.so.0 > > R= eading symbols from /usr/lib64/libstdc++.so.6...done. > > = Loaded symbols for /usr/lib64/libstdc++.so.6 > > Reading s= ymbols from /usr/lib64/libsasl2.so.2...done. > > Loaded sy= mbols for /usr/lib64/libsasl2.so.2 > > Reading symbols fro= m /lib64/libssl.so.6...done. > > Loaded symbols for /lib64= /libssl.so.6 > > Reading symbols from /lib64/libcrypto.so.= 6...done. > > Loaded symbols for /lib64/libcrypto.so.6 > > Reading symbols from /lib64/libresolv.so.2...done. &= gt; > Loaded symbols for /lib64/libresolv.so.2 > &gt= ; Reading symbols from /lib64/libgcc_s.so.1...done. > > Lo= aded symbols for /lib64/libgcc_s.so.1 > > Reading symbols = from /lib64/libc.so.6...done. > > Loaded symbols for /lib6= 4/libc.so.6 > > Reading symbols from /lib64/ld-linux-x86-6= 4.so.2...done. > > Loaded symbols for /lib64/ld-linux-x86-= 64.so.2 > > Reading symbols from /lib64/libdl.so.2...done.= > > Loaded symbols for /lib64/libdl.so.2 > = > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > = > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > > Reading symbols from /usr/lib64/libkrb5.so.3...done. > > Loaded symbols for /usr/lib64/libkrb5.so.3 > > Readi= ng symbols from /lib64/libcom_err.so.2...done. > > Loaded = symbols for /lib64/libcom_err.so.2 > > Reading symbols fro= m /usr/lib64/libk5crypto.so.3...done. > > Loaded symbols f= or /usr/lib64/libk5crypto.so.3 > > Reading symbols from /u= sr/lib64/libz.so.1...done. > > Loaded symbols for /usr/lib= 64/libz.so.1 > > Reading symbols from /usr/lib64/libkrb5su= pport.so.0...done. > > Loaded symbols for /usr/lib64/libkr= b5support.so.0 > > Reading symbols from /lib64/libkeyutils= .so.1...done. > > Loaded symbols for /lib64/libkeyutils.so= .1 > > Reading symbols from /lib64/libselinux.so.1...done.= > > Loaded symbols for /lib64/libselinux.so.1 > <= br />> Reading symbols from /lib64/libsepol.so.1...done. > > Loaded symbols for /lib64/libsepol.so.1 > > Reading = symbols from /lib64/libnss_files.so.2...done. > > Loaded s= ymbols for /lib64/libnss_files.so.2 > > Reading symbols fr= om /usr/lib64/sasl2/libanonymous.so.2...done. > > Loaded s= ymbols for /usr/lib64/sasl2/libanonymous.so.2 > > Reading = symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > > L= oaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > > Read= ing symbols from /usr/lib64/sasl2/liblogin.so.2...done. > &gt= ; Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > > Re= ading symbols from /usr/lib64/sasl2/libplain.so.2...done. > &= gt; Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > > = Core was generated by `./slapd -d5'. > > Program termi= nated with signal 11, Segmentation fault. > > [New process= 12313] > > [New process 12314] > > [New = process 12312] > > [New process 12311] > &gt= ; [New process 12310] > > [New process 12309] > <b= r />> [New process 12308] > > [New process 12307] = > > [New process 12305] > > # 0=A0 NdbTransact= ion::execute (this=3D0x15, > > # aTypeOfExec=3DNdbTransact= ion::Rollback, > > =A0=A0=A0 abortOption=3DNdbOperation::D= efaultAbortOption, forceSend=3D0) > > =A0=A0=A0 at NdbTran= saction.cpp:278 > > 278=A0=A0=A0=A0 NdbTransaction.cpp: No= such file or directory. > > =A0=A0=A0=A0=A0=A0=A0 in NdbT= ransaction.cpp > > (gdb) thr apply all bt > = > > > Thread 9 (process 12305): > > #= 0=A0 0x000000370e8077e5 in pthread_join () from /lib64/libpthread.so.0 > > # 1=A0 0x000000000059affb in ldap_pvt_thread_join (thread= =3D1107417408, > > =A0=A0=A0 thread_return=3D0x0) at thr_p= osix.c:197 > > # 2=A0 0x00000000004ba2a8 in slapd_daemon (= ) at daemon.c:2835 > > # 3=A0 0x000000000049bfad in main (= argc=3D2, argv=3D0x7fff78fd91e8) at > > # main.c:950 = > > Current language:=A0 auto; currently c++ > &g= t; > > Thread 8 (process 12307): > > # 0= =A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > &= gt; # 1=A0 0x000000000068a73b in my_sleep (m_seconds=3D) > &g= t; =A0=A0=A0 at my_sleep.c:34 > > # 2=A0 0x00000000006b3ff= 0 in TransporterFacade::threadMainReceive > > # (this=3D0x= c7a6530) > > =A0=A0=A0 at ../../../../storage/ndb/include/= portlib/NdbSleep.h:31 > > # 3=A0 0x00000000006b4049 in run= ReceiveResponse_C (me=3D0x0) > > =A0=A0=A0 at TransporterF= acade.cpp:564 > > # 4=A0 0x00000000006a35de in ndb_thread_= wrapper (_ss=3D0xc581620) at > > # NdbThread.c:147 5=A0 0x= 000000370e8064a7 in start_thread () from > > # /lib64/libp= thread.so.0 6=A0 0x000000370e0d3c2d in clone () from > > #= /lib64/libc.so.6 > > > > Thread 7 (proc= ess 12308): > > # 0=A0 0x000000370e0cced2 in select () fro= m /lib64/libc.so.6 > > # 1=A0 0x000000000068a73b in my_sle= ep (m_seconds=3D) > > ---Type to continue, or q to quit-= -- > > =A0=A0=A0 at my_sleep.c:34 > > # 2= =A0 0x00000000006b2d0f in TransporterFacade::threadMainSend > > # (this=3D0xc7a6530) > > =A0=A0=A0 at ../../../../st= orage/ndb/include/portlib/NdbSleep.h:31 > > # 3=A0 0x00000= 000006b2d89 in runSendRequest_C (me=3D0x0) > > =A0=A0=A0 a= t TransporterFacade.cpp:529 > > # 4=A0 0x00000000006a35de = in ndb_thread_wrapper (_ss=3D0xc588670) at > > # NdbThread= .c:147 5=A0 0x000000370e8064a7 in start_thread () from > >= # /lib64/libpthread.so.0 6=A0 0x000000370e0d3c2d in clone () from &gt= ; > # /lib64/libc.so.6 > > > > = Thread 6 (process 12309): > > # 0=A0 0x000000370e0cced2 in= select () from /lib64/libc.so.6 > > # 1=A0 0x000000000068= a73b in my_sleep (m_seconds=3D) > > =A0=A0=A0 at my_sleep.= c:34 > > # 2=A0 0x00000000006b9740 in ClusterMgr::threadMa= in (this=3D0xc7b8ce0) > > =A0=A0=A0 at ../../../../storage= /ndb/include/portlib/NdbSleep.h:31 > > # 3=A0 0x0000000000= 6b98d9 in runClusterMgr_C (me=3D0x0) at ClusterMgr.cpp:50 > &= gt; # 4=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc5888b0) at<br= />> > # NdbThread.c:147 5=A0 0x000000370e8064a7 in start_threa= d () from > > # /lib64/libpthread.so.0 6=A0 0x000000370e0d= 3c2d in clone () from > > # /lib64/libc.so.6 > <br= />> > > Thread 5 (process 12310): > &gt= ; # 0=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 > <b= r />> # 1=A0 0x000000000068a73b in my_sleep (m_seconds=3D) > <br= />> ---Type to continue, or q to quit--- > > =A0=A0= =A0 at my_sleep.c:34 > > # 2=A0 0x00000000006c8738 in Tran= sporterRegistry::start_clients_thread ( > > =A0=A0=A0 this= =3D0xc580c70) at > > ../../../../../storage/ndb/include/po= rtlib/NdbSleep.h:31 > > # 3=A0 0x00000000006c89e9 in run_s= tart_clients_C (me=3D0x0) > > =A0=A0=A0 at TransporterRegi= stry.cpp:1422 > > # 4=A0 0x00000000006a35de in ndb_thread_= wrapper (_ss=3D0xc588a40) at > > # NdbThread.c:147 5=A0 0x= 000000370e8064a7 in start_thread () from > > # /lib64/libp= thread.so.0 6=A0 0x000000370e0d3c2d in clone () from > > #= /lib64/libc.so.6 > > > > Thread 4 (proc= ess 12311): > > # 0=A0 0x000000370e0cced2 in select () fro= m /lib64/libc.so.6 > > # 1=A0 0x00000000006a82d6 in Socket= Server::doAccept (this=3D0xc7b8bd0) > > =A0=A0=A0 at Socke= tServer.cpp:189 > > # 2=A0 0x00000000006a8612 in SocketSer= ver::doRun (this=3D0xc7b8bd0) > > =A0=A0=A0 at SocketServe= r.cpp:279 > > # 3=A0 0x00000000006a8639 in socketServerThr= ead_C (_ss=3D0x1) > > =A0=A0=A0 at SocketServer.cpp:231<br= />> > # 4=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0= xc581710) at > > # NdbThread.c:147 5=A0 0x000000370e8064a7= in start_thread () from > > # /lib64/libpthread.so.0 6=A0= 0x000000370e0d3c2d in clone () from > > # /lib64/libc.so.= 6 > > > > Thread 3 (process 12312): > > # 0=A0 0x000000370e0d4018 in epoll_wait () from /lib64/lib= c.so.6 > > ---Type to continue, or q to quit--- &gt= ; > # 1=A0 0x00000000004b9559 in slapd_daemon_task (ptr=3D0x0) at = daemon.c:2460 > > # 2=A0 0x000000370e8064a7 in start_threa= d () from /lib64/libpthread.so.0 > > # 3=A0 0x000000370e0d= 3c2d in clone () from /lib64/libc.so.6 > > > > Thread 2 (process 12314): > > # 0=A0 0x000000370e80= ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > > =A0=A0 from = /lib64/libpthread.so.0 > > # 1=A0 0x000000000059b0a3 in ld= ap_pvt_thread_cond_wait (cond=3D0xc538bc0, > > =A0=A0=A0 m= utex=3D0xc538b98) at thr_posix.c:277 > > # 2=A0 0x00000000= 00599b63 in ldap_int_thread_pool_wrapper (xpool=3D0xc538b90) > > =A0=A0=A0 at tpool.c:672 > > # 3=A0 0x000000370e806= 4a7 in start_thread () from /lib64/libpthread.so.0 > > # 4= =A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > &g= t; > > Thread 1 (process 12313): > > # 0= =A0 NdbTransaction::execute (this=3D0x15, > > # aTypeOfExe= c=3DNdbTransaction::Rollback, > > =A0=A0=A0 abortOption=3D= NdbOperation::DefaultAbortOption, forceSend=3D0) > > =A0= =A0=A0 at NdbTransaction.cpp:278 > > # 1=A0 0x000000000056= 1195 in NdbTransaction::execute (this=3D0x15, > > =A0=A0= =A0 execType=3DRollback, abortOption=3DDefaultAbortOption, force=3D0) = > > =A0=A0=A0 at /usr/include/mysql/storage/ndb/ndbapi/NdbTrans= action.hpp:343 > > # 2=A0 0x0000000000575926 in ndb_back_a= dd (op=3D0xc58c5d0, rs=3D0x4283ec00) > > =A0=A0=A0 at add.= cpp:336 > > ---Type to continue, or q to quit--- &g= t; > # 3=A0 0x00000000004c6489 in fe_op_add (op=3D0xc58c5d0, rs=3D= 0x4283ec00) at > > # add.c:334 4=A0 0x00000000004c5e13 in = do_add (op=3D0xc58c5d0, rs=3D0x4283ec00) > > # at add.c:19= 4 5=A0 0x00000000004bd06a in connection_operation > > # (c= tx=3D0x4283ed50, > > =A0=A0=A0 arg_v=3D0xc58c5d0) at conne= ction.c:1123 > > # 6=A0 0x00000000004bd5ef in connection_r= ead_thread (ctx=3D0x4283ed50, > > # argv=3D0xd) > = > =A0=A0=A0 at connection.c:1259 > > # 7=A0 0x000= 0000000599c01 in ldap_int_thread_pool_wrapper (xpool=3D0xc538b90) >= > =A0=A0=A0 at tpool.c:685 > > # 8=A0 0x00000037= 0e8064a7 in start_thread () from /lib64/libpthread.so.0 > &gt= ; # 9=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > <br= />> (gdb) > > > > > &= gt; > > > > On Tue, Dec 15, 2009 at 4:0= 1 AM, Quanah Gibson-Mount quanah(a)zimbra.com> > > wrote:= > > > > --On Saturday, December 12, 200= 9 5:48 PM +0000 quanah(a)zimbra.com wrote: > > > <b= r />> > > > > > > = # 0=3DC2=3DA0 0x000000000066f891 in ?? () > > (gdb) &= gt; > > > > > > > So where's the thr apply all bt command inside gdb? =A0You've= just loaded > > > > > &g= t; Please provide the backtrace as noted if you want this to be further > > investigated. =A0Thanks! > > > = > Again, after you run: > > > >= gdb > > > > You then need to run: > > > > thr apply all bt > &g= t; > > To get a backtrace of all threads, and then submit= that to the ITS. > > > > > <br= />> > > > > --Quanah > > > > > > -- > > = > > Quanah Gibson-Mount > > Principal So= ftware Engineer > > Zimbra, Inc > > -----= --------------- > > Zimbra :: =A0the leader in open source= messaging and collaboration > > > > <br= />> > > > > > > <= br />> > -- > > > > Quanah G= ibson-Mount > > Principal Software Engineer > > Zimbra, Inc > > -------------------- > > Zimbra :: =A0the leader in open source messaging and collaboration<b= r />> --001485f6da5ee30006047ac04fe7--

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 15 Dec '09

15 Dec '09

Afshin, Copy openldap-its(a)openldap.org on all you replies so they go into the bug=20 tracker, so that others can see them. --Quanah --On Tuesday, December 15, 2009 10:39 AM +0330 afshin afzali=20 <a.afzali2003(a)gmail.com> wrote: > Hi Quanah, > > Appreciate your help. Hope this be helpful. > -- afshin > > > [root@dc1 libexec]# gdb ./slapd core.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.=C2=A0 Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu"... > Reading symbols from /lib64/libuuid.so.1...done. > Loaded symbols for /lib64/libuuid.so.1 > Reading symbols from /lib64/librt.so.1...done. > Loaded symbols for /lib64/librt.so.1 > Reading symbols from /lib64/libcrypt.so.1...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libnsl.so.1...done. > Loaded symbols for /lib64/libnsl.so.1 > Reading symbols from /lib64/libm.so.6...done. > Loaded symbols for /lib64/libm.so.6 > Reading symbols from /lib64/libpthread.so.0...done. > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libstdc++.so.6...done. > Loaded symbols for /usr/lib64/libstdc++.so.6 > Reading symbols from /usr/lib64/libsasl2.so.2...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /lib64/libssl.so.6...done. > Loaded symbols for /lib64/libssl.so.6 > Reading symbols from /lib64/libcrypto.so.6...done. > Loaded symbols for /lib64/libcrypto.so.6 > Reading symbols from /lib64/libresolv.so.2...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /lib64/libgcc_s.so.1...done. > Loaded symbols for /lib64/libgcc_s.so.1 > Reading symbols from /lib64/libc.so.6...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. > Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 > Reading symbols from /usr/lib64/libkrb5.so.3...done. > Loaded symbols for /usr/lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /usr/lib64/libk5crypto.so.3...done. > Loaded symbols for /usr/lib64/libk5crypto.so.3 > Reading symbols from /usr/lib64/libz.so.1...done. > Loaded symbols for /usr/lib64/libz.so.1 > Reading symbols from /usr/lib64/libkrb5support.so.0...done. > Loaded symbols for /usr/lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libsepol.so.1...done. > Loaded symbols for /lib64/libsepol.so.1 > Reading symbols from /lib64/libnss_files.so.2...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. > Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 > Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. > Loaded symbols for /usr/lib64/sasl2/libplain.so.2 > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] ># 0=C2=A0 NdbTransaction::execute (this=3D0x15, ># aTypeOfExec=3DNdbTransaction::Rollback, > =C2=A0=C2=A0=C2=A0 abortOption=3DNdbOperation::DefaultAbortOption, = forceSend=3D0) > =C2=A0=C2=A0=C2=A0 at NdbTransaction.cpp:278 > 278=C2=A0=C2=A0=C2=A0=C2=A0 NdbTransaction.cpp: No such file or = directory. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in NdbTransaction.cpp > (gdb) thr apply all bt > > Thread 9 (process 12305): ># 0=C2=A0 0x000000370e8077e5 in pthread_join () from = /lib64/libpthread.so.0 ># 1=C2=A0 0x000000000059affb in ldap_pvt_thread_join (thread=3D1107417408, > =C2=A0=C2=A0=C2=A0 thread_return=3D0x0) at thr_posix.c:197 ># 2=C2=A0 0x00000000004ba2a8 in slapd_daemon () at daemon.c:2835 ># 3=C2=A0 0x000000000049bfad in main (argc=3D2, argv=3D0x7fff78fd91e8) at ># main.c:950 > Current language:=C2=A0 auto; currently c++ > > Thread 8 (process 12307): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b3ff0 in TransporterFacade::threadMainReceive ># (this=3D0xc7a6530) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b4049 in runReceiveResponse_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterFacade.cpp:564 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc581620) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 7 (process 12308): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > ---Type <return> to continue, or q <return> to quit--- > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b2d0f in TransporterFacade::threadMainSend ># (this=3D0xc7a6530) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b2d89 in runSendRequest_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterFacade.cpp:529 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc588670) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 6 (process 12309): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006b9740 in ClusterMgr::threadMain (this=3D0xc7b8ce0) > =C2=A0=C2=A0=C2=A0 at = ../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006b98d9 in runClusterMgr_C (me=3D0x0) at = ClusterMgr.cpp:50 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc5888b0) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 5 (process 12310): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x000000000068a73b in my_sleep (m_seconds=3D<value optimized = out>) > ---Type <return> to continue, or q <return> to quit--- > =C2=A0=C2=A0=C2=A0 at my_sleep.c:34 ># 2=C2=A0 0x00000000006c8738 in TransporterRegistry::start_clients_thread = ( > =C2=A0=C2=A0=C2=A0 this=3D0xc580c70) at > ../../../../../storage/ndb/include/portlib/NdbSleep.h:31 ># 3=C2=A0 0x00000000006c89e9 in run_start_clients_C (me=3D0x0) > =C2=A0=C2=A0=C2=A0 at TransporterRegistry.cpp:1422 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc588a40) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 4 (process 12311): ># 0=C2=A0 0x000000370e0cced2 in select () from /lib64/libc.so.6 ># 1=C2=A0 0x00000000006a82d6 in SocketServer::doAccept (this=3D0xc7b8bd0) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:189 ># 2=C2=A0 0x00000000006a8612 in SocketServer::doRun (this=3D0xc7b8bd0) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:279 ># 3=C2=A0 0x00000000006a8639 in socketServerThread_C (_ss=3D0x1) > =C2=A0=C2=A0=C2=A0 at SocketServer.cpp:231 ># 4=C2=A0 0x00000000006a35de in ndb_thread_wrapper (_ss=3D0xc581710) at ># NdbThread.c:147 5=C2=A0 0x000000370e8064a7 in start_thread () from ># /lib64/libpthread.so.0 6=C2=A0 0x000000370e0d3c2d in clone () from ># /lib64/libc.so.6 > > Thread 3 (process 12312): ># 0=C2=A0 0x000000370e0d4018 in epoll_wait () from /lib64/libc.so.6 > ---Type <return> to continue, or q <return> to quit--- ># 1=C2=A0 0x00000000004b9559 in slapd_daemon_task (ptr=3D0x0) at = daemon.c:2460 ># 2=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 3=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > > Thread 2 (process 12314): ># 0=C2=A0 0x000000370e80ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > =C2=A0=C2=A0 from /lib64/libpthread.so.0 ># 1=C2=A0 0x000000000059b0a3 in ldap_pvt_thread_cond_wait = (cond=3D0xc538bc0, > =C2=A0=C2=A0=C2=A0 mutex=3D0xc538b98) at thr_posix.c:277 ># 2=C2=A0 0x0000000000599b63 in ldap_int_thread_pool_wrapper = (xpool=3D0xc538b90) > =C2=A0=C2=A0=C2=A0 at tpool.c:672 ># 3=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 4=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > > Thread 1 (process 12313): ># 0=C2=A0 NdbTransaction::execute (this=3D0x15, ># aTypeOfExec=3DNdbTransaction::Rollback, > =C2=A0=C2=A0=C2=A0 abortOption=3DNdbOperation::DefaultAbortOption, = forceSend=3D0) > =C2=A0=C2=A0=C2=A0 at NdbTransaction.cpp:278 ># 1=C2=A0 0x0000000000561195 in NdbTransaction::execute (this=3D0x15, > =C2=A0=C2=A0=C2=A0 execType=3DRollback, abortOption=3DDefaultAbortOption, = force=3D0) > =C2=A0=C2=A0=C2=A0 at = /usr/include/mysql/storage/ndb/ndbapi/NdbTransaction.hpp:343 ># 2=C2=A0 0x0000000000575926 in ndb_back_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) > =C2=A0=C2=A0=C2=A0 at add.cpp:336 > ---Type <return> to continue, or q <return> to quit--- ># 3=C2=A0 0x00000000004c6489 in fe_op_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) at ># add.c:334 4=C2=A0 0x00000000004c5e13 in do_add (op=3D0xc58c5d0, = rs=3D0x4283ec00) ># at add.c:194 5=C2=A0 0x00000000004bd06a in connection_operation ># (ctx=3D0x4283ed50, > =C2=A0=C2=A0=C2=A0 arg_v=3D0xc58c5d0) at connection.c:1123 ># 6=C2=A0 0x00000000004bd5ef in connection_read_thread (ctx=3D0x4283ed50, ># argv=3D0xd) > =C2=A0=C2=A0=C2=A0 at connection.c:1259 ># 7=C2=A0 0x0000000000599c01 in ldap_int_thread_pool_wrapper = (xpool=3D0xc538b90) > =C2=A0=C2=A0=C2=A0 at tpool.c:685 ># 8=C2=A0 0x000000370e8064a7 in start_thread () from = /lib64/libpthread.so.0 ># 9=C2=A0 0x000000370e0d3c2d in clone () from /lib64/libc.so.6 > (gdb) > > > > > On Tue, Dec 15, 2009 at 4:01 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: > > --On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: > > > > ># 0=3DC2=3DA0 0x000000000066f891 in ?? () > (gdb) > > > > So where's the thr apply all bt command inside gdb? =C2=A0You've just = loaded > > > Please provide the backtrace as noted if you want this to be further > investigated. =C2=A0Thanks! > > Again, after you run: > > gdb </slapd> <core> > > You then need to run: > > thr apply all bt > > To get a backtrace of all threads, and then submit that to the ITS. > > > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =C2=A0the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6431) LDAP Server disabled
by yimnara＠khaouchuly.com 14 Dec '09

14 Dec '09

Full_Name: Yim Nara Version: 2.1.0 OS: Window 2003 server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.248.180.59) LDAP server Disabled Tue 2009-12-15 10:14:45: [LDAP] Error adding 'MDaemon(a)khaouchuly.com' to LDAP address book. Tue 2009-12-15 10:14:45: [LDAP] Error 1: Operations error. Tue 2009-12-15 10:14:45: [LDAP] 0 address records exported, 0 address records already existed, 41 errors.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 14 Dec '09

14 Dec '09

--On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: >># 0=C2=A0 0x000000000066f891 in ?? () >> (gdb) > > So where's the thr apply all bt command inside gdb? You've just loaded Please provide the backtrace as noted if you want this to be further investigated. Thanks! Again, after you run: gdb </slapd> <core> You then need to run: thr apply all bt To get a backtrace of all threads, and then submit that to the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 13 Dec '09

13 Dec '09

Now it is OK. Build was successful and slapd is working fine. No more delays on start of TLS/SSL queries. Thanks Pavel

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 12 Dec '09

12 Dec '09

--On Saturday, December 12, 2009 1:16 PM +0330 afshin afzali=20 <a.afzali2003(a)gmail.com> wrote: > Hi, > It is makes no difference except that the 'Bus error' replaced with > 'Segmentation fault'. Also I've used the 'make clean' to cleanup my > installation. Any suggestion ? > > Regards, > =C2=A0 > > > [root@dc1 libexec]# gdb --core=3Dcore.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.=C2=A0 Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] ># 0=C2=A0 0x000000000066f891 in ?? () > (gdb) So where's the thr apply all bt command inside gdb? You've just loaded the = core, you haven't asked for any information. Also, keep replies to the bug tracker (i.e., CC it as well) if you want=20 help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Friday, December 11, 2009 9:22 PM +0000 pali(a)tmapy.cz wrote: > > --=-NIKZplg5L6FNssI2Xw1S > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Please re-sync RE24. There was missed commit sync'd in tonight. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 11 Dec '09

11 Dec '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Thread 1 (Thread 20774): > OK. The patch for #6419 that was backported from HEAD needs some additional > stuff that isn't yet in RE24. > Fixed now in RE24, closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 11 Dec '09

11 Dec '09

michael(a)stroeder.com wrote: > Thread 1 (Thread 20774): > #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 > #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 > #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, > bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 > #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at > syncrepl.c:4582 > #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at > syncrepl.c:4748 > #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 > #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, > at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 > #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, > rs=<value optimized out>, parent=<value optimized out>, > c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) > at bconfig.c:6139 > #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, > cr=<value optimized out>) at bconfig.c:6527 > #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) > at backend.c:224 > #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 > #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947 OK. The patch for #6419 that was backported from HEAD needs some additional stuff that isn't yet in RE24. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 11 Dec '09

11 Dec '09

Thread 1 (Thread 20774): #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at syncrepl.c:4582 #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at syncrepl.c:4748 #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, rs=<value optimized out>, parent=<value optimized out>, c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) at bconfig.c:6139 #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, cr=<value optimized out>) at bconfig.c:6527 #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) at backend.c:224 #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947

1 0

(ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 11 Dec '09

11 Dec '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.120.34) >>>>> Starting test017-syncreplication-refresh for bdb... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9012... ./scripts/test017-syncreplication-refresh: line 86: 20774 Aborted (core dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 Using ldapsearch to check that consumer slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test017-syncreplication-refresh: line 102: kill: (20774) - No such process >>>>> ./scripts/test017-syncreplication-refresh failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

--=-NIKZplg5L6FNssI2Xw1S Content-Type: text/plain Content-Transfer-Encoding: 7bit It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Pavel --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.conf" Content-Type: text/plain; name="slapd.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap24/schema/corba.schema include /etc/openldap24/schema/core.schema include /etc/openldap24/schema/cosine.schema include /etc/openldap24/schema/duaconf.schema include /etc/openldap24/schema/dyngroup.schema include /etc/openldap24/schema/inetorgperson.schema include /etc/openldap24/schema/java.schema include /etc/openldap24/schema/misc.schema include /etc/openldap24/schema/nis.schema include /etc/openldap24/schema/openldap.schema include /etc/openldap24/schema/ppolicy.schema include /etc/openldap24/schema/collective.schema include /etc/openldap24/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap24/slapd.pid argsfile /var/run/openldap24/slapd.args # Load dynamic backend modules: # modulepath /usr/lib/openldap24 # or /usr/lib64/openldap24 # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCACertificateFile /etc/pki/tls/cacert.pem # TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateFile /etc/pki/tls/certs/ldap3.ldapnet.tmapy.cz-cert.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap3.ldapnet.tmapy.cz-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # Define global ACLs to disable default read access and provide default # behaviour for samba/pam use include /etc/openldap24/slapd.access.conf # Provide write access to replicators, and cover access to any other # attributes (default anonymous read access may be undesirable) access to dn.subtree="dc=tmapy,dc=cz" by group="cn=Replicator,ou=Group,dc=tmapy,dc=cz" write by users read by anonymous read # loglevel <integer> # Specify the level at which debugging statements and # operation statistics should be syslogged (currently # 1 trace function calls # 2 debug packet handling # 4 heavy trace debugging # 8 connection management # 16 print out packets sent and received # 32 search filter processing # 64 configuration file processing # 128 access control list processing # 256 stats log # connections/operations/results # 512 stats log entries sent # 1024 print communication with shell # backends # 2048 entry parsing # 1 + 2 + 8 + 16 + 32 + 64 + 128 + 256 # loglevel 507 # 16 + 256 # loglevel 272 # 8 + 16 + 128 + 256 # loglevel 408 # 16 + 128 + 256 # loglevel 400 # 2 + 8 + 64 + 256 # loglevel 330 # 8 + 128 # loglevel 136 # 128 + 256 # loglevel 384 # loglevel 128 loglevel 0 ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=tmapy,dc=cz" checkpoint 1024 15 rootdn "cn=Manager,dc=tmapy,dc=cz" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret rootpw heslo # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap24/tmapy.cz # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN,entryUUID eq # Replicas of this database #replogfile /var/lib/ldap24/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # enable monitoring # database monitor # # # allow onlu rootdn to read the monitor # access to * # by dn.exact="cn=Manager,dc=tmapy,dc=cz" read # by * none # syncrepl directives ServerID 11 syncrepl rid=001 provider=ldap://ldap1.ldapnet.tmapy.cz:389 starttls=yes bindmethod=simple binddn="cn=Manager,dc=tmapy,dc=cz" credentials=heslo searchbase="dc=tmapy,dc=cz" schemachecking=on type=refreshAndPersist retry="5 5 300 5" timeout=1 --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.access.conf" Content-Type: text/plain; name="slapd.access.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # This configuration file contains default ACLs that attempt to cater # to most setups, specifically unix authentication, samba-s ldapsam backend # and allowing users to have a shared address book # If these ACLs don-t meet your needs, please do not modify the file in-place, # but rather make a copy, and change the include directive in slapd.conf # This file is *not* marked as noreplace, so it will be replaced during an # upgrade, this is done so that we can ensure that the ACLs are in sync with # the schema files they require. # The root DIT should be accessible to all clients access to dn.exact="" by * read # So should the schema access to dn.subtree="cn=Subschema" by * read # Generic ACLs # These ACLs should work well for any domain-based (ie dc=,dc=) suffix, # but need adjustment and testing for any other suffix # Note that these ACLs allow anonymous read access to most non-password # attributes, you may want to prevent leakage of this information by # removing the "by anonymous read" lines # Regex-based ACLs also impose a performance penalty, replace # for example dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" with # dn.subtree="ou=People,dc=example,dc=com" and all $2-s with dc=example,dc=com # if you need the extra performance # Protect passwords, using a regex so we can have generic accounts with # write access # Openldap will not authenticate against non-userPassword attributes # but we would have to duplicate most rules ... access to dn.regex="^([^,]*,)?ou=[^,]+,(dc=[^,]+(,dc=[^,]+)*)$" attrs=sambaLMPassword,sambaNTPassword,userPassword,sambaPasswordHistory,sambaPwdLastSet,shadowLastChange,shadowMax by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by anonymous auth by * none # ACL allowing samba domain controllers to write their domain info access to dn.regex="^sambaDomainName=([^,]+),(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaDomain,uidNumber,gidNumber by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # ACL allowing samba domain controllers to add user accounts access to dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # allow users to modify their own "address book" entries: access to dn.regex="([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=inetOrgPerson,mail by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create groups and group mappings access to dn.regex="^([^,]+,)?ou=Group,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixGroup,sambaGroupMapping by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create machine accounts access to dn.regex="^([^,]+,)?ou=Hosts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,inetOrgperson,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba to create idmap entries access to dn.regex="^([^,]+,)?ou=Idmap,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaIdmapEntry by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow users in the domain to add entries to the "global address book": # For use with Evolution, the attrs list could be modified to be: # attrs=children,entry,inetOrgPerson,evolutionperson,calEntry # if evolutionperson.schema and calendar.schema are available access to dn.regex="^([^,]+,)?ou=Contacts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=children,entry,inetOrgPerson by dn.sub,expand="ou=People,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read --=-NIKZplg5L6FNssI2Xw1S--

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Friday, December 11, 2009 4:05 PM +0000 pali(a)tmapy.cz wrote: > How can I download this particular revision? > > I'm not familiar with CVS > > I've found this: > http://www.openldap.org/software/repo.html#AnonCVS > > I've tried this > > CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" > cvs login > cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap > > but after build I cannot start it, it is crashing > > [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test > -d1 Please supply your configuration file that is causing slapd to assert. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6429) New mirror
by mirror＠artfiles.org 11 Dec '09

11 Dec '09

Full_Name: Artfiles New Media GmbH Version: OS: URL: Submission from: (NULL) (80.252.98.63) Hello, here are the facts about our mirror: * URL of mirror: http://artfiles.org/openldap.org * Hosting institution, country and city where the mirror is located: Artfiles New Media GmbH, Hamburg, Germany * Contact email address: mirror(a)artfiles.org * Update frequency: daily With best regards Artfiles New Media GmbH Andreas Worbs

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

How can I download this particular revision? I'm not familiar with CVS I've found this: http://www.openldap.org/software/repo.html#AnonCVS I've tried this CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" cvs login cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap but after build I cannot start it, it is crashing [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test -d1 finishes with this: oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Aborted or with LANG=cs_CZ.UTF-8 oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) similar is slapd [root@ldap3 ~]# slapd24 -f /etc/openldap24/slapd.conf -d 1 slapd24 startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}corba" config_build_entry: "cn={1}core" config_build_entry: "cn={2}cosine" config_build_entry: "cn={3}duaconf" config_build_entry: "cn={4}dyngroup" config_build_entry: "cn={5}inetorgperson" config_build_entry: "cn={6}java" config_build_entry: "cn={7}misc" config_build_entry: "cn={8}nis" config_build_entry: "cn={9}openldap" config_build_entry: "cn={10}ppolicy" config_build_entry: "cn={11}collective" config_build_entry: "cn={12}samba" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" slapd24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) I don't use cn=config, I have only slapd.conf. Is it the reason? Pavel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 11 Dec '09

11 Dec '09

On Thu, Dec 10, 2009 at 08:21:20AM -0800, Quanah Gibson-Mount wrote: >Well, now 2.4.20 is current (just to note). Right. I'm now running this version. The results below are with 2.4.20, and not 2.4.19. >What we'll need for resolving your issue is: > >(a) Your configuration files (minus passwords) # egrep -v '^#|^$' etc/openldap/slapd.conf TLSCertificateFile <removed>.crt TLSCertificateKeyFile <removed>.key TLSCACertificateFile <removed>.ca include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/nis.schema include /usr/local/ldap/etc/openldap/schema/qmail.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema include /usr/local/ldap/etc/openldap/schema/mod_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/monsternett_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/sql_user.schema include /usr/local/ldap/etc/openldap/schema/using_space.schema pidfile /usr/local/ldap/var/run/slapd/slapd.pid argsfile /usr/local/ldap/var/run/slapd/slapd.args loglevel stats modulepath /usr/local/ldap/lib moduleload back_hdb sizelimit 99999 tool-threads 8 threads 16 concurrency 32 backend hdb database hdb suffix "dc=<removed>" directory "/usr/local/ldap/var/openldap-data" cachesize 60000 dbconfig set_cachesize 0 52428800 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectclass,sn eq index cn,uniqueMember,memberUid,uidNumber,gidNumber pres,eq index uid,mail,associatedDomain,mailAlternateAddress,apacheServerName,apacheServerAlias,apacheSuexecUid pres,eq,sub lastmod on checkpoint 512 30 access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=<removed>" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=<removed>" write by * read >(b) A backtrace from gdb of a crash. Since this is a *live* server, I don't want to run it through gdb if I don't have to. Also, the server doesn't really crash, it just hangs, using 100% of one CPU core. We currently have a script that checks if ldapsearch succeeds, and if not, it restarts slapd. AFAIK, if we would have done this via gdb directly, the ports would still be open, and slapd wouldn't be able to start, which means I would have to sit there for an hour to quickly be able to run a backtrace, so slapd could be restarted instantly :) Anyway, instead, I made it dump a core (by sending killall -11 slapd in my script). I hope this is sufficient. --- gdb core bt start --- (gdb) thread apply all bt Thread 18 (process 7691): #0 0x00007ff212f77b78 in epoll_wait () from /lib/libc.so.6 #1 0x000000000041c618 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2465 #2 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007ff212f775ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 17 (process 7692): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x410f6670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x2732490, rs=0x41277ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x2732490, rs=0x41277ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x2732490, rs=0x41277ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x2732490, rs=0x41277ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41277df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41277df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 16 (process 7694): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x418f7670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x285ba50, rs=0x41a78ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x285ba50, rs=0x41a78ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x285ba50, rs=0x41a78ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x285ba50, rs=0x41a78ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41a78df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41a78df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 15 (process 7695): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x42947670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e40163b0, rs=0x42ac8ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x42ac8df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x42ac8df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 14 (process 7699): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43148670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42babf0, rs=0x432c9ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x432c9df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x432c9df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 13 (process 7700): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43949670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x16e57b0, rs=0x43acaca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x16e57b0, rs=0x43acaca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x16e57b0, rs=0x43acaca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x16e57b0, rs=0x43acaca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x43acadf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x43acadf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 12 (process 7715): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4414a670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e7260, rs=0x442cbca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x442cbdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x442cbdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 11 (process 7864): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4494b670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x1b731b0, rs=0x44accca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x1b731b0, rs=0x44accca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x1b731b0, rs=0x44accca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x1b731b0, rs=0x44accca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x44accdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x44accdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 10 (process 8395): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4514c670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e4038380, rs=0x452cdca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x452cddf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x452cddf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 9 (process 8808): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4594d670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1fcac89e0, rs=0x45aceca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x45acedf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x45acedf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 8 (process 9706): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4614e670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414b4d0, rs=0x462cfca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414b4d0, rs=0x462cfca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414b4d0, rs=0x462cfca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414b4d0, rs=0x462cfca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x462cfdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x462cfdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 7 (process 10771): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4694f670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c100, rs=0x46ad0ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c100, rs=0x46ad0ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c100, rs=0x46ad0ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c100, rs=0x46ad0ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x46ad0df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x46ad0df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 6 (process 11742): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47150670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e8640, rs=0x472d1ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x472d1df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x472d1df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 5 (process 11743): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47951670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c610, rs=0x47ad2ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c610, rs=0x47ad2ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c610, rs=0x47ad2ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c610, rs=0x47ad2ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x47ad2df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x47ad2df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 4 (process 18180): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48152670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x4376ee0, rs=0x482d3ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x482d3df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x482d3df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (process 18190): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48953670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42d4510, rs=0x48ad4ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x48ad4df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x48ad4df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (process 18200): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x49154670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e78e0, rs=0x492d5ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x492d5df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x492d5df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (process 7690): #0 0x00007ff214c50715 in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000419c4c in slapd_daemon () at daemon.c:2840 #2 0x0000000000407d8a in main (argc=7, argv=0x7fff1d3caa88) at main.c:961 --- gdb core bt end --- I guess the last part in the treads are caused by me sending a SIGSEGV, i.e. every thread was inside clone () after slapd started hanging? Well, I'll leave the analysis to the experts I think :-) -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 3:13 PM +0000 pavel.lisy(a)tmapy.cz wrote: > Today I've tried go back to 2.4.18 release and in the same configuration > there isn't this bug. > > So it is problem in 2.4.19 and 2.4.20. Please try CVS RE24, there's a fix to TLS in there that may be the cause. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 1:02 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi Quanah > > I did reconfigure with --enable-debug, but just could get this: To build with debugging symbols, you need to use a CFLAGS value of -g, like: CFLAGS="-g" ./configure <whatever options you use> make depend make make install DESTDIR=/my/path/to/install STRIP="" The STRIP="" ensures none of the debugging symbols inserted by gcc get stripped out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 10:44 AM +0100 Helge Milde <helge(a)monsternett.no> wrote: > I have now installed openldap 2.4.19 from source (default configuration > except for --enable-crypt=yes). > ># slapd -V > @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ > > But unfortunately, the bug is still there. Nothing has changed at all.. > It has crashed 10 times since I did the migration 10 hours ago. It > usually crashes 1-2 times at night, and 10-20 times during work hours > (when the servers have more load). Well, now 2.4.20 is current (just to note). What we'll need for resolving your issue is: (a) Your configuration files (minus passwords) (b) A backtrace from gdb of a crash. Make sure you build OpenLDAP with debugging symbols (using CFLAGS of -g) and when you run make install, make sure you use STRIP="", like: make install DESTDIR=/my/path/to/install STRIP="" Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pavel.lisy＠tmapy.cz 10 Dec '09

10 Dec '09

Today I've tried go back to 2.4.18 release and in the same configuration there isn't this bug. So it is problem in 2.4.19 and 2.4.20. Pavel

1 0

(ITS#6428) modification to global limits require a restart to take effect
by rhafer＠suse.de 10 Dec '09

10 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.231.132) Changes to the global limits in "olcDatabase=frontend,cn=config" don't take effect database until slapd is restarted. I am working on a fix.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 10 Dec '09

10 Dec '09

I have now installed openldap 2.4.19 from source (default configuration except for --enable-crypt=yes). # slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ But unfortunately, the bug is still there. Nothing has changed at all.. It has crashed 10 times since I did the migration 10 hours ago. It usually crashes 1-2 times at night, and 10-20 times during work hours (when the servers have more load). When I migrated, I recreated the database by typing: # oldbin/slapcat > db.ldif # newbin/slapadd < db.ldif # (under the new openldap/slapd user) So I can't imagine the database can be corrupt in any way, which I initially thought when I first sent this bug report. It still dies on the same queries as before, in the middle of iterating through ou=users,.. or ou=groups,.., which both have ~1.8k entries. These queries comes from proftpd, which does a "getent passwd" and "getent group" every time a customer logs in. I tried to reproduce this manually again, launching 8 processes, constantly querying ou=users and ou=groups, 2 using a unix socket locally and 6 using ldaps://hostname/ remotely, but it still won't break down when I do that. This causes *alot* more load than proftpd does, but the crashes seem to only happen "randomly". Any suggestions on what I can do to figure out this problem? The LDAP server is live and in use in two servers with 2-3k users, so I can't mess with it *too* much. On Fri, Oct 02, 2009 at 09:28:25PM +0000, quanah(a)zimbra.com wrote: >--On Friday, October 02, 2009 8:54 PM +0000 hyc(a)symas.com wrote: > > >> strace is useless. Use gdb and get a trace of all running threads when >> this occurs. >> >> http://www.openldap.org/faq/data/cache/59.html > > >You also need to test against a current release of OpenLDAP, like OpenLDAP >2.4.18. > >--Quanah > > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration > > -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 10 Dec '09

10 Dec '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> The problem is that back-relay presents slapo-rwm(3) an entry with both >> REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a >> consequence, the entry is released (namely, freed) before it is returned >> by the frontend. As far as I understand, the two flags should be mutually >> exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is >> supposed to be a copy of an entry that may need to be released, or an >> entry created from scratch and thus not stored anywhere. I have a quick >> fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when >> REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in >> tracking where the issue occurs. Unless I track it, I'll commit the quick >> fix. > > We already have ITS#5340 for issues with these flags... Right. I asked him to open an ITS because I though the error was in slapo-rwm; my first fix was in that area. Soon after, I realized the error was in slapo-dynlist, related to ITS#5340. p.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

I wrote: > Otherwise it should use rs_ensure_entry_modifiable(). Currently > it's still wrong: Discards the old entry without obeying sr_flags. Unless dynlist_sc_save_entry() handles it, I haven't yet tried to figure out the state when it is called. But it looks wrong: it saves and clears rs->sr_entry without saving/clearing (rs->sr_flags & REP_ENTRY_MASK). Here is a draft for what rs_ensure_entry_modifiable() usage is supposed to look like, though I haven't tested it well and I'm going home now. I'm unsure of the translucent code. rwm looks a bit weird, but that's mostly to assert that some functions that receive rs won't modify it. I haven't touched dynlist, don't know what entry ownership is there. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft.diff -- Hallvard

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

ldapwhoami has the same behaviour [root@ldap1 ~]# time ldapwhoami -xZZh ldap1.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m4.835s user 0m0.021s sys 0m0.012s [root@ldap1 ~]# time ldapwhoami -xZZh ldap2.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m0.042s user 0m0.023s sys 0m0.013s

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

I've been trying to do too much at once in this ITS. My macros can be simplified to at least use functions for the exposed API. Since we now have commits related to this (ITS#6423), there's no reason not to use a common function for the new commits, instead of trying to get it right each time. I've committed a variant of this, so far unused: slap.h REP_ENTRY_MUSTFLUSH, result.c rs_replace_entry(), rs_ensure_entry_modifiable() When an overlay can wants to update rs->sr_entry it can use these. Exception: Some code may want to temporarily replace the entry and later restore it. That should be by a push/pop of sr_entry and (sr_flags & REP_ENTRY_MASK) together. That is, push: <save rs->sr_entry and rs->rs_flags>; rs->sr_flags &= ~REP_ENTRY_MASK; rs->sr_entry = new entry; rs->sr_flags |= new entryflags, if any; pop: rs_replace_entry(op, rs, on, <old entry>); rs->sr_flags |= (<saved flags> & REP_ENTRY_MASK); Maybe this is what dynlist.c:dynlist_prepare_entry() wants to do? I don't see why else it waits to the end of the function to set rs->sr_flags/sr_entry to the _new_ flags and entry. Otherwise it should use rs_ensure_entry_modifiable(). Currently it's still wrong: Discards the old entry without obeying sr_flags. I don't know what overlay to pass to entry_modifiable though. -- Hallvard

1 0

(ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

Full_Name: Pavel Lisy Version: 2.4.19 or 2.4.20 OS: linux - CentOS4/5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.132.159.239) I have my rpm built on source from Fedora 12. ldapsearch have delay on start, slapd is heavy loaded (up to 90% proc) on the same machine over TLS/SSL only (numbers below) [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m2.610s user 0m0.029s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-z.log 2>&1 real 0m2.700s user 0m0.026s sys 0m0.013s [root@ldap1 ~]# time ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search.log 2>&1 real 0m0.021s user 0m0.010s sys 0m0.008s [root@ldap1 ~]# time ldapsearch24 -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2.log 2>&1 real 0m0.027s user 0m0.009s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-z.log 2>&1 real 0m0.070s user 0m0.028s sys 0m0.020s [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-zz.log 2>&1 real 0m0.048s user 0m0.026s sys 0m0.017s This means: delay is there when I query from the same machine over TLS/SSL, not across machines. I suppose it is bug but I cannot find where it is. When I've changed in slapd.conf "loglevel 0" to "loglevel 1" delay is gone [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m0.315s user 0m0.030s sys 0m0.025s When I start ldapsearch24 through strace delay was in part with stars: ------------ cut --------------- munmap(0x2b2edf8b1000, 4096) = 0 brk(0x15747000) = 0x15747000 write(2, "TLS trace: SSL_connect:before/co"..., 53TLS trace: SSL_connect:before/connect initialization ) = 53 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4 fstat(4, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0 poll([{fd=4, events=POLLIN}], 1, 10) = 1 ([{fd=4, revents=POLLIN}]) read(4, "D~j?,\274k\310mx\336\t\17k\207Q\322\0369SDB\260\241bd6[R}6\201"..., 48) = 48 close(4) = 0 getuid() = 0 write(3, "\200t\1\3\1\0K\0\0\0 \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 118 *********************************************** DELAY 2s HERE *********************************************** ) = 118 write(2, "TLS trace: SSL_connect:SSLv2/v3 "..., 53TLS trace: SSL_connect:SSLv2/v3 write client hello A ) = 53 read(3, "\26\3\1\0J\2\0", 7) = 7 read(3, "\0F\3\1K \10\5\232\0\3\2\354\235\351\233\276\31\242\302\217\214\35\32\370cGH\342\277\7;"..., 72) = 7 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 49TLS trace: SSL_connect:SSLv3 read server hello A ) = 49 read(3, "\26\3\1\6\303", 5) = 5 read(3, "\v\0\6\277\0\6\274\0\2\2500\202\2\2440\202\2\r\2\3\20\0\0010\r\6\t*\206H\206\367"..., 1731) = 1731 write(2, "TLS certificate verification: de"..., 191TLS certificate verification: depth: 1, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS certificate verification: de"..., 146TLS certificate verification: depth: 0, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 55TLS trace: SSL_connect:SSLv3 read server certificate A ) = 55 read(3, "\26\3\1\0\4", 5) = 5 read(3, "\16\0\0\0", 4) = 4 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 48TLS trace: SSL_connect:SSLv3 read server done A ) = 48 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 57TLS trace: SSL_connect:SSLv3 write client key exchange A ) = 57 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 56TLS trace: SSL_connect:SSLv3 write change cipher spec A ) = 56 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 46TLS trace: SSL_connect:SSLv3 write finished A ) = 46 write(3, "\26\3\1\0\206\20\0\0\202\0\200\202\365\233\356\r\26\27\330\251\17\330\331\3362\23\231\211`\\\262\32 write(2, "TLS trace: SSL_connect:SSLv3 flu"..., 40TLS trace: SSL_connect:SSLv3 flush data ) = 40 read(3, "\24\3\1\0\1", 5) = 5 read(3, "\1", 1) = 1 read(3, "\26\3\1\0000", 5) = 5 read(3, "\353;\20\337y\307&\331\207@#\265\314\267\240\244\177P\223\216\221\216!\"G \27\265R\3078l"..., 48) = write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 45TLS trace: SSL_connect:SSLv3 read finished A ) = 45 write(2, "ldap_sasl_bind\n", 15ldap_sasl_bind ) = 15 write(2, "ldap_send_initial_request\n", 26ldap_send_initial_request ) = 26 write(2, "ldap_send_server_request\n", 25ldap_send_server_request ) = 25 write(2, "ber_scanf fmt ({it) ber:\n", 25ber_scanf fmt ({it) ber: ) = 25 write(2, "ber_scanf fmt ({i) ber:\n", 24ber_scanf fmt ({i) ber: ) = 24 write(2, "ber_flush2: 44 bytes to sd 3\n", 29ber_flush2: 44 bytes to sd 3 ) = 29 write(3, "\27\3\1\0 \217\244v\31\275A\232=\300\357\330\312*\316)\311\23\242\260\350n\353\373\221\204B\v"..., write(2, "ldap_result ld 0x156816c0 msgid "..., 34ldap_result ld 0x156816c0 msgid 2 ) = 34 write(2, "wait4msg ld 0x156816c0 msgid 2 ("..., 50wait4msg ld 0x156816c0 msgid 2 (infinite timeout) ) = 50 write(2, "wait4msg continue ld 0x156816c0 "..., 46wait4msg continue ld 0x156816c0 msgid 2 all 1 ) = 46 write(2, "** ld 0x156816c0 Connections:\n", 30** ld 0x156816c0 Connections: ) = 30 write(2, "* host: ldap1.ldapnet.tmapy.cz "..., 53* host: ldap1.ldapnet.tmapy.cz port: 389 (default) ) = 53 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected ) = 31 write(2, " last used: Wed Dec 9 21:26:51"..., 39 last used: Wed Dec 9 21:26:51 2009 ------------ cut --------------- How can I debug it more? I will send more details if you want.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 09 Dec '09

09 Dec '09

--On Wednesday, December 09, 2009 12:56 PM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: 2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > Bus error > [root@dc1 openldap]# Please provide a GDB backtrace of the crash with full debugging symbols. Thanks --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

hyc(a)symas.com writes: > We already have ITS#5340 for issues with these flags... I'll follow up there. Looking again, I think it can be simplified. -- Hallvard

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 09 Dec '09

09 Dec '09

On 12/08/2009 07:31 PM, masarati(a)aero.polimi.it wrote: > Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 > > Please test and report. Thanks, p. Thanks! At least the dynlist overlay works fine now. (Couldn't test slapo-collect and slapo-overlay.) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria

1 0

(ITS#6426) slapd crash with 'Bus error'
by a.afzali2003＠gmail.com 09 Dec '09

09 Dec '09

Full_Name: afshin afzali Version: 2.4.19 OS: CentOS 5 - 64Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.182.20.153) I use "Apache Directory Studio" to manage my directory service. Randomly I used an invalid attribute ( cn ) to create an country object. Regards, -- afshin >>> slap_listener(ldap:///) connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 42 contents: op tag 0x60, time 1260363040 ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=root,dc=callee,dc=ir>, <cn=root,dc=callee,dc=ir> do_bind: version=3 dn="cn=root,dc=callee,dc=ir" method=128 ==> ndb_back_bind: dn: cn=root,dc=callee,dc=ir do_bind: v3 bind: "cn=root,dc=callee,dc=ir" to "cn=root,dc=callee,dc=ir" send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 56 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 3 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: subschemaSubentry => send_search_entry: conn 0 dn="" ber_flush2: 68 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 96 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=2 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 0 0 0 ber_scanf fmt ({mm}) ber: filter: (objectClass=subschema) ber_scanf fmt ({M}}) ber: attrs: createTimestamp modifyTimestamp => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 127 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 174 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=3 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 0 0 0 ber_scanf fmt ({mm}) ber: filter: (objectClass=subschema) ber_scanf fmt ({M}}) ber: attrs: objectClasses attributeTypes ldapSyntaxes matchingRules matchingRuleUse createTimestamp modifyTimestamp => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 71646 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=3 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=4 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 221 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=4 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension supportedControl supportedFeatures vendorName vendorVersion + objectClass => send_search_entry: conn 0 dn="" ber_flush2: 797 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=4 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=5 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 40 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=5 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: * => send_search_entry: conn 0 dn="" ber_flush2: 70 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=6 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 79 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=6 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 104 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=6 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=7 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 76 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=7 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnPrettyNormal: <cn=config>, <cn=config> SRCH "cn=config" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass ==> limits_get: conn=0 op=7 self="cn=root,dc=callee,dc=ir" this="cn=config" send_ldap_result: conn=0 op=7 p=3 send_ldap_result: err=32 matched="" text="" send_ldap_response: msgid=8 tag=101 err=32 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 82 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=8 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=callee,dc=ir> => ldap_bv2dn(dc=callee,dc=ir,0) <= ldap_bv2dn(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 <<< dnPrettyNormal: <dc=callee,dc=ir>, <dc=callee,dc=ir> SRCH "dc=callee,dc=ir" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> => send_search_entry: conn 0 dn="dc=callee,dc=ir" ber_flush2: 122 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=8 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=9 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 55 contents: op tag 0x63, time 1260363055 ber_get_next conn=0 op=9 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=callee,dc=ir> => ldap_bv2dn(dc=callee,dc=ir,0) <= ldap_bv2dn(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 <<< dnPrettyNormal: <dc=callee,dc=ir>, <dc=callee,dc=ir> SRCH "dc=callee,dc=ir" 0 3 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: * >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> => send_search_entry: conn 0 dn="dc=callee,dc=ir" ber_flush2: 138 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=9 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=10 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 95 contents: op tag 0x63, time 1260363086 ber_get_next conn=0 op=10 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir> => ldap_bv2dn(cn=myCountry,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=mycountry,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir>, <cn=mycountry,dc=callee,dc=ir> SRCH "cn=myCountry,dc=callee,dc=ir" 0 0 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass send_ldap_result: conn=0 op=10 p=3 send_ldap_result: err=32 matched="dc=callee,dc=ir" text="" send_ldap_response: msgid=11 tag=101 err=32 ber_flush2: 37 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 87 contents: op tag 0x68, time 1260363100 ber_get_next conn=0 op=11 do_add ber_scanf fmt ({m) ber: conn=0 op=11 do_add: dn (cn=myCountry,dc=callee,dc=ir) ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: >>> dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir> => ldap_bv2dn(cn=myCountry,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=mycountry,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir>, <cn=mycountry,dc=callee,dc=ir> ==> ndb_back_add: cn=myCountry,dc=callee,dc=ir oc_check_required entry (cn=myCountry,dc=callee,dc=ir), objectClass "country" Entry (cn=myCountry,dc=callee,dc=ir): object class 'country' requires attribute 'c' ndb_back_add: entry failed schema check: object class 'country' requires attribute 'c' (65) send_ldap_result: conn=0 op=11 p=3 send_ldap_result: err=65 matched="" text="object class 'country' requires attribute 'c'" send_ldap_response: msgid=12 tag=105 err=65 ber_flush2: 67 bytes to sd 13 Bus error [root@dc1 openldap]#

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 09 Dec '09

09 Dec '09

quanah(a)zimbra.com wrote: > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. A fix is in HEAD (it's been there for a while); please test. Thanks, p.

1 0

Re: (ITS#6037) errno in signal handlers
by hyc＠symas.com 08 Dec '09

08 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Signal handlers slapd/daemon.c:slap_sig_shutdown()/slap_sig_wake() need > to save/restore errno, since they call functions that can modify errno. > > And/or possibly they need sock_errno() - sock_errset() from ac/socket.h, > since they use tcp_write()? I don't know if that's safe inside signal > handlers, or if Windows itself saves/restores this code around signal > handlers. Windows doesn't really have signals in the first place. SIGTERM/SIGINT are simulated by the C runtime library, none of the other signals are really supported... All of the "support" is synchronous only - can only be invoked by raise(). I don't think there's any issue here. (An exception - I wrote a patch for the MSYS 1.11 runtime to propagate SIGINT/SIGTERM to other processes. The patch only works on win32, not win64 because I never got a decent win64 build environment working... But if you're using MSYS, it is possible to send these signals to a running slapd and have it shutdown cleanly. Otherwise, signals don't really exist for native Windows apps...) > slapd/main.c:wait4child() can loop forever after EINTR, since it checks > for errno even when the waitpid returns 0. I don't know if there is > a good reason it does that. Some of the commits have my name on them > but I think I copied it from elsewhere. > > > Anyway, I'm doing the minimal changes now: save/restore errno, and > set errno=0 in each loop iteration instead of before the loop. > Anyone with better ideas can take it from there. Good enough. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by hyc＠symas.com 08 Dec '09

08 Dec '09

masarati(a)aero.polimi.it wrote: > The problem is that back-relay presents slapo-rwm(3) an entry with both > REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a > consequence, the entry is released (namely, freed) before it is returned > by the frontend. As far as I understand, the two flags should be mutually > exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is > supposed to be a copy of an entry that may need to be released, or an > entry created from scratch and thus not stored anywhere. I have a quick > fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when > REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in > tracking where the issue occurs. Unless I track it, I'll commit the quick > fix. We already have ITS#5340 for issues with these flags... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldapsearch with delay (on the same machine over TLS/SSL only)
by Pavel Lisy 08 Dec '09

08 Dec '09

Hello I've found one problem I have latest openldap release 2.4.3 (but it is similar on former versions too). There is small delay (1-2s) on beginning when I query ldap server from the same machine over TLS or SSL. Without SSL is no delay. Is it bug or is it normal? How can I debug it more? QUERY with delay: from ldap1 to ldap1 (the same machine) [root@ldap1 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d QUERY without delay: from ldap1 to ldap1 (the same machine without TLS) [root@ldap1 ~]# ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap1 to ldap2 [root@ldap1 ~]# ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap2 to ldap1 [root@ldap2 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d I think my DNS/hosts settings are correct My testing environment: servers: ldap1.ldapnet.tmapy.cz ldap2.ldapnet.tmapy.cz ldap3.ldapnet.tmapy.cz from ldap1 config: slapd.conf TLSCACertificateFile /etc/pki/tls/cacert.pem TLSCertificateFile /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap1.ldapnet.tmapy.cz-key.pem [root@ldap1 ~]# hostname ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# grep ldap1 /etc/hosts 192.168.241.10 ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# ifconfig eth0 eth0 inet adr:192.168.241.10 Všesměr:192.168.241.255 Maska:255.255.255.0 [root@ldap1 ~]# grep ldap1 /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem Subject: C=CS, ST=Kraj kralovehradecky, O=T-MAPY spol. s r.o.,OU=ldapnet, CN=ldap1.ldapnet.tmapy.cz Pavel Lisy -- Pavel Lisy <pali(a)tmapy.cz>

3 4

Re: (ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

h.b.furuseth(a)usit.uio.no writes: > In syncrepl.c lines 1001-1010: Also in equivalent code around line 820. -- Hallvard

1 0

(ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.20 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In syncrepl.c lines 1001-1010: LDAPControl **next; rctrlp = ldap_control_find( LDAP_CONTROL_SYNC_DONE, rctrls, &next ); if ( next && ldap_control_find( LDAP_CONTROL_SYNC_DONE, next, NULL ) ) 'next' in the last line is uninitalized if 2nd line failed. Seen in testrun/srv2/valgrind.* with './run -b null test050' and and slapd under valgrind.

1 0

ITS#6423 slapo-collect & slapo-valsort could suffer from the same issue
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

This should now be fixed in HEAD, collect.c 1.17 <- 1.16 valsort.c 1.27 <- 1.26 please review and test. p.

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 Please test and report. Thanks, p.

1 0

(ITS#6424) slapd-meta pseudoroot* directives deprecated
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando The man page erroneously reports them. A fix is coming. See also ITS#6418. p.

1 0

ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

The problem is that back-relay presents slapo-rwm(3) an entry with both REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a consequence, the entry is released (namely, freed) before it is returned by the frontend. As far as I understand, the two flags should be mutually exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is supposed to be a copy of an entry that may need to be released, or an entry created from scratch and thus not stored anywhere. I have a quick fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in tracking where the issue occurs. Unless I track it, I'll commit the quick fix. p.

1 0

(ITS#6423) slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 08 Dec '09

08 Dec '09

Full_Name: Leo Bergolth Version: 2.4.20 OS: linux URL: http://leo.kloburg.at/tmp/dynlist-rwm.log Submission from: (NULL) (137.208.89.66) When using the relay backend, entries that have attributes expanded by the dynlist overlay are not shown in the virtual naming context. (Not even those attributes that are not created dynamically, only an empty dn is shown for those entries.) Example: # real naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu-wien,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: cn=dynlisttest,ou=LDAPgroups,dc=wu-wien,dc=ac,dc=at objectClass: wuDynGroupOfNames objectClass: groupOfURLs objectClass: top cn: dynlisttest memberURL: ldap:///dc=wu-wien,dc=ac,dc=at??sub?(&(objectclass=wuPerson)(uid=be rgolth*)) member: uid=bergolth,ou=users,dc=wu-wien,dc=ac,dc=at member: uid=bergolth2,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at -------------------- 8< -------------------- # virtual naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: -------------------- 8< -------------------- According to Pierangelo Maserati it seems to be a bug in slapo-rwm. http://thread.gmane.org/gmane.network.openldap.technical/207/focus=210 # dynlist config: -------------------- 8< -------------------- dn: olcOverlay={0}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}posixGroup labeledURI memberUid:uid olcDlAttrSet: {1}wuDynGroupOfNames memberURL member -------------------- 8< -------------------- # relay rwm config: -------------------- 8< -------------------- dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "dc=wu-wien,dc=ac,dc=at" -------------------- 8< -------------------- The debug output of the second ldapsearch can be found at the specified URL. Thanks, --leo

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 7:19 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi, > Thanks for your reply. After inspection in config.log, I found that ld > could not find libstdc++ although it there in /usr/lib and /usr/lib64. I > just add a symbolic link to libstdc++.so.6.0.8 then bingo! THE ISSUE HAS > RESOLVED > > Best Regards, I've closed this ITS based on the response. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 9:47 AM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: openldap-2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > > > Hi Guys, > As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel > package (there is mysql_config & ndbclient library), counfigure does not > locate ndbclient library. Also I've upgrade libtools! > > Best Regards, > -- Afshin > > > > [root@dc1 openldap-2.4.19]# mysql_config --libs > -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc > [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ > total 51780 > -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a > -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a > -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a > -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a > -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a > -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a > -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la > -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a > -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la > -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a > -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a > -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a > -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la > -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a > -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a > -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la > [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb > --disable-hdb > Configuring OpenLDAP 2.4.19-Release ... > checking for ndb_init in -lndbclient... no > configure: error: could not locate ndbclient library > [root@dc1 openldap-2.4.19]# And what does the config.log show for why this linking failed? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Dienstag 08 Dezember 2009 11:53:41 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > >>> ------------------------------------ > >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > >>> type="refreshAndPersist" starttls=critical bindmethod="simple" > >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > >>> ------------------------------------ > >>> > >>> Question is if this is a bug in the documentation or in the code. I > >>> think it's the latter. > >> > >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 > >> -> 1.509. Can you please test and let us know the result? > > > > It solves the problem only partially. It still doesn't work when using > > "ldaps://" uris AFAICS. > > The code was assuming that at least one of the other TLS config keywords > would also be used in these situations. Most of the time the slapd TLS > config would only be appropriate for server use, and would need to be > overridden when acting as a client. > > Anyway, this is now fixed in HEAD. Confirmed. -- Ralf

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by hyc＠symas.com 08 Dec '09

08 Dec '09

rhafer(a)suse.de wrote: > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: >>> ------------------------------------ >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" >>> type="refreshAndPersist" starttls=critical bindmethod="simple" >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" >>> ------------------------------------ >>> >>> Question is if this is a bug in the documentation or in the code. I think >>> it's the latter. >> >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> >> 1.509. Can you please test and let us know the result? > It solves the problem only partially. It still doesn't work when using > "ldaps://" uris AFAICS. The code was assuming that at least one of the other TLS config keywords would also be used in these situations. Most of the time the slapd TLS config would only be appropriate for server use, and would need to be overridden when acting as a client. Anyway, this is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6422) configure does not locate ndbclient library
by a.afzali2003＠gmail.com 08 Dec '09

08 Dec '09

Full_Name: afshin afzali Version: openldap-2.4.19 OS: CentOS 5 - 64Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.182.20.153) Hi Guys, As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel package (there is mysql_config & ndbclient library), counfigure does not locate ndbclient library. Also I've upgrade libtools! Best Regards, -- Afshin [root@dc1 openldap-2.4.19]# mysql_config --libs -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ total 51780 -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb --disable-hdb Configuring OpenLDAP 2.4.19-Release ... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking configure arguments... done checking for cc... cc checking for ar... ar checking for style of include used by make... GNU checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... none checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ranlib... ranlib checking for strip... strip checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... cat: ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool checking how to run the C preprocessor... cc -E checking whether we are using MS Visual C++... no checking for be_app in -lbe... no checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... (cached) none needed checking dependency style of cc... (cached) none checking for cc depend flag... -M checking for afopen in -ls... no checking for EBCDIC... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether termios.h defines TIOCGWINSZ... no checking whether sys/ioctl.h defines TIOCGWINSZ... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking arpa/nameser.h usability... yes checking arpa/nameser.h presence... yes checking for arpa/nameser.h... yes checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking bits/types.h usability... yes checking bits/types.h presence... yes checking for bits/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking crypt.h usability... yes checking crypt.h presence... yes checking for crypt.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking filio.h usability... no checking filio.h presence... no checking for filio.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking io.h usability... no checking io.h presence... no checking for io.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for memory.h... (cached) yes checking psap.h usability... no checking psap.h presence... no checking for psap.h... no checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking sgtty.h usability... yes checking sgtty.h presence... yes checking for sgtty.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking sys/fstyp.h usability... no checking sys/fstyp.h presence... no checking for sys/fstyp.h... no checking sys/errno.h usability... yes checking sys/errno.h presence... yes checking for sys/errno.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/privgrp.h usability... no checking sys/privgrp.h presence... no checking for sys/privgrp.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/stat.h... (cached) yes checking sys/syslog.h usability... yes checking sys/syslog.h presence... yes checking for sys/syslog.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/vmount.h usability... no checking sys/vmount.h presence... no checking for sys/vmount.h... no checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking for resolv.h... yes checking for netinet/tcp.h... yes checking for sys/ucred.h... no checking for sigaction... yes checking for sigset... yes checking for socket... yes checking for select... yes checking for sys/select.h... (cached) yes checking for sys/socket.h... (cached) yes checking types of arguments for select... int,fd_set *,struct timeval * checking for poll... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/epoll.h usability... yes checking sys/epoll.h presence... yes checking for sys/epoll.h... yes checking for epoll system call... yes checking sys/devpoll.h usability... no checking sys/devpoll.h presence... no checking for sys/devpoll.h... no checking declaration of sys_errlist... yes checking for strerror... yes checking for strerror_r... yes checking non-posix strerror_r... no checking for regex.h... yes checking for library containing regfree... none required checking for compatible POSIX regex... yes checking sys/uuid.h usability... no checking sys/uuid.h presence... no checking for sys/uuid.h... no checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for library containing uuid_generate... -luuid checking for library containing uuid_unparse_lower... none required checking for resolver link (default)... no checking for resolver link (-lresolv)... yes checking for hstrerror... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for gai_strerror... yes checking for inet_ntop... yes checking INET6_ADDRSTRLEN... yes checking struct sockaddr_storage... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... yes checking OpenSSL library version (CRL checking capability)... yes checking for _beginthread... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking POSIX thread version... 10 checking for LinuxThreads pthread.h... no checking for GNU Pth pthread.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... yes checking for sched_yield... yes checking for pthread_yield... yes checking for thr_yield... no checking for pthread_kill... yes checking for pthread_rwlock_destroy with <pthread.h>... yes checking for pthread_detach with <pthread.h>... yes checking for pthread_setconcurrency... yes checking for pthread_getconcurrency... yes checking for thr_setconcurrency... no checking for thr_getconcurrency... no checking for pthread_kill_other_threads_np... no checking for LinuxThreads implementation... no checking for LinuxThreads consistency... no checking if pthread_create() works... yes checking if select yields when using pthreads... yes checking for thread specific errno... yes checking for thread specific h_errno... yes checking for ctime_r... yes checking for gethostbyname_r... yes checking for gethostbyaddr_r... yes checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for openlog... yes checking for mysql_config... yes checking for NdbApi.hpp... yes checking for ndb_init in -lndbclient... no configure: error: could not locate ndbclient library [root@dc1 openldap-2.4.19]#

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > > ------------------------------------ > > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > > type="refreshAndPersist" starttls=critical bindmethod="simple" > > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > > ------------------------------------ > > > > Question is if this is a bug in the documentation or in the code. I think > > it's the latter. > > Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> > 1.509. Can you please test and let us know the result? It solves the problem only partially. It still doesn't work when using "ldaps://" uris AFAICS. regards, Ralf

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > This fix allows the overlay to use poorly formatted data > since we cannot prevent the user from using it. Which is what I suspect is a misfeature... > A better fix would be to intercept write operations that modify entries in > a manner that would trigger slapo-dynlist(5), and be picky about how URLs > are written. This would not fix existing databases, nor handle cases > where slapo-dynlist(5) is configured using slapd-config(5). Yesbut... LDAP URLs can come from many sources and be used in many contexts; I suppose this would in practice need to treat URL-valued attributes as if they had an URL syntax. I guess we could as an extension, turned on by default. > Or, we could simply become picky about how LDAP URIs are written in general. Yup. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> Well, the fact is that memberURL is stored in the data. As soon as we >> accept that value, we need to deal with it. The current behavior of >> slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be >> parsed). We should rather reject values like this when written in the >> database, but this would probably break other applications. So I >> believe the fix is better than silently ignoring these values. > > I disagree. Data validation in LDAP is generally the user's job, LDAP > syntaxes are very rough in that regard. > > If this is a fix to make dynlist compatible with the rest of OpenLDAP's > handling of URLs in data (e.g. the ref attribute), then this is a good > fix and I'm way to late to complain. But in my view, if this fix is > introducing an incompatibility with the LDAP spec, then it's not. Data validation is the user's responsibility, but here we're using user data (an LDAP URI) to perform internal operations, so if we want to be strict, we should do it when the user writes the data, not when we are going to use it. This fix allows the overlay to use poorly formatted data since we cannot prevent the user from using it. A better fix would be to intercept write operations that modify entries in a manner that would trigger slapo-dynlist(5), and be picky about how URLs are written. This would not fix existing databases, nor handle cases where slapo-dynlist(5) is configured using slapd-config(5). Or, we could simply become picky about how LDAP URIs are written in general. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > Well, the fact is that memberURL is stored in the data. As soon as we > accept that value, we need to deal with it. The current behavior of > slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be > parsed). We should rather reject values like this when written in the > database, but this would probably break other applications. So I > believe the fix is better than silently ignoring these values. I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard. If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> When a memberURL contains a simple filter with no brackets, like >> >> ldap:///ou=People,dc=example,dc=com???objectClass=person >> slapo-dynlist(5) is unable to build the composite filter needed >> for the related internal search. >> >> A fix is coming. > > Are you sure that's a good idea to fix? > > It's not a valid LDAP filter, even though OpenLDAP accepts it in > many places. That we accept it from users in tools is fair enough, > but I'm not sure it's a good idea to accept them on the server side. > > Makes them one step closer to interoperability problems if they > reach other servers that do not slap on the necessary parens. Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > When a memberURL contains a simple filter with no brackets, like > > ldap:///ou=People,dc=example,dc=com???objectClass=person > slapo-dynlist(5) is unable to build the composite filter needed > for the related internal search. > > A fix is coming. Are you sure that's a good idea to fix? It's not a valid LDAP filter, even though OpenLDAP accepts it in many places. That we accept it from users in tools is fair enough, but I'm not sure it's a good idea to accept them on the server side. Makes them one step closer to interoperability problems if they reach other servers that do not slap on the necessary parens. -- Hallvard

1 0

(ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando When a memberURL contains a simple filter with no brackets, like ldap:///ou=People,dc=example,dc=com???objectClass=person slapo-dynlist(5) is unable to build the composite filter needed for the related internal search. A fix is coming. p.

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by quanah＠zimbra.com 07 Dec '09

07 Dec '09

--On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > ------------------------------------ > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > type="refreshAndPersist" starttls=critical bindmethod="simple" > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > ------------------------------------ > > Question is if this is a bug in the documentation or in the code. I think > it's the latter. Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> 1.509. Can you please test and let us know the result? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6420) test058-syncrepl-asymmetric may not clean up
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test058-syncrepl-asymmetric can leave slapd processes behind on failure. It tries to kill them with the command 'KILL' instead of 'kill'. Fixed in rev 1.4 in HEAD.

1 0

(ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 07 Dec '09

07 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.43.63) The bindconf parse is used in a few places where remote connection to other server are to be configured (syncrepl, back-ldap, ...). The documented behavior is (from the syncrepl section in slapd-config(5)): "The tls_reqcert setting defaults to "demand" and the other TLS settings default to the same as the main slapd TLS settings." This does however only seem to work if at least one of the "tls_" appears in the bindconfig. E.g. the following syncrepl config doesn't have any "tls_" setting and should, according to the man-page work as if "tls_reqcert=demand" was set. However the actual behavior is like "tls_reqcert=never". ------------------------------------ olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" type="refreshAndPersist" starttls=critical bindmethod="simple" binddn="uid=syncrepl,dc=test" credentials="XXXXXX" ------------------------------------ Question is if this is a bug in the documentation or in the code. I think it's the latter.

1 0

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 06 Dec '09

06 Dec '09

All tests now check for backends they do _not_ support, not for which ones they do support. They note why backends get exluded. ./run -b ndb all" accordingly runs the following tests which it didn't before. If any of that was intentional, ndb needs to be re-excluded. test006-acls test018-syncreplication-persist test019-syncreplication-cascade test023-refint test033-glue-syncrepl test040-subtree-rename test041-aci test043-delta-syncrepl test045-syncreplication-proxied test054-syncreplication-parallel-load test055-valregex test057-memberof-refint test058-syncrepl-asymmetric Beyond that, I seem to have confused this ITS with an "add support for back-ldif and back-null" ITS, so I'll continue that way. back-ldif passes the tests I can run here. back-null now fails 6 tests. Need to look closer to figure out if any failures are bugs (or doc bugs), which is kind of the point of the exercise. -- Hallvard

1 0

(ITS#6418) back-meta pseudorootdn generates broken idassert-bind
by h.b.furuseth＠usit.uio.no 06 Dec '09

06 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 6. Dec 2009 or later OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 'cd tests; make regressions' fails because pseudorootdn in back-meta generates a broken idassert-bind. testrun/slapd.3.log complains line 55: "pseudorootdn", "pseudorootpw" are no longer supported; use "idassert-bind" and "idassert-authzFrom" instead. line 55: "idassert-bind <args>": SIMPLE needs "binddn" and "credentials". Line 55 in testrun/slapd.3.conf is: pseudorootdn "cn=manager,dc=example,dc=com" Also it looks like the slapd-meta(5) manpage should copy the 1st slapd.log complaint, instead of or in addition to the current text.

1 0

Re: (ITS#6417) Mirrormode documentation slightly misleading
by hyc＠symas.com 06 Dec '09

06 Dec '09

apm(a)mutex.dk wrote: > Full_Name: Peter Mogensen > Version: 2.4.20 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.166.36.16) > > > All of the examples about mirrormode in the admin guide tells you to set > ServerID to "1" and "2". > The extended form (ServerID<N> <URL>) is only mentioned for N-way multimaster. > > However, IF you also setup mirrormode for cn=config, The mirrormode examples don't talk about mirroring cn=config. > you need to specify > ServerID on both servers as: > > ServerID 1 ldap://server1/ > ServerID 2 ldap://server2/ > > ... so the config is the same on both server. Else your replica will not receive > all updates and servers will think changes they made them self are made by > others. > A user might be able to figure this out be thinking about what mirroring > cn=config actually requires, but it would probably some time if this is > mentioned in section 18.3.4 of the admin guide. It should be obvious that if you replicate cn=config, you will wind up with the identical configuration on the consumer as on the provider. If your configuration is not already appropriate for both the consumer and the provider then it will of course not work correctly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6417) Mirrormode documentation slightly misleading
by apm＠mutex.dk 06 Dec '09

06 Dec '09

Full_Name: Peter Mogensen Version: 2.4.20 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.166.36.16) All of the examples about mirrormode in the admin guide tells you to set ServerID to "1" and "2". The extended form (ServerID <N> <URL>) is only mentioned for N-way multimaster. However, IF you also setup mirrormode for cn=config, you need to specify ServerID on both servers as: ServerID 1 ldap://server1/ ServerID 2 ldap://server2/ ... so the config is the same on both server. Else your replica will not receive all updates and servers will think changes they made them self are made by others. A user might be able to figure this out be thinking about what mirroring cn=config actually requires, but it would probably some time if this is mentioned in section 18.3.4 of the admin guide.

1 0

Re: (ITS#6406) back-ldif fails test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

Howard Chu writes: >> With back-ndb, I imagine somthing like an SQL 'ORDER BY<reqStart or >> entryCSN>' will do the trick, if it isn't already handled. > > back-ndb also orders by entryID. Thanks, I'll note that for the test. >> Anyway, if I have understood this correctly, this requirement needs to >> be documented, and it looks rather fragile anyway. Only databases >> supporing this use of accesslog. The admin must not slapcat the >> accesslog, rearrange it (maybe he's looking for changes to something >> specific), and then slapadd it back. Not something which would happen >> every day, but there's no reason people _wouldn't_ do it either. LDAP >> defines elements as unordered, after all. > > I thought it was obvious; a "log" is an ordered transcript of events. > If you rearrange the sequence of events then you invalidate it. No, it's not obvious that the order of slapadding entires has any influence on their order returned from search. The LDAP spec doesn't say so, nor man 5 slapd-bdb, nor do the syncprov or accesslog manpages say that they need it. Obviously *something* need to take care of ordering, but as far as the user knows that could be accesslog or syncprov. Actually, the slapo-accesslog(5) suggestion to index reqStart may give a careful reader a hint about how the ordering happens. So anyway, syncprov needs to document that it doesn't ensure this ordering but depends on the admin getting it right. Long-term I'd also like some way for syncprov to catch errors if the admin does get tings like this wrong. E.g. let accesslog require an attribute to be set in the log database which promises ordering. slapd startup would fail if the database doesn't confirm that it can honor this flag, and slapadd of entries out of CSN order would also fail. Unless that breaks what you say about refresh below... anyway, all that will have to wait for RE25 or later. -- Hallvard

1 0

Re: (ITS#6416) back-null + back-ldap + idassert spins or hangs
by hyc＠symas.com 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd spins when current HEAD's ./run -b null test028-idassert gets to: > "Testing ldapwhoami as bjorn, dn:uid=bjorn,ou=People,o=Example,c=US..." > > Here is slapd.conf for reduced case which hangs with: > ldapwhoami -xH localhost:9011 \ > -D uid=foo,cn=users -w secret -e \!authzid=dn:uid=foo,cn=id > Possibly I've created a loop somewhere but I don't know where: Obviously you've created a loop. Your server is running on localhost:9011 and you've defined a back-ldap pointing to localhost:9011. You run a query that causes a lookup on the back-ldap cn=id database, and in the absence of any rewrite rules to alter that lookup, it will simply loop back on itself trying to search cn=id. This is an invalid config, this ITS is invalid and will be closed. > include schema/core.schema > authz-policy from > > database null > suffix "cn=users" > bind on > > database null > suffix "cn=admin" > bind on > > database ldap > suffix "cn=id" > uri "ldap://localhost:9011/" > idassert-bind binddn="cn=admin" credentials="xyzzy" mode=self > > > slapd creates a bunch of connections to itself (according to loglevel 256) > and then loops, with the log repeating this paragraph: > > ** ld 0x3ad3930 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x3ad3930 request count 1 (abandoned 0) > ** ld 0x3ad3930 Response Queue: > Empty > ld 0x3ad3930 response count 0 > ldap_chkResponseList ld 0x3ad3930 msgid 1 all 1 > ldap_chkResponseList returns ld 0x3ad3930 NULL > ldap_int_select > ldap_result ld 0x3ad3930 msgid 1 > wait4msg ld 0x3ad3930 msgid 1 (timeout 100000 usec) > wait4msg continue ld 0x3ad3930 msgid 1 all 1 > ** ld 0x3ad3930 Connections: > * host: localhost port: 9011 (default) > refcnt: 2 status: Connected > last used: Fri Dec 4 19:48:32 2009 > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6406) back-ldif fails test043-delta-syncrepl
by hyc＠symas.com 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> This often fails (producer and consumer databases differ): >> SLAPD_DEBUG=0x4105 ./run -b ldif test043-delta-syncrepl >> when configured with --enable-accesslog. > > Apparently syncprov sends changes in the order it gets them from an > accesslog search, so it needs accesslog to return change records ordered > by change CSN. Otherwise the consumer discards changes, complaining: > > do_syncrep2: rid=001 CSN too old, ignoring 20091130202958.564835Z#000000#000#000000 > > This works with hdb/bdb under normal operation: They return entries > ordered by entry ID, which always increases as new entries are added. > It works out since something (syncrepl or accesslog) serializes writes > so change records are added to the log database in the same order as > the changes are applied to the main database. > > With back-ndb, I imagine somthing like an SQL 'ORDER BY<reqStart or > entryCSN>' will do the trick, if it isn't already handled. back-ndb also orders by entryID. > back-ldif does not support this: It returns changes memcmp-ordered > by normalized reqStart. Normalization "<t>.210000Z" -> "<t>.21Z" > makes that value sort after "<t>.219999Z". > Anyway, if I have understood this correctly, this requirement needs to > be documented, and it looks rather fragile anyway. Only databases > supporing this use of accesslog. The admin must not slapcat the > accesslog, rearrange it (maybe he's looking for changes to something > specific), and then slapadd it back. Not something which would happen > every day, but there's no reason people _wouldn't_ do it either. LDAP > defines elements as unordered, after all. I thought it was obvious; a "log" is an ordered transcript of events. If you rearrange the sequence of events then you invalidate it. > What happens if a consumer does a full refresh from a provider without > accesslog, and is also running syncprov with accesslog? Do these > changes end up in the consumer accesslog? I don't suppose the refresh > can send entries by entryCSN order, since there may be children that > were changed before parents. True, the changes will be written out of order. But while a consumer is in refresh mode, it won't be updating its contextCSN. And while the contextCSN doesn't change, the provider won't be sending CSNs in the cookie it sends with any changes. (And the cookie CSN is what matters, not any entryCSN in the entry's attributes.) So any downstream consumer will accept these changes implicitly, since there is no CSN to check. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6416) back-null + back-ldap + idassert spins or hangs
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no writes: > Here is slapd.conf for reduced case which hangs with: > ldapwhoami -xH localhost:9011 \ > -D uid=foo,cn=users -w secret -e \!authzid=dn:uid=foo,cn=id To clarify, that slapd.conf if for a single slapd at port 9011, matching the URI of its own "database ldap". -- Hallvard

1 0

Re: (ITS#6406) back-ldif fails test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

I wrote: > This often fails (producer and consumer databases differ): > SLAPD_DEBUG=0x4105 ./run -b ldif test043-delta-syncrepl > when configured with --enable-accesslog. Apparently syncprov sends changes in the order it gets them from an accesslog search, so it needs accesslog to return change records ordered by change CSN. Otherwise the consumer discards changes, complaining: do_syncrep2: rid=001 CSN too old, ignoring 20091130202958.564835Z#000000#000#000000 This works with hdb/bdb under normal operation: They return entries ordered by entry ID, which always increases as new entries are added. It works out since something (syncrepl or accesslog) serializes writes so change records are added to the log database in the same order as the changes are applied to the main database. With back-ndb, I imagine somthing like an SQL 'ORDER BY <reqStart or entryCSN>' will do the trick, if it isn't already handled. back-ldif does not support this: It returns changes memcmp-ordered by normalized reqStart. Normalization "<t>.210000Z" -> "<t>.21Z" makes that value sort after "<t>.219999Z". Anyway, if I have understood this correctly, this requirement needs to be documented, and it looks rather fragile anyway. Only databases supporing this use of accesslog. The admin must not slapcat the accesslog, rearrange it (maybe he's looking for changes to something specific), and then slapadd it back. Not something which would happen every day, but there's no reason people _wouldn't_ do it either. LDAP defines elements as unordered, after all. What happens if a consumer does a full refresh from a provider without accesslog, and is also running syncprov with accesslog? Do these changes end up in the consumer accesslog? I don't suppose the refresh can send entries by entryCSN order, since there may be children that were changed before parents. -- Hallvard

1 0

(ITS#6416) back-null + back-ldap + idassert spins or hangs
by h.b.furuseth＠usit.uio.no 04 Dec '09

04 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd spins when current HEAD's ./run -b null test028-idassert gets to: "Testing ldapwhoami as bjorn, dn:uid=bjorn,ou=People,o=Example,c=US..." Here is slapd.conf for reduced case which hangs with: ldapwhoami -xH localhost:9011 \ -D uid=foo,cn=users -w secret -e \!authzid=dn:uid=foo,cn=id Possibly I've created a loop somewhere but I don't know where: include schema/core.schema authz-policy from database null suffix "cn=users" bind on database null suffix "cn=admin" bind on database ldap suffix "cn=id" uri "ldap://localhost:9011/" idassert-bind binddn="cn=admin" credentials="xyzzy" mode=self slapd creates a bunch of connections to itself (according to loglevel 256) and then loops, with the log repeating this paragraph: ** ld 0x3ad3930 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x3ad3930 request count 1 (abandoned 0) ** ld 0x3ad3930 Response Queue: Empty ld 0x3ad3930 response count 0 ldap_chkResponseList ld 0x3ad3930 msgid 1 all 1 ldap_chkResponseList returns ld 0x3ad3930 NULL ldap_int_select ldap_result ld 0x3ad3930 msgid 1 wait4msg ld 0x3ad3930 msgid 1 (timeout 100000 usec) wait4msg continue ld 0x3ad3930 msgid 1 all 1 ** ld 0x3ad3930 Connections: * host: localhost port: 9011 (default) refcnt: 2 status: Connected last used: Fri Dec 4 19:48:32 2009

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by aej＠WPI.EDU 04 Dec '09

04 Dec '09

>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: hyc> Yes, I was able to reproduce it here. A new patch is in HEAD, hyc> connection.c:1.449. Please test, thanks. Delightful. Thanks.

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by hyc＠symas.com 03 Dec '09

03 Dec '09

Allan E. Johannesen wrote: >>>>>> "hyc" == Howard Chu<hyc(a)symas.com> writes: > > hyc> I think we'll need a copy of your client and server certs to > hyc> reproduce this locally to identify a fix. And your slapd.conf / > hyc> ldap.conf / .ldaprc TLS settings. > > I'm guessing the client cert might be a slapd syncrepl slave; I don't know > where else a client cert might arrive. Would you need the key and the ca file > from the server? > > Before I do that, are you sure you don't see this sort of behavior at all? Yes, I was able to reproduce it here. A new patch is in HEAD, connection.c:1.449. Please test, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by aej＠WPI.EDU 03 Dec '09

03 Dec '09

--5fnLV4VEuZ Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit >>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: hyc> I think we'll need a copy of your client and server certs to hyc> reproduce this locally to identify a fix. And your slapd.conf / hyc> ldap.conf / .ldaprc TLS settings. I'm guessing the client cert might be a slapd syncrepl slave; I don't know where else a client cert might arrive. Would you need the key and the ca file from the server? Before I do that, are you sure you don't see this sort of behavior at all? I had been running 2.4.20 on another set of servers and that group didn't get locked up looping, BUT, I just did a test and found that the client cert loop commonly happened in this setup, too, although it didn't "lock up". In servers you have, are you sure this doesn't normally occur? I'll include slapd.19.debug -d1 from the master syncrepl server difference between: TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(25): got connid=20 connection_read(25): checking for input on id=20 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data and the .20. of: TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(22): got connid=1143 connection_get(22): got connid=1143 connection_read(22): checking for input on id=1143 ........ many replications removed connection_read(22): checking for input on id=1143 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data --5fnLV4VEuZ Content-Type: application/octet-stream; name="slapd.19.debug.gz" Content-Description: 2.4.19 Content-Disposition: attachment; filename="slapd.19.debug.gz" Content-Transfer-Encoding: base64 H4sICIUyGEsAA3NsYXBkLjE5LmRlYnVnAOw9a3PbOJKfz7+C69u6lasShaTeqtHUKpZzcZ1s66x4 Z7+pQBKSOaEIDh+ONHP579cAQRJ8U4qdmSSa2o0J9BNAo7vxIPXP1n9eSH+/c7A9n00XY8mzkGNI arvbVkZS6073JUWVVFkeSYoyluVxpwfoZ//hEuL/c7pYzK+nt5dXavuXxXX7avYwfuMTYnlvPFd/ Q4CnZSDnzf37q3nv9W7YX/W7ce3rUMQbD7tP2AUKKveMQlbOk7/aYP+ReL62t9EWr9BYoqVJXuAr yZ3IZwbCW2KvTNv0x5Jlej62JWJLlNv4zZs3VXAvj6ByFFBL8olENW6326FugWutHOR6eIV3fisS cMEZjGNKibIykWX+jo1EjxIWXkMeBbp2BV2popj3oe5i5OOzcDRD1JCbD7zCPm8z6MpDnrUSMZi8 v51phrbSkP5xldSKGNLb2VuJwrFtFOO+xe5HbOG9BIjddq+tymOptcSOj7caNE6VX1G76l+cPdZI ei9IKsRtLOnnn3+WDPuWuFtO+dPPZz/99FOuLo+n2xMvcLAbQN95ryQSTJCuYw8eDX3yyTHZX2wE RfzStAkpp4wIib7SHzE0DVkW+QTD5O8dLJ1vWSPOWR/D/8KRuo5ab9obNhIG8pGGPMxVX7jY9/eh EqEGFtlEuhUDXyVoZTxukI022KVNmMZNgIlI/8BcLOdfRxjK3iZYxT30JV3QRNOcUhn5B/WLSHhQ vwiEDfslb64ABcgC7I3YDw/Xs4mK1r1h31j3h7KsdTrDka7hgaZraxWNVNlYU+YLTBwLF4/pFzN3 YubVmkN7keNYpo58k9jlbS6cZo0oC2U6aHugrEqKv6IDyetU28zaVoEuBoZg5m+x7Tfot2r8Qv5N h+SAsXiWdhcbdKFeB9j+i9vhSfPvSPO5qbnI3S+Q7x7sK62Q1qmhPbXm1BrQ6JNBXiML716b9poc 2JqGtKfWnFrzdVrjBP5qbVo+dsfSeeu/Wv/XivPZ6RoAJssgJ2ukB5a/vyiGej5ary8uWn9rifnw wjWfkL6fOOHfi4uL85S46e1MKK/o4h1UeEkFzjPN/RJZaV539wVNOZp5Vs9KRmlkz9yCdbGq8DFh U8WlkcQi5Q6Vx3hkpR00bLd3Hwr6uopBVlxz3IrWVTA5P4NFxsrTkb2W1ltfav2x3X6+kKByfBTk a3mcF+NKx6jZsqUQs5Cn7s0bc9W95nyxjpszBuTmnJEVbJuzptjNeX9L1vAysVLc7zh4S6HRZslf x4m8TLdmU4GqFoLLFmFbyNDTXj4wsO03DPnPIejr+/hsCDtCzeJQ1oRRabxuTNMkcJczOy7EfR27 rckmntV0n0nWd58QnSbLX2SyfI0p+N1Z7/cxSN8e1xc6uiW26RO34iiSI/Ajxwj9ZfhlMtEMswy0 mnYZaJ7+iLeo9OAshm+Rrz+a9mblBjALAg+zk+QzCf5T2mp72JXbitLp9fptpd1tD+Wu1DJtH2+w +9b079wbSn4xliI298DlwQMxrTLy2+nNlfSPHI9/SOwey9USKL3AcYjrY4PevvkXzERwodLfJXCg 7v6Db8FjYBq3AbvH8HdpIzwTS78kth64Lrb1fVxh36DdAtsGPRUvqJsG/mNYf21Y+IO5xSTweYVt 4B3tTt+9Xt+Y9hzbRQC0KwJM7X1J9dLHjlB/bfsx4pzoyFou34Ul4DzDLl7PsBPpeI/jJQrQYfcJ WSFgSfSPWkCVubZ1so0bm69PGvzh0cXI8HiBECtV8Ytr+un+mGmXCCznnYtxqmJJ76Twitmtnq26 ns1zdUuMXP1x6SP9Y1z1uP0fzIdt6Sxh6QWNhCkMNVtkWjCh1piOLL5z/NAmvEdkkE9z5PmXj8je 4LgKxip5Rrv4+Rfk2mHPhOVrG+m++ZQQXu0c002K7yxEkU3Qxn0ydbwAw2TlhUt8ohMrsT1bv3d0 XryQLsrnUEecQ1PbOHQSdXKTKGJymkWnWfRdzqJOOzR+pa10+/Aoj2BKdNuq1NKRh683NnHx9bRX OZNKeYSzKc9InE3I8pfshmA8YMRem7RROu9X+GPQZ+R5RGd3CmcE6tmc43B0j3XiGpRgljz+O360 l/GjdzeNn3WqYFz6FdnYvwGGGtlx0czap4bhwljzqvfE8/njPdgdNdcY7q71oapSFjc4mv7AnYIe yRbPYOR0SC6oCYHZmPbyEVtU/fDSzINpxM+3pneL/Y1LAocNJ5UaD6XpAOwTcT+ma7bIS2q2SE/0 0gjx35kWNRvb9G6Qc0V9Fe2/KCGHCtO3ML0oU28cSmgcVzuwzSNtQxFsI8XnZBrfgmmo7V5b6bQ7 I7AE7Prmmnp8tqsfGYOINcxhsSGvsJuEkptJGXnKXCBsEAgJ+3v8RMIIRJHpYCbkOZiBLR9larPN 7KUaUNTEbgqjafO6+eYVN43exbtMkGiTpmI5q7AstYj2K1jUNd0dASzsvjNdiEJk6xAbqhooJ3Pl GjAqzI5gsvouoTYcV13tfGzzdCmufIeRH4A1Uss3kLPc2z7asWKMMk0ODyhXvMsNkTqKU79DGwqk qayvaftO2d8p+/u2s79oAgyk1oa+1BG+jEG7tMGsGfBZU0Qpzpfw3RAK8ny0pYa1JYa53ic1WXXA lzpc/2t7TTdYaH82UClyp2XUiVoFGBklYCkZ2OZvAQ7DdQPp0eIxR5aIFUEZeSptNPbAjTBteIBu IFaNG11MLTY6h5FRAsKGjy3sPILrC22lgQJRnCiiFA0hA+eJz4LWMKPQwizEoW8fwF9xu3gZ7vKH uBlzUcB6ie5jf+m7oGC9wkpkuVmqbMBdQFb5Kcz/Ql/i7h2fuoCsBn2ppZnN5fe5/DRNIn3Xk+UH ZilJ0M1ITDYLG8jLbA2eItopon3nEU0B7w0LGwujBmFDiRy3SCHOj0fkgSWBIzBtiGR8rMCBslTU 9qc6N4j/hoKF3z8swuJ70zBiK4MeuyHck9yYrktcKPKx4QcSsQHdg0Xc2dY+KtE3VvGckI+BExsB ffPGC7ZR+ZZA2qzHFmG6dBGEYs81N20YfWb7XHt2/WZONsuAPUU2cEsWYZCIKu6xRZDx3syv/RRF 3CISl34VXa3ktoRiQrHHHVjSiotrF2/oe6curATiOhY8UngZBWHVaQdb7Jp6U88crTbzZKJyO0VV EjWoU3Vt5h4gCVrObostciBsmYRuCVg3CO+D7D5Jhjjlx0FplEwQA9Ir0+aOy6AujLBq+38D0DQM Kmkl+4KSd66Bm/VaP6tiivRZFewJCtYr1ssqVh75ltPl/Abr4NNMb0uH9QlCFXFv0RbHhSQygl+k 2yUhULfDAEmXr0iDHMd4uL8OW6e7ZuQ4wyC4Njd8ryUuw1wVpyR/pq/URc/uxkuIpj4Mvhb43CV7 mdoPeyd2UBB0rmf3+BMNKknV7wsC4WwvVNxDUrDjnuVt+OIz9xv8FVdeMj0kqDUzfe7/aMd7UXTV rSBya/P0Yp7WmFvTj56J0BVQmIObsyJ/aADLOYn8V1heoCiI3rENiUsL0rOI811mj4LXgue0EG9r lM2xLG6JLP8dy/zTwPfI40IWppHot7CCjWmLzyn172mcdKO8gCcMqUJ6EHllSgStS/P8LTDdqH33 mE56nWt7T4g/W14lhcUv3F8jz5oGO1jdOF5Sw7cleQnigrVNikusLwR0DMmc6Uc5Adt8vZ7xEiQT bASjNMf1/4WsiDAJkLwC4pELbeKpzuXibbBeRwNDcxyB1Yf58lLczkp6IQtJjIBCyiiSekhv0iDT ecTuMoinBK27n7NwKlakiO6RbaQqwBPAAvbSMuNACZWz9wvkom0KMUpabiLjeXAMtge5FkJ1vO+b RHaHmHaSAVKDTdjOtAWskFLZXhLXIdRD9jnDPtZj+iTRiKP+XTTecc0icDc5LMvI11BXEyUHKV0/ 2uQTOL8NFtfUkNaxf9KOnyYqbF/QZ/9AcsuUpf8P4B+23Qx/tcCDvMXzLqHLNmEXhYnBZdgiWrhb w0Djt2xX3nncezDq1gxbkGG6+xDGfXhJsNkAps1R+EceaNeEmxoUOYlF6chEExBYJKZcjrE1OCvH w4FB7D2daHS78gpWAgY27u7FxGFNW2xApKSm5xKyjTuIbfdS/8bEhNvURA/oFnxaIK/8wHssKieh KqqZ8+1tqhtbUiMrItKpGkF2vQlj4W4gHP7OUxtYOPgBOzAITIuu4qJ+5QIWgWaZ3mM4vsidQ8/b Xtjx0RvYSeA3PQf8MueAt+D59jjZFogqaDCj+rJlCOR+c1hxBIiZabI+4DNMio4vIqYFb8aI1bem /tHOoOavF2agtm46YMYZsqVOHEhMU1TZjxZkqm7QryS7xwE+IlcX2YBYNzWeTC+HCQHCgXTA1CAJ yssLZ0Kmki+1Cq7lhbU0M+dt5aVLi3jYSMpLB22T0t0nO5+xdcVFwiGJbze3UnjJzLcjqtk89e3k lHy53Dd1It9gWy6n2in7PWW/p+z3lP2est9T9nvKfk/Z7yn7lV4s+6W3izv99mDUH6jqUKG331iS 6RrxgYS4lS61wCjofbGAGhGbRg0203mGV0yaO4Inrsfbw87fwcqjcvzSAoQxHN3+on9ntxJL9IA7 v3ZDhwN8AKRFRph0RPOAfjnTpHGQ+jMvtPK0VswR4qnlEe6a8RoF9IIfPZZ6GydaLLrfch/LtIpL EELNnRhJIsg9jvOc2FnP3krRhTkKYaND/YyF73Q9cJAd3tSz+WlzNJGn7A4Z0xV6zUesM5LbhVFz rz/cY4MFL3Eu3LkbppJY8QBuNV3JJ1oCyyT6BXe36o2h7LLWs17PqruPFX7/E2KU6weO8AnQ9hn/ oOaKw1bEBuVZgZ56nev2RGfrgfOz8G/41U1DW9GvjMZ11PeumGWOC2my8NCqy+F/yJ91WBhVICiA QMNwBYr6GeAwuzZhZKnA7Hzemp5egdD9DF68At77DEZUK6b/OXRqtYgDikjfBizBERZBkz9eK5/X LlvyGE3Qac9WDE4KV/msGVo5Il/HUJ4epNWQ3j814ao+I9cYWfkcfrgAFitNdIARD892zxvMAMaT f3SUmv04/sZoDIYq8NBPDNx684Tc5LPHsV5t9aIdsrFVplQror44m/wscYhpCNU/TZLqsbQhvmQa E3mnnDH6lYFp+jZOlAR8EdIK6y+Y1BCwwf5YcvWJXNduQ/z8Z2nz01gVvUBJCjog9epjrh+y0Kbd kdE92ysp8FGdk7ysWPQ9zUNfZQzfmgxBfKfDS79RmYUVysySZsBahlrkTK8BQXSiOzdFglPgQtkF DDIYep6HKCKamoXyBWCh9BxxBm5k6UXm8+jD2UWSBWDJ1/0yxLkv+GXoU8yzL/QK1cXSEoKsnOxL v2H1ncOXi4WNE6GF8vLkGQSS45DiHzrnYtkxrFhyhjQrN0MtcqZ7pkUSw/ril4cFkux7w8izCqXQ 25qQSOuFrROhxRJz5Fm5OQ4if345rUh0DCqUmyHMQP00bYqtucWF4lh9sSyBJCtIoEpxmy8LhdDq YhkJQVaEVdiOX5Dpl8z1GFQoKUOY/eJgJW20fS1Xu2YKr/RvkvxK9HavagONkSI0RMLq1+kjjZUa jZUaerWGXq1rcefYFneObHGnRuNODX23hr5bQ9+roe+VfTwB7SS2GzvjBzyk1Fi3gLqmqIaIWjy/ iI+sshkWworzAXbz2C/LBSJoIe07vpopIV7H4Jq5Ujsn6mbrKyGpqrc8TSTTBLJqu4v1LZtqhoBQ FSsl5ZUQOOv1JSIZEcgazpPjeqdzWO9EbSsbTJLA/wJ9E49lmdszBIRKfdXj9FUP0/dkOfWW85VH oq7L/xIjmUTn2ihclx8cZwvqYbYQrdJKjcESEKo5lA2QJSBUcyjzDZaAUM2hrNctAaG4183SqKqZ pRH1wdbK6QK7gjI8Qihb4XBgyX7C1kFu2fJBj6Aley/0LcbSrZcQWEbpGnY5JQMWUk6Nsg5CRmmm gi3slzXR4MBiaRqyDVKmKIqghbTsKMHAZeriGPyy8fhIP5dkS8euC5QD1wVJTD9WonqgxDjy1IWY v4zGb/d+6d6bFsIK6RbFPywFEKf0W8f0KxhmqTQcQQtpowtRZdRuAi9bY5UvqSrWZfz1yorlmBNh lO3DlU12wkBle0xsu7p8h4mDi30MexuwzMVwYPGoVra2uqU0FaDvtVXE/xBcuqtWprIXwortIrB/ C3BQRurG4OI1MvI+0tBbtkyOweWjVDVEL7DCfnD88r25wPHL9/Tou4ulk6d0XNjrs2U7ZyFMOKEG 6yg7Jis6qmG/XhmlPitmmTDSreHFWGLapODCT3UmBxKUWUuhBPRIidbTYyURgbYtxGC/rEbPgNaE /jCnE/j0F0QZPv1SKnBa2RBDU4Wx5KONJO86smRhW+rJVAa9ouqNz4jDgX35lUQ7XlLU3mg46A+7 3TRHqs5ElogD/xhkRdOu3MdZza1f/G3dzEdb89/pbPDjV4cRvapny1sxlp7Ce2GTDkiZnFeTnUtb +puwxkRRh3kzqSLMni6W45WcM67zx7TV8kr49PqDggPcKlZFB7sV+BdC13ak8KG2W31Sr4ZHz0TZ D8u62AsssGzRKp1JJ41Br35B67beBtqtUEOfjAYShFg+W9ZW4D2qY0lVJZYmUB08Q1KGf97kVEad wtnZaTw7FTo7w8VN/uPJJvynVU3FJjMvN9EyRM/xCyw3nyPIBIzeYjfkQ6crttTD1rp+wvqPpjc5 z1n0JMWW/kjlZHYb3qSaXP17evmhiTeIpmTU4ZW3C3Luov7nNIvuZjSiKpn7ardTMPeXlONDxLHo t3ELXUA9WUnIZJ21guE2THpdzxtL7FpMpsOklryTw/+UC8mj90knaqo7rNIbHPg3eiXZ3wtCottz 7PYoQ/yI92z2Rp1l0hvjrGYsrZFpYUNqve7Io+Eo7s8CvmPWs6+kNf08GH0A/vD3mTSR+oNuV0po 6xSh6JEuHa5LV+koo0p9AtOo00M5QAkl0kAdDkZ9rgV7PksmS45IpBFJMvaavUQ86cu4O9Q6qobk UXc9lHF/NOgasq7JhtYdyFrZjwrnbfrZWBfE+qKPrVfM0wyDozQ7TORAHuhUKguhfIj45TXqcyWZ +cNn7H0xBHc7o2wMBjXLVcE7029X5gNKTT6gsnxAkZVGCcEzZfmqkk4klFwiwTBKEwnl2bP8XkEe oZyy/C/I8r9u7qs8b+6rKn+eySqjYpvN5b6lNvtD5L7KD5T7nrLHHzl7HAy6XAd4apA5AlaCXpc1 KkMkK7KhotFQ6eAROJ+BjodD3Rgp3c7aWH9B1ngs62zWeBTjw5K+jtyvyvmU4pzv+L5L5Xy9Tjb2 VOR8SnXOpzxzzvdtB0L1hwmE6ikQngLh9x4IlU4nioT0sUEopGgCQe0WijJUlRG4dGME63YDr3s9 uTsYINwbDNZ93fiSLZQjWdcGwyaMDwuGvc4xwfD4vktvgPSeORiqNcGw860EQ+ULg2HnhwmGnVMw PAXD7z4YysowCobw2CQYAppAUBcMZU1W9IHRH66xpqrqSF53wLGjkaLhdX84+pJgeCzr2mDYhPGB K8M1OiIYHt93qWDYHTxzMOzUBMPuQcHwuU4D1HQQVfNBVK0KoupXOQ1QT6cB38xpgPrMpwHqn2ey X5T3qT/MaYB6Og045X0/RN7X60VpHzw1yPoAK0Gvy/lGa4QHsHLXeiNNHXY1Re7jgYYH+mDYkXtd /QtyvmNZ1+Z8TRgfeOtExVU5n1qc8x3fd6mcrz/Mxp6KnE+tzvnU5z4NyAfCr7cBMux/4QZI90cI hP/f3rv1SJJcB5rv+hUJvohccFp2vzS2JRA7wGIAqrXYHj0MCILwq1jY6qpGVfVyqMX89/XITM+M i5sdu3qkpx2NSMV0e1iGe1jY+eyY2fme7xQDIQbC9x4I1foZllchgVDx18uhQCjEZG03azWRkc9i 0lPPOe35zKfZTNxkBMLUpsFAGNJwZCDkPCH5kf7sLgNh6eSHAAKhPMhKQHYglM0EQomBEAPhew+E lHD+shLAQ0Lh6bKzN0DB0Miht11H5kGPkxHzMOvBDoSMwzzPrMtZCUhtGgyGIQ3HBUNBbEIwTH92 l8vitHAwlEAwVAcJhtl7xFQzwVBhMMRg+N6DIdOCrJ/i8XXIUbvTdedvATdNC2X7Ye7opIScTac4 Y9Mo9aQsUd3c5WyaTmwa3jQd0HBcQFQ96VN2TSc/vMu18dK7phUQEXVWRDzQgmETu6YZ7prGiNhE RKTmZXZogiaHhr9eDkbCbhZ05Griy1iu6TzZXgqiOKWn2c3EcyJhYtNwJAxoOC4S9jphvTD90V2e HiKF1wtLbpi+63qhzZwZ6hbi4POdYhzEOPjO4yDj9KUGy/IyZF64XHb2BjAWUjMoQUU/jyMT0vJx tmygbPkfPhsicmJhYtNwLAxoOC4WWuItn+KaFCY/u7qTQg0EQ/NGJ4WnK+ZTAF4Hj+Xjffr8A3n4 7U+/Pg6OF7uwh5O684UBvi4ts1qbu3nkPfJdNndz3Nx9mM3dfO/N3fW6bFauhjezuZvj5m5k1CYY NWtzt4e6+NvZssz91MXf05bl7MVp08Lw/nynOLzj8P7Oh3cqtF5z8cvLkGT8ctnZG6AUxECMUVoP tuuNNTPp9DJ35oqrU6Eq200ZKYjUpsEUREjDkQVMBpmQgkh/dpc7tWzhFIQBgqE9yk6t3AImtplg aDEYYjB898Hw5fwODTq/Q9fzOzTg/I7uJLfMzJ0YR04nwwY1zYapmQs6dlPOQdbUpsFAGNJwXCDs Uo7vpD+6izhoSxfyslDKj7zRQLjm4ml0Lp4+5uLBdYO3nKBsYjMZx81kGLTbCNo5m8niE5T32CMV kqCsu0eq3vCevizMCy8LX4VbERluRXAIy1kWFrgsfJhlYbG3AaRel81aNxDNLAsLXBZG6mqCurIM IB7qEm/HayH81CV291q85eG9iUm1wEk1Du9NDO/ZXov4If4etoaQIX5XW0PNIT4jbyqasTUItDXg EN/GEJ9ra4gf4u/hIAgZ4ss6CO43xOeU4RPN1KMVWI8Wh/gmhviserTxw/s9qqyGDO+7Vll9y8N7 E1VWBVZZxeG9ieE9u8pq/BB/j9qhIUN82dqhlQ6ay8hdEzI4NITuKFAbkUHijoLD7CiQex80r9dl g2nG2Web2FEgcUcB0kwTNCOVfZms2qDJqn29HDp8MWpLre2NYtwMRvVdx6XmvOMdHSbRyYzDF6lN g4cvQhqOlad468XLbeZLf3aXey9ExI5X6Wc+ufuR/Dew92IrEIpm6sULrBePgbCJQFikXnzCFrs7 FEEPmdrXLYK+Y/Y2sPirc5hvovirwOKvOMy3McznFn9NGOLvUNI0ZIivW9L0QCTfRHEtgcW1cIjf /iSlFl745U9e3f7kue8nr4J/8jkLL+o9LbxUDM67r+m8hTps+64rqdd1pYBF5MsCcEUWolImrPeo jhZCM3Wro+02tGUt0KlmFugULtAhzTQxYc1aoPMM72rXZSfuG96Vf3hXpZed+I77L9ILrcjnQitv /+yac2LdRKFOgYU6MRQ1EYqyCnXGzzTuUX8yZKZRuP5kpW2vOjKG6V2yL/o9ZV/e+bZXvfe213pd llqWjjK6mVm1xlk1okwTKMMkX4/hn16GLAMvl529Adr6SqRmXElpqBFSaabnsTc9Y5T3UnaDp3QW uPU1tWlw62tIw5EO0KnzgZ92FCxIfnbeBXPv1lftBz9df+trvWCYnoPQdR2gJvIezS6MapBRD8Oo Zm9GrddlsxjVNMOoBhkVGRUZNYRRPeRl3g55GT95mfLkVYpmxGVosLehQfhCg92FZizSzGFoxham GXG/Lpu1j8U2QzMWaQZppgmaqVUVze5aFU34SMb6ScaWJhlRjGTklfOO3MYF6ZXekV1YhhKEmcPA zPplFaMZec9um8UzT4+iCaBZbxWJBokGiSaJaJaf0J5II31Is3wWv5CXlIaa21G+3px1XRgT0Qtj 9nFh7HZ+XTMirZ9WxuuDyePHlbUyX3RDkuz9TqjHklySFyny4nF4ke6d/arZbbNOpT89ijZ4kSIv Ii82wYvLL/5lOS/kJNdy1evl0H4zrgZl6DSMSg6ca9uZXpKh67VgsxhmT5ERcL9ZatPgfrOQhuP2 m1F/Da5lsNkk6/SHd7nsKSOShctn8ZM1LZ8u3DMeprP1cudPcF2LVlnsbbJ9aJUhrR6HVtnutFqx 2+bRKmuHVhnSKtIq0ipEqz4GY2+IwRjAYGx/Bis5ymcwGHMkOOtth04/pWDqnlKgPPImlzfswosc efE4vMj3PqlQs9tmnVV4ehRt8CJHXkRebIIXuVbs+UOcXgYQ4+myszdAGU7NhnGw42gGYQdqx3lS A52MWmhRSclsRoYztWkwwxnScFyGc+qZl665o5ZK8sO7oGtJIw52LJ/FT9d890O1RWNiOrAud16X WDeKgvlvM7wqWCix6q3IL5BYj0OsYndirdhtg4nV3W/bIFaBxIrEisQaQqw+DnPVtLsHhwFF7daf /J4cVnKkz+Aw4aixWq/c9/phefSHVY+flVdjxtiit7S4KFuSrdiLpuwDMePuquya3TZUHufpt20w I+qykRnbYEYr1pIsy6sAYlyuer0cynBaxsjEuTC0Z1yPdpQjtZQyZcysxjFnD2dq02CGM6ThuAwn 74WXrB2+7PSHd7l/QMeQNSDMphWM2ZVkXTSWcWlxXdd2GH1Xvq73jn+qMP7dmjp27LZ5+NeOi4mi jAnxD/EPxD8f1DhsTJWgxmtjooCOie7vYyo6yc9IF8rKy7axNZ9pcWnHdixDa8eBGGx3bUfNbpvH YO2YOyiqO5DB2mCwhSnWB3J6GeIhWy47ewOUhptnPVlBxEj7mXXd0JHZToOcOyWU7E2OuiO1aTAN F9JwZBpu9i9wO9wd6Q/vglh5VBoOkHfQCvaOIyBgBulqx8L49WmljfM//tNKxRUekm5FfnR4HIhY S0s84EN2FbttMLG6+20bxIoiDyRWJNYgYvVxmMPkUYnD/MepAZUHLe7y2HekzzhObRzHqWsuZ6Vv NaS19xpu1PD0U264eILzrfCr9XX4lVvh91WWsvyzpYdOt+j483NQe+3A66XfP3XYh8/LBz59lMcx 3o8zlJEiGbiE5/nf//jTw7cv3bB8op9++uNfToHrl2/f99Ny6fRPT/+/5S0fvn1Yxrb/7E4NO96y vFww8XF0HD5+WJ77w1+njx8/P/zBe/3fvnz4Ni0jyZeFaSPeMExfvn2YPwxLL4z5A+PnT9D1jw// YRmKO8dly/f0+BQfbm845FMFv3237/r2gyyBbxnBh792n/4DelyPb5uXDvL1r8vIEvTVPTU7fPjl r8s38vWXaQh6W+DfOPv6Nh/Pr5+6/uN0+kUtD/Xh1NLzPf/XH3//8Pjd/CDsw83z3Xv0klqEzXrd wxeNn/W+DGrXs+Htf/y/vJNkx5TjNMs4m8qOnx5++7uHn/7w0x+Xeerw14f/86ef/vB//bezAfNr 9/Xj04hKxeNoSiVMDc/Tw+fTAi/jKVG32aQfnoLX6c88f6SFyilY8KTml89M7nfPyn339/mSlfR8 x9zzHVO6kTF8g9+xlbnfMT/07/vl+1hubfy0jMvffxhPT2SJ0t+WQX758pZZ2A+nr/+//Nx96v5j +vJP3cdff/5umeB8t8xwfr/MuJfJynfLTOX08qnV06vu129/ff68Tx/pw38u/eZ/T29svc2o1s5e /sfXr90yJX9p7Ycf/vnl5tnpzp9v+tSfHh/Tp275/tP/wunRdUs0e8y2fJkeg+dfHrva//z2l+6X Xz7+/eFP4xIv//oD/fPD129flr/7wz+m/7l/vPg7X379OD3/kdPLjYa/+9+unvZVcyU+0sOflrll 9/Xrb6evv/tz0HNYRpgf/j/y+39cZy4XGZzXSfG//MvCj//y2+XvPH+o3/3j/3rqyr90X75O//5/ /7fvH06vTt9ldFP/8DjW/frl41Njp+nEb6Mb+d0/LKPRX+YPH78tv9uH35z/q99c/KuvH35e5vyP /+jp5eubXt/zG0+a7/Y35viQWz8gZ4r78qfxy/RlGWJ/Pj3OD8sX9+VT9/HhKd/w8NvHHJmjnd8/ 58fo77w5PXee7mppcLnwDxt3drvQ57jwd+4knzPT+Zrum9d0H71O97lv4Hwx7+NTSomvOSX1nFES zBwkQTh8qpKPM2z988urgGzcctXr5VddZPnR/OvTj+b3wb0Ffs/1eu/rT9OTZHYt5HLhTMg9A8Up IbfQ0uWP8P94Ccqv4WmJMfBHuQ3yy3+uo3xAM49/9g/LwP75yzJ6PPzp+SP/+fuHh1++fP6ff3/o nv/dY3biofv48fPflsZP//Q//+uPP/zmN5ug+YhhP/wX+ooqp7/zT0/B/2GFlx9CHvnD4z1+/Tr/ IJUHW0XMXisHtJIazPr4aX/5f7+t39Wn6cuHYfl1ff22PMvwhBsNXPByI63IWvBavqmPn//Dvfp6 +pe/f72s8NrWP58SCn8Zvn35+DUWu8/f+/1j2vA39Dv+nfqOfidO/2GEL//HLv+hS1z49PnTsMDM h6H7+Ltb9I8C/N7B/XGzh959G+w7qr4zgpw+OuWak+W2xHdsuYvXW1iGq7O3fVrmrqd+/vgj+Y1/ Te7pm/zN7/zDmrhdZ4AueYSNn6fxwxICzrO5jm/lecrq+enL5yzv1lqGsLX2lFxJqFishIqFaxFD s+1bdSAZeZPZdlAzmfI8Mdt+kGx7te+6mWy7jMm2s1uw2XH0kg7twU02zj18YbYdzLbLiEzsjl9+ aLbd/d1jtv2tf8eh2Xb3d9xetv2XXz5+6D4NkyiXc49rMizzvtlmhfx73N8plIWP+6M75uIjPxhm 5DEjn5eRxwT6e0ugOzIya7g9UC6akfeci3YiXZUp2865aDfwYS4ac9EFc9Frp/LkorcvuWsuWhbL ReuroWFDMau9Q0O4cj30wODmb5/igcHDHBhcv6xiBwb1Pbtt8IFBd79t4sDgeqt4YBAPDL7zA4Oc cCNXNcHpdYib4HTd+VugMheGkEENExnNRK3s7TiNAzGmFyMlRGqSUeYitWmwzEVIw3FlLrTqqe98 5TLqbJ6vTH96F9x1ravVvvOVJ3Tzna9cR8hy5yv3DYzrgUUdfWBxufPTgUVdDVs3rLz+2wx3r2dh K0NsPQ62st2xtWK3pWZ7/TQMW1k72MoQWxFbm8BWak8b/57WSJaXIXUulsvO3gAha2e6rlPK9loQ M7HJdmrSVFpqleGWdhnImto0iKwhDUcia2+9xMq2iTX94V0SK48hVgYQK9ufWEvGxAxiZZWJdcN0 67/NcPt7FrFyJNbjECvfnVgrdtu8RCtvh1g5EisSaxPEWiTR6mMx/oayhxxgMV6exUrBjbmKEhv6 WOONEsX99ttBAv32B4Kb0n57c89um5eOa8dvv94qwg3CzTuHm+x0nA9sHH77Skkm4wUbwG+//uTL gc2+I/2aZDLxSaYnv/3tx605687IifHKObENjZj/Nssr7vVW+EXF/YGwsbTiHs6JVey21LIwbHT3 2zawERX3iI1tYCOTepWcnl4GYOPpsrM3QKu4WlA5mdl0ox06QZe779RoiTBD1/eSDBmruKlNg6u4 IQ3HreJ21OvXYg7NffrDuwBsSWMyh4DmnhXX3O8bEzOIVVYm1g0fhP82w/XmWcSqkFiPQ6xqd2Kt 2G3ziFW1Q6wKiRWJFYk1hFh9HKbeEIcpgMPU/hxWcqTP4DBVmcM2tKz+2wxXnIdymNmKZxo57Dgc pnfnsIrdlloaxmHuftsGh2nkMOSwNjhMUbVymDqZKWEOU2tRrcc3QJnDcSRyZkyMkjI6jkwOsyZm XsaZoePC9hmZw9SmwcxhSMORmUPuJ1a9TazpD+9yaT6KWDVArHp/Yi0ZEzOIVVcm1g3xrf82wxXn WcRqkFiPQ6xmd2Kt2G3ziNW0Q6wGiRWJFYk1hFh9HGbeEIcZgMPMcc5+bIiu/FsrI+zLOWBjEWyO AzZ297MfFbtt8MFWd79tA2wsgg2CTRNgswTp9YGcXoac/VguO3uDD2zsNtjMs56sIGKk/cy6bujI bKdBzp0SSvZmDgQbrmPOflgAbOz+Zz9KjvQZZz/s89mPShzGN4q8e2+TR3i5MjiME+Sww3DY+mXt x2E1u20Wh3HSDIett4ochhyGHJbMYcvP6M1w2PJZvBy2/uRrcljNpYSMhT7zvNC3Z2BKx8bliyqL jVffCo8tGM3LC0A2wy8KQA6EjbsLQGp226x1Sd6OAISjAASxsQ1s5HL9DMurkJp0kr9eDu2iE5rN bOwUoZoKfjrCYBiVXHWCTfM0jRm76FKbBnfRhTQct4uOKq/3gzu8H+kP7/Lch4hYveWA94Pv7/0o Gg/T4ZpX9n7w2GLRvLz3YzPqo/fjQLS6u/ejZrfNo9V2vB8cvR9Iq0irIK36GMxhsrgLgwEmC76/ yaLoKJ/BYJVNFjy2OCEvbrJQbCuWocniQAy2u8miZrcNZTBPv22DwdBkgQzWBoNRtZZAWV6FLDMr 83o5eO5WjZOYiaCmnwWhcgGvWQ5KDstbBqGmnHO3iU3D524DGo48d+s9dssdqo/0Z3cBqypGu8YB 1QevoPrYMxxmwGrlEtN8o/C3/zaLm0m2gz6aSQ4Eq6XNJPCvs2K3zYPVdswk660irCKsIqy6YdXH YA4ryV0YDLCSrD/3PRms5CifwWDCsSOSXn7cjU9LfZ824MPS6A/79FlpMV68uke+Ucfae5O8uJJE bS7UoZLkQLxYWklC79ltQws8e/ptG7yIShLkxTZ4kRn+orJ7fB1SqOV03flboCQnnyfOzDzowWiq 5p7ZTo+nf2jkSPigM5KcqU2DSc6QhuOSnGoarRexHV6S9Kd3gdjCXkciH2IDXhJe3Ety58AYmEhx B0bWTmBkGBgxML73wGi1ff4My6uAoLhc9Xo5FBCl0HZUMxe9Hkc19ZZxSk+HSmc5DMrYjICY2jQY EEMajguIfPTvUXPEw/SHd5lyIsXjIQPiIY+Kh7XW0WK9Ery4+Go7jKL46kB5kd3FVzW7bV5epB3x FUfxFeJfG/hXJC/igxuH/KrSZN+/ngbIr/j+8qu6o33OZF+1M9lXONnH0b6J0T5rsp8wyleawhYY 5UtOYfcd5TN2TaiwXRNFM9Dp+ya4rLxxYkPj47/N4kbG7dCLRsYDJQhKGxnh9aGK3TYPGdsxMnI0 MiIytoGMVAn6stNW0KCttoKevQGsJaU6OfWz0rzreioHSifLue6NMD2bRpFTSyqxabiWVEDDkZsm lB+wHUbG9Id3mUaRMWtEgJGRFzcy7hsTM4hVVybWjXq0/tssbmRUdivyo5HxQMRa2sgI/zordttg YnX32zaIFY2MSKxIrEHE6uMwh5HxLhwGGBl5cSPjviN9BoeZyhy24Wfy32ZxgeR2PEOB5IE4rLRA Ev51Vuy2eRzWjkCSo0ASOawNDmNErqvNp5chG4uWy87eAGUOZzV1pGdkmo2lkxl6zjvGtRwtIb2d cjKHqU2DmcOQhuMyh4b0XmJ1qTaTH94lseoYYgVUm7y4anPfmJhBrLYusYoNNZS/EkJx1eZm5Beo 2jwOsYrSqk3w11mz22YRq2hHtSlQtYnEisQaRKweDhMu1eYdOEwAqk1RXLW570ifUauJVOawDemR /zaLuys13Ypn6K48EIeVdlfCv86K3TaUwzz9tg0OQ3clclgjHEbNC4ctL0M4bLns7A1Q5rCzsmMd mamYiD0dODRs7CZCSd/P1PCcQk2pTYOZw5CGIzOHZvQSq8Nfmf7wLohVxqx1C8BfKYr7K+8cE7dZ LiImNnF0c71VjIkYE995TKRGynVX0/IyZFfTctnZG6CYaJWcpkH1XPFOWTN108xmwsw0C0F7PWTE xNSmwZgY0nBcTNR8TomJ6Q/vIiby8jGxbK2mPWNiRhaHVs7ibGgT/bdZ3Om8HfnR6XygLE5ppzP8 66zYbfOyOO04nQU6nZFY2yDW7CyOj8McXue75CYAr7Mo7nW+80ifk5tg7eQmGOYmcKRvYqTPzk0k jPR3mXEHjfT7zrhLjvQZM25Weca94X7132a4Cj1rxs1xxn2cGTfffcZdsdtSozI4jLcz4+Y440YO a4LDxPoJAghMrJdC60K064SZB2HMMokmg+1Nx/vZajvy3lLtMZ+C60KpTYPrQiENx60LCS+j8m1G TX90l3t7Y4xWy2fxMyrfPxtRMgpmMCqvzKjRttlwA3oWowpk1OMwqtidUSt22zxGFe0wqkBGRUZF RnUxqo+9xBtiLwGwlyjPXpXsaWKjBry3ZL0obpXfDgpolT8QzJS2yoOmhZrdllqeATPtWOUFWuUR Zt4czPz4689Ll62DNFSbl4+iTQjYLJedvQFKwWnKes773ihlxWQm2s9y7oxRbOj72cwZKbjUpsEU XEjDcSk4SiTzkqDDo5v+9C5IkKkICZEAPLqiuFcetPoUnednZOFE5SzchmvJf5vFtb+abwEAan8P BK6ltb9wFq5itw3esefut22AK2p/EVzfHLhW0v4ay160v8vrIO3vct35W8BT9qzjhs+yZ1L1XCoy iZlOI+sEVVIxknPKPrFp+JR9QMORJwrJOHix1eHOTH96lxscowpDAe5MUdyQXI4D7VVA3VACWW9A LW533I6naHc8EAeWtjvae3bbPA5sx+4o0O6IHIgcGMyBPrhxeAsrwY31wg3gLRTFvYX7jvZrTs7G 5+SevIW3H7dmkiIjhagqpxBjLUaiuGZRi60QjJrFA6Hj7prFmt02uLyDu9+2gY6oWUR0bAMdKeEv msXlZcih3+WyszeAYvBZMqPZRK0ZekbtJMRoOzsu/zVawmxG+jC1aVgMHtBw5METor2A7RJSJj+8 jOwhIKQUFYSUtbKHG1ogP5gXNzxuh1I0PB4IAUsbHuH5ZMVum4eA7RgeBRoeEQERAYMQ0Ac2Dm9h JbDxZw4Bb6Eo7i2EU3ElJ/sZqbjKpm0ZqwWSxb2Fm/FMorfwOBwmd/cW1uy21LJ0DpPteAsleguR w9rgME7oWmn19DKAw06Xnb0BSsXxnkrCp8HMsheKM2aYnDVjlGszDl1OKi61aTAVF9JwXCquH7ym bekwPKY/vAtiFTwiFScBw6OsYHgshICcXMXSW6fA4yXuWFpembgZSlGZeCAELKxM5OSe3TYPAdtR JkpUJiICIgIGIaAPbBzSozpgswytPrABpEeytAjwdqSvOtlPT8XJVV29Z2B6/rhLXIr+uI+Opo2n W3NJK2OLpH3eIlkr0Rlbx1uWV0rJLVpApdSBKHd3pVTNbhu84Ozut21QLiqlkHLboFxNV8/I8iqA cZerXi8Hk5xKj6brpkHMvZhp19GZ9DMX/dhRNUqak+RMbBpOcgY0HJfkZECS06FjSX94F3MBZWKS nICORVYQb1Xabyg3SmR7KVeW95uorTCKfpMD4V9pvwm437Bmtw3GP3e/bQP/0G+C+If4B+KfD2oc /o5KUOPdaygBf4cs7u8A9xoWneRnJDjZdoKzalBKzxhKXjljGFvPURbXjRiyFXpRN3IgZNxdN1Kz 24aui3v6bRvIiLoRRMY2kFEQ+vIhlpchtbmXy87eAGUNrWaTJHombJrJPPSTHea506qXUsupz8ka pjYNZg1DGo7LGs7LN+YDbIekJf3hXe4giDmlLAFJyzo4HiFruGG78JNucUnLdihFScuBELC0pAXO GlbstnkI2I6kRaKkBREQETAIAX1g43COVAIbf+YQcI7I4s4ROHNYcrKfkTms7ByRsXURZXHnyHY8 Q+fIgThsd+dIzW4bWmva02/b4DB0jiCHtcFhzJpVk3d6GVJperns7A1QKk5R1bFu1sM49lTLkUpG 7Ngb2iva9ZJnpOJSmwZTcSENR55S7ry6EenQjaQ/vAtijSoYKAHdiKygGzl2TGTtxESGMRFj4ruP iWQtoLa8ComIhL5eDsXDmQ3dJLVlvJs4H8ighJ2H3nIi+rmzOVU7UpsG42FIw3HxcPCfbXWEw/Rn d5nAiSraERQOGRAO+WHCobG54ZC3Ew45hkMMh+89HFKrxFpQdHkZUlB0uezsDaCScpCiH+g8aT2P amleWjKLedCz5RNnOVPE1KZhJWVAw5FKyrQpYvrDu5wi0uIxkQMxUbzZmJixqFHZgiQ33FT+2ywu 0NyO/CjQPNCiRmmBJvzrrNht8xI47Qg0JQo0kVjbINbsRQ0fhznkmXdJ1QPyTFlcnnn0kb6NVL3G VD2O9G2M9Dmp+oRR/i4Z6KBRft8MdM1RPisDrdvJQGvMQOMo38Qon52BThjp75JXDRrpy+ZVawkC blVYQEHb4rp2c1Ui13enT48XVe4HSmIWVrlzEtXdr4HotiAy9wNRcTXtdXd/ekqopj1Qly6spuVw 2fH9R+kbjN/stuZoaXkI1g0m3xuH9WonKdnqmFhehZyjZPb1cmhrhukGYdXcEW262cyGC0WttPPp VTfznK0ZqU2DWzNCGo7bmkGBQhpmewqR/vDOB3UjZIyKwwBTCFNdxfEG2CgsyBxOfw4FGZScY5B5 g0HGN3Q6hOKVhk5/9gUQisvSQvE78/nWyCkYMHJubJODPEPPMedx6fXXT4/TUNfuObOtH9o1ohR7 LMDuwef+FPJYHjVHt72lagmfjBqrsnCN1avbVBtqL+9tqgj9vAjLtbANnlConz9OrkWV1s+DBbZq dltlwjDY3W2zMfgUgx+egrCbg18DdU0OViiZRw4+Fgcrh6a8DAdTaiNKVilAU66Ka8rvOnYGAl9A 9XwAlZ4fXADwKfJMUHtuw8k49KLrHnpRt3JU/22q4rJ5w7ciJ8rmDwR8hWXz8Ca5mt2W2u2Jyg3x ufvtkRKf6SiIsvnWUbCVTXLMEL3uhV5ehmyGXi47ewNYuUQzOQ18ULPQwopZWjEQY5TQA6VSmpzK JYlNw5VLAhqOWwvsZu0FeerYOJ788C62E8qYjePLZ/GDPD1MUX21YbvyTwCKm9i3Qyma2A+EgKVN 7PC8tWK3zUPAdkzsCk3siICIgEEI6AMbh2O8Etj4M5SAY1wVd4zfeaTnuSN9E+ee11vFkR5H+rcz 0v/4689Ll8Xxvvp4X/IE9NHJvokT0Out4niP4/3bGe9xpK8+0pc8AX3nkZ7mjvSinZFe4EiPI/17 H+k5faldd3oZMNKfLjt7A7iMx4Wxik7TILnWHTNacmuYFLMlxPApZxkvsWl4GS+g4UgBgfZWBXHG xOSHdxETr+s/FYiJAoiJ8jgxcXNHXkxMlO3ERIkxEWPiu4+JRK/1n04vQ2LictnZG6CYOGrFOek6 yfg4jIrr3mrRz9M49VqOfc4x99SmwZgY0nBkTCQsJSamP7zLeaIsHhMlEBPVcWJi9gqQaicmKoyJ GBPfe0ykxJwOqTzVODy9DqmKeLru/C1QXBQzI7Q3yiwjvF3mN/2siJkEnfvZjP00ZMTF1KbBuBjS cFxcZJ3sUgJj+tO7DIxRh7eCAqMCAqM+TmBUuYFRtxMYNQZGDIzHCYwlnog7KJI1KN5e+v3Dp8/n 9+8dSzUwlpqssbTmmbL0E5+KVj7xyWNvkweHjNDt/mIrYnDc7n+c7f589xOfFbtt8KYgd79tY7s/ x+3+SDoHI51UzZl92RS0vAzSnFl99gZo+q9M3xuuhBhnPlmp+nFiZugEYcJ21LCM6X9q0+D0P6Th uOl/30vv7J87hHDJD+9y9h8jkFg+i3/2z+sL4WrO/tOL0i2sHlRSpWgIzwBsXhmwRextin0AWyBg Hwewxe6AXbHb5gG2aAewBQI2AjYCdghg+7BRvCFsFAA2it09wkVH+gwOE5U5bKNks/82PSWbEzlM bcUziRyWwWGpvWVnfpPV+e16MqhiJ4Nqn+6usLsfZ9qhqpfx2XGUppaFTTvcw3Qb0w7Z0LQDHka3 JibRQ2vWTOaiNwLTmuAjkMGzDu8P5Xwq4Brsg380AbOroN/VTjOwt/rzVQ39fDFr0HLWQBD68iGW lyGWgOWyszf4sgZyO2tgNZsk0TNh00zmoZ/sMM+dVr2UWk49DT2XqGOyBhLIGsjyWYN31lW4kS8H m5aXIQeblsvO3gCt4Paad1aTaZpIRzgd+5EKTaiRSup+6HJq9qY2Da7ghjQct4I7k8n7o1LbP6r0 h3f5o6Ix+7cV8KNS5UvbFcptXcvr1K2dwi+vUx47RcnJvsbJ/nEm+7qwE/1WLrhjt82b7Ot2Jvsa Zws4W8DZQu5sQe85W/CLyZfP4gcbXV1MXjWtm7HGKAuvMdZcdMnYgacCd+DdOo+BbyXCeZyDjQax 8TjYaHbfmlax2waXCXT32zaw0SA2IjY2gY3ZmUMfNppd82H+JLMBsNEcx2FlYznMFgcbvRUgLILN ccDG7u6wqthtqd3utzdg4+63bYCNRbBBsDkY2Lz58h327S6lXU0u9e3mLu6dXGqyCzpoguhwGHRY v6xiS2k3OZE9u20WOjw9iibQYb1VRAdEB0SHQuiw/qjKLVbBR2dKTsMyVnHsHVZxMtbWzPPa2p6b Pp4/7hKooj+uPn1cTmodN9Sx5eO0p3xcGkdathWPKXLkcTiS7r22VrPbhnKkp9+2wZEUORI58mAc mbi2xl+W1njQyhoXr5fDqpGJzUp0YrZjJzXlYlpeGmWpUVTPOfqt1KYDVCNww3E78qnw7shfBhuH aiT14V2sQEoTsQK5fBbvCuQ6MFYsjlE1r7LSajxcL7OgE61WWzDVsaXjdHjh+CxaZUirx6FVtveC ac1um0errB1aZUirSKtIqxCt+hjMqXurwmDeU5EasNqsP/eSS7l75iTSE5yabic4qwal9PSxXsvw 1kpwxpbv1cXFEXZLNaRRHHEgZNxdHFGz24YeHvD02zaQEcURiIxtIKMSKzIurwKQcbnq9XIwwWn4 LNjUndS/nRYTW/53mPUsbWf4YEROgjOxaTjBGdBwpDPS+OHaIY1If3gXcK14TIITkEboHaQRu8bD sBoMdqvO+9OzYO3EQ4bxEOPhe4+HzLCXiPj4OqTS++m687dAcXHQw2wH2Rkyi1GzWY3LYMnGfh7Z PJI+x6Wc2jQYF0MajouLavKfPXQFxvSndxkYZfHAyIDAyN9sYMzIOlXWE+nY6v+6uJ5oO/yjnuhA aZzd9UQ1u21wGsfdb9tI46CeCLG1DWzNSuP4GMyhJrpLcgJQE60/9z2TE1VH+ZzkhGgnOSEwOYGj fBOjfJHkRMJof5cZd9BoX3bGXWvz6kZxSf+Gi+JmNyu3ggSa3Q40hS1taIM3r1bsttToMLhx99s2 prAtqa4QbpqGGy7lyjbLyxC0WS47ewO06tJZ0Y8TsQObDJkM6yzvac+onu1orfaUugZXXVKbBldd QhqOW3Wx3FsnXDusQukP73Krr4zZ6gtYhXRxq1A1AYq+LbztLyqgi9tOt0Mp2k4PhICFbaewAKVm t81DwDhx46EREHWJiICIgEEI6AMbh9mtDtj4BSgaMLvp0ma3DQFKzcl+xqEguV1TqmpgSi/SpNVz kaY914ky9uqIynt1bktnAbdZXPNnt7wXGjV/B6Lcwpq/gFXcit02eK+Ou9+2Qbmo+UPKbYNyKbfc Pn+Kx9cBnPt43flboGQnZbMcup5PVjCycCwfRj70Whs1CUVtl5HsTG0aTHaGNByX7ORK+7OdDiti +tO7mBSIqO1NgBVRl7Yi7hwYM7BVV8bW2AK1urhmcDv8o2bwQNi6u2awZrfNw9Z2NIMaNYOIrYit wdjqYzGHavAuLAaoBnUF1eCeo30Gi5nKLLbhNvDfZnEz4nZMQzPigVistBkR/nVW7LZ5LNaOGVGj GRFZrBEWI5asK+WPr0NY7HTd+VugFKLsGFdCSyqkIIwNRlvGRiGY1vPAR5aRQkxtGkwhhjQcWb2p s35stdvYmv70LrE1xpC9fBY/thbXXFY7M2Nu69r79yOY4ppLu6ULNKi5PA4HmsKaS/jMTM1uG1zw 3d1vm+BAg5pL5MA2OFC97JdUQdsl1bpbUgWcl1mgRYhO8Zlp0fWn/ZGGk5lTQ7hSmucsIac2DfJf SMOx1TtnH/4tg80m/qU/vMttpSLivMzyWbz4Z0qrSu8dDwMLZLjjYRMFMtZbxXiI8fCdx0MqqDZr XuT0OiQvcrru/C1QXJwnOQ28I4oMfS9GJcapE3SkdpBamy7nHGlq02BcDGk4cmuVViwlMKY/vcu8 iC4eGEvWEtk3MKaftzCksITl+jY31Dj+2yxvmTZb4R8t0wdK45S2TMO/zordNng5z91v20jjoGUa sbURbC2xnOdjMYdDudIalZ/FAIeyKe5Qhv19JTdvZGytsnW3VpkN75/3Nk15h/JmTEOH8oFYrLRD GdxaVbPbBi+pufttGyyGDmVksTZYLGtJzcdgDodypYUi7z4hAziUTXGH8p1H+cCFIvco38ZCEcOF IhzlmxjliywUJYz2lVY/Coz2b7KS+nXZJ3PrPPOXfTLlne6bQQKd7geawhZ2usNlNGt227zlhHac 7gad7gg3jcANIS9ss7wMWkwg5uwN0A6Yfu7EQLRWZGZ26kynJZvmkbCRdsyOU8YOmNSmwR0wIQ1H 7oCZiRcBHfra9Id3iYAxBUcNoK81pb3uO8fE9Aqehj9X8KxFrLeVP4HbLK+v3Yz8qK89ELEW1tcG /Dordts8Ym1HX7veKhIrEisSq59YfRzmkBrehcMAqeH6k69Z+L3mwkv65hfDnje/7LkzM2PfNC28 b/r6W9kox+//VsorIzfDLyojD4SNpZWR8CpuxW6bt4rbjjLSoDISsbENbOTCrJt1Ti8DsPF02dkb 4CPwkvVc6I4II+gwk4FLoXQn9MiGgdmsI/BpTQccgYcbjkt0jnb0ArZDGZn+8HyADax1A8pIU1wZ eRMTq6ZSMhKdomyi8wbMb41MAJiXN1zarciPhssDEWthw2XASb+K3ZYaE0as7n7bBrGi4RKJtQ1i ZYTp1XC5vAwxXC6Xnb0BItbRWslHOhIulZ4JkcR2SpKZMULMRHKINbVpkFhDGo4jVj31XmJ1uEDT H94FsXIbcx4ScIGa0i7QepJzc6sLAki3vP5xM5Si/vFACFhY/xiw1l2x2wYfMHT32zYQEPWPiIBt IOCCB+ta9+llAAKeLjt7A4SAnTSis70YZzIISmZKhRBayWHUZh5pTt321KZBBAxpOA4BKWWTlwEd 6sf0p3eZtaQx2wIA9aMprX4suN/xegXwVlPE/SuA5V2Km7EUXYoHYsDCLkV+m6TfsdtSKzIYsB2X okGXIjJgGwzIJBNrGnB5GZIGXC47ewPEgIZMM1F84t2s2ECZGljfMamHjmoxLCEznQFTmwYZMKTh OAa04+BFQIdxMv3hXSCg1NdByIeAgHHSlDZO8nKHtNlVLL0tp/Z4iTuWllY4WkK2QikqHA+EgIUV jpzds9sGrgT7+m0bCIgKR0TARhAwdyXYBzYOJ2Gd9c1laPWBDeAkNKWdhLcjfdU9PxlnSFTd2vs2 VjFgSysUt+OZRYXicTjM7q5QrNltA1Nxvn7bBIdZVCgihzXCYbmpOA+HWYcDqU6Cyb/PzAIOJFtf Dlh10WU9GZFw9Ng8nowolw+7uk17e2TZf5u2tAPJEc/QgXQgDivsQIKXRGt228Btcb5+2waHoQMJ OawNDsveFufjMIf/qNJeL+9CnwX8R7a0/2hjpK+5ATrjhKquW4rP3la68d+mLe0/soRuxTP0Hx2I wwr7j+DjCTW7bWApPl+/bYPD0H+EHNYGh3FF13XJ08uQmirLZWdvgLamkVmNSg9LD9H9NE2E0lEI Y+d+ZOPA+j5ja1pq0+DWtJCG47amTYx6idXhD0l/eBfEuky/w08nWMAfYkvbogoiIL+KpRtFp7k3 lpb2hzhCKfpDDoSApf0h/J7dNg8B2/GHWPSHIAI2goBsfR7LqxAAZOT1cgj/6KDULBTTM+2t0nY2 Yy/0uIz6etSTNRn4l9o0iH8hDUeeThVed4h1uEPSH97lwrG8DkA+/APcIba4O4QXwz9xFUc3SvEJ bxwtLeNwhFGUcRwI/0rLOMQ9u20e/rUj41hvFfEP8e+d4x8lhr/aOJbXQTqO5brzt4B16shgeKcE lYaMWp4WYhU1QhIy0Wn5ezl16hKbhuvUBTQch4Gsk8rLgQ53SfrTu+RAeh2JfBwIuEvWEbIcB94G xpp5kXXhmkcvXNsnh1w5bL2+zVurAnCbpWUgjvCPMpADYWthGUhA1rJit83D1nZkIBZlIIitiK3B 2OpjMYfmohKL+XNygObCltZcbIz2NbcppW8itOx5E+GeOZX144r4j/tk5YBJt2QszSBdWZh0rzvR 7clsoBOVlog4iAElIgci3cISkYAtmhW7bR7ptiMRsSgRQdJtg3Szt2j6KNehxrjLxkNAjWFLqzEq bjzcOGLj57fSagxHgEA1xoHAprQaA07hVey2eWDTjhrDohoDwaYRsMnZeOiDGofr4S7b6QDXgy3u ergZ5Zm+HOXFhrVd+0Z5EbNQw9NHefGYxmQtjPLrreIoj6P82xnlf/z156XL1qm7pV7KbqmgqltK vF4OKpCGielBMq2nYTBjJ/QwSj7PcjBs6MWcsbsotWlYgRTQcOQmc+Jd0BKOBa30h3c51ReX5cC0 LyoKYEFrHR79UZFHVCfTuyZ1Mxa0lGNBq+ZULWOFSD+vEF1/3JrV1tePy+JrjtjHjwuWDC5alDS9 ZLAlzyWDr59uzdpd6ZX1lhl+0cp6N9/KbQFB4FspLRuzRG1lJ1A2dqCsWmHZWECF44rdlloWNt9y 99s2smooG8P51pubb9WprEcZUS+fgp1++eBs6/G687dAMy7eT3zqu1EtE4aZa6LUKAbNNOXzSJXu MmZcqU2DM66QhuNmXB2Z/ec5HMax9Kd3MeW6KkQIFIQGjGO2tHGsnOniBnc3JhN+3C1vHNuMp2gc OxAHljaOwRWWK3bbPA5sxzhm0TiGHIgcGMyBPrhxWMfqwA1QZRmwjtni1rGb0b7qrD8jhWjqWsco iU2V0usq/76wth3VbmjMbES15e9UwTFHcDvFMyc0XWCRo4++fN6CmalzpOo+ff70958///r1Ea7u /L2GbhPwfLFN8MrLvT4By59evsQ/J9HJH378tx//x7/+27//FEUfyAxvkBkqrtUrsz6V5VUANSxX vV4OVgJhuiPzYMeukxMhtpsJY9oO2o6DpVblVAJJbBquBBLQcGwlEO9a/elnv336NPnpXcKVjMgc nT6Ml65eBqm3mDti13FtY63UuxJNr/eqFcge2c2whoKu46SPXr6t/Yz1dbsuNSoMyTx9txEkQ0sX 8uCb48E6JCjpSoKShpCgpK+XQySoGRvnaZhH2nVWs970g+ppr2w/6q7nMoMEU5sGSTCk4UgSNL2f BB0ys/Snd0GCnFxHIS8JAjazl7GxXKJt77CYvrnwdD9PuwursetG0RXgTss7zbbjP0rNjsSupa1m AT/Sml03k13bEZu93CuyK7IrsqubXb1E5pB13YfIAFvXyy++JJFVqppBSWyB39M79uEbNHYdiW92 V3bV7brU2By+acfa9XKvyDfIN++cb6h5KQt2ehlS/tasZcEe3wDl5yzVkttRCLXAyzAPwmjbjWbs DTGzMCIjP5faNJifC2k4Lj+nn75eN4A53F3pT++SBmOKjZw+DECDFexd+4bG9LPKp5uvKm6gZKPK MHCn5Y1j2wyAyrEj8Wtp51jAj7Rm183k13a0Yy/3ivyK/Ir86udXL5U5TFr3oTJApfXyq9+VyooO +DlUJmpTWaxM4fSOwlRGyWZkQ6PWkahsd6VW3a4bWpHX13cboTLUaiGVNUJldn0e1Iac/Viuer0c yijOE1XdPDLL+0EQvjCXmvtx1kJTMxKtMzKKqU2DGcWQhuMyiv3kR1dHncb0h3eBripGPHb6MAC6 7qAeqxsVc9BVOqof1qz8kFGfz5atz3d9m5Rs1ND03ie9rkdRjbTR6HUk0i6t9AJrs9Ttupmk3Y7V 6+VekbSRtJG03aTtBUiH06sSQHoLs5w+DACQxa1eew/26UB2uvnKRLZRJhy40+ImMkdUQxXZkYis tIss4Edas+tmElk7OrKXe0UiQyJ770RGDVuRbHkZwmTLZWdvAD01RsrBSDNLMwlLuJq6ZZTp9Mjp 1Euas6MytWnYUxPQcFz+U1ggAerQt6U/vQt+lXH8CvjbXsbHmvxa9zBlzolnVvvE820VRehOizs/ 6Jarbvk7yK8H4tfC1o+QE881u24wv3r6biP8iuYP5Ffk1yB+9VKZw2VRicqAU8+AzOLlV79rHZqi A34OlZlty13lFEtOHlTXzoPGrsDT67MI1TgSpSFH4sjdrSF1u27oyRxf322EI9EcghzZCEdWPZnj 0IZUOpkDZPcAb8jLr75kdq9WrozeGhsA/rxe3arFOLSOiQMZpwrj0MIekoCpU9Wum8c4tCHZCCXI OMg4yDi5jEMd9o5KjOPPlVHI3kFL2ztCMk9FJ7U5maf1TMTVJ6bm8hPfBqjHK5yf1xOenj8tNdGf lpw+KzU7h9OMTCQlZdeHr78VSm9rf/u/F3od5Qswr97kBrS5HIl5C9tcbn+k+3bd02bxIOb19N1G mBdtLsi8rTCveEFeEUS84vVycG9jPwx67GetmRBDJ/tpkFTMTDPV04nk2FxSm4b3NgY0HHm226/1 ow6ZS/rDu5gYCHIdhLwTA0jmQkvLXHaPiumofbr5J9iuhq63mzihOy0uc3GEf5S5HAldC8tcQn6k NbtuJro2JHOhKHNBdEV0BdHVS2QOmct9iAySudDSMpfdB/scImO1iey2UDl0p8X1M9RsRjXUzxyJ yArrZ0J+pDW7LrUijMg8fbcRIkP9DBJZG0QmiHr5EMvLACY7XXb2BiihOFIySUnUpLi0xHZmouM0 2XkcaSenOadYZGrTYEIxpOG4hOI8zn5+dehn0p/eBb9eFfuB+BXSz9DS+pndQ2MOv/La/Hpb0h26 0+L6GQcDoH7mSPxaWD8T8iOt2XUz+bUh/cx6r8ivyK/Ir35+9VKZQz9zHyqD9DPrr35XKis64OdQ mahNZbfVyqE7La6fYdtHG1A/cyQqK6yfCfmR1uy6oSVsfH23ESpD/QxSWRtU9lLAJqh8zVq8JqD0 ohqlmeQ4mFGJUXMzm4nbkQ+DFVqPlGZkE1ObBrOJIQ3HZROlv8YPdahn0h/eBbaaOGyF1DO0tHpm 94iYg62yNrbe1kiH7rS4y8UR+tHlciRsLexyCfmR1uy6mdjakMuFossFsRWx1YutXhpzeFzuQ2OQ x4WW9riUY5ub0+c0uu7h9WbzAmzDNuMDWlGOxDb7W1Gqdt3QSjm+vtsI26AVBdmmDbah3Fq5Hr44 vQ45fnG67vwtUHpu6KWUZiBiVsM8dN0otBkHKxU9FcsZTEZ6LrVpMD0X0nBceo6rrvcjoUONkv74 LpAwrngihdQodAc1St34mFFYiNYuaU03yo0Dd1pcjeIAAVSjHAliS6tRAn6kNbtuJsQ2pEahqEZB iEWIDYZYL5k59Cj3ITNIj0KL61H2HvRzyMyElXwsvI6Us9irai/23pbjhO60uB6F8c14jHqUI7Fk YT1KyGJvza4bvNjr6buNsCTqUZAlG2FJ8lI5nAQVDif69XIoETrLaZqkppJwI6zQE9NcjlqO86Ts xHLKKKY2DSZCQxqOS4QqIA3qcMikP7zL4zU6amUccsjQ0g6Zu0fF0AyLJyqyhqIiw6iIUfG9R0Up 6PNnWF4FRMXlqtfLoaioO2WE4LMcDBmpoYNgVulh1FRR1s05u/dTmwajYkjDcVGR0TEpLKY/vcsc 1E0UKhAWGRAW+RsOizkZHVs5o8NihSWnd+yS0WEogztQRocVlsEF/Eirdt28jA5rSAbHUAaH7NoG u2ZldHxExhwiuLskKhgkgmOlRXB3H+yzEhVPj6ONRMV6rzjY42D/zgf7rERFymB/l+l34GBfdvpd a6sru5UCAVtHrk/fVpvMouXxSJPZwpbHgF1PVbtuJt80ZHlkaHlEvkG+yeMbh7ywDt8AW1wZJC9k peWFBY/yXPu62a1iB/B1Xx9eqMY3qAI8Et8UVgFydt+um8k3DakAGaoAkW+Qb/L4xqECrMQ3zM83 kAqQlVYBbgz2dSezGUd4GA08wlN2eSFjwwcjzxs+9g2o6zNmCZ/4Ube49IpqW1SixTzXcb4A9cpN ckDd4pGod3/dYtWuGyrA9vXdRqgXdYtIvW1Q78Kd64c4vQxSYFN+9gZoi3Wv6Mh6TeeBEyYNJXZS duiH5b/JTAeWscU6tWlwi3VIw3FbrDX1H/NnDt1i+tO7mCPIuA09kG6RVdAtVlvjvRUCQXOL4vJC R0RFeeGRaLCwvDBkjbdm182kwYbkheu9Ig0iDSIN+mnQyzgOeWEdxoHWeSF54fqrr1jKqPL0Pyer WFspzaJ9N9dxyBfaWBiVqc3IVkde6Ihvp5DmZKcLOnL20/L6vnOy6j59/vT3nz//+vWRse77vRoe Riye77URYrkQ+/3p5Tv8cxKe/OHHf/vxf/zrv/37T1H4gdDQCjQYYlZLCTEhmhJiXi8H69Zwrrup l3RSnZZmQYVBMULY3CvbqYVWMurWJDYN160JaDiygPcSALxo5RDspT+98whhlIxKH0GCPXYHwV5d 4LD5kel9nAf7+YKCPnU/T0s3fPocyyco1j//+eIplG35/NmVb7n6I3n6uj/851TjqWQ3vjXs3fa8 ML5hyDcH4ZsSn8TNFWRNRdxe+v3Dp8/nSOOPSPvWjKkckWR2ROLvIiKFjSUcx5KDjCVvZa50kDGN A2OaaGtMEw2NaQLHNBzT3uOYJoAxTbY1psmGxjSJYxqOae9xTJPAmKYONKaFnq70jGmqoTFN4ZiG Y9oO63SMGvX8IU4vA1bqTpedvQFcq+upHLVghA1k0pOg5FR3UCmth+W/5JSzVpfYNLxWF9Bw3Fqd MV3aWl3y07vcBmUqrNUpIDrpA0WnAmt1uqHopDE6YXS6jE4//vrz0m3eZox6byOvBkZec5yRt8D2 PdPQwGtw4MWB9wjTgvsNuVbUGHINMOTa4wy5JWDXvosxN3ZjWmL/DNiYltwyuDEtq+Xqj8S/dyzz qWQ3XnJjmsXIfZDIfZDFAQud7iFthSRK3kVMCjzGQ3A4Ochw8h4yMFS9TAdOL0OOAKt1OvD4BmiV YByFJoR1vNdKDZ2S89gpMlOrKe2YnDNWCVKbBlcJQhqONFHbtIlT+tM7jwmSVznRA55CpTlxqnJ9 jJyykeK5bGS1IjYq+k5VcEQOLGLDyWZAVljE5kBFbNT+RWxqdl1qdBBM+vpuI0fCFRaxQY59axxb hWAFNS+fIeQ8+nLV6+UQvbLezo/JpE6I5Uel+aClpFqPdDBmtjn0mto0SK8hDcfR64KafnpV2/Sa /vQuVlpVnNJFQfSqqpf62TksBsqofWHxfZxHDwuL6CfFsPjuw6Ima15neRUQFperXi8HwyLjjA1M 8ZHrSZCZUanpIIxRrJv63iOehsNiYtNwWAxoOC4sLq2lhcXkp3cRFrWsEBYLHoqvaTrT0XYLvVOC RGOC5EAJEr2/6axm181MkOiGEiQaEyRIgk2QYFaCxMs3etdpP2A60xDf6Pqms30H+7xpv25o2q9x 2o+DfRODfda0P2mwrzOZLTLYl5zM7j3Y5ygX9bNycd+sdM6OClV7R4WJvlNTPGFAN+OwwYTBgRIG Zv8dFTW7bjBDevpuIwkDgwkDZMgmGNIQ8VLhXwRV+Bevl0NLR8SM1o695GSYR6O1YiMhfJqnYdR2 VGPG0lFq0+DSUUjDsRX+hZ+2zTZtpz+9C9q+OkgJLR0ZiLZN+R0V1ZaObDSl251I0CIJHogE7f5L RzW7biYJ2oZI0CIJIgkiCUIk6OUbuyvfANlEC/GNrb90VHfan5ObM8+5uX3PEefoLGVlnSUnsXd6 vQZXgCE3Rc1LG8iQh2HI9dsqKPO8a9cNZkhP322DIdd7RYZEhnznDCkWGls/xPIyZAPSid9e3wBl FDtG51l0nBo59KPWjEyz7eikRymHUZmMjGJq02BGMaThyDNaVBEvci9DziZypz++C+S+8rEDJQaW D+NH7nWALCkNrbW4fMnGIah+nUQpgIN6M6RSxMED4SDdfXG5atcNxkFP320EByniIOIg4mAIDnoZ h+7JOMCy6fJhAMah1Q+iV57/ZyTplhhROUnHou+U7URlDKnsQFTG9k/S1ey61JgcKmMNURlDKkMq a4LKqCL6pQwo0UFlQIk+ewOUpJNGajVr0RszjzMZ9DwIMdjeDgNh2ubIwlKbBpN0IQ1HlgEV2s+v bJtf05/eJb/yqBwdg/iVlc/R7Rsac/iV1eZXHn2nfCd+5civB+JXvj+/1uy6mfzKG+JXjvyK/Ir8 GsKvXirjb4nKOERl/A5UVnTAz6Ey/kxl++6lzzmsbbcPazN9+YnF7e7Kx0ucH1iUl7SIrb3/4lEG wFuIqOutYkDFgPp2AmpFO4yi6ydZXgUE1eWq18uhlFBvJsEnPc0D452xnLCxE4Qu/zOpUZucfVup TYMpoZCGI4uIKumDD+EQw6Q/vAv20JehnmkfewjAC7MOj37yEOHksXycatmVW5kMRCwemcx1dkUE ZVc2w+nydzC7cqDsitg/u1Kz66qw5Iqv62YnV06j1cO4oUG9vuj5mhwWBHMoAnMojSNftZ1QzK6Y d5pbwvuglqniy+XefIXYZgbTDcKquSPadLOZDReKWmnn06tu5jyMGSi1UfkKAeUrxB3yFVWj/9YI KhgwgiYkQNZn91jE89dPj7TgTIyI2stV0ac/r0+B5S9XOaKSRKA6EFDJ/YGqZtcN3QTv67uNLFdJ RK3GUesNZtfqoB9fn4fgPqU8fb3+9XIorzZN86j6fuzMMA7jKGbFOzWroSeED51iGXm11KbBvFpI w7HOuskPyY7EWvrTu0isqThIhozL69i4KyQXDYs5i3rV63nc1kGG7rS4b9kR/9G3fCR2LexbDvmR 1uy6mezakG+Zo28Z2RXZFWRXL5E5dIn3ITJIl8hLW4R3H+xziEzVJrJblwZ0p8UFj4JtRjUUPB6J yAoLHkN+pDW7bjCRefpuI0SGgkcksjaIjBpB183v5jQXgze/L5edvQHKKIpZDlzzWRFmO0mUGXln WWe51ctY09mMjGJq02BGMaThuIyi5tTPrw5DWvrTuzwmEFdgDTKk8dI6zN1DYw6/6tr8elu9GbrT 4r4xBwOgb+xI/FrYNxbyI63ZdTP5tSHfGEffGPIr8msQv3qpzGHSug+VQSYtXtqktfuAn0NlpjaV 3R76hO60uPtL8M3Ihu6vI1FZYfdXyI+0ZtcNpjJP322EytD9hVTWBpUJJl+Op8ig4yny9XIooziO pO95p6lURBpOB8vGwU7DPAqi2ZSzRzG1aTCjGNJw7B5F4CCPw5KW/vQu2JXHrYhDljRe2pJWUNlw Xf5D3JZBBsp/iOIGr+1oKtDgdSASFIUNXgEW2Kpdl9rtvhtGgqIhg5dAgxeSYBskSIV+Ka62vAzJ zy2Xnb3BxzjCoaUaiDFK68F2vbFmJp02RHDFVUcosV1ocbUrxgFMsALSUonSWqrdB/yMUmWCPJcq q0ZlGzYi4E6Li7QckQ1FWkeistIirZsfaYX8XMCPIz3PnvJbcqbp7XOavlpGUTSk/hKo/kKObIMj szKKXoZ0aL/q5MkghoS0X6K49qsYkd2ENRGtW7jeuVONyFCidSQi21+iVbXrZubJGpJoCZRoId+0 wTd182QONVSdPBmwFiggNZS4gxqq7ICfsY9N1FZDiWjdwnUcqkZlqIY6EpXtr4aq2nWp3ay9GUpl DamhBKqhkMraoDJm6CqcP70MoLLTZWdvgPaydZxTyiXpzcyHnhE99axnM9dy1GrQOXvZUpsG97KF NBy3l60nzM+vDolW+tO74Ne46i4CkmiJO0i0yobGHH7ltfk1uvy2iCi/HcivYpMBUL5xJH7dX75R tesG86un7zbCr6jlQH5Ffg3iVy+VOVQh96EySBWy/up3pbKiA34Ola0Gj3130eXsF6Rl9wvefjfR FaojpKihHCk3YzE6R47Ekfs7R6p23WCfr6fvNsKR6BxBjnxzHFnR6KuteP4ky6sAllyuer0cNI8Q RfnSRfphFExN1A7MdiORrOv01ImcOoGpTcPmkYCG4zKhnHZ+5naZR5Kf3gVz25tY5GVuyDwiKphH qp0fua2PDZFvcY+HJJsxFT0eR+LBwh6PkENeNbtu6GkMX99thAfR44E8+OZ4sFJekdCXvCIJqbp3 uuzsDRAN0mkQ/TgPHevF1M/cUEMHO+mRDPMsB8/ORJAGU5sGaTCk4Tga7GZ/fULhsJ6kP70LGhQ0 6uwKZD0Rpa0nu4fGnHymqn3++bY+NnSnxa0nDgZA68mR+LWw9STkR1qz62bya0PWE4HWE+RX5Ncg fvVSmcPlcR8qg1weorTLY/cBP4fKdG0qu62PDd1pcZeH3D6xgC6PI1FZYZdHyI+0ZtcNpjJP322E ytDlgVTWBpVxRdnzhzi9DKCy02Vnb4CyiprP00JfPZ97KrXSk2LcdDNVQ2doL3lGVjG1aTCrGNJw XFZxooOfXx3Wk/Snd8GvXEfxK2Q9EaWtJwVpkF+H1NtCb4/XeEJqcYeII6KiQ+RINFjYIcL5fbtu Jg025BAR6BBBGkQaDKJBL+M47BiVGIf7GQeyY4jSdoyNAb/u9D8nR2eec3T7hqj1E/OET/xY5HZ5 xrWyijK6qvf16lYBjtzc/y/RQHIgjpT7G0iqdt1gjvT03TY4UqKBBDmyDY4U9KVyNA2qHE3l6+VQ RpFp3iku5llPM7eECm57TrlUStHRdjn1e1KbBjOKIQ1Huujs7KVt6fC0pD+9yxVxE5NRlJCnRe7g aaHXCoiNc9fUr4AIOHdNEzzKT+euaTF2vb5TGX2nsrinRarN+I+eliOxa2lPC71v1w1mV0/fbYRd 0XqC7IrsCrKrl8gc1pNKREb9RAZZT2Rx68ntYF83UZGR/5S1zXnytvY5dKfFPS1Sb0Y19LQcicgK e1pCsok1u26op8XXdxshMvS0IJG1QWSMrZqW5VXIuRGmXy+HsokznfmguRID7yWXQy96Yjvb910n ul73GdnE1KbBbGJIw5H7E7kfXR0ym/SHd4muUcI+CclsZGmZzf2jYmCewhMVWUNRkWFUxKj43qOi VOr5MyyvAqLictXr5eCufT1xwTQ1XacZ50INnAy9munIGJ96lbNrP7FpeNd+QMNxUZFxlRQW05/e RViUUbv2A8MiA8Iif8NhMSejw2pndG5tINCdFne8OeI/Ot6OlNEp7HgL+ZHW7LqZGZ2GHG8SHW/I rm2wa1ZGx0tkDmvZfRIVkLVMlraW3X+wz0pU8IYSFRwTFTjYNzHYZyUqUgb7+0y/wwb7stPvWofm 5a1ECTjWJYsLHx0xAoWPR5rMFhY+Bhyar9p1MyezDQkf13tFvkG+eed8w4x6qWsZwjfLVa+XQwsx AzvtBh0GPfXz1KleqoHQXnFplw4j5zljISa1aXAhJqThyMNOdPKToEOLmf70LkiQ25jSAhLSYq5j Y83SAnXDYsZBfSkKH9S/udNbUx90p8Ulk474j5LJI7FrYclkyI+0ZtelS9jJYNeGJJMSJZPIrm2w q+Yruy6vQvSSXL1eDuolO22nwRppJsH0QHoulOy7jgvaT3PW1trUpmG9ZEDDkZuIJuJnV5deMvnp XS5ZySh2hfSSsrRecvewmMOusja7bqiTgDstL8Q0m/EfhZhHYtfSQsyAH2nNrhucd/X03UbYFYWY yK5tsGtW3tVLZA7F432yiZDiURZXPJbjG3EdJDYkRMIfJMoLE7djBAoTj8Q3pYWJ4r5dNzg35+m7 jfANChORb9rgm6zcnJdvHLLEShkn4ecbSJYoi8sSbwf7upukc46t8cBC7GWn3zk5MvWcI9s3oK6f WCR84ichpah3NDC6rP91nK9GvSikPBL17i+krNp1qbE51NuQkFKikBKptw3qZZzZNa23vAzJ6y2X nb0B3FE5kZ4ILc04mGHmTHIqGdWGzcM46a7L2VGZ2DS8ozKg4bhVafv09bqx3CGkTH96l3MEHnW2 BhJSygpCyn1DY84cwdQubbEheQLutLxC024yACo0j8SvpRWaAT/Sml03mF89fbcRfkWFJvIr8msQ v3qpzKHQvA+VQQpNWVyhWe/Es9ooPe/Pn6ryesfNOKFQ73ggxlGl9Y7wzruqXZdakcE4qiG9o0K9 IzJOG4wjJF8fyOlliCRHnsaTlzeAJ0cmO5qOMcLssPy3ZlxTPU/9ZPjMjck6OZLYNHxyJKDh2FPP vd+orhyOx/THd4GDksdsVFSQ41EVdzzuHRszlsUVqXx0RG2I8oA7Le943IYAdDweCWBLOx4DfqQ1 u24mwDbkeFToeESARYANAlgvlTk8j/ehMsjzqIp7Hm8H/LqrMjlLpzZwe2XZEJXDkbQwR15/Nyra 2KDKmym3YzGaKY/EkfubKat2XWpMDkc2ZKZUaKZEjmyDIylh6xmd08sAjjxddvYGKBF6Klg9zZpy PXCubGe5IkM3DaLrx3FiNiMRmto0mAgNaTguESoIkAd1eLjSn94FcS/MFbEsriAPl6qgp6yWVdw4 CAVwb3mr1XZERavVkWiwtNUqIKtYs+tm0mBDViuFViukQaTBIBr0Mo5DdlKJcYCsIiQ7UcXNVnBW sez0PyOrqFhoVrFoiMrJKvLaWcWN8uPAd1NcKHP97J5vHYUyR+LI0kKZgKxiza4bKszz9d1GOBKF MsiRbXCksKsddXkVsjZt9evl4PHnXnDBOkWJlIR2nI8LPCo+68GIfmYeOR58/Dmxafj4c0DDkVsr Z+qnbZdQJvnpXdC2jjpooyChzDo2HiKjGF3MWxXXsziiKepZjkSC++tZqnbd0H2Kvr7bCAmingVJ sA0SZEqK9TCxOgnZ4MPEy2Vnb4BocNaqJ4McZ0JlL0YxT3xWvJ972zEjO55Bg6lNgzQY0nAcDXbS rxdUDkVL+tO73NEZpWhRkKJFVVC01CoIrjbKVvqLQKriwhNHREXhyZFosLTwBC4IXrXrUstyaLAh 4YlC4QnSYBs0KAh9+RDLy5DM4HLZ2Ru8jOOQnljNJkn0TNg0k3noJzvMc7eAj5RaTj0NLS2jY4qC K0h6oopLT9LLP9d433XwUdfBx4Ri11NgUv7AVLzctCMuBZebvr5/fX3/GyeItP8eN04QbVHb9V+W 1395o2y59P/lq7LlSVwY+pUU+eoqQejFUwjvO7uz63Nnvaot+fxP36knaB9KPytgvvu3WmRaoHZ/ ZKVNR/LddNl3OpMtXSRV7xBM6wfN4JWTMpPq8Bn3FuaU93Gd943ghpPm7CGfxj17fwNpgoKpBXSN VUwtbD/y/ELBwZmCgt/Ny0w/5nt6O3mSg/SY956MCpj015vYZ+5EfZcyHvgrc4xib0fXk5zg3Ccz eshF9fsEY2/y1lEXPH2B+s0N5N4Vc/22xnnf9wTktYuXTN94NGDgqXsEIuBkVfLg4zzgJJ6PZB1u P7f3Z++SNNXZpaz8fRuSNKnikiZ1jJU1h2630sqa9H9LkG5XFdftyp23UmSoYJV6VsHuuxU45+Sm rHxyU29UUPaP/bq4GGN7zqFRjHGgvLYuLcaAT25W7brUbvfdsPmybkiMoVGM8cbmUm9qsvSedmjJ Vf0lQ8Rf0r5cDO3TF92gjOonaWY2zpLqiVE9UjIwQno55wgxUpsG9+mHNBy3T5/3XtDWDh1G+sM7 jz+SyJhDmxrSYejiOoy9I2JGiRRNKjtr9UbBZuBOi+swHKEfdRhHwtbSOoyAH2nNrpuJrQ3pMDTq MBBbEVu92OqlMYcG4z40BmkwdHENxt4DfQ6N0do0Fl2aTxeXSjgiGkoljkRj+0slqnZdalQOjTUk ldAolUAaa4TG1AuOqSAeU/b1ci+ROTQJo7bU2t4oxs2woFnXcak573hHh0l0MrSMhYgiMkiToCto EvYd7HOIjNUmso3Sw8CdFhc7OKIaih2ORGSlxQ4BP9KaXTeTyBoSO2gUOyCRIZHlEZlD6nAfIoOk Drq41OF2sK975mUlMpWw0c48EpnaOTzlMCR3aCjqFNO4/sQ64Rk/6XhvTyzXPU+8fmKZ8In14yeW 9Tg9euu9Li/OUJusg+KMI3H6/uKMql2XGhvG6Z6+2winozgDOb0NTlfr41AkgNIVebkYlGZMPZ2t 6cdJ0q6b1GipYt1s56HrjZlytl+mNg1LMwIajtx+OfgnMy5nRvLDu5zMmKjJDOTMWIfFXdPLRSNi ztRA1E4vb5yPAu60vOVDb4Z+tHwcCVtLWz4CfqQ1u24wtnr6biPYipYPxFbEVi+2emnM4ay4D41B zgpd3Fmx90CfQ2OyNo1tnK8H7rS4ZeP6INHzraNl40g0VtqyEfAjrdl1Q2ue+fpuIzSGlg2ksTZo jPK1WtPyKoDHlqteL4cSiQtzKUuI1WZWXderUatZCjPoeZZq4a+MRGJq02AiMaThuESiAXZFOFQk 6Q/vAl3FTRDyoiukItHFVST15Lt6Y93cX7ZIh9fhDgVBuhlM36lX4Z2CYGkrASzfrdp1g0HQ03cb AUGsiY4giCAIgqCXbxwFISvxjV8nq6GCkLp4Qcjbwb7urD8nNacceyjp1SeWG2e5qfcTy4Cz3DT+ E8uns9x054CaUcJS68IlLK+/G72xh9j/3ejiQrzrhfznWw8W4iH1vgHqNYWp9/ZHumvXpcaEUa+n 7zZCvW9H6IDUi9RblXqtoSv2Li9DuHe57OwNUApU8WFgphOG2H5gwmjNu26WwzATwohiGSnQ1KbB FGhIw3EpUN2P/jmCo7R/+tO7mCMwex2JvHMEqLS/Ll7a/+6hMWyfli80soZCI8PQiKHxvYdGzpR6 /hCnlwGh8XTZ2RvAYwajotqSoTP9MNBBM90Ngks9jVpTRj26JviYQWLT8DGDgIbjQuMS4JJCY/rT qx8aGRAaeVRorLZPbOMgMJB28xwELpoosZgoOVCipLTDOmCfWM2um5koibM2H5sG8/29SINIg0eg wexEiZdxHELPStN/YAsUZK3Uxa2Vdx/ws6b/tqHpv8XpPw74TQz42dP/lAG/0qS2yIBfclIL77Ao m+/N2GGhjWOHRd0QlbOLxRY+YHb93ZgNr5T/uzHFJaHXO4Cebt2gJPRAiQNTWhIKLyNV7brU6DCO 9PTdNhIHBiWhyJFtcKSibD3vT1nIgX/KXi+HlpC4VgPTfFYTH8Xy/6idCWWciIF0lg8eqTy4hJTa NLiEFNJw3BISU8JL28ZhCk1/ehe0zXnMEpKBTKGmuCm03hKSiXZameLeTUc0Re/mkUhwf+9m1a6b SYINeTcNejeRBJEEQRL08o3DvVmJb/zZRAO5N80O7s260/6MbKIhz9nEarm5DacVcKfF3ZuOqIbu zSMRWWn3ZkBurmbXzSSyhtybBt2bSGRIZHlE5nBv3ifjBLk3TXH3Zjm+uT7HbjZ8S/5z7Ka4ydIR I9BkeSS+KW2yhGsaVe26mXzTkMnSoMkS+Qb5Jo9vHCbLSnzjr2lkIJOlKW6yvB3s605mczJOLHD/ WtkFkYz9a4Y6qjDVDagZNY0Mr1zTyGyohIDeVNwLeb2/8vnW0Qt5JOot7YUMyOrV7LrUbvfdG+r1 9N1GqBe9kEi9bVCvfvG36yB/u1797afLoR131i43S8bJUjFMI7GETcoorvm03C63OTvuUpsGd9yF NBzphiT+A43GIYdMf3oX8wMRVbTBQHLIdWx8i/nPG0qP1hiZ4qpFRzRF1eKRSHB/1WLVrptJgg2p Fg2qFpEEkQRBEvTyjUO3WIlvgB13kG7R7KBbrDvtz8l/ito77jaq1wN3Wl63uB3VULd4JCIrrVsM yM3V7LrUshwia0i3aFC3iETWBpExa8z6RB5fB1DZ43XnbwFrjhPLdd9RxhTVYuiU5LzvGJOyp2xQ MqfmeGLTcM3xgIYja46L3vgh1iFeTH98lxAbt0kREi+a4uLFveNjDsSq2hC7oQcC7rS8KnIbBFAV eSSILa2KDPiR1uy6mRDbkCrSoCoSIRYhNhhivWTmUEbeh8wgZaQproyseHxko6wgsGWwvBxwO1ag HPBInFNaDhhwfKRm1w0ugezpu41wDsoBkXPa4ByxQMbLhzgVPwcp53TZ2RugRN1subCTMHIw1vSz UB3plBnZqJWRhIqMRF1q02CiLqThuEQdJWLy46BDgZT++C5xUEadtoEUSKa4HXDv2JhzEsQ8nwTZ N2uRk1rUtVOLG3WxgTstr5naxhbUTB0JuUtrpgJSizW7biZyN6SZMqiZQuRG5A5Cbi9HOqwjlTgS SCtC1hFTXDMVcAa66Bb1nDPQ0nEGum6IyuFIW5kjbXQNR1veOmK3YrFF68iBONLubx2p2nWDdaWe vtsGR1q0jiBHtsGRpyXiVVe6vAzRlS6Xnb0BNI8QLYgmHVVMG84YNZMc51FO08BHw3JSt6lNw+aR gIbjUrdi6LzEbV3mkeSnd0HcPIq4LWQesRXMI/uGxgx+tbUrc9uN+krAnZZ3pWwzALpSjsSvpV0p AT/Sml03k18bcqVYdKUgvyK/BvGrl8pcvpS7UBnkS7HFfSl7D/g5VEZrU1l0nU5b3JdyffL9+dbR l3IkKtvfl1K1656OnIVQma/vNkJl6EtBKmuDypjR67GX0240+NCL0a+XQxlFMguqp5l3dLL9SLq+ Z9yYebKT1YMgJCOjmNo0mFEMaThyMyid/ezqMMukP70LdpUmil0hs4x9w2aZ67V/u1FN3L/2b4ub ZRzRFM0yRyLB0mYZuLJi1a57moNlkGBDZhmLZhkkwTZIkBKxouDpZUh+brns7A0QDdLB6n4iVpuZ 99M0Sj3ZgQ22F2wcyNhn0GBq0yANhjQcub5MtZ8GHR6e9Kd3QYNKx9ShtJCHxxb38MD7I8smSXIy maEenrLBPGMPquXPe1Cr5V6ja4Ta4lYbB7Wg1eZIxL2/1aZq183MvTZktVnvFYkbifudE3dW7tXL kA5Xy30yipCrZf3F77oaXnSwz2HI2rXM7cb5J+BOi9tlHFEN7TJHIrLSdpmAH2nNrpuZA23ILmPR LoNE1gaRZedAvVTmMMxUyuwBVAYZZmxxw8zeA34OlcnaVBZdhtwWN8xc10t6vnU0zByJyvY3zFTt uqEnR3x9txEqQ8MMUlkjVCaokiuWnV6HcNnpuvO3QKvTzAw9Y1qoaexGMbBZdrwTRqpJ247pLmN1 OrVpcHU6pOFIC7SW0g+xDsNM+uO7gNi4OuYWMszYOxhmysbHHIitbZix0QUvbXHDjAME0DBzJIjd 3zBTtetmQmxDhhmLhhmEWITYYIj1kpnDMHMfMoMMM7aCYWbfQT+HzGoX6LYbxdOBOy3uxLkuSvl8 6+jEORKZlXbiBPxIa3bd4EVfT99thMzQiYNk1giZWb4W6D69DOGy5bKzN4BOHDLyUTPTU24NUbzv hln2eui6wZpJ5Rx8SW0aduIENBwprzZ+JY51KXGSn97lpkUaxa+QEscWV+LsHRpz+NXU5tfoEui2 uGDGwQAomDkSv+4vmKnadTP5tSHBjEXBDPIr8msQv3qpzCWYuQuVQYIZu4Ngpu6An0NllXUtjMQW 9j69ozCVXR+Mfrz15e8glR2Gyl6+rf2orG7XPRWaD6EyX99tgspe7hWpDKnsnVPZ8nt//gzLqwAm W656vdxDZKff0CaRWbs8ADJOlophGoklbFJGcc2n5RFwS0PXeW0EkZ0+jJfIXn7xBygXyMhGiWxv mZbTO/bhG9R5HIlvSus8wHKBdbtuJt+0o/N4uVfkG+Qb5JtEvnGoPCrxjbcA3unDAHxTXOUBFsAr PJlNzzid4C6oAF7h8JReAO/0dVUtgMdIbHHC0ztKM6TajMMoHzkSQ+4uH6nbdUPPRPj6biMMifIR ZMhGGJKsC5fLqxCGJOL1cmjXnTbzLLuRT0ZNbPmWZD8wbdlMeiGIWOg1fdddatPgrruQhuN23bGB +GnbIR9Jf3oXtM1iitKcPgxA28eRjzASW/T59I59SBDlI0ciwd3lI3W7biYJtiMfeblXJEEkQSRB Nwl6+cah06jEN0A2EdBpvPzid80mFp3252QTA3UahcNTTjZx1WmM3fTz50/fP3z966/fxs9/+/Tw Zenx04KM48PSf5fP8uHbh6UPj985N++Jx4qD1LguMI//nlFnA4+b/xj7h//+x58evn3phuVf/PTT H/lD93H68u3hb18+fJu+/1v35dPyfL5/fOPDp8/fPsx/d9/cY4OyWINPd8i08w6essnMPhL5+PIs v3/4W7c8vuev9bSdYPrSnd799Z++dV//n8eePi9P+Otfb9748tyXAPvD87A2dEs3WTrNx2mJJH/p Pn70/runFsflq/zyefkZz1+m6fRJvv59+W5/Xr7lr59//bL0ke/WP/3t8y+/nL7m/x+7oXWuNvIJ AA== --5fnLV4VEuZ Content-Type: application/octet-stream; name="slapd.20.debug.gz" Content-Description: 2.4.20 Content-Disposition: attachment; filename="slapd.20.debug.gz" Content-Transfer-Encoding: base64 H4sICNYyGEsAA3NsYXBkLjIwLmRlYnVnAOxd63PbOJL/fP4ruL6tW7kqUUTqYVk1mlrFci6uk22d Fe/sNxVEgjInFMHhw5Fmzv/7NUCQBEnwIcfOU1O7MYl+oAE0un8AQeqfrf88Uf5+42JnNp3MR4pv I9dQtHavrXWU1hTritJVtE7nTOkMR73OqK8C+9F/eIQE/5zM57PLyfX5hdb+bX7Zvpjejd4EhNj+ G9/T3xDQaRvIfXP7/mLWf70dDpaDXlL6OqrijY+9B+yBBK33iFKW7kOwXOPgnvjBauegDV6ikULv xsUKXyneuHNkILwhztJyrGCk2JYfYEchjkK1jd68eVNF94sMGmcBs5SAKNTidrsd2RZ69tJFno+X eBu04gpOuIJRIqlQVRayrT+xkdpRosJvqENia0+wlRqKeR/qHkYBPopGM2KNtAWgK+rzNqMufeTb S5GD1fe3o5WxWq6Q/nGZloocytvpW4XSsWPIed9i7yO28U4Bxl67D4M9UloL7AZ4s4LGaZ1X1K8G J0f3NTW9F2qS8jau6ddff1UM55p4Gy75y69Hv/zyS6GsyKc7Yz90sRdC3/mvFBKOka5jHy4NffzJ tdhfbIQyfVnZVJRLxoJEX+r3GJqGbJt8gmEKdi5WjjesEcesj+F/0Uhdxq23nDUbCQMFaIV8zE2f ezgIdpERkQU2Wce2yYmvUrYyHVfIQWvs0SZMkibARKR/YC6W668TjOrepFzyHvqcLmhiacGoXP17 9YsouFe/CIIN+6XorkAFyhz8jTh3d5fTsYbM/nBgmINhp7Pqdodn+gqfrvSVqaEzrWOYVPkcE9fG 8jH9bOVuorzacmgvcl3b0lFgEae8zdJp1khSWqeLNnvWVSnxLQaQok21zaxtFdhiYEhmwQY7QYN+ q+aX6m86JHuMxbO0W+7QUrv28P0X98OD5T+Q5TNr5SFvN0eBt3estCNZt0b20JpDa8CiTwZ5jWy8 fW05JtmzNQ1lD605tObLtMYNg6Vp2QH2Rspx679a/9dK8OzEBILFEOTYRHpoB7sTOdUPkGmenLT+ 1hLx8NyzHpC+G7vR35OTk+NMdZPrqXC/pIt3MOElDTjONfdz6srqurmVNOXJyvN2VirKMvvWBryL FUWXqZoqLY1qlBm3b31MR762vYbt+uaDpK+rFOSra85b0boKJcdHsMhY+jpyTMXcBErrr83m8USB wtGTKF8q4ryYVjpGzZYtUk6pTt2fNdaq+831Yh03VwzMzTUjO9w0V025m+v+nrzhZXKluN+x95ZC o82SbyeIvEy35qFAVQshZIu0DSD0bJQPDewEDVP+c1T05WN8PoU9wUx5KmuiqDRfN5ZpkrjLlT0t xX0Zv61BE8/qus9U1w8PiA6T5RuZLF9iCv5w3vtjDNL3p/WFHt0SxwqIV/EokjPwR44x+8voyyHR nLIctVp2Ea58/R5vUOmDs4S+QYF+bznrpRfCLAh9zJ4kHynwn9rW2sNep62q3X5/0Fbbvfaw01Na lhPgNfbeWsGNd0XFT0ZKrOYWtNz5UE2rTPx6cnWh/KOg4x8KO8dysQBJP3Rd4gXYoKdv/gUzEUKo 8ncFAqi3+xDYcBlaxnXIzjH8XVkL18TWz4mjh56HHX2XFDhXaDvHjkGfikvKJmFwH5VfGjb+YG0w CQNe4Bh4S7sz8C7NK8uZYUdGQFsZYeLsSooXAXaF8ksnSBhnREf2YvEuugPNU+xhc4rd2MZbnCxR QA57D8iOCAuif1yF1JhLRyebpLHF8rTBH+49jAyf3xBiZwp+86wg2x/T1TkCz3nnYZwpWNAzKbxg eq3niy6ns0LZAiNPv18ESP+YFN1v/gfzYVu4C1h6QSNhCkPJBlk2TCgT05HFN24Q+YR/jwzyaYb8 4PweOWucFMFYpddom1z/hjwn6pno/tJBemA9pIIXW9fy0tt3NqLMFljjPVg6noNjsvu5RwKiEzv1 PUe/dXV+e6KclM+hrjiHJo6x7yTqFiZRrOQwiw6z6IecRd125PxqW+0N4LJzBlOi19aUlo58fLl2 iIcvJ/3KmVSqI5pNRUXibEJ2sGAnBJMBI45p0UbpvF/hj0Gvke8TnZ0pnBIoZ3OO09Et1olnUIFp evnv5NJZJJf+zSS51qmByd3vyMHBFShckS2vmnn7xDA8GGte9J74Ab+8Bb+j7prQPVMfahpVcYXj 6Q/aKemebPAURk4HcEFdCNzGchb32KbmR4dm7iwjub62/GscrD0Sumw4aa3JUFou0D4R72O2ZIP8 tGSD9NSuFSHBO8umbuNY/hVyL2isov0XA3IosAIb04My9c6hRs5xsQXffKJvqIJvZPQcXON7cA2t 3W+r3Xb3DDwBe4Fl0ojPdvVjZxC5hgUuNuQVfpNKcjcpE8+4C6QNAilhd4sfSJSBKDMdzFS8QDOw HaBcab6Z/UwDZE3sZTiaNq9XbJ68afQs3nnKRJs0Ee/zBneUFln9Dh51SXdHgAt77ywPshDZuMSB ogbGdbhxDRRJ0RFM1sAj1IeToottgB0Ol5LCdxgFIXgj9XwDuYudE6Atu01YJunDA6oVbwtDpJ0l 0G/fhoJoBvU1bd8B/R3Q3/eN/uIJcKq01vSljuhlDNqlDWbNKZ81MklxvkTvhlCSH6ANdawNMSxz l5bkzYFY6nL7Lx2TbrDQ/mxgUhxOy6RTsyQcOSNgKRk61h8hjtJ1g9rjxWNBLK1WJOXq02ijsQ9h hFnDE3SDarWk0XJpsdEFjpwRkDYCbGP3HkJf5CsNDIjzhExSdIQcnQOfOS1hTrGKUIhL3z6Av+J2 8SLa5Y94c+6igvcSPcDBIvDAwHqD1dhz81L5hDsHVPkpwn9RLPF2bkBDQN6CgdJaWc3rH/D6szJp 7dt+p3PHPCVNurka083CBvXltgYPGe2Q0X7wjKZC9IaFjY1Rg7ShxoFblBDnxz3ywZMgEFgOZDI+ VhBAGRR1gonOHeK/4cbG7+/m0e17yzASL4MeuyI8klxZnkc8uOVjwx9IJA50Cx5x49i7+I6+sYpn hHwMuRMDRNahDWAU5ou1yDPo6zh+uInvrwllTNzE8ujKCCXhbGY54BJsQvAmsTM5M7JehOwqdoxr Mo8yR1xwi22CjPdWcUGoquK+kbgerOh/tbBPlAiKw+DCOldccXt4TV9G9WB5kJSxjJLhyxkIS1En 3GDP0puG63gJWhQTjduqmpqaQSOt57CYAchoMb2Wu+mpsI8SxSpQ3SDnn+Y3T3LCmeAORqN01hiA uSyHRzODxjXCip3/DcHSKNNkjRwIRt54Bm7Wa4O8iRnRZzWwLxhYb1g/b1h5OlxMFrMrrEOgs/wN HdYHyF/Eu0YbnNyk6RKCJd1DiYi6E2VNuqZFKwA+xt3tZdQ63bPiaBplRtNa8w2Y5B7mqjgl+TV9 zy6+9tZ+KjQJYPBXYcDjtJ8r/bBzk6gFmehyeos/0UyTFv05J5DjdkLBLSCFLQ83b6O3oXnc4O+9 8jvLR4JZUyvgQZF2vB+nXN0O41g3y67waYm1sYL4mghdATcziH12HCQNUDkjcfyK7ucozqw3bJfi 3AbMFmu+yW1c8FIIpzbibY0hHoN2C2QH79hyIEt8j3xeydwyUvvmdri2HPE6Y/4tTZ5eDBY4isjc ZAeRF2aqoGVZnX+Elhe37xbTSa9za28JCaaLi/Rm/huP18i3J+EWljyun5bwvUp+B3nB3qS3C6zP BXYMCM8KYqDAdmQvp/wOEAYbwRj7eMG/kB0LplkzTVwetInjn/P529A044GhwEdQ9WG2OBf3uNJe yFNSJ6CUMom0HDBPlmS599hbhMmUoGW3M5ZOxYKM0C1yjEwBRAJY1Z7bVpIooXD6fo48tMkwxkjm KnaeO9dgG5OmkKqTzeA0s7vEclJYSB02VTtdzWHZlIGAaV6HVA+QdIoDrCfyKfpIsv5NPN5JyTz0 1gUu2yiW0FATg4OMrR8d8gmC3xqLC23AeuyfbOCnQIVtFgbsH0C8zFj6/xD+YXvQ8HcV+oBbfP8c umwddVEEDM6jFtGbGxMGGr9lW/Xu/c6HUben2AbY6e0iGo/hJclmDZwOZ+FffqBdE+10UOY0F2Uz EwUgsHLMhBxjY3BVro9Dgzg7OtHoHuYFLA8MbNzcisDBpC02IFNS1/MI2SQdxPaAaXxj1UR710QP 6b58tkJe+IH3WHyfpqq4ZMb3vKltbJ2N7FhIp2aE+UUojIW3hnT4J4c2sJoIQvYUIbRsurSL+5VX MA9XtuXfR+OLvBn0vONHHR+/lp0mfst3IS5zDXgDkW+H072CuIAmM2ovW5sA9pvBMiREzE3TRQOf YUr8TCNWKnldRiy+tvSPTo61eOYwR3V0ywU3zoktdOICMM1I5b9kkCu6Qr+T/MYHxIhCWewDYtnE eLD8AickCBfggLUCEFSsL5oJuUK+/pKc1YtKKTLnbeV35zbxsZHeL1y0Se9uPjlFxNYTFwn7AN9e YaXwksi3K5rZHPp2C0a+HPbNPKZvsFdXMO2Afg/o94B+D+j3gH4P6PeAfg/o94B+lRdDv/TIcXfQ Pj0bnGraUKVH4hjI9IzkKYW4la60wCnoIbKQOhGbRg020znCk4sWnssTz+ftYQ/lwcvj++RNBuEp A/s7vVYY0APt/CwOHQ6IAQCLjAh0xPOAfk7TonmQxjM/8vKsVSwQ4ontEx6asYlCeuqPPqt6mwAt lt2veYxlViV3kEKtrZhJYsotTnBOEqynb5X4FB2lsNGhccbGN7oeusiJju85/BF0PJEn7GAZsxV6 LUCsM9Ijh3FzLz/cYoMlL3Eu3HhrZpJYcAdhNVvIJ1pKywF9yYGuemcoO8H1rGe26g5pRR8FhRzl BaErfBe0fcS/srnktCVxwHh2Qx+FHevOWGfrgeOj6G/0KU5jtaSfHk3KaOxdMs8cSWXy9Miry+l/ dR51WBhVMKjAQNNwBYv2CHSYXesos1Rwdh83lq9XMPQeIYpX0PuP4ES11Qweo6BWy3hKGekrgiU8 wiJo/Ndr9dH02JLHaMJOe7ZicDK86uPKWJUz8nUM1ekDrAZ4/9BEq/aMWhNm9TH6mgEsVprYACMe PfA9bjADmE7+JVLq9qPkw6MJGYogQj8wcuvNA/LSbyEndrW1k3akxtGYUa1Y+uRo/KvCKZYhFP8y TotHypoEimWMO1v1iMkvDUzh2yg1EvhFSisqP2G1RoQ1DkaKp487de02xG+CljY/y1XRC1RE0gGZ 9yEL/ZCnNu2OnO35XsmQn9Q56RuMso9s7vt+Y/QqZUTiOx1+9jXLPE1aZ140R17lpEXN9GwQZCe6 cyOrOEOW1i1RkOPQizrEKuKpKa1fIEprLwjn6EZeXlQ+i7+mLatZIJZ88i8nXPisX04+ozz/lq9Q LK8tFcjXk38TOCq+cflyUdo4kSqtryieYyAFDRn9UXCW153Q5DXnRPP15qRFzXTPVFZjVC5/o1gQ yb9MjHxbWgs9wglAWpe2TqTKayyI5+staBD18xNrsqoTkrTenGCOGmRlM2qtDZZWx8rldQki+YoE qYy22UJaCS2W15EK5Kuwpe34DVlByVxPSNKacoL5zxBWysbb153q0EzplfFN6bwSo92r2kRjZAQN UbD6HfvYYrXGYrVGXquR1+pa3H1qi7tPbHG3xuJujXyvRr5XI9+vke+XfVEBbRW2GzvlD3hIqbNu gNWkrIbIKp9fJEB22QyLaHI8wI4jB2VYIKZKZd/x1UyJsJmQa+ZK7Zyom62vBFBV73krUWwliFX7 XWJv2VQzBIaqXKmor4TEWW8vEcWIINZwnjytd7r79U7ctrLBJCn9G+ibZCzLwp4hMFTaqz3NXm0/ ew+eU+85X3gk6rr8mxjJNDvXZuE6fPA0X9D284V4lVbqDLbAUK2hbIBsgaFaQ1lssAWGag1lvW4L DPJet0qz6soqzah3zqpcLnQqJKNHCGUrHE4s2U/YuMgrWz7oMbVk74W+2li69RIRyyQ9wymXZESp 5MQo6yBklCIVbOOgrIkGJ8prWyHHIGWGopgqlWWPEgxcZi5OyC+bj58Y51K09NR1gbrnuiDN6U+t UduzxiTz1KWYb8bit7ugdO9tFdGkcnP5r00BxS39ADL9NIZVWhuOqVLZ+EBUmbSX0svWWOVLqop1 GX/nsmI55sYcZftwZZOdMFLZHhPbri7fYeJkeYxhrwiWhRhOlI9qZWurW0qhAH2vrSL/R+TSXbUy k/2IJveL0PkjxGGZqJeQ5Wtk5H+kqbdsmZyQy0epaoheYIV95wble3OhG5Tv6dF3F0snT+m4sHdq y3bOIprwhBq8o+wxmexRDftJyxj6LJlnwki3hicjhVmToQu/35k+kKDKWioVoI+UaLlljNVOpyPy 0OZFTOwX1+hjIJPQH+x0w4D+smgsQj+iCvqWDmTSzM1ICdBa6Wy7HcXGjtLv0JroQVV/dERcThx0 Xim0+xVV658NT087nX5WI7WIVaQQd9xRDLKk+Kvw6VZrE8i/vJv7pGvxK54NfhprP6FX9Wp5K0bK Q3RAbNyFWsbH1WLHyob+Yix0uzYs+kuVYP4xYzlfyQNHs/i8trq+Ej39wankSW6VKtkT3gr+E6Fr u0p0UdutAak3w6cPR9nPznrYD21w7pxjuuNulokeA4MGbvw1nSnU3cdnpwqk23E0Z0w79O+1kaL2 FAYZqBm+oajDrz1R1TNVOlO7+8xUlc7UaMVT/MyyBf+tqqZlk1lYmHQ5oef4rZarx5gyhglgs2Pz USTONdbHtlk/f4N7yx8fFxx8nNFMf9FyPL2OTliNL/49Of/QJDjEMzTu88pTB4XoUf/bm7IzG42k SkKB1utKQsGCaryLNcp+SFcaEerFSlIp66wljLhh0WN8/khhx2VyHaa0OttO9J96ovj0nOlYy3SH XXqyA/9BjyoHO6GS+FQdO1XKGD/iHZvGcWdZ9CQ5KxkpJrJsbCit193O2fAs6U+J3hHr2VeKSb8l Ri9AP/x9JkuUwWmvp6SydYZQ9tiWLrelp3bVs0p7Qsuos0Pdwwg1tqDfHXIb4OoonSgFgZQ/Zc/5 af5Q8RhjtYNQv4/PDBV1hv2e3tMw6g8Gptnvajou++Xhoi8/m2pJypd9kb1ifuYUPMmyPatUEa2U ZVE+OvwsG422Cou2NBI+Y/+Libh72slnYjC00hq8tYJ2HTZQa7CBxrCB2lG/SXBAmUxacxyIwEiH AOBp8Q+2ZBYWOj2ZLrbfB/3DF1yyqPs3Vv1SSxb1sGT5jCXLFwfy6lcA8i/qvp8L5NWfCcirPxGQ P0DhAxR+IhSuxmfqN4XP1Fp8pn4NfPa8Mf+z8Jn64vhM27+x2rPjs4E8v2kHfPY94TPtK+CzF3Vf dXjWDJ9V+e/Pgs+0Az474LOfAp+pZxq3Aa4a4DPgStnrtipNvXO20k+1gT40h5qqab2hYWp9s7Ma 6D1T633GVuVTVee3Kp+keL+dRr1TA2Q1OZB9eu9lgOygkImqgaxWC2S15weyz4QJNbWQVLuFpMqY qpJq90thwu4BE35PmLD7vJhQU7+2+34uJuz+TJiwe8CEB0x4wIR1mLAa6nS/JNSBAFsNdbq1UKf7 zFCnGPNffB/gs/bsNL5n96UTFTdaU59idJcaDT39chuNvf1HqPfsoHIoT8q9A6j8nkBl7ytsNL6o +6pn3Wagssp/fxZQ2TuAygOo/NZAZfRN1peBloP4cTBcNYGWg2HKXrfdaAwM3DM7PXW4Mnsdtd9R T82+PujrIKL3Bp9zMvKpqmu3G5so3m+7EdU9N+/JMfjTey+DwSH677Xd2KvF4L2v8dz8hVNkw7NS VSlS+5lSpHZIkYcU+Q2lyG8vOf6AMV+rifndny7md3+mmN89xPxDzP/RY36vG/cHXDWI+T0aTmL2 +lfFTGOwWhloqBu6Yfx/e+/aIz2OHWh+n1/xor/YvfC0xTtZ2J6BsQMsFvC0F9szHwaGYVC36cJU vdWoql6PvZj/vox4U5kRKZGH4kVKJQ986egqiSkpGDyPDsnz8FkyK2c59F3HBitp1laxtKbBF6KY hve9EBE7pUXH9Mf3HB1NlejIgOjILxUdY2eiQ9GRtxQdOUZHjI6fPToSxl+not3HmHcid9jDCWCE ZLMStueWk2HQnHPbKdLZ2Y5DzyTL2kyd2DQcISMa3hchBUuNkMmP73neXlWJkByIkOJKEZJ2Mj9C ipYipMAIiRHyOhGyxBPxx8duiY/rQ7/78vWnx/sHRlUBjKrylIXfdDUai/WCJAqMxiJ6NM5coyNw jc6V1uiIwgu/6dndNzcZLVpaoyNwjQ7CxMVgIu11m3WcvFzE7WPE6/btsIcToNdt21E9WUII6/pu 5rNWRk/ytsybmL4zLON1O7Vp8HU7puF9r9v9RIDXbbH9up3++J5et7V4H47Cr9sCfN0WpZfJHx8h lxXnNGXFubivOKcVaVbuv1l5FM1KpNkr0aw8gWardt9cmpUt0axEmkWaRZqNodkwo8kPxWgSZDRZ ndGqT4lkbWXknq2MtYNVFljKsmC58Q2p/d+QKg2WpNsOzArB8kpgqU7Yyli1+8aCZbD/tgKWCsES wbIJsCS6Wy7i9jFmVZI77OEEKE2q5r43mttZCtVPXDLRCzMyLntle2VMRpo0tWkwTRrT8L40qep6 AMHVNoKnP74nBFdi36okBSK4OmMnY9kImYXgqnoFYL3/ZvVRNKuRZq9Es/oEmq3afXNpVrdEsxpp FmkWaTaGZsOMpj8Uo2mQ0fQZjFZ23M9iNF2d0cz+mzXFGY1sxziDjHYlRjMnMFrV7htbPC3Yf1th NIOMhoz20RitYvE0ashSIOb2MYLUboc9nADlHbnuDZ+VHI0iohulZePs/pOpUQnCXBBNzzumNg3m HWMa3rk8U0qAac0206Y/vtDUP8i0BmRacwbTVo6TkbmMUJxspYKawQpqGCc/Wpz8mBHyE477R1dR +/jjfitV1AxWUcNxv41xX5nlIm4fY8Z9d9jDCdCbEe01N1ZwPnbdbCc+qEkT2ylr9UwnKTLejFKb Bt+MYhreWVp6MmkRMv3xPUfInXVGIyPk0ZXU6kbIyEpqwQjZSiU1g5XUMEK2ESENUW9vRiruzUg9 nACuWRy5JVbqeRaU8q4bJq0nbulAFDMz6XPWLCY2Da9ZjGh4b+5QpEXI9Mf3FCFlnQh5dCW1yu+Q 23PEuyJkK5XUDFZSwwjZRoQUhC8R0n2MiZDusIcTwAjJjOGaio5I2RGrpLtT0w+cdi5qWEZyImRi 03CEjGh4X4Q0I+QI9UXI5Mf3FCHNTh16ZIQsWxXv9Aip8yOkbClCSoyQGCGvEyEvUGv05WcVHlXV x6g1SrrdFQPeb7IosKSVbg7GpMMlrRda0rp8XUdWZ6rbfaOnbEP9t5ElrcvNIkwgTFwGJtJet5US L9fgPkW8bLuj3g6HXrWZJJMbVXoirRylUDMbe81FT5kVIxttxqt2atPgq3ZMw/tetVmnwq/abrjZ fNVOf3zPm7PYrhpW7mqAV+1leDy0zmjh6JhTDsrdf+U6o+6NfvfNkqNIliDJXolkyQkkW7X75pIs aYlkCZIskiySLESyYT4jH4rPCMhn5Aw+KzvmZ/EZeeGzo+dvsnb8m9o7/gndfbPvQ2gBqGTbQZki VF4JKunxO/7rdl+iVRxUhvpvK1BJESoRKpuASsmXa3CfIqDSHfV2OJQeNcTBo6KEEDlN3Sh6Moth dFDJjRKU5OzzT20aTI/GNLwvPUo1ULvKDTeb+J3++J7wW5BdK5Hc1UD4Tcvv86+XaWT7sZ0dBYUM ofBKUMhOyDRW7b65UMhagkKGUIhQiFAIQWEYddiRqANmGhmIOuwEm1HhREBO0s6hXu2k3X51Ewmo mxL5jG/HN458diU+4yck7ap23+gthKH+2wqfceQz5LMm+IwwapZS6u5jTCl1d9jDCVDibuyJspOc ueId7a0ahp52ikvKZj11QmUk7lKbBhN3MQ3vS9wJBrg53ZCzSbPpj++JZqXcl7jjIM3yEwp0Fo6Q WTTLq9PsWhYP3mxAFl+WZgXS7JVoVpxAs1W7by7NipZoViDNIs0izcbQbJjRxIdiNAEymvi4k6ts FS82FOYMiBcBhXlZ3JGIO1fCHVl4cpWd3X2J4Vm4I1vCHYm4g7jz0XCnpmNHyNdK0u5jVBUwyR5O ALcmU8GmudNs0vMg2CxGy4RDHa6p1XOfs/YutWl4a3JEwzsrSUPeSDfwbG99SX58z3go3gelMB5K EA9l6QnpVZysnhbISuGJlxTe2cFdR5YuCwX3RsRAy81icMfg/nGC+8cM658wWBUUA32El7q8HLZs SAy03CyO+zjuf/Zx34glh337GKU9EObhBOh1bu6kpnpkgmnLO22H7laufxzNNE9m6HOKOqc2Db7O xTS8U3ug57QImf74niKkMlUiZEEx0AeIkLFioFCEbEQMtNwsRkiMkJ8+QnLxGiF5TP2a22EPJ4Dq PD4bZQyRSvCZdz0jRJCps2bsmLBkyFHnJTYNq/MiGt4bIaE1i54Imf74nnfg1ImQBcVA50dI2kXW dwtFyEbEQMvNYoTECHmZCPnxtQfLz6qYTMaNqvUWVav900+q+CojuT0YK1xldKVVRuqERdVVu290 sdhQ/21llZHCVUYIExeDidRF1Ya9rap2n6OWVbvjHk+BXrkJncVgezYZTjtjFBtGNvRKaTlxSUyO /iC1afCVO6bhnfoDqaB5W7X9zp3+/J6z0vtkvO5qoHdu9XHXoPNVeNXrd3UOhFd9FB1qpMMr0aEu vAadn919c+lQt0SHGukQ6RDpMJYOw8ijj0QeN9CGkUeDyKNLr6tejf3VMwNZ66rVSeuqFw8CS7lo efcg1Ew97vcnkHj/dSZcGoTLK8GlOSH1WLX75sKlaQkuDcIlwmUbcMmNWZ7I/XMMXN6OezwFrFBm 5djzaZKaE0o7KvqRaiUdUYpJSz3lVChLbBquUBbR8M7Uo9UTwOHGU/4i+fk9bxkx+1KPBuRwc0aJ srJhMovDq1uy6NozC90sjbew5yEt7RBpL4S0y9d1JNLW7b7R27tC/bcRpF1uFpEWkfazI602y+L1 28cYoHWHPZwA4aygMxsFcV+SkD3nnRqFJGrquWHjMCqTgbOpTYM4G9PwPpxVUoVp1g05mzSb/vhC G6AhmnVXA9DsMkQeSrOFI2QOzbr7r02zaysveLPxJvZMmiVIs1eiWXICzVbtvpkJWkpaolmCNIs0 2wbNlkjQhjmNfKSso7saiNPIx13wuJqAp2s9GDQBT8tr7j0hAzX3l0Kewpr7mL21dbtvLvK0pLmn qLlH5GkFeYRgr8jjPkchjzvu8RQoiTfNaiDEcDPYkU0znUcmBRVWMSKMETnbYVKbBpN4MQ3vnJPW I7A2lHp89+nP73ltqNpVgoKCvnta2nd/QpjMWWZJadlllhs3u2E5h2423nIei7RqGwkYIu2VkJad gLRVu2/0nHSo/7aCtAyRFpG2DaTNnZMOMxo7cqYVZDQGMhorz2ilcEes4sVaiXo/KBQvyjvvPeEC nfeXwp3Cznsqzu6+0Rm8UP9tBXfQeY+40wjulMjghZHHY3OvlJYSAPKANvflx18OeVZjf/UFK1mL y0j1xWX7vVe0vM3dE+fQ5n4pTjvB5l63++ZyWks2d4o2d+S0NjhNqSUr5T5FMJo76u3wMJ95TO5M kskNNT2RVo5SqJmNveaip8yKkY2VquhR0OROK5jcj343X6YNRQqf8fu0YQxUlg1UWVApqkPlun4O eLPxboFMqJQIlVeCSnkCVFbtvrlQKVuCSolQiVCJUJkHlT6l7jlQCeqQaGn/e0zJv8LrW7LWorGX tWhHB6osqJTVoXJ/JUlaXpHiCcqoSLkUVJ6gSKnbfaONpKH+2wpUoiIFobINqORCLtcgZARUuqPe Dgf3gkxdp6kVdOSdEpr2c9cLNQgiJB97ynP2giQ2De8FiWh4314QMmgAvz1mlPTH94TfemdBF9CM QiuYUY6Ojlkkq6qT7NqHAd5seZ2LhwRQ53Ipki2sc4n6rVbtvrkk25LOhaLOBUkWSRYk2TCfeTQu J/EZqHGhpTUuVQu5rMtOg2nV8nIRT6hAucilUKewXCRq12vV7ps7E9ySXISiXARRpw3UEWS5Bvcp AnXcUW+Hg1WYGetmMVsmOqnM3Evd2YEzrSnvuO7HnCrMiU3DVZgjGt6XtKMdAaDQ4xRJf3xPUOgG /l17g0GnCC3tFPkI0TGvJsT9idCWoiPF6IjR8bNHRyLfakLIuJoQ8rUmhIzwFEirxkGOwlrCht5Y 6r6uWXE5mplRO+R4ClKbBiNkTMP7IqQ0c1qETH98j9GIE10lQlIgQrIPHSGzVpWZ2hXO2FrKAN0s K2/d2qYBhtatK+V6WGHrVsxvtW73zcz1sJasWwytW0izbdBsVq4nyGfM55E6JYPBQI8UK+2R+ghj flYG49sTaSSDsdwsjvk45n/yMT87g5E07p/zXh477h/8Xl543M95L2fd9m4vylcK7/W6u/tBIYV3 YN3dctE8ReGt7xfND18smLWwV78s7H3/pOnqSW9sBqTAk47YDEhTnvS3zYC03mpktr/cGSuvlzTb CIR6yUulbU7QS9btvtFpm1D/bSVtg3pJRPhGEL66XpJ9KL0kA/WSrIJe8uixPwcuWfVKrWxtSwJv trwT0xPn0Il5KU4r7MSM+q1W7b65nNaSE5OhExM5DTmtEKd5RI8ncRooemSlRY8njP1ZnEarc9o6 eQjebHHR43shwXL3KHq8FKcVFj1G/Vardl9iaBSnBftvK5yGokfktDY4zTFS97q///Y5Zof/7bjH U6CF/ayf2NTbUerRzkx1Uo58UFQRNo9Eqhx3eWrT4ML+mIb3Ley33QwURGAeL2b683tCWkX2IS3o xWSlvZgFCyKsppbZhrwAmFpmxb2Y7y3qy4NEL+al6LC0F5Oe3X2J4XF0GOq/rdAhejGRDtugQ8YE ebmI28cINrwd9nACRIb8JvjuR86klb2ZJ2H7mQ56NJx0ho59BhmmNg2SYUzD+8hwJAoAQ489NP3x PYMhex+OwmAI2kOXIbLcloIPECHjthQEI2QrWwo4binACNlGhFzCY0xsXA4FCyHQTpNBDYJOA+sG IeQo3f/X2kij2RSYwoILISQ2DRdCiGh4X1SEttl5YmL6w3ue/1NVYmLJ7RbFlqZvbNNYSxPBbRrF 5dS+UIpy6kslSwrLqaN2GVXtvrnJkpbk1Azl1IiCjaBgbrIkjDseQXWlFAC0uxQUVLPSguqPMO7n pQBESykAgSkAHPfbGPdTUgBJY32lV9tCY33dSgK10705W8Xdq/23reJHB6is8gciVnZbeGFi1iJi Vn0R8X6zL4tX0GdmPiRmPq6U+ZAnLCKu2n2jFxGH+m8rmQ+JmQ8k4CYIuMgi4jARyw+1MlaCRCyv tDJ2rYAFSTpekJ6JPAqR50rIo05YGVu1+xKtspBHtYQ8CpEHkacJ5CFaL7vbtY7Z26712+HQ+h9D Z040dVijjOgdy+ihI6Pphs70Ny9qxvqf1KbB9T8xDe9b/9MPABOqbSZMf3pPTCjEvgVACmRCVX5R bL0FQBslT6FEZbxqPJMJNTLhlZhQn7AAqGr3zWVC3RITamRCZEJkQogJw6ijD0UdaEJYg6ij6y/+ qZ0HyJoQVmVrh2/c7IbfDrrZeANsLJ+x7fhmkM+uxGfmhJxd1e5LtInjs1D/bYXPDPIZ8lkTfOYe 3vJAbh9jlut1S0HK+wlQ3m7ujRwHKfhAu5lIOc6CW6pGSyc7EZqzby+1aTBvF9PwvrzdQChAsx6B cfrje6JZTfYl7kCB8TJEHrubvWyEzKJZU5tm+YYVCrhZXlxg7KEBjgLjK9EsLy0wjvit1u2+mTTL WxIYcxQYI80izUbRbJDRuEdmeQ6jcVBmyYtLjFfjfvXF1lkbI2TtjRF8v/KHF7cV+mIc2govxWgn 2Arrdt9YC06w/7bCaGgrREZrg9GUWnzj7lMEobmj3g4P85nHUsgkmdxQ0xNp5SiFmtnYay56yqwY 2Ri9IYLt2hDBQUshP8NSWHjMz+EzXt1SyPerfnhxS6EvvqGl8FJ8doKlsG73zeWzliyFHC2FyGfI Z5l85rETnsRnoJ2QV7ATlpou5KtYsS5Icj8oFCvKi/48oQJFf5dCncKiP8rP7r6504Utif44iv4Q ddpAncrThR5zXaXpQg7gDmiu46XNdSeM+8uSLp6SjrrXUdu46NprW3LWofGu+jq0/TUFeXlHoCcw oyPwUmB5giOwbvfNBcuWHIHLzSJYIlgiWOaApcfyc9I6NNDys/zwD12HVnjuJGuek77Mcx4drLLA kpcFy41vaF33GfyGyvuU+HZgRp/SpcCysE8panK2aveNnpwN9d9WwBJ9SgiWbYAloWYpKnz7GFNQ xR32cAK0XXdQA+vNNAorxaxkp7tZSyOtEYJMs8jZrpvaNLhdN6bhfdt1BYEQ3GMjSX98IQQHp7JB GwkvbZ46IUJmIbiovtRw/74XXt6RIbZpAB0Zl6LZExwZdbtvNM2G+m8rNIuODKRZpNkomg0zmseP cRKjgX4MXsGPcfS4n8Vo0pMmrV3JNssYp1+McfXAcl3CEfyGyptIPIEZTSSXAsvCJpKoAaZq942W r4X6bytgiSYSBMs2wJJqJpe60/fPEWh5P+7xFChVOvXDPBA7zrMcetMpM0pLp453fLA943NGqjS1 aTBVGtPwvlSpnEYoV+pxkqQ/vycON3ofh4NOEl7aSXJCmMzicFU9V7rmd/Bmy4tUPEiAIpVLIW1h kUrUb7Vq9yVaZiFtSyIVjiIVRNo2kJYQqZZcqfsYkyt1hz2cAOFsJ2lHrZr6ns+MaMaF1dbK3sxz b7UQGTib2jSIszEN78NZrmeAZj3amfTH90Sz7ivbRbOgdoaX1s6cECGzaFZXp9l1VXLwZstrZzw0 gNqZS9FsYe1M1G+1avfNTdC2pJ3hqJ1Bmm2DZoskaMOc5hGqnJR1BIUqvLRQpWCxodU+JbF/A7wo 7ybZDhkC3SRXQh5xgpukbvfNTOCJltwkAt0kiDxtIE92Ai+IO8LjJqmTloL2hAvQTSIquElK4c5q vaFY18yG1huK8poPT7hAzcelcKew5mNDAn5w9yWGZeFOS5oPgZoPxJ02cIcqveztuH2Mye+4wx5O gOYrlZlHo2bL+GSFNYOihlimrLK3IjjuUaTPV6Y2Dc5XxjS8b77SToBYWHikKOmP7wkMlXofjsJg CEpRRGkpygkRMmdDiSBlN5Rs3Oy6MhJ4s+WlKB4aQCnKpWi2sBQl6rdatfvm0mxLUhSBUhSkWaTZ KJoNM5pHjHISo4FiFFFajLIe96uvU8laU2ZiCzoWnmnKKegoClcKX39DYl3LHfqGRHkFjdwOzKig uRRYFlbQxCyEq9t9idnuvyuwDPXfVsASFTQIlo2AZUeXB3L7GAOW7rCHE8BtHWbkVPLZkoHPIxuG jgzS9vMw0nEyVuVs60hsGt7WEdHwvjSpmjiA4B5ZT/rje0bwfcWCBCjrEaVlPSdEyBwEF6z2tg6x rsUO3mx5742HBtB7cymaLey9ifqtVu2+uTTbkvdmuVmkWaRZpNkwzYYZzeO9OYnRQO/N8sM/ltHK jvtZjMarM9r+CuOivEJGbcc4VMhcitFOUMjU7b7RRbdD/bcVRkOFDDJaG4ymlHi5BvcpgtDcUW+H h/nMI0VhkkxuqOmJtHKUQs1s7DUXPWVWjGy0sXzG9vEZKEURZ0hRCo/5WXxWXYoi9lcXF+WlKJ74 hlKUS/HZCVKUut03l89akqIIlKIgnyGfZfKZR4hyEp+BQhRxhhCl8JifxWeyOp/trzotyrtF9HZ8 Q7fIpfjsBLdI3e5LtInjs1D/bYXP0C2CfNYGnxHVLZXrbh9j6ri4wx5OADc2j5qqgXFlFGW95cJS rXQ/9Lbnlg5jzsbmxKbhjc0RDe/0itgBoFmPViT98YU2zYA0C2pFxBlakcIRMotmq2tFxP6q06K8 VsRDA6gVuRTNnqAVqdt9c2m2Ja2IQK0I0izSbBTNhhnNI8s4idFAWYY4Q5ZReNzPYjTt2dhcuwpH VsUcWlvBLPZvPRfFDR+s2w7MaPi4FFieYPio231jt4IE+28rYImGDwTLNsCSd4YvF+E+RoDl7bCH E6A0KTejYNM4Dp20ajC86+kgBz733aD5rLqMNGlq02CaNKbhfWnSeZ4ABPd4UNIf3xOC652bZkAP iqjgQTk6QmYhuKmdJpXrmkTQzcri8hYPDUiUt1yJZmVheUvMb7Vu982kWdmSvEWivAVpFmk2imaD jCY98pZzGE2C8hZZWt5S01UnN2p7AyUYZXF5iy9coLzlUrhTWt4S4aqr231j96AE+28ruIPyFsSd NnCHUvpq56U0Ss7rDns4AUzeDZRayRzLSN1rZpkURHSWWDVSNdiAhRdO3iU2DSfvIhrel7zTPQSG HnlL+uN7nj8n78NRGAxBeYssLm85P0JqkR8haUsRkmKExAj5+SPka6GzuDpnr2XOImr2DoOQI2Ud Y/2sBHeQbu04znyY1TToMWdqK7VpMDrGNLwvOo7ABgBfcEx/ek/BUa4iUZHgSIHgyK4VHONU58Hg yFoKjgyDIwbHzx4cyWsJAxJVwoAsJQxuh0PBUfDR6I7zsbODnBQRVAlpJ01M15th1BnBMbVpMDjG NLzT+zmnBcf0p/ccHE2V4MiA4MhzgmP1qeScZR+yi1VKXSCi85YiOseIjhH9s0d0Svnr627M7Lc7 6u1weMO7kR0bDdNU9kRyrTnVfOrsJPtuVDRrw3ta0xEb3uGG90X0Cah+7ovo6U/vKaKbOq+7HIjo 4lKvuyVmS0VLwVFgcMTg+NmDIxFLcCQiJji6o94OB2dK5WSVnRhTvOs7KcU8a/cGZ6TWzEw653U3 tWl4pjSi4X3B0djEidLkpxdaQVcqOAogOMpLBccSb46ypeAoMThicPzswVGYJRfsPkUER3fU2+FQ cKSKis7Q2f1P5z4xOWs6M9ERPkjFSM4yotSmweAY0/C+4EgFS4uO6Y/vOTp2VaKjBKKjai46qpai o8LoiNHxs0dHSjvzto7IxC0kMg8ngBGSCzVxq/nY275TM5/ZoHnf9dS9CPGsXfKpTcMRMqLhnQtt LUmMkMmP73m6lFWJkAqIkPpSETJz5+39ieiWIqTGCIkR8rNHSKboyzW4TxHx0R31djgYHYmZiBvY 555Oyr0N9dJ0crhtu9VjR4jJiY6JTcPRMaLhfdGRqMRtKOmP73nqUVSJjhqIjuZS0VHr/OhoWoqO BqMjRsfPHh2lWa7BfYqIju6ot8Oh6NgNlI5czIzYYe5mTgwd9EBor6wQ4zRlRMfUpsHoGNPwzuxq D2jVfNEx/fE9Z1d1lehooCoG3aXCY5E6Bl1L8dHdLQZIDJCfPEAqseRXlYhJr7qj3g4H1+bMdmCT ZsM025kqwSQXimjWzZNg45CzcDW1aXhtTkTDOwPkrBIX5yQ/vucqBnVWrhKwzg9pL0K2VeoHa/1g hPz0EVLoZfWq+xSzQEfzt8OhCMk4F9OkZW+1JoopbbVQyirBOZ/FqDIiZGrTYISMaXhnhOSAJ8cX IdMf33OCVdWJkFChH3KtSj9FImRTpX4I1vrBCPnpIyRXZLkGRWJK/yrydjgUIedZat6ZSQ9a2GEW ahzV3BMtejl2Ug4ZETK1aTBCxjS8cwpyTHyHTH98zxGyzgIdAlX7IfvK/dRzQqx1bmAlhIDOrWyR ZIpFkq9UJJme4ISo2n1zwZC2VCSZYpFkxMImsDC7SHIYeOiRpX9BJwQFgYdW93ZVTwgsFlqaUsCJ 3C20MVWn6garzHrFtKV6xRTrFWOwaiRYZdQrTgpUdcrwlgpUBcvwfoAXlMzNpbSlMrwUy/DimN/E mJ9VhjdpzK9TXbbUmF+wuuwnGfNbKdRKsVArjvlNjPlZhVqTxvw69UdLjfkF649+gDE/diKCBMb8 VuqPUqw/imN+E2N+Vv3RtEmIKmU1S435BctqfoAxP5bzQ2N+K2U1KZbVxDG/iTE/q6xm0phfp1hk qTG/YLHITzLmt1IskmKxSBzzmxjzs4tFpo37VUoglhr3C5ZA/ADjfmwJxNC430oJRIolEHHcb2Lc zyqBmDbmVynsV2rML1jY7wOM+bGF/UJjfiuF/SgW9sMxv4kxP6uwX9KYX6dcXakxv2S5ug8w6JeY yG2mXN1ytzjs47D/yYf9rHJ1aVO5VYqwFdtPVrII22cZ99vaSox7iXHc//TjflYRtqRxv05psWLj fsnSYp9l3G9qVy6WFsNx//OP+1mlxZLG/ToFs4qN+yULZrmLKlQwa6PyBNtfeYIVL5hFt8MFw4JZ VyqYxcoWzIqqpFq1+0bjTqj/tvKWy7BgFsJOE7BDu9dJrdvHmPVr3TKtdT8BFFZRRjUXxv2oBBWs 73k/dprbnvZsnLqcauOpTcPCqoiGd8qO6QigIfPMACY/vueVfmZfLVUGoiErXFrshAiZVVqMvZQW q0ezfP/N8qNoliPNXolm+Qk0W7X75tIsb4lmOdIs0izSbAzNhhmNfyhG4yCj8eqMVn3S5oXRiE5h NHpjtKiatWWDVRZY8rJgufENif3fkDgKLAWC5ZXAUpzgFajafYk2WWApWgJLgWCJYNkGWHK+1Ha4 fYwBS3fYwwlQmnRiZhq17a3SfW/7XhD3gYxiEJa6wSZQvQdMk6Y2DaZJYxrelyY1GkqTim0ET398 zwi+cwZdgAguqhsYqkfILAQXLwhej2bl/puVR9GsRJq9Es3KE2i2avfNpVnZEs1KpFmkWaTZGJoN M5r8UIwmQUaTZzBa2XE/i9FkdUZT+29WFWc0vh3jFDLalRhNncBoVbtv9FR2qP+2wmgKGQ0ZrQlG E1Iuuw9vgR/efejC+OvhULZRqYlxqoi2VlHGuBxYN/RyJiOlbOplRrYxtWkw2xjT8L5sI2USIFnl 0WskP74nktU792kqkGTVGSRbOTpGll8MRcdWNmkqVKdidGwiOlKqXqvuqqiiu+rtcCg6zmRmg2KS D6wXTAw97ztjTd9by22v+ozomNo0GB1jGt4XHSdoNZwnOKY/vafgqHb6BiOD49GO2bLBMSvNo6qn efT+m9VHpXk0pnmulObRJ6R5qnbf3DSPbinNozHNgyDbBMhmpXnCfKY/VPJCg3ymz0heVB7z85IX uqXkhcbkBY75TYz5WcmLpDH/pHfyyDG/7Dt5vQ35Zv8mMXPU663B19srvd6aEzbkV+2+ua+3pqXX W4Ovt4g6TaCOUstCU/cppna+Em+Hh1HHeGooSzK5oaYn0spRCjWzsddc9JRZMbLRxqIO27cZ34Co Y87YjF/29TZr+kHXnn5Q3e6bVV1xPhOb8U11yGcX4rPl6zpy+qFu943ms1D/bYTPlptFPkM+Qz5L 5DP3IzqQz6BUlLsagM+WH33F6Yfq7+RZdYfMS92howNVDlS6L602VJL9N0uKQ6XcDsoEofJKUElO gMqq3ZdoGQeVof7bClQShEqEyiagkspFnEZljDjNHfV2OLQ42w4TVYOgSk3DoEfL1TAKNs9i0HTo +ZyxODu1aXBxdkzD+xZnk04D+E228Tv98T1GIk73qUXd1UD4TU5Y/VM4OmaRLKlOsvsLs6p4m14m yVIk2SuRLD2BZKt231ySpS2RLEWSRZJFkoVINsxnHhXkSXwGqiCXH31JPqu2Uk/t9wSp8iJIT6hA EeSlUOcEEWTd7hu9KSHUf1tBHRRBIuq0gTpK8deZ4BjUcUe9HQ4l7Yi2HelGao0mbDJuCFLDpPUw GsLZPOYk7VKbBpN2MQ3vS9qxDtiypzwSyPTH97xlb9+aRgVKIFV9CWT1REBW0i5aMFQ4pOdM9KvC 5sqNb2htUwK/ofLmSg++oLnyUvhd2FwZlWms2n1z8bslc+Vys4jfiN+I3378DkOlx1pZByrBTCNo rVx+9MfOBJcd87OgklefCd7vB1LlBZBqO76hAPJSfHaCALJu943eKBPqv63wGQogkc9a4bNqG2U8 SsOTNsqASkN1htKw8JifxWfVlYZqvxtIlVcaeuIbKg0vxWcnKA3rdt9cPmtJaahQaYh8hnyWyWce neFJfAbqDNUZOsPCY34Wn1XXGar9Rf1VeZ2h3o5vqDO8FJ+doDOs232JVnF8Fuq/rfAZ6gyRz9rg M62Xa3CfIvjMHfV2OLS8sBsHO81jz42WfTdRMplOkJn1kvCOGpWxvDC1aXB5YUzDO5cXKsDYpDzG pvTH90yy+6pDK9DYpM7QGRaOjlkkW93YpPbXh1TljU0eEkBj06VI9gRjU93um0uyLRmbFBqbkGSR ZEGSDfOZx95xEp+B9g51hrGp8JifxWf1S1qv60OCN1teOeKJb6gcuRSfFVaORP1Wq3bf6JngUP9t hc9QOYJ81gafEf2qV7t9jCC022EPJ4AVCKdeGj0b2Q3SDHLorR65ZcOgiPtvWZuZU5uGKxBGNLwv 26goRLMeQUv643umWbKPZkFBiyotaKlZ4Uava3BD+4l1edfJdmDV6Dq5Ehjqwq6TmAo3dbtvJhjq llwnGl0nCIYIhlFgGMQd7fGd1MEdqHaLBn0nurTvJKp2S9mEQFbyztRO3un91aV1eXWIJ8ahOuRS jHaCOqRu9yVaZDFaS+oQjeoQZLRGGI0tz8N9iiG023CyHA4l7thkrO3kxMdR3oYWomxH+NwTMyhJ e52RuEttGkzcxTS8L3GnKQCyHnNI+tN7Blm5K2+nQXOIPsMcUjg45oCsrm4O0fsrLury5hCzDQJo DrkUyJ5gDqnbfaNBNtR/WwFZNIcgyCLIgiAb5jOPOeQkPgPNIbqCOeToCaacesu6ixUrFw5UWVBJ q0PluiI2eLPlHS2eoIyOlktBZWFHSxRUVu2+0TPYof7bClSiowWhshGorDuD7bGPnLNgT4P2EV3a PlJ1wd66wDQIpMWdGLzbDhfoxLgU7hR2YkS9mpTFnaxXExYr3an7m4tltOCPrhVGQ5EHMhoyWgFG 88g8TlplCMo8lh9+xVWG1cf9rOQfry1b0/srY+viMg/OtmMcyjwuBZYnyDzqdl9ieByjhfpvK4yG Mg9ktDYYjRqzMNrtYwSj3Q57OAFaaSh132smOR9nNhkh+3GierC8o9xYR3kZKw1TmwZXGsY0vG+l Yd8DpbW1R32S/vieaFbvzDiC6hNdQX1SL+O4LskNUnBxi4gvsKJF5FJgWNgiEvUSV7X75oJhSxYR jRYRBEMEwygwDOOOxyRSB3fA5B1oEtGlTSJRM01lEwJZM00ieqapbLDKyjjK6hnH/RWydXH9Cffs C0X9yaXA8gT9Sd3uS7SOA8tQ/20FLFF/gmDZCFiqt7LR988xaKleS0d/OwXc32xHNfZDNw2k17wj c6fJLHs+Th3p1cxy9jcnNg3vb45oeF/WUQ5TD3C4x4OS/vyeOFyqfWlH0IOiz/CgFA6TWRxe3YOi 9xcV18U9KD4kQA/KpZD2BA9K3e6bi7QteVA0elAQaRFpo5E2zGkeH8pJnAb6UPQZPpTCY38Wp1X3 oej99SN1cR+KL86hD+VSnHaCD6Vu9yXulnI4rSUfikYfCnJaG5zGGCEvF3H7GEFpt8MeTgAXOwpi uBg47Ww3SdNrSbqBiEGP40zmsctZ7JjYNLzYMaLhfWnHYZoBmvX4UNIf3xPNip00C/pQ9JV8KGZ/ vR9T3IfiCawGfShXAkNzgg+lbvfNBEPTkg/FoA8FwbANMCTMGPFapNB9jipT6I57PAWCw6EXQuih 47Mc5sHakSs9DkZIwrnsh5ya26lNg3AY0/A+OGTSAnPSxqOPSX9+z7lOsWttqAH1MeYMfUzl/Els QY9Q/oS2ESaXm8UwiWHyk4dJTgx9vQhDI4Lk7bCHE6AQqW1HtRlGMgprxr4nA7FamI4OfLLCTBkh MrVpMETGNLwvRJJOQoWPPQmU9Of3vH2CVUmgUCBEsrKFjyu/SeaFyG/Q0EiIXG4WQySGyE8eIlm3 7Jpzn2ImGDr1djgUHukgRjX1VknSccNmxsZR9lKPSkyzVkNGeExtGgyPMQ3vDI8MWCzje4FMf3zP 0dFUeYEsGB3LbXmjbBVV17qn+0GhqFpc5SnIdlBFleelphcKqzwpO7v7xk4vBPtvK9MLqPJEKGwE CnPXnYRxx2OprLOawg2yYdwBLZWmtKXSXVIp3OGreLEWEd0PCsWL4sJHX7hA4eOlcKew8JHys7vv LbmbgzstCR8NCh8RdxrBna6jr0mwLmaa6HbYwwngMttZKsu1pDMZCJ3lRCSfZ6alEIJpm1VTNLFp eJltRMN7a4paAAw9esz0x/cEhkq9D0dhMAT1mKa0HtNdUikwFKvIutbA3A8KRdbi0kZfYEVp46XA sLC0kYqzu29uHqwlaaNBaSOCYRtgWGSZbRh5POLGSmtHBYA8oLjRlBY3boz9R8+BRC6MCc6BtLIw huDCGBz7mxj7s9eOJs2B1FkQWWoOpOSSj/Xc99HMnznus5bGfYbjPo77TYz7WQsik1i/0jK/Qqxf csxfs37tRfA55fhN91KO/+hZy+WiecpF0/tFr6Zaq+/Iy6o+ZmpXHzNrryx0sybeJ56Z/eaY/b5S 9psfX32sbvfNXRbBW8p+c8x+Iwk3QsKZyyLCNMyPnOyHtoS6q4FomJ9QIbbwuJ/DaO7+azPafn2Y ifeJZzKaQEa7EqOJExitavfNzVaKlhhNIKMhozXBaNQQ+Wo9JTLKekrkwwnQ0lWh2Dgoh2B0ntU0 DXY2A+F9z7UaBO1ylq6mNg0uXY1peOfSVckBmhXbNJv++ELzeSDNCpBmRXWarT6ft6RJRQrNsnua 9PjFJ8tFs5SLJveLXs2cVmeRrPcGUf29YW3wBW82Xjef+d4g8b3hSu8N8oT3hqrdN/e9Qbb03iDx vQHfG/C9Iea9IUzD8kPRsARpWJ6R2y077mcxmqzOaPuVtCbe3B7LaHQ7xilktCsxmjqB0ap23+jd Z6H+2wqjKWQ0ZLQ2GI3L5YHcPsYwmjvs4QQot0tmYozQsxWTGfk49HboNCXTNPKbpzUgYwVzu6lN g7ndmIb35XaNGQCaVds0m/74nmhWmH00q0CaVVeyf60duOB633j/eSwYsu3AqhEMrwSG+gT7V9Xu Gw2Gof7bChhqBEMEwybAkFCjl6oE1OiYogTusIcTIDA0hg7TYDvK1DwPg+iGyfaMG841mQeVM+mf 2jQIhjEN7wNDQaAlrHobDNMf3xMYSrWvbrsGwVCXF3/Vq9u+3p4EzrvHC8MywdAgGF4JDM0Jddur dt9cMDQtgaFBMEQwbAMM3bNbwNDcNuvCYOgOezgBAsN+ngQfjO5n06luGMfRECF6NbDBkEmMGWCY 2jQIhjEN7wNDNUBVvTy6u/TH97y3ieyr7gLq7pYh8goV7km3USEgvNn+dsohYOj+EILhdcDw9es6 sMJ95e5LDMsAw5cH0gYYvt4sgiGC4ScHQyrV63I/9zFmKtkd9nACBIZcSsuNUoQqafSkGOGjtor1 Q2ctoTkZw9SmQTCMaXgfGFoV3iZ0G3I2wTD98T2DodhT4f52NWEwfB0ir1Dh3v39vduLbqccBIZo erwUGJY2PcIV7it33+h9IKH+2woYoukRwbARMHS/+QUM3ccYMHSHPZwAgaFSVLpG2SB7xsdBKjZa bfuJioFaJgJSRxAMU5sGwTCm4Z37x9kIgKGnHnT64wuCYbg26J3kADAs7sQUxcBQriLrRnlOCUTW 8k5MT2BFJ+alwLC0E1Oe3X2JVllg2JAT8/VmEQwRDD85GDItl6nk28eY4o/usIcTIDCk00z6jtuR 6W4mnegsGW3H545MxnBqMsAwtWkQDGMa3geGM4HA0OPETH98z2sMzftwFAZDyIn5OkSWA8N1hKw9 p5ZRf/2WMY2sv154T2nW/m/1sv/76CRVRgmnW+fZLuFUG6CWi5YpF/2tPP+6T9feWZIlQtAeEULt VY9ZxbLMS7GsWjUNSLcuZwb8gG+nlH6t5NtYjkbdS71WFjbqRtQ0qNx9o1coh/pvK6+VaNTF18o2 XiuzVyiHX5Y8hq06626Bnfq3q4FelkrbdD/AuB+7ADE07rdhVXy9WRz3cdx/fyWht5bzYsIf/vKj 69B1IoM2yxLF28eYyOAOezgBSjhqbt3AM2g33veD4moceS+F4Iy7p8GmnIRjatNgwjGm4Z17V6RO i6Hpj+854Vgnhha0VLpLyqloQ7q1swdI3NxOOSgtgKrBS6UFCqsGIyraVO6+uXjYkGrw9WYvhoch cklDx5w6EqRbqxCAlPTtlOf+vIGusUP0h0DcYJx4ZLmn2/44MLz8IFDCdqnoVVjC9m2f82fKhmVv yzpk9KuX5G9ISvd6sxeL5pjswST/4YWLwwkKj2qtTjleoLjG7WqgBEVp1Zq7pPAD8piVK20yDZel u10N9IBKm5ULlqVbLzVbWzvApWblZWOeeIqysUvxcWHZWFT1kardN3ovQaj/tsKDKBtDHmyDB7P3 EoRxxyMbq7RCHqqpAcnGXn/416ipsV6kDq73Lu/t8oQL9HZdCncKe7uiampU7b656a+GvF2vN4u4 g7jzyXEnW88Qxh2PjaqSdACqFAHZqF5/+NeoFLGx6QraKVbeRuUJF2ijuhTulLZRxVSKqNp9o0uI hfpvK7iDNirEnTZwJ7uEWBh3PI6lSoWxoPoHkGPp9Ydfsf7BJbdyskbG/ZebxXEfx/1PPu7jVs71 NhQGjPv8Wls583j//kR4S+M+x3Efx/1PP+5LTZdx332MGffdYQ8ngC6JqeeGDXZgRtB5kFx3lMy9 nvisRzXOOS6JxKZhl0REw/s2akoTts96I2T643uKkJpViZAciJDiUhGyxJuRaClCCoyQGCE/fYTM LWXwCTfoC2Dcl1ca92lXoMiNbGnclzju47h/nXG/xBPxj/rdMuqvD/3uy9efHu8fGFUlMKqqXaNq qWUVajUab5SFVcBoHCgLW3ZZhcFlFVdaVmEKL6tQZ3ff3DSraWlZhcFlFQgTF4OJ1Ok1pl6n11jM sorbYQ8nQGnWueOjplYpOjE7SUvFTG3HWe/+1+gxMJMGpllTmwbTrDEN76yHZwjwum22X7fTH9/z RKR5H47Cr9sGfN02pRegqGJguHpNJxviDuA1nQTEHUXBkHQIhhcCw+XrKgaGaxvKwd03EwxJ1xAY LjeLYIhgiGAYBsMg7rgf0pG4A8wuuKsBcGf54ZfDnfW4XzshsGiOVIpQ6pvmaJ3FqF3YNUModav4 sy2Uqr2jJUvdpV/UXaVoePUNkQ25GvANkYBcrSwNE6ThK9EwOb5ydN3um7nWhpCWaJggDSMNt0HD iiwP5PYxhobdYQ8nQGlSNjjGsrLXVKqOUCPFbOg0yZnoWYxdYKMZmCZNbRpMk8Y0vHM1qp2A9way /d6Q/vieVyWpXUUn3dVA7w2kfNHJnRHykIrNEQrVEM/6aVi86FVzQ36ImEu9bxAS+75B9quCSUAV XBbBKSL4lRCcHl8Aom73JWa7/8YiOG0JwSkiOCJ4EwhOleFkqQBx+xxTAuJ23OMpEIYPZpopo4bJ WXPR96a3nWLCjmYQyv2/DAxPbRrE8JiGd2L4SAXA4XSbw9Of3xOHi331MtzVQBxOq9fLgKpgHxJK czLP7hl9yzyvLiijdPdyQTwlFS7vF7SuN167AOdy0SLlotX9ostVj1u/3iW8DcVvOsl8eWD48nCl lwd2Qv6+avfNzd+zll4eGL484MtDEy8P2fn7MA179sqelJUG98ouP/yPqEJaZarJxoISIFNNjhJd ExRdXwp3Souu2dndNzdX2pLoerlZxB3EnU+OO0VypWHk8dgfKyUAAT0mAe2Py4+/pB7z3dhfvTzI S1qK6JS0FLulpdY1TarvNllyaSkX7Qj8lksrVjJg/Q2R9TII6Bsi8eLqWLgU28EZPfSXgsvCHvqY +kN1u2/0zrBQ/20FLtG7jnDZBlwySZbKrLePMZ5Nd9jDCdAkvGLzZGnfs7knQkk1Scq0nYkcrCa9 CCjWwUn41KbBSfiYhvdNwk9kABDcY6hPf3yhrCNUoY+AhnpS2lBfsJbUau6e7J8GJ+UF7J7AigL2 S4HhCQL2ut03FwxbErATFLAjGLYBhoTw15IB7mPMJKs77OEEsJYUo4pMZuR8HllPpJ4olYwMg7Z2 7CedU0sqsWm4llREw/vAkKseAEOPqj798T2D4T5VPQFV9eRKqnqyf6khKa+q9wRWVNVfCgxPUNXX 7b7Rq+9C/bcVMERVPYJhI2DI5Kuq3n2MAUN32MMJEBjKzsxW02mkdLTSklHOxrLJPYWuZ6bLyRim Ng2CYUzD+8BQCA2AodoGw/TH9wSGmrwPR2EwVCAYqtJgWG5bxnonz/4aUiTeip4JhhrB8EpgqE/Y 0121+0avUwz131bAUCMYIhi2AYZSvkk+ZZzkU9KHE8CySnZgRFGmZve/nM2MWEvZPNquF3zuc8Aw tWm4rFJEwzv3cyuorJL2bGBJfnzPqznNvu3cGgRDXX87d+2V/BElk/wLI/lLWaR6u242as9CN1ve peShAXQpXYpmS7uUYnbdVO2+ufPfLbmUCLqUkGbboFmlxMs1uE8RLOuOejs8zGceOxCTZHJDTU+k laMUDtPG/rbthjIrRjba2HL5bN9uG9AORIrbgdZjfu2prZwiMGQpAnP0Qq2ccjtkKbdTbVEl3dha BNwsLe9h2g7KFD1MV4JKWtrDFLGosm73zYRK2pKHiaKHCaGyDajM3m0TBEvq8TDV2UMCLRWkoIeJ Fvcwrcf92lNjWTUa9bpG4yFbQ3P2nhPh2XteO22TlWI1ZVOs62+IrkU20DdEy3uYPDSBHqZL0XBh D1PBnXWr3zjdqHgL/MZpefeBp9uj+yCn21ca8g7/NT0oFZ56SaHZi3rrZGhL+jGK+jF8CWzjJTB7 nUz4JdAn1aqy+gMqJEBBqRYtLdX6eLgDTnZsKbGAyQ4aKC0WjVQJCcwN9ooPbJtR7lMVmX+CjqKh O5//0oL/PmgsywqHs2LpCvrCizuoekLcaQR3cgsJhHHH4y6qtD0eWExBQXcRLe4uilhMUZgvyu4T pi1ZOihaOnDcb2Tcz90nHB73PZaOc3a/UtDSQYtbOirufqUbmyOAOVJa3tLhCRdo6bjUZFZpS0fE 7te63Td3aVdLlo7lZhF3EHc+Oe7U2y9APXaOSvsFgP2cFLRzLD/6kvs5S6GOWsWK9cqq+0GhWHGU M4KiM+JSqFPYGUHV2d03N7PTkjOCojMCUacN1CHMmNcVDLfPUbkdd9zjKVCxDy25MJbqWd1GGaWl 7VVPZ6llN1POZEaxj9SmwWIfMQ3vK/bBpIUSYR5xRPrzCy76VwAdguIIWloccUKYXJaiq4Sl6PS+ ft5ddD2k3diFCt3sUbYLiraLSyFtadtFzG+1avfNRdqWbBcUbReItIi00Ugb5jSPx+EkTgM9DrS4 x6Ec8qy3omxUC4G2ohzlcaDocbgU8pT2OERYmut2X6J1FvK05HGg6HFA5GkDeSiR5uUibh8jgOd2 2MMJUAbPOHzph5lTMk9sUExbQybZka4XeppFl5HBS20azODFNLwvg6eVAcDQ43FIf3zPG7bU+3AU BkPQ40CLexyOj5BLAi+lAAb9Vg6u3C6z9c1ulCiBbvYo+QRF+cSlaLa0fCLmt1q1++bSbEvyCYry CaRZpNkomg0zmkepcBKjgUoFWlypUA53zCpebNQJM0C8KG8nkNvhAu0El8Kd0nYCc3b3jd5tEOq/ reAO2gkQdxrBnc7IBXfcxxjccYc9nAAl7+zcCUV41+ve9FRZ02nRdzN3NyyEyUrepTYNJu9iGt6Z vGMdAIYel0P643ue1SXvw1EYDEGXAy3ucjg+Qi7JO5OSvPtWCNbUo1m2UVceuFlWXouwTQMMtQhX ollWWosQ8Vut232jk3eh/tsIzTLUIiDNtkGzxMjlIm4fY9beucMeToBodhpHMVlHYyMZrCWKKCmn QYmJzMzOo8mg2dSmQZqNaXgfzSrbh2mWeQQS6Y8vuEYRoFkGCiRYcYHEKkJWr/Sf42KgxONiqB3W cxDcfWnfEPz9RdcuLp8jkKD0RSDx/qJre6VyHHC0K+uAW/8W2P7fAitvvfDAIlovLvWyU956cXL3 zUzds5bK/zMs/48vO2287GSn7sMI7yn/XychDZX/Z2D5f1ah/P97RqtdIC7HAefAbtMBV72Ib44R 2SH0NyNyNdEC24/+rLxXyhOY0St1KbCkhbPo65fAg7tvbha9vJziA4MlihYQLNsAy+wsehgsPaKF SrlhQLTAQNECO0C0UHvcz8lYMl/GsnbBlaziSLJwcaT1N7RB0dA3FK/CyATLT6XC+vxgWdoWFTPA VO2+uWDZksmFockFwbINsKRGLgav28eYjKU77OEEcLEx6wWjXe/40TLZGa7FPKhJcU07M7Oc5Rmp TcOLjSMa3rc8ozeA64x5nDfpj+8JwZXYh+Cg84YVd94cHyGzEJy9IHg9mt1IZEM3W17U46EBFPVc imZLi3pifqtVu28uzbYk6lluFmkWaRZpNkyzYUbzyHpOYjRQ1rP88CsyWvV1VzlLaNmyhLbeGsl1 7XnwZssbhjwxDg1Dl2K0woahqDWSVbtvdDn2UP9thdHQMISM1gijdYS8rpEkJGqNJCEPJ4AbwvjY GassGyZqmJnYNPVU815NlE3a8pwNYYlNwxvCIhreuSFshDaEeeRC6Y/vmWb1vtWkoFyIlZYLnRAh s2hWeDaE0fcXTTbSpDR80SQiTUoTLpp8S5PSigi+XuEAfkPljUgehEEj0qUQvLARKWqAqdp9cxG8 JSMSQyMSIjgieBSCh8HSY0M6CSxBGxIrbUPaYLTahbSzit7rl6L3R8/pZc2/88Lz7yuKZhtaAoCi WXnvlCcwo3fqUmBZ2jtFz+6+ufvfW/JOMfROIVi2AZak08supU7HbFLq9NvhUF6X6pH3hvQzl2J2 bStj1KAm415yKRfzkJHXTW0azOvGNLwvrysHgL49yqn0p/dE32YVicL0DSqnWHHl1PHBMSdDylTZ DOnGzW68akA3W1455QEBVE5dCmRLK6difqtVuy8x2/03FmRbUk4xVE4hyLYBsrTT9DVDqmOM8bfD Hk6AYJZ1XA6zUXRUoxH9NHe9ZYoO0naznlWOgyG1aRBmYxre6WCgFKBZj5wr/fE90yzZR7OgnIsV l3MdHyGzaFZXp9kN4QR0s0cZxRgaxS5Fs6WNYjG/1ardNzct25JRjKFRDGm2DZrNSsuG+czjyDop 2wg6slhxR9ZqzK++xitrEamsvSWKr2vkQzfLj3JkcXRkXYnPeGFHVsx6zLrdNzPbyFtyZHF0ZCGf tcFn2dnGIKNxj/mpTg4NWo/JQfMTL21+Koc76yWRfL3dHVoSyY+y5HC05FwKdwpbcmKq9NTtvrm4 05Ilh6MlB3GnFdx5LWZ++xiFO0sx8/sJ0OQq5zNXtGOD1IzP/aQscZ9sZyY2cy5ExuRqatPg5GpM wzsnV7sZAEOPTyj98T2BoSa76hlx0CfES/uEYuoZFU4I5CTveBe7A7zwLFPWjLB5mRE+mkVydhdx UnZ30Ua3WtsEwG51lASJowTpUu8NhSVIUWnSqt03972hJQkSRwkSvjfge0PUe0OYhj0SpDo0DKZJ QQkSLy1BKpgmXQEp31+SiMe7TRjbChdKvQ8XajtcvKl53D91T3JaI8+PL4Pw24NeDv3u24P98pO7 6NvF3EekcBC+yduLLCZLe6r/5e//+OXXn+3gruqPf/z7f74NtX/+9bt+cgdPf/vtv7mTvv/1e/dr /Dd7a9pzivvoEOf+ex5++N49/S9/mn744acvfxc8/l9+/v7XyfX8nx2P7ThhmH7+9fv5+8H1xz1/ YPzpK3T8/Qv44gYP6znMfVf35/hlfcMxVxV9+s7vu36fwCvHK8crxyvHK8crxyvHK8crxyvHK8cr xyvHK8crxyvHK8crxyvHK8crxyvHK8crxyvHK8crxyvHK8crxyvHK8crxyvHK8cr/xxXvr7g/zH9 65fpfw5/sl//O7TI7H7a/P3X73/50zTGLXj71uzw/Z//NP385Zc/T0PUaZF/42HR2+YD+stX2/8w 3dYiugf75dbSyz3/pz/8zZf7d/h7br5U/h6it7soHrffJbQAlOzf7/K6LPT9Ppjtf/y/gttjPJsM bvsKHjaxjF+//PVvv/zx7/74919+nIY/ffk///jHv/u//69iC3f56ovbUD5x4IsLKJ/KLtzlH3Lh Lq/1VHHh7kUW7gLfd/0+gVeOV45XjleOV45XjleOV45Xjlfuu/Jm0hp8Z1qj2vewepc98Q1ceEot xKZOOKZOXr44ufrixPqLk8AXJ4qXePF8bwJLvFypxIsoXBpSnt19o0u8hPpvKyVeBJZ4wRIvkVdy 7RIvTCj5chG3jxElXm6HPZwAlYach4GzcZ7ngYwT14IJZrhUo6IzYdrmePdSmwZLQ8Y0vK805DgD Xhc35GwWw0l/fMHSkBIohiPAYjiidGnI4yPkUrBQphQsFPeChbIiza4lNuDNBiQ2ZWlWIs1eiWbl CTRbtfvm0qxsiWYl0izSLNJsDM2GGU1+KEaTIKPJ8oz21s4v9pcfvi3pcUfdlvMQweL/9fZVvAQf wncc+Xi9tOveLw0K/mt6H9nuiHa73peo7AYN167/35ycQaY6P4FMyyWQa2aK/b1JikAXYYEuQjrz vot82G/aiPxvml1+quD+rbibG79+9+Uv330/3p6JI/VfXbh0X6ELJb+/dYJ//6P9av/79PPf2j// +Yfv7ddh4r9zI/Xv3FD9Nw4e3Kj7Ozfk3j5+a/v2yf7l1z+9XPW3C/v+31wf+t9zm1xuOaHNh4// /ZdfrCON1zYd3b0+Dnp7Fi+P4dbL7g/uq3V9Ivfv3B6p/fKf/nCHyZ+n+1zgP9874f/89Z9vbf3r l38cpz//+qffk3/68suvP7u//vu/yv2jf/X0137+yw/Ty5+6fdxo/nf/27vn/665chf25R9d+HTU 9NfTL7/9p6hn4sai3/9/3d/81fKm/4Sqb7H/P/7Hn75O//Gv3d95ubTf/tX/+tbd/2x//mX6r//P //Xdl9un27e7u6l/dx8V//LzD98au63A/evdjfz237lR65/n73/41f22v/zm8V/95ulf/fL9jw5t 7v/o28e3k97O+U3gjWb9C/Rc5NYPy/tW//xjca8Obij+8fY4v3df3M9f7Q9fvmHVl7++vwx42vmb lxcB8tvgy4v/heRdftQd+Hcbd7bOdnoO/K3/bcb7Svf2XjMv7zXk/XuN/wYeM5o/fGNntmirX9CZ cKov8iY0fK3y4qHp8ufdp4jXDnfU2+Hvuoj70fznbz+av4nuLfA575Pebz/NwNu0J5vNGA+8dbxg x+2tw5HV88/w/3gN3W8hy0Uc+GLWKOD+7z0LRDRz/7N/54b2n35248eXf3y96H/67suXP//80//8 1y/25d/eF/R/sT/88NO/uOZv//Tf/tMffv+b32xi6R3Yfv/vyRvS3P7S334Dgy8L5Pw+5rF/ud/l L7/MvxcyALk8Pl3nRdyuFuHer/jP/++vyzf2dfr5+8H9yn751T3P+N0qxGRl+e49kWdl+dz39cNP /92fer79y795O6xwQu8/3FZN/fPw688//LIX0h/P/e6+5+Y35Hfsd/J35Hf89n+0Y+4/jPs/4iLE 15++Dg5rvh/sD79dvyjseh3oPW8J+941ev9t0N8R+TvNu9ulE6ZY526L/466u3i7BTdwPZz21b3v 3nr7/afym3Aa8ts3+ZvfQgMcX6dV4IPu6PHjNH7vAsLjdijPN/PtVZcGBgHxsk1qK3nDFLRN6uBd g5mJC4aJi+jk1cnfdGbigrWZuPjhLz+WS1nENhaXrHjXWoU0RexfKJSgiP1zB6Ymoi8JkxKYlMhL SmAO4bPlEPwgyq74Os4+8+u4F9zWr+OFuO1jvI4zfB3H1/Hyr+Ms5nV886BTX8dpsaWja1mwWg8S kCxYRQ8DmUtHFS4dvdLSUVV46ejKdX109yV6Ow0VG8VUS0tHFS4dxaWjTSwddT979XIRt48R71+3 wx5OgDZCDdOkO8ulZFTJicjeUqYoNb3ihFj3x9M3QqU2DW6Eiml430YoPhlgka3aXmSb/viCi2wh K7gCF9mq0otsVxGSrCMkXUVIAkVICm6EIjplIxS9bYQix4f1ZfdW0kWr++6tYv71jW9I7/+G9FEI rhHBr4TguiyCr3+rR3ffXATXLSG4RgRHBG8DwY2gC4K7jzEI7g57OAFC8IlJoRXVcmK9Jpbz3hIh uew4UWIyNAPBU5sGETym4X0IrmwHILjeRvD0x/eE4MK8D0dhBNcgguvCCH5ChMxCcO1B8NqbsrMK KMiyBRQ2viGz/xsyRyG4QQS/EoKbExC8avfNRXDTEoIbRHBE8DYQPDcLHgZLc2RuFwRLA4KlKQ+W 1epFiW4324nuINxxZyPuXAd3lq/ryHpRdbtvJu58eyCN4M5ys4g7iDufHXdyM45B3HE/pAPzaFC9 KHc1AO4sP/yi9aJqrXEUZPdssjvlINwhiDtXwh1y/BrHut2X6KyV+t8eSCu4QxB3EHcawR35hjsy DnckfTgBmmDtZc/nzs6MKkKmXvdy6s2sue7EKGU3ZEywpjYNTrDGNLx3gtUCYEi2wTD98T3nwdiu NY7uaiAwJNXXOFaPkDnLBd39F10uuHGz6wWd4M0GFnSWpVmKNHslmqUn0GzV7ptZ7P3bA2mFZinS LNJsEzSrFH+5BvcpgmXdUW+Hh/mMbvMZ0bYj3Uit0YRNxo1Lapi0HkZDOJvHuRKfUZDP6Bl8VnbM z+IzWp3PNsouQDcbXy4rk88Y8tmV+IydwGdVu29utpG1xGcM+Qz5rAk+y842hhmNfagcGgMZjZVn tFK4Y1bxYqPoswHixQ4Feh7ucMSdK+EOL4w75uzum5uO4i3hDkfcQdxpAncqpqP4oekoA6AOB1GH l0ad9Zhfe/1wztZGxzeV3dBivwhbBETYZflMIJ9dic/ECWv9q3bf3HSUaInPBPIZ8lkTfEZYJ5Z0 lPsYk45yhz2cAC1+mylXI5dMzVxZPRPKLR2YpZMS0yRUQAMNLn5LbRpc/BbT8L7Fb4IABf7ckLNt 0U5+fE80q3buihAgzYryuyKOjpBZNCuq0+z+qiQiUJWkLM1KpNkr0aw8gWardt9cmpUt0axEmkWa RZqNodkwo8kPxWgSZDRZn9FqzzItjGZSGI3fGW2dJq29Eihr1R6rvmpvf8Xp92G0HliiB+VSYHmC B6Vu9yWGZIFlSx4UgR4UBMtGwFKTV7B0H2PA0h32cAKUJh1nM3VK93rSZB763hiqtJTc3bK1vTYZ adLUpsE0aUzDO/cIE6BWnvB4UNIfXxDBofWNoAdF1PegVI+QWTRbWCmycbPritPgzR6lFBGoFLkU zRZWikT9Vqt239w0aUtKEYFKEaTZVmj2VapO4qzq5FWrfj8Bolk5TbwbzDi6gxXvjGMyK8aRS2uI GXVgDSZIs6lNgzQb0/Bemh0AmvUoRdIf32M04u4FZBfNgkoRUVopckKEzKJZXZ1m13oD8GaPsnMI tHNcimYL2zmifqtVu29ubrYlO4dAOwfSbCs0m5mbDTOax85xUsYRtHOI0naOmjuq5cb2JGCxgDzK ziHRznEl3JGl7RwRO6rrdt/M5J1syc4h0c6BuNMI7pi3+jFx5WPo2+FB1JEeM8c8dKYfFJWDnjUl lHI9zlTMXS8HPlMeiTpyNcAGUUeCZg5Z3MxhSqEO61axYl24+X5QKFYcZeaQaOa4FOoUNnOw7nDU yVnWK7vtZb1H/+Zy+awlnYhEnQjyGfJZJp95BBl1+MxFhTCfgYIMWVqQ4S6pXipqo3AzFODKuyb0 dqhA18Sl+Ky0ayImFVW1+0ajTqj/toI66JpA1GkEdXLXkYVxx+ObqLQ6CkpHgb4JWdw3EVPgr2yZ haySKLJ2SRS5sU0XuFlZ3jfhiXHom7gUo5X2TUSURKnbfXMZrSXfhETfBDJaI4zG+XIRt48xjOYO ezgBXuvPLeG9HmalmWDCTDPlVk+3NVG27wPZp4i1/mlNR6z1hxveWeDPMoBmPWaO9Mf3TLNsV/EY CZo5ZHEzx/ERModmJatOsxuVcqCbLa8T8dAA6kQuRbOldSIxv9Wq3Td6rX+o/7ZCs6gTQZptg2Zp R8nLRdw+RtDs7bCHE8By1XIWSnRkpFoMYuQznajk1jIzDXwQOTSb2jRcrjqi4Z07VydgV4T0yFfS H9/TVLQb/HfRLChfWYbIY2m2bITMollenWb31+aW5eUrHhpA+cqlaPYE+Urd7pubm21JviJRvoI0 2wbNZudmw4zmUYqclHEElSKyglKk1HYOsooX63n3+0GheFHezuEJF2jnuBTuFLZzMHJ2981N3rVk 55Bo50DcaQN3spN3Ydzx2TmqpKTcIBvGHdDOIUvbOdbjfvUCTVnF1MxLMbWj17Zn7T2kL3sPq1WA k/uLN8vydg5PYEY7x6XA8gQ7R93um5tHa8nOIdHOgWDZBli6983XfSjuY9SmW9I9nADNCnM7z3pm 0o5qEkTwiVo9TUzM8yTERHPsHKlNg7PCMQ3vnBVWEkBwj50j/fE9IbjcVytPgnYOeYado3CEzEFw Wd3OIfcXb5bl7RweGkA7x6Vo9gQ7R93um0uzLdk5JNo5kGaRZqNoNsxoHufESYwGOifkAc6J2quB slbuieor9zZywtDNlndOeGIcOicuxWilnRMxK/eqdt9cRmvJOSHROYGM1gijSf3qnHAfYxjNHfZw ApRx1IPp2TiRiY6OzPq+6wY9dtNI2GBGy3L2oaQ2DWYcYxrel3GUBtqH4rFzpD++J5oVO/ehgHYO WdzOcXyEzKJZU5tm1UahYuBmVXmlyDYNKFSKXIlmVWmlSMRvtW73zaRZ1ZJSRKFSBGkWaTaKZoOM pjxakXMYTYFaEVVcK7Ie92vPNGXNCle33Kq1lwG6WVXeheKJcehCuRSjFXahxMwK1+2+xGz331hG a0krolArgozWCKOpTi6M5j7GMJo77OEEKOPYcS2YUKxjY8dHpQer5nG20ywHOfU8J+OY2jSYcYxp eGfG0VqAZj0SlvTH90Sziu2aP1eghEWVlrCsIyRZRUi+zjgSIEJyOONIUmiW3zOO5PiwnoPg7ksr iuDrb0it91RB35A6SnejUHdzKQQvrLtZ/1aP7r6Z+9dVS7obhbobRPBGEJy+ITiNQ3D6iuA0AsHZ MHaKqn4WVtqJ8lGwWepJ91RbOXcBsw2I4KlNgwge0/A+BOc9sM1IecRA6Y/vGcHF+3AURnBQDKRK i4FOiJA5CK7oC4LXo9l13XjwZo8SAykUA12KZguLgaJ+q1W7b25CuSUxkEIxENJsIzSbm1AOM5pH d1MnTQoyGqi7UaV1NxsZx9qLvXIWZqqu+sLM/dXQ1VG6G4W6m0sx2gm6m7rdNzfj2JLuZrlZZDRk tM/OaLkZxzCjeSQudfJo4MJMUOKy/PArLsys/m6elUdjnqns2sEqCywLm2c2vqH1Zn3wGypvnjHb gRnNM5cCy8LmmajkX9XuGw2Wof7bCliieQbBshGw1OR1x4/7GAOW7rCHE8Jg6THPjLOZOqV7x5Jk vulmDFVaSu6eg7W9jq0xpMy+5B9onlGlzTPl5jo32G6t7gDZrrx5xhMu0DxzKdwpbJ6JyqNV7b7E 0Czcack8o9A8g7jTBu7wjrxehPsYgTu3wx5OgFbuGUUn0am5o9PcObSZzDDPVsleCCWmnmSs3Ett Gly5F9PwvpV7s/vGwmDocfSkP75nMFT7Mo6go0eVdvSsIyTrVlvB1/tQ7geFtoLD+1BcgEzYCn7f h8K6ilvB91dDV+V1Nx4aQN3NpWj2BN1N3e6bm7xrSXejUHeDNOu5kqNz8FmTfOJlku+TIXjljKPH PFMn4wjuygbNM6qCeabeBOu6NhH46ygvcfHEOJS4XIrRCktcohZDlM04Zi2GkC+LIU7+zeWmSVsy zyg0zyBYYpo0Kk0aZjSPeaZO8g+cFQbNM6q0eabqrPD+Gt+qvMTFEy5Q4nIpRjtB4lK3+0bvgA31 31ZwByUuiDtt4A7RnXlNSXUmKiXVmYcTYG00FdOoJjsRO/JhliM1Q2eJHXohO54zK5zadIQ2Gm54 pzaaEAAMPRKX9McXTN5Bs8KgxEVVkLiUAkPzPrLqjT3GJhxZdXkfynZg1ehDuRIY6tI+FHN2982c YNUt+VA0+lAQDNsAQ6WWqUqlYmYq3VFvhwdRR3tcKEySyQ01PZFWjlKomY295qKnzIqRjTaxerQJ o44GXSi6uAvFlEKd9cI5vX/hnC6vFfGECtSKXAp1CmtFWHd2981FnZa0Ihq1Iog6baDOLcQvObD7 mxOcA7tBwdsJUA7MjuOs2STmyf3n7JhGz8PQqY5pqoeOThk5sNSmwRxYTMM7axqbAQBDj1Yk/fE9 gaEU78NRGAxBrYgurRUpt8mA0VVkXddCvh8UiqzlZReewIqyi0uBYWHZBaNnd99cMGxJdqFRdoFg 2AgYVi09pw9VOLhBNow7oMJBl1Y4rMf96otishYum+2Fy9UnbJaLNgkXrb/VNF7NMlVPveRsudWl t9yuupVeVzSEupUuLsuQ3TZNoCzjUjRcWJYRs1SwbveNpeFg/22FhlGWgTSMNFyAhj2yjHMKMWtQ lqFLyzI2yqLUzoIsjEZTGO0uNNtI3ZBVLZf13sP7QaFaLvDeQ0ZSarnc9x4yUnGp4UbVaQj9ixs+ fIEZDR+XAsvSho+YpYZVu28uWLZk+FhuFsESwfL9laRGr4pACqeX1uVlwPRScUPB+4EFxOjlx3iO wuCp99WJosC7QX6QzVmEsSM4716zcXg0L6xVYB3wPuUR29RZTAGusgXFNku8K7nK9uRBKXbLrQ93 WvJOaPROIO40kkfL3XIbHvc93ok6G0nBRXSgd0KX9k4UXES3SmXp/aksXdw74QsX6J24VHansHeC kbO7b252pyXvhEbvBOJOG7hTcSOpx6RQZyOpG2DDqAOaFHRpk0K5iayNqcZ1VXdwqrG4lMAXKlBK cCnUKSwliNovULX75qJOS1ICjVICRJ02UIdISZbMjrz5iODMjjvs4QSwmJoQEx3IJIlhnOtZUml6 MylqBztrKXKKqSU2DRdTi2h430ZSqQDFlvaYENIf3/Pch9m3swI0IejSJoQTImTWWjL1spasHs2u S8mDN1tc3+CjAdQ3XIpmC+sbon6rVbtvLs22ZELQaEJAmkWajaLZMKN5TAgnMRpoQtClTQgxS+cL T9jkLJ3XhZfOb9zseqsveLPF9Q2+GIf6hksxWmF9Q9TkatXum8toLekbNOobkNEaYTSj6cJo5rbV D2Y0d9jDCVDGsRfMGPeLIox2QnW9sobKYdIjG6hUlmdkHFObBjOOMQ3v1Df0E0CzHn1D+uML0iw0 FQ3qG3RpfcM6QlYXhS9lUZIMw/eM49puXn2JeFZZFPFSFuXobXxZBWi4pwBNbYDKetkxhfcJr34L ZqNEEPBbMMWVJB5YNKgkudLLjimtJFn7hA/uvpkvO6YlJYlBJQm+7ODLTtTLThDhjUdLUgfhKaDm NaCWxBTXkqxpuPZEZNaiAb1dgKa6R/7loknSe8f9ostJkNc3a9ZlHKGbNcUFML7AjAKYS4FlYQEM WQ0wR3ffzB3ZpiUBjEEBDIJlG2BJu06/XMTtYwRY3g57OAHKondMSDrokSo6qFH2ls9yttPc05GJ 0cqMLHpq02AWPabhnVn0UQMI7hHApD++ZwQX78NRGMFBAYwpLYA5IULm0Kwh1Wl2XfASvNni1hof DaC15lI0W9haE/Vbrdp9c2m2JWuNQWsN0izSbBTNhhnNY605idFAa40pba0phzvreXuz4XUA5u3N UVoSg1qSS+FOaS1JRPXout33lvHPwZ2WtCQGtSSIO43gjqCLluT2MQZ33GEPJ4DJOysnTWZBqTUj JQN3P69+HIUhA1OaBcoJwcm7xKbh5F1Ew/uSd2YElsAaj8Al/fE9gaEiuwoOG1DgYooLXI6PkDkL M939f1uYWY9m969CNUe5UAy6UC5Fsye4UOp231yabcmFstws0izSLNJsmGbDjOaRQpzEaKAUYvnh 12S02mvbc7YpmW57m1L1maasWWH6Mit8dITNomFeloY3vqH1RjLwGyovQCLbNHGO3whpOJGGC7uE oqayq3ZfF2/jaDjUf1uhYVTlIA0feSV+Bu2WfTbrQ7/78vWnRwAGBrOjF9FVHs1k/mhGWxrNKI5m OJp9ntGMAqMZu9ZopvJHM9bSaMZwNMPR7POMZgwYzfgpi+fWo+C6WCaYt9sh5+NZCRaU810qwVJY zhdVUqVq95WRs42h7pudX7lNHHz5NnPgD+JvswtZQRwO1ajgaz1U15rE43QR/LpPEVN47qi3w6Hl aNoO3MjZdkrbm8GdcenitJlvn+zMWMZytNSmweVoMQ3vW45GLOCAMR45YPrjexzfzc5qLqAb0JR2 A54fcsRWxOEUiDgJU6evj++eMvvL1zth+Wf65Mucaj0Q3V/n0uxQJ+aBKKoTLwWihdWJUaNC1e6b CaJlzIkfC0RRkIgg+gFBNIxXHsXeOXgFGvZMacPe+QPpoXil4vFKVcerdTk/8LHukKHRLLyq4/Lz BKlbXPJC0BPm+H8YhW127m89MpL9+tPXf/3xp7/88uV9rznluzXbX24sfLQkujNPort/fP0i/ykJ Qf7uD//wh//2n//hv/5xF2IgGHzAZe9/+MuPrt/UWfxu+LL2/bbOF176bvjb4VDejPa8cwwy0I5M A5u7XopJkolrJWZqBpORN0ttGsybxTS8M28GbhHwePnSH9/zFgG9j+xAL58p7eWLIruyYSpri4Cu zltrLwd4s+W9fJ6QjF6+S6WzCnv5on6rZ3TfWKK8nJYP5kaU77UOrRfMZnn0bWWyWdKIfdAD6ttM aX1bQX54v8uPdhv7KcO7/G6nHMIP7g8hP1yHH16/rgPLQFTuvjepXzpAvDyQKwFEOlq83iyiRbNo 8QHzYVdf5P36szqyEFb1UTVnlcHLE2ljA97rzeKoiqMqjqqFR9WCGwFPGFUzCqrc7r9ueUHarUUo 4M2WN915Igia7i71XlnYdBf1W63affOWOrw8kFbeK9F0hwT04Qio4joLIZcag+5TRCLdHfV2eCiR fvspbSbSlZoYp4poaxVljMuBdUMvZzJSyqY+1g6i1Z4Cg7erCSfSX3/6x777Vh75Wf7I38q7L8F3 Xxz5Gxr5zfJQTOj9l7we/XowtLpuGGY6Kjl1Ayda6lHZUUvC9GSFtKNUGavrUpsGV9fFNLxvdZ2w aeEx/ek9hiLeySrh8egkxscPj21UM3q9WQyPGB6bCI/8dYFR1Poi83owFB77kQk2ipkRd216diM9 J71hpBvNbf10jkMotWkwPMY0vC88MpIWHtOf3nN4FFXCY8HyWJ8kPPKWwiPH8IjhsZHwSF4vJCY8 kteDwZpGchSMTyOfiaGTpbPi08zJLAfeKa5FTk2jxKbhmkYRDe8Lj8AqZW94TH96T8lVaaqERw6E R/Ghw2PWFDipPgW+tr6ANxuwvpSdAqc4BX6lKXB6whT4Gd03lmTp1WbAYV6lOM/dOK9ebmvWrdMe uTULgh4KQg+tP6Ms3+9x1RtaYRne46ojtMIyYT+6/qYVlsWg5/3N0m73zd5OiU6ARNb/odtRg12r /s/rBRcL+3JP/Z+Dv9tYIgh9t5+LCBgW+cGgnBCU2aFBWQJBmYFBmZUOynI1lh1deCKu/B/seI0p /2fiy/+ZbWPt4S9/xR4PkPl5Rb6Yx3M79FtK6OxImPR4nn5NcfdbnwY3HMLQcwo4hBNTYGz7QXFM gV0pBcaLs/DJ3ZdoE0e8of57JeLNYWGO2bHGQfwDzubWqbPZEbEU2nQfYyptusMeToDmc9Wkxkko KwbB5W1mUvbT2NGZ6LGnhgwZ87mpTYPzuTEN75vPVeMMvEZxz26Z5Mf3PKHL9r1GcfA1ipd/japV tpJ2aykq8Pp1O+UgMBQIhlcCQ3F42crK3Td6e3Co/7YChgLBEMGwDTCUYlnid/sYA4busIcTIDCU SluqxGCMGOZp0tRMko1sGPqedJwE9gGDYJjaNAiGMQ3vA0MregAMxTYYpj++JzBUbE890tvVQGAo Pmw9UtatIuvaeng/KBRZd1gP88AQPdGXAsPCnmjWXbXb52YaywimLwKUaJ5GoGwDKEm3PA/SxVQc cEe9HQ7BpFDTxCWno+OhaRR9P81mNO4fCGNHTkgGTKY2DcJkTMP7YFJygCU9Iuz0pxdKMroIFmZJ yIT9OjoWY0nWrYIjWQXHtarxflAoOO5QNeYxISqbL8WEhZXNjJzdfYmJXDcZ6r+tsB3KnJHt2mA7 xqRSL1dx/xzBd/fjHk+BGM/1vFlSatXQjdJ0nGsq52Hm1Iiea9JnMF5q0yDjxTS8j/E00yNAeR4f d/rze84YqvcxKUx5kJD7dZwsR3mkWOqErsLrWvd4PygUXuOtxJl0WMc4jXRYiQ4L+7YZPbv7Eq2y 6LAhqfbrzSIdIh1+cjokVL2m/tzHmNyfO+zhBIgMu1HN08D40BGie6upJcZ0zNKx76ZRzxlkmNo0 SIYxDe8jQz5DFbk9Pu/0x/ec/iPvw1EYDCGf9+sQWQ4MaTEwZKvIut7idT8oFFnLq7H5dmBFNfal wLCwGpuxs7tvdNow1H9bAUO0ZiMYtgKGTL2CIYtJGt4OezgBAsNxkpJxPnVqUNbdpZ2mQZvR9Er1 Exm6DDBMbRoEw5iGd4LhKAAw9DjP0x/fMxiK9+EoDIaQ8/x1iCwHhqwYGPL3kZWsRXz3gwKRlZR3 nm8HVoLO8yuBISnsPGf87O4bvVYw1H8bAUOCznMEw0bAUBK9gKH7GAOG7rCHE8CMoeWdJpNhlFgm ez1MvbVDx7XQo1DDlJMxTGwazhhGNLxzvaCgYTB0Q852xjD58T2BoWHvw1EQDN3VAGBISvvr3SWV AkOxiqzr8tT3g0KRtby02BNYUVp8KTAsLC1m4uzuS7TOAsOWpMUEpcUIhm2AIe2IfCtXEyMsvh32 cAJYroYMljGqLDfUdmKyk9KTHHs7moFZk7PIMLVpuFxNRMM7y9VMHQCGPrlz8uMLZgwFAIagf4SU ljtvRMjac2ovVSgZS/GP3GtxbkwE1l4htlw0Tblofb/o9bK22pselosmKRet7he93qlRG6CWixYJ F03uepqNPl07HbhcNE+56O5+0ascZvXKihk18W91s75VQX1/0bWr/kSW+N2+aLFdybf6zvKle3Qp Fy3v3aPYNvp1tyIbZYuBbkXKK5c8L0CoXLrUC3xp5VJEvdm63Td3ZudyzqWcF3i0MeELfBsv8FlV IMKvpB47VJ3iBlAFVQLaoUhxO1TFCqpkQ0EAwCjJlvHEok4d0RKiTiXUKa2ZiqigWrf75s5VXE4m lYM6DFEHUacN1DGv0q3bxxjYMYt2634CNFfRWy2p5nbs7DjPlpJx4HZgpBMdkV2WKj21aXCuIqbh nXMVGjCUEY+hLP3xPYHhu3oIUAVVAhrKSHFDWcUKqmSdWoUSfqS8c0lsB1Z0Ll0KDAs7lzaKvR3c faO3vYX6bytgiM4lBMM2wLBItaww8nhsQpVKQAGFPgloE1p+/BULfVZPCuRMsBL2MsGaymmh8+AH sX+mmZTXI3liIOqRLsVw5fVIeXnrql07Wp0U6tut8B2qk5Dv2uC7bHVSmO0+lBCIgEIgUkEIBC4I JRvr0IAFoaS82Mcz7KPY51JIU1rsE1HEvW73jV6aFeq/rWALCnoQWxrBllwVeBhbPO6ZOoJrqCo5 Ad0zpLh7pmJVcrKx/wXYtEPKO2s84QKdNZfCndLOmoiq5HW7b/TyrFD/bQV38p01B6Sw11stycau RWCrJSmvZfB0INQyXGoALK1lYMFuj28Hn/TtAN5Ku7E9HNpKW75iuGfMworhlxqzSlcMXxeGPDjk 5i6dakklQ1Alg1GojRxVdsXwcI7KI0g5pw42AQUppLgghdXsMJWICOyHTwHisVNGz5FUql4VDmt7 S1v5Oe4xDoZ/AB51ZF5Zp6ywG/wF0bSoHP7ZgcJK8iCs9IfxfT9IPwr482r7QQHVIggKjYBCbgXp 8DjpEWacVBcZFGaQ4sKMinWR6UaJMaAuGi0vzNh+r6QozLhSXoSWFmZE1EWu232jFbuh/ttIXoSi MANxpxHcyVXsBnGH+jQQdcSxQLVfCmogaHENhCiGO6syfHSjDCxQho+W10B4wgVqIC6FO6U1EKsq kkd338xpINqSBoKiBgJxpw3coe4vL4l09zEmV+4OezgB1EBoZvgwUm24JkTO4yCZ5lrZ2VgydTpH A5HYNKyBiGh4X2klLRgAhj4NRPLjCy7qBmpuUlADQYtrII6PkEtN9JTq8/Rbnf9ihUI3bnZdVBq8 2fI10T00gDXRL0WzhWuiR/1Wq3bfzJXotKWa6BRroiPNtkGz2YVCw4zmqYtep/wlyGhgXXRaui76 etyv7sLIMQQR+mIIquatoRuFr6AgV76YuyfGYTH3SzFa6WLuEb/Vut03N+PYUjF3isXckdHaYLTs jGOY0Twlyuvk0SB3DQVLlNPiJcrLpaTUKl5s1HhWQLw4qkQ5xRLll8Kd0iXK1dndN7OEJW2pRDnF EuWIO23gDuG0W67i/jkmKXU77vEUcJKV9GRkdpomOs6qn6ykzEijR9mPjOlAxUp4kjWxaXiSNaLh fZOsTKkeoENPNff05/ecwRPvY1KYDsFq7rR4Nffjw+Qyy6pSZlnvjm930fWQdl3WGrzZoyq2U6zY fimkLVyxPeq3WrX75iJtS1XZKVZlR6RFpI1G2jCneSqzn8RpYGV2Wroy+3rsr27kyLLuiBfrzvuA VbvW0QKXLOWi9R0u2eqia1fVXC6aply0ul/0uhRo7QVYWYsladnFkuvfAl2XeYd+C/QoSwFFS8Gl ML6wpSDGql63+xJDsjC+JUsBRUsBYnwbGE/J7Wpe5tU5j5qId7f7dgKYlR4VoV03zLKfyGzdKDMM HdOKz2RSemY5WenEpuGsdETDO7f+SGhPuM/nkPz4nl52zD4NFQV9DrS0z+GECJnzsuPuP08xCt/s +n0DvNmjJBQUJRSXotnCEoqo32rV7pu7rLQlCQXNl1AgzSLNXoFmieKvdXvcx5iUtDvs4QSIZo0Y rej6qbP0tstn7KhRVGpKyCgdlpEMmk1tGqTZmIb30awcBoBmPYVv0x/f8wJcso9mwRK0VJ1Bs2Uj ZBbNKk/qvrZlY0ko85QsuLknlIuVztz4htbzFOA3dJQGiaIG6VIIXliDFDXAVO2+uQnllpQiFJUi iOBtIHh2QjkMlh6lyElpUlApQksrRTYYrXbJ5IXRRApYdndGK1fvc7Usg24AKbAsgx6lfaOofbsU o5XWvkW4eut239w06Up385kZDW0uyGhtMFp2mjTMaB6bS53k301aFWQ00OZCi9tcVuN+9aorORWS KHupkHT0RpOsTWHiZVPY0VmQrDSr9qRZySrNul7pcD8olGaFVzowkpJmva90YKReAS22fl+Bfgvs KEMRQ0PRlRCeFTYUxRTQqtt9M9OsrCVDEUNDESJ8GwhPu24xN98+RultO/VwArTSYZDWED2bqesF ZZSMPTGMC+r+094+Zax0SG0aXOkQ0/C+lQ5qBBzXzONySn98zy87+0qNMdDlxEq7nDbeG2onuXK2 zlGzvXWueljPeUNjXe0atmwtVQBv9ihrFkNr1qUQvLA1KwrBq3bfXARvyZrF0JqFCI4IHoXgYbD0 uKBOAkvQBcVKu6AK4s4qJ8w2/ARATpiV1yrJ7XCBWqVL4U5hrVLMws663TdaqxTqv63gDmqVEHfa wB2iuH5bNKDjFg3ohxPAjOPcM83nrtNipLYnggo224lY2nPZkZxKAalNwxnHiIZ37q0agSWwzCOg Sn98T2AoxK4lsAwUULHSAqoTImTOpD+jtSsFsI21JNDNlhdQeWgABVSXotnSAqqY32rV7ptLsy0J qBgKqJBmkWajaDbMaB4B1UmMBgqoWHEB1Xrcrz1pkzXBSqpPsK59CuDNlrdmeWIcWrMuxWiFrVlR E6xVu28uo7VkzVpuFhkNGe3zMxp5Y7QYSejtsIcToIzj2Hez1LyXlgo1W22oppLLUQtpBmPnjIxj atNgxjGm4b3VnEaAZj3CrPTH90SzyuybigaFWcsQWXGNY/UImUWzvDrNblgnoJstL8zy0AAKsy5F s4WFWVG/1ardN5dmWxJmMRRmIc0izUbRbJjRPLKskxgNlGWx0rKsjXG/9kxT1qwwqz4rvL9YPitv Q/LEOLQhXYrRTrAh1e2+0Vs6Qv23FUZDGxIyWiOMpjVdGM19jGE0d9jDCVDGkY+OuuSg1TjaWU9u iGGa9cTKgfVU9jYj45jaNJhxjGl4565qYQGa9diQ0h/fM83uK/PJQBsSO8OGVDhCZtFsdRsS218s n5W3IXloAG1Il6LZE2xIdbtvLs22ZENiaENCmkWajaLZMKN5HD8nMRro+GEHOH5qzzRlzQoLT5nP blV8cj2VfT8oVHwSnsp2sSqh+OR9Kpt1FaeyN8qDQt9QecePJzCj4+dSYFna8RMzlV21+0bXjw/1 31bAEh0/CJaNgCXpzAKW7mMMWLrDHk4ApfGEDHa0I1OCa8aVG/z5PNLednRUnKmMNGlq07A0PqLh fWlSLgSA4D4bUvLje0bwVTgKIzhoQ2LFbUjHR8gsBNfbCF49X5SV21WFc7vrb2hdHhT8hsornDwI gwqnSyF4YYVT1ABTtfvmInhLCieGCidEcETwKAQPg6VH4XQSWIIKJ1Za4VSz+CTfKCwOsB0vr7vZ DhccdTdXwh1eWncTMZVdt/tmTmXzlnQ3HHU3iDtt4I5S4uUa3KcI2HFHvR0eRB3uEbgwSSY31PRE WjlKoWY29pqLnjIrRjZWmsbmoMCFFxe4HD/m56SjeFd7qSHfqEsE3Wx5F4onvqEL5VJ8VtqFEvNb rdp9iRFZfNaSC4WjCwX5rA0+41zy5SLcxwhCux32cAJYHLzrJ206qYfJMGGt5p3Q3NBeD0b1RucU B09sGi4OHtHwvhlhQhQgX+c+bUzy83sMR5yofTgLamN4cW3M8SEyC2dJdZzdXwqdH+W64ei6uRTO nuC6qdt9c9ONLbluOLpu6uFsoeF/vZifr2ueQIv53SnRTPv0q3gEy3ox4ySjRMSrQ52wctAbyeeP XoXdFqyLeIur9PuMjm/aZMW3luwXHO0XmK5pI11DDHu1XxgWZb9whz2cAKVrjGZEKDF2ZKIzoWwQ RshZjoMYpoGwISNdk9o0mK6JaXhnnRMD7KHlHk9I+uMLTT5+C1jBq4GyNaU9IW8x9Bo/nIrz0B6t 30nz0KDWj9fX+lWHpZydyZy97Ew+en141gYUU7syON9fBp0f5bnh6Lm51PvaCZ6but03d/K8Jc/N crP4NoZvY5/8bSx78jwMlh57S6UZYWAvBwftLcsP/wPu5dgA0nV9HxBIjxKhcBShXAp3CotQ1q8m R3ff3ORzSyIUjiIUxJ02cCc7+RzGHY8I5aSUKihC4aVFKBspqdqLarIWwNGXBXBHv5vn5NE43y7k Uj3CZmUsRe1ainyjIjn0DZVXzqhtmkDlzKVouLRyJib5V7X7RtNwqP+2QsOonEEaboOGJVlg2H2K YGF31NvhoG7GwW3PtbLC/Yca5qEXXU+6iVkiZiNYjm4msWlYNxPR8L5lGFQCuhnu080kP76ndwZD 9qVIQd0ML66bqVnuZn8pQ17e3OIJqmhuuRQUnmBuqdt9o6v7hfpvK1CI5haEwjagkBjFXlOkikWl SBV7OAECw872DmOkGUYhXQd0ZDPLvpMTU3pm8yQywDC1aRAMYxreuT63hxZlehw36Y8va1Em6Ljh FRw39ebO14W5wdRoefOKJ7CieeVSYFjYvBI1d161+0ZvTA7131bAEM0rCIaNgKGm6lXpR1WU0o+q hxPCuOPxidipl0bPRnaDYx459FaP3LJhUMT9t3GOxR2yb+4c9Inw0j6RcpOjjKzixXobyP2gULwo b7nwhAu0XFwKdwpbLhg5u/vm5sFaslxwtFwg7rSBO7TTC+7cPkbgzu2whxOgPBihE2facNFRo2bd j7wbheW8J0JTrU1GHiy1aTAPFtPwvjwYDIYeH0j643sCQ2neh6MwGII+EF7aB+IuqRQY0veRVayL a98PCkRWUd4Hsh1YBfpArgSGorAPhNGzuy/ROgcMRUs+EIE+EATDNsCQSLNsmb19jMmDucMeToDA sB8c1PBRzpKocTZ8oqaXQ9+TeZq0GroMMExtGgTDmIb3gaE0UxgMhceekv74nsFQvQ9HQTAUoD1F lLanuEsqBYZsFVnXZarvB4Uia3kRiSewoojkUmBYWETC2NndN3OCVLQkIhEoIkEwbAQMje5eV87p LmrlnO4eToBFJMNAyciYEsxwazlzPMMH2c3z6H5oPEtEktZ0hIgEbnjvyrkBAEOvhyT18QWnkhkA hqCHRJT2kGxEyNpLiLI2B+vYcoaFd0lmbcOWnm3YtVlkedIs4aLF3fiy7h7Vtx5k7dJX27v0q88T L0+apFz0vdrlxuR27RzmctE0pXvc/ZblXivXP2CxUfwB+AGL8kIgvY3lKAS61GtlaSFQxC79ut03 eiFKqP+28lqJQiB8rWzltTJzQ1b4ZclT+73SNiNg/7kAa7+L4rXfK+4/F+ua8RBFi3jBTibuRLus Qo8nhEK+x4aYdCQmPZinwKSAWJc5g5IC7pRd9PXUsf07/+p1eyzEf6nuW7gQf0yFwrqjdvTkUWjY boXyUYuGlN8K5WdOHoUp3yP7qjMlAhUTEKDsS5SWfRUsJrBKO4uNOqtA2lmUL8TvCRdYiP9SuFO6 EP96AqIQ9Mcvoo4sPRrC9VZwB71DiDtt4E5W6dEw6nicQ3UKakKFBAToHFp+9BWL8B+NLLkTWS3J VwTKV3DMb2PMz95RHR73PfKVc/YJC1C+IorLV2ruE14vvAMXKZW3a3jCBdo1LvWKW9iuEbVPuGr3 jd4nHOq/reAO2jUQdz447oSiaKU9xKHgvHt/cRiTPL6Jk3bNgr4JUdo3sREv1kv216vfwSX75b0R nnCB3ohL4U5hb0TU7teq3Td3AUNL3giB3gjEnQ+OO5coDyw8NoRK5YGhPZ2gDUGUtiHE7OksPJOb s6dT8LLC142b3b+BVZRXOHhiHCocLsVoJygc6nbfXEZrSeEgUOGAjNYIo0lCXtNOhESllgh5OAGq UGLmrp+oHhgXo5J2pPPcGWZIP1vj/kGO9DW1abBCSUzDO0vX8R6gWY/sIv3xPdGs3rlGBZRdiAqy i6MjZBbN6uo0u1G6ArrZ8oYODw2goeNSNFva0BHzW63afXNptiVDh0BDB9Is0mwUzYYZzeOdOInR QO+EKO6dOH4dcU7FLSG2K25Vr+KTU0VO0OgqcmXn9LKqyKnYKnIFdlLHrO3a+jbiKs0lLQXzPxj2 Uqlu60knFWSTLwXZjgawrJclU/Zlaf0DluuSedAPWJa31mzDpkRrzZVelmRha01MFbm63TdzNaps yVoj0VqDL0uNvCwp9lpFzn2MeVlyhz2cAOoM2WzmqZs7wYhgs+jFMAvDueXjxHWoYBysM0xsGtYZ RjS8M/U/iPBrpfRYa9IfX2ibElRvT4LWGlnaWlOz3p5cl9qG3jdkeWuN2Q6saK25FBgWttas65cf 3X2jd2WH+m8rYIjWGgTDNsCQs1cwvH2MAMPbYQ8ngGAohBqnsTODEd3MtZaM8r7jgx34xHudA4aJ TcNgGNHwPjAk3TQCZOjR1qQ/v+clzmxXjTYJamtkaW3NRoisnTvJyd3L7iV3Xy/PuX+iQpa3ZXhw AG0Zl8LZE2wZdbtvLs62ZMuQaMtAnEWcjcLZMKN5bBmVGA3K3oG2DFnBlnF0GiPHHSfJy4x8vZTj /iUOsrziwxPjohUfyGgfgdHYCSnHqt03ei461H9bYTR0HSCjtcFo2XPRYUbzuA4qzbBCeTTQdSA/ sOtgtc5Q7i8xIOOLxWfiDqqdLoU71dVOR3ff6H1Kof7bCu6g6wBxpw3ckXIpjOQ+xbgOpHo7HJpd 1dbOUz+RTmkyjtYS2vNBKzaPfBJcThmzq6lNg7OrMQ3vm12lBthxLz1WiPTH9wSFhu7azSVBK8Qy PJbczVVNgCX37wKT5QVYnqCKAqxLQWF9AdbB3ZdomQWFLclQJMpQEArbgEK+1P/mPGaOkr8eDAGh mkWvurGnveGUmUH2io7unxBtNOe9zQDC1KZBIIxpeCcQDgAPemwx6U/vMQhxKnbZYiRoi5EVbDFH Tw5lTeQuW6uPjuY5JQmkpyTB4XmpWAdnKC9FG0GQl5tFBEEE+ewIQuTbRciopVLusIcTIBSxdKKU cWKncZz1MDHCejNwyqfhZhdRGSiS2jSIIjEN7135z6EZS09yKv35hVaVlUpOUQBGWNlykIVDZE6F E1m4uPkGea2FZSB5lffteXAAfXuXyqgV9u1FrSqr2n1zp1lb8u1J9O0hzraBs1nTrGE+8zjz6kwe givKQGeeLO3Mq7qibKOwIcR15V17nlCBrr1LoU5p117Ma0nV7ps7ediSa0+iaw9Rpw3USZ48DGOO x7FXaU4MSkOBjj1Z3LF3/HiflYZSL2mos9/HM6eXZEvTSxKnlzBItRGkcqeXkt7J68yZlHonLzhn UvWdfL9663056Xrv5OhWvdQ7+Qlu1brdN3dTe0tuVYluVcSdNnCHUKaXTe3uY8ymdnfYwwngaprO upvTYpaTtXIaxDCNglhGScfIONCc1TSJTcOraSIa3reaho8SAEOPWzX98T2BoVb7shigW1We4VYt HCGzshjV3apyvxvpfeyuR7PoVr0UzZ7gVq3bfXNptiW3qkS3KtIs0mwUzYYZzeNWPYnRQLeqrO9W rT5pk7X7Snp2X9UOVllgWdpDufqG1EYxeuAbUsU9lO9bfLl7hR7KK4GlKu2hjFilXbf7xq7SDvbf RsBSoYcSwbIRsNR0WaZ9+xgDlu6whxOCYKk8dkU79dLo2chukGaQQ2/1yC0bBkXcfxvn2FlhsmtW WIF2RVXcrlhxVlit67pDbKeK2xV94QLtipfCncJ2xZg8Wt3uG6ujCfbfVnAH7YqIO23gDu308kBu HyNw53bYwwnQrPA0WjJZ282z6kXPhR7NrPjYk8HKnjKWMSuc2jQ4KxzT8L5ZYU07AAw9csX0x/ec cSS7Mo4KlCuq0nLFmvU/1Vr0BpVcUsU9hb7Aip7CS4FhYU9hTP3Put03Fwxb8hQq9BQiGLYBhsTw VweO+xiTB3OHPZwAguFEqLWS9qrj3FDK1GBYN5FhGjtGOpMDholNw2AY0fA+MFQGyhh6jI7pjy8I hkAhUAUaHVVpo6O7pFJgSFeRdV1A9H5QKLIWlyP6AivKES8FhoXliIye3X1zJ0hbkiMqlCMiGDYC hnUnSD1yxDoTpG6QDeMOKEdUpeWI7pJK4Q5bxYuNEqUMiBfF5Yi+cIFyxEvhTmk5Iju7++bmwVqS Iy43i7iDuPPJcSd7gjSMO57K6pWm/RiAO2Bl9eWHXw531uN+7YUxOWv2HT9GlrQqvHg5Z3eE6mLd NIVnmnLcNIq+uGnq7Y5Yi3jAb6i4FdJHE2iFvBQNF7ZCRu2OqNp9c2m4JSukQisk0nAbNJw9Kxym YY/0sM5cJ7g7ApQeqtLSw41xX652sK4Z7X5QaAcrzGhUpuxgvTMalYenbhawZClg+U2OtHrvqB5h sxBevCB8KRpedSu1sZsb6FaquNHJRxNodLoUDZc2Oq0GmKO7b+5UeEtGJ4VGJ6ThNmiYdlS85oap iMoNU/FwArRGchbCKj4JNmk68UFI1Q1zZ4ScRkHZGBA4gWskU5sG10jGNLxzjeRkgPcGT63t9Mf3 9N5g2PtwFH5vAGttq+L+K1kxTboWSoAUXNx/9T6fvzxI9F9dCgwL+6+i0qRVuy8xIg4MQ/23FTBE /xWCYRtgyJRZwPD2MQIMb4c9nADW2p6mG9sMY09viyFlN49Dr2fJZT+o0QaUV3Ct7cSm4VrbEQ3v A8NphBLKHmNY+uN7BkOxL6EMGsNUaWNY1XI7+2t0q+ISFl9gRQnLpcDwBAlL3e5LdB4YtiRhUShh QTBsAwyJluZ188ytsHDE5hlpHk6AwFBopsQ4CG6V5VZMVGslaK+4mZnsZM6u6tSmQTCMaXhnxpCP ABh6JCzpj+8ZDHeW2wElLOoMCUvhCJm17lZHr7stm+/JmrRX2+tuq89e5qzpUPJlTUe9lQbrEuzg zRbX3fi4C3U3l3pvKKy7qTmPovdvCNDli/Fvd3uNxfiv1O11/WL8B4/a0QtsQsN2K6/LaHnC1+U2 XpezF9iEXwI9lqeTlo2AlidV2vK0sbDyYGzJTJPqliQsGiUsOO63Me5np0mD4772SFjqJP+gWWEN Slj0lSQsev9mfV1ewuIJFyhhudRr7gkSlrrdN3O5oG5JwqJRwoK40wbuZC8XDOOORy1SZxEcNNep QbWIrqAWOTq9mTUDZ7Z3VVd/N8+Z69S+GkO1I2zOrLJeqjlVm+vU+zfr6/LmGbpNE2ieuRQNFzbP xOyqrtt9oyd9Qv23FRpG8wzScBs0TImhy6SP+xgz6eMOezgBWiNJzUgEGZnsmVL9yJgdO/eNGT4q Y4wiGWskU5sG10jGNLxTSWiA2qTaY55Jf3yP0Yh3Ytf0mAbNM7q0eeaECJnz3qB91Zhqe0MWBKcp LzvsjuDFit5vfEPrmwW/ofKOHw/CoOPnUghe2PETNcBU7b65CN6S40ej4wcRvA0EV2rJRysVk452 R70dHoZKj9+HSTK5oaYn0spRCjWzsddc9JRZMbIxNhmt9q250qDfR5f2+5ww5mdBJau9HUSvS4OC N1teSuSJbygluhSfFZYSRf1Wq3bfXD5rSUq03CzyGfLZJ+ez7BRpmNE8UqKTEn+glGj54V+inKLe X1Rcl7fOeMIFWmcuhTsnWGfqdt9c3GnJOqPROoO40wbuVExHeYwzldJR0FYQ0DijKxhn6m0FWVc1 AVf6lVeKeEIFKkUuhTqFlSJRW0Gqdl+idRbqtKQU0agUQdRpA3UIf9v5yuN2vvLXna88okAg5eOs hba81yO1DnHGTqtu6KnlTGmaoxRJbRpe/BbR8L7Fb6IHCgRqj1Ik/fE9gaHYuWkGVIro0kqRmE0z hec+suYpefV5yo3CgtDNlvegeGgAPSiXotnSHpT1ms/aNJu17Up6inke/JvLRfCW5C0a5S2I4Ijg UQgeBkuPkqQOWIKTq6CSRBdXksRsbC47y5S1sbm0eXl9s+sy2+DNlveoeGIcelQuBZaFPSpRM8JV u2/ujHBLHhWNHhVktDYYjSqtlgVw6vbKBy+Ac4c9nAClSfvBKmPJPA1a024gapbz3ItZCU1JT1hG mjS1aTBNGtPwvjSpnQDBnvZ4VNIfX9b8OehR0aU9KlXnz9c1icCUTXlRBtsOrCjKuBQYFhZlRM2f V+2+0WAY6r+tgCEaAxAMEQyjwDCMOx5jQB3cAWeFQWOALm0MiDGwFU4IZCXvdHRVwrLBKmt6zBSu Srj6hsz+upGmvIpqOzAbVFFdCSxNfRXVwd03EyxNS0oSg0oSBMs2wJIYs4Dl7WPMrLA77OEEKONo maX9wKVUjI0DkUQJI2nHZjLNwow5GcfUpsGMY0zDO83NA7Aw03jkLemP7wnB3bvAnoyjAeUtpoK8 5egImYPgpqs9f27WBcXBmy1vnPHQABpnLkWzhY0zUb/Vqt03l2ZbMs4YNM4gzSLNRtFsmNF8xplz GA00zpjSxpkYoXbhte1Zm2dU7c0zZn+ZbFPeg8K3Yxx6UC7FaCd4UOp232hGC/XfVhgNPSjIaG0w Wt2pbOOxe1RauQfsQzGg3cNUsHtUW7lnNgQbwGyyKe+c8IQLdE5cCncKOydiVu7V7b7EDVI5uNOS c8KgcwJxpxHcoVovuHNfEAbjzm1919sJYOWbkc2WdoYOQo96pMJ2nfs0zFbMUg4yp/JNYtNw5ZuI hndq32ZA+2Y8ho70x/cEhlLtWuNoQEOHKW3oiFnjWHjSJmuClVSfYN0o8wPdbHlDh4cG0NBxKZot beiImWCt2n1zk3ctGTqWm0WaRZr97DRbN3nnMXScs+3WgIaO5Yf/EbfdklW8WBefuR8UihflDR2e cIGGjkvhTmFDByNnd9/c5F1Lhg6Dhg7EnUZwJzd5F8Ydj6WjUkqKALgDWjpMaUvHetyvvkYlZz2Z oS/ryY6eacrZdmtY4W23629oXYIX/IbK+1A8gRl9KJcCy8I+lKhFcFW7LzHb/TcWLFvyoRj0oSBY NgKW2pAFLPVtCg0GS3fYwwnQrDCb1Mw7Rek0Kdr3epzl0BNJ+TS6k4jKmBVObRqcFY5peN+scM97 AME9PpT0x/eccdxXttqAPhRT2odyQoTMQnBZfUvH/v0rprwPxUMD6EO5FM1W96Ec3X1zabYltYhB tQjSLNJsFM2GGc2jFjmJ0UC1iKmvFqk+PbZkHEkKo93VIlG53bLBKgss6+8V3qgfCd1seR+K2A7M 6EO5FFiW9qHEgGXV7hsNlqH+2wpYog8FwbINsCRaLhdx+xhTz8Ud9nAC6EPRfc+mwfZED0IKMjBF ZykJV3MnJj3k+FASm4Z9KBEN76xOyKGFmT4fSvLje0ZwtQ/BQR+KKe5Dqbmren+NblPehyK3Ayv6 UC4Fhif4UOp232iZcaj/tgKG6ENBMGwEDCV9BUP3MQYM3WEPJ0BgqGxnmbGG8NnMrLfjNHbMEtLN Qk7zMGaAYWrTIBjGNLwPDKWAwNBjjkl/fMElrNCuatAcYw4wx9ROnWSlOXX0EtayYT1rCetijjl6 T2zW/nVeeP/6+27Fuo1q6OFudTvlkPcG94fwveE67w2vX9eBCeXK3Tc6oRzqv228N7zeLL434HvD Z39vyE0oh2j49kP6OGnS29WEafj1h/8B06QrtmPd7tpEt1MOwh30oVwKd473oVTuvnlp0pcH0gru oA8FcacR3MlNk4Zxx+NDqZP8A8r13K4Gwp0KPpRas8KsW+97B/Jvt1MOwh1Ui1wKdwqrRSJmhSt3 3+jqhKH+2wruoFoEcacN3KGSyGUfivsYsw/FHfZwAjQrPI6dmCnloyCUjCMVw6w6PbuxZrCMmz5j Vji1aXBWOKbhfbPCloULG92GnE0wTH98z3kwsmdW+HY1EBiWlrCcECEzJlhv91+0RtDGze4uiHQ7 5SCaRXPMpWj2eHNM5e6bS7MNmWNebxZpFmkWaTZMs2FG8/hQTmI0yIfy+sM/cuVe6TUqGSv3bnO1 myv3qs80ZSyCu2Vcvy2COzrCZtFw7YqZrNtYpgh1q/LmGQ9NoHnmUjRc2jwTs3KvavfNpeGGzDOv N4s0jDT82Wm406807D7G0LA77OEEKLc79OOotOGEWNMJMvPBSm31aN0lzyOdMnK7qU2Dud2Yhnd6 FCn03uBx9KQ/vqf3Br1LsH27Gui9obijp+Yax3UVJxDdyzt61HZgRUfPpcCwsKMnao1j1e4bDYah /tsKGKKjB8EQwTAKDMO443H0VMIdaI0j5Oh5/eFfY43jurA4mPTbod6gWbhTxxzjCRq3OOGFkifs 8H/zhd0prHtiFvv1p6//+uNPf/nlTi+nf7dGZLFAQ1qV15v9xgL/+PpF/lNS4P+7P/zDH/7bf/6H //rHXYEdw/H1wnGJJ+IPxt2y4WB96Hdfvv70eP/AkHf0uq2PP7DRlgY2igMbDmyfcmCjwMDGmhvY WEsDG8OBDQe2TzmwMWBg45ca2LTJH9h4SwMbx4ENB7YjMsPkLTNM4jLD5DUzTCKWDMw9EaPitKND N6mJk26cJymlUoP7fyJnyUBq0+CSgZiGdy4Z0BbIoXskm+mP7zmHrvctNYYkm6+jVDhIicJLjcsu qstaaswji4RWf2Vg+ZFVtBRZBUZWjKzPkfUPf/nR9ZuPGV8/YdQQQNSQV3q10QXGX9nS+Ctx/MXx 9wpvNieOvMrUGXklMPKqK428RdBXfYqh98enBTVf7Y+T64vfrsNdQbFO+h+enkLZlh+fXfmWqz+S b1/39/821Xgq2Y1vJSvWPS8ygCsM4BcJ4FeZ61BAWNJZaaTaS/CzNn+L6gaU3f7w2ykHbZdRuF3m Sttl1An7qKt2X2K21z/HIqRqaYmswu0ySB5NpA54p/lyEe5jROrgdtjDCdCkKJ3nfuaMkplOVA6D HZmwxorRfW2DVCRjUjS1aXBSNKbhfZOi88yBJIvaTrKkP77n9LbYt49agUkWVX4f9dERMmtSVL1M itaj2d2ayNspB9GsRpq9Es3qE2i2avfNpVndEs1qpFmkWaTZGJoNM5r+UIymQUbTV6p1sxZMg5nK gGC6LO4YxJ0r4Y45odZN1e6bu6nAtIQ7BnEHcacJ3CGa6ld98cu4DOmLqX44AUreMWM7PpFhHjo2 dqZTo+nN2JHRTDPtLMtI3qU2DSbvYhrel7xTFAJDsw2G6Y/vCQyl2VcVyIBgaMpXBTo6QmZNRZvt OuTVsxhZGUddO+NI9pe3J4Hy9kURnHSI4BdC8OXrOjLjWLf7ZiL4twfSCIIvN4sIjgiOCB5G8CBY uh/SkWAJZBzd1QBgufzwK84KX3LpvW5j3F9uFhdN49B71K5TIl/3Pt0+xgzActn7dD8Blvxy1XXU sl5JOVgp5tHKbiZGEWKpmLMkv2lNR0h+4Yb35UCkSdwllv74HsMCl6LKLjENhCpTtqpD4VeUnHQC 6aqnEzbEc9DNBsRzZdMJBNMJV0onkBPSCVW7b246gbSUTiCYTkCm/WhMW4VmWdctF3H7GEGzt8Me TgBpVkwj7fXIBjWImU+kl73VnVGDtcJ2WTSb2DRMsxEN76PZvu+BxAvx0Gzy43tOvOxb6uWuBkq8 kBOW4xeOkFk0S6rTLN1/s7Q4zeptGqBIs1eiWXoCzVbtvtE0G+q/rdAsRZpFmkWajaHZMKPRD8Vo FGQ0ev3JsRdGc8N+wgImeWO0qDRp2WCVBZb0BSxHO/3409fvvvzyp7/8Ov70L1+//Oy6/+Q4cvzi urK7mu9//d515/F33rZuygvXFtH+Izi7/zX67/7L3//xy68/28H9qz/+8e/ZF/vD9POvX/7l5+9/ nb77F/vzV/cQvruf+uXrT79+P/9roMlv1Xv5/iZvqDy+3u93X/7Fult8efi3ed7pZ3v7e7/87a/2 l/9x75Ozewq//Gl14uuzcSHx9y/j0GDdl+m+2h8mN/T/s/3hh+C/+9bi6B73zz+5n9z88zTdruSX f3XP/0f3Tfzy019+dl/k75Y//etPf/7z7av4/wH6MqRpbr8OAA== --5fnLV4VEuZ--

1 0

(ITS#6414) back-ldif can write to parent dir of database dir
by h.b.furuseth＠usit.uio.no 03 Dec '09

03 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-ldif can be convinced to write/delete a file in the parent directory of the database directory: "<database dirname>.ldif". That shouldn't happen, even if the only use case I know is silly: slapadd entry "" to an LDIF database with suffix "". Fixing. (The fix is not to prevent this in slapadd, which explicitly accepts this case - I think for some syncrepl magic from bdb.)

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by hyc＠symas.com 03 Dec '09

03 Dec '09

Howard Chu wrote: > aej(a)WPI.EDU wrote: >> I ran for a long time with -d1 and it didn't loop again. >> >> Then, I changed it from running in an xterm under script to simply: >> >> slapd -d1 2> /filename >> >> This started looping almost immediately. The script is in >> http://users.wpi.edu/~aej/trace > > I think we'll need a copy of your client and server certs to reproduce this > locally to identify a fix. And your slapd.conf / ldap.conf / .ldaprc TLS settings. > In the meantime you can revert the patch for ITS#6304 to avoid this problem, until we come up with a real fix. (Revert slapd/connection.c:1.446) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 03 Dec '09

03 Dec '09

On Nov 22, 2009, at 6:43 PM, Howard Chu wrote: > bduncan(a)apple.com wrote: >> On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: >>=20 >>> --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com >>> wrote: >>>=20 >>>> Subject should have been: "PATCH - Added kqueue support to slapd" = to >>>> make clear this ITS tracks a patch that has been submitted. >>>=20 >>> What OS(es) has this kqueue support been tested with? For example, >>> the last time I looked at kqueue on OSX 10.5, it was very marginal, >>> and missing most of the important pieces, which meant it wouldn't >>> work for OpenLDAP or Postfix, etc. >>=20 >> It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- >> specific about the kqueue usage in the patch. As far as kqueue >> support in OS X 10.5, from what I see, most everything is there. >> Certainly all of the kqueue features in this patch are supported in = OS >> X 10.5. >=20 > To expand on this: there are a lot of comments around the web that = kqueue was fairly broken at least up to 10.5. E.g. this: >=20 > http://lists.schmorp.de/pipermail/libev/2008q4/000523.html Perhaps I missed something in that thread, but the only specific = complaint was regarding kqueue and stdin. And it's true that OS X's = kqueue didn't support EVFILT_{READ|WRITE} on *devices* (stdin, tty's, = /dev/* ) until 10.6. I don't believe OpenLDAP actually needs that = feature, though. >=20 > Since we also use a pipe for the wake_sds[] in our event loop, if = kqueue only supports sockets, then it cannot be used reliably in slapd. The OS X kqueue has *always* supported EVFILT_{READ|WRITE} on sockets, = pipes, fifos, files. Same for kqueue in the BSDs. (FWIW, I believe the = BSDs have always supported devices in kqueue.) I think everything OpenLDAP needs from kqueue has been, and is, = supported by OS X and the BSDs. If there is a specific kqueue filter or = fd type that OpenLDAP needs and isn't supported, please let me know. Although I don't think it's necessary, you could add a test to the = configure script to ensure kqueue supports the types of fd's OpenLDAP = needs by doing something like this: int fd; /* or int fds[2]; */ /* do something to create an fd here: open(2), pipe(2), socket(2), = etc. */ struct kevent ev; EV_SET(&ev, fd, EVFILT_READ, EV_ADD, 0, 0, 0); int kq =3D kqueue(); if (kq < 0) { ac_have_kqueue =3D false; } else { struct timespec to =3D {0,1}; /* anything so that kevent will = return */ int ret =3D kevent(kq, &ev, 1, &ev, 1, &to); close(kq); ac_have_kqueue =3D (ret >=3D 0); } If the fd isn't supported 'ret' should be -1 and errno should be = ENOTSUP. -- Bryan Duncan

1 0

(ITS#6413) Race replicating syncrepl config
by rein＠OpenLDAP.org 03 Dec '09

03 Dec '09

Full_Name: Rein Tollevik Version: CVS head OS: Solaris URL: Submission from: (NULL) (84.215.13.80) Submitted by: rein There is a race condition when the syncrepl config in cn=config is initialized in a MMR configuration. Seen by test050, but so far only on Solaris10 x86_64. The problem appear to be that a do_syncrepl task can be added to the thread queue while syncrepl_config is deleting it. It removes any tasks already in the queue, but the main loop in daemon.c is still running when the thread processing have been paused and can add new tasks to the thread queue from its runqueue. A patch is coming. An alternative fix may be to stop processing the runqueue when threading is paused. That may still leave the possibility of a task being added to the thread queue as a result of syncrepl input, although I haven't seen that happen. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by hyc＠symas.com 03 Dec '09

03 Dec '09

aej(a)WPI.EDU wrote: > I ran for a long time with -d1 and it didn't loop again. > > Then, I changed it from running in an xterm under script to simply: > > slapd -d1 2> /filename > > This started looping almost immediately. The script is in > http://users.wpi.edu/~aej/trace I think we'll need a copy of your client and server certs to reproduce this locally to identify a fix. And your slapd.conf / ldap.conf / .ldaprc TLS settings. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6412) compute loop in openldap 2.4.20
by aej＠WPI.EDU 03 Dec '09

03 Dec '09

I ran for a long time with -d1 and it didn't loop again. Then, I changed it from running in an xterm under script to simply: slapd -d1 2> /filename This started looping almost immediately. The script is in http://users.wpi.edu/~aej/trace

1 0

(ITS#6412) compute loop in openldap 2.4.20
by aej＠wpi.edu 03 Dec '09

03 Dec '09

Full_Name: Allan E. Johannesen Version: 2.4.20 OS: RedHat Linux URL: http://users.wpi.edu/~aej/typescript.txt Submission from: (NULL) (130.215.36.68) In one server environment, I've found that slapd starts consuming CPU. I ran it -d-1 and it seemed to run ok. Then I tried -d1. That usually worked, but on one occasion it ran away, too. I think debugging affects the timing. My belief is that it's in a certificate retry loop of some sort. I'll attach a log of the -d1 output showing some cert retries. This run didn't go into the loop, though. The one debug -d1 which went into a compute loop was spewing these. I managed to ^C it, but also managed to delete the typescript, so I can't show the thousands of retries on the one connection which had kept it busy.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 03 Dec '09

03 Dec '09

--0016367f92e6a19d180479d1aa27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached to the configuration file server testing openldap squeeze. I made some changes to the file /etc/ldap/slapd.overlay.conf being included by /etc/ldap/slapd.conf and discovered that the problem is with the overlay rwm, because when I comment that overlay the problem does not appear. If I keep the following entries rwm overlay the problem happen again: moduleload rwm overlay rwm Even with the other settings overlay rwm commented the problem continues. Any ideas? 2009/12/2 Howard Chu <hyc(a)symas.com>: > jarbas.junior(a)gmail.com wrote: >> >> Full_Name: Jarbas Peixoto Junior >> Version: 2.4.11 / 2.4.17 / 2.4.20 >> OS: Gnu/Linux Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (200.152.34.143) >> >> >> Possible bug in Overlay pPolicy >> >> I have OpenLDAP installed via the Debian Lenny package functioning >> normally. >> >> Aiming to test the version of Debian Squeeze in the test machine install= ed >> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >> >> However, when testing the overlay pPolicy noticed that a wrong password >> authentication, runs all objects in the ldap database, causing a "delay" >> that >> does not exist in version Lenny. >> >> Below is some information that may be useful in detecting the problem: >> >> File: slapd.conf >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> moduleload =A0 =A0 =A0ppolicy >> overlay ppolicy >> ppolicy_default >> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,dc=3Dbr" >> ppolicy_use_lockout >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov,= dc=3Dbr >> '(cn=3Ddefault)' >> dn: >> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dpreviden= cia,dc=3Dgov,d >> =A0c=3Dbr >> objectClass: top >> objectClass: device >> objectClass: pwdPolicy >> pwdAttribute: userPassword >> description:: >> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >> pwdAllowUserChange: TRUE >> pwdFailureCountInterval: 3600 >> pwdGraceAuthNLimit: 5 >> pwdInHistory: 0 >> pwdLockoutDuration: 60 >> pwdMaxAge: 7776000 >> pwdMinAge: 0 >> pwdMinLength: 6 >> pwdSafeModify: FALSE >> pwdCheckQuality: 1 >> pwdExpireWarning: 600 >> cn: default >> pwdMustChange: FALSE >> pwdMaxFailure: 10 >> pwdLockout: FALSE >> >> date ; ldapsearch -LLL -x -H ldap://squeeze -b >> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgo= v,dc=3Dbr -w >> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >> pwdAccountLockedTime modifyTimeStamp ; date >> Qua Dez =A02 16:14:56 AMST 2009 >> ldap_bind: Invalid credentials (49) >> Qua Dez =A02 16:15:36 AMST 2009 >> >> grep 'access_allowed: search access to' /var/log/debug | wc -l >> 83714 >> >> The question is: why access all entries in LDAP? > > Don't know. This would have to be the result of a search operation, but > there is no search code in ppolicy.c. Since ppolicy cannot be the culprit= , > we'll need to see the rest of your config to track down the issue. > > -- > =A0-- Howard Chu > =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ > --0016367f92e6a19d180479d1aa27 Content-Type: application/x-gzip; name="ldap-squeeze.tgz" Content-Disposition: attachment; filename="ldap-squeeze.tgz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2rgwh8a1 H4sIAISmF0sAA+1aW28bxxXWK/dXDCgjIhNSInVLakBAGUpKhFKXiLJjN06N4e6QnHh3Zz2zK4lu +hP6H5r2IciDn4K+9JV/rN+ZvZDUxVEQKgWKPZDBuZ4558y5ztr4PPLWXRUOVx4NWoDdVmultb2z s9napn4bf3Ycv+32p7sr7fZWa+fTzS1qt9o7ra3NFdZ6PJJmkJiYa8ZWvuN6wM16JOS1itXtdfsq 4DJkz4zQ5veg63eCVdbRbxN5qZ6yDRG7G77How1TKIWz6qyyAxNrHk9/GknOPMGO5Ujz6Y/Tfynm KYN/gQwlGl/L0FNXhkVcc9YjPH0eDPhTYNj7DeCkFAg2/YkpxlNqiQ6iT46SnJZIy9CVEfdBEbMc UCNI/Fg2Aw4EuvniBXA9F99xNuOwtlNPKVYDLGG4ZMNkOFQ6ILz/FmYdMnBWV9m+1CKWl9ywL3w1 wDIMLgWIwX0xhBDTA4m3vjsWAWcCVH0n3Ljrc2Mc8OcnmMxh7sLs8g1XabGeth+y2MiwWL76i+tD aR6MWw/dza3Wp4NfsQW0xEqPIpiXCh+86y3uy09gkw/eEY2j0RV3XZWE8a/bBG2JufvwTYa0/8Gr vUk40iqJHk5TpHzpTvL1UKJMaTzOzrS4lJ6APXBWi9A55rFuMGqdyDhtdKNhgwFp/ZeP8pXL/bmD TkOsFiae/sDslHzHYWoz41yLpLdWmKGD3lD6c/gvud7QSZj6mczbYBGh7kn4Y7IArkdJIMIYjuVt IpixJg4r4ORzUoNluHewqbSDxWb+iDtPoEV0xMn0/aXw6QxfjRjEBJfRZJfkFqz1i2DRPTirWOcL 2pMBSIwNw4HkMbjrO3cvoBkncxzTn7WEiHLBgRmwEUx/9hKffKgMp/8MJEzSCRSGRMTjcWUjMXrD lwN7F4TpOF/PiXXQ6XKtxYhEku3zFfcqA+6+eT32BlaeaqSGQ+sufQlxCvJuHH6MThWRktbdtHcY nHhCwq5ttVrAPkrgzA10w/Ph9QKhkphhhlB+lfAwlh7HPk2yI9xRsjZ3T0ksrU7w7KYQGMR16qad WCm/GY+x0zOVbau2ImbxWLAwCQaQpxqybJrFin22zlgPNyeyQXbJ/cQy4aJrbBSIwZdUIVDx0GOh iqUrB/6EySCCvTK4FOvOQ1c4+cGVz3Dyb4lKc/GJOKAwFE5/5FCki15/o9/vsdoFhkykdMx6Vjf6 wk20jCcbtgEfr9w3AmrS4xOh6w72dTtdoWM5lC6PxSHp85wpGn/DxazZ6Haa1ECqEthND9gSBDRw 37Y/ickdOxFPLzGZ730jJvnW50LL4aRr9Ylx31dXNkAekRux9w+NiBXdfqfbW16YLELUzUQF3lwY k+YrdBpJOs0JDkyE5ntiM9XEz2EaIrSZQSwjxWAlT5dF4KozSLFXKqnxfYgSeyrb5zEfkBavtpgb 7qUZzVNWO7/oPmXnSdi8gOk1u3miQ1peXx65jpcfnx7sOFqp2AsZq4IY7sElNAqqqnYyumLsr/3+ l52/vbDJVL9/SAbb3vyMKc1GMC5yiXAqiMke2a9JdT29ImzAUIHSMZlFMANT9cXrARzFHnD9Stm1 mefuRbOQ10B3pC7pZ6CXJq45eWX3yzrMEgCV9Aof75hkOJTXlUr1A0RVrR+NPbsXVqStr4RDD0RA WLjjckRbI9+JyiYVSXcthw5P34eedMX8Tjjw62qxu5qqPei1rnyGdddiBVoMuG8YAgFs+WosQrgq zXa33zBilg0mFDGucElwsrhibMhCBYbHRDMskK76aiyBifYqF5dK0VGb2LHYLfLK7nZlx7r7BA45 Mcn0B4qIYCKXaqZ9kBw05JiHfCR044NCTDWyUik08kWRnVCQTLMRG+A8mzZkkXcoDVSJkgtKMwL+ ToQ2hNIlukhCJ5WqTSDy0LtRtf5t+ncrbMNCQcps6Sfvxjo+oqVhtJTOyJWV8hTl4WqsSWR7PTlE 5CZevDQCw1/gTxEeW9MESKNAe4TcLitA2BAUBmSjBsUMZ9N/pGpns4Jl6bYN0chc5uqNRiK9ExuT G6OiBTXDD2ayVkNdhUJXxNsCA82ZsEGJOfZdijCEqBueNJHPJydoVypY3jDJoNji4tItpOMNHkVa XafTFZtG94/2G7aRluGEJu1/QTnzxSTKulhHGWRBT8Vm7p003bfL5gf6SNMSY88taPGED6L15BhX 1+Dz6xoqaagGkM/WV4jLDqWByKlEx/M0FMOyfqj0FdfI60bZ6MIhAu5OTYTIhFpk6HmCnuXni5Sl qyBVavRJb9INp3QDtrUvfGSDME277z6VTV2CmYQupHyJjOVc5NoG44AG2jmNwYxJ8jiTbv+kYRvP nh3tZ5d1M+xDceeL8qyWPX1+cN7rvFxeInBfHqBwb9CxIhFYzEj6L0+65wdnvYx/JCgQRV5BCIpN HSrvQ1vJrM2/G6w9fgqTS/whSczN8LdJEfVYhTJWy4x2s4IirWlsVRFkxxSRMB9w0ghP8d1D+Z4M Yi3EXnVGWdXJi6PBhH1MlQPqvf/t21cJKyu3LWf5Z9j33+3te95/W7tbm5vZ+y89/G6ttNq7O+1W +f77e8AH3n8X3Oky3oGX50bh//Kogvj14OYSX2xXbTw5Oz99Dvy2eqF80j5KJVTzC0rTrFeH+3uX iYmEyyJBLzgQ8aVYHkE3nXUe3Z3sEmcDeaM5S80ZrBH/ZlMGnhylJj2PtW2VsMrOzk57R92Xi8zS +47yp+9jhCYb6o0Ix2llstTk9CZ32dNnwVzez35fe2LIEb9tIZG1kbztkS6eIbG9Utqj/hlWW9Kp 83kiEfHDDxcc+QGobl/7yn2jkthK5/zg8OjkYkE2kKsY6fyZLE/6fWsqIw0debzL1/QxIS6kk3XT n9c8jrUc2PotzeDziVDFY6Sr7MHVl2X86+Ob+h/wSNjiymZdnfQ0yjpB4ezF9tF4vwpyxivUhtv6 kg8kLppoW9OCallxEI5kKNYcrGguDFVUaB9aCx6sWh9CNXTaPBMG7tLw+a1deoK8jsEc1+740D4L 51ikPTah9/AavY8ivRbTH3lg82xfxJSJixHmrbTC6X8CgZOyT1Jri3XCAr3nYJtVa+sf11+9qmH/ Xu0b3nzXaf75229azT98+wmG6zRbZdUn7doior0nm/UnW5h5Wr2PzpgsOUAditrY3KLr/k8Kv0Tj HbR9X3yhILpqGcaiDaTUvpvgm+Xd3miNKS2TMHsgEdcRFV8qp1sZeW1LxvvpvI1ygdq5Anlvhq7+ ZLOgrkfvzozPCnbvLkKTuwl9OFnJPFlzx8/dZihxlcfWytcyCQRZD1XfYTf7Rnf/lc0hwN39pX7z 6lJs96rTXdVxQQjm1hjMys1Krj/OeZr1gU6XLQzC92DiXmrvOm2vtv5J/QbmRQ6wCfTfcc7dLLlh zsDci0Z+lTYLYvE4odp8ILV3L62vXn2fUWwpBEnowvHOOvbphJDPjZm5BXUUVNXaR7CeBY0EG2f2 E2r91vhRaOLbo3145Nuj9IhSrwN5Jp86Efdkq16b45r69Xouo1X27OToq2cH0KwR5EOxQDAokJuG QPqilz6TqSSrvXkeGh4hGFRS1S1iYNZNf16nr7YfeDPO1s3HSsjBcnl8cPz5wfnpIfgMwKUICj5y 4zodrjGOfsDj/JnxMThMD1PDgsdiIG807QflpnKZbZwO6dbMbDptNBE6s0zA/jeHlye9o/4F2Nuf hDyQrv0kyxa+QTwGO94k9HFQwU3ez36bdBdGxAusMJ8PhC+8Z+dHBQvlm0IJJZRQQgkllFBCCSWU UEIJJZRQQgkllFBCCSWUUEIJJZRQQgkllFBCCSWUUEIJJZRQQgn/x/Bfxxv0fABQAAA= --0016367f92e6a19d180479d1aa27--

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by hyc＠symas.com 02 Dec '09

02 Dec '09

jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) > > > Possible bug in Overlay pPolicy > > I have OpenLDAP installed via the Debian Lenny package functioning normally. > > Aiming to test the version of Debian Squeeze in the test machine installed > package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). > > However, when testing the overlay pPolicy noticed that a wrong password > authentication, runs all objects in the ldap database, causing a "delay" that > does not exist in version Lenny. > > Below is some information that may be useful in detecting the problem: > > File: slapd.conf > ==================== > moduleload ppolicy > overlay ppolicy > ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" > ppolicy_use_lockout > ==================== > > ldapsearch -LLL -x -H ldap://squeeze -b > ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br > '(cn=default)' > dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d > c=br > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: userPassword > description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= > pwdAllowUserChange: TRUE > pwdFailureCountInterval: 3600 > pwdGraceAuthNLimit: 5 > pwdInHistory: 0 > pwdLockoutDuration: 60 > pwdMaxAge: 7776000 > pwdMinAge: 0 > pwdMinLength: 6 > pwdSafeModify: FALSE > pwdCheckQuality: 1 > pwdExpireWarning: 600 > cn: default > pwdMustChange: FALSE > pwdMaxFailure: 10 > pwdLockout: FALSE > > date ; ldapsearch -LLL -x -H ldap://squeeze -b > ou=usuarios,dc=previdencia,dc=gov,dc=br -D > uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w > wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime > pwdAccountLockedTime modifyTimeStamp ; date > Qua Dez 2 16:14:56 AMST 2009 > ldap_bind: Invalid credentials (49) > Qua Dez 2 16:15:36 AMST 2009 > > grep 'access_allowed: search access to' /var/log/debug | wc -l > 83714 > > The question is: why access all entries in LDAP? Don't know. This would have to be the result of a search operation, but there is no search code in ppolicy.c. Since ppolicy cannot be the culprit, we'll need to see the rest of your config to track down the issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by quanah＠zimbra.com 02 Dec '09

02 Dec '09

--On Wednesday, December 02, 2009 8:25 PM +0000 jarbas.junior(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 / 2.4.17 / 2.4.20 > OS: Gnu/Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.34.143) ppolicy doesn't execute searches. Please provide your entire slapd.conf, minus passwords. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by hyc＠symas.com 02 Dec '09

02 Dec '09

andreas(a)canonical.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I also just uploaded a new attachment to the launchpad bug entry with the > contents of the slapd.d/ directory. Thanks, a fix was committed to HEAD yesterday. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 / 2.4.17 / 2.4.20 OS: Gnu/Linux Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.34.143) Possible bug in Overlay pPolicy I have OpenLDAP installed via the Debian Lenny package functioning normally. Aiming to test the version of Debian Squeeze in the test machine installed package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). However, when testing the overlay pPolicy noticed that a wrong password authentication, runs all objects in the ldap database, causing a "delay" that does not exist in version Lenny. Below is some information that may be useful in detecting the problem: File: slapd.conf ==================== moduleload ppolicy overlay ppolicy ppolicy_default "cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br" ppolicy_use_lockout ==================== ldapsearch -LLL -x -H ldap://squeeze -b ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,dc=br '(cn=default)' dn: cn=default,ou=LdapPassword,ou=Politicas,ou=Builtin,dc=previdencia,dc=gov,d c=br objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: userPassword description:: UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M= pwdAllowUserChange: TRUE pwdFailureCountInterval: 3600 pwdGraceAuthNLimit: 5 pwdInHistory: 0 pwdLockoutDuration: 60 pwdMaxAge: 7776000 pwdMinAge: 0 pwdMinLength: 6 pwdSafeModify: FALSE pwdCheckQuality: 1 pwdExpireWarning: 600 cn: default pwdMustChange: FALSE pwdMaxFailure: 10 pwdLockout: FALSE date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:14:56 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:15:36 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z modifyTimestamp: 20091202191724Z date ; ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br -D uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br -w wrong-password '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp ; date Qua Dez 2 16:19:03 AMST 2009 ldap_bind: Invalid credentials (49) Qua Dez 2 16:19:44 AMST 2009 ldapsearch -LLL -x -H ldap://squeeze -b ou=usuarios,dc=previdencia,dc=gov,dc=br '(uid=jarbas.peixoto)' cn mail pwdFailureTime pwdAccountLockedTime modifyTimeStamp dn: uid=jarbas.peixoto,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br mail: jarbas.peixoto(a)previdencia.gov.br cn: Jarbas Peixoto Junior pwdAccountLockedTime: 20091202161422Z pwdFailureTime: 20091202162324Z pwdFailureTime: 20091202162805Z pwdFailureTime: 20091202162925Z pwdFailureTime: 20091202164558Z pwdFailureTime: 20091202164702Z pwdFailureTime: 20091202165016Z pwdFailureTime: 20091202181310Z pwdFailureTime: 20091202182914Z pwdFailureTime: 20091202183248Z pwdFailureTime: 20091202190153Z pwdFailureTime: 20091202191147Z pwdFailureTime: 20091202191544Z pwdFailureTime: 20091202191644Z pwdFailureTime: 20091202192051Z modifyTimestamp: 20091202192133Z I tried to identify any problems that may be in the logs. I made the following: /etc/init.d/slapd stop Stopping OpenLDAP: slapd. > /var/log/debug /etc/init.d/slapd start Starting OpenLDAP: slapd. tail /var/log/debug -n 50 Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi807249521$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=douglas.dcosta,ou=Pessoas,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149827$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813149622$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808649957$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=apssc-fcn333$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808638963$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=mgapssba055$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808644351$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148464$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi813148430$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=fnsi808643444$,ou=Windows,ou=Hosts,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.udsl,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access to "uid=admin.listas,ou=Servicos,ou=Usuarios,dc=previdencia,dc=gov,dc=br" "objectClass" requested Dec 2 18:01:59 squeeze slapd[21772]: <= root access granted Dec 2 18:01:59 squeeze slapd[21772]: => access_allowed: search access granted by manage(=mwrscxd) Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "cn=default,ou=ldappassword,ou=politicas,ou=builtin,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: => bdb_entry_get: found entry: "uid=jarbas.peixoto,ou=pessoas,ou=usuarios,dc=previdencia,dc=gov,dc=br" Dec 2 18:01:59 squeeze slapd[21772]: <= acl_access_allowed: granted to database root Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 op=0 RESULT tag=97 err=49 text= Dec 2 18:01:59 squeeze slapd[21772]: conn=1000 fd=15 closed (connection lost) grep 'access_allowed: search access to' /var/log/debug | wc -l 83714 The question is: why access all entries in LDAP? Does anyone have any tips, or it may be some as yet unidentified BUG? As tests, I installed the version 2.4.20 and had the same behavior. Best Regards, Jarbas

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 02 Dec '09

02 Dec '09

I have updated to 2.4.20 and this problem gone. So this ITS could be closed.

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I applied the diff from http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c.diff?r1=1.… to 2.4.20, rebuilt and retested, it works now. Thanks! - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksWY94ACgkQeEJZs/PdwpCkoACg4xdTEzYb1QuQhjUfjtLHxSBK 74IAoMnwcVdaHsIhaiwwm8fnbx0DDgx8 =jss8 -----END PGP SIGNATURE-----

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I also just uploaded a new attachment to the launchpad bug entry with the contents of the slapd.d/ directory. - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVMTMACgkQeEJZs/PdwpAN5wCgru6E73Ex1kKdrSpwxCq6zbR9 vzcAmwczNIFgUK5w+8cz2gniT9g1NG8X =IZTr -----END PGP SIGNATURE-----

1 0

(ITS#6409) ldap_init_fd and LDAPS
by viatly.kroivets＠gmail.com 02 Dec '09

02 Dec '09

Full_Name: Vitaly Kroivets Version: 2.4.20 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) It seems that function ldap_init_fd can not be used in LDAPS connection . I tried LDAP over SSL (without start-tls), but maybe with start-tls will be same.. I copied here my program. Use it this way : a.out -H ldaps://{IP}:636 -i {your src IP} -D {user} -w {password} Thanks! ====== #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <ldap.h> char* url = NULL; char* host_uri = NULL; char* bind_dn = NULL; char* password = NULL; char* out_file = NULL; LDAP* server = NULL; LDAPURLDesc* ludp = NULL; char* attribute = NULL; char* dn = NULL; BerElement* ber = NULL; LDAPMessage* result; void OnExitHandler(); void PrintUsage(); char src_ip [64]; int main(int argc, char* argv[]) { atexit(OnExitHandler); char c; while ((c = getopt(argc, argv, "H:w:D:o:i:")) != EOF) { switch (c) { case 'H': { url = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(url, optarg); break; } case 'D': { bind_dn = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(bind_dn, optarg); break; } case 'w': { password = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(password, optarg); break; } case 'o': { out_file = (char*)calloc(strlen(optarg), sizeof(char)); strcpy(out_file, optarg); break; } case 'i': { strncpy(src_ip, optarg, sizeof (src_ip)); break; } default: { PrintUsage(); return 1; break; } } } if (url == NULL || (bind_dn == NULL && password != NULL)) { PrintUsage(); return 1; } int rc = ldap_url_parse(url, &ludp); if (rc != 0) { fprintf(stderr, "ldap_url_parse: %s\n", ldap_err2string(rc)); return 1; } // server = ldap_init(ludp->lud_host, ludp->lud_port); // ldap_initialize is undocumented call we use instead of ldap_init // it allows to work over TLS secured connection, i.e. using ldaps:// int host_uri_len = strlen(ludp->lud_scheme) + strlen(ludp->lud_host) + 16; host_uri = (char*)malloc(sizeof(char) * host_uri_len); sprintf(host_uri, "%s://%s:%d", ludp->lud_scheme, ludp->lud_host, ludp-> lud_port); int sockfd ; printf ("%s;\n",ludp->lud_host); { // struct hostent *gethostbyname(const char *name); struct hostent *he; struct sockaddr_in their_addr; // connector's address information if ( (he=gethostbyname( ludp->lud_host )) == NULL ) { // get the host info herror("gethostbyname"); exit(1); } if ((sockfd = socket(PF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } their_addr.sin_family = AF_INET; their_addr.sin_port = htons(ludp-> lud_port); their_addr.sin_addr = *((struct in_addr *)he->h_addr); memset(their_addr.sin_zero, '\0', sizeof their_addr.sin_zero); // { struct sockaddr_in my_addr; // my address information my_addr.sin_family = AF_INET; // host byte order my_addr.sin_port = 0; // short, network byte order my_addr.sin_addr.s_addr = inet_addr(src_ip); memset(my_addr.sin_zero, '\0', sizeof my_addr.sin_zero); if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof my_addr) == -1) { perror("bind"); exit(1); } } // if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof their_addr) == -1) { perror("connect"); exit(1); } //connect mysock... printf ("init=%d\n", ldap_init_fd (sockfd , 1 ,host_uri , &server)); } /* // rc = ldap_initialize(&server, host_uri); if (rc != 0) { fprintf(stderr, "ldap_initialize: %s", (*ldap_err2string)(rc)); return 1; } */ //server->ld_conns->lconn_server = 0;//ldap_url_dup ( ludp ); rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); if (rc != 0 && rc != LDAP_SIZELIMIT_EXCEEDED) { fprintf(stderr, "ldap_search_s: %s\n", (*ldap_err2string)(rc)); return 1; } int num = ldap_count_entries(server, result); fprintf(stderr, "Number of messages: %d\n", ldap_count_messages(server, result)); if (num == 0) { fprintf(stderr, "ldap_count_entries: no entries received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_entries: more than one entry received\n"); return 1; } LDAPMessage* entryIterator = ldap_first_entry(server, result); dn = ldap_get_dn(server, entryIterator); attribute = ldap_first_attribute(server, entryIterator, &ber); if (attribute == NULL) { fprintf(stderr, "ldap_first_attribute: no attriubutes received\n"); return 1; } else if (ldap_next_attribute(server, entryIterator, ber)) { fprintf(stderr, "ldap_first_attribute: more than one attriubute received\n"); return 1; } else { BerValue** vals = ldap_get_values_len(server, entryIterator, attribute); num = ldap_count_values_len(vals); if (vals == NULL || num == 0) { fprintf(stderr, "ldap_count_values_len :no values received\n"); return 1; } else if (num > 1) { fprintf(stderr, "ldap_count_values_len :more than one value received\n"); return 1; } FILE* fo = NULL; if (out_file) { fo = fopen(out_file, "wb"); } else { fo = stdout; } fwrite(vals[0]->bv_val, 1, vals[0]->bv_len, fo); fflush(fo); fprintf(stderr, "Responce received from '%s'\n", url); if (out_file) fprintf(stderr, "Stored into %s\n", out_file); /* Free memory used to store values */ ldap_value_free_len(vals); } return 0; } void OnExitHandler() { if (result) { ldap_msgfree(result); } if (dn) ldap_memfree(dn); if (attribute) ldap_memfree(attribute); if (ber) ber_free(ber, 0); if (ludp) ldap_free_urldesc(ludp); if (server) ldap_unbind_s(server); if (url) free(url); if (host_uri) free(host_uri); if (bind_dn) free(bind_dn); if (password) free(password); if (out_file) free(out_file); } void PrintUsage() { fprintf(stderr, "Usage: ldapget -H <LDAP URI> [-o <output_file>] [-D user [-w password]] [-i src_ip_addr ] \n"); }

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Michael Ströder wrote: > Howard Chu wrote: >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> Howard Chu wrote: >>>>> michael(a)stroeder.com wrote: >>>>>> Download content of testrun/ here: >>>>>> >>>>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >>>>> >>>>> Shows that a change was replicated to the consumer and ignored on the >>>>> consumer. But since there's no SYNC logging enabled, we don't see the >>>>> reason why the consumer did this... >>>> >>>> It does not happen very often. This time I had to run it almost 50 >>>> times. >>>> >>>> Hope I got the sync log level right herein: >>>> >>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… >>>> >>> >>> I think you have an OS / clock problem. The skipped op in this case got >>> assigned an entryCSN older than the immediately preceding op. (The >>> missing op >>> has CSN 20091130201002.575384Z. The preceding op was >>> 20091130201002.577244Z) >>> This test doesn't run any concurrent operations, each new op is only >>> submitted >>> after the previous one completes, so this is not a thread concurrency >>> issue, >>> your system clock is going backwards. >>> >> A patch for this is now in libldap/util-int.c in HEAD. > > Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't > suspect to have a clock issue therein since the host is a rather fast > dual-core notebook. I will investigate this. The one thing you can rely on as far as clocks in VMware is that they will be wrong, regardless of your CPU speed. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Download content of testrun/ here: >>>> >>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >>> >>> Shows that a change was replicated to the consumer and ignored on the >>> consumer. But since there's no SYNC logging enabled, we don't see the >>> reason why the consumer did this... >> >> It does not happen very often. This time I had to run it almost 50 times. >> >> Hope I got the sync log level right herein: >> >> http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… > > I think you have an OS / clock problem. The skipped op in this case got > assigned an entryCSN older than the immediately preceding op. (The missing op > has CSN 20091130201002.575384Z. The preceding op was 20091130201002.577244Z) > This test doesn't run any concurrent operations, each new op is only submitted > after the previous one completes, so this is not a thread concurrency issue, > your system clock is going backwards. > A patch for this is now in libldap/util-int.c in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Howard Chu wrote: > Michael Ströder wrote: >> Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't >> suspect to have a clock issue therein since the host is a rather fast >> dual-core notebook. I will investigate this. > > The one thing you can rely on as far as clocks in VMware is that they will be > wrong, regardless of your CPU speed. > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… > Read more... http://www.google.com/search?q=site%3Avmware.com+clock The "Timekeeping" PDF doc is a pretty good explanation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6408) 2.4.20 slapd hangs at 99% cpu when adding data
by andreas＠canonical.com 02 Dec '09

02 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately ftp.openldap.org/incoming is full: lftp ftp.openldap.org:/incoming> put AndreasHasenack-091201.tar.bz2 put: Access failed: 553 AndreasHasenack-091201.tar.bz2.30: No space left on device. The same files can be fetched from https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/485026 instead. - -- Andreas Hasenack andreas(a)canonical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVH2cACgkQeEJZs/PdwpCw3QCgvnfE2Ynmzb7wFWvsuH81HmjV XpUAoLzmgy/qBkz4h68J1KJUIv4egNUY =wwV9 -----END PGP SIGNATURE-----

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 02 Dec '09

02 Dec '09

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Download content of testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >> >> Shows that a change was replicated to the consumer and ignored on the >> consumer. But since there's no SYNC logging enabled, we don't see the >> reason why the consumer did this... > > It does not happen very often. This time I had to run it almost 50 times. > > Hope I got the sync log level right herein: > > http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… I think you have an OS / clock problem. The skipped op in this case got assigned an entryCSN older than the immediately preceding op. (The missing op has CSN 20091130201002.575384Z. The preceding op was 20091130201002.577244Z) This test doesn't run any concurrent operations, each new op is only submitted after the previous one completes, so this is not a thread concurrency issue, your system clock is going backwards. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael＠stroeder.com 02 Dec '09

02 Dec '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Download content of testrun/ here: >> >> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz > > Shows that a change was replicated to the consumer and ignored on the > consumer. But since there's no SYNC logging enabled, we don't see the > reason why the consumer did this... It does not happen very often. This time I had to run it almost 50 times. Hope I got the sync log level right herein: http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… Ciao, Michael.

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael＠stroeder.com 01 Dec '09

01 Dec '09

Howard Chu wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> michael(a)stroeder.com wrote: >>>>> Download content of testrun/ here: >>>>> >>>>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz >>>> >>>> Shows that a change was replicated to the consumer and ignored on the >>>> consumer. But since there's no SYNC logging enabled, we don't see the >>>> reason why the consumer did this... >>> >>> It does not happen very often. This time I had to run it almost 50 >>> times. >>> >>> Hope I got the sync log level right herein: >>> >>> http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.… >>> >> >> I think you have an OS / clock problem. The skipped op in this case got >> assigned an entryCSN older than the immediately preceding op. (The >> missing op >> has CSN 20091130201002.575384Z. The preceding op was >> 20091130201002.577244Z) >> This test doesn't run any concurrent operations, each new op is only >> submitted >> after the previous one completes, so this is not a thread concurrency >> issue, >> your system clock is going backwards. >> > A patch for this is now in libldap/util-int.c in HEAD. Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't suspect to have a clock issue therein since the host is a rather fast dual-core notebook. I will investigate this. Ciao, Michael.

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by hyc＠symas.com 01 Dec '09

01 Dec '09

michael(a)stroeder.com wrote: > Download content of testrun/ here: > > http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz Shows that a change was replicated to the consumer and ignored on the consumer. But since there's no SYNC logging enabled, we don't see the reason why the consumer did this... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6405) test043-delta-syncrepl failed - producer and consumer databases differ
by michael＠stroeder.com 30 Nov '09

30 Nov '09

Failure is reproducible on SLES 10 32-Bit with BDB 4.8 but it seems to work on openSUSE 11.2 x86_64 with BDB 4.5 installed from RPMs.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs