April 2008 - openldap-bugs

(ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

Full_Name: Tuan Huynh Version: 2.3.39 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.39.129.66) My password is 10 characters long, however system allowed me to login as long as I enter first 8 characters and it ignored the rest even if I enter garbage. For example: my password is !thisIsATest! when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk I used ppolicy and pwdMinLength is set at 8

1 0

Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > When syncrepl and syncprov are both used on a glue database, the > contextCSN received from the syncrepl producers are not passed on to the > syncprov consumers when changes in subordinate databases are received. > The reason is that syncrepl queues the CSNs in the glue backend, while > syncprov fetches them from the backend where the changes are made. As a > consequence, the consumers will be passed a cookie without any csn > value. > > My first attempt at fixing this was to change syncprov to fetch the > queued csn values from the glue backend where it was used. But that > failed as other modules queues the csn values in their own backend when > they changes things. What other modules? Generally there cannot be any other sources of changes. > Instead I changed ctxcsn.c so that it always > queues them in the glue backend where syncprov is used. But I don't > feel that my understanding of this stuff is good enough to be sure that > this is the optimal solution.. I definitely don't like references to the syncprov overlay appearing in main slapd code like that. We need a different solution. At one point in the past, I had changed syncrepl.c to queue the CSNs in both places, but that seemed rather sloppy. Still, it may work best here. > Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE > test, should that have included an overlay_is_inst() clause as well? Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on that call. > Rein Tollevik > Basefarm AS > > Index: OpenLDAP/servers/slapd/ctxcsn.c > diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 > OpenLDAP/servers/slapd/ctxcsn.c:1.2 > --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 > +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 > @@ -37,67 +37,78 @@ > ) > { > struct slap_csn_entry *csne, *committed_csne = NULL; > + Backend *be = op->o_bd; > > if ( maxcsn ) { > BER_BVZERO( maxcsn ); > } > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_COMMIT; > break; > } > } > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; > if ( csne->ce_state == SLAP_CSN_PENDING ) break; > } > > if ( committed_csne&& maxcsn ) *maxcsn = committed_csne->ce_csn; > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_rewind_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be = op->o_bd; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_PENDING; > break; > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_graduate_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be; > > if ( op == NULL ) return; > if ( op->o_bd == NULL ) return; > > + be = op->o_bd; > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + > #if 0 > /* it is NULL when we get here from the frontendDB; > * alternate fix: initialize frontendDB like all other backends */ > - assert( op->o_bd->be_pcl_mutexp != NULL ); > + assert( be->be_pcl_mutexp != NULL ); > #endif > > - if ( op->o_bd->be_pcl_mutexp == NULL ) return; > + if ( be->be_pcl_mutexp == NULL ) return; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, > csne, ce_csn_link ); > Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", > csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); > @@ -110,7 +121,7 @@ > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > > return; > } > @@ -161,22 +172,25 @@ > struct berval *csn ) > { > struct slap_csn_entry *pending; > + Backend *be = op->o_bd; > > pending = (struct slap_csn_entry *) ch_calloc( 1, > sizeof( struct slap_csn_entry )); > > Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, > csn->bv_val, 0 ); > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > ber_dupbv(&pending->ce_csn, csn ); > ber_bvreplace_x(&op->o_csn,&pending->ce_csn, op->o_tmpmemctx ); > pending->ce_connid = op->o_connid; > pending->ce_opid = op->o_opid; > pending->ce_state = SLAP_CSN_PENDING; > - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, > pending, ce_csn_link ); > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > int > > > -- -- 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#5491) slapd crashes with ldappasswd
by Deepak.Cheema＠emerson.com 30 Apr '08

30 Apr '08

Full_Name: Deepak Cheema Version: 2.4.8 OS: Red Hat Linux 3.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.189.5.201) Just built, installed openldap 2.4.8 and slapd starts up fine using the following slapd -f slapd.conf -u root as root user on default port 389 [root@dl2k245 libexec]# ps -ef|grep slapd root 15065 1 0 15:31 ? 00:00:00 ./slapd -f /dbapps/informatica/l dap/etc/openldap/slapd.conf -u root The process stays up as long as I don't type the ldappasswd command to get the encrypted password a new user... once I type in ldappasswd... this is what happens.. [root@dl2k245 bin]# ldappasswd SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Can't contact LDAP server additional info: SASL(0): successful result: security flags do not match required [root@dl2k245 bin]# ps -ef|grep lapd root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd and the slapd process is no longer there... Any ideas why it might be happening or how to debug this? I tried dbg but it did not tell me much.. maybe I did not use it correctly... Any help is appreciated !

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > syncprov_findbase() must search the backend saved with the syncrepl operation, > not the one from the operation passed as argument. The backend in the op > argument can be a subordinate database, in which case the search for the base in > the superior database will fail, and syncrepl consumers will be force to do a an > unneccessary full refresh of the database. OK. > The patch at the end should fix > this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the > overlay_op_walk() call, which is the reason for the long pointer traversal to > find the correct bd_info to save and restore. But the overlay_op_walk call is only appropriate when the DB to be searched is the current database, and the current DB is an overlay DB structure. Your patch causes fc->fss->s_op->o_bd's bd_info pointer to change, which is not allowed. That's in the original backendDB, which must be treated as read-only since multiple threads may be accessing it. The correct approach here is to use a new local backendDB variable, copy the s_op->o_bd into it, and then just do a regular be_search invocation instead of using overlay_op_walk. But, this patch must not take effect on the first call to syncprov_findbase (which occurred in syncprov_op_search) - in that case, the current code is correct. So, you need to tweak things based on whether (s_flags & PS_IS_REFRESHING) is true or not - if true, this is the first search, and it should use the original code. Else, it must use be_search. > Rein Tollevik > Basefarm AS > > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 > 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 > @@ -404,7 +404,7 @@ > slap_callback cb = {0}; > Operation fop; > SlapReply frs = { REP_RESULT }; > - BackendInfo *bi; > + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; > int rc; > > fc->fss->s_flags ^= PS_FIND_BASE; > @@ -413,10 +413,8 @@ > fop = *fc->fss->s_op; > > fop.o_hdr = op->o_hdr; > - fop.o_bd = op->o_bd; > fop.o_time = op->o_time; > fop.o_tincr = op->o_tincr; > - bi = op->o_bd->bd_info; > > cb.sc_response = findbase_cb; > cb.sc_private = fc; > @@ -435,7 +433,7 @@ > fop.ors_filterstr = generic_filterstr; > > rc = overlay_op_walk(&fop,&frs, op_search, on->on_info, on ); > - op->o_bd->bd_info = bi; > + fc->fss->s_op->o_bd->bd_info = bi; > } else { > ldap_pvt_thread_mutex_unlock(&fc->fss->s_mutex ); > fc->fbase = 1; > > > -- -- 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#5489) Assert failed in slapd_clr_write()
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in > slapd_clr_write() failed, see the stack trace at the end. The > last log message (at loglevel stat) related to the socket was > "fd=657 closed (connection lost on write)". The comment where > slapd_daemon_task() calls connection_write() makes me believe > that slapd_clr_write() should not have use assert here. Remove > it or include it as a condition in the following if statement? How frequently can you reproduce this? I'm tempted to say move the assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still triggers. > > Rein Tollevik > Basefarm AS > > > Program terminated with signal 6, Aborted. > (gdb) where > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 > #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 > #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 > #5 0x080726d7 in connection_write (s=657) at connection.c:1814 > #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 > #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 > #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6 > > > -- -- 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#5490) accesslog_response segfault
by quanah＠zimbra.com 30 Apr '08

30 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Repeated coredumps from slapd, in the accesslog_response function. Core #1: Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://zimbra-adm.'. Program terminated with signal 11, Segmentation fault. (gdb) thr apply all bt Thread 10 (process 7511): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 12519): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 12520): #0 0x000000376980af8b in ?? () #1 0x0000000040fff920 in ?? () #2 0x0000000040fff6e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe611c0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c900, rs=0x41000ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c900, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c900, rs=0x41000ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c900, rs=0x41000ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0xd97c900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x38) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 12521): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c600, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c600, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c600, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c600, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xd97c600) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 12524): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7768c00, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7768c00, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7768c00, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7768c00, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x7768c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x3f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 12525): #0 0x000000000045569b in slap_acl_mask (a=0x8b4000, mask=0x430040d8, op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, nmatch=100, matches=0x43003da0, count=1, state=0x0) at acl.c:1496 #1 0x00000000004538ca in access_allowed_mask (op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, access=ACL_READ, state=0x0, maskp=0x0) at acl.c:698 #2 0x000000000043fa48 in slap_send_search_entry (op=0x43004ab0, rs=0x43004780) at result.c:737 #3 0x0000002a979a0647 in syncprov_sendresp (op=0x43004ab0, opc=0x43004850, so=0x791ff30, e=0x430048b8, mode=1) at syncprov.c:784 #4 0x0000002a979a09a2 in syncprov_qplay (op=0x43004ab0, on=0xddec40, so=0x791ff30) at syncprov.c:853 #5 0x0000002a979a0be6 in syncprov_qtask (ctx=0x43004e10, arg=0x2178f00) at syncprov.c:898 #6 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #7 0x0000003769806137 in ?? () #8 0x0000000000000000 in ?? () Thread 4 (process 14050): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x22e2d90) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x23d0900, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x23d0900, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x23d0900, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x23d0900, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0x23d0900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x3c) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 14051): #0 0x000000376980bf1c in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 14052): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x214e6c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7657c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7657c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7657c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7657c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7657c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x36) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 12522): #0 0x0000002a97aac75a in accesslog_response (op=0xd97c000, rs=0x42002ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0xd97c000, rs=0x42002ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0xd97c000, rs=0x42002ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0xd97c000, rs=0x42002ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0xd97c000, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0xd97c000, rs=0x42002ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0xd97c000, rs=0x42002ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0xd97c000) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x23) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () Core #2: Thread 10 (process 11473): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 15458): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 15460): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcadbc00, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcadbc00, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcadbc00, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcadbc00, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xcadbc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x32) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 15461): #0 0x000000376980af8b in ?? () #1 0x0000000042001920 in ?? () #2 0x00000000420016e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64380) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2300, rs=0x42002ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2300, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2300, rs=0x42002ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2300, rs=0x42002ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0x34d2300) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x2b) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 15463): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2900, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2900, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2900, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2900, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x34d2900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 15724): #0 0x000000376980af8b in ?? () #1 0x0000000043003920 in ?? () #2 0x00000000430036e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616dc8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75900, rs=0x43004ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75900, rs=0x43004ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75900, rs=0x43004ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75900, rs=0x43004ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43004e10, arg_v=0xcb75900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43004e10, argv=0x31) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 4 (process 15725): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616fc0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75c00, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75c00, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75c00, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75c00, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0xcb75c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x2f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 16249): #0 0x000000376980af8b in ?? () #1 0x0000000044005920 in ?? () #2 0x00000000440056e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xcb1ff50) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcbccc00, rs=0x44006ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcbccc00, rs=0x44006ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcbccc00, rs=0x44006ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcbccc00, rs=0x44006ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44006e10, arg_v=0xcbccc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44006e10, argv=0x24) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 2 (process 16251): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xdcd06c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7661c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7661c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7661c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7661c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7661c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x35) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 15459): #0 0x0000002a97aac75a in accesslog_response (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0x34d2c00, rs=0x41000ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0x34d2c00, rs=0x41000ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0x34d2c00, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0x34d2c00, rs=0x41000ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0x34d2c00, rs=0x41000ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0x34d2c00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x2e) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () 2 more cores that looks similar if desired.

1 0

(ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in slapd_clr_write() failed, see the stack trace at the end. The last log message (at loglevel stat) related to the socket was "fd=657 closed (connection lost on write)". The comment where slapd_daemon_task() calls connection_write() makes me believe that slapd_clr_write() should not have use assert here. Remove it or include it as a condition in the following if statement? Rein Tollevik Basefarm AS Program terminated with signal 6, Aborted. (gdb) where #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 #5 0x080726d7 in connection_write (s=657) at connection.c:1814 #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6

1 0

(ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncrepl and syncprov are both used on a glue database, the contextCSN received from the syncrepl producers are not passed on to the syncprov consumers when changes in subordinate databases are received. The reason is that syncrepl queues the CSNs in the glue backend, while syncprov fetches them from the backend where the changes are made. As a consequence, the consumers will be passed a cookie without any csn value. My first attempt at fixing this was to change syncprov to fetch the queued csn values from the glue backend where it was used. But that failed as other modules queues the csn values in their own backend when they changes things. Instead I changed ctxcsn.c so that it always queues them in the glue backend where syncprov is used. But I don't feel that my understanding of this stuff is good enough to be sure that this is the optimal solution.. Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE test, should that have included an overlay_is_inst() clause as well? Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/ctxcsn.c diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 OpenLDAP/servers/slapd/ctxcsn.c:1.2 --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 @@ -37,67 +37,78 @@ ) { struct slap_csn_entry *csne, *committed_csne = NULL; + Backend *be = op->o_bd; if ( maxcsn ) { BER_BVZERO( maxcsn ); } - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_COMMIT; break; } } - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; if ( csne->ce_state == SLAP_CSN_PENDING ) break; } if ( committed_csne && maxcsn ) *maxcsn = committed_csne->ce_csn; - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_rewind_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be = op->o_bd; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_PENDING; break; } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_graduate_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be; if ( op == NULL ) return; if ( op->o_bd == NULL ) return; + be = op->o_bd; + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + #if 0 /* it is NULL when we get here from the frontendDB; * alternate fix: initialize frontendDB like all other backends */ - assert( op->o_bd->be_pcl_mutexp != NULL ); + assert( be->be_pcl_mutexp != NULL ); #endif - if ( op->o_bd->be_pcl_mutexp == NULL ) return; + if ( be->be_pcl_mutexp == NULL ) return; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, csne, ce_csn_link ); Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); @@ -110,7 +121,7 @@ } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); return; } @@ -161,22 +172,25 @@ struct berval *csn ) { struct slap_csn_entry *pending; + Backend *be = op->o_bd; pending = (struct slap_csn_entry *) ch_calloc( 1, sizeof( struct slap_csn_entry )); Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, csn->bv_val, 0 ); - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); ber_dupbv( &pending->ce_csn, csn ); ber_bvreplace_x( &op->o_csn, &pending->ce_csn, op->o_tmpmemctx ); pending->ce_connid = op->o_connid; pending->ce_opid = op->o_opid; pending->ce_state = SLAP_CSN_PENDING; - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, pending, ce_csn_link ); - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } int

1 0

(ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein syncprov_findbase() must search the backend saved with the syncrepl operation, not the one from the operation passed as argument. The backend in the op argument can be a subordinate database, in which case the search for the base in the superior database will fail, and syncrepl consumers will be force to do a an unneccessary full refresh of the database. The patch at the end should fix this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the overlay_op_walk() call, which is the reason for the long pointer traversal to find the correct bd_info to save and restore. Rein Tollevik Basefarm AS diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 @@ -404,7 +404,7 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -413,10 +413,8 @@ fop = *fc->fss->s_op; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -435,7 +433,7 @@ fop.ors_filterstr = generic_filterstr; rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + fc->fss->s_op->o_bd->bd_info = bi; } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

This is a multi-part message in MIME format. --------------080809000906010300090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > Thanks. Please try HEAD again. No way. new testrun directory in ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz backtrace attached --------------080809000906010300090306 Content-Type: text/plain; name="bt.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="bt.txt" Program terminated with signal 11, Segmentation fault. #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 588 undef = f->f_choice & SLAPD_FILTER_UNDEFINED; (gdb) thr apply all bt full Thread 5 (process 11932): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x0072f605 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011e907 in ldap_pvt_thread_join (thread=18434960, thread_return=0x0) at thr_posix.c:197 No locals. #3 0x080766b2 in slapd_daemon () at daemon.c:2644 listener_tid = 18434960 rc = 0 #4 0x0805badc in main (argc=8, argv=0xbfce4da4) at main.c:946 i = -1 no_detach = 1 rc = -12 urls = 0x9210018 "ldap://localhost:9012/" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 8 g_argv = (char **) 0xbfce4da4 configfile = 0x0 configdir = 0x9210008 "./slapd.d" serverName = 0xbfce5306 "lt-slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x812e057 "" l = 1347374360 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main" Thread 4 (process 11947): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x00670346 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #2 0x08075aa1 in slapd_daemon_task (ptr=0x0) at daemon.c:2281 ns = 1 at = 0 nfds = 7 revents = (struct epoll_event *) 0x9213d78 tvp = (struct timeval *) 0x11942fc cat = {tv_sec = 1209559064, tv_usec = 0} i = 0 nwriters = 0 now = 1209559054 tv = {tv_sec = 10, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x92895b0 l = 2 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #3 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 3 (process 12114): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 22633360, ltu_key = {{ltk_key = 0x8079056, ltk_data = 0x926ab48, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x80dc7a5, ltk_data = 0x9268408, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a890, ltk_free = 0x80910e8 <slap_op_q_destroy>}, { ltk_key = 0x9294ac0, ltk_data = 0xb7b821d4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6196008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 165 hash = 5272741 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 2 (process 12129): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 60083088, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9266bf8, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x8079056, ltk_data = 0x927ba30, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a558, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b823b4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6997008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 306 hash = 5400882 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (process 12939): #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 i = 153708648 p = (Filter *) 0xb tmp = {bv_len = 0, bv_val = 0x9296868 "\b\220\231�\b\220\231�\b\220��\001"} value = {bv_len = 153577944, bv_val = 0x0} len = 44136616 choice = 134851750 undef = 153577944 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #1 0x0807ef20 in filter2bv_x (op=0x2a17dac, f=0x92dd360, fstr=0x2a17df0) at filter.c:742 i = 40 p = (Filter *) 0x32383833 tmp = {bv_len = 9, bv_val = 0x92769d8 "�]-\t"} value = {bv_len = 153998176, bv_val = 0x0} len = 94946797 choice = 160 undef = 0 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #2 0x080e97eb in syncrepl_del_nonpresent (op=0x2a17dac, si=0x9294348, uuids=0x0, sc=0x2a17c08, m=0) at syncrepl.c:2444 f = (Filter *) 0x92dd36c i = 1 cf = (Filter *) 0x92dd360 of = (Filter *) 0x92994e8 be = (Backend *) 0x92891f8 cb = {sc_next = 0x0, sc_response = 0x80eb85b <nonpresent_callback>, sc_cleanup = 0, sc_private = 0x9294348} rs_search = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} np_list = (struct nonpresent_entry *) 0x92994e8 np_prev = (struct nonpresent_entry *) 0x0 rc = 44137248 an = {{an_name = {bv_len = 9, bv_val = 0x922ed58 "entryUUID"}, an_desc = 0x922edf8, an_oc_exclude = 0, an_oc = 0x0}, {an_name = {bv_len = 0, bv_val = 0x0}, an_desc = 0x0, an_oc_exclude = 0, an_oc = 0x0}} pdn = {bv_len = 0, bv_val = 0x0} csn = {bv_len = 4294967295, bv_val = 0x15a4b8 "P\223\004"} #3 0x080e4a27 in do_syncrep2 (op=0x2a17dac, si=0x9294348) at syncrepl.c:952 rctrls = (LDAPControl **) 0x92994e8 rctrlp = (LDAPControl *) 0x92ddf18 berbuf = { buffer = "\002\000\001\000\005\001", '\0' <repeats 14 times>, "X4'\t\2304'\t\2304'\t", '\0' <repeats 32 times>, "�|�\002\000\000\000\000\000\000\000\000�|�\002\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\021\000\000\000�h)\t\021\000\000\000\210�%\t�|�\002", '\0' <repeats 16 times>, "��\"\t8\226(\tpb)\t\001", '\0' <repeats 15 times>, "\n\000\000\0008�\"\t��\"\t\000\000\000\000��\025\000\000\000\000\000\000\000\000\000\000|�\002\000\000\000\000\001\000\000\000�D)\t\001\000\000\000��\025\000x}�\002\024\021\024\000\210\220(\t\001\000\000\000�}�\002\b9\016\b\001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 5.5384093382201037e-312, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x2a17c44 msg = (LDAPMessage *) 0x92d6718 retoid = 0x9297730 "all alumni assoc staff" retdata = (struct berval *) 0x92734f8 entry = (Entry *) 0x92cbf2c syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0x92d5dff "\t\020"} syncCookie = {ctxcsn = 0x92ddf30, octet_str = {bv_len = 60, bv_val = 0x92dcf08 "rid=004,sid=002,csn=20080430123714.430853Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9277d68, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x92734e0, octet_str = {bv_len = 60, bv_val = 0x92966e0 "rid=004,sid=002,csn=20080430123714.247229Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9297bd8, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 60, bv_val = 0x927345c "ames a jones 2,ou=alumni association,ou=people,dc=example,dc=com"} rc = 101 err = 0 len = 0 psub = (struct berval *) 0x9289190 modlist = (Modifications *) 0x92748b0 match = -1 m = 0 tout_p = (struct timeval *) 0x0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x9272478 si_tag = 163 #4 0x080e5c1f in do_syncrepl (ctx=0x2a1820c, arg=0x92895b0) at syncrepl.c:1276 rtask = (struct re_s *) 0x92895b0 si = (syncinfo_t *) 0x9294348 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_peer_name = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_listener = 0x8134fa0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x808d3c3 <slap_send_ldap_result>, c_send_search_entry = 0x808e0c3 <slap_send_search_entry>, c_send_search_reference = 0x808fe46 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x2a17e84, o_tag = 99, o_time = 1209559044, o_tincr = 18, o_bd = 0x92891f8, o_req_dn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_req_ndn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 44136992, bv_val = 0x92dd360 "�"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x2a17a20 "\t"}, rs_newSup = 0x92dd360, rs_nnewSup = 0x5a8c5ed}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x2a17a20, rs_filter = 0x92dd360, rs_filterstr = {bv_len = 94946797, bv_val = 0xafb97008 "(&(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unknown)(?=unknown)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unkn"...}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = { bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 44136992, bv_val = 0x92dd360 "�"}, rs_mods = 0x5a8c5ed, rs_modtail = 0xafb97008}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 16 times>, "\002", '\0' <repeats 14 times>, o_controls = 0x2a17fb0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 28, bv_val = 0x9289570 "cn=Manager,dc=example,dc=com"}, sai_ndn = {bv_len = 28, bv_val = 0x92891c8 "cn=manager,dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x2a17afc, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x2a18030, oh_msgid = 0, oh_protocol = 3, oh_tid = 44141456, oh_threadctx = 0x2a1820c, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x817c834, oh_counters = 0x81c2900, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x0 <repeats 32 times>}} op = (Operation *) 0x2a17dac rc = 0 dostop = 0 do_setup = 0 s = 18 i = 44138952 defer = 1 fail = 0 be = (Backend *) 0x92891f8 #5 0x0011d72e in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x9266868 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 44141456, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9296868, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b822c4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb7198008, ltk_free = 0xbf9b08}, {ltk_key = 0x8079056, ltk_data = 0x9288c68, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x9273cc0, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 606 hash = 5329502 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #6 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #7 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) --------------080809000906010300090306--

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

Here it is again. HEAD code checked out this morning. I'm able to reproduce the crash fairly often. testrun directory uploaded at ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430.tgz the core file is in testrun/con

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 29 Apr '08

29 Apr '08

Howard Chu wrote: >> Looking at the log snippet above, I can see in the "syncprov_sendresp" >> lines >> that the cookie appears to be empty. This does appear to be similar to >> ITS#5432, > > I don't see that in the snippet above. Seems unrelated. Okay. I was just querying whether it was related to the fact that the cookie= field appeared blank similar to the ITS#5432. > "info threads" would probably be a useful start. And "bt full". No problem. I've created a file containing the same snippet from the log file and the extra information requested above, and uploaded it to http://pastebin.siriusit.co.uk/openldap-its5486-detail.txt to help preserve formatting. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by hyc＠symas.com 28 Apr '08

28 Apr '08

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.8cvs-RE24-2008-04-15 > OS: RHEL4, x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.207.197.142) > > > Hi there, > > In order to resolve issues experienced with syncrepl/glue on an existing > openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of > openldap RE24 branch taken from 2008-04-15 on one of our test systems. > > Unfortunately, we are still seeing random segfaults occurring roughly once a day > which appear to point towards the syncprov overlay once again. At the moment, we > are having difficulty reproducing the fault under test conditions, but if > openldap is left running long enough then it is possible to obtain a core dump. > > The issue is occurring with a server, pelican, which is configured using the > syncprov overlay to a number of subordinates for different parts of the tree. > The relevant log snippet follows: > > Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: > cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing > 0xa12ee70 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Looking at the log snippet above, I can see in the "syncprov_sendresp" lines > that the cookie appears to be empty. This does appear to be similar to ITS#5432, I don't see that in the snippet above. Seems unrelated. > although this claims to have been fixed by a commit on the 21st March (and hence > the fix would be included within our CVS checkout). Further information can be > provided on request. "info threads" would probably be a useful start. And "bt full". -- -- 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#5470) Sporadic failures with RE24
by hyc＠symas.com 28 Apr '08

28 Apr '08

ando(a)sys-net.it wrote: > raphael.ouazana(a)linagora.com wrote: >> Hi, >> >> Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >>> I updated RE24 this morning with a couple of fixes from Howard. >>> >>> See if you can still repo, thanks. >> It still seems to fail, after more than 100 runs: > > It appears from your logs that the entry > > "cn=ITD Staff,ou=Groups,dc=example,dc=com" > > is being added first, and then removed from server 3, probably related > to some issue in sync replication. Seems like the consumer has received a cookie from one provider, while receiving a newer entry from the other provider. During the nonpresent search the new entry is found and removed. So we need to restrict the filter in the nonpresent search to only return entries older than the cookie context. -- -- 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#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 28 Apr '08

28 Apr '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-04-15 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, In order to resolve issues experienced with syncrepl/glue on an existing openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of openldap RE24 branch taken from 2008-04-15 on one of our test systems. Unfortunately, we are still seeing random segfaults occurring roughly once a day which appear to point towards the syncprov overlay once again. At the moment, we are having difficulty reproducing the fault under test conditions, but if openldap is left running long enough then it is possible to obtain a core dump. The issue is occurring with a server, pelican, which is configured using the syncprov overlay to a number of subordinates for different parts of the tree. The relevant log snippet follows: Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing 0xa12ee70 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 The backtrace obtained from the core file looks like this: Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/openldap/syncprov-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/openldap/syncprov-2.4.so.2.0.4.debug...done. done. Loaded symbols for /usr/lib/openldap/syncprov-2.4.so.2 #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 355 rc = on->on_bi.bi_entry_get_rw( op, dn, (gdb) bt #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 #1 0x00b187ac in syncprov_qtask (ctx=0x7e3ef2a0, arg=0xa02f708) at ../../../../servers/slapd/overlays/syncprov.c:871 #2 0x0817a277 in ldap_int_thread_pool_wrapper (xpool=0x9db94d0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00acb371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x00944ffe in clone () from /lib/tls/libc.so.6 (gdb) The server pelican is configured using both the syncprov & glue overlays, while the subordinate for ou=V,ou=W,ou=X,dc=Y,dc=Z is a simple syncrepl declaration of type refreshAndPersist. Looking at the log snippet above, I can see in the "syncprov_sendresp" lines that the cookie appears to be empty. This does appear to be similar to ITS#5432, although this claims to have been fixed by a commit on the 21st March (and hence the fix would be included within our CVS checkout). Further information can be provided on request. Many thanks, Mark.

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)tollevik.no wrote: > On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > >> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). >> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. >> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if >> and only if rs.sr_entry->e_private != NULL. Which is possibly true with >> back-bdb but seems a shaky assumption in general.) > > Almost, except that it triggers an abort.. Using be_entry_release_r() was > not correct, as it ended up calling entry_free(). It works if I changes > it to use overlay_entry_release_ov() instead, as in the alternative patch > at the end. > > I have put a test script that shows this deadlock on: > > ftp://ftp.openldap.org/incoming/test053-syncprov-glue > > It deadlocks without this patch, it and the rest of the test suite succeed > with it :-) I haven't tested it in production though.. This last patch is now committed to HEAD. I am ignoring the first patch; it is unsafe because it unlocks the si_csn_rwlock too soon. (si_ctxcsn is being used directly in the modify request and must be held consistent until that completes.) -- -- 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#5484) Remove runqueue task when freeing syncops bugfix
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: > Submission from: (NULL) (81.93.160.250) > > > We have seen occasional seg. faults in syncprov_qtask() where it was > passed a syncops pointer containing garbage in its arg. It looks as > this could happen if syncprov_free_syncop is called to free an abandoned > operation. I hope the patch at the should fix this, it makes sure to > remove the syncops->s_qtask (if any) from the runqueue before freeing > the syncops itself. I think this could also cause ITS#5452. -- -- 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#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > > While I was here, I added myself to the aknowledgements in the man page. > Applied to HEAD (with minor changes); please test. A quick test suggests it works as intended. Any chance to have it in an upcoming 2.4 release? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

Emmanuel Dreyfus wrote: > Sorry. The new patch was uploaded in FTP: > manu-20080426.patch > > While I was here, I added myself to the aknowledgements in the man page. Applied to HEAD (with minor changes); please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > I'm considering your patch for inclusion in HEAD code; I see that in > your patch you didn't follow the IPR notice as indicated in the > contributing guidelines. Please resubmit the patch adding at the top > the notices illustrated in > <http://www.openldap.org/devel/contributing.html#notice>: > > - notice of origin > - rights statement Sorry. The new patch was uploaded in FTP: manu-20080426.patch While I was here, I added myself to the aknowledgements in the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5470) Sporadic failures with RE24
by ando＠sys-net.it 26 Apr '08

26 Apr '08

raphael.ouazana(a)linagora.com wrote: > Hi, > > Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >> I updated RE24 this morning with a couple of fixes from Howard. >> >> See if you can still repo, thanks. > > It still seems to fail, after more than 100 runs: It appears from your logs that the entry "cn=ITD Staff,ou=Groups,dc=example,dc=com" is being added first, and then removed from server 3, probably related to some issue in sync replication. Can you enable "sync" log when running the tests? SLAPD_DEBUG="sync,stats,args,trace" ./run test050 p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

manu(a)netbsd.org wrote: > URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch > This patch adds attribute remapping capability to slapo-dynlist. Emmanuel, I'm considering your patch for inclusion in HEAD code; I see that in your patch you didn't follow the IPR notice as indicated in the contributing guidelines. Please resubmit the patch adding at the top the notices illustrated in <http://www.openldap.org/devel/contributing.html#notice>: - notice of origin - rights statement p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5485) Header files contain insufficient/outdated entries that prevent usage with Kerberos
by hyc＠symas.com 24 Apr '08

24 Apr '08

The ITS is for tracking issues in OpenLDAP software. Nothing in this report indicates any bug in OpenLDAP software. Most likely you've found a bug in MIT Kerberos. I suggest you contact the MIT folks. This ITS will be closed. brian.peters(a)analog.com wrote: > Full_Name: Brian Peters > Version: 2.3.39 > OS: SPARC Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.71.23.54) > > > I am attempting to compile Samba using active directory. This entails using LDAP > and Kerberos during set up. The native versions on Solaris 10 are insufficient > due to a lack of ldap_initialize in those header files. I am using the most > recent versions of both Openldap (2.3.39) and Kerberos (krb5-1.6.3). The error > manifests itself when compiling Kerberos. Before we proceed any further let's > first lay down the foundation of the data. > > Openldap was configured using the following: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openlda > p-2.3.39 --without-bdb --disable-bdb --enable-null --disable-slapd > --enable-shar > ed --with-shared=yes > > CFLAGS -D_AVL_H > > Kerberos using: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/kerberos/krb5-1.6.3 > --with-ldap --enable-shared > > > All important environment variables have been set specifically for each > configuration (CPPFLAGS,LDFLAGS,PATH,LD_LIBRARY_PATH,CFLAGS). > > I have confirmed in the config.log files that each is pulling the correct files > during the attempted compile. The issue appears when running gmake. Below is the > important portion it returns. > > ... > In file included from kdb_ldap.c:37: > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.c:491: warning: missing braces around initializer > kdb_ldap.c:491: warning: (near initialization for > `kldap_init_fn__once.once.o.__pthread_once_pad') > kdb_ldap.c:500: warning: no previous prototype for 'kldap_ensure_initialized' > gmake[2]: *** [kdb_ldap.so] Error 1 > gmake[2]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap/libkdb_ldap' > gmake[1]: *** [all-recurse] Error 1 > gmake[1]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap' > gmake: *** [all-recurse] Error 1 > > > At this point I am at a bit of a loss on how to proceed. Any advice on a fix or > versions of each to roll back to would be greatly appreciated. > > > -- -- 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#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 24 Apr '08

24 Apr '08

Hi, Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : > I updated RE24 this morning with a couple of fixes from Howard. > > See if you can still repo, thanks. It still seems to fail, after more than 100 runs: Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Using ldapsearch to read config from consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved configs from producer and consumer... Comparing retrieved configs from producer and consumer2... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Using ldapsearch to read all the entries from the consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved entries from producer and consumer... Comparing retrieved entries from producer and consumer2... test failed - producer and consumer2 databases differ I sent the testrun directory through FTP: ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-20080424.tgz Regards, Raphaël Ouazana.

1 0

(ITS#5485) Header files contain insufficient/outdated entries that prevent usage with Kerberos
by brian.peters＠analog.com 24 Apr '08

24 Apr '08

Full_Name: Brian Peters Version: 2.3.39 OS: SPARC Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.71.23.54) I am attempting to compile Samba using active directory. This entails using LDAP and Kerberos during set up. The native versions on Solaris 10 are insufficient due to a lack of ldap_initialize in those header files. I am using the most recent versions of both Openldap (2.3.39) and Kerberos (krb5-1.6.3). The error manifests itself when compiling Kerberos. Before we proceed any further let's first lay down the foundation of the data. Openldap was configured using the following: ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openlda p-2.3.39 --without-bdb --disable-bdb --enable-null --disable-slapd --enable-shar ed --with-shared=yes CFLAGS -D_AVL_H Kerberos using: ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/kerberos/krb5-1.6.3 --with-ldap --enable-shared All important environment variables have been set specifically for each configuration (CPPFLAGS,LDFLAGS,PATH,LD_LIBRARY_PATH,CFLAGS). I have confirmed in the config.log files that each is pulling the correct files during the attempted compile. The issue appears when running gmake. Below is the important portion it returns. ... In file included from kdb_ldap.c:37: kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: error: previous declaration of 'ldap_initialize' was here kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: error: previous declaration of 'ldap_initialize' was here kdb_ldap.c:491: warning: missing braces around initializer kdb_ldap.c:491: warning: (near initialization for `kldap_init_fn__once.once.o.__pthread_once_pad') kdb_ldap.c:500: warning: no previous prototype for 'kldap_ensure_initialized' gmake[2]: *** [kdb_ldap.so] Error 1 gmake[2]: Leaving directory `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap/libkdb_ldap' gmake[1]: *** [all-recurse] Error 1 gmake[1]: Leaving directory `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap' gmake: *** [all-recurse] Error 1 At this point I am at a bit of a loss on how to proceed. Any advice on a fix or versions of each to roll back to would be greatly appreciated.

1 0

Re: (ITS#5484) Remove runqueue task when freeing syncops bugfix
by hyc＠symas.com 22 Apr '08

22 Apr '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: > Submission from: (NULL) (81.93.160.250) > > > We have seen occasional seg. faults in syncprov_qtask() where it was > passed a syncops pointer containing garbage in its arg. It looks as > this could happen if syncprov_free_syncop is called to free an abandoned > operation. I hope the patch at the should fix this, it makes sure to > remove the syncops->s_qtask (if any) from the runqueue before freeing > the syncops itself. Seems OK. I wonder if it's worthwhile to check for the s_op->o_abandon flag first. If your tests are ok with this patch, go ahead and commit it, then login to the ITS and update the status. > Rein Tollevik > Basefarm AS > > Index: OpenLDAP/servers/slapd/overlays/syncprov.c > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.17 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 Fri Apr 18 10:56:41 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Apr 22 16:38:27 2008 > @@ -738,6 +738,13 @@ > ldap_pvt_thread_mutex_unlock(&so->s_mutex ); > return; > } > + if ( so->s_qtask ) { > + ldap_pvt_thread_mutex_lock(&slapd_rq.rq_mutex ); > + if ( ldap_pvt_runqueue_isrunning(&slapd_rq, so->s_qtask ) ) > + ldap_pvt_runqueue_stoptask(&slapd_rq, so->s_qtask ); > + ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); > + ldap_pvt_thread_mutex_unlock(&slapd_rq.rq_mutex ); > + } > ldap_pvt_thread_mutex_unlock(&so->s_mutex ); > if ( so->s_flags& PS_IS_DETACHED ) { > filter_free( so->s_op->ors_filter ); -- -- 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#5483) "syncprov_qplay: failed to get [dn] ..." Bad?
by hyc＠symas.com 22 Apr '08

22 Apr '08

marian.eichholz(a)freenet.ag wrote: > Full_Name: Marian Eichholz > Version: HEAD-20080411 > OS: linux 2.6.23.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > > Hello, probably this question is paranoia related, but: Are log entries of the > subject's form something important, that one should take care of? The end of that log message is "ignored" - which is what you should do. > Sorry, if this should be a pointless topic after all. This ITS will be closed. -- -- 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#5469) Assertion failure causes slapd crash
by jwm＠horde.net 22 Apr '08

22 Apr '08

On Mon, Apr 21, 2008 at 09:54:31AM -0700, Quanah Gibson-Mount wrote: > --On April 17, 2008 8:11:11 PM +0000 jwm(a)horde.net wrote: > >On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: > > > Howard Chu wrote: > > > Please try the patch in slapd/connection.c 1.416 and report your > > > results, thanks. > > > > I patched our local slapd yesterday; I'll let you know in a couple of > > weeks, once we can be certain that slapd is no longer crashing. > > I'm working on putting together OpenLDAP 2.3.42 release, so I was wondering > if you've seen any ill effects from this patch. After being up for about a day, our NOC reported that our patched slapd wasn't responding and restarted it. I'm not sure if it really *was* wedged or if they were just confused or trigger-happy, since they didn't do a whole lot of troubleshooting first. The backtrace shows that slapd got a SIGTERM, and that every thread was waiting except for one in epoll_wait(); I'm not sure if that's normal state for an idle slapd. Other than that questionable problem, it's been fine. john Program received signal SIGTERM, Terminated. [Switching to Thread -1212565280 (LWP 26178)] 0xb7ce9183 in pthread_join () from /lib/tls/libpthread.so.0 Thread 14 (Thread 2141186992 (LWP 5848)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9562048, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf5, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7dbfa008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x42, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2141186992 i = 697 keyslot = 697 hash = 697 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread 2145381296 (LWP 5847)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9a428f0, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf2, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7e3fb008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x43, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2145381296 i = 761 keyslot = 761 hash = 761 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -2144339024 (LWP 5846)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8f497f8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf1, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7ebfc008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x41, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2150628272 i = 602 keyslot = 602 hash = 602 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -2125464656 (LWP 5356)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0xcc7c050, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xed, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x808ff008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x40, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2169502640 i = 635 keyslot = 635 hash = 635 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1967129680 (LWP 26656)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9401ac8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x3d, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x8247af0, ltk_data = 0xbe, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x89efe008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2327837616 i = 756 keyslot = 756 hash = 756 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1936733264 (LWP 26210)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x844f890, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x83, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8b3fa008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x3c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2358234032 i = 662 keyslot = 662 hash = 662 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1931486288 (LWP 26209)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x846cae8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x3a, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8bcfc008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8247af0, ltk_data = 0x82, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2363481008 i = 758 keyslot = 758 hash = 758 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1917846608 (LWP 26208)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x82606a8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x7c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8cdfe008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x3b, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 keyslot = 743 hash = 743 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1884959824 (LWP 26205)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x825cf38, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x4a, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8e459008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x34, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2410007472 i = 687 keyslot = 687 hash = 687 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1879712848 (LWP 26204)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x825c578, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x51, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8dc58008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x38, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415254448 i = 783 keyslot = 783 hash = 783 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875518544 (LWP 26203)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8259f38, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x1c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8ee5c008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8247af0, ltk_data = 0x7d, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419448752 i = 592 keyslot = 592 hash = 592 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1538761808 (LWP 26202)): #0 0xb7c7d679 in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0806f7fa in slapd_daemon_task (ptr=0x0) at /var/jwm/o2/openldap/servers/slapd/daemon.c:2174 ns = 1 at = 0 nfds = 12 revents = (struct epoll_event *) 0xb7b37008 tvp = (struct timeval *) 0xa44853a4 cat = {tv_sec = 1208360230, tv_usec = 0} i = 0 nwriters = 0 now = 1208360042 tv = {tv_sec = 188, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x81bea68 l = 4 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #2 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #3 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212565280 (LWP 26178)): #0 0xb7ce9183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f58f9b in ldap_pvt_thread_join (thread=2756205488, thread_return=0x0) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08070524 in slapd_daemon () at /var/jwm/o2/openldap/servers/slapd/daemon.c:2579 listener_tid = 2756205488 rc = 0 #3 0x0805a58d in main (argc=9, argv=0xbff9b084) at /var/jwm/o2/openldap/servers/slapd/main.c:859 i = 9 no_detach = 0 rc = 0 urls = 0x8162008 "ldap:/// ldaps:///" username = 0x8162030 "gidNumber" groupname = 0x8162020 "\202.Í·°K\235·" sandbox = 0x0 syslogUser = 160 g_argc = 9 g_argv = (char **) 0xbff9b084 configfile = 0x8162040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = 0xbff9be9b "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x81112bb "" l = 3086212344 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5484) Remove runqueue task when freeing syncops bugfix
by rein＠basefarm.no 22 Apr '08

22 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: Submission from: (NULL) (81.93.160.250) We have seen occasional seg. faults in syncprov_qtask() where it was passed a syncops pointer containing garbage in its arg. It looks as this could happen if syncprov_free_syncop is called to free an abandoned operation. I hope the patch at the should fix this, it makes sure to remove the syncops->s_qtask (if any) from the runqueue before freeing the syncops itself. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 OpenLDAP/servers/slapd/overlays/syncprov.c:1.17 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 Fri Apr 18 10:56:41 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Apr 22 16:38:27 2008 @@ -738,6 +738,13 @@ ldap_pvt_thread_mutex_unlock( &so->s_mutex ); return; } + if ( so->s_qtask ) { + ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex ); + if ( ldap_pvt_runqueue_isrunning( &slapd_rq, so->s_qtask ) ) + ldap_pvt_runqueue_stoptask( &slapd_rq, so->s_qtask ); + ldap_pvt_runqueue_remove( &slapd_rq, so->s_qtask ); + ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); + } ldap_pvt_thread_mutex_unlock( &so->s_mutex ); if ( so->s_flags & PS_IS_DETACHED ) { filter_free( so->s_op->ors_filter );

1 0

(ITS#5483) "syncprov_qplay: failed to get [dn] ..." Bad?
by marian.eichholz＠freenet.ag 22 Apr '08

22 Apr '08

Full_Name: Marian Eichholz Version: HEAD-20080411 OS: linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Hello, probably this question is paranoia related, but: Are log entries of the subject's form something important, that one should take care of? Sorry, if this should be a pointless topic after all.

1 0

Re: (ITS#5477) Pasword Policy docs from Symas
by ghenry＠suretecsystems.com 21 Apr '08

21 Apr '08

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: > > This document represents original work of Symas Corp. Symas Corp has not > assigned rights and/or interest in this work to any party. > > The referenced document is subject to the following notice: > > Copyright 2008 Symas Corp. > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > >> http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 > Should it be Portions Copyright, as I've rewritten some of both of them? Only very minor changes. Or is this for the actual forum post?

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: > > Yes, but a Symas representative should have submitted the actual ITS, with > a > Rights Statement attached. So here it is: > > This document represents original work of Symas Corp. Symas Corp has not > assigned rights and/or interest in this work to any party. > > The referenced document is subject to the following notice: > > Copyright 2008 Symas Corp. > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > Should it be Portions Copyright, as I've rewritten some of both of them? Only very minor changes. Or is this for the actual forum post?

1 0

Re: (ITS#5482) AIX 5.2 Logging core_dump Errors
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On April 21, 2008 7:56:58 PM +0000 rightsidedwn(a)gmail.com wrote: > Full_Name: Steven Handy > Version: 2.3.27 > OS: AIX 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.237.119.62) > > > OpenLDAP had been running fine our AIX box then all of a sudden we are > starting to get core_dumps in the errpt and we have to restart openldap. > We turned on the logging for ldap and the errors we are getting are: > ch_malloc of 8388608 bytes failed > Assertion failed: __EX, file ch_malloc.c, line 57 ch_malloc means that you ran out of memory, in most cases. Re-tune your server appropriately. I also advise upgrading, since 2.3.27 is particularly old, and IIRC some memory-leak fixes were put into place since then. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5477) Pasword Policy docs from Symas
by hyc＠symas.com 21 Apr '08

21 Apr '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: This document represents original work of Symas Corp. Symas Corp has not assigned rights and/or interest in this work to any party. The referenced document is subject to the following notice: Copyright 2008 Symas Corp. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. > http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 -- -- 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#5476) delta-syncrepl docs from Symas
by hyc＠symas.com 21 Apr '08

21 Apr '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: Yes, but a Symas representative should have submitted the actual ITS, with a Rights Statement attached. So here it is: This document represents original work of Symas Corp. Symas Corp has not assigned rights and/or interest in this work to any party. The referenced document is subject to the following notice: Copyright 2008 Symas Corp. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 -- -- 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#5482) AIX 5.2 Logging core_dump Errors
by rightsidedwn＠gmail.com 21 Apr '08

21 Apr '08

Full_Name: Steven Handy Version: 2.3.27 OS: AIX 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.237.119.62) OpenLDAP had been running fine our AIX box then all of a sudden we are starting to get core_dumps in the errpt and we have to restart openldap. We turned on the logging for ldap and the errors we are getting are: ch_malloc of 8388608 bytes failed Assertion failed: __EX, file ch_malloc.c, line 57 The following is one of the errors from the errpt: LABEL: CORE_DUMP IDENTIFIER: B6048838 Date/Time: Mon Apr 14 16:07:15 EDT Sequence Number: 119609 Machine Id: 00C4F0EA4C00 Node Id: host Class: S Type: PERM Resource Name: SYSPROC Description SOFTWARE PROGRAM ABNORMALLY TERMINATED Probable Causes SOFTWARE PROGRAM User Causes USER GENERATED SIGNAL Recommended Actions CORRECT THEN RETRY Failure Causes SOFTWARE PROGRAM Recommended Actions RERUN THE APPLICATION PROGRAM IF PROBLEM PERSISTS THEN DO THE FOLLOWING CONTACT APPROPRIATE SERVICE REPRESENTATIVE Detail Data SIGNAL NUMBER 6 USER'S PROCESS ID: 40430 FILE SYSTEM SERIAL NUMBER 1 INODE NUMBER 2 PROCESSOR ID -1 CORE FILE NAME /core PROGRAM NAME slapd ADDITIONAL INFORMATION pthread_k 98 ?? Symptom Data REPORTABLE 1 INTERNAL ERROR 0 SYMPTOM CODE PCSS/SPI2 FLDS/slapd SIG/6 FLDS/pthread_k VALU/98 Is there a fix for this issue? Thanks.

1 0

Re: (ITS#5478) Can not compile ldap_t61s_to_utf8s function from LDAP library
by hyc＠symas.com 21 Apr '08

21 Apr '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.38 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > Using OpenLDAP LDAP library to perform conversions between X.500 directory data > and LDAP directory data, I need to convert values from T.61 to UTF-8. > I see that there is a t61.c file in LDAP library with a ldap_t61s_to_utf8s() > function to perform this. > The problem is that t61.c does not compile because it refers to > ldap_x_wc_to_utf8() and ldap_x_utf8_to_wc() which are defined in utf-8-conv.c > file only in case sizeof(wchar_t)>= 4, which is not the case with windows where > sizeof(wchar_t) = 2. Just patch utf-8-conv.c to allow those routines to be compiled. The T.61 variant supported in t61.c will never generate character codes greater than 0x2126 anyway, so it will always fit in a 2-byte character. Note that all of that T.61 support is heavily deprecated. t61.c is present in the source distribution mainly for historical reference; it has never been included in any distributed Makefiles or public builds. As such, you're on your own here. This ITS will be closed. -- -- 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#5470) Sporadic failures with RE24
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

I updated RE24 this morning with a couple of fixes from Howard. See if you can still repo, thanks. --Quanah --On April 21, 2008 5:31:48 PM +0000 phil(a)cogbill.net wrote: > scratch that.. it happened again. :\ fooie > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5470) Sporadic failures with RE24
by phil＠cogbill.net 21 Apr '08

21 Apr '08

scratch that.. it happened again. :\ fooie

1 0

Re: (ITS#5470) Sporadic failures with RE24
by threeiem＠gmail.com 21 Apr '08

21 Apr '08

I ran into this same problem and was able to fix it. I had been using the yum version of Berkeley DB 4.5 and updated to Oracle Berkeley 4.6 and then it worked fine. Just make sure that when you run configure that it includes the correct version of db.h

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On April 17, 2008 8:11:11 PM +0000 jwm(a)horde.net wrote: > On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: >> Howard Chu wrote: >> Please try the patch in slapd/connection.c 1.416 and report your >> results, thanks. > > I patched our local slapd yesterday; I'll let you know in a couple of > weeks, once we can be certain that slapd is no longer crashing. Hi John, I'm working on putting together OpenLDAP 2.3.42 release, so I was wondering if you've seen any ill effects from this patch. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ali.pouya＠free.fr 21 Apr '08

21 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > Please check after applying back-meta/search.c 1.205 => 1.206 > > Thanks, p. > I tested, it's OK. I had never received such a fast response from my editor ! Thanks a lot. Best Regards Ali

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠suretecsystems.com 21 Apr '08

21 Apr '08

<quote who="quanah(a)zimbra.com"> > --On Monday, April 21, 2008 2:16 PM +0000 ghenry(a)OpenLDAP.org wrote: > >> <quote who="Craig Squires"> >>> More docs. Great! I notice, however, that in the config for the replica >>> there is a difference between this and the directives used in the >>> tests: >>> >>> http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- >>> slave.conf?hideattic=1&sortbydate=0 >>> >>> There, the directive "overlay syncprov" is also included. Is the latter >>> necessary? >> >> It shouldn't be there for a consumer/replica, but test043 fails if it's >> not. >> >> Anyone explain why? > > I know that I require it on a glued DB to see the contextCSN. Nothing else uses slapd-deltasync-slave.conf and it's not glued either. It shouldn't, but I'll read the test more to see why it's needed ;-) Gavin.

1 0

Re: (ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ando＠sys-net.it 21 Apr '08

21 Apr '08

ali.pouya(a)free.fr wrote: > When searching SOME entries slapd core dumps with the following back trace : Please check after applying back-meta/search.c 1.205 => 1.206 Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On Monday, April 21, 2008 2:16 PM +0000 ghenry(a)OpenLDAP.org wrote: > <quote who="Craig Squires"> >> More docs. Great! I notice, however, that in the config for the replica >> there is a difference between this and the directives used in the tests: >> >> http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- >> slave.conf?hideattic=1&sortbydate=0 >> >> There, the directive "overlay syncprov" is also included. Is the latter >> necessary? > > It shouldn't be there for a consumer/replica, but test043 fails if it's > not. > > Anyone explain why? I know that I require it on a glued DB to see the contextCSN. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Craig Squires"> > More docs. Great! I notice, however, that in the config for the replica > there is a difference between this and the directives used in the tests: > > http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- > slave.conf?hideattic=1&sortbydate=0 > > There, the directive "overlay syncprov" is also included. Is the latter > necessary? It shouldn't be there for a consumer/replica, but test043 fails if it's not. Anyone explain why? Thanks.

1 0

(ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ali.pouya＠free.fr 21 Apr '08

21 Apr '08

Full_Name: Ali Pouya Version: 2.4.8+ OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) Hi, I'm trying to upgrade to back-meta 2.4.8+ I do my tests with the HEAD extracted on april 9. When searching SOME entries slapd core dumps with the following back trace : (gdb) bt #0 0x00dc17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x006d07a5 in raise () from /lib/tls/libc.so.6 #2 0x006d2209 in abort () from /lib/tls/libc.so.6 #3 0x006c9d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x080a1bad in modify_add_values (e=Variable "e" is not available. ) at mods.c:64 #5 0x080d9966 in meta_back_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:2049 #6 0x08061bbf in fe_op_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:368 #7 0x08061315 in do_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:217 #8 0x0805ff3a in connection_operation (ctx=0xa2b692a0, arg_v=0x905d4f8) at connection.c:1084 #9 0x0806060e in connection_read_thread (ctx=0xa2b692a0, argv=0xb) at connection.c:1211 #10 0x0814d149 in ldap_int_thread_pool_wrapper (xpool=0x8fb2cf0) at tpool.c:663 #11 0x00116371 in start_thread () from /lib/tls/libpthread.so.0 #12 0x00770ffe in clone () from /lib/tls/libc.so.6 (gdb) The target server is an OpenLdap 2.3.34 managed by another team (I cannot modify the entries). The end of the detailed slapd log file is reproduced below. It shows that the problem happens at the end of handling of the received data. Some more precisions : If I specify the attribute names (even all of them) ldapsearch is successfull ! The problem ONLY happens if I do not specify any attribute name. ldapsearch using directly the target server (or through back-meta 2.3.7) is also successfull. The end of the log : ber_dump: buf=0x905c5e0 ptr=0x905cb28 end=0x905cb66 len=62 0000: 00 04 04 02 39 39 30 1c 04 0a 69 64 48 72 61 63 ....990...idHrac 0010: 63 65 73 73 31 0e 04 0c 30 30 30 30 30 30 38 30 cess1...00000080 0020: 32 34 38 38 30 18 04 08 69 64 4d 69 6e 65 66 69 24880...idMinefi 0030: 31 0c 04 0a 31 30 30 30 32 38 33 34 39 37 1...1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb2e end=0x905cb66 len=56 0000: 30 1c 04 0a 69 64 48 72 61 63 63 65 73 73 31 0e 0...idHraccess1. 0010: 04 0c 30 30 30 30 30 30 38 30 32 34 38 38 30 18 ..0000008024880. 0020: 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 31 30 ..idMinefi1...10 0030: 30 30 32 38 33 34 39 37 00283497 ber_scanf fmt ([W]) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb3c end=0x905cb66 len=42 0000: 00 0e 04 0c 30 30 30 30 30 30 38 30 32 34 38 38 ....000000802488 0010: 30 18 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 0...idMinefi1... 0020: 31 30 30 30 32 38 33 34 39 37 1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb4c end=0x905cb66 len=26 0000: 30 18 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 0...idMinefi1... 0010: 31 30 30 30 32 38 33 34 39 37 1000283497 ber_scanf fmt ([W]) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb58 end=0x905cb66 len=14 0000: 00 0c 04 0a 31 30 30 30 32 38 33 34 39 37 ....1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb66 end=0x905cb66 len=0 slapd: mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed. Abandon (core dumped)

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Quanah Gibson-Mount"> > --On Monday, April 21, 2008 7:34 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: >> >> http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 >> >> This is a ticket to track commits for the delta-sycnrepl sections. > > I give my permission too, since I wrote a chunk of it. > Thanks.

1 0

(ITS#5480) Two object deletions missed in sync replication after daemons restarted
by marian.eichholz＠freenet.ag 21 Apr '08

21 Apr '08

Full_Name: Marian Eichholz Version: HEAD-20080411 OS: linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Like in ITS#5371 we again missed two object deletions, approx. 4 minutes after provider and consumer were restarted (after stopped for a slapcat). This is too bad, because the cvs source from 20080411 at least is far more robust in terms of connection management than the release of openldap-2.4.8 (see ITS#5463) We now had full debug log on (any), and as far as I can see there is no obvious rejections or any other reason, why this deletions were not replicated to the two consumers. There were heading and trailing deletions in the same second, and I cannot see structural anomalies in the residual objects. The consumer databases were cloned from the provider after the incident that lead to ITS#5371. When we checked the consistency on Friday morning, the databases were identical, measured by the set of "dn:"-records in the dump. Of course we first stopped the provider, then the consumers. When we (re-) start the LDAP services, we first start the provider, then the consumers. Any idea how we can debug the problem or can get a realiable release? When needed and useful, I can provide a (heavily edited, for privacy reasons) excerpt from the debug log of the given second. Thank You in advance! - Marian Eichholz

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On Monday, April 21, 2008 7:34 AM +0000 ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: > > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 > > This is a ticket to track commits for the delta-sycnrepl sections. I give my permission too, since I wrote a chunk of it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by csquires＠mun.ca 21 Apr '08

21 Apr '08

More docs. Great! I notice, however, that in the config for the replica there is a difference between this and the directives used in the tests: http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- slave.conf?hideattic=1&sortbydate=0 There, the directive "overlay syncprov" is also included. Is the latter necessary? Cheers, Craig On Mon, 2008-04-21 at 07:34 +0000, ghenry(a)openldap.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: > > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 > > This is a ticket to track commits for the delta-sycnrepl sections. > >

1 0

(ITS#5479) Pasword Policy docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Marty and Matthew from Symas have given permission to use how we see fit: http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 This is a ticket to track commits for the Password Policy Overlay section.

1 0

(ITS#5478) Can not compile ldap_t61s_to_utf8s function from LDAP library
by emmanuel.duru＠atosorigin.com 21 Apr '08

21 Apr '08

Full_Name: Emmanuel Duru Version: 2.3.38 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) Using OpenLDAP LDAP library to perform conversions between X.500 directory data and LDAP directory data, I need to convert values from T.61 to UTF-8. I see that there is a t61.c file in LDAP library with a ldap_t61s_to_utf8s() function to perform this. The problem is that t61.c does not compile because it refers to ldap_x_wc_to_utf8() and ldap_x_utf8_to_wc() which are defined in utf-8-conv.c file only in case sizeof(wchar_t) >= 4, which is not the case with windows where sizeof(wchar_t) = 2.

1 0

(ITS#5477) Pasword Policy docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Marty and Matthew from Symas have given permission to use how we see fit: http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 This is a ticket to track commits for the Password Policy Overlay section.

1 0

(ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Marty and Matthew from Symas have given permission to use how we see fit: http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 This is a ticket to track commits for the delta-sycnrepl sections.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by pere＠hungry.com 20 Apr '08

20 Apr '08

Just a quick reply for future reference if others ask about the same and find this request. [Kurt Zeilenga] > No. Attribute description options cannot contain equal signs. See > RFC 4512. Thank you for your reply. It was very valuable for me that is not as well lectured in the LDAP specification. It is now obvious to me that the extention used by Active Directory LDAP is outside the RFC-documented LDAP specification. I've been told that AD range feature is documented in an expired draft RFC, available from <URL: http://www.tkk.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt >. I'm not sure what was discussed about this draft, but it expired a long time ago. Anyway, the draft can be used to understand how the feature is working. It claim that it is possible to see in supportedControls if this range feature is used by the server. This could be used to enable this feature at runtime, if one wanted to implement the non-conforming feature. I suspect I have to go in that direction, as the project requirements are to use LDAP from AD. :/ > If you want to implement this crap, you can do so without additional > support from LDAP API. Use ldap_first/next_attribute API. Good idea. I have since found out that this ranged multivalue feature is implemented in nss-ldap, and hope it is possible to reuse some code there in nss-ldapd. Happy hacking, -- Petter Reinholdtsen

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by h.b.furuseth＠usit.uio.no 20 Apr '08

20 Apr '08

ando(a)sys-net.it writes: > Although I don't see any particular issue in implementing this > enhancement, ldap* tools are essentially intended to implement the basic > LDAP features at the operation level. True, ldapdelete -r is a bit of an aberration in that regard. > You can easily obtain what you're asking for by using > > ldapsearch <search options> | grep ^dn: | ldapdelete <delete options> No. Must also join continuation lines first, check for non-success result from search, and sort the DNs so children precede parents. Excellent example of how quickly LDAP shell scripting become more cumbersome than using a proper LDAP API:-) Come to think of it, an ldapdelete option to reverse-sort the DNs by number of RDNs would be useful. This would satisfy child-before-parent. -- Hallvard

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by serenityzhu＠gmail.com 20 Apr '08

20 Apr '08

------=_Part_10709_1485377.1208682014107 Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBQaWVyYW5nZWxvLAoKVGhhbmsgeW91LiBJIGFncmVlIHdpdGggeW91IHRoYXQgaXQgaXMg bm90IGNyaXRpY2FsLCB3ZSBjYW4gdXNlIGxkYXBzZWFyY2gncwpmaWx0ZXIgdG8gYWN0IGFzIGxk YXBkZWxldGUncyBmaWx0ZXIuCgpBZnRlciB5b3VyIGV4cGxhbmF0aW9uLCBpdCBtaWdodCBub3Qg YmUgYSBnb29kIGlkZWEgdG8gaW1wbGVtZW50IHRoZSBmaWx0ZXIKaW4gbGRhcGRlbGV0ZSwgYmVj YXVzZSBpZiBzbywgdGhlIGZpbHRlciBmdW5jdGlvbmFsaXR5IGlzIGR1cGxpY2F0ZSwgaW4gYm90 aApsZGFwc2VhcmNoIGFuZCBsZGFwZGVsZXRlLiBXZSBoYXZlIHRvIG1haW50YWluIHR3byBjb3Bp ZXMgb2YgdGhlIGZpbHRlcgpjb2RlLgoKRnVydGhlciBkaXNjdXNzaW9uIGlzIHdlbGNvbWUhCgpC ZXN0IHJlZ2FyZHMsCkphY2t5CgpPbiBTdW4sIEFwciAyMCwgMjAwOCBhdCAzOjQ2IFBNLCBQaWVy YW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cndyb3RlOgoKPgo+ID4gSSBmaW5kIHRo YXQgbGRhcGRlbGV0ZSBjYW4gb25seSBkZWxldGUgYSBETiBvciBhIHN1YnRyZWUgb25lIHRpbWUu IElmIEkKPiA+IHdhbnQgdG8KPiA+IGRlbGV0ZSBhbGwgZW50cmllcyBmdWxmaWxsaW5nIGEgY2Vy dGFpbiBmaWx0ZXIuIEkgaGF2ZSB0byBnZXQgdGhlIEROcwo+ID4gZmlyc3QsIHB1dAo+ID4gdGhl bSBpbiBhIGZpbGUsIGFuZCB0aGVuIHVzZSBsZGFwZGVsZXRlIHRvIGRlbGV0ZSB0aGVtLgo+ID4K PiA+IENhbiB3ZSB1c2UgYSBmaWx0ZXIgaW4gbGRhcGRlbGV0ZSwganVzdCBhcyB0aGUgZmlsdGVy IGluIGxkYXBzZWFyY2g/Cj4KPiBBbHRob3VnaCBJIGRvbid0IHNlZSBhbnkgcGFydGljdWxhciBp c3N1ZSBpbiBpbXBsZW1lbnRpbmcgdGhpcwo+IGVuaGFuY2VtZW50LCBsZGFwKiB0b29scyBhcmUg ZXNzZW50aWFsbHkgaW50ZW5kZWQgdG8gaW1wbGVtZW50IHRoZSBiYXNpYwo+IExEQVAgZmVhdHVy ZXMgYXQgdGhlIG9wZXJhdGlvbiBsZXZlbC4gIFlvdSBjYW4gZWFzaWx5IG9idGFpbiB3aGF0IHlv dSdyZQo+IGFza2luZyBmb3IgYnkgdXNpbmcKPgo+IGxkYXBzZWFyY2ggPHNlYXJjaCBvcHRpb25z PiB8IGdyZXAgXmRuOiB8IGxkYXBkZWxldGUgPGRlbGV0ZSBvcHRpb25zPgo+Cj4gKHdoaWNoIGlz IHZlcnkgVU5JWC1zdHlsZSwgQlRXKS4KPgo+IEluIGFueSBjYXNlIHlvdSdkIG5lZWQgdG8gYWRk IGZ1cnRoZXIgbG9naWNzIHRvIGhhbmRsZSBhbnkgZGVsZXRlIGZhaWx1cmUsCj4gd2hpY2gsIGFj Y29yZGluZyB0byBMREFQIG1vZGVsLCBjYW5ub3QgYmUgdHJhbnNhY3Rpb25hbC4gIFNvIGFueQo+ IGNvbnRyaWJ1dGlvbiBpbiB0aGUgc2Vuc2Ugb2YgeW91ciBzdWdnZXN0aW9uIHdvdWxkIHByb2Jh Ymx5IGJlIHdlbGNvbWVkLAo+IGJ1dCBJIGhhcmRseSBzZWUgaXQgY3JpdGljYWwuCj4KPiBwLgo+ Cj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4g U3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAtIDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0 cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCj4gT2ZmaWNlOiAgKzM5IDAyIDIzOTk4MzA5Cj4gTW9iaWxlOiAgKzM5IDMzMyA0OTYzMTcy Cj4gRW1haWw6ICAgcGllcmFuZ2Vsby5tYXNhcmF0aUBzeXMtbmV0Lml0Cj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+CgoKLS0gClJvbWFucyAzOjIzIEZvciBh bGwgaGF2ZSBkb25lIHdyb25nIGFuZCBhcmUgZmFyIGZyb20gdGhlIGdsb3J5IG9mIEdvZDsKw7mw qK7RIDM6MjMgpl2ssKVApEizo6XHpEa4b6FBwauvyqRGr6uqurphxKOhQwpKb2huIDM6MTYgRm9y IEdvZCBzbyBsb3ZlZCB0aGUgd29ybGQsIHRoYXQgSGUgZ2F2ZSBIaXMgb25seSBiZWdvdHRlbiBT b24sCnRoYXQgd2hvZXZlciBiZWxpZXZlcyBpbiBIaW0gc2hhbGwgbm90IHBlcmlzaCwgYnV0IGhh dmUgZXRlcm5hbCBsaWZlLgqs+b+rutattTM6MTYgr6u3UqVApEihQqzGptyxTqVMqrq/V6XNpGy9 57W5pUytzKFCpXOkQKTBq0ilTKq6oUKko6bct8CkYKFCpM+xb6XDpc2hQwpodHRwOi8vd3d3Lmhr Y2NjLm9yZy9mbGFzaDIuaHRtCg== ------=_Part_10709_1485377.1208682014107 Content-Type: text/html; charset=BIG5 Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBQaWVyYW5nZWxvLDxicj48YnI+VGhhbmsgeW91LiBJIGFncmVlIHdpdGggeW91IHRoYXQg aXQgaXMgbm90IGNyaXRpY2FsLCB3ZSBjYW4gdXNlIGxkYXBzZWFyY2gmIzM5O3MgZmlsdGVyIHRv IGFjdCBhcyBsZGFwZGVsZXRlJiMzOTtzIGZpbHRlci4gPGJyPjxicj5BZnRlciB5b3VyIGV4cGxh bmF0aW9uLCBpdCBtaWdodCBub3QgYmUgYSBnb29kIGlkZWEgdG8gaW1wbGVtZW50IHRoZSBmaWx0 ZXIgaW4gbGRhcGRlbGV0ZSwgYmVjYXVzZSBpZiBzbywgdGhlIGZpbHRlciBmdW5jdGlvbmFsaXR5 IGlzIGR1cGxpY2F0ZSwgaW4gYm90aCBsZGFwc2VhcmNoIGFuZCBsZGFwZGVsZXRlLiBXZSBoYXZl IHRvIG1haW50YWluIHR3byBjb3BpZXMgb2YgdGhlIGZpbHRlciBjb2RlLiA8YnI+Cjxicj5GdXJ0 aGVyIGRpc2N1c3Npb24gaXMgd2VsY29tZSE8YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+SmFja3k8 YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTdW4sIEFwciAyMCwgMjAwOCBhdCAz OjQ2IFBNLCBQaWVyYW5nZWxvIE1hc2FyYXRpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt bmV0Lml0Ij5hbmRvQHN5cy1uZXQuaXQ8L2E+Jmd0OyB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwg MjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsi Pjxicj4KJmd0OyBJIGZpbmQgdGhhdCBsZGFwZGVsZXRlIGNhbiBvbmx5IGRlbGV0ZSBhIEROIG9y IGEgc3VidHJlZSBvbmUgdGltZS4gSWYgSTxicj4KJmd0OyB3YW50IHRvPGJyPgomZ3Q7IGRlbGV0 ZSBhbGwgZW50cmllcyBmdWxmaWxsaW5nIGEgY2VydGFpbiBmaWx0ZXIuIEkgaGF2ZSB0byBnZXQg dGhlIEROczxicj4KJmd0OyBmaXJzdCwgcHV0PGJyPgomZ3Q7IHRoZW0gaW4gYSBmaWxlLCBhbmQg dGhlbiB1c2UgbGRhcGRlbGV0ZSB0byBkZWxldGUgdGhlbS48YnI+CiZndDs8YnI+CiZndDsgQ2Fu IHdlIHVzZSBhIGZpbHRlciBpbiBsZGFwZGVsZXRlLCBqdXN0IGFzIHRoZSBmaWx0ZXIgaW4gbGRh cHNlYXJjaD88YnI+Cjxicj4KQWx0aG91Z2ggSSBkb24mIzM5O3Qgc2VlIGFueSBwYXJ0aWN1bGFy IGlzc3VlIGluIGltcGxlbWVudGluZyB0aGlzPGJyPgplbmhhbmNlbWVudCwgbGRhcCogdG9vbHMg YXJlIGVzc2VudGlhbGx5IGludGVuZGVkIHRvIGltcGxlbWVudCB0aGUgYmFzaWM8YnI+CkxEQVAg ZmVhdHVyZXMgYXQgdGhlIG9wZXJhdGlvbiBsZXZlbC4gJm5ic3A7WW91IGNhbiBlYXNpbHkgb2J0 YWluIHdoYXQgeW91JiMzOTtyZTxicj4KYXNraW5nIGZvciBieSB1c2luZzxicj4KPGJyPgpsZGFw c2VhcmNoICZsdDtzZWFyY2ggb3B0aW9ucyZndDsgfCBncmVwIF5kbjogfCBsZGFwZGVsZXRlICZs dDtkZWxldGUgb3B0aW9ucyZndDs8YnI+Cjxicj4KKHdoaWNoIGlzIHZlcnkgVU5JWC1zdHlsZSwg QlRXKS48YnI+Cjxicj4KSW4gYW55IGNhc2UgeW91JiMzOTtkIG5lZWQgdG8gYWRkIGZ1cnRoZXIg bG9naWNzIHRvIGhhbmRsZSBhbnkgZGVsZXRlIGZhaWx1cmUsPGJyPgp3aGljaCwgYWNjb3JkaW5n IHRvIExEQVAgbW9kZWwsIGNhbm5vdCBiZSB0cmFuc2FjdGlvbmFsLiAmbmJzcDtTbyBhbnk8YnI+ CmNvbnRyaWJ1dGlvbiBpbiB0aGUgc2Vuc2Ugb2YgeW91ciBzdWdnZXN0aW9uIHdvdWxkIHByb2Jh Ymx5IGJlIHdlbGNvbWVkLDxicj4KYnV0IEkgaGFyZGx5IHNlZSBpdCBjcml0aWNhbC48YnI+Cjxi cj4KcC48YnI+Cjxicj4KPGJyPgo8YnI+CkluZy4gUGllcmFuZ2VsbyBNYXNhcmF0aTxicj4KT3Bl bkxEQVAgQ29yZSBUZWFtPGJyPgo8YnI+ClN5c05ldCBzLnIubC48YnI+CnZpYSBEb3NzaSwgOCAt IDI3MTAwIFBhdmlhIC0gSVRBTElBPGJyPgo8YSBocmVmPSJodHRwOi8vd3d3LnN5cy1uZXQuaXQi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnN5cy1uZXQuaXQ8L2E+PGJyPgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5ic3A7KzM5IDAyIDIz OTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4KRW1haWw6ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86cGllcmFuZ2Vsby5tYXNhcmF0aUBzeXMtbmV0Lml0Ij5waWVyYW5n ZWxvLm1hc2FyYXRpQHN5cy1uZXQuaXQ8L2E+PGJyPgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+Cjxicj4KPGJyPgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBj bGVhcj0iYWxsIj48YnI+LS0gPGJyPlJvbWFucyAzOjIzIEZvciBhbGwgaGF2ZSBkb25lIHdyb25n IGFuZCBhcmUgZmFyIGZyb20gdGhlIGdsb3J5IG9mIEdvZDs8YnI+w7mwqK7RIDM6MjMgpl2ssKVA pEizo6XHpEa4b6FBwauvyqRGr6uqurphxKOhQzxicj5Kb2huIDM6MTYgRm9yIEdvZCBzbyBsb3Zl ZCB0aGUgd29ybGQsIHRoYXQgSGUgZ2F2ZSBIaXMgb25seSBiZWdvdHRlbiBTb24sIHRoYXQgd2hv ZXZlciBiZWxpZXZlcyBpbiBIaW0gc2hhbGwgbm90IHBlcmlzaCwgYnV0IGhhdmUgZXRlcm5hbCBs aWZlLjxicj4KrPm/q7rWrbUzOjE2IK+rt1KlQKRIoUKsxqbcsU6lTKq6v1elzaRsvee1uaVMrcyh QqVzpECkwatIpUyquqFCpKOm3LfApGChQqTPsW+lw6XNoUM8YnI+PGEgaHJlZj0iaHR0cDovL3d3 dy5oa2NjYy5vcmcvZmxhc2gyLmh0bSI+aHR0cDovL3d3dy5oa2NjYy5vcmcvZmxhc2gyLmh0bTwv YT4K ------=_Part_10709_1485377.1208682014107--

1 0

Re: (ITS#5475) Enhance ldapdelete to delete with a filter
by ando＠sys-net.it 20 Apr '08

20 Apr '08

> I find that ldapdelete can only delete a DN or a subtree one time. If I > want to > delete all entries fulfilling a certain filter. I have to get the DNs > first, put > them in a file, and then use ldapdelete to delete them. > > Can we use a filter in ldapdelete, just as the filter in ldapsearch? Although I don't see any particular issue in implementing this enhancement, ldap* tools are essentially intended to implement the basic LDAP features at the operation level. You can easily obtain what you're asking for by using ldapsearch <search options> | grep ^dn: | ldapdelete <delete options> (which is very UNIX-style, BTW). In any case you'd need to add further logics to handle any delete failure, which, according to LDAP model, cannot be transactional. So any contribution in the sense of your suggestion would probably be welcomed, but I hardly see it critical. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5475) Enhance ldapdelete to delete with a filter
by serenityzhu＠gmail.com 19 Apr '08

19 Apr '08

Full_Name: Jacky Wu Version: 2.3 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.166.160.180) Dear all, I find that ldapdelete can only delete a DN or a subtree one time. If I want to delete all entries fulfilling a certain filter. I have to get the DNs first, put them in a file, and then use ldapdelete to delete them. Can we use a filter in ldapdelete, just as the filter in ldapsearch? Thank you. Best regards, Jacky

1 0

Re: (ITS#5471) Object-Deletions (some) missing in syncrepl consumers
by m.d.t.evans＠qmul.ac.uk 18 Apr '08

18 Apr '08

On Wed, 2008-04-16 at 08:34 +0000, marian.eichholz(a)freenet.ag wrote: > Full_Name: Marian Eichholz > Version: HEAD-20080411 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > > When I made a consistency check with our two syncrepl consumers, I found several > irritating differences. > > After the initial refresh cycle, the DNs were complete. But when the consumers > got all new objects after, they now have objects that were deleted on the > provider in the meantime. Unfortunately I cannot tell when that happened to a > specific DN. > The set of undeleted objects is not identically on the two consumers. > So I guess that it is not a problem with the data itself. > > So the consumers are corrupted now. > > Both consumers suffer from hanging replication sessions. This is why we switched > from 2.4.8 to HEAD (11.4.2008, see ITS 5463). They were stopped and restarted > repeatedly, of course. The daemons have never been killed. So the DBD backend > SHOULD be OK. > > Any idea how to find such events in the LOCAL4-Log? I did not apply "any" as > loglevel for predictable performance issues and so liked to keep the entries to > a reasonable volume. > > Thank You very much for any idea. > > Yours sincerely - Marian Eichholz (freenet AG) > > Hi Marion. I saw both those problems with 2.4.8. But they both seem to have been fixed in the RE24 cvs tag as of 14/04/08. I have an arrangement of syncrepl servers based on that release that has been running fine for a few days now with about 10 connections per second on the consumers. Martin. -- -- Dr Martin Evans, Computing Services, Queen Mary

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by jwm＠horde.net 17 Apr '08

17 Apr '08

On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: > Howard Chu wrote: > Please try the patch in slapd/connection.c 1.416 and report your results, > thanks. I patched our local slapd yesterday; I'll let you know in a couple of weeks, once we can be certain that slapd is no longer crashing. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5474) Problem with schema validation in 2.4.8
by benoitde＠sympatico.ca 17 Apr '08

17 Apr '08

Hi, Thanks a lot guys! I tested the patch with both a dump of an LDIF and the JMSAdmin tool of IBM MQ, and confirm that now the problem is fixed. On Thu, Apr 17, 2008 at 06:59:10PM +0000, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > > The problem is that OpenLDAP 2.4 allows to add entries that contain > > ABSTRACT objectClasses, as soon as no non-ABSTRACT class is subtyped > > from them, which is clearly an error. > > > > It all reduces to a missing negation in the ABSTRACT subclassing check, > > resulting in reversing the logic of the test. > > > > Please test servers/slapd/schema_check.c 1.112 -> 1.113 > > I also note that 2.3 suffers from the reverse of the reported issue, > namely an abstract class is tolerated, even if no other class inherits > from it. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- >

1 0

Re: (ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 17 Apr '08

17 Apr '08

On Thu, April 17, 2008 18:18, h.b.furuseth(a)usit.uio.no wrote: > On Thu, April 17, 2008 02:12, Howard Chu wrote: >> fails on test005 > > Did before too, I think. Probably canŽt test this week, sorry. Yes I could. And yes, ldif.c rev 1.81 failed the same way. > The full patch is... closer to allowing work on a full ./run -b ldif all. The one IŽve been working on but not committed the rest of yet, I mean. -- Hallvard

1 0

Re: (ITS#5474) Problem with schema validation in 2.4.8
by ando＠sys-net.it 17 Apr '08

17 Apr '08

ando(a)sys-net.it wrote: > The problem is that OpenLDAP 2.4 allows to add entries that contain > ABSTRACT objectClasses, as soon as no non-ABSTRACT class is subtyped > from them, which is clearly an error. > > It all reduces to a missing negation in the ABSTRACT subclassing check, > resulting in reversing the logic of the test. > > Please test servers/slapd/schema_check.c 1.112 -> 1.113 I also note that 2.3 suffers from the reverse of the reported issue, namely an abstract class is tolerated, even if no other class inherits from it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5474) Problem with schema validation in 2.4.8
by ando＠sys-net.it 17 Apr '08

17 Apr '08

benoitde(a)sympatico.ca wrote: > I tried to load a slapcat dump from OpenLDAP 2.3.27 into OpenLDAP 2.4.8, > and had problems with java entries. I narrowed down the problem with > this simple test case: > > LDIF: > dn: cn=REQ,dc=example,dc=com > javaClassName: Toto > objectClass: javaContainer > objectClass: javaObject > objectClass: javaNamingReference > javaFactory: TotoFactory > cn: REQ > javaReferenceAddress: #0#VER#1 > > Load of this LDIF in OpenLDAP 2.3.27: > > ldapadd -D"cn=Manager,dc=example,dc=com" -W -x -f /tmp/bug.ldif > Enter LDAP Password: > adding new entry "cn=REQUEST,dc=example,dc=com" > > Works, but in OpenLDAP 2.4.8: > > ldapadd -h myserver -p 1389 -D"cn=Manager,dc=example,dc=com" -W -x -f > /tmp/bug.ldif > Enter LDAP Password: > adding new entry "cn=REQUEST,dc=example,dc=com" > ldap_add: Object class violation (65) > additional info: instanstantiation of abstract objectClass 'javaObject' not > allowed > > And the entry is not loaded. The problem is that OpenLDAP 2.4 allows to add entries that contain ABSTRACT objectClasses, as soon as no non-ABSTRACT class is subtyped from them, which is clearly an error. It all reduces to a missing negation in the ABSTRACT subclassing check, resulting in reversing the logic of the test. Please test servers/slapd/schema_check.c 1.112 -> 1.113 p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 17 Apr '08

17 Apr '08

--On Thursday, April 17, 2008 6:42 PM +0000 quanah(a)zimbra.com wrote: > > --On Tuesday, April 15, 2008 8:57 PM +0000 quanah(a)zimbra.com wrote: > >> --On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: >> >>> --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: > > Looking at the fix to ITS#5376 and ITS#5378, it should fix this problem > when it occurs, but it doesn't however address why the issue occurs. > Which is still problematic. :/ Just to note, Stanford is hitting this problem as well, after going from 2.3.35 to 2.3.41. So it looks like a regression. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 17 Apr '08

17 Apr '08

--On Tuesday, April 15, 2008 8:57 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: > >> --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: Looking at the fix to ITS#5376 and ITS#5378, it should fix this problem when it occurs, but it doesn't however address why the issue occurs. Which is still problematic. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 17 Apr '08

17 Apr '08

On Thu, April 17, 2008 02:12, Howard Chu wrote: > fails on test005 Did before too, I think. Probably canŽt test this week, sorry. The full patch is... closer to allowing work on a full ./run -b ldif all.

1 0

(ITS#5474) Problem with schema validation in 2.4.8
by benoitde＠sympatico.ca 17 Apr '08

17 Apr '08

Full_Name: Denis Benoit Version: 2.4.8 OS: RedHat enterprise 5 URL: Submission from: (NULL) (64.254.229.130) I tried to load a slapcat dump from OpenLDAP 2.3.27 into OpenLDAP 2.4.8, and had problems with java entries. I narrowed down the problem with this simple test case: LDIF: dn: cn=REQ,dc=example,dc=com javaClassName: Toto objectClass: javaContainer objectClass: javaObject objectClass: javaNamingReference javaFactory: TotoFactory cn: REQ javaReferenceAddress: #0#VER#1 Load of this LDIF in OpenLDAP 2.3.27: ldapadd -D"cn=Manager,dc=example,dc=com" -W -x -f /tmp/bug.ldif Enter LDAP Password: adding new entry "cn=REQUEST,dc=example,dc=com" Works, but in OpenLDAP 2.4.8: ldapadd -h myserver -p 1389 -D"cn=Manager,dc=example,dc=com" -W -x -f /tmp/bug.ldif Enter LDAP Password: adding new entry "cn=REQUEST,dc=example,dc=com" ldap_add: Object class violation (65) additional info: instanstantiation of abstract objectClass 'javaObject' not allowed And the entry is not loaded.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 17 Apr '08

17 Apr '08

------=_20080417135952_29866 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, Le Jeu 17 avril 2008 01:59, Howard Chu a écrit : > Raphaël Ouazana-Sustowski wrote: >> Re, >> >> Le Mer 16 avril 2008 10:41, hyc(a)symas.com a écrit : >>> If you can get it to fail more regularly, let me know... >> . >> In fact test050 fails with or without your patch on syncprov.c. >> >> Logs attached (RE24+last syncprov patch). > > OK, please try again using the latest syncrepl.c patch. The syncprov.c > patch > has been reverted since it did nothing helpful. Failed after 68 iterations: Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! ------=_20080417135952_29866 Content-Type: application/x-gzip; name="slapd.1.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.1.log.gz" H4sICIcuB0gAA3NsYXBkLjEubG9nAOxdeXPbuJL/e/QpUJ6penJWUXhJsvgi13MsZ+Ja2/FayUzt bG2pKBKyuaFIPR6OPVP57tsAL5AEKUqmYnmizBERaDQajUb3Dxf5r/bPh+iXj0tsX4xPrlXkWdrS QFJX6T6g9snSReIASYJwhERRFXuqKAF16ydXW95p2PpX9Lf6xl8s3zjAxDK05RsPu/fY9d5QXi2S NF3e+9Nb7N85nj97tLUFnmoqIk+jiEUHuSOhZWh44dhT0zZ9FZGC6ps3lqNrFiFVh4IovsnRmJ6P beTYtajFiB6EQ76DiMDdbjeUMHCt6VJzPTzFD36bz+0wYqcmfBBhbGqW+Sc21haB1I+NVqjyMDtk 5wOzUInd1syYTWea/mWa1qQytaJ343eI5GPb4NO+w+4XbOFHBIRKt9+VRBW1J3jp48UMGiANOqSD B4etuxU1fWBq4tLWriniMvV8zfWD5dSxoTR9MO1bdKDbI92x5+btQWt0DOmuhG3ffVTRgQGqT3Jb zuz/sO6fWprnqcix9F8tZ6ZZLZ0QRRSWPqF6PB+D6lvAKtD9wNWsj/yitJ7Pnwn1YK70JGWuvNaE 2fC1KEj66yOpL74W50Kvr4vKHEtSS3ex5juudwUWzUpG0/Enc4GhVYulSoeQoIgDERhJ4h9hRaeT q3xOVzkaDvvKHz8L9M/P0X/wp7VwDHNu4mJlNOOxorKD1vHxMTLsaxf7/uOV4y40S0VvEw7HRM10 EMzuJcNuJxkd4bD1dsTNOhwJKClm2NLsvi0NpJQ8THoS+du3b6uE7mRaELYwJKPG+P2bF8pbIsKu ywcFk4HGlEOvj5HwcCTJeD7UeaMRxs5Y87WZ5uHRX6/Fb3PXsX3iIfKDM6Y65Y/d91G502TgxgVU lOVr6Rea5186hoo+3Xw+IwmX2sMYu3g+Bl9zpyKBpN1gzfhoWyDn+5OLCSWb6Hd4oY2v6OCZBDOP PlMGDrgxxwXvE5OXu4pcQ3IuQxaMnMuQt+4yhoLc7zEuQ9yayyjr7bwJl9EVLbqMsp6Bb7E01/uU tr9TpZtdH/u7Ll/GN5V2GuOqsF4a8ZJhz2lZksdtXJJbu33rl/AyJcoCYNqGMAZ6aZt+0GavCkzC txLImI9KmbCTloJw4jj+9e+qin4bX8r4yx9XV9Z/jzaOEhIeSNkoIX2HKCENj74LsOSqvjJExEQr 4kNMtoF7b6ro6rCQNDgfE1JN7LrD3XX5ygNC0lfZaOCR2Saty8VeYPl0gmiPXoswB4fa4D8OCXZd yFtoPjgZY3RwgHz84MPfLZoEWHHqBhaeBh6ms+AWgj9iV+oeKUJXFOVer9+FYdeFEYPaJsSoW+y+ M/2P7iUpfqiimM0NcPlMHE67rPjVyeUZ+keBxz/QyfX1xfnZBEp6wXLpuD42yDLObzCYTcdGvyCq ok++BT8D07gK6ET8F3TL/Ab9gZPSA9fFtv6YJNgAqq9BJ2RGzkk7Cfy7MP3csKhDcgI/SrAN/ECc te+ezy9N+wLbvAztgZdxYj+WJE98vGTSz20/IbwgKy6TyfvwKTMbCJNu8NIydc0HpUA57N5rVpgx cfQvs4AIc27rziJpbDE9bfCnO3DChhc9OI6VSRjPTjUwmPcuxpmECVlCiRLGV3o+6Xx8UUiDOU7y e4I1V7+b+Jr+JUm6W/wnjjpsspxgj/S55dyiQ3RYbowya4wntrGuNcoFa4yZ7M1xb47V5ih3QysS u6LSh5/CEGxL6UqorYP3Pr+1HRefn/QqTbKUR2iWRUasWWqWH64HJrqg0WK1iGIo4tmDpvsbSigy Emb4rCOg1O11Rbkr90Ae7PqA28CMcCwOS6FkKGiFPDIBtUNMfG7A4KQ48L3pev6ps1g6NiRVNDXl EbasBiOuj4A2+q5DhkCSdPYAc7rIaSSJ7wH7BhCdIY0E6smj7WsP8JhTjjRMXNy6TYGiGe9WtwV7 L7f3cjkjHKD2LdnmCfeGSF/VML9BZH68kqzh5aaBIE5urlYQB9zB0nV8R3esc3tOYDXpF45HkAAg BLb57wBf0m0bHolEmGFAzD7lcmIY8OTxKMG9+NjCyzsYQKHxc6hE0JWj+9if+GQJdrWexFhP+VKs jgCXu9cwHf/quEZiFO7j0if9l1OP2EftmZmrn81PIXwN6XKAfe829m6jrtsQYfTNQEys2TUMLcbi bAnW0O40D7oE7N+0wV1Ejf4V7MzCHz5fh48fTMNI+ibcWIm6xnRdx03ble6RxP0UbrDET2TLH184 zpdgGbf6yoEYrSeaNF3/kZSKEy5MGzRFLSTWzJVzHTqWOOEGW45mfIChVFCVyMLGC9Pj4Zsj1LaD BXZNvXRsDxhoFxow0PGcWZ8h/OgauIRfjyFb3Ye9PCos9xaTk8nFJdbvNNv0FqQz72F4Oy5ZtUse Um8Cgwr+b4eZuh06FYKctBk4ZOPzzTk8GNjTXXPph0VCxwFw871pYfYZei58PNF1MN3ot2U5X+Pf 7q2XFjrxQYezwMcfKWcvl/rpcRnbIhmo5+Mb/NU1fZwm/XntgAt4ZBJuwJE+RHb1Ljw9EFlRtPQT PZmexog1Nv1TujvgE8V7sUfSrSA26gtzYfpe7JmYhsPDBZi0Fdu+AQwunNh2w+drLXYzzOpvXM3H HBiOUmGUWFrUsjg60ag0Aej/nsblbOYHzYsquTaNVL5rK7g1bfZ3RvwbPMeuG3vOyKVmHrJdFiVm qiBpWZ7/Dkw3bt8NJiNFj6Qly+PjyVn6cP17NII1z/rgeH76BB7AWqSPE6xfu84y4gpPAdhC7Cmj sxvRE7hb2l+x23f93zQrLpj6uSgBPI8LLYhcPwQ9puyni8npyWk6PUobmc9J+5jklJVI08HLZ7PM 5R12J0Fi3yTt5uL0DsfBIUzIFLrRbCOTAMMa0N2pZSaeERLHH641V1ukhJ+XBkhwQwd+7HHBBh33 MYlupNqlY8ZcIkSUsoDglrpj8NAQWsfYx3rijxkOOX+ssO640pHKLGWFJ82sC9RAz4UlgL0v3fvS vS/d+9KX40vJkrvc7w6G/YEkHYlkDZH6S9fgzdUBARuAe8EbBqZ3hw3ivmpMGyI/yS9aWGaIdqFR tMYQbxQjsjAXbcCDwdDJK4omseOr0F0Cd+ozHqhb0CwTnIsRDuaIhUEOA5vE4nyYhBGqglSkIoxP LM+JNInnWkCWSckk613iruiouYpUGx30is15Pjcf2G6Nc2ByoRXWAjgroqt1WrYE2uCiJxEzPCoc HZtlTgt31zhSG/4dnt41ZlNyCDlJC0zLmManKMgRC6rIg5YFHR+W0AyDzeowjB19qhOLnrqhczNC Y0BtDvVhBzFHMdBB0mmneWY0BgEvHyId0KWFSml0u7x4MZZU0WbD7GquUdAqJeQeFymlTs6MlLeU GZ/VROlaYXV1p5OrUoLM8K+memSqy9kOhFIVCXQvXUUNb8wzwwOsnj5O4+P2U5hbm/egifYARjI9 4pDJLz3yTwUS0NwYHaGT09Oz609o7joLdH49EqVBV4B/RLV3NBjAxD+TRsqHxaGrYVSTCxDtI06K im4dnzbcNKDBTD5Zq6IEVNNkJM8dcudgGfjkzgMln0HbgM/UBiVkHlTka7dIeJAFZGEbiRKpggA4 T80WilpINW4405lJrhIAgadr9hzNFz5q/2Uu/EMEiWo+Z/EtSuceBTrmH5ghZ2OOM/W+O78aAx3p zQW5J2KAIo9akTQqug+x+Egu0pSYkBBbkLyWBbGkS8Db4EUX3i0oWiTaHA0HYVmqhbkVeHeSikQF zR7J+prvIM9AR5mG3ZxNPl98yhQOa2MaJyPNduzHhRN4iGp/Z4xGHqw2GpEYjUfDccFsFib8mW1s IZOb0w8IukeAf+AP+UsoGGDEnRDMTcuH33EEp/519OqwINblt29MKQ3cPDSPbRGtmB4pgto9HYIk GRtkpZq4AlrL6CBXS3hbhQZhqow4kBK+IDg13Izd9ISc3ZBzTaXl8YPpdyutXWzO2iVqsKIgrmfu oLizE6I6xuoTJojsobom9shYoiNgZ8y8V2bl7APhOof2orkGGN8gjbIdaFZ7EtCpfEZ63XI8ep2A iPlIpIu05JE4QiQlFDhfBDrAoNPNXAlGxxIZboGd+Ik49fMV8aFZDRHYBQ4GDBwvlhQJRnIVeGdl 4NRM4x/NNpoMrGKNwNpvJLCK6xmPWNt4pGGljxS3Elj/Vpe3WD0lQCCdWdRABHzi1Xz1u9Hk/PL6 4gx53pxcQGVicviDpQeHx86kSnyx+NzIQ1yFPHZm6Iji0eqxQ/FFOK0o4otojHCpwZfaiLHLQmn8 1+J/fv/fbz/iQBOj1Zxwox2U/xNZ4NN0rLKLha2fflqA2ZpLC6N7zQqwl2Fx+TE/pArZBFuNWI5V qwSlawPh9dxtrQrs9LSc0d0zTN1rX4xvnlTaCld5Pa77++f7++f7++c7cf8c6/vY8YJiRxU4ftpC RaPMuKse8npQW8wud8g7irUVcTXWposLmlGcphaBdkwaoux0P37kPdr60nXuO8yRAuaKZwUeX/z1 ewLG18irxO8bCMa5qrouC+5F1rUVVPeu6m4xLrsiu3Y3dDbsPdZGT8bhFGUDRhU7mpuohrPjCUWv oejp0/c8U4HWjVRFYMA0DtoRt++YE7/LKPPbxXy6ZvS/BsNd7YLdAAu7tP8bDd4GUcLTmGVQghzF +d56KEHKooTebqKEvqSsRgnyWitycn5Fbm1ckFun22QZb/2Qv3Z4byTifh8m9d9iUQjHdUOvXFhg pMM/8rnkPCRncTGhSS+fAJVjRwQdYqK3/h1SMhXFy5Ar40m+ULI4GUmUq7kq/KwZZ7Kvg3lqnIm5 VdGEB0dfZihijpxW0aRd9d2D2q4vp+zl28u3l69ShP0Lw/YvDNu/MOzHGO5rvzBsD/320G+DjQ25 ySWLpzHLLFkom21syFUbG6Njcuw3vhnmkvOWghzurYedvfaWvKd5Fj1+NfVyCdEjaV/0wnk6MKFL whwbf52mCyJIhH+EMMe0fXrFhcmOZAyfp74zpYKgT6fXKCtXyttz9C8YaIbR1wygyZqL88lFli49 +Zk5uSinH0SI6FU0h0nvEPkLFb0WkUZ0qsby0xOXTEX0aKVOL6+l5T/fnI/4mkXjq8yJt7ye47Os 7dfiYYvpTzXuUASBK2xFW6G/TbAUC8/9Q64BSJsYgLSjBiBtxQCk72gA0pMNQKowgJ1ZtPxux7fF tY9vi8whaupTlfzx7Sh1g+PbYuXx7WzNWzq+La0+vn0kNXJ8W1rPeKSmjm9L++PbtU6VSls6vl3J dxvHt6XnPr4tNX18e2tDRxRqjJ2nXQ/7Ww2U8DobY5HS1u61QTNIX+i+a3mle3QlNbJlVeSASRyw bzVVJEGGv4bk5QQHqG07gBgAkkF4KApkVteUS55Vn++BfmDkIlHN1aEPyNCAEZje5EOv0H9kDJC5 zccoP7zWJ62+1ldgRfeNSCVVLmTtc2kVtwel/DH7zDXCvlz/HqEU3SNcWVlmoYP9hEuJFP1hfwtS 6LwXDbDVyvJwMNx283l7iRk/LirSdmTY6NhMpluE3vqSNWrWKSl5H6a7wAZ5ZUVcgHiXEueikBgz 6iurD2xKvGuqw7xZNAh7ZQJ7h9Wwt9atxSEnJRO75ULsHlbFbrkp2CvvYW8t2CtvCfZW8t0G7JWf DfYOMy2uDXufb+isgr3yHvbuYe9zwl65OdgrrwF75aZhb95LVsLeYRWykVdjLrkR2NuMFBvA3i00 f23Y25gMjcPeWpI1atY7AnuHTcJehcBeUajGvYM6uFcUeEmZ8K0UwjelKI3fSlPQV9lD31rQV9kS 9K3kuw3oqzwb9BWFTJNrY99nHT4iBJ/qd8kpCQBeeZUwQ8q8sMPFHU4QbOzK4FauGlYIzh30fNIS N1CikPojfZsMyp1HiTo6K7TF2kZ8ha+iwAFbIH77ArGoMPjaRJ5kI7yEBbIdlB6NYo9x/RMYLmCk YCNzuCv3zlJwTu4tNvhn4ShgcTHvEh2by3nPapTHb3XVhfiKgs/39tWm36j6N7kjt95JvU1u1ClN 3rtvgBn33n2NG3WZiJm7eN/LnU9bvbdQObiyUogAbJtc4pcbkKHWrGaXoANMWoXVyKHeSwgypAxy 8Ez7pWKHMtG56KGMuAQ/lKqlPgDYNotyFFGqmM5KzbG2kkESZUVYLCGtwhKlTLaLJsRvYdVleCLN 5yGKOHcDTFFVdI8qfkxU0dQ9/QaYbXpPP4MqKi/q14ro1QMsI4egbBLTa2Gbp0hRC93sErKQ5H7p KeC0a+X6yELOIwvQJIz42yUMQ8d+kQBjZQs4OGNlGS7cWK2rupDhe3MqwyCrddepq2PWxhhEsrIk C0zkamCymtd28Yn0LSNBGUwpkPHQSo5oA9BSg8Meu/yY2KWpC3sNMONe2FsXu8hPxi61hhsrjjQU xC0hmKfL8uJwzFG/+osrSnKHqB6MUfIwhtyFIyb3IhFMlfAc8FJFzsUtlcqpCzS+D5MyoFKpok4N LbK2w8CTqkIsMlGqkUklm+2CEvlbXHkZHmEpeFAkzd8AhVQXfhkfxNtDkOYhiNIkBHkaswwE6W0I QZQnQ5BVwywjiTxs9hig1IwYLw549ORe9bdYaOf26iOPXh552Kb3IkFHidwcvFFCyYUaZdqoCxC2 Wb4MW5RpolOtJ9YmGERRQs+CiV41mCjjsF0coXyDessgRJTJQw80awPgUFpuv2jxYyKGXpOI4WnM MoihvyFi6D0ZMVQMrcyVgeHR0ZbAwqYSvDycsMa7VkThKS9bUcgLTAiL+m9biYowttXPv24lSt3g dSssc877VnJ1hyflm3/jSq/OGfyjhs7g99Y0o15TZ/B7+zP4tc7g97Z0Br+S7zbO4Pee/Qx+r/kz +NsbPkO5+gR+r/4J/Awp5wX94reZMduh6dpOTQ+rNFX5Atsc7Yr32Ob7YP130m6Hw+qX2+Z1kn/H bUFnrE0yH+8pLZF9pTBUb+gj/ABw3MId+AnTvXw/FAiKyi+Q1NMXvxirJL58xXnmjjZihYi5noA+ utRs7Ra7nZXtqaLlBuVS6tqBt5pDrteq28IYbcWKRaUZb7Jm8c6Y8RYscuNx52ypgXFU0bjOStNk odXLNdA6HBa1TbyeTkIEWsr1uAU2PYV/yTtaVXQevqnV/JNgnXfjd8iIrH9vp3s7fV475a7s7rKO 62go15y1mr9zg28NwLHvxn037rvx+buR7GXQlWxfc/1gOXVsIKQPBAAcFEocxHCB7LOrqwm+aq5N OL0mWHn8bnr68er9+a/kBUYYzZ3ANpBpI8N0ASI77iPqvjFmKmpLh93W2cMSEtHScVy0xO6ctMPW MV2A8YL53Hzg1d7NVh+jFx4p5M6wfU8p26Tiw7DwwgEM5LgpkyiBNMMwPW1mYeOf0YwhcHGcndbl OwjbhIz3UdWKSXG9D5jk5/TFDcVkivE9Plwyno3j3qv8QAjtsVVfQBmXb++t/kZKw58h2W9trt7a 7DV5Q70BZk+9od6rcUO9+AGN/t/8Cypij/8FjTi9yHSNb6iIvcI3NHg67m2i4xf0kRKxX6Lj/ho6 LvtMidjnf6eEim/gOSGGqB9u884Di1GKh917GDexTgqbeiV7epm3KcaDTsluo8dNC4c44Bn6La/B TOgdhSMYia2vmukr8MDNRW0fnJ0T+DB+6R8UeFg/TAuR3RbTDjC/NHhFqOHVq2zuadKbntp6hUJl J72HAI+45JsuoGyE2qA7DWQ/bCHkghptyIFkcL9+4KkxK2xANvhYn4gHvfHpLkAnSxeJAyTKqiCp kkI/utdqFYT5GPjAzDZIT9+EXQBSoVdxGzoIAS6JfobVonOYdTu3oFSPvGfSYTi4dONdszwkdBCx MpvsegXwf4FIyFYc9XeUDZoGHGAbAA6B6LAg5k3kedF/BTjA9D2gZ4ul/1jkGtHFtYamffclZnBh enxDiDqLS+9iCGa2ly139fniIh2nHragI1pkO08EjmpVHXW380R2N28FZwjJHswkwgDM3R3HJyfR iClhJSBwF2kXMmQQFd0vTI8RjAtG1+GPqJjOoEi/hMSb0sMfMGSHHRQ9OoAH3h6Hj1EcJgmhkucu xrGTALya2GTE8pChYrypEHdpLkONRlOcHXr50E8UPU2iuZJNQMoCBCGVbPopptKZYMXXmZRhSbPF uF3Uw0YHXVhHOeD6yYKSNEBxYLOPiOQYvC9B9Sq+BLULEaDHjQDDgVQRAdjc9SNApvT/t/f9z23b Wr4/v/wVHL/pjN1NUpESScnznGk2yd6m06Z5dTJ35u7seGSJrtXKkleSc5N3Z//3B/CLRBAHBEAc iKSN3u02EcGDQ3w533DOB5wGSJ8qa4ChXQ2QMtOGBkg7VtYAaWsFDZBT1dEAwGQpaYD0PUUNAPSB pAEYymYaICVloAGYHQVrgEoTpwEqtzG2qgHCxhogqr0MUgdZmgtXsf50YAMSxYABS0m69tLD/GF9 LU+oDrPGNN2nhxUA3TA6t62UMVkqlhZXQHqW1vtgypbeuKgmYXWFqijdS2/cnzeZq/JaLKWFaVE5 KVOpz9PRo9uo3ohQJqbVFyiBp3zOAqPhQ+VHopZkLdCjiFRmUTlw7q3mguMWvul6Rlqerh6Wy7OT 5950R3N7qWD5ukuDzOkBySq/WB2geFaQJI0Wc7gFWZj7Fuf0qotc553TM54Pv336j98+f3h77n1Y ZyFbKhn/Sr79QI9IiN252ORnP6cvhoPJONWS3EGJ9D4BrfMTXWpQnRYz+6ZnKzlD7gwC5QwCC88O gZgpnl1ojmfXaPeUWYsiG/Aw6Gz1zsY7XiFWqF+IFZaLocI9nl65ECv/tUEhVlhfiFXp21YhVqRQ iDXxkQqxIs1lFCkvo1FU6ylEtgqxupze08OExvJklau2hCQVC8TU3r/IrbyMCLUu615txqxa1VkN ibwQTdxCpMij1mvTIvzaNHsSZTiur+2M1GvTIr42jd9RbReIdelZrdTtXFZhGwn25XVVBBJEiYcd c2wpsX3I/jw35ylS5IbQhr6iJJb2IjrbSJxI7uL3lnukfBMR48Nxi3LPh5Y0+4fIsHnyNY9okCen 9BwBGqqUfeXGxfEm7SFrnqxm63lyOviaHR4O/DPRMKczQP4fscbTsHrWXLQQ63RSuwlukTTBrUta yR+N5FpJLSQeASHxh4uPyTqft47pp/qouZhxLkAubgrEwmsGRC1AjUDgvo4AHMyuGY7n6WMRzVfM 2tiHqMX0qjqmhjYnfevbHlnv1H3jQQhB0eaySqqh0puBAhRWQAPQNUyk37aYL68WRBhvdleEPs36 +I4fBEDHBSIdFzz36qcF1nby1+R6LziTzyWoAQP5hqnThe0GWiNpoLVLulDFQVO7KoNpuleFf9us H+63FlWhTKWJGABUmqgpqNKEH6aqkYwJ/FFHQKTShMORqTQRzVfMHJdUmogeoNJEtCFJXdP2+CpN +I1aKk1EpTcDBai0YabShEyAKm2oqNKGIpU2zHSTeFpglSZ/Ta7ShmfyuQRV2lC+YepUWrv3SUTS +yS6pNL8YCjXaWr3JjBN9zrt9fLhbrXwXm+369liSj/g+TGcPpmm02ML0H96BECtqDk0qqrOEtlp RnbKkm3kKmoOfqZt9fp/xazJkg7W6xvQzHp8QGpIm8LxtbjmKB2Eau1YVrW8Xi+PcioAO2GU2Qma rIHWw8j7ruYdwSs/1r0CmB4jkekxymwI3bUEGyRNicnNlNFZ08UIGi+jppKmzqRp936KSHo/RZdM mrE/8uU2jdqNDEzTvU3zfpUiYaRlBJ+S2e1qvVz/8c17u/iy2B7LwDExfgz4BywhA2qgWWQyuqrG zDH6WJT62B36mJf6aGQ9mcxeZkoZcPaK2Rclu8qAK8DIMuAQUvNm5I5vfpkMZkNbzKDLJzZ9gMkW ZiabCZ+gMRbq22+htv0Wiuy3MDO5jBYjbMyhUJZbduEZytIGzbwQRfDV2Xzt3jASSW8Y6ZLNN5Hc Yh7t77RQM/mi6iVcr5dL73I3vbl5foxzmjau61L6QiDJWOk9MOFYbUxVU4dxqdEq9G1BTf/wSHk8 swRlpd5eMeuzdCGYUk8c3nuvc8m1UMb5D//36eZ6upl6PydESKYiGtElwqYPDjBqD8qTgt8rP5HI c8NP/s/TVeK9XSfPjY8BjIiB09qcnPIcGnbBT5jJeAKzs75dFdRwNyUSZXjecGirTyJif8CMYs0B pHI2f3nvlsvFeoey/4zoCVSXAUUN9WbaC6QCjcYWkpR3xC947f28XpH/+kgC05CmQG4aUtUQnxg9 QVLUeKxlExhYkKmoHShMrWkXDecZpVvZpJvPD7ACEuJ53yQb7/JusbvF2cGGJOFZNiSqPq8YHQEz aTzO/Ny9XW/Wu9tvxLdLvhBjGGXyjGmCs2dMVXn6cHri5w9hrPkJ/LzZPiyn3k+k3XZHfFOMCTSm CU6gMVXlCcTpiZ9AhLEG4gR/rjcre1ECPOpwjACPvnqEALlPID6AOSfuBhW+vQuONZua67zXP/e9 4mQAVKYHtRvBEnjiIbI/aRfzrIvGaa+VIW1OUzRHLlCmMpW0v3zYrWxHpA6EqsiFyzK1R3pJ9r1g bUojskLZ6YJmvEClPRGddegJT64aklaaRhc6azzbgT3Ri9qPaB24AFpldouOtkVHaFvZkLJgBl0Y jZ/Eed7T9tAT1iwakxZMowum8dP4kPV0W+oJaxqNSYuiCy6kphtXSPu0HVXA6+TVs/nqV5qd6r0I B8/+V/3FHdlzxN5PDr37ee/GJqJVLkeKY4TwFfs+44Jk05gEPk9RThHHncbnz88oGotFC7OZs2as eC2wNirWtoGfbWEug3xDY4ZS7U2sqV1sYQCHEElTD+zp8tndmX4xnCiqJ2PWq5oAayya67jDIAxV dTRCZ7hrAUErFJyNcPWMoVIouBqiDhcSUy+GSBYWFj/dtRF8iyIaWcEfRjNA9izs8Bnb1H5YhnpF 7FuxybB5fRHhzj86g1YNHwQf6BiWOCKbVpxTRP5egEK0+XpEZM3mQrQSkLG4Ii0FkGwsTlRWn3jl 6ZNNL2RxQWaKdc4cAojGi0eGapmpFl8zoCziEm0GlEWV+CMYZgBSJcrupVLjCERCiVLwFNE7gld+ rHsFAE+JROAp0XNPY3nAMCmaNOSAKNGZ5rICoU8iTeCBOpCTCA/kJG4IchL1BeQkCmM5yEmsDnIS 8yAnh1PqR492ovOpIOyJDgEB/onWcKsDoVghW3YAjKFRtAa/wEjR6f8Vs84ZsBSdvp+87erqER9R PaJLTe59Pf+TrsvpOnSNSxXuba29K7TpES6NSwXuYV39k42CuqKEx1uU4CzqR1Ls96Tt6n7Uuzvr uueFeM7G7l0xu7O0+1Z0p11XhJgg3OEsUzAV0iBhDyHRO8YerJ4luiPnrOEVIGCvYjTGDmmnpnV7 aCyNcCcRKd3dVSr0vlKhQ6msT/wI+MkG7oC8Op0UBDjBTpNCGwmNWgkSjTMbdXp5lFMBJD3GRdKj FmtgKmOsn/0Ya2c/xqLsx7jIXNRbS3AaZFNi8nzI+KzpYgQTI+OmSUZ1GZIxXobkuGGGZNyXDMl4 FMkzJMfqGZLjaoYkLrJs20mS7tlxk04dsnIzs+5x4TnbXhfPbcBEl2ViKZsWlXPI03o6t1Lynpni t4NeWt/HTff+zcrnK16oybkVuFWfgNeB3cHx/UPcLc+4j0ayo+phovLpVoqK+zrO3Ffk0mnIVR2n 3q0BWQHVH61RFb4CuNVjkVs9zjxh5C0Ie92W+pI75eMzS/sX9NnHlkyZOpd+jOfSTxq69OO+uPTR JJC79BN1l37CufSIkK5tO6Du2ZEdegdmrOvKPxoAZbur4Tk+KnNZBpZdeDyunQPvHPi2HXhE3CLI KUMl34LzjrjZLbrueFy6FSJz2ie5044J+AW5wRMrLvvEiss+0XbZJyKXfZK70ZgbD3bYrfQkd9cn Z1b2LOisT6wYLXWu+gTPVfcHDX31SW989WAi99XJMCg76/u2e2/dvBqxbZ/SPWvma7uKWVvoM8eu zbUxt8+xynwZ4VNyk41ZdM6xc45bdo7N6yEAhweD6PEdYfPtzLi/uqKg6vEas/OEJxvwaaeZT4tQ /wN5h9PUk9WjJCD0IyYhHX91KvJX/UHmRiJsENhNxexA7p1OzxD3F+iTThEthDpPlJgjeK6o39AV JUz0xBcdxUMFX9TX8EX9qi/6/tPbR46Sq/SFgJ2l9B5oZ6mNqaqdhUttsZsbAt+qjWfmyyj19opd oCV/RakrV9v4VGsb6eevpnfJ5/dvG+MBd3m0EFcKbaw/VMAbTND6t89m2SL8dKCSr09GMaMuT0Yx o99aMgq/rFAThAQLEbUPwdJl0eMClG7q8JLNe5DA6pl2oICxZ9pFQwhrlG5leNbm8yNYzDYWGtQN vSwrB9XDXshYpPkVjEMZXro4tNXXLGJ/wGLFmgPRKsVdPk/aCuXau6Ra3Umxk+BamRbUXFQFMF1n AjTG3DW9XlMVgNe0H9E6cBpUZcpx7vusmWucDkqQlKEiJKWde1KHFohbudu2l9d3j6yNLvrl3aNI EeQSq2fubFYptgudv6q+ePwDdbV4c0O0MCXij2CYgaPs6+woW40j8HD4Wh8J7FobCexaeJ7sZ8e9 iutDcGasSUR+Lnx9prGwtkuieJeL7S5ZJZur6Wy3+DLdJacUPSy1YJjnp1RNn//ww3I9my5v19vd +WTg+z9kR6EXsXczv/BD7/WbN+8+fvJuNus77/3HCz+IXw7I//zzcBxPRt4p8xslwB+lhtBPzOlq zJ+uhnWnq7H66Wo9zlZMz6PS3N1rMpfcieTibgefR97JDiRrfEnO2BO2Bc23esfW3DXGcq51xuS5 bMzKk/Xv7z/sDw/FmtG7S3a3a7KEg/GzfHrPvS/JhirBi6He+4WUz4jMV+mOFL7ajNnZ7cXl+18/ /vLO225vLgYlnode9gcJid1a0kKUtJFzipezkWrdSayQsREyY1VK2CjeFuRrtClRfL/+cuP0Y9IU jG0y3cxu+TSHBfnnuk5+SIWGgqRouLlRXwMFAbj7gS++/P3NT94JsNADb+CRfwb0f5xczoeVNrhZ LHfkz97p+vpPshDeLKfb7cX3fJrLr/ukE/KZdC5nu81yK0y0EfRYfvfcW5MldeK/HL6MXvovR/Tf YDAk/5mQf/0T73S1Xs02i92CaF6eoUV9T5Wfr+szZsg8lfhakZW5mZG5obuL7GI6TtPdbkMefe/9 G7OA0/G/nm6TC2gStrP1fXIRePOEWNuEXjbYFyeVwT7hSdLuLmhnuVAtdgljE0M2bNbwinzifEEM 04TwLGTvYD/5ZwWvjNG6hPvIm9wTmUYMsaTUGbOMMj8DYIhM+wufDMZmuyPfS5qS//iUaiou8xfS b8yEr5chsUIGcklsjoOoKjfJtIpJJl8Xu5fyXmsz/Mr9hxNObiP1L/asmP5HA0v96+Y9sqNia1aM igSZhRMFQxs8qtYZnFS0v511PNPHMWbYIv6LJbaQoZoYroORNa4xa1bZkZ74lnhGyGlmOfXHDTit s7B9PAs7yONaPmRi+9yOZ1Twu9dUCTO50TkZb0U/aZFs0wLg1O5GjCeM03hCVB9PCJXiCRH0E2P9 j3nrP6qz/sdY8YSxiyf0J54w7lM8QZfZ9uIJ4/biCREzVurxhDYliiyeMHbxBBdP6HM8YYwfTxi7 eILAEh03iidEdcbtWG6Gjw3jCWj9N4wnoPWPGk9A48piPAGHR6x4AiI3mPEENLaOGk/A4/p48QQ0 nq3HE5Q4rbOw24onRKwK1oonCGvTrzWrQWvrzxFHxg+a1p/7fak/j5TqzwON+vOgWn/O5hr7+pup 07Xp7lmzmn3jVSFNnG9AUyFXvsn6bVYhZ7Mn42uLa0Nz5nP7HEjjb8DlK1YwlXAHjFl0OGkOJ61l nDTzu8eBnGIMosdP6zbfzqg4acbsPOHJBpLLZ9lxhTm3YBb5DAsnbYaFkzbTxkmbCfPagywlHWGD CHLeETuQ58PPzhD3F+iLzhAthFo/NUD0U4dN/dSgP36qwv1aZBzU/dRhvZ9qXBPbtgPmnmE4pq68 u12El1aryq0vDsjNNa9WZ4Sc0Oc1Zd45wM4B7pQDbFxyLnWQEHpo2zU23vX2rtPCZdStFjXfeg75 1uboDZBbO7dytdbcytVac20XfC50wYeQh2y+EQX+uK3e5M75HHLOUfYx6KnPbdk1tW77ENFtHzV1 24e9cduHKm77SMNtH/Fu+yopAI3cufKjfyZ335suB9BVb0pM4JY3XqrqLrj1Lv6kXeR4Q6iHxo0n rnCjm/L1ihUwjMvclCnnHjv3uHX3uOmGgJ0bA2ptuL2Ndy7yUXBTPp7UhAKeaVJ4po3ZBD27BOu4 N8E67k20fc1E6GuOCu+v+eoX+JUYlOU+ZHKGsWtAfzHBUOq1vuEI0TcMm/qGo974hr7KNcyhhm8Y cr5hQr6BaAnv8m6xu3Ue4qN5JvUCDSce8gUNScIeoekCVfYLj9XRn0VH26IjTB/RdFpzT9GQx1es 0Cn7i4YMOq/ReY1te42GmwN0NcxptuBBmu5lXD/SkJsnO9GAZ3mTe5amzILe3A2Wf3mD5V/eaPuX N0L/Msy9QOO9IfAy8ejLfc2bM7ydBXqcN3hmQa3fGSL6nVFTvzPsjd85VCl5jTT8zojzO5EuWWnb zXLPGrqf7mqgI1+u185VRPZm/jnu3UaMsCr7qzjsOrfVua1tu61ItyBBTg0a6RacWKQNbjHtF4dD tyJE3q4/yN1dzHvCqj6mP7CS3EvI2sjuzcnquMR0FAU+cZT7rFhbTeAao3cj9ZAzjwtvi3YJeDUU +YDlv1CqNxT1Kt+V1KddrYnuOr3Mho75gNlyvSVMnXuU0W+UvRwra5v61ZRX2iSpvkM03zwV4tVX SlhbKarSwyrFlS7/+vkDxQRmR2lLBfU5hcZM7u53KdGMM544ywXUd4bbnTaYCyMdZD9hG5S1AY8I MeARNw14RH0JePgT4WIvfU6sEfCIqwEP8Y3dbbvqJm58l284P84d6Tpjoga7XiygkhMqJAlcSSoG JAfMtLrGxzfFxZ95kFgK9rKQTI8GC7JSfRkmPWzJ+d53avabL7Tf4sywqpkfgUWm8KLcxvLPFKYV VLq+wgaqVaMxohodN1WjcV/UaBSMFNToWEONjnk1uvnLe7dcLtY7l6z2aJ7JzQyDWQdNEQN6AnPF ZF2qmzTH6OWO9pLse0HMTjObx8J8MuDuFStcGBPLgDUX3XfR/Zaj+0bbArZ2zQi24T6YbGHUXDQj Vp7g5ELuTlC4Oyaswi5RgJWBRighpaDllLQC7oHQYRsXfpfRjhA4dUjE5Y5fcIa0mUDnMEBS/bUO 5BjRgZw0dSDHfXEgw7FKwdNEw4GcVB3IzxsyAVPvJzKH212ycU5kr57JHEXj2QUMS2OaoNFpvg5V DdLj9fSQ9XRb6gnReTSf28yBNObyFStgSk6kMYvOkXSOZMuOpPH2gPwNDKLHdyjNtzOqU2nMzhOe bMjBHGYOpjm7sEM3RHMyh2hO5lDfyRwKncxJ5gci7BKBo4nYgdzZHJ4hbjLQ4Rwimgm1TucE8erD QVOnc9Ibp1Mnz21gkucWpYljA508t/yV0sCSGakkuhU/N8h0K5MHMt0qvd+k3OeZbtX5CvkpDNkp jPkpDOumMLYzhaHJFMbpiIQ6U5i/8iz/C5SqGDdOVSwTByaw0vdNyns+gRevCBfbb6vZJrlfeptU Tg2fpVKA/DTdJdmfHzbLq/vpZptckTE8pT+d//DDcj2bLm/X2935hMi1H85AYkFGYDvdLq/ot15t Kz/wnaWCaLFa7BbTJfn4/35ItrvsySr559XhIz2f/G+QPVmsdlfr+2RVepwTzv5+tVtfpax6n958 9FjOVT8xIJ+o9DFH/oDgQJsojr8S0obMdvrbPZmJ6SbhfueJbtLl7QfxywH5n18amPsvu6L9OVk8 lIi3uzv3XvjEDCGTfV58AsPAQMDAQIOBQMTAAGYgHT+y8Wjj80LZ3zwsS7NCzKAvRBwUk1KNOi12 gnDUovR7ofmGflXzlRQt8eOIaLoOw8FgFI0zRer5z/45XexG5C/wY+90t7hL1kT4+Zm54D1sk9nZ 4S0q4Rarh0TwOnX3/Gfff195/Ga/pIho/N7LBny/hDzvfr0hP9AB97xTMn5Twv/ZM49IvZvZijwh PxMncvdAHKScFJEcnreckpcJg2RGPt0+eK/vN54fE/PyfBCcB7EXDAbjZ894bn572BFqqzmd7t+z eSBsed8XX/Hc89abRf7HrF/v/erjZv3HhtpuHnlcorB33rzBc48utRVVNQ/k/w8oi0zP+aznz8lo T68JlfWKqAFie3CM/p6bQd7/fUgeknPa8zsifr91YrGF/GIbB9N5MhsI1lrlqeZSq77NrrTiqfJC G1pcaAUzR19nRcdqy6xoLVxlHNW8XdFrJkdv/yoI/LLYwgshnyyw/SbZPWxWW/a9D59/+eWglbbJ kkzEM2oC+YTieV0fjN3Fb7/KF9Ql45cB0SVd35Hpmv6ReLtv94mXauHqhkpev863lHjQBMJU0De9 uP2fh0WhMLh7+unoHsh66dn2Yc1QD48s++fwnuZnJXuPLi94eEiT7VVq5Z7TpZv/bb059/7Pq+yv uS9If6h+rmBQUi5uNklSyDbv9LCV8qZn7GI4vFKyfwaVJVO3CCAC57nk4OeJY5xfJJltkVp8mRSt WTachN4/EfVbXSCCMyzVdcAZEin35C90RKBVwL2gtQzUJlg4p5K54kc+15nTzez2qnDZ4PEWjCNx GK9uFssd+bN3crq+/pN0OiN6Y3vx/dkJO1jlptsFHeb0p+yPByIMjROOwyzo/7BYzotfyUh5rz99 +v3ynOiYf1PhSOwnQOYDwLfQolD4oOq7ZQFZ911M7CeMQatE78OU7SLALOI4GDBeaMB6oTWmeVBv mgcHe0nPKA9SkTnouVEeHIyloKNGudTaUFb9xZTp6vSqbtaPbw4EIRS3pN2S7sSSrreyil5UI7bD UGzkc6QZA46wlGzukvliHzTMzAnmd2jXDGv1ntibDqrvTfP36pxsYIdVqPxWpVLndZeHt0RjV3xC rTcusJuUnXTGhJJsWblgwvXpdcWcsgzQk4caEqNedLYTT1AW2KqBB3WhUxt4kCy22uAAKJEUF5+q 4JJxIBZciipLJN+Ul7FA5GmsV4Hws6X4BFJSKaAESUZtPSmQlo3UZyE0q+taqnE0VYuWDulz5Bbf cuto5BZJgEI+RXEOqHXG26cD0Ehw/hhhnD9G3PkjNMZRkzEednSMh8AYx4IxjjEOmeNOnPGOxmx4 KYbE9vV0NhEd8Vaeah+7sW9Xj92yp20I7wkvvDNmWjh2yzpWFd5Za7nwLqhqCG9oslSEd/YeKLy7 sOgj2KMbx0ldYkP5cYPEBuZ1PrEhfdxGwIlb+HtuWklsSHtWt7vT5ioBp5yuVsAJmDI1izl9Ue3U GdpiqvGm+kNllrLOobKAVPUIUP3Ml1Uo4BlvtUmHD/e0D/MYtylP2s/ytf+g9sVqTvoDMcC4pusZ PXxbPSyXZyfPvemOJvvTFfB19+byQxU3DSpBqNDbzC4G3FFg/UmfwXFj3THcsc/ZorBqCEHhVUBT sEuV92qZp0bmEe/b9s88suHbdtI80vFta8wj4NQA0EIYCoIjbaAh9rSaqgjO/BJkgFTaPFol4URy aqZDIhlIFK2sDOicuPzYzHiHTov7Z7zbOS3uqPGud1rc0HjXPSwOAl/Vem9yWFyz4YCDD8EBhej8 ofL7f/79v3Rlm7OonEXVikVltmn9wbjhps1U7AtpZq5V3zuQ+94BllkVFGZV0IpZ9S+BaFvXSyo1 sXmnK+6q3+4XH5caUXnVZNkYisEwPTdS09nugazgbx59wuUOCNQgiobiaD9qFeUsTGdhtmBhGm7g Wm1Vv4EbqivsQACosIA2TmN1TWNFahpruySNlmSXJCtCizxcfCGq4TQ+O/dSACzmOZhg4P+QpaFf TPJLi16/efPu4ydCf33nvf94cTidD8fjIPROmd8oAeg6KtkNVRPNG6omypt2FNWiRU4oqkKKlgGG 6BZ3gojLnQxlsOYGFw5NTNgWRBCrv3HG/M4ae7feiMdE7dabfLIoAEYBkyO+6IQI4N3tmizhYPws n95z70uyoZdmXQz13i9QtjIi9Hyp7tVmzM5uLy7f//rxl3fedntzMSjxPPSyP0hIEEkhufpFAAiU c4oHQpvC+UxiBTSgiBmrEhhQ8bYAC6hNieJHgVyk+FSkZFqfxy5dkH+u6+SHVGgoSIqGmxv1NVAQ gLsf+OLL39/8BJ3jEttqQGxOj1ZZc6m4hWKmDYpIfR7gf5MH+Ln5+HWPJEs+k87lbLfhS3L/JdD5 d8C7596aLKkT/+XwZfTSfzmi/waDIfnPhPzrn3inq/VqtlnsFkTz8gwttIyO63pbhMxTia8VWZn0 lDrdXWQX03Ga7nabbXZGUV7A6fhfT7cJdKGWt52t7xOKUpQQY43Qywb74qQy2Cc8SdrdBe0sF6rF LpEetufHKjPq4syJWUN4FrK3x2wb+GcFrwzA3xLuo8gR+G9iVS1230qdeacpa28uP+yRB4FW56Vm 3oqIoxSxLr/0EfgAskxe+GTwNtsdGR/qOl74k1JjIjLpbbPblFYqhfORZtoECm2GCm1GCm1ChTaR QptYoc1Yoc1EoY2vMoi+yij6KsPoq4yjrzKQvspI+ipD6auMpS8azDrLwde1HDq87+8J88lqljD7 viTRzvT2MeqwHZqWw37FC1ThCPTNiJotF8NwUIfhmEEwBj5gtA0nPn+S3NkpXKzUhDfYTii+7awP J+fN5TyZmTx1IkvvoNOX7TP6SuZ4vf/0Vg66fcIs+smQc1XIwhH3lHxd7F4qMfPz9I5Qfe39vF6R //pNkF0Zl4r6I8fgNDC+jZplO7Y3wKukuD3bbGR5dxWLxYQ4qTfJxru8W+xuzRkdcOFCLEaxbiJn +Q24EgIkfutuQS5xEI0iawwYXRRUmdaJJS4R0KUZTgdxkwm1ZB4JbJsBZNuQMRZHpIjD+u41dVkZ lOqcjLein7RItqRt94JUWmjHkQna8SSFD4500I7zV0ojzaEdTxqjHZeJA2jHlb6zM44c7Rjx9IQi eMuPT2Kk4xMWnVthIfnqp56SAxTyoe4EpTcnKMVs9eMIRZvb9s5QClZbPEQpWMA8RbEpWGTnKNn3 uIMUd5DS14OUYgVjnqQwNN1RiguxuaOUR3GUUuxrd5aid5bScNzcYYo7THGSXucwhWy0Y52mkK6k ocwDO+2ep5jw2uqJii7jrZypaDLZ5qmKJqsdOFfR49jKyYouC22drejx2e7pyp5XWxYTxvnK3o21 e8BiM351vCMWMljaZyzFO+Xh5k5Zip8bHLMw9IFzFq5/5qTlSeJhYmCOCvEweczRjkID0vroJKzD wyw9bQBPUH6bx8OkT5XrPvHgCYYgPAFlphU8TNqxOjwBba0CT5BR1YIn4CdLDZ6AvqcKT8D3oXxC IQEELFM2BASkpExACco7SgBKwDZxWE9PD+tJKo0hsJjSUyNpDIHF9E0a2wGL6aA01gOLaSaNdcvv RxNVaYyHFYMnloVYMWwTV3kvqbyXHNK2VnnvblGwf4tChz2amfAS98rTJoBrwivci6fKOhQPyQbW obM2LnAvOtYAXFO4Vu9AVQ9wDb4NWQ64pninHtwHlkdTpmwKcQ7ccqwFsxZJPRq2ifNonp5HA6DX sgsDhL+ELv9rII1B+MueSWNL8Jfdk8aa8JeNpDG2R1OmjIZ+iSaWxeiXkfNoHoFHg1kN4ytUwwyH WNUwvu6hn7oBJauG8V01TI+qYfxeVcPocttiNYzffjWMb6EaxqJgkVbD+K4axlXD9LoaxrdQDeND 1TC1UulIiU8hl+bNMqyS99RNSXXEvCe/Qd6Tz+Qd+XDek98878mX5D1V+7dWYR6o2NRYAL1+oLug AjSbOnA2dY9s6qBXNrUuty3a1EH7NnVgwaa2KFikNnXgbGpnU/fapg4s2NSBjk0ddMCmDo5jU1uU VEe0qYMGNnXA2LQBbFMHzW3qQGJTV/tXqCVQzMdpWG2AmcbTOM2nSQJQg9Qg8yqIZslFsSC5KMYo l4jh5CKd7KaWE5F0hkE3x6qn2U14GcIjl910nOymLuwkIKUvvRPrOh4IVn31cZML6sqvs+t+/7iF RBJ+4e+5OfrK3/escUEdba50QV1GV++COn7K5Kt//6JL7nPJfS65D07ui3XKlXqS3NcBY8Ql97WY 3BeEccPsvsd226/btG7T9mTT+n4ou5FekpObIrFwu/PrV5TE0n8ld+UdRz9ivrq6puBe1Qj48l+w 9SYwZEVHpABglR6UzSt27LlzVeMO6HGKqlHMndMa956enciGWMfYBo5vROSrBjh3Aoz9dQp3TZd9 ZvBT4Ouny69xn/Fn+hlT78/DZ0yzz5iyn3Ff/xkaPoTodNx8O2Sn6MafpOrmcHLh74zOhhwgvVdK rpHkxVqn6dBW2Z0SvyMiVWGoMFjUeakQKLlt4pbaDl09KYmrJ+G4zgmUfqyJe1gzvyLHUfyK0gs1 lWRNJryfT8pqPZNgr4m6l4J3AvlPSu+BuVBKbypnNalTK8twrW/PBi0T+4v/lzyOcaNm3rag9od8 3Cqfr/T6K2C9CWEjgbEStgXHR9haeUzqKfDrp+ZbwDXT5W9XyQ6sfE5N6p+bdzfvaA6jHR/Rku+n MuY4PfHrEmGswfXr5tCWEwruLwRnkN+Hlw/XNOvqbgrMxf4ZOKb7p8pjw77Br9MSL+B6OyavW4DX Cjtbhp2uXs0gvpjh8+f3b1Uu1knbuZt1OnOzzsBdv9Pa9TsvmlUsFzUn0/k8LTcx1kcVGYOhHQ4i I5UqaERzAZMSPaeJ63la8rn39t+vPvz26T9++/zh7bn3YZ0NHD2s+iv59gORKVPvfrrYeDfrh9Xc O30xHEzGE5ZJOqDe4Ks/yuppzNlNx5WI1KvFaptsdleEk3R1f6dNSkTpR1RKwnfKo14apQEdvlSM Z3cB0EenXjB47gmuHdG8kMBL59tqB0XiH/2SrItkNVvPk72e9EdnSJtMEUqqcjRRPbmuPjbLAqye XfczCxD/9LrDWYDqJ9haWYCCXlTPsEeDUHyEzdF+1JknbgO7Ddy/DVyfhFK/g7uahWIxv+TRhZr6 GdTqdLJE+yex7slTeuLO3d25uzt3d+ev7tzdzbs7d++3Ie3O3d25uzt3d+funTh3Dwbu3N2duz/5 c3cX9ndh/0cX9g99w6i/7n0wwkrChiV/4I0wQBt3JYzk8FQAH9m4pEy/cKwEldlVQ+yeTFmymiWM IVZCtDzTM6twFRTt+m49X9wQU1yW5AV94+H97PB9RQ9VDuMlIsq9QtEPp7MkEyxfd28uPwjTa8gs iMim6W3k/xGRnebKZNk4BWCyefLPUa0DB0fREhxFeU883NPNWFpOAz9dTsDaaAfFQmFFiu0NFKAL 3QWvi4nB1UDvjRRQnQpvGWtizqDcbleu8uWuOHsyV99x97Y5Y8gZQ90yhoos+XlCt1Saw/t5Q96Z ej+Rr9mSKcBIlH/ISN6WSBolyufs0gTrYZaGbt7DPuU7o52nfA+9HzGoi4gb5LhX2USlpJbjzswC l+ZOnp56/iTLQjdeVECaO3oHhzT3i2JfzKZkx+QfSjvzst1abJfsv2XTe38zijlD9rf6r1Svvlsu F+sdxjZP1XSyJ4e1xYPi5hYT6vBqD9LtbURZRBhrawdoWztotLUD4dYeZzvPaBEJtzUScfmWHku3 dFBsaTNmjrGdRTcqAVtVdMmRcBv6sguU4FXn51usjjXgpe+UF6gvXKBxsYaEVz4JFp/Ci/KFFUsX ln9YWLpXTuEtmp/Xtyvv7Tqha/f96oae+6ZuyadkdrtaL9d/fPPeLr4stvrVkZTwPCO8KBHeHQjP S4T19cIgr0BE6gdeiYN0+SL1IeriOztkf7RHVleLDISbNMrLFHGWoXBLo3cjFwCRVAAM9nFaJLaO IC6S1Wpxk2y8y7vF7halirqguC0oIhmON7l8MKUP7oObTC4Y0haQRrIdb7BMx5sme/5GuOXDfC8a LiXhXsejL9/koWyTD272m9yUnyPs7ukqKeSQOToCoZXrTKQdnRSYA40pg8s7yfZyY6oCoki7OMHa xUmTXZwId/GowBdoumSE+xeDsnznjqQ7Nzkcozbm5Bh7ljvjxbXj+VxcG+b8XIgngm7Uz/P9jtmT oCMblv3cimE/byId5kLpMBSij9iw7m31JpciQ6kUmdckY3Tc1mcY9nGMgvKm8xFtgxkkP5p0AO6O GSAyGhAX0EayFGZYlsKsiSyYCWVBAO3OBstJuP0RO5Dv+EC642fwjm/CkPX0K+VcEkE6R6yW+bBd kkbLxXaXrAgt8nDxZUpGMz4799ICGOY5eGuv/8NZfsnwML9k+PWbN+8+fiIdrO+89x8vDteqhuPx yPdOmd8oBegeaenV0kPdq6WH6nBAkehu6eJD0zmer6/Am0kWdwJ8/juo1r0M/1BTvshVGwnbgtVH 9bWU5tWYWPWcOmPyXDZmzGzRK7aL/S8+K/Hukt3tml5EPn6Wz++59yXZUK1/MdR7v5BTGZH5KtXd 4gOXZtzObi8u3//68Zd33nZ7czEoMT30sj9ISBB5ITk+Et1jP2wk6sT32PvpBfSTGLjGnjiF4DX2 OQul++uL15vfWW9RsPhRoCBZaN3UPmOqipexIP9c14kRqexQEBgN9zjqa6A8AIUA8MWXv7/5yYNy xgJv4JF/aP3GQJSzRhsUaW7lhLCL7/nLgX79n/85ZLrRyZztNsstP231eXrld8+9NVlUJ/7L4cvo pf9yRP8NBkPynwn51z/xTlfr1Wyz2C2IEuYZWmhlBF7XJwqSeSrxRdant5mRuaEb7OQkHafpbrfZ ZpfhMCs4nQBh5l6erEdMtE1ChFY+2hcnldE+AWjSDi9odx3OLBTXu765/KBS7kqbuWrXx1ftGogo 1apYXztk0N2tsVipbQ6wHc72aDzWZIr7NdjHyXBuuEgPTctQqcULVAcKVOCImlIXQRDUmJJBagv6 gQ/YkkHkV43JDs+hnQ1jZ4E4xdMlxUPmOL9mMLtykS6EbMt6h2xohEJExk+jHk5lc5EFWsNH8nWx e2lNtAjkwgCSC35Y52QS8/Pda2qAlnzNPR1vRb9qkWypD9tBvzMUeZ3lv1CyN/Sz80sJvLQSi3zc 6WUWemU+YbZcbwlXtBhqOv9G+SsGa5sGASm3tE1SfSmNzNJaMu6d8nBT0VBEOZmfP3+goRF2qLZZ TRhxDZK7+11KN+MOoM9yAvefhTHTJrgR0pFKhHSIFSEd6S6oEVqEdOQipD2KkI56FSHV5bbFCOmo /QjpyEKE1KJgkUZIRy5C6iKkvY6QjixESEcuQuoc1b46qkYR0pGLkB4tQiodaxchxVykLkLqIqRO 8VhUPLa2K0rUcaQRdeymL3fEqOOoQdRxxET9RnDUcdQ86jiSRB2r/TNRx/J1m0v2uk3y0/6uwYfN MsefIkMJBh+DH3IMrO10u0wDH1fbyg+lvNLFinhN02WBqJU9WSX/rGSiFlBoFD+NiOtV6XHOY/b3 q936KoPq+/Tmo8fydaC9Xc/+SnYUdzkH1CLfPN0k3O880U26BJhQaU73/suuaH9ORjYFdd7dnXtE Jk/psJ4Xn5CyT5YGbXxeJBnfPCxLg7JNNl/Iii3GhPMnBbFMxtEstvtoXN3tANjibJQEBSiaz4Et Mk+1wRbZtymsnV9CAMyetgDDHAJgixkzErBF/wC26OOgMBcdq6ImZq3lqIkFVWUIZniyVCARs/dA AGZIsERNBMuwo4JlCAiWWCBYYg3BMhQJllhTsHAwi9AsK8dLy+FSCWUGMbIyPzZlXKwOr12w3Bxz kpWdIOYk24STvxn6tlAAVx83gsIXiuD94xYAb3kZvOfm6EJ437MOFL6CGC7R1YTCbyCI9y8KoPBR wE79AuzUxwR1B2Hv5VJKCfpUfBF1kSJCqNnCKFWRo9k5z8NiuU9aIYPuvf706ffLLJAv0WtGEhUQ qMGAsxpl88PL+rLiD1iPQmx98lDfzFMj65OH+u6f9Yl/B0hHrU8dQO4a61PZENgvaLElUMOlchrL RNV6wrk9BNe8EUBqV5t05uoQvStSqiaaIcy28JqVUj82oLgl58f4hb+RWuFvp62P7psSXTMR/Cis Ol2QwgfCTZVdAN/81Vjlc69DN3/1zd2xdfNXJ90d3Zu/xO5OncWqq7mDMJbd/CXS3eXD1LLsYX5X E+6COxx+g3/eCaj859//S1e6uQ3sNnC/N7Dvh+OmOzi3vtODe26nfv2KcuHKv5K78u6jXzFfXV3T o+Vq5uKy2NeipHV3SbWti8aPfR22jbl9jnWzNrcw/y5yVdwT98T8CX+T+2uiAi5305sbulD/tlk/ 3G+VhJnSe6DAUnpTWVSoU+Nvjlf8dvBW+b6PG1X924LaH/Jxq3y+0uuvgPUmvJ8BGCthW3B8hK2V x6SeAr9+ar4FXDNd/naVOrbK59QUqbl5d/PuDGm7hjS/LhHGGly/bg7tuiiV4UbwK/h9ePlwTbNf 76bAXOyfgWO6f6o8Nuwb/Dot8QKut2PyugV4rbCzZdjpak2FuKLi8+f3b1UK9NJ2rkLvURdKWLlr 3oWzXTi7h+HsuqvblaLZurkkChkyWmkWYDYJ0KYz6SQYWSE2Mj7c5eudKbx9ymj8oQrW1BgLayrU LSMM0bCmQoc11SOsqbBXWFO63LaINRW2jzUVWsCasihYpFhTocOaclhTvcaaCi1gTYUOa8pFsvoa yTLCmgod1tTRsKakY+2wpjAXqcOaclhTTvG0hMYfdgSNP5Sg8ZuKFhRcrPA4aPwW/c4j4mKFDXCx QgaXKoRxscLmuFihBBer2r81NP5IIUIaot1XGukuqAgtQhq5CGmPIqRRryKkuty2GCGN2o+QRhYi pBYFizRCGrkIqYuQ9jpCGlmIkEYuQuoc1b46qkYR0shFSI8WIZWOtYuQYi5SFyF1EVKneFpA4zfd rihRx+g4aPwWfbkjRh2jBlHHiIn6RXDUMWoedYwkUcdq/wpo/IpQ2g3x+jERuBsjdDfB7m6A6m1+ j0B7uODCCwcEuODoNx4Igcm7eeNBLCj5mU5rEbdLj5uU/JRfBxC36eOj486S/4NLfig37SBu0541 Sn5oc6WSn4yuXskPP2WKJT/0RbDkpwvLH7zw4/qarmLRhR/MU23IZfbt6oUf2dOjV7tBS79gpoUL P7KOVSGXs9ZyyOWCqgbkMjRZ8lVfvKdc58ZvLcYi5FCLIbbqjg2EpwYyZnjYcp1uFDGY2a/huxQx WS20U+lSoQSvrPgEvPIlfnClHkxKhinNSh+tCj8QgJqlJy4CLGMHN6wrFFYMWsMp1qlHNKlQlEIe C37ma9dEsMjVv6sXJiqXLepXMqJBL5tiMyujNiOYDQo4z7o3RMT16NCR4DoIHczog7ABa/RLj80M drBGv3cGu6Ua/W4a7Jo1+kKDvd5cwLztgSONVqIPWQ4N7QNxiT7bxpXod+1SBsX6b4lryN/Gwzw1 cg3523j65xrauI2nk66hzm086q4h3IeqdK1F5K+SftSA/G7Tuk3bk01bj8Jfu2sdCH//cSf7iXDp QPjdE/fEgfA7EH5m3BwIvwNj1y1fcyD8bt4dCH9XDGkHwu9A+B0IvymvDoTfgfA/ofoIKyD8LoTt Qth9CWHXIe+rRLB1T/XFSXlNEu7AM32+iTvSd6j7fSmw7QzqfnR81P1YBVMqxMKUinXLBWM0TKnY YUr1CFMq7hWmlC63LWJKxe1jSsUWMKUsChYpplTsMKUcplSvMaViC5hSscOUcqGrvoaujDClYocp dTRMKelYO0wpzEXqMKUcppRTPC2h7scdQd2PJaj7pqIFBf8qPg7qvkW/84j4V3ED/KuYwZ+KYfyr uDn+VSzBv6r2bw11f6wSIZ1gRUjHugtqjBYhHbsIaY8ipONeRUh1uW0xQjpuP0I6thAhtShYpBHS sYuQughpryOkYwsR0rGLkDpHta+OqlGEdOwipEeLkErH2kVIMRepi5C6CKlTPC2g7ptuV5So4/g4 qPsWfbkjRh3HDaKOYybqN4ajjuPmUcexJOpY7V8BdT/LPc8w9RUR+DGh9BsA4hug2w+1rw3o2AcE HQG9bx32v3uo+z2CHccD8PQd7HgrsONyDHFlpG9tPG9xZU/DnalYECTcwE2huUUbXwGFu042RFj1 RWgg283qi8TofI1QrtULgbKYuCHgdFPpr4YGDcM997nuswM6wdV9tlj3WYfmjFL2CWyOaTJIyjcl KKmB6h5iiIj2UNNiUuHeY3vN1K9C5elhqWUEmO2ppTaUa7jV6lclO16oflRFgURNVccFlhS8MlO2 J8VaT0OqiApwPZZ5VWmTtRZKG0FZL9dZRQjVaXGBbIIWs4psyt5LZZNAjVZFluAklNv6EEc19cx7 AcfYKqoWsLA4VsIWbxqD1bSwOKyps41FHVdFoVI5rrroq4pjQJpVmzg79xHZuYrXmoBXrpUXBm/n Mk+17Vz27aqdCyjS4+CbQHZunfayaueiah6ZilHVJTp2bkmXSO1cqA9VO1eCq8+SfuS4+m7Tuk3b i00rw9Wv2bUOV7//UJL9BK10uPruiXvicPUdrj4zbg5X3+Gr6xaoOVx9N+8OV78rhrTD1Xe4+g5X 35RXh6vvcPWfUAWEJVx9F8J2Iex+hLDrcfXlEWx9XH04aaBZPoAAV7/axOHqO1z9vpTQPmVc/YkC alQ0wkKNmugWBE7QUKMmDjWqR6hRk16hRuly2yJq1KR91KiJBdQoi4JFiho1cahRDjWq16hREwuo UROHGuVCV30NXRmhRk0catTRUKOkY+1QozAXqUONcqhRTvG0hKs/6Qiu/kSCq28qWlAQribHwdW3 6HceEeFq0gDhasIgTE1ghKtJc4SriQThqtq/LVx9Yv4pREjHSBFSIpD1FlSgUdhfHyElH+oipL2J kBaz1Y8IqTa37UVIC1ZbjJAWLGBGSG0KFlmENPseFyF1EdK+RkiLFYwZIWVougipc1R75aiaREiL le8ipPYjpPKxdhFSzEXqIqQuQuoUz/Gzyo23K0bUcW/S2cXVt+nLHS/qSAZLO+pYvFMebi7qWPzc IOrI0Aeijlz/Ulz9CPyVRdvn/qyBq4+CYC+CtFdFuEfFvhe/wuPHC2D9Ha5+73H1AWy56zAcjKfT sQBYv/pYs8qHe52F1t8/bqHOJ+DqfPbcHB1cf9+zWqXPvrms1KdEV7nWRzBl8mKf/Ysq1T6CXpSD ozUQ+xxpHYx9Ea2mZT7c9gLqfIA2vQT+rJdwgrChvuBjKkSaSEF3u4hIAh7/dpF8+h0QrBIQbEVS VCtyq4/NlHW1Jrefyhq/KrfDylq9MtdEWaNiwnK0HzUorNvAbgP3bwPX48PW72AHEIuEiaR1544l ACXlq3yAPA7sG98soW+pgFrUXBoEfLj+3XKWQKlU/eke4Osa36onBlWtQfxQuzjvQLrpzXkKN+Rp hQjEHBoGD1QINwwriCdIetOIhCtR6EAFZ7fqropbHgFqpMpXnYsr/STA+VV5R+IW18yigsMsplRz d2CTaT3mfYNN+OvyEwc97aCnHfS0gyB20NO9nHet6281B6r2jAMYRaxjD8srEfdUpUfQ2soxOUvh B41Qn0oAQiWAghxdQLsLuVcg4aqhnULM2Fm9mpEdS2vYNGAExm6PHzBi7rO2hXbe/J5sA5x0cTxI gkquGC6qnXC967PbA2hXuItbH8NdK6ZlCPguDnwdGx63Uk8gOgiR1hmoHZXowelKSv6OUdrAn6dC eLCKWPmHuFWe2twIPF8MNRu7Goj+1kDAe7qKEnxE+H2XLOCSBXqYLFCHxK+UK6ALxY+dpAuC8QNt HBq/Q+PvS+HtE0bjD3wFrKkYC40/8HXLCNWrHmRYU77DmuoR1pTfK6wpXW5bxJpqJupQsaZ8C1hT FgWLFGvKd1hTDmuq11hTvgWsKd9hTblwV1/DXUZYU77Dmjoa1pR0rB3WFOYidVhTDmvKKZ520PjJ vugEGj/dn3Vo/MaiBQUXyz8KGr9Nv/OIuFh+A1wsn8Gl8mFcLL85LpYvwcWq9s/gYs2nyR0NnG5v H3bz9T9XxekGGSAiEL2smIP87aXK6NCOxrVjU2qX80PZGefceKc0IDvfM6MyJUNKbCLvNGv3LP/z DX1H1Cn793OPHn0WS5RssVvKQLqNqGJfrGjxOAQkFnB7YsBvkwG7TQYmZzy6QfSBWhAd+rYh9yEh /21hi98Wqh8QlKd6v95T/bLbBLk8P8njm4TUzeKPZyUj4txbL2d/W66vp8tns1W62GgL8u4D6Woz Xf4Gt92nhRDWb0ZhMLoZvZgOricv/EEwezEmZtwL/2YQRjN/dJMQazDFoFtvth+ISiuzkmHTfVoQ Rbcjmus8PfMejPzYJ4QC/x/PSJeXaXkV7cr34EMOtlUAtgoqrYZgq+EPzwqjrMJL8DL0R8PB5B// OzMYyX/8/I/P7tbzxc0i4T8vffBN9HnBP56dCI8bMgrA2UL2ADxIyB4px/ybNxedB+RMP2e+AMyy O+7ngZlwfeGP2mjFXi695714lWYcTq4TfyY/8oRcRDUjzZgatYiznUDMC+5oRSGrb/9+5o6u6HI7 eG4iotwrVANMZ0lmb33dkT1O5yntmFi+s/U8KfuD9WTPvYd76m/NvVSjZO+khrv6IU3D4by4KA6v ZlPyjLywTIiDe0UUQ64R5kTcbNaER6omqO7ffiM20R3NyFg/bIi5+LJQHbv1/T01j/4/ALMl8f0R BQA= ------=_20080417135952_29866 Content-Type: application/x-gzip; name="slapd.2.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.2.log.gz" H4sICIcuB0gAA3NsYXBkLjIubG9nAOxdbXPbOJL+PPoVKM9UrZxzFIKUrZcapdaxnY3rbMdnOTN1 e3WlokjI5oUitSTl2DuV/34NgJRAEqQo+UWSjUxlIgKNRqPRaDQegMTf67/uot++Toh3dnx42UWh a05spDeajXtUP5wECLeQrmlthHEX73exDtS1XwJzcmsS9+/xv90P0XjywQcmrm1OPoQkuCNB+IHx qtGkweQuGtyQ6NYPo+GDZ47JwOwi+tSLWeyhoKfVbJOMfW/geE7URbRg98MH17dMl5J2OxrWP2Ro nDAiHvK9StQ4pgfhUOQjKnCj0eASTgN3MDGDkAzIfVSXc9uN2XVnfBBl7Jiu829iLy0CrZ/YNa5y ns3ZRcCMK7FRG9rDwdC0vg/mNXWFWtGn40+I5hPPltN+IsF34pIHBITNxkFDx11U75NJRMZDaIDe 2qMd3Nqt3S6o6YtQk5S2ck0xl0EYmUE0nQx8D0qzB8e7QTuW17N8b+Tc7NR6HyE90IkXBQ9dtGOD 6me5NX/4f8SKjlwzDLvId61/uP7QdGsWJYopXKvP9Hh63EV6DVhNrWgamO5XeVFWz7dvlLo1ajb1 Ztt6b2rDznus6db7TssYvTdabe1g1GlZ+6RVswJiRn4QXoBFi5KxdHLtjAm0ajzpsiGkNXELAyMd /5NXdNS/yOY0mm2jqe3/81eN/fk1/gt/amPfdkYOyVfGMh5KKtupffz4EdneZUCi6OHCD8am20W/ zzh8pGpmg2B4p9tefZaxp+3Wfu9Js3Z7GpoVsz19eFfXW/qcnCc9ivz3338vE3ov1QLeQk7GjPHl m8flLRBh0+WDgrOBJpRD7z8i7b6tG2TUsWSjEcbOsRmZQzMkvb/e45+jwPci6iGygzOhOpKP3c9x uaPZwE0KdFGar2udmWF07ttddH317YQmnJv3xyQgo2PwNbddpNG0K2LaXz0X5Px8eNZnZH3rlozN 4ws2ePrTYcieGQMf3JgfgPdJyItdRaYhGZdhaM1mymU08Qu4jFanLbgM/dlcRlFvZ024iC5v0UWU 1Qz8GUtLvU9h+/fKdLPpY3/T5Uv5psJOE1wVsQpnvNmwl7Rslidt3Cy3cvuWLxGmShRNgPM28Dkw nLfpjTZ70cSk/SwIGbOzUmramZeC6cT3o8s/u130x/G5Qb7/8+LC/e/eyrOETvR2epbQXmKWMFov ElhKVV86RSREC+aHhGwF9/5URRdPC7MGZ+eEuSY23eFuunzFE8Ksr9KzQUhXm6yugIRTN2ILRK/3 HsMaHGqDvxISEgSQNzYjcDJ2b2cHReQ+gn9rLAlixUEwdclgGhK2Cq4h+IMbeqPd1BoYG/v7Bw0Y dg0YMajuwBx1Q4JPTvQ1OKfFd7soYXMFXL5Rh1MvKn5xeH6C/pbj8Td0eHl5dnrSh5LhdDLxg4jY FMb5Awaz43voN8RUdB258HPq2BdTthD/Dd0Iv0F/4KSsaRAQz3qYJXgQVF+CTuiKXJJ2OI1uefqp 7TKH5E+jOMGzyT111lFwOjp3vDPiyTLMe1nGofdQkNyPyERIP/WiGeEZRVz6/c/8KbUa4ElXZOI6 lhmBUqAcCe5Ml2f0fev7cEqFOfUsfzxrbD593uDrW3DCdhg/+L6bSjgeHplgMJ8DQlIJfQqhxAnH F1Y26fT4LJcGa5zZ7z4xA+u2H5nW91nS7fg/Sdxh/UmfhLTPXf8G7aLdYmM0RGM89OxlrdHIWWPC RJmjMsdyczQa3IpwAzcP4KfWAdtqNnRUt8B7n954fkBOD/dLTbKQBzfLPCPRLE034njgTBdstlgs IuYintybVrSihFiQMMVnGQH1xn4DGw1jH+QhQQRxG5gRScQRKZopClahjExDdR4Tn9owOFkc+NkJ wujIH098D5JKmjrnwVtWgZHUR0Abo8CnQ2CWdHIPa7rYacwSP0PsO4XZGdLoRN1/8CLzHh4zytE7 Mxe3bFOgaMq7VW2B8nLKy2WMsIXqN3Sbh+8N0b6qYH6t2PxkJUXDyywDQZzMWi0nDriDSeBHvuW7 p96IhtW0XyQeQYcAYeo5/5qSc7ZtIyPRKTMCEXPEuBzaNjyFMkpwLxFxyeQWBhA3fgkVBl35VkSi fkQh2MV6womesqVEHUFcHlzCcvyHH9gzowgeJhHtv4x68AGqD51M/WL+PISvIF0mYFduQ7mNqm4D w+gbgpjE9CoYWhKLiyVEQ7s1Q+gSsH/HA3cRN/ofYGcu+fLtkj9+cWx71jd8YyXuGicI/GDervke SdJPfIMleaJb/uTM979PJ0mrL3yYo62ZJp0geqClkoQzxwNNMQtJNHPhX3LHkiRcEdc37S8wlHKq wmLYeOaEsvimjeredEwCxyoc2y0htOMGDHQyZ3YgEH4NbFLAb18gW9yH+9mosNhb9A/7Z+fEujU9 JxzTzryD4e0HFLWbPcy9CQwq+L/HMy2POxUaOZlDcMj2t6tTeLBJaAXOJOJFuOOAcPOz4xLxGXqO Px5aFphu/Nt1/R/J7+AmnBc6jECHw2lEvjLOYSb1+mGS2CIdqKfHV+RH4ERknvTvSx9cwIOQcAWO 9D62q0/89EBsRTH0Ez85oSmIdexER2x3IKKKDxOPZLnTxKjPnLEThYlnEhoOD2dg0m5i+zYwOPMT 2+XPl2biZgT0N6nmayYYjlNhlLhm3LJkdmKzUh9C/89sXk5nfjHDuJJLx57Ld+lObxxP/J0S/4qM SBAknjN2qamHdJfFiakqaFqa57+mTpC074rQkWLF0lJ4/Lh/Mn+4/DMewWbofvHDaP4EHsAdzx/7 xLoM/EnMFZ6mYAuJp4zPbsRP4G5ZfyVuP4j+MN2k4NzPxQngeQJoQez6YdITyl6f9Y8Oj+bLo3kj sznzPqY5RSXm6eDl01nO5JYE/enMvmna1dnRLUkmB56QKnRlenYqAYY1RHdHrjPzjJB4/OXSDMzx nPDbxAYJrtjATzwu2KAfPMxmN1rtxHcSLnFENGcBk9vcHYOHhqn1mETEmvljgUPGHzdFd1zqSA2R ssSTpnCBCtFzDgJQvlT5UuVLlS/dHl9KIXfjoNHqHLR0vY0phsj8ZWDL1uoQAdsQ94I3nDrhLbGp +6qwbIj9pLxoDmaId6FRjDEkG8WIAnPxBjwYDFu8ongRe3zB3SVwZz7jnrkF03XAudh8MMcsbHoY 2KEWF8EijFLlpKIVEXLohn6sSTIypxQmpYusTzN3xUbNRaza+KBXYs6jkXMvdmuSA4sLM4cFSBDR xTotgkCfEPSkYvKjwvGxWeG0cGOJI7X8X3561x4O6CHkWdrUce1BcoqCHrFgitypudDxvIRp22LW nsDYtwYWtehBwJ2bzY0B1SXUu3tIOIqBdmaddpRlxuYg4BXBTAd080KFNJZXXDw/l5TRpqfZxVzj SauQUHpcpJB6dmakuKXC+CwnmmOF5dUd9S8KCVLDv5zqQaguYzswlXaRxvbSu+iJN+aF4QFWzx4H yXH7AaytnTvQRL0FI5kdcUjlFx75ZwJpaGT32ujw6Ojk8hqNAn+MTi97WG81NPgPdw80DbdRPZVG y/Pi0NUwqukLEPW2JKWLbvyINdyxocFCPsWqGAHTNB3JI5++czCZRvSdB0Y+hLYBn4EHSkg9dFFk 3iDt3tCQSzyEdVoFDeDCbrpQ3EKmcdsfDB36KgEQhJbpjdBoHKH6X8442kWQ2M3mjH/G6dKjQB/l B2bo2ZiPqXo/nV4cAx3tzTF9T8QGRbZrsTRddMdj8Z6RpykwIS2xIGMpCxJJJxBvgxcdhzegaEy1 2eu0eFmmhZE7DW/1LsJNNHyg+Frko9BG7VTDrk76386uU4V5bULjDGR6vvcw9qchYtrfGKMxWouN BlOjCdl0nDObsQN/hitbSP/q6AuC7tHgP/hD/9FyBhhzpwQjx43gdzKDM//ae7ebE+v850+hlAlu HpontohVzI4UQe2hBZMkHRsUqaaugNXS28nUwt9WYZMwU0YykVK+IDgz3JTd7GsZu6HnmgrLk3sn apRaO346a9eZwWINL2fuoLiTQ6o6wepnTBDdQw0cEtKxxEbAxpj5fpGViw+U6wjai0YmxPg2bZTn Q7Pq/Slbyqekt1w/ZK8TUDEfqHSxlkI6j1BJKQXJFoEOsNlyM1NC0LFOh9vUm/mJJPXbBfWhaQ3R sAscDBg4GU9YJBjLleOdlkFSM5v/WLb9lBMrrjCxdp5kYsXLGQ+ubDx6p9RH4meZWF/Vy1uinmaB wHxlUSEikBMv5mvd9vqn55dnJygMR/QFVGFO5j9EenB44kqqwBfjdUceeFHksTFD50BvLh47LL7g y4p8fBGPESk1+FIPFRw0n1trjif5a/w/f/7vLEJYkF39BPxe4ZhdQF7xVPzekgP2xZhUPzO/l/IQ C7Uo9jpfnfJzA2BLv7DFZoxdUvS19ssvYxiBzsQl6M50pySc08y3uoHK92KCPWqiN9EtaqYqOv/K /cgC6XZyhWiY2RMkytRcCJ8sUnEeSkm/fPIoMEXgVkbDYertBD4EgLuMZt5VLw6hbPr7GEo+JZ+S r1QE9Xqiej1RvZ74Nob70q8nqtBPhX4FoV8ZxvA4vPdJmUnBY2M5xAKnUWMjBVn0PtJNhuQcSkDR Xc3gX+7inV31K17Gh11OGpqhy8CeQZhJiB9p++LPW7GBCV3CczzyYzAHRBCG/zSe43gR21AXsmMZ +fMg8gdMEHR9dInScs15h771nQBNJ/52GjTZDEg2Oc8yYDhzCic15p9fi+m7aASL3g6Kxl30HiOT 6pR+MkemYLyKgvGGKhjnFYw1uYaT9EoqxgUqxlpOx4yQiW+TESXuopDvHYymrqAU/u23mU5ykHEB YvyXI6QnA87AqQGXNI0Pb5jg2DS0j8lBm49ehGs/TCdqwoM0F9Wj+AUSzAM0+qKNtTsvRPE8x5sS eWlwd1DDu3fp3KNZb4bd2jvElT3rPYToURgwWlA2QnWbHwCih3YCUKMHOTqiu/7RFILbmBWxIRum moiKRz8VdTtF8ecMsdHV9K5usHixVssJ83UaATP+Ns0V7wKQCr1L2rCHkB848U9eLTqFmMu/oW9B 0R1FX+AQxKcHQ6TtIWplHoVVp/B/jUooVhz3d5wNmoa517N9D2YHiF6yYl7FXhf915RMCdvJPBlP ooc815guqZWb9u33hAF9daKss6T0EGFOAy9Ml7v4dnY2H6chcaEjNsHoO1Kbbxq6VmzzYu7yNp8q nbN5llvZ5o3ntXkmzDpsnlVc2eYZdQWbj7kuY/OSzqpk86yc1ObpHgkGjt2yOlY6uLOAM8SNoXlD eDQp3W8kh4fxgClgRffpf8y7UCCDKDD4LvTYeOISMLo9+YhK6Gx2FLGAJBywXfQuNZT4yQ/48Q/6 GIed7JgI0/EoICRxEbA8mplkzHFXoBICCC3p0UxGNx5MSTYPbLibyPuZmeIyOclOEGMBgtBKEr/G z3FA/06m0SA5nZIcHLFmB0fE3NChemVJ/Oe8XKrYDq+Dn9mMawLNoMPr66t+F4bufywKsx7ldiVe F+Os2xWDSj0dtRc7Y73UGetzZ7yUG9bZqNO22g3rczesv2o3nHTWk7thSXjzRG44xflxbpixeoQb TgXzcjecIVFu+BW7YaxJ/TBetBCU+GExdxk/nCqX88NbtwR8Fj+8iUvApfxw8RJwY84bvdg5T7z0 OU8snLbE0nOeeOVznrj0nGe6ZvGcZ6aXsJbrOEjKnNCV44jKASkHtEYHVBquJXVUdiL7naqRoJ6O BHl48J7tFeVm8vv7ginelKf7RecTx2IgRNtgewNIyJ+ddP96MyeMc23/s+h4p8oRc0TLWN8+u6z+ TT8EoDSnNLd+za3vu/95Lfaz1xRkWvGSsspuHMiII1wv8LRvKYtlk5uq6LvRNGAhgUfnseOL1Hsq pstWF/QVQIgDVxeHxiWVT4Ws2LplTwlUu3dtraTGclzVnWXqzjJ1Z9kLyLfozrKRdtB86i9MPL2v TEHVCgxRYMhWgSEHncrbYtsMhqQOYosX2lV7p1NaovpleI96KfP5+Sx1VV7JK54Fel0/CqJylsOI NnrVqYAFBcmsTXOvch7J9E6VNua77RVrZtlmbplDVTBeGYy3uMO3C99Td4AvfH1a3QGu7gBXd4Cv 9Q5wBf0p6E9Bf88L/RlGp7X/FsA/K//9colPzJJIvWPuO+iVI90nLVi0TZVr5l5B69ePOr2dHAW+ KNhq/ZrbTA+Y13BeTqmuN7k5C0VVANErAogkPbxdiJBayqilzJYvZTA22m9hJaO+S73cuYUVv0u9 /jXD28lRMb5aHW3Spv42e9WyjXxZuxbs4m+/KpZqmlqVvaJV2aLbHdQKTa3Q1ArtBc+Za/iNLNDi a82p16EfzJgE/t3e8tPqClyks+0KfCpPwpvIu2hNuEqv7K3en+tfV21yjlq5qDXf+td8ylEvv55c SWfSZabS/kpL2Ed0gFrZbvbK1rWd0WBo0jtF6L2GO6v1do4P1NdF/BqOLlJnKtUyVy1zn2+Z22mt uMpl6NWY2M7sphb+oZJUejailgfaBUvfr/LkqIDLWJ6chPCP/EjKwq+iPO4Vi9m7HPt6cyS+y9HW D/B7PNL2DyzcHBFdT3+uBbPpIP+tm8xHXaRUeobKkFIZH4peAtEb+7hpaB3hJRD8yJdAdPUdls1Z emyufIu+w8LuuFOBgwocVOBQ8lXsTu7jyp0q31Y21CUb6pKNzbpkQ1JH1fi3qZd/WznFeoVtHmGk dJOhwsYYLx7fu/rDiW6p7dO7QVEfLIAwoQLfTU8Vy49gVlx6e4ae3J6hF9yegZPrMdjEFn8Yfijc +9CS3XmWu2rDhLAZ+uQB0RxbUIg7Vwh0Pr/osN5kvx3g6pIRDMnQBZ4uGAjxoGbg5dyBduotaCcL U1L5hV9IZHO1zj81f3h0dHJ5DdL4Y3R62ZtfrXigaXoT1VNptLzk8oAF1wnoy10noFe21pSxpgrF LWTBCKhYegWMMy641GMs2+d4naG3qCd6rQGUTH35dExgJNpgAe1arMYugvVRCD3ZM0qIF/O1bnv9 0/PLsxMUhiMYmXP2BuI/RHoYU8JjUfipJ9HnE12ki9lVuJ1W5Xt0YwGEe3STwvE1uhszdLBWYexg Ona4Z87vBjrwZ/hmBkr/6uhLyiJ1iMzgD72vTyvCXihBcmtRXQBVeu92c/o8/ylAM7QvrChww7za y9EesWwX+WASO7hhNA4auNGkf3XNgH868BfvoLrnw8zjRA5MD3mBnKVwpWE53AT9IMhF7zkJLOgD OjRgBFI9mVEUhPy+JtEAmd4ZVi4qP7T8CaE3tNAvjgAfruTeTkbJO3lWtJoeraTMhSx9FzdF0/gt UvymK46qUYZgJ2nXl/IiBzrOuBG6li/kRO6dqLG4sgqfvElL0Tl4BiksyXtVqWrp++ud526+bIMl 5cdxU38eGVba+0l1i7a/vGRPatZzUhHGTgpQ71LgXJp0jullPwEiu6QeBkB+cu1kzSIzSaqLkBTm tJ2Y09O+NdfEbWMrTmUWLbAeeVoTHCfzogHZk8w2krCzhFoai5bQV444X4JHUShbpp29xfpb/0nD 15ajzv+pk5Pr19z2O818b5S2SdpFr0ULyzRLnSTcxpOE5b26xScG1Smk7TiFxNYY95G8uv2D9oGs OnV0aVPm/s2VTx1dUjCSgpEWwkhVwPbSCCG9dYnbreWR5eeFsrSmgrIwdGDoeJVXJGX08jVJWYnq q5IX4lIIapXqaa+KLtcPBL22HAXPKGBr/Zp7PS5UAnCVt00Ocb0yfSzXPAV2bSvYVdavCu5ScNe6 4K5m40DrtJuagrs2OSLYXPkU3KXgLgV3rffUlN5e+SX/V4M06T8huIJI4WYC06PvVV0dVCgmXyRU KFh9rbAWZoVgVBVV7i2h9fVDOa8tRwEsCppav+behs+VwFaV2i1Hr96QylZqugK4thXgqtC9CudS ONcacS7cbGtY4VybHF5srnwK51I4l8K5lsa5Kh3zKt8bSx300pqrHPSqJEWlAEYURgeTXF4WS734 q4b2axjaT3ta0miXf6brDUDYxk9/QjzKqCosUF5CjgiUl6kOBrwgn0KkeoHG9qrpdf147mvLUSir wqfXr7nX51AlWPSiNsph6FeqmWWbqdDmbUWby3tWAc0KaF4n0NxuNvcV0LzJccLmyqeAZoVGKTTq eYDmRVFDCmo2OoZCd9V4eqPj6UnR3f1Ou/nW0d3mT88Jq662C4nlC+1C8upr7GdnUQjiFitmb6Hm 1g91vrYcBUAq6Hb9mttubymBaUvaI0doX4EClmiSAmK3FYgt7FSFwSoMdo0YrK4ZhrQ6hcFuyoS/ ufIpDFZhRgozeh4MtiRgEOHX/U67vcJdQU93maRBL5Ps/H9739rjxnG0+/nVrxjsgYFdZyVx7iQP 1vBaUhIZsWR4JQRIECy45NCizOXsS3Jl6wT+76d7LuRcume6p6vnsqw4iSVOd/W9uqqequrqxyQn Io9J1r7haZdexJtUvYhnC5vdHK/yQTxb12OS97PN7Ndge7mYXwV/kJt7HdA/zsN7BnPnlmXye25p 4StANwXePc2fk8u6OcsuVvblSW4VwUcuxepzLia77mFKZ6LwMqUzKeR3LTxEm+1C+WlK0jTzbcru TqLLO4jZv1CqSzI6YzlbrclNQIayCckAz28e53Ny3+R6P1/TkIlfpwbtZvSybjInO8q1aE9piaBY hUz3IrqmCjUyMxo9kZk8Bpz99eM7uvnyM0R5ONlas/0+IBdSRDPuV4l2vg+MliNuG31eIIqGEtHT kIiAH0ezTjqhdO6pSfPPu8Ud3ypaVbYsWVSVFpMLWqDAlCwq5+Sybs66h5vwCwhMVytpC4jXDSXi ejGY3b+yDaing6jpYhm6+ElC/eGWZao/3NLCyks1hTL0UTEWxDsRKe545gYtERRWoXos5YV5AmMX Hw7iw0PAh5lSe+9udQCJpmJwl7VCQtYqOFxRQZ+llD8ntZZSwjVuyX9XmxXZpm/J/6/otqeWiB9e /2AsEv6C+xT3abf7lHlL9HmORWaoMByp4ffu8EmofriMuIy4jN0vI/U0jNwD9rPt/vHhNtyQgtFf qABwVqpxlooLNCZsWl/g99l2Qyk9Nzah8fqH21fv3/317d+M5WodGMvwcbMwVhtjsdoG8324/Wq8 eLm4mxrn1sWLZ2/+eCA/Gg9huDUegu2SjmMzDyKUbve4XK7+YLX+It98Kr2wipKvd8HmS1TynDZ8 Ue0KQQnfh0Q+CrfHBpIf6BAXq93sbh0s/m/i0vi4DdLPx37sQyPY0GIlv9AqXW7QbqFlhNFLEKLI czP+8+N2ffsw2+6CW1KP6WNiv7yIi+5mu3WEzt/uCj8kf6WdW8Vy7G2CkMVfNsHvt0dI1DDJP6Mj +kQXNPM56WP899t9eBtjjB9e/Wzk+3WkvQvJYdpT5D3+7YGMebYNSr+XiW4jMDrnE5PQffiyT8tP jeUigvX391ODLMeMTivZBrJOOg6FjU230kvHNpleOlGXoolaBEtKjDCLGGdfPq4z07+LnF4Ps1/y kuE4yfx3lfk99WNw8i5N6STmkWj/zpqNEhjPLCHRua9HJNqMvVvr8Oh8bQo/mhlsNf4qjEfbcHi0 U8aj487U4NHmEY82ofDouGFRPDouXY9Hp1Ql8GjWYong0XE9roceerYP3LPd9zxMY91rgKK//UPP dvTjQj+ubv24PPekX2sj1+17ctmuZ1+v/jv6kwr+D9vwy6UknilLgglzyhIRRj/7RZjnOSa9DJcN V697f6k+f0F3EHSk6d6RBnmymJOO/DwxfXdwuoX9gprOOLoL9dtdiGVPd5rY082e2tNNhj3d49jT PQl7usmzp3sle3ptSG41VpMPwrMaPL1TUm9YVk3hCBirSnHKU84pTswA1+D6OpHAOKRGBlm6o/Kb KUa28/a3jK5LwTiirl+ybfhpuUUESXKK7G6jeL8pVbGTv4VbcgK/i/+anB/6Q7z61ACS7mGizB2M 4AnFi0ypzMYepTbkwodpYoZIP8cHLj7CZWjjMHGFLzkNMTXSkC1I8cZoc9CFnRqbBQdvLRcNyS4+ O988rtcXZ5fGbE+zzhxsowlAu0nMWQyKFylJUmi1YJcgm/hQYmqQVpP4yykFed+9//DX9x/fvZ4a 78KYh9HT+Fvw9SXFQY2H2WqbgL/nz+3RZDxJOVFyIsh+fnjc3y5X6z2ZGDKU2Mg+p4bzq28vznJf dyvas+in+I/HerlqiRXs7nG1Ppw9shOM6w8ffrmZGt8af6ljd0rIFgPYMs1JEdliRV56dXhX2WKX +6qEd5XtdsPDu3TY7XqJd8nY7Srwrj6AvMxN745GizEX5M19ld70+dpFkDf+2oWxmrHp4850APLG DQsbq6PSAsbqhKqMsZqxWELG6qieoLGa0QaMyJWnrCRyxaSai1z5E8UUuYpFUORCkevpiFweU+Ri uhhlDwIDJM1+Vbp9GFDp4G4fLVBpH28fKai04e0jC5WOLeHrp1OoVBES7Z3DdRexR90DcfhFP7TZ 57gK8OQIJx5Tguve/7FrXffe3WunnJYGIVAICDRRbmPxspfKcC1Iy8vYabJR2mQEUbBWqf+9nIFs i7TfRFcw2daPbMvHkhFsutosgj8Suwj5ck4NPQwSRtR94cKp+Zm2EBcPNvNwEZyP/ojV65F5wZvm aAXI/xH9MFLt4+IRissYWuNtUO92XYm8Aqt4edKo4qGKh1969QVFfRT1+z92XHdU8VDFQxVPh4qX wIFzigARnSTYTY3InZKlAGTlfGM3Dx+CKyunr6wrlajgfx9Jn/dfM40Z54fY6YMmxSg2zZYzNuE+ 1lmCxbPjWHPFoycZlqvtbk/+TZG1K1OnTnHExeP8/m455b+bT/nvlB5riEpwX2twoN5NcfDdFF3X EPy7KU5X76akdpOYSJJpgVu1WWfnn65u3v708z/eGLvd8mqU6bNtxH+oIbEPa0rwjrzT6MQLvv4y qnr8xXRzc1V+/WWUPP7SrRNMgd52fjVi5UmSjW0ZdPokzD0y9NwjtuM6mHuk1zGd/e0f5h7B3COY e6TBq5qsMEn09URfz6fl6+lORqfg6xk+Xv0chImuUK3mVxRlxPLzCwvG7AMQeKgiwE5DUzEdl9Fn Hk2EExHMQ1AHwTxcd7B1H+zdVEzTUzUORjqeHg9b4EYtDIV/XyJgiIBhu4DhsSi1lC5C0jqlFNlW jDjSEtrKnHVXrTiAhWWqODclF9bqsi04s1oUO6joRDQ2sjOIqrYLtvtbQp/q0d+UJ4Hh/2rx/F+J RnxWMaE8T9j6avU+sdZF9VqyX2bADCSYgaTzDCSgvtLuxDwFX+k+y2NoIjnxL6gqo6rc/7HjuqOJ BE0kaCJBE0nPTCTPCzYSqwMbSZ0fC+rDqA8PQh/2PDV1mJNsr6XE0FZ9YmgLKkuhlWYptDrJUihp SeBpYZy4CvbPdxIJE5lTYqZjjljr4+YQ7ZF6pvvM1zxLEzib78nVsf5q0C8Lfih/kpC9wlbatj8j uo6h69ggXMfsyovgCbmO/W0bPj7shJQwXlGmEsYrLKyEKRP4tYoAzy7KnY7YLsqjiXZRtHGirQtt nLjuPBvnMO+Zso2TPw6mjbO3wxa4HQtD4d99aONEG2cPbZzZMlYnvmK8U1r2FeMdLpavWEXZFnzF 7NhXjNsJpq+YLegrZvN8xezY6Ys3oTxfsfpq9b5i9kX1Wl4JvIgnH5WfNQt5nin/Th7XKmSnViHu rKBVCK1CaBViecudxOMRhDVcrx/vNyvjercL56sZPRqXcoC9HAGmiCtHQljw1UR2FpOd5ck28s2T nPzYMiXXPtqr0F6Fdgu0V+G68+xVeANW28Fk54dpHXvCk9xYHihMkey9jrY4tMW1aouzwWxx2TJ2 J/Y6OV5QtuLJHVaWbU+aQgsWPye2+El2jWkHdIxvKupwqnxfVYVhRHR4RkQntgbKrTLPtNiUWL3B 0blouhmZ9j4ntfdJdhWtgGgFRCsg430hz5yciBnw7WZJ/xY5r34I5p824Tr89avxevVltZMX1hWo MSV3BXrCYnwbbawybeyPbSwybTSyI6qsXmxUVOgZWhjR9og2KLQ94rrL2x7x2lVto2yvVJpTpvES VwlGcClMq5LMgdZPtH62av10WrV+Zss4nVhIFdhK2VyqcNRZtlM1ci0YUt3YkKrST6aJ1JW3qrrS VlWXZ1V1Y0Oows7gmVhBKNfbW90LkK3NNL66qfFVZRBoiUVLLFpiy5ZY06l+6v2pWGKJLHZNJuZm P1suLyWCikTrMUVKoZrC4iYsNbpNdik1+Thf4fmMn+sSag3tnWgjbc1Wli38w2x7N9vOjB8Dwo0j OQLQMAFNnznBoC0ILwp8q+WFBF6b8uL/ONsExuswuFR2plMixlzW5uSE11CxifKCqcwnY3XCT5uU GuyhBKLMXjcY2uKLCNgeY0Wh1oB15Wx/M96s16twD3L+lOhxri4FihLXm2orrCtQaW5ZnJLI/8a1 8SPRoHaGCcQwFWly+KYiVQn2CdESi4sqz3XdAloaeCpoAwJLq9pEw3UGabZu0dXXh7EDgs1mtQy2 xs39av8J5gQrkmSvsiJR8XWFaIixksrzXF671+E23H/6SnTu4AsRhkEWT5kmc/WUqQovH0xL5fUD mOvyAn7c7h7XM+PvpNxuT3RTiAVUpslcQGWqwgsI01J5AQHmmmEn+BxuN/qsBHDU2TYCOPriFgLg Nhn2Acg1QTeqcnk0jjVbmruk1c+HVuF9faCb4WyBEzeRfaZNLOImQGJSlWjy1ggNZSJLSdtLpl3L cQRqgHsVobksvvZIK8GhFahDqUSWyzvRaFZmqLQlcmcdW4Ljq4qkhZYRTWeNV9vSx3pB2+HtAzSg FVY3bWiXNgR2lBUpc1YQzWjlRVwkLe2OLUGtojJpzjKiMa28jI9xS58yLUEtozJpnnUBTWqydoWo Td1WBbhGvnu22PwURVc8d0fP/uesygR1Fn8HbP3s2LqZtK4sImrtpSM4RwCjOLTppySb2iTg++Ql FGHUafj+mTFFZbaoYTWTrilfvBq65qR7W0HP1rCWVnKgIU2p+hZWVS7WMIE2i6SqBna6/ezvSj+3 J4LXk3LXizcB1Fw0v+OOk2CL3tEAjcHuBYBbIe2ZA3vPKF4Kaa9s0OkC6tRzG0jCgupPf2UEUyOL Br7gj7NpAWsWevrp67z9oAT1AtvXIpNB9/W5B7v+4B3UKvgA6EBtSOKA3dSinAL27zmTiTbfj4Bd 07kRtRhkNO5ITQYkHZsTtKsnHnl64u6FuO79HzuuO667jnU/nRQc5X0iOHbmnhn6vMkmGykMXzB7 CGYuxMyFrWYudHuXuTBbxm0/u6Eo4yhsItEjXspYKFGxhdyE3tQQ7xEzpaAXZSHk1eFU+b6qCiML ocfLQuhdRv0XWkFevkFJGvWZBb0LyW3FzCHoRTkEhTuG2QIxWyBmC2RkCzQt+2SyBR5dNBvK3jIE OEK4DAkJLUYL2axJWDm1oNTkpzkGZdrHZIOYbLCTZIMYfzDwNB4Y0Tf4NFgnHc7e94yPGGFXWK/h pKjC+PQBpXPECLoBpqM6cTARY3mfYiwvStRPJEfGScvVw0gThdL1wPNXoIw9uBxQKGkPLVeFdDg+ YFxdj4OzmBFECnEuAPGRPvRkDSw+FDjUAy5uF3oXg3XsGK2lmu4CrEsO7CICRYligO/gA3x7FAF2 4hDwiRvucN37P3Zcd1x3HeuOrnTVe0l2fjghQk92khs7FpbCiOQcBDGeCOOJWo0n8gYZT5Qt43UU cyTDd1jBRzKMgR2FJEmhhXAkPw1HkuoaM8jIl49L8qXjknxeXJKfxhTJrDIvQKkpsfpIJf+i6WZk hiz5x5Alqa5i7BLGLmHsEiN2yXJOJXYJn2xrpmg8rYfidO+LSx3vz3UfqoRf8As7ZG3oWVgwe01T +1M32Wv6bDNGezniJLjusOuOYntfxHbGM+Owa4MvbQ9AgWrjpW1ElxBdagld8p8supQt43eCQIEy vjJABZt9nIFfQTfQArw1juEt4MTsLChrHKFfCmQ5VL/XRpVbhQG7jXmw2zhGykC3Ng+V09RWPWg3 vtB0fpmY3jjF9GAHipAfQn4I+bHSFY79U4H88B1lWavBk3m7We9uuIR/ELp7cAe/4BcE+RDkQ5AP wR4E+XDdWwT5UFDvWFBngHuQa8KG9nDVe6EqFSE9SK0GAT0E9FoF9MYnDehly4y7Af3g2CID8gN8 cZcF+IGSbwHumyRwH+RDxCwAbaIF7JtoAfsm0mDfhAf2TRIADm5L86A+LS3VA32TCy1nlgnzTQ4w H+AgEeRDkA9BPhbIZzonAvJhunNdTwe1nVhdx9peQuVo7x6WwS9P7wtCbQi1IdSGkAtCbbju7aw7 issDfGkTX3hqVRHR9cITwmAIg7UEg00QBquBwbJlJp1AZcrMsQyQqT9LwIDFIIi2AIbNYjAM4GUG Fqw0iyAwOUocQt9DEpIBumY8oMscxfiT8o7k4VuQDdTDWrMLwPPFBLNmKZilPiCEsBDCQgiLCWGp IVjxvi9DT9fXifGVQ3NkbILfj4uZKWZED9Ec144eY7L9LtlnKy1Hl5XdbVJkd0ta2YRTumWSv4Vb IuZ+F/81OeD0h3i26bG+TSmfHzdnQvEiU2p+OGlkSCbzwzQ5Vulnsml3wS1n4laHiVMD/3hWcfbP 9+yf72poE8Z9Hy5WS3JP1olNLHHlWJ/u72C7oYjUUR/gES1V2QYP69k8iDfyH/tXN+/4t5Z5UU12 ajw+UIE/ew+Z0T3UwaVS3GFmuoUiqo+bOyICRIuzXD/uPllUVL/7SlWgfWjsFobpcfbjbL4n+tD6 q0G/LJ4dP1E2cW66F4yfiDwZ7qPxkYlxsgXo0Y1LkBHNf6NMehluiXjyQC410uuovDhDysbN5mpF c+vQqaWa1kEdLcI+K/KfOwbyc4A8aw01AlaXhiYU0GpMPLc8uEvmiG9+efV3g6WQW4SPkf+M6D88 NkELxMob0aLDu89kI7wissHu6tuL0nr89GfKLsgw6VrO91vC70vLVs2YsnWnRki21Jn5wn7hvTBf OPR/1sgm/5qQ/5lnxvkm3My3q/2KyDvlDq0gWSBZp0y/NmRnbudkbegZJyeaztNsv9+ST98af8lt 4Gj+uVaRxBBiLAJydRB68WRfnRUm+6xMkjZ3RRvrsdHmgbBCwpeDnNEmM7ILCROMGelaET9MKkRj jDkxNZOwOXeWaY7HTp5tunRZ+SSDP1b7F/WtVqoj2fbdia72+Zn6c+07I03tyypp+VnxNPVKyRUy t3E8y9bRR1HYO98b07G0zNhc/h2IXLdMy9fULeBUNrleW462XkN65uZnemJq6jOAASbfU3PcoKcc cTu5/h6ubBlpO1c00sOnsX5Hrl0ikZKLxYwrF3peOvG5K/jNNb2Ef3lz8/EfH/JkiL5LhrQKduSn uBO9krtdntSd/QuluqSDTuzKRqRWk7Gd38TWwtwA5utwRzpF9bPZ4ivtXjJVu8UVJUH6SosExTpk IRaRXaBYJTPVFEdJFaDsrx/f/fD23ev8LO1i5Z5IRsH9wz4iGvesTDzfC1bby6jvUYHFs92abJ/1 akfmjcwS0apWX4igck6f44lUj9z3c7rZpi9fHsxw08nItF7GU3blRpQd4/rVqzc/fyCKWXhvvP35 ijDPFyPyjzn1RiPbM85zv1EC5T3jsH7KbSO3vI2cqm3kCm8ja1KpvbmxYkzW7qC65kTz+z1HOGe5 8mV9WAn15epXBnIaf2DCpvEnYcy0eXGe423S6cvcCLLzRPdyyoLj72fGfbD/FJKtYo2fJdM4Nb4E W3pVXNkVhevpzj9d3bz96ed/vDF2O6J0ZMgTnhf9IVue8L/MX3m82U0tIUC82YyY6sRnseaCFO3k hpxhyWltDhfu8viYrlN/ftSsH0/qsMRWjMyuROuFXuuFW7JeZCZfzmrhsqwWVWxETcSDIxYZnu+D BZF6g7QCXVPOkjr0ZF9Z9QKnxRI4bb/I1a6+o8f/K9kjwcPa2EZmajsBlQgz2ie248ftOkEayACY sof9MgEydrPdOmL1t7vCDxlr82pDtuRsncIi8ZdN8HvBPp3iWxSwIrthk/mc9DH+++0+vI1hyQ+v fjby/TrSJrrFbwEpQ+SvGDohY55tg9LvZaLbSODMiUoJ3Ycv+7T8lAhdlIixv58az01jRqd1mg4h 6j6RRGnhaYqHLx/XmUnZBVty9x7mpHRYOeJM7hQfVrqkvLGAZce2RgkOZZaB5exXeWA5V5viiGYW JI2+CgPLNhywPGYAy1FnaoBl8wgsm2DActSwMLAclRYAlhOqMsAyY7GEgOWoniCwzGhDWJKxKnHl HOUcrsxUDKrg5IiUApycO1FsOLlQBARONlM42ewETk5FgDLomBpgyPoSEfY2lZTSW3x+uMWzX3cr Oq/RT/Efj/Vy1RKU8+5xtT6YesjMGNcfPvxyE8sZNVeOEt9lsF3TLRn6sjeslb9h+dyY4eaT/Xrk xlJ8mOHgMzg+rMXBp498WMrBh8+H5c2CI45QiBsZN3KHG7ny2pf1VLNdUYGi4KiWVdeyN2budzE3 KY4L1nv2z3sOFf7Vi4cSD6XuQwmIWXgRZuFVYxZjIczCY/2Uu+O8stHVqzK6esKcxfEqba6eLsyi IqK0ZJnllmUaa6vDW9UDZKFCbGXm5LJuzrKLlQU4uFUEsRSx+mnYUUxksYliI7hVm3VWDKCpIJFg NvwSPJOp1x2M4+XmShzG6ZKjmJ5Vz1LQiRWdWIcKA3nwTqzewJxY+ZHHr27eiQQe02IN447NEQYe AwQe5+ZwJBed7DUCEXu8n1cbsR3NLAezp5tOtWkObK6BHeBBt6gizm2OvYZIt2WVJL8eL6Ge46Jn f+BdMcS7oqmD8oivPwk6KPdRpZLyT/ZU/JO9yOHXk/FPTqpkZrrkn+w19k/OEmf4Jxfaji1yiX8y CxXynrqrkMdxFfJ4RGVchbxeuAo5Y2acLz8HBcNVKPtVKQcFw1VILgcFHIhgN81BocVVqI85KKRc hRrmoAB2FcpRVnMVAsw8wXMVKhRBV6Gn5CrkuWUNpexhUcuNe50RqAfcGDMCdZgRyJmIcmNMCPR0 EwLVIAblq6ClVDUsjcZpotGYPdVoTE0aTbrVUKNpQaOBy6pnu6jRoEaDGg1qNF1qNM6gNZoecGPU aDrUaOyx31Cl6Z3r+L//+R9Fn3I8tHhoh3BoJ+TfSnaIwTyt+fbD60ZvqgnVY7qHC9UUdvSGpbba L6ReaGs6n7E7uVBr+Cxlt4819vkhMXxEDfIRtc3sPvj49rXUhJ3gTqGF5aeKUQMwFSVrOUDJlxYQ kDpzyQHpC28S6DbL2wp0TTgbEXxbMdr4kfy0M66NH4nUvCPyOfzuhW6htIFhG2DuYdgmhLexhmbL Oxl6fTibWcdGYzUTftoYr8NAx0aGIl3ewTCU2VsXhrb4ngVsj7FZodaAt0tht89JS6Gl8ijHyC7K XdTm50Obq0yb+2Obi0yb8i/GAjbCWXgUARrvgM9RszPj87FZLZsAth3ePsAbVGTJaXuLuD09aw3T wHfPFpuforCd5+7o2f/UZESIvgOymrNj67YG4hFF2ENx7LGvh3xMFGZxj511tM0udE+fO57YNgRr +WRNZyje4rrjup8U6ljeJ4JjZ+6Zoc+bLL5aGL4gYFrebzePdzTO9X7GmJvDN+b4D1+Fx5ivUV7/ TF+Ya9xmX3eMvha6s8t1p68JEfjpED5+fPtaJCFOVA4z4gw1y8Hx1WO5lDjJ/pktFlHOPCF2V9j6 oozpuFujDS1VMdm/UcUpzZeV5BiYGq9/uH33/sNf339893pqvAvjQVKPsN+Cry/Jlp0ZD7PV1liG j5uFcf7cHk3Gk3xH6OCN0R93cQI/sR5FU0AO5e2KaDbb/S1pjBxu45uKOpwq31dVyQ772M3o0dXo lMYP9dEv54ZpXkYDEFrCMyOaU2UiaWwK/8nvuwuJjQWYHtWPkjH4lelRPV8oParP+imXecMvZ97w qzJv+FDpUX1Mj6pLvodPj+oPKT2qbGe7S4/qd5ce1c/NlXh61C45Sl16VB/To1YyAubpZ4wY06Ny WpILdpZPj+rDp0f1MT2quDJoojLYljKYK8Sb6aprE3Oogm78plN92jlUm8+blrdCR07THKqOVRQP e7yEw8mhihfKE75QgBKt+nlBTSbR6sH+Sf4vWBhRzH1sukoVXzFrGLBpFoOJMZj4SQQTm6Y7PpFo 4ry7p0nZxfX68X6zMq53u3C+ihyGlLxUG9AUcExtQLVhOIrOlvKecVFLs7ilWb4lAedHHWt7yfCZ bdBLjIjGL11HhV+TG6CJI45QPSbDEqopzCrEqZUdWATHznRuGfq80ZtfwYFJqDo6SqKjJK57v8eu e91RkNYlSNeFcjeaa4H4PVxDaBWlMhavkV6BjsPoONyu4zCa9gdh2gfyLlbms2XPY2Wux/JKhiDa gsfyPPapU+8t0zV5Hnkzy1HiEPoekhC3CsNZes51lrZiP2flHcl1pAZsoN7Jen4BeL6YWNg8xcLU B4Q4GeJkiJOxcDL/VLLuYmoXICvA8DPKaN8cLNRNPVNN96AMfnl6XxBoQ6ANgTYEXBBow3XvAmhD Sfyp51nGTJsD0YtaybSJUB9CfW1BfRZCfb2C+nKFeFPdJh6oyrPrwEHlVKm1SCFACy3AhgsWbKie R5aF2C0iDFGBLIfq99qoyqCLCy66aLPAP9X9zYUadbVWjzsuWLgjyDlmgpALNgipPFREJBGRRESS hUiap4NIboI0XT+Al2pTYhzVtik5CVuG9iY+0yaS9OmgYXmNFy5FBpv2C1FA/IL4IOKDiA/2AytB nAjxQVx3aHwQ5eLmTbDwvObzycHuTnqBQLSKEtbWXCNAXA1xtXZxNRtxteHharlCvLnWDb41Zc4s oK0px2SDagrUWgDQghRAa9xNJgAVQAXcBVABd4E0JBZwITEnBama7jou/AVBuR7qCi4gTg0T1gqO sFbjISCEhRAWQlgsCGtknwqEFWw2K7J3jJv71f4TjD6oSJKtFSoSFVfe22roc9rQLm0IEuBSXdYE 5lLsI4Jd+AUhLYS0ENJCaONpQBt9Hjuuu0ZIC+VkDXIyA+pSnmc24IXLp037KAJhyjoDwmEIh7UL hzkIhz1ROCxXiDfZmjEzRZ7OQM4UWSwTP1On2QKKtkxQNNXOMpGrJRSWtoTC0pbSWNqSi6W5CeKl uBu5iBoc/XpcbXkBd7KY6NrygK6pDgcxNsTYEGNjYWyWcyoYW/hpkyL0wClSYCizVVEY2uIGhZbb +0zbSzxxtGWlBFr5BI2D6TGCcvgFQTkE5RCUQ3DmaYAzfR47rrtGUA4F65YFawZgB7UGbNwOV7gT VaaI6UFpHgjtIbTXLrTnIrR3ytBerhBvtjXjfzC3AQMGhOHKTDQQjHQLoKA5SlBBoE4zoTiy63Wk pSRkdeSlTMjKIId0FjnQoZdAezAbmYsggjdTCySaowvwI8rCEynLTPBEoMEhrIiwIsKKZVjRc6wT QRX7bPhpx3QkMyeXddal7vGT0/mCFly04PZ/7LjuuO647rDrjtZetPbqtPZ6aO1Fa2+NtTdXiDfd ek3CXEZdNvJy2SvLbFtVuA1DrBkbYvndYBsrTeMbMROlyTVR+rHtkDuxXKOjQMV6M6J5UbOs84P9 iir956Z/wfiJrEq4j/YZYW1+tgC1Y8QlyM6a/0bXZhluyWgeHvdGuDGi8qImEjdjIOHWoVSXC2oN i3cJ3dubkOzu85t4MnIDmK/DHenU1KAd/Uq7F50W39gtrigJ0ldaJCjWIVfbIjJ/Fas8S/5CDhvl GrePmzuydLlfP7774e271/lZohcktb7u98H9wz4iGvesTDzfC1bby6jvUYEF37JrppZd/g5CWy3a atFWy0yz5p6MsXb7m/FmvV6Fe5DkA0r0OLqjAkUJ3bqNVu5pK8GhFcC8amrrmBqhFXqHhmr8gsEb GLyBwRtoEn4aJuE+jx3XXee6o0gM0wprHyrNLWev4npBKhels6OkFSDUhlBbu1Cbj1AbQm0QUFuu EG++deNxCjcHC7NT4OVsXE+NYBvYn5VifypdZeODFlRiNkIJKDNbQkkqwMLiopfjFIRU2IZchBOI eD0Kal0AHSYm0GYdgTaVgSAYh2AcgnEMMG7kn0o+to9bckJnxt8JX9gR2QJEm1WmydRulKkKa0Xt tfQYt/Qp0xIgQKe+tjFIp9xLBOrwC8JxCMchHIewzLBgmf6OHddd37qjUKxLKC7vS4C5Zu5fXEO9 6kZhugF0BITtELZrF7YbI2yHsF1rsF2uEG/C9WJ7yldNGd9TZvwsjA+CaBs4nx3jfOrdZeNqNhjW Z4NhfbY81mdzsb5JDMcpb0su3gfYQD3mZ18AHjIm7menuJ/6gBD7Q+wPsT8W9jdWg/7ifV/G7K6v E3s2h+bI2AS/HxczU8yI/EiOa0ePMdl+l+yzlZajy8ruNimyu41imKd0yyR/C7dEc/gu/mtywOkP 8WzTY32bUj4/bs6E4kWm1DGgmAzJZH6YJscq/Uw27S645Uzc6jBxaqgpD2hg/3xfTeThcX8bS2xE AjgP7z6Tgc0JM9hdfXtxlvu6W9Hlin6K/3isl6t2xutBj9W3B7Jk5BIMcupbPKpXdFQXMsrYBPhG ok3fh4vVkkgtdXIsa4zH+pTXBNsNhVWP88UjWqqyDR7Ws3kQM5U/9q9u3vHfcqS5E6rITo3HBzqF 2ecZ46D7Di744mk30+McUU2yFNBNvVw/7j5ZVBG9+0q3yD40dguiTHF4w2y+J+r++qtBvyye7dak 0JrcCMGG0CIfV1/IDJzTBBCRJSb3/ZySnL58ebjZp+RKt17GCRquxlEeA8+4fvXqzc8fCP3w3nj7 85Vp+S9G5B9z6o1G3sQ4z/1GCZQzVHisn3JJK8blpBVeVdKKsfAV5Xi8rBXJKKP1XYS3hxXI8dP7 PYflsQDXrD9BhQ29ZPLilmWawKoN+uqQgL4sm/w5qc2ymV0smr4jle35GWOIvLH/FJItbI2fJcs7 Nb4EW5oh+cqWq5+aBmIii02kunCrNuvs/NPVzduffv7HG2O3W16NMn22jfgPNSQIp6jJocNhcuNG PC5XNJJEp7GEQy4pcgKvJn5cN8fVTKfI1rI9+OXNzcd/fMjVjpvrFUcxPauepVCr3UEMKXprrMh/ 7qr4Ry3TEOAUDQ83aDUmI2CefsaIb3559XeDJYhZRFYm/xnRf3iCIC2Qyo5ZKYuInKX1+OnPP4/i I13L+X5LdIrSslULv9m6UyMkW+rMfGG/8F6YLxz6P2tkk39NyP9MIktuws18u9qvyM1b7tBKSsy+ q5a+yTpl+rUhO3M7J2tDTxc5xXSeZvv9lnz61vhLbgNH88+VhhMB2FgERD0h9OLJvjorTPZZmSRt 7oo2VsWOTDh2ZEUMxSSyX5kfuSafH5HuvrmmHc6wpQMVon8SoXQV7HrJoqQydXkqmbrGUeorTyZT V1IlM9OlTF3jxpm6ssQZmboKbccSbpKpC1B2ngjIzv6IKTtffUcvjq+EOxBVyNhGqksi/JOfSIfi Pz9u14klgKwkszP2y8TQsJvt1pEocbsr/JDRQFYbwoxm69RsEX/ZBL8XdJbU/kQNSuT8bzKfkz7G f7/dh7ex2fDDq5+NfL+OtHfh/LdgT1GgxLRBxjzbBqXfy0S30Q7MzV1C9+HLPi0/JasQQUz7+6lB NLkZndZpOoSo+2Rr0sLT1F69fFxnJmUXbInAeJiTEpvm6AY5/p1yGmec5zR+neHXrDT8mkqGXzOy 85nNDb82mOHXcRoafs2j4dd80obfdLEUDb/y99NE8n6aQCnlE11KeZ/99Ab49EV2sbJ6bkVOVCGl XKw+UymvzqQq3VkxpbyCRKKUy+f4nHSulE/glXJ9HMXzuTLvcTCRUj5blDlKqlmVi9KNZURPs87u yQxdGz+Se2BnWA0cD8ut/veff3IjOvBbH77VXSjKu4L1wLAqTfbTwsr7V/jZ6NZa+hy1NDM+H1sC jAhUX9v4AlXu5Xc5vnT9+nB1KffwrDJezDiGIZWBtsrIp8qaNbFPlXUxauxJRI2VX6RVPSPMt2gB iEI7RlJiB1V0mtgUHfLvLaENdKiPgmEDhlB6hFi1Oye82CwvWCd5cli5u2yPUwfMC9YB84J15L1g HZ4XrDVK3vpVPyVsL1jIBuq9YJ0LoENW6XuXWpCEEU7hp1DNvFcf01zTkjOfWe/MZ0I585mpM5/Z iTNfqpWU3YwS9zG6vjq87mLJ43G1XqQtkZkxrj98+OUmxg9rAAUlqzrDqG56btGqnsVPrDx+MlAn 6x7Y2tHJukMna2eCPtboY13j5QHvceqLeZxyw28cQCtFlY1cg6eIK2kkN/MuIm5vreTt+YVM5P1C JlnfjAnTL2TS2C9kUu0XUmhbl1+IORJxDLGFHUOcJo4hZk8dQ0xNjiEpT0fHkBYcQ+AiAp2mEYHo GKLbMcQcSd5QpoS0W+0aQjgoBmwMJmAjXa1hRGxI97a7kI20qx26h6Rd4PuHoE0SbZJok+TYJJ1B 2yR7IOahTXLIYl5dEF18u2AUHUbRDTWKLt3BkGF0OZqHOLoeJ73g5yx8dfNOJGUhLdYwY6E1woyF mLGwXxkLc5uNN5mVOp803NFj7gCZEoecdth5OxaN0tPcB4sVaTytQG8mzsXkUAHnyvbG9UiTxYpJ dkaTosLd4zVcbcR4PLMcl8vr2SB4HeB10KvrgGzzxPwQm0joWYi5VjS3YPh5zj5BVa8CfyFntKIf wR+r/Qtt3FUmXYPpVtkiBRM2mCLmSXTSQSedp+Ok0y/bT3teKIQvSLuhpHWynKXkiJL+3MATJUef 4YpSal+bM4op4oziAWX4M03ZDSWODdVhxiZixgPCjM1BYcayve0QM26WyxQUMzbhcwroZCy1KIWJ KAWiFINGKUwNKIWJKAWapdAsNVizlBJKYSJK0QilaDZviFIgSoHXAV4HXaEUZk9QCrMGpVDlriAo hdkApeiXQtyi6dZsYLo1c6ZTk226NZubbs0a022x/Zzp9iQzO3ucAD6PR1Qms7PXywC+2mwTvQ7g g8s24WJm53YC+DDOBuNsTi/OxhqV+C7m/tHAjTHOBnP/oFvRabkVCb42eZIpSSA0Gm5KkrJGA+nw Y0UKqV/p8DNmZ58p2hx81k95M4RVNkP4lWYIC8zhx0KHnwE5/FiDcviR7W2HDj9Wdw4/fn62+A4/ PbXY3HnmaGL7PJNN8bOkllCqnjfaHD53EI/vluLxD71p3WxzaFlMUzgUr1MVMnSFdQXOktUrC4eK QlH53d6r1qj6FZ34OKO/G/q7DdbfzdLg72ax/N0qL+WOnrf1Cx2Wed+2YCng8EMIM3OJtIKd+UCr qUWjJAgwTBqMMmhqfkKm5lJKJ7apmZHSqbAzirbm4mc1MbJobR6mGAlvb+6xGCluc9YgRlaz3bRr cMKmsmNJUVp1fU6t1APF53ug1A0+d+dkfStFfFesyA/Ez/iuZNhwFTGGT0tCi8enMhd62dXFyrm6 FCjMMhSEPWA4vXlfppVzjOFU23MM3v/+53+qr6S8PTNxsCnfU8iKkRW3zYrFuKqwnExEeFFBGQYC hJaYmSAgowyigDUoIEdFTonoEMT55oC+Ovq3E6zxvFkobYo3LAJ6XiK04eOW1JkZfyej2ZElgHhe 8TEm+SlDUul5xaS75NSS+8SAaeHwUGBMO3ko0Da+h6DOI67wMmKxm6CUxF5GzK1C6XFE8vXcMCfx 24XKm4rxOCJ4A8fHEa/SczGfkROTDJQ2ZsSnNT0u8b+zbwwd8D71Duk/6j/RS/PNer0K9xDHPLqD gwM5qCNupXikCnX2brei461EmUcY6mhbYEfbanS0Le7RHscnT2kTcY81EPH6Iz2uPdJWeqTVOtPG ceb5CTCOKg+65x5Ds84tgL3rzOSIVXWNUekb4Q1qcjeon+4hriMDZ/MJVKzfWH7txjKPG0vWkQJu 0/wYftoYr8OA7t23myWFDSO15EMw/7QJ1+GvX43Xqy+rnfyb2pTwIia8yhDeHwkvMoTl74VR8m41 UDvsnTiKti9QG7wmvtFD9nt9ZGVvkRH3kHrJ49Yw25B7pMGbqWcAXi0DOCbUBOpWC+wi2GxWy2Br 3Nyv9p8gpMbPKcVdShFIcFwm/EGVPvMcLGO+oEibQxpIdlxCiY7LJmd+yT3ybnIWFbcS96zD0a8/ 5G7dIR8tD4dctT8tnO7ZJkj5kPK5prSSOxPoRAfJiW5Ombm9g/gsN6bKIQp0igOoUxw0OcUB9xQ7 ySlrvGW45xeCcv3JdWpPbnDMJNG4J22c2VKaC1g5PqI/Mz4f6esQ5xfp2QZtjXkQFsl5h2yJ05AO yX6hRbBfNOEOCy53sNMzDLk5uRxDV2v1XMSu5SKLinw0PZf1cx02YYSC7KEzAWWDOYt/NGmAeTrm DJbRgDiHNpCkMIeSFOZNeMGcywss1ulssJ24xx+wgfoTb9We+Dn7xDfpEPAh7ywuFzJm1BZIEj92 oJLE27Kpq2ywmFEbY0YHFDNqDypmVLa3HcaM2t0nibc1JInXyFhqg+ZsDJrDoLlBB83ZGoLmbJmg ObvDoDmv0GGZoLl+caoWs3faDbJ32rnsmTY7pMFunr3TrsneWWwfs3di9s7UWX1u+6OKXBDZzw0i R3LVy7kgos+t54wj/y3ljDv0ppNcEFHL4pEjUXGRyJGErlTkCGPJxCJHooqikSOMVqAirHOkFSOs I1oq8SK548WJFymUwQjrJxRh3TyZZ2FnsML6sp/VmDMrrG94zFlPWF9PmbNcWF9T5gyZ17NEGiqq D5JLc6P6CmUwqm+guT0hMQRHBEMYQ2EIjqwC7TSTqRiWPkcLhvAd22xGrWTf5Rs+GJhFTN65MjzD i9O9OdipMwdnreOzTbj5eh+SC+1gM+jR9qmzFDvqlmKIYDgGMKVMkwlgKVMVhqnaa0k5fLUSOFNf 2xhgU+5lao6HiQYdabPgH+3Z+TOWsWXDDCE2f4/qzd8UQVyv7lf7HT3+OUYbxyj9+8DE/lP9MKKG YG8wolm3lSkFHBJz8tR4/cPtu/cf/vr+47vXU+NdGN8flLP+Fnx9uZjtZ0TJWG0Jn33cLIzz5/Zo Mp5cVF9QVciAmbmhGiyrLJZgW7lLzbMrLrUqMMG2QNAEjbdZi2iC0wBNcHLWfIeNJjjN0QSnBk0o tp9DEyCla1dEup4wpeuTTODvc0ANHyKBv18CNRocWlf20LpgXlAuekENyAvKHZQXlGxvO/SCcrtX e90hZM73B4+WQuXZI/9l5tlDtFQTWtqve7XWCdBFJ0B0Ahy0E6CrwQnQlXECdHvgBOg2cAJEvw70 6zhRv45S5nxfJnP+gPw6+iBGol9H534d+ZT0Uo4dubTwGd6T+13Mp4Djr/Ce/XPjJOxl7oYHGA/w AA4wQ3WsErjqUrCrO2vVK66iwpmagtvYGUwQJgL3Gcv1XsyBTBKdaio9CqBabgnVkhE56xGwhD7X nS2j0ZSRMbfq6ZCw3Id6wIzTnRp3OR68xqHWQZL8PAqXAHx8cwBmzu9FKgW/fTdITwConZhQbpCe 7F3ggYGIHoKIAwIRvUGBiLK97RBE9LoHET0NqRQ0MpZaFMVDFAVRlEGjKJ4GFMWTQVG8HqAoXgMU pV+cqkXnR6+B86OXcz702Cqe19z50atxfiy2r8350ReRqW0omdqX3VA+WGiR31Voka8rtMjvXjzy 2w0t0rl96iQnH0OLMLQIQ4u0hhb5/QwtSo8+hhbJhRb5wwwt8uuEa6DQIo23WYvStd9AuvZz0q3P lq795tK1XyNdF9vHRGWYqIxiqWPLHY0WY47nfeGrpMNFsXbe7z79KuxuAZcHxyzlwUk707rXfdqw mLNFWrrO1+JIVdjVgr1Y9Z4WaT0RRwt2GxBerEXKCk6sKammPqzFE8VwYCgXQQ/WJ+TB2jwzWX5j FP3fCl+VuHHR+22I3Bje962n3Fjc7605N4ZMR1akDJGNDJYtM3ORlYtgKjJMRWaORfACDwovGMuq yGMwvGDcFV4w1oUXjLvHC8bt4gU6t08dXjBGvADxAsQLtOIF437iBWPECxrhBeNh4gXjlvACjbdZ i3jBuAFeMM7Z68dsvGDcHC8Y1+AFxfa1eeNMRKRrH1ORdZSKrA+wBSNj0Nia3dkLXsKgwldpQ1m+ dhG2iL8KG8rgokTNUpRo2pkOYIu4YVFDWVy63lCWUpUwlLEWS8RQFteDyhM0kb2pJmChMxMMnRlQ 6MxkUKEzsr3tMHRm0r2tZ1Jn6ynZtFnMCwYPzVNWwkNjUs0N7/mrmml4LxZBPPQJ4aHNM/rkN0YZ D819VRLzynjo8MQ8HXhoL8U8GTx0MGJebSDjBAMZMZBx0IGMEw2BjFmatYGMkx4EMk7qbKf16SDZ 3FCY0VQlHCuSftL5xlC8QPFCn3gBemgrM4pVHtrG/laQah/H36pYBP2tathmB7mq+GIJpqUaUlqq fmk7LcKvkwbw6yQHf07Y8OukOfyapc+CX4vt64JfrVE9/ErEHSDnRmskuaEsCX/kapSEDBRRksGg JOlqDQMlke5tdyhJ2tUOUZK0C5AJxnQyljq7XDwetMuhXW6odrl0B0Pa5XI06+xyaeEu7XKHDutN MKaTU7UnU5PJkpap0zrZ6S7J1OnPDWTqHH2GTF1qX5tMbYrI1FBJey1TdkM19DBg3HxmRwFDacPg AUNWM50eVDwyWw0Y0rp96iQnEwOGMGAIA4Z0BgylZ6xnAUOHo48BQ1IBQ+m8DSxg6LALNQcM6bzN WpSuzQbStZmTbk22dG02l67NGum62D4mGMMEYyebYMzCBGOYYAwTjKFDPSYYGzI3xgRjmGAME4xh gjG9CcYsSwQvcKHwAktWRbaaCVAMe6/VFV5g6cILrO7xAqtdvEDn9qnDCyzECxAvQLxAK15g9RMv sBAvaIQXWMPEC6yW8AKNt1mLeIHVAC+wcvZ6i40XWM3xAqsGLyi2r80bxxaRrtnpezHBWNcJxhoc aVv2SNtgMQY2xhgMKMbAHlSMgWxvO4wxsLtXim0NMQYaGUttjIGNMQYgMQbtwOCMhJV3njma2z4v Y2XxsyT0UqqeR8IPn4XBF7h0A1Yp3cChN61j4YeWxeCXQ/E6/CVDVxiA4SxZPQJzqMiEYDCIpqsg GltDEE2WZm0Qjd2DIBq7Tm+HCaJRvYoL0B/nLEL4jZRIKziOHGg1hShLlxADo2SUQd+RJ+Q70jwZ Y2FnFJ1Hip/VRJii+8gwRRh4B5IeizDiTiTVIkw/bKp2A5uqnbNp2mybqt3cpmrX2FSL7edsqtUX E2gSuRLtJ51FDvki8sU2+CLsAa5MKFd9gBs62EGLr0wXO0YZ9LHDpHKYVE5PUjlIoNYRAWonUG6Q jqwJwQGDCR2ECQcEEzqDgglle9shTOh0DxM6GmBCjYylFiZ0ECbEVGSDRlEcDSiKI4OiOD1AUZx2 UBSNnEqET5VNYw7PNMYz0jlVRrp6e5pTY09zcvY0R5+Poisg+ppgWXhd2XV3wSKA3K4igFxdEUBu 91KM224EkM7tUyfguBgBhBFAGAGkNQLI7WcEUHr0MQJILgLIHWYEkFsnAwNFAGm8zVpEq90GaLWb k25dtkjuNker3Rrputg+ZgzDjGEDdJWGy1Njl/LUoKu0RldpdAJFJ9ATdQJtnkBsYM5OfWDO6OzU ubNTVS4x9HU6JV+nvuYTW8yCe/rz7tPjfhH+vkk3BjnJ5EQb8a1A/vZCRBukitW4UhfMlEv0L6p+ jRPtyzin4MXi0BkRFTTW5pz6VpOCz5K/LKNavHbzf58a9N5ItXLL2H+ifYimmroOrzZUL2RpjmbJ DDAqWwZGecvASOWEyO6SkdguYY3NLg3ELY/N7XBsrrgrWXapD1uemt92+21s0yOyVeIJQ0gtV78+ yxgPp0a4nv9tHd7N1s/mm2i70RKk7iNpirDf95yy1KAQbnfvZvdBlnRsaPhABBhyOd8/TCMBYOSY vmmOLMv817OoRx8/vn1Nxrx0XMtZOs9no7vJc/J9/nxseeZzczlyvbnpLAPLekaavImEOFrDNFjm CvNlvpTFLGUVStnMUvbLuIevbt4V+m69cE3HHk3+9X9iqYz8y0z++Ow+XKyWq6A8HdGHr7zpsP71 LLpi/9iXm3NeeK4z9nxWc2dclCZulgG1xB+YeEn8SRiKaF6cBz8knb7MjSAeYVxs9f+CLoYX95fT hb73j1Q8MIBMPeP5d1FS1dnSm8zrPWpZTrdiAK0yNWroj4/P1Ch77tX7OR/rx1EyG7rdjv7MPKKl KvTamM0D43hS6TpFDd8Gm3m4CLJe0tVkp8bjA3VxXhjRNRTXieAZcR/AhtN5dZX6Rs5n5BupsA5m RNIkt0lyjSwIj9qGpI/0bqECw+4rkaXuqRAcPm7nwe5Fet/sw4cHKlb9f1xB0AmJCAYA ------=_20080417135952_29866 Content-Type: application/x-gzip; name="slapd.3.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.3.log.gz" H4sICIcuB0gAA3NsYXBkLjMubG9nAOw9a3PbOJKfR78C5ZmqlXOKQpCSbKlGqXVsZ+M62/FZzkzd Xl2pKBKyeaFILR+OvVP579cAH+IDfMiWrYeR1ExEoNEAGo1+oQn+vfnrPvrt65xY5ydHVwPkmupc R3K7035AzaO5g/ABkiXpEGE8wN0BlgG68Yujzu9UYv49/HfwwZvNP9iAxNTV+QeXOPfEcT8wXA1a NJ7fe+Nb4t3Zrjd5tNQZGasDRJ+GIYoWcoZSQ1fJzLbGhmV4A0QbDj58MG1NNSnooC9h5UMGxnA9 YiHbqgWNQ3gYHPJsRAfcbreDEfqOOZ6rjkvG5MFr8rHth+gGMR5EERuqafyb6EsPgfZP9EZA8qA6 QOcBsoCI7cZEn4wnqvZ9vOhpkOgVfTr5hGg9sXQ+7CfifCcmeUQA2Gn32jIeoOaIzD0ym8AE5IMW XeCD/cZdRU9fEj1xYWv3FGIZu57qeP58bFvQmj0Y1i3a06yhZltT43avMfwI5Y5MLM95HKA9HUgf 1zbsyf8RzTs2VdcdINvU/mHaE9VsaBQohDC1EaPj2ckAKQ1A5Wue76jmV35T1s+3bxT6YNpRZFnr vVelSf89lmTtfV/RtPdTXe9Mp9OuMpWVhuYQ1bMd9xI4OjkyVk5ujBmBWc3mA7aFpA4+wIBIxv8M OjoeXWZr2p2D3qEk/fNXif35NfwP/jRmtm5MDZLvjFU8lnS21/j48SPSrSuHeN7jpe3MVHOAfo8x fKRkZptgci/rVjOuaEn7jd+H3Kr9oYTiZrolT+6b8oG8AA+KngX++++/lw26lZpBMMMAjDHj608v GG/BEDZ9fNAw3miJduj9RyQ9HMoKmfY13m6EvXOieupEdcnwr/f459SxLY9KiOzmjKCO+Xv3c9ju ON64UYMBSuM1tXPV9S5sfYBurr+d0oIL9eGEOGR6ArLmboAkWnZNVP2rZcI4Px+djxjYSLsjM/Xk km2ekT9x2TNDYIMYsx2QPhF4sajITCQrMqaKnBYZ5OVFxoGMewmRobyYyCha7SwLF8HlOboIsh6D v2BrrvQpnH+rjDabvvc3fXwp2VS4aAlRRbRCjRdve87M4jru5OLa2vNbvoWbalGkABdzCHSgu5jT G512lWKSfhaYjFmtlFI7i1agTmzbu/pzMEB/nFwo5Ps/Ly/N/x4+XUtoEy2tJfRX0BK4030Vw5JL +lIVEQFV6IcI7AnifVVNq9VCPOGsTlhQYtMF7qaPr1ghxGuV1gYu9TZZXw5xfdNjDqI1fI/BB4fe 4D8OCHEcqJupHggZfbi3hzzy4MG/DVYEtuLY8U0y9l3CvOAGgj+4LbcPO1IbY6Xb7bVh27Vhx6Cm ATrqljifDO+rc0Gb7w9QhOYasHyjAqdZ1Pzy6OIU/S2H42/o6Orq/Ox0BC1dfz63HY/oNIzzB2xm w7bQb4iR6MYz4adv6Jc+c8R/Q7eJ30A/EFKa7zjE0h7jAguM6iugCfXIOWVHvncXlJ/pJhNItu+F BZZOHqiw9pyz6YVhnROLV6E+8CqOrMeC4pFH5onyM8uLAc9pxGU0+hw8pbyBoOiazE1DUz0gCrQj zr1qBhUjW/s+8elgzizNnsWTzZcvJnxzB0JYd8MH2zZTBSeTYxUY5rNDSKpgREMoYcHJpZYtOjs5 z5WBjxP/HhHV0e5Gnqp9j4vuZv9JwgUbzUfEpWtu2rdoH+0XM6OSZMYjS1+WG5UcN0ZIBDsKdixn R6UdcBFu404Pfkp94K1OW0ZNDaT32a1lO+TsqFvKkoU4ArbMI0qypWp6QTwwpgXTFtVDxMEQTx9U zXviCHFihCk8ywxQbnfbWGkrXRgPcTyw24CNSDScJEQnBcE65IFJqBnYxGc6bE5mB342HNc7tmdz 24KikqkucAQzq4GIKyNgjp5j0y0QF50+gE8XCo248DPYvj5oZyijinr0aHnqAzxmiCP3YxG37FSg aUq61Z2BkHJCymWY8AA1b+kxT3A2RNeqBvsdhOzHa5lkvIwbCMPJ+Gq54YA4mDu2Z2u2eWZNqVlN 14UjEWQwEHzL+JdPLtixDQ9EpsgIWMwew3Kk6/Dk8iBBvHjEJPM72EAB83OgMNDK1jzijTwagq2m E47olG2VpBHY5c4VuOM/bEePmcJ5nHt0/TLkwT3UnBiZ/pP1CxO+xugyBrsQG0Js1BUbGHbfBIZJ VKsGo0W2eLJFktHuVBeWBPjfsEBchJP+B/CZSb58uwoevxi6Hq9NcLASLo3hOLazmNfijCRap+CA JXqiR/7k3La/+/No1pc26GgtpqTheI+0VVRwblhAKcYhEWUu7atAsEQF18S0Vf0LbKUcqXDSbDw3 XJ59c4ialj8jjqEV7u2DhGkXMDDA8YRZLwH41dFJAb5uAqx6DbtZq7BYWoyORucXRLtTLcOd0cW8 h+1tOzRqFz8spAlsKvi/FVRqViBUqOWkTkAg69+uz+BBJ67mGHMvaBIIDjA3PxsmST7DygWPR5oG rBv+Nk37R/TbuXUXjY48oOHE98hXhtnNlN48ziNepBv17OSa/HAMjyyK/n1lgwh4TBRcgyB9CPnq U5A9EHJRGPoJnwxXTQzrxPCO2emARwnvRhJJM/2Iqc+NmeG5kWRKTBwezoGlzYj3dUBwbke8Gzxf qZGYSUR/o26+ZozhsBR2iamGM4u0E9NKIzD9PzO9nK78orphJ1eGvhjflenfGlbyd2r412RKHCeS nKFITT2klywsTHVBy9I4/+UbTjS/a0J3ihaOlobHT0ani4erP8MdrLrmF9v1Fk8gAczZ4nFEtCvH nodY4ckHXogkZZi7ET6BuGXrFYl9x/tDNaOGCzkXFoDkcWAGoegHpZdoe3M+Oj46XrhHi0lmaxZr TGuKWizKQcqnq4z5HXFGfszftOz6/PiORMohKEg1ulYtPVUA2xqsu2PTiCUjFJ58uVIddbYA/DbX YQTXbONHEhd40HYeY+1Gu53bRoQltIgWKEC5LcQxSGhQrSfEI1osjxMYMvK4kxTHpYJUSUKWSNJU XKCG9ZwLAQhZKmSpkKVClm6PLKUhd6XXPuj3DmT5ENMYIpOXjs7z1cEC1sHuBWnoG+4d0an4quE2 hHKS3zQXZghPoVEYY4gOihENzIUH8MAwzHlFoRN7chmIS8DOZMYDEwuqaYBw0YPNHKLQaTKwQTnO AyeMQuVGRTsi5Mh07ZCSZKr6NExKnaxPsbhiu+YyJG2Y6BWx83RqPCSXNaoB50LNxQI4EdFqmhaF QFcY9KTDDFKFw7TZRLZwe4mU2uDfIHtXn4xpEnJc5humPo6yKGiKBSPkXsOEhQ9aqLqerGolENva WKMcPXYC4aYHzICaHOj9FkqkYqC9eNGOs8iYDgJcHmg6gFs0KoTRrOLmeV1SBptWs9VYQ6VVCMhN FymEjnNGimea2J/lQItYYXl3x6PLQoDU9i+Hekx0l+EdUKUDJLGz9AFa8cF8YnsA17PHcZRuPwbf 2rgHSjQPYCezFIdUfWHKPxuQhKb68BAdHR+fXt2gqWPP0NnVEMsHbQn+4kH3ANOT1VQZbR80h6WG XU1fgGgeckoG6Nb22MQNHSacqKexKgbAKE138tSm7xzMfY++88DAJzA3wDO2gAiphwHy1FskPSgS MomF5D7tghpw7iDdKJwho7hujycGfZUAAFxNtaZoOvNQ8y9j5u0jKBxka2Y/w/LdzzFP0unT2eUJ tBwmJCua0RdcdOCAw0ZIxgG6D5yIoVICXI1XuxuOzi6uzk+R607pezIxegUFP5Lwnp0S+AV7TIq2 mLLUFkuCzsEhATUzc2+BEzFlt2H/IGjL2GRq+u6dPEC4gyaPNAAJI3N1lJ7x9eno2/lNqnHQ2+Zs HSzV2DuY7h2XWSW53TMz4M/kzWyU0fXxlxRHyiDx4Y9E/+YESEgWCjA1TA9+RxYY04/Dd/s5el78 jKQOTIOuheY5ppsne4HI4rQdIBtYYi95et+RJTCW231qhO+hpmWDEwT2FqiH/ICM8p4yxRN+cTQn WIfEuCzgLEeDNaBbA3YgpZMKhglUvUP/kWJARneWCJckvquBjTeUkU4PWqgmY0Qe7mWIvJdHRbsZ 0k5ofi2zLhl7RxYihYcVTUur1MbvKEpm59PUvUJM5MHw2tWdJUIV6bcLCkbR6+AXGAXXBk52qyh9 OSv4Vj79OHO2YBBdLC0/hDKNgVenMWQm9LGEl1MZwJynR5Q9E5ojRoJoooZjEHfY2TQt0i3SIckH inUK80VT1TCpC+U4lg3Tao58Fi9MjV4zbZe9s0SH+UhHF1LJpcYqHSmFINkmsAA6i2llWiRoLFNl 5lvMFEyWfrukBkqaQnQXgAUCwoLM5szdDMeVw50eA6dnZmSzan2V1juuYb13V2K94+WYB9c3QeRS CwS/iPX+ka/2qbb/mOo3tlrrGMEpmAJRg9dtnOIq4zRpgqtgGzzObN9F8YbZCKZRDqqZ5nlmaymH BGbgHjP7Xsb6W9hCqRkl7KDI/JGqzZ8SxYsDxk1r1iUUKy5XrHjtihUvoVjxExXri7H5qylWvLRi xQn1hrmKFT9ZseJSxZru+YUUq1xDsfZWoljl5ZhHXlVYTBZhsVphMfmFwmKleF8iLCav2/KQVx0W e7Gt0wP3tnLvMPsiOBQojM9woUGWWqjgNdEFt+Zwkr9m//Pn/8YWQkV1/fdXW4V7tgK85jutrSU3 7Kshqf/GayslISqpmFz14GwpyPoFXvqFHRWFmQc0d6Lxyy8z2IHG3CToXjV94i5gFomqAGVbIUCL suitd4c6qY4uvp7UC6JkG7FYWGJEmZ4LDz+rSJw/CE2/Ov6so9AEtjKYIMlkO48tE+kpZTCLpXr1 A9BNf5tajE+MT4yvdAjichFxuYi4XORtbPelLxcRpp8w/QpMv7IYw/PivStFxg0eK8tFLHA6aqyk QhbDj/SQIcoid+ixqSQH9+4Gi133Dl75w34A6qquyYI9YzdTED7S+YWX07KNCUsS1Fjkx3gREEEY /kpBjWF5LB02UR2OMXgee/aYDQTdHF+h9LgWuF1b+04Aph/efAxTVh2SLc6jdFicORUnlReXJ4fw AzQFp7ePvNkAvcdIpTSlF17yCIyfQmC8oQTGeQJjiU/hqLwWiXEBibGUozEDZMPXyZQCD5AbnB1M fTNBlODm5pgmuZBxQcQ4lUMU55CkM1eiqQXbGxQcU0NdPO0dBrsX4cYP1fA68MCtRU0vfP0bBwYa fU1e2180ovE8w/IJvzWIO+jh3bt07XG8mu6g8Q4FxI5XDyGayA5MC8RGqKkH6fs05d4BMlpQIyOa s+v5YNyGqIgO1aBqPDo8etHrnY/Cy8ixMpDkgdxh9mKjkRvMV98DZMG78NfBEsCo0LtoDi2EbMcI fwbdojOwuexbeocBPVG0Exic8N0fF0ktRLnMomFVH/4v0REmOw7XO6wGSoPutXTbAu0A1kt2mNeh 1EX/5ROfsJPM09nce8xjDeGiXgPWvvseIaAvPpctFhceLEzfsdx0u8tv5+eLfeoSExZiE5i+z+X5 jtyTink+Wbs8z6da53ie1dbmeflleZ4NZh08zzquzfMMugbPh1iX4XnOYtXiedaOy/P0jAQDxkHZ vnpS4k4FZrAbXfWWBNYk97yRHB2FG6YAFT2n/7FYwgQYWIHO98SKzeYmAaZr8bVIBKezF4kKQNwx O0UfUEYJn2wnSP+gj6HZydJEGI2nDiGRiAD3KGbJEON+AiphQEjRimYqBuFmiqoDwyYQE3k5ExOu IOmWoYCB0E4iuRbkccD6zn1vHGWnRIkjWpw4kqx1DUpXVhT8XLRLNdsL+gjeuAp7Asqgo5ub61GQ 2VthZj1L7HKkLsY5WyNpVcppq7LYApFLLRB5IY2Xsj1ktu2krbY95IUclnfa9ogW65m2R17EcWT9 iuRwCvPz5DBD9Qw5nLJs+HI4AyLk8A7L4T5XDMtVRjFHDCdrlxHDqXY5Mbx15vCLiOFNNIeXEsPF 5vDG5Bu9Wp6nvHSep5zItpS5eZ7yk/M85dI8z3TPyTzPzCphKbdwUJR59YUfRxR2oLADN8oO5PRR W4h0+3UdcjltCAbWwXt2VpRT5A8PBRpe5ZfbRfmJs6QdROegW2MoyOdOmn+9mQzj3Nz/LErvFDXJ miRnrO+cndf/picBCMoJyq2fcuv7aleeiqPsR8Yys3jNsfK+F5YZTuLjYKu9YyjZNvrOLL3ZiBos xLGoHju5TL2noprMu6CvAIId+PThULukdlbIE2e3bJZAva8mL5vcsVKsS4KKLw6LLw6LLw6/wviq vjg8lXqdVd8Pt3pZmYpUi2CICIZsVTCk16+dnbDNwZDqC6Nqf8C67mud3DbP+yz1C+FZ6kPXJa94 FtB1/VEQUbNcjGijvU4RWBAhmbVRbif1SGZ16swxv2w7TJllp7llAlWE8crCeDWuGt2q+F7Vu8yJ KVa+zpyp/hy2i6pTbzun8MYfmgM/8vrbKS1IfQeQvmxjLz4wN0Cfj85HDCz6sAMLRsUMxxDEX6eL wJ/8+vRUkdMhOPIKr0/LuJcIwSmv8/p0YlVqi+faQvl5ongFrZdybMrcmW2xUzZ3fMXvVCcXTYT+ ROhPhP5eKfSnKP2D7lsI/mn5e9o5MjELwpWOua8Y1bZ0V9qw6JgqN81WwezXH3V6OzUi+CLCVuun 3GZKwDyF8+Pk0nqTp1M5VBEg2qEAEWeFtysiJFwZ4cpsuSuDsXL4FjwZcS/1cnkLT7yXev0+w9up ETa+8I426VB/m6Vq2UE+b14Vp/jbT4qlpia8sh3yyqq+7iA8NOGhCQ/tFfPMJfxGHLSv98Qx1Ucq deiFGXPHvm8tr1afgIWrbZ+Ap7YS3kTcRT7hU1al9fT1XL9ftck1wnMRPt/6fT4hqJf3J59EM66b Kaj/JBf2GQsgPNvN9mxN3ZiOJyr9pgj9ruHe01Y7hwf6G6DgMxwDJHIqhZsr3NyXc3P7B0/0cln0 akZ0I/5SS3BRSao8a1HzDe0C1/crv9grwDLjF0cm/DMvSam8FeV5r1jE73J05c60k3iX41Du4fd4 KnV7Gu5MiSynr2vBTB3k77pJQ8lcKDkDpXChlA9FL4HI7S7uKFI/8RIIfuZLILK4h2VzXI/NHV/V PSzsG3fCcBCGgzAcSm7F7ucuV+7XuVtZFpe7i8vd13m5e+mXMJY+5sHlBnAK9fYe8+yU+bT+84Bd qxFRenG+ISi3vZQT0fFNjI5X+HjCOBbG8YYbxxV3be6IcbyTN4GJuzZFjbhrU5iTwhB/zRSt3dMj 4q5NcdemcN6E8yacty1z3qpvS9sR903b1Mt1xG1pb6FGmM/C8Vg/5TZTAorb0oSJv6kmviZuSxOu jHBltsGVqbwtbUc8mZ25zEbcliZqhHckvKONoNzOSFVxW1rdsxfxTvmOe2Vv67Y04aEJD22zPbSq 29J2x0ET18Cs/4oZcVvaRtcIz0X4fOv3+YSgFrelbT71xW1pb8WzFV6e8PK23MuruCys2MnbtsvC xF4Ve/X196qWvo0HS7kLeqCoxg09mHtDDxYXTYmLprbwhkrcwYfKVnyKIatjfq4m6AhGKTP7HdKq lxlZAs21o0vga1vWr4GjKC2+jDqtavqtP2C2azUijCUCgOun3PYLzfxqlM6Ju0S7QoVlpiUCYtsR EEt/PqB8Vbf4MwHi6vHtuHqc+RgPHr+7bu+wx+tO3Fe+Kbp/c8cn7isXYSQRRnrufeUiHioYeTsZ ebXxUKkj4qEY/ATXsGq7tWXwfMe2rEV91/aVsBRGRkvp1KpDy/VHE3etRsT4RHR0/ZTbHRHKiZKW z40fJ90xeiw3PREx3daIadm6ipipiJmuK2baafek/mFHEjHTTbYINnd8ImYqQk0i1CRipoKR3yYj rzRmKh8++TvnOxMylX+ClwAm7+0c7Dzbquvm1mjG93ZrNKzv9K4FWWFUtQ4pW0tQff0xyV2rEZFC EWNdP+XehszlxF9rzZsfhn1DJHvS1EWkdlsjtTWWVwRsRcB2jQFb3DmUsAjYbrJ5sbnjEwFbEecS cS4RsBWM/DYZebVJrsph/60HbJWf9pxYFFFdJ7i8Bd//LW9T3/V9RTyFcdkKirXq0XX90ctdqxEx RRGNXT/ldk+gciKvVXPkB113lDLLTlPEVrc1tlq+siKsKsKq6wyrHnY6XRFW3WQ7YXPHJ8KqIhol olHPDav2c1HVfp2gqswNqsriSmBxJfAWXt9dfZPqpnymqTSqGukSscXFFhdbfNnLQcQWF1tcbPEt 3uKV77KIHS52uNjhW7zDK5MftnmHiwQnEVLazpDSShOcuv3DzltPcOr8tAy37oFzITD/rLkQvP4x 84ujKMxjKiZMq5Jy68/22bUakYMjspfWT7ntlpacTKWS+fCTlHaAAEtMSeQibWsuUuGiijQkkYa0 xjQkWVIUbnciDWlTFP7mjk+kIYmYkYgZiTQkcbwhjjeeebxRGfrcquMN14QHE8hJLABXYQPcg8Xa PIB9zZR6qr7JtxEDqTBU0FQfHqKj4+PTqxs0dewZOrsaYvmgLcFfPOiCKQcclSqj7XNC5ZBTkhIz SrKeLgADAJWpfaf8PrWd/2/vW3vcxpF2P29+hdAHC3TvdhJLlq8HPZieJLubwU5mMJ1ggX3xouG2 5Wln3HYfy84kWOx/P6QubckiLUos6tJ+ZncusaQixSKLxXqqHlmL1SOzDOuVFdyuqlu3n9Bs6qHo DYOtm9myu8Vqlhn5xcM2Z+hljurDZMUmyeZyNr3yvjLPeOnx/5yuHwTOk/ReoT8lvVvZxTItQeYH y8fkMm/Mksr64f2Ht0z+1dmxR87YOt3er2dsZg5fROodW+xo5LMZxiQVel7i+HVjv68r8fvcUa4b GRi/cWhcrmw+d69Gg+jhYNLNlzv/3mFHQ9e6+7b1fGu7tvyZNUwNya/vbj7982P66bC95qzEnmwh Jv/Apc7Z21nzyWLJtij2Kqs1e8Hzm910ygxvqvfTJf/QALPTvJvfeO+iMfG51eI95Xd4h4+w4Z4F ++fBE4kRtblF2K0Cm5D89dMHPvnSI8SDKmxqTbZbj+2UgcywXxnZ6T4IWg6sbXB5BpQaJ47nceKg peFwnZP+1Nx6OX072bJ54Xv8Syt3szs56nDs3qxncexuNb+gAglCz+LomFzmjVn9cC6ukMDguZ62 gntd0iPOd4PF/cvGWBv6EjldzEKDPxU4/kjvFR5/pHcrH16OS8hCi0feBfkEyMSoeeRa7REcaOH4 u2QV8wzeXf11kH/RhvwLodfeuF2dwKM58nKXuU5CMirYXlfBXKRUPia5kVJmNW7Z/xerBZum79k/ F3za80jED29/sGaRfcE8xTytd54Kd4kmj7HKCB28TqHXb9ziK3D0gxqhRqixfjXyTF7uq/rbyWa7 e7xdr9iNwR+4A3CWeeIsdhc4WeE4/4Y/JpsVl/TSWq2ttz/cvvn5w9/e/92aL5aeNV/vVjNrsbJm i4033a4336xXr2d3Y+vcuXj14t3XR/aj9bheb6xHbzPn77GaegFK5+/m88VXUeuv0s3H3ovoVnb1 zlt9Ce485w1fhA8/rJkPtN7shUQ/8NeYLfzJ3dKb/d8oLXi38eLL+7a2a8tb8dsyudXHzmtIrUZq dZ2p1YN+Hx/OaXQEr7n9Q2o1Eh2Q6FBvokO/d9Lfh2bb7c9ss11Ovl39p/Nfnrz0uFl/uSwY8C8q QogDFBWiDA80S7AstaKwGi5Laq/+hIImXwFeCqS5fqQZNlkNxS4+TkJwG8OtDJyXHXHg6c3G01n/ eBQv8Ga5Pzm2VjNJpDJ763rK7jxf7ZbLi7NLa7LlfAhPQZMotLmKzrkCiRexSHbTYia+gw3W0x1j i7UaVS6MeXj0w88f//bzpw9vx9aHdfhy/KD0u/ftNY8uskPSYhOFTc9fdjuj4ehCFGMsOrURekTo scbQY9ftuQg9Ntqla27/EHpE6BGhx8KhR1HhXy8SGmxt4X/vNstbNjy+d8tmq7D023l9Ed7qT/xl UDR76x/8EP2RL4lFmF52Gw1qeGXl/XE7fZprbIjt+P14hzkGm7gc9TH88+12fRtOy49vfrHS/drL 9tfT37lzZ7vhb4/snZnKM79nhW6CGtFUqXok9/HLNr5/bM1nQbXt9mFsMSMw4cM6jl8h6D5bHPzm seWHRanz3TIxKH6wVz+NSaakXFJR/p9F4ve46Ncdpop+41c7ZNiYDmN6AlvAsJG4ujcpdrgp5/Ns JJ/mc9VOcUbwq8qGxTTPBu9MjmGx94bFpuPZ4A2r82zwu1V4NkKphXg2sspSMizBc8qGxS1jWOyG GhZbYFh6EsPSK2BYbJlh6TXSsPSEhmV4NxvKDUvyanHDkno6nKvHmEsSCyh4sineTNCZOoxO0LCy 0QnuVjA6kdQiRkegSCWjEzynCKQK2lCuGHeO4qgpySkcVUgI411fR6tJIqpjMVOyV2HiNnZa2Pye 0BiPI7FJdylebfF9syCFT3KLfxvwY4z5RIn+tN6wA9V34R+j4wn/IRxjfiiJ7Yd1vp+SkcSLxF0J Q9uJNXpwYRwtpvhyuAGEJiRrhJ4G7uCKkMPo9KJ+gZHnwD3fQV887ra388VyywaGvUoY+JryYNbV Xy7OUlf9Be9Z8FP4n/vnUo9FJ9O73WI5i1tiM8G6/vjx15sxM1V/zdt+tfYgwRZk26PDPUjEVCJ2 eRMLQXCKTl7V2pkEZ+nW7T5GztJN3H0KnaXlu09BjjSXs/bY/eMkaT0VkjS7L/opRfHjZsiZgjuk 7EwuFU+aC5609vCkuXXxpF1FO2coJEJvpI+W6+z0/urm/U+//POdxc5HV51En7tW+B85Ithuc/wO WUTYzaN7yw8vy9neOsfI3ux+aqyybG+diOztqH9bNAVx6Ci7zrWmIAaDWz7VsHGVPnUUvdaf4IYr 5lMGm1zQR87Kc+LFjNB789/dqN4bt6+dMh8aUgspUguj40XoXjYykJebTCI7O9jifLjoDYI0vuwB qokjkGyR95udFWxx5DbZ8v5OzmJssXOc9zWK6bIr5zxILRBhBd1XvjmG1XgL4e3earqeeeedr2Fo sGNfiIb5ICiDb2bgmxkn/82MXCLmVn0z48nGsn8wJQcrMzQIQUxKPUaUb+jLZQ0C7wDeYQjvII0Z 9kadU4gZrndXv3jryB4cP6AcuVVQayW/WbGmikDA4zEB4jLhI8NxGVyWyUTkEXE/xH8Q94PeyfTe 2r3psIz62HsIyqUb/NoKO+rBq8j3S8QWmxFbjHLopvwYMZtsPXa0CapxRZGnZIDJ8qfrR+/KSQXK lkejd+zYwfq8/ZZozDp/qkh9CuEJbhsn77NW620YLGOHr/27pm4P0hLmi42/Zf/mx7MrO3ErL2Wd rVnrXFJwjLXCbEPi43Aq7HlkAR6o6ci6yYRCj99bQVDU4RmaRzoRvBubGeyo5nub7S2Tz8/Rf84O giCO6sjiqOxEfHZkQGUR1fzH8mOrzsVxXTYpG862B/npcMFHAmN7ceiNL9hfd0g7yUk7ufn1zT+E sXrH6ljsrw7/XyaEFw0rvyFOdj5PkANc/eUio4+f/hufjthrcl1Ot5uln1WbJGgoeJZNZjalzuxX 3Vf9V/Yrl//tdLrsXyP2t82M/mq9mm4W28V0ssx2aHG8pYOf78Q/x+/E9JTo14rNzM2U6YbbV2ZN +ThNttuNH6Z5JydwMP7SbSvaqayZt/HmTF442FdnB4N9lhXJm7vijTV4V31k2xCzUV5qV0282cWR PfLlwSYZtBslyIdJ/CGDBR8Yy5XFkJMZf0Onf5jyx2vhpSK9r4vtq/xWjxntVPu9Ua9E+8cyJW26 TEknyHW0O7YgVbI/lKdKstn47prPx0TG5JMUa8XfaOH5XHyQPSlFAZz8sQQeADwAeEAWD+j2TwQP +PtmvXv0lYIPsluFwQfZzcrBB20Bvx0TIMMDpMMR4gEymcADENtHjBexfehdFttv5z6Tje3L30MY 22/sayvsjgevIt/7ENtHbN9obD8bt1AJ7ifvcWoBAGSrNAsAyBaXCAA4cm8FAEA3BACknRACAF1F AKArAwC6YSRfNqAyACD/sXwAoHtxXJeCHNIsn5VyBP947WpKsh7tSyBKg/Ylxd4mpn05uAW0L0Zo Xw7k8RA6iFlC1kFR5YKYMiwxVUWVC4mrWlyEovqFtnERmqlfaCAXYbH6BSkXYZMA4p4MHk7+gUud c0gich6swGwzj+f8JtwrUy8wXa591iluXiezgFAwAjL8gF+G95Xf4h0+w/aJWTA1Dh9JACHca7vd rYK9Lfnrpw+cdyM9Sn64eUy2W4/NgkBo2LOs8HQvRG2H3DjBDTPUUaGOCnVUBb/z9jzKqLoxgCo9 QABABYAKAFVUUHUSJEzMNFwvdw+rhXXt++vpYsKXxmWxnO5iAoTR4GIilGPEhsROQrGTtNhS5VsF Bz8EcYu1D2gX0C4gPkC70LsM2sUOeBwyLjo+QiD5GQ9yaX/gYIiK7uuArQFbVwpbd8lg6+Q93Vqg 7WK2IAt4F1usIhi8sIQKwHE3BMcLdk0ImbvWn488I3nk+2OPCPB2V4a3uyFwXkzLMhS+rLB8bN69 KDsZhfG+p+KTgl1FFBBRQEQBBVTsfXt0ImHA96s5/1OQgvLRm96v1sv1b9+st4svC7+4s64hTei5 a8hTduOraGORaGO7b2OWaKNUHFFHe2FQUaNniDAi9ogYFGKP0Hvx2CO2Xd02svFKrTEVBi+hJRrH 5WBYtXwORD8R/aw0+ulWGv1M3uPWEiHVMCvZcKnGUhfFTvXEVRBI7YWBVJ1+CkOkveJR1V7hqGpP FlXthYFQjZkhC7GSSM6Pt/YuSKa2MPjai4OvOi+BSCwisYjECr97cRIJmcwXu2YDc7OdzOeXBerv VZ8TupRKTyq7m7TS+DTxY2nFKXGUxzP8xK9Sa4h3IkZaWawsefMPk83dZDOxfvSYNQ78CMLABLV8 4QCTtqCsFPpWs4ok1k1W+T9OVp71du1daifTaQkTqrW8OGUdajaRVZjOeAq0s75fxdJoFyWRZLHe aGSrK5GwPYFGqXQg2nI2v1vvlsvFekuy/rTkSbYuDYkFtjfdVkRboNbYiiwl8/+ta+tHdoLyLZvI YGrKlNhNTakFzCdFSyIrqj3WeQp0DNhU0gYUVKvbREk9kzSbp3R9/QhmgLdaLebexrp5WGzvaVaw pkixljWFquuVoiGBJrXHOau7t+vNenv/jZ25vS/MGSZRnrZMofa0pSqrj6alrP4IxjqrwE8bf7ec WP9g9/lbdjalUKC2TKECtaUqK5CmpawCCcZaECf4vN6szEUJ6KSLYwR08tUjBMRtCuIDlDpBGlX2 fgTHyqnmLmr181Or9Lk+1M1IpsCJh8g+8yZmYRMkNalaMmU6QqBMRZW8vWjYjSxHogakWxHCZeG2 x1rxnlqhWpRaYqW2E0GzrEHlLbE9a98SnV3VFK2kRoTOSmvbMWd6SduRzQME0A60Gzfkxw2RLWVN yRINIoyWVeIsasnft0SlRW3REjUimJZV4y5s6T7REpUatUXLogsIqRWNKwRtmo4q0DXy3YvZ6qeg uuJlr/PiT2fHQlBn4XXC1s/2rdtR69ouotFeuopjRPAWT20OYpFlYxL0fepHEmmO0/T9s0OJ2mbR gDajrmlvvAa65sZzW+OcbUCXTrSgKUOp5hSr6xcbGMCuSKTuCex0+9lcTb/sjhS3J+2uH+4EVGNR fo/bD0JXdY8maIx2LhDsCnHPXNp9RnNTiHvVJR0uok697BJ5WFT9aa6PYBs00cQb/H40HeKThZl+ DkzuflSO+oHZN+KTUff1ZZ9W/+QdNOr4EJyBqvDECbtp5HBK2L+XQiNafj4Sds3kRDQSkDE4Iw0F kExMTtKunnjl6YmnF0LvzX936B16N6H306HgyM4TxXcXzpm2j1tRspGD11dkDwFzIZgLK2Uu7DWO uTB5T696dkNVw3EwiVSXeIaxsMCDFXAT9seWeo+ElIL9gIVQ9ozkke+PPSJgIezLWAj7l0H/lTQo 4xssKCOfWTD4wH2RaSXkEOwHHILKHQNbINgCwRYoYAu0ne7JsAXuUzRL+t5FBEic8CIiCpxijIhN hoS1qQULDX7MMVikfZANgmywFrJB1B+0nMYDFX2tp8E66XL2pjM+osLuQF/toahCfXqL6BxRQddC OqoTBxNRy/sca3nhUT8TjoyT9qvbQRMF77rl/BXwsVvHAQVPu21cFYXL8Qnr6hpcnCWsINKocyGo jxxQD1bL6kOJSz3o6napZzFZx/bVWrp0F2RdcmmVSFQligLf1hf4NqgC7MQh4BMP3EHvzX936B16 N6F3pNIdn0tFx0dSIvRsB7l0YmGmjKhYgiDqiVBPVGk9Ub+V9UTJe/o11RwVsTui4qMihkFchVRQ QgXlSIO4HKlQ14RFRoPidUmDwnVJA1ld0iCuKSqiZVmBUllh+ZVKg4uyk1FYsjTYlywV6ipql1C7 hNolQe2S455K7RI+2VbuoPG8PhRnel5cmvj+XP2lSriCK+KStbazsIC9pmz8qR72mibHjBEvB04C vdPqHW57U9x2wWfGaXWDL2234ABVxZe2gS4BXaoIXRo8W3Qpec+gFgSK1PBlASpa9nEBfkXdQAXw 1jCEt4iJ2UVQ1jBAvzTESqR+b0yq9BEB7DaUwW7DECkjndoyVM5QW/mg3fDC0PoVYnrDGNOjfVFA foD8APmJ6AqHg1OB/PAd5aJRg2fz7Wazs+GS/oPQ9YM7uIIrAPkA8gHkA9gDkA96rxDkg6Nes6Mu APcodSKG9qD1RhyVDiE9ylMNAD0AepUCesOTBvSS9wzrAf3ozKIA8iP84q4I8CMVXwHcN4rgPsoP EYsAtJERsG9kBOwbFQb7RjKwbxQBcHRTWgb1GWkpH+gbXRhZs0KYb/QE8xG+JEA+gHwA+UQgn+2e CMgHunNTnw6qmljdhG4vqTja64dlcOX5XQHUBqgNUBsgF0Bt0Hs1eoe73MIvbeILT5UeREx94Qkw GGCwimCwEWCwHBgsec+oFqhM2zhmATL9zxIIYDEKoRWAYZMQDCP4MoMIVpoEEFgxSRJB31MKKgJ0 TWRAl90J8SftGSnDtygbyIe1JheE60sIZk1iMEv/hQBhAcIChCWEsPQQrHDeZ6Gn6+so+CqR2bFW 3h97ZSZus4IP0ex1x5cxm36X4rUV38fVKu42u8W/Za2s1mM+ZaI/rTfMzf0u/GO0wPkP4WjzZX0b Sz7fT85I4kXirunTSmOvZAsvjKNlFV9mk9b3biUDt3gaOD3wTxYVF//8IP75Lkc2M9wP69lizvbJ PLdJ5K7sn+fz29usOCK1Pw/IhGYe2XiPy8nUCyfy1+2bmw/yXcu+OC52bO0eucOf3IfsYB+qYVM5 nGF2PIUCqbvVHXMBAuXMlzv/3uGu+t03fgTari1/Ztk9yXycTLfsPLT8ZvErM8ESdafDTkmLMmRP HrMoKdHtxcRzoz0KoZuScRjSx4SgcPblLoVvXD+0hyt1wqhNDvED3gCsBb0T6r1xO96BLpUU2NCX yOkigA0AG5UCG3YHqEUOapFCfjqVQBu5Ucfk2SobdUydvApHHQVHwkQELbiqHHV0zEYdg87UEXUM GlaOOgZ3K0QdI6lFoo4CZSlFHYPnFKOOGjGC3ugkYgQFckMKpXxoZ3JQCCieap6TQY7EcJzmcarD aR56r0Lvrd2bDnReMK+zya9dMGcSqZCIGDQ2YqCSC4mIASIGiBggYqAUMej2TyRioFpVWaiQUrt2 kkKAQr1lgeEIIwbyIsz6T9hNvoJTIE6BzX936N3c6b+d+0z29F+EwaDJr12QjaAgAQFO/zj9N+v0 r5JTgNM/Tv84/eP03xs5J3L612OYIKCTMMQdYU4sFRFeKdY7UNwhLoHzKeIS0DtZXAI74PF4hz63 1fMeZBI+KpBPIeZyojEXlawMxFwQc0HM5XnHXIZ9e3QiQRfCT+LpSRP6ScY/eVdRG0a+OK6pvTCE gy+KI9KDEz8iPdB7pZEebLvE3xPWHVNhqAhaov/+r67PgVgTYk2nEmtSyQFCrAmxJsSa2htrsl3n JBJ8pu3/glq932MrO56XRT7fVn9s5HSunHg0IHnzD5PN3WQzoflmt2CwSOULB5i0BWWl0LeaVSSx brLK/3Gy8qy3a4/kK2PlhQnVWl6csg41m8gqTGc8BdpZ369iabSLkkiyWG80stWVSNieQKNUOhBt OZvfrXfL5WK9JVl/WvIkW5eGxALbm24roi1Qa2xFlpL5/9a19SM7QfmWTWQwNWVK7Kam1ALmk6Il kRXVHus8BToGbCppAwqq1W2ipJ5Jms1Tur5+BDPAW60Wc29j3Twstvc0K1hTpFjLmkLV9UrRkECT 2uOMLxurqK/xXzZOCv208XfLifUPdp+/ZWdTCgVqyxQqUFuqsgJpWsoqkGCsBXGCz+vNylyUgE66 OEZAJ189QkDcpiA+QKkTJIpk70dwrJxq7qJWPz+1Sp/NQN2MZAqceIjsM29iFjZBUuOkJVOmIwTK VFTJ24uG3chyJGpAuhUhXBZue6wV76kVqkWpJVZqOxE0yxpU3hLbs/Yt0dlVTdFKakTorLS2HXOm l7Qd2TxAAO1Au3FDftwQ2VLWlCzRIMJoWSXOopb8fUtUWtQWLVEjgmlZNe7Clu4TLVGpUVu0LLqA kFrRuELQpumoAl0j372YrX4KMrFf9jov/nR2LAR1Fl4nbP1s37odta7tIhrtpas4RgRv8dTmIBZZ NiZB36d+JJHmOE3fPzuUqG0WDWgz6pr2xmuga248tzXO2QZ06UQLmjKUak6xun6xgQHsikTqnsBO t5/N1fTL7khxe9Lu+uFOQDUW5fe4/SB0VfdogsZo5wLBrhD3zKXdZzQ3hbhXXdLhIurUyy6Rh0XV n+b6CLZBE028we9H0yE+WZjp58Dk7kflqB+YfSM+GXVfX/Zp9U/eQaOOD8EZqApPnLCbRg6nhP17 KTSi5ecjYddMTkQjARmDM9JQAMnE5CTt6olXnp54eiH03vx3h96hdxN6Px0Kjuw8UXx34Zxp+7gV JRs5eH1F9hBws4GbDdxsxb4VAG42cLOBm62h3Gy20z0ZbrZ9QlxJT6eIAInLU0REAZ/RiNhkAE6b yK3Q4MeMbkXaB7UbqN1qoXZDtnfLSRNQP9V60qGTLh5uOr8e6pkO9NUeQiBUA7eIPA/1Si0k/zlx 6AaVk8+xchIe9TNhJDhpv7odpDzwrlvOFgAfu3WMO/C028YMULj4mbCKqcGlMMJ6DY2qAoJqtAH1 YLWsGo84sZ6uSpJ6FpN1bF8bo0suQNYll1aJRDV5KKdsfTllg+ptThwCPvHAHfTe/HeH3qF3E3pH Kt3xuVR0fCQFGc92kEsnFmaKNoolCKJ6A9UbqN4oVr3RR/UGqjdQvdHM6g3HPZXqDXwiqJyr9bw+ TGR6Xlya+N5R/cUauIIr4qKdtlf9gy2h7Am8HraEJkfNEDFEpBh6p9U73PamuO2Cz9rS6gZfdm3B AaqKL7sivo74OuLrlPF1FQYlxNcRX0d8nZodaTg4lfg6PpJX1EV/Nh/mMzsbLum/9ld/JBVXcAUR dUTUEVFHZBURdei9wog6HPWaHXVBJJ1SJ/iGeYOPSia/YY7oOaLniJ7XEz1XyWBH9BzRc0TPi0TP bfdEouegLTRFAV41QaIJ3V5ScS3WH+/Eled3BTFsxLARw0YsEzFs6L0avcNdbuEXc8DUXulBxBRT O+LLiC8jvtzE+LIsgxvhZYSXEV4WhZf1osvhvM+Gha+vo8CIRGbHWnl/7JWZuM0KyF73uuM2mU2/ S/Haiu/jahV3m93i37JWVusxnzLRn9YbtgV9F/4xWuD8h3C0+bK+jSWf7ydnJPEicdf0aaWxV7KF F8bRsoovs0nre7eSgVs8DZxeYF4WsRL//CD++e647KwVPBwSO37nwLbuVnds/wukzZc7/97hZv/u G99Pt2vLn1m2KxnAyXTLNtflN4tfmb3wl+ymJVs23orJYhcXX9j+eT64GFuB35O6fs5Fjl+/fjJ/ Y2b3uq8vXgQbQM+az65s17p+8+bdLx+Z/PWD9f6XK9sZvOqw/9nj3sC2h9Z56jcuIHw+7CBfXee2 K/ppbP223gZ7Ddvbe8kb+IwP72CTb/o7t23z9YZ5CI9sL2BjF9yvuo6dUWIZpx6K3jLY5Wbr2ycN pCbdw1YyL0ThzWRcn0mfL34TeJPhBaErGV5S9iPL3y4DI6JOX6beIDlOP7z/8JY9eXX2dP2MGb/t /ZpNFWf4IhrGsfXF2/CMlKvukZvz5U7vr27e//TLP99Zvj+/6iTEd63wP5L3s5WS+KPMr+mVcmtS twZ70zi0ecwZZdPtajQIn00tYbZ4DtZwsge/vrv59M+PqafD5hq1fOyem79+uOv9dEA5BAIW7K+7 k1ksN7+++UdqVjps92N/8X29I9tc+A2hN87OReu7z0yRb5hH6V/95SIznj/9N7Y87DW4LqbbDfMS MsN+fDtLPju21mxKnNmvuq/6r+xXLv/b6XTZv0bsb5udElfr1XSz2C7YNpHt0IJy42R6SPRrxWbW Zsp0wFcHW4V8nCbb7YZd+ov119QEDMY9POcmBj860lozjzkaTE44yFdnB4N8lhXFm7nijRwzI7aW GaETxnxgb/PgzRZsr48f4DqVqNTlK5sd9OVGzQnMku3YAqvWzXgmhE5HP3A6ekedDqej5HT0RD+l rGY/azV7x6xmn8rp6MPpUHI6+oacjqNyTTgd/fqcjl7qldWdjjqXT57T0YfTAaejTqejT+d09As4 HX1Kp0NXWK1OR4/S6RgETkf/uNPhKDkdfdFPKas5yFrN/jGrOVC2mm7/qNEcmHI6jmDzGdMqvVdo bY8nCuinGlAlKxQZk8u8MUsqK+mhyD8OqOYMqT1/FUF7oZDZis3MI4+W66yah3VEROR0HflcosTm Derzw/qpsVL3w+q0KHbfyTcpen5YrtFQsBQlFzfpY0JDIFz9gjcO/TfBRIcfZ9aPG2T8OIESivlz A5E/18ocjjc3H1RSOPhtyOCoM4NDp4pwUOoU0OD5vFipzWjhfTRzuuxQ23bLxvqR9d5bTb3USCes 4kU142bioGoP+yWPqo6T8fwarEIzy8XM/MBe0ca9IncVdUSryGadk56fmHv17po7WIlj1JMYa8Xn 5MLzG3mk6skOVMk/cKlz/s7WfLJYejMrSNJi73N+s5tOPb5wEv2bLtc+6xRPpprMvvHuRSPlB1Et 3ld+i3f4DNPDLMgyO3wkMdJ8CcXZSclfP33gp/30KPlhqhhzer2Hx20gNOxZVni6F6K2w4hccAM3 J/yI+Y2dI7zHpbVhA97pRAlR7CdmMsL/3m2WUQoZG0NhyM9+HWWo+RN/GQQdbv2DHxJZWYsVO7ZM lnG+W3hl5f1xkMcVJy7yTERmfleJy1Efwz/fbte3Yb7pxze/WOl+7WX76+nvHruHDUWYE8feebLx Mr9nhW4C3acilHFe3ZdtfP+YjSwXYm0fxhazsRM+rOP4FYLus0nBbx5bfjjZ5rtlYlB8b/OFTdV4 TDIHOkkUMXXSixe5Ozxc46KM4eHdbBglGNrZjOHk1eIZw6mneYKoncx+Da6+Uc0YtskyhruijOGg MzkZw/Y+Y9gmyxgOGlbOGA7uVsgYjqQWyRgWKEspYzh4TjFjWNCGcrQsGSzLkZxKGBbG44/lCQei NPKEUytKnCd8cAtJnrAd5wnbF0fhmxpyiOWJu5F3ynXP9vvbONIWR3+mT9Gf5FV/wcc8+Cn8z/1z qceieom73WI5i1tio2Zdf/z4600Yp8rZjrRsssAk2/1e9vSy332d9O4rt9SC2o7kVS1LLajtMGep C2KJw8BzGRzFEl21rOmB6KeUmzrMuqmDY27qkApLHAJLbA+WOGwTlli0s/VhicP6sMRBaqzUscQ6 LUoeljgElggssc1Y4pAeSxwWyA0bVhic69lye6QZm6vTRBWKzQ10YnPDINg1KBKbix5JjHQmNjcs HZtLChfE5g7aDj3cKDZnKJJhpPa5iZGMQrXPJSMZRWufuznfpUqJToUyklhb8jye+v3IMTTxs6Sq 92fxz1uJlP/51/8WPfGfwKEWi/b5LdoR+3e5Rds2Otz3H9+W4kFUek4YPFB6UjkMQCttsZ0VYlUs O55hsEGpNVDJ1kuw2mTyPxAfUhIfriYP3qf3bwsN2AnOFH5z8aESPGHgUzz4+pIOJ2LLvr4kmYjk 00rQxo/sJ9+6tn5kXrPP/HP62UvdQmYC0zYgnMO0TShPYwPNZmcytX4kk9nERBM1s75fWW/XnomJ TCU6O4NpJIunLo1s9TlL2J5gslLpQDZLaafPSXuh+J7gyX5P8KAFuAClZ8DnoNmJ9XnfrJFJQNuO bB5gB1VROW9vFrZnRtc0DXz3Yrb6KSgQednrvPhTTr5McJ3Q1JztW+8aEB5IpF0U+x4PzIgPhdIo d99Z19joUvf0pdtXm4ZkLZ9s6AzuLfQOvZ8U6pidJ4rvLpwzbR+3ovjqwesrAqb4eg6+noOv55xW PX3JT+zEZRWT2SyoqFAydwdTX9Uw7WdrMKELPRjN3+DBMc+mjjJmx9bbH24//Pzxbz9/+vB2bH1Y hy/JM8J+9769ZlN2Yj1OFhtrvt6tZtb5y25nNBylO8Jf3up8vQvLO9R6FAwBW5S3C3ay2WxvWWNs cVt/PvKM5JHvjz2SfO19Nzu8+8EqvQ1UwK+cW7Z9GbyAkgrPrGBMtYXEdd28R6EYbzVdz7y9Obu7 KDixgqnI/uHNrKA8MJQSF/CodazqD1EhrxN5nW3I67Tt3vBEEjvTkXeb5KOf2jIVMIISUktmBphs KR2ktLU+L2pCt5cC+KJEL5Gciit1J+hesx2gTExE6TmhwVJ6UtlUqEvLxhIU310YZ2j7uPGdXyOW pPQ4YtaIWUPvzX5303qHI23Kkc7Lqi011gqpVNAh9RHlaFpUqXMFMBxgONViODYwnKownNRNspE2 C/Ro29ksCKRt9UQAEYXQCsCjaQge6fdWiBJNA2CpmCSJoO8pBUkfEeBWUylu5YSQk/aMlGJahA3k 413TC8L1JcTCpjEWpv9CwMmAkwEnE+Fkg1MhQEGVDVEUoP3FPcYnhwh10y8aqh+UwZXndwVAG4A2 AG0AXAC0Qe91AG3wxJ875Q1ID1pyLqqE9ABQH6C+qqA+B1Bfo6C+1E2yoa4SD9S12XngoDZrRS5S SNBCBbDhTAQb6lN6iBC7WYAhaoiVSP3emNQi6OJMii52ReCf7vyWQo2mWsvHHWci3JFkHQtByJkY hNR+VSCSQCSBSIoQSft0EMmVFzOnEWSplhUmOdqWFVcglmG8ic+8iYjJirQsr7TiYmSwbL+AAuIK 8EHgg8AHm4GVACcCPgi9U+OD8IvLNyHC88qPpwS7O2kFkZwqMlhb+RMBcDXgatXial3gau3D1VI3 ycbaNPhW1jiLgLayFlMMqmlIqwBA82IArXQ3hQCUR1Vw51EV3HmFITFPCom5MUhVdtZJ4S8KyflQ l3dBsWqEsJa3h7VKvwIgLEBYgLBEEFaneyoQlrdaLdjcsW4eFtt7mvOgpkjxqVBTqPrhvaqGPscN +XFDlACXrlojmEuzjwC7cAWQFiAtQFqANp4HtNHkd4feDUJa8JMN+MkCqEt7nMWAF9Rn7PRxCIRp nxkAhwEOqxYOcwGHPVM4LHWTbLANY2aaNl2AnGmaWCF+pi+zAhRtHqFoup0VIldzKixtToWlzQtj aXMpltaLEC/N2ShF1Ojk5+Nq8wu6lSVE1+ZP6Jru6wBjA8YGjE2EsTnuqWBs6/tVjNATU6TQSBYf RWlkqwcUKm7vM28vysQxxkpJpPkIjaPpMUA5XAEoB1AOoBzAmecBzjT53aF3g6AcHOuKHWsBYEel AzFuBw3XcpQ5xPSoTh6A9gDtVQvt9QDtnTK0l7pJNtqG8T+a3UAAA9JYZSEaSCa6AlDQ7kSoIFGn hVAcm/UmaCmZWBO8lJHYIsghH0UJdNiPoD2aiSxFEMmbyQUS7c4F+RIV4YncZEZ4ItHLAVYErAhY MQsr9l3nRFDFJgd+qgkdFRmTy7zoUv34yelcQQQXEdzmvzv0Dr1D77R6R7QX0V6T0d4+or2I9uZE e1M3yYbbbEhYaqizQV6peRWFbY/dXEUg1g4DsfJuiIOVtvVntRClLQ1RDsLYoXRgpUFHhQfzw4j2 hYJahYFBOw4MyjuAUB9CfQj1CVm6eicT69v8br1bLhfrLUntupY8ydFDQ2KBo1kVrTzwVrynVghp ufT0GMcwNXqHOCeuIPcfuf/I/UdE8XlEFJv87tC7Sb3DJaZpRTQPtcZWMlehL8rDRWbtaJ0KgNQA qakWqRkAqQFSQ4HUpG6SjbdpOEdj5xBBPhq2XAwL6QmsAjpyYuhIp6tieMmh4vVikoiIvSJJhfLz HSn4NYwxLI1pKAXIiITng2jOBdFiEgJtzh5o03kRgHEA4wDGCcC4zuBU6Lw+bdgKnVj/YHbBZ74F yWlWW6bwdKMtVflUVF1Lu7Cl+0RLhACdvm5DkE67lwDqcAVwHOA4wHGAZdoFyzT33aF3c3qHU2zK Kc7OS4KxFs5f6NDsceNguAnOCIDtANtVC9sNAdsBtqsMtkvdJBtws9ie9laTxfe0Db8I46MQWgXO 1w1xPv3uinG1LhnW1yXD+rrFsb6uFOsbhXCc9rSU4n2EDeRjft0LwkUmxP26Me6n/0LA/oD9AfsT YX9DPegvnPdZzO76OopnS2R2rJX3x16ZidusII9krzu+jNn0uxSvrfg+rlZxt9kt/i1rZbUe8ykT /Wm9YSeH78I/Rguc/xCONl/Wt7Hk8/3kjCReJO6aPq009kq28MI4WlbxZTZpfe9WMnCLp4HTQ01l QIP454fjQh5329vQY2MewPn67jN7sSkzBv7VXy7OUlf9BVdX8FP4n/vnUo+dyXrQ4OPbI1MZ2wS9 1PEtfKs3/K0uihzGRsQ7Em/6YT1bzJnXkufHit5x/zy3Nd5mxWHV/XjJhGYe2XiPy8nUC43K1+2b mw/yTwHy0vtjYsfW7pEPYfLrfmHRfQ0b/OFqt+PlHEjdre6YOxZM6vly5987/CB6941Pke3a8mfs MCWxDZPplh33l98sfmXGBmu2vvW/raZ8IK1N8OK9aMtgNnIb9Wa3WUZ2hHX4nP80fv36aYMfs53d eR2ZKX/iL2957279gx8S/V+sFtvFZBkbvfAKs9AHbxzvXnw7Ystnlbgc9TH88+12fRs6HR/f/GKl +7WXzVy3373t+Gls2ALjG3rm96zQzTfuCtjO4FWH/c9OyH38so3vH1vzWXCK3T6MLTYPJnxYx/Er BN1nrg+/eRx7u/PdMjEo7BzwhSk0HpOMqd5KbOwi8Xs8G9yhcDrI3Ub7qNtoa7mNduAl2OXdRofO beyVdBvtvdtoP2u3MVaWSbcxbkPZbVRmarXTXuOTlazBWbTznUWbylm0Y2fRrsVZjB237DYWuSdc vya8ujDWv1ssZ3FLbGSs648ff70Zs6X717wtR8vuCsyu3e8d2t3kDuukd9iWHuIbYI1xiK/xEO90 RyUP8YHf/uDNFk+OZWhvUr+rHSElx9OfxT9vJVL+51//W9SiYdFi0bZw0SLyhsgbIm/PIPIWo84z j6+WtgDPUXfNwLqh7D2ESiFdJlwDMz7sJqkkNcw4pYUMbMyumoWNyRvYw8ZX8bqYTtiKiV6UN2aF qzVeLuG/2wH7CpZ6g+vHE5OLtkI7NdudYHlrSZYJplraWqXfAklFl7ao+jtceYaqv0mF5y/pYe6S bmYFt3A5k7N7JyaCOsd2atbZ0RI71jXBQ3nE3Kl+SSZoCW5u5QfzJ9Ygd2JVz8EtmDQt+0poQvGm vr6ZmomdYPoStSFrguoDn4c9Nye26C4i+sZnuNaMf+PTUDP5BqCfawCa/nVOkbnwVqvF3NtYNw+L 7T2F1/g5lujHEokcx3lkH3TlC9fBPLQLmrIlool8xzmV6zgvs+bn0iXfi9ai5lSSrnU6+fmLvJe3 yDvzp0Wu258KVvdk5cV2SHtdc1nRnkm0or1oRZeXLJzeXriWS0uVCCVaxR7VKvbKrGJPuordaJWV njLS9UshOX/lurkr13taueV7UsWaffB869r6cb1i/3bo/fhA/sT6vJdvwp2fxWubtDXhQphF652y JUlDJjz7mRHHflbGOsyk1qEbr2HKySm1GKZay7ci3VwrMttbEdLeVW1ZbBqnILnobELfYCqyH2Ua EK6OqcBklBAukU3kKUypPIVpGVswldoCR7Q6S0wn6fInbCB/xTu5K34qXvFlOvRcKgP8JbtpufC3 3orJYhcXXyZsNAcXYyvgaEhdF5YEdF9fvAhefWTNZ1d237p+8+bdLx+Z/PWD9f6Xq30+fW9g92zr PPUbFxA+H3aQJ7ac233RT2Prt/U2GGWm0VHyBp5sEt7BxnX6O08rYuabzcfH3dZiYxfcr5pC4/YT GTSph6K3DPQ7W98Ks44XD5I80gcRFVuSafAIu06GDEN6r5Ac4zjVjz5ZEBXdUJExucwbs6Syfnj/ 4W289OUwifXgbe/XbAo7wxeResfWF2/DN/yrbrHnYxMVCpmtgm1bjrWU6uz0/urm/U+//POd5fvz q06iz10r/I8cEcxS5ABHEiM3KmXjUrcGmXLjMAPryuYr8Go0CJ9Np1q7h2Yt2YNf3918+ufH1NNh c42yKHbfyTcpnM/jKU3qkMdxwf66O2Y/co2GgqUoubhJHxMaAuHqF7zxza9v/mGJEsUcq2Oxvzr8 f7JENX5DnNuWzAK7+stFRh8//fe/+/Q2rsvpdrP0s2o7npyXfHZsrdmUOrNfdV/1X9mvXP630+my f43Y3/aZdb5ar6abxXbBdt5shxaF0gDvjmcHMj0l+rViM3MzZbrhq4utYj5Ok+1244eVF8kJHIy/ NFsvStBjbtnGY+YqGuyrs4PBPsuK5M1d8caOmSObzhw5gUGxO7bAHjEHRmqPWHffXfMOJ8zSkxRr xR3jhec30kT1ZAYq+Qcudc7fOWKBsYIsXPY+5zehb556gely7bNO8WzZySyorIxGyg+8RN5Xfot3 +EzgufM04sNHEiPNeY1iHzj566cPfPdMj5If5gKzSeQ9PG4DoWHPssLTvRC1HXq4wQ2kvrPdUXGe XaHzLCrudcsU99oNLe61BcW9A0lx76BAcW+cv50p7h1kinuLr1W7U3Cx2upZ/jlHFDaZcEZpzRkl 1lY7DimFe1vfKSXuao3HlLgL8nNKE1gDBq1mDaAjm3LLkk2BNQCsAWANAGtAQdaAgZA1wG11AXID rDEKkItZ42adbfKCpaFLhWgpoqVtjZbGM5gyXJqSmRcvjW+uM2D61OEiEVNSqgS3LL0JmBKeEVNC zuqmz8sYqOVlNGtTrg4eYHahMD4QP5O0LBmEIP65BESQki/ACDLtp1ACcG+Ce7P5UTQ64igX3JuI oiGKhigauDfbbI0RRauRxs/t9EoeTsG9iUWLRVsP96bd0yTfDEpnMqvz61eSuMh/vIfkiuMvMVvd 3vGP6h1GYpfxWpblAQkq5rQ/DKstU5hXpC1VOXuoupYEBbKlP0FrQrdh3pN2L7/LTsx/yYJ7uIIr +leyX0++ZjvAzXYyn/OJ+vfNevfoKxkzpeeEBkvpSWVToS4t+7VmxXcXfsm57ePGd34/lvZb/rgd vL7S46KvdUsJ5wRjJb1XOD7Su5XH5LiE7Pw58i7COdPkd1dJDT54nSN5v9A79A5H2qwjnZ2XBGMt nL/QodkjysFwE5wrsuvwZnfHQeCHiUAXT9eEY/p0VXls0k9k52miL8L5VmVffUFfD7rjp7rT1I89 eP9vx/q8/Zb62EPQtU+f3r99+tK94LZx8j5rtd6GPCferNjnIfY3jy2evcja57IC8ClK7krd4yjc 01W4x1W4p6dwT1/hnoHCPUOFe0YK93CO1vybZCNthqIp+N48hZ1VInvT4mciE5rkHBrzVMgo+2ds vf3h9sPPH//286cPb8fWh3U4cDzs/Lv37TVbKxPrcbLYWPP1bjWzzl92O6Ph6IBEig0oJyl2pRR0 ZSmkFivf22wj5mRXh+fpQJIG0ZNAkhrT036UMjxP7NK55XSkLGzaPE/kDex5niQfeLbdC8JFFixZ 9o8U/bN7hBmuaTxRAMsAlrURLOvZSL9G+jU+VFfxh+qcDvGOxJt+WM8Wc05Vm+PHit5x/3yYo7Li OOR+vGRCM4/w7OrJ1AuNytftm5sPUg+CaeG42LG1e+RDmOSODL8JU8MG3z4iSHbqUiCzGRIxQdp2 0boH9azYPKIVG0QrLSJasVtFtFK0tzUSrZQzdaREKzY9IaRJw5Jb5WyjyhlVzq2ucrYNVDnboirn BnvuctSB+acqoAO/rSTmwDx9YA5NwhxSIy2TdHSLLVyy3+ClsVipLQ7hfTTLo/RYszvaNdjVRBBK TtL9rckilfgBvgdKtkCXu1JXjuPkU1M4ImoKp5/hpmiwDs0sGDMTBBtPkzYepuOoCjOsFOUTIVyy 1v5TxwRQV+qcxk84B4uLTdAj/fC+LravjJmWIpQ1nGhZfshU5KyxG3nurJDIwy5B5GGniDRsMZGH XZ7Iw84h8jhs3xjdt6MQIWULCHTfjaH7Dp4tTjGSt9YdeTF8QSMgkJQ406cWupwIWCMW7iAW3qJY uNOqWHjR3tYYC3fqj4U7SqTjLSUqoiOY7YHuG0RFICoCURHovttsjZHGaZzu2yl3FlEx505HGpJI ODMAwgGEtxYIdwwA4U4Rum+nAXTfTt10305vAEo1uBdwL1pVJQJKtVNmEWgnXwEo1XAFV0CpBkq1 1LiBUg3UWkWBT1CqQe+gVGuKIw1KNVCqgVJNt6+gVCOhVEOWecOyzEF0hBA2QtggOgLRUQG0GURH rSE6yu5Izf0UsMGEnQoriJwSFUROqoLHEVcQOeUriJycCqLD9vEpYHwKuGUZ9nTUnD18ChgZ9siw R4a9mQx7p5Oxu/gUsAFrjPhBnZ8CHiF8gPBBTlY6/dm0BtbYrgonAhlrbLfoEbmrvmRzKuW7qJRv UaV8t1WV8kV7W2OlfLf+SvmuAdZYg4YllzW2i2I5FMu1uliua6BYrgvWWKRVtDWtQos1tgvW2MpY Y3PHGqyxlJMUrLFgjcXGUxNr7NNJtmbW2G4Oa6yuaSFhje1Wwxpr8NxZYc5Ht0TORzeVc9EV53x0 y+d8dHNyPg7bN8Ya66pESEdgja2JNbYJqSeDMqYjl4OsinyVgtbLJQvHuwjHtygc77YqHF+0tzWG 4936w/FuXji+9ioM9n+wxiKnDTltyGkDa2ybrTFy2oyzxrrmXPpc1lgXQDiA8FYD4a4BINwtwhrr NoA11i3BGtssS1Vh6NQtETp1U6FLVxw6dcuHTt2c0Olh+6nQKfh/wf8LR7FljiL4f+/A/9so2jLw /4L/F1fA/wv+X/D/NowLFTyw4P+F3mn1Dkca/L/PUYfg/wX/b6NKC8D/i3oB8P8ihI0Q9tEQNvh/ QeAD/t8GFZy2jf8XrLFgjT0d1lj2f7DGIsMeGfbIsAdrbJutMU6dYI3FoROssYZZY3sKnAiDHhVr bK9opniPrEy9hzL1FpWp91pVpl60tzWWqffqL1PvGWCNNWhYclljeyiWQ7Fcq4vlegaK5XpgjQUY 31YwXos1tgfW2MpYY3PHGqyxlJMUrLFgjcXGUxNrbK8hrLG9HNZYXdNCwhrbq4Y11uC5s0Lqg14J 6oNeinqgJ6Y+6JWnPujlUB8ctp/7peBnT9dKkfMhpWtFzgd9zgddbqsNVkXkfCDnAzkfFbEqinM+ wKqoaY2R81FjzgcYrrBosWhbtmjBcHXSRd3tLB8HwxWu4AoYrsBwlRo3MFyB6aho6ikYrqB3MFw1 xZEGwxUYrsBwpdtXMFyB4eo55jaB4QohbISwwXCFYuMCxT5guDphhqsa6sH7KvXgQ6p68H7R9Nk+ WT14H/XgLaoH77eqHrxob2usB+/XXw/eN1APbtCw5H48tY96cNSDt7oevG+gHrxf5OOp/QZ8PLVf zcdTDVqqCiuI+iUqiPqpCp6+uIKoX76CqJ9TQXTYfm4FEVhjwRrbrAoiOp5CG6yxqCBCBREqiMAa 22ZrDCQHrLEAcsAaaxglGCigBEOHCiUYFD0iD8hQggFQghahBINWoQRFe1sjSjCoHyUYGEAJDBqW XNbYAVACoAStRgkGBlCCAVhjkeDa1gRXLdbYAVhjK2ONzR1rsMZSTlKwxoI1FhtPTayxg4awxg5y WGN1TQsJa+ygGtZYg+fOCnM+BiVyPgapnIuBOOdjUD7nY5CT83HYPlhjwRrbspwPunoxB6yxyPlA zgdyPsAa22ZrjJwPsMaCNRaLFotW2YUCa+wpEyW1k5IJrLG4gitgjQVrbGrcwBoL9tCiqadgjYXe wRrbFEcarLFgjQVrrG5fwRoL1tjnmNsE1liEsBHCBmssio0LFPuANRassVXWgw9V6sEHVPXgw6Lp s0OyevAh6sFbVA8+bFU9eNHe1lgPPqy/HnxooB7coGHJZY0doh4c9eCtrgcfGqgHHxZhjR02gDV2 WA1rrEFLVWEF0bBEBdEwVcEzFFcQDctXEA1zKogO2wdrLFhjW1ZBRMdT6IA1FhVEqCBCBRFYY9ts jYHkgDUWQA5YYw2jBCMFlGBkU6EEo6JH5BEZSjACStAilGDUKpSgaG9rRAlG9aMEIwMogUHDkssa OwJKAJSg1SjByABKMAJrLBJc25rgqsUaOwJrbGWssbljDdZYykkK1liwxmLjqYk1dtQQ1thRDmus rmkhYY0dVcMaa/DcWWHOx6hEzscolXMxEud8jMrnfIxycj4O2wdrLFhjW5bzQVcv1gVrLHI+kPOB nA+wxrbZGiPnA6yxYI3FosWiVXahwBp7ykRJ7aRkAmssruAKWGPBGpsaN7DGgj20aOopWGOhd7DG NsWRBmssWGPBGqvbV7DGgjX2OeY2gTUWIWyEsMEai2LjAsU+YI0Fa2yF9eBOR6UenIo1lqmgWPqs U4DC4Xg9OHtR1IO3ph481lY76sEL97a+evC4qzXWg8ddoKwHN2lY8lhjw/dBPTjqwdtaDx7PYMp6 8JTMPNbY+OY6WWOfOmyWNdakpaqugogNVuEKoviZ5HBnKojin0tUEKXkCyqIMu2nKohmE++Bu9r+ /W47W/+xik/DbIDYscIK067Zn14pjE4vaMg9OjjJG19Ef5gHT4Udss65Fz976o+KVvqBuF5+u9GN L6I/zIOnZO2m/zy2eJQsnqhsnd3zPgSLiSe/LlY891VUjuUcroxRZq2M0kuloxMZKHj0GqmdvEQv ZmeWfCdrBTr1vZrdUT9VJvX8NOWDItXtxomKQs8ip5iJmi9+e5Gw/mwXXE7/vlzfTZYvpqtgrvE7 2LM71tRmsvxZci8v0Vtv/A+TBy8pOizd+7h4YMPD9qJxEO3suPbAtjuOY//7xRNmwN557vYcd+6+ nHTuRi/Z9enLodO3X9rzTq8/td255zgvWJM3QZUEf8K2xAWA6bsc4V3OwV1d4V3d1y/iyu6Dvjuv erbb7Yz+/X/C4Aj7lx3954uH9WwxX3jZ4QgufJMNh/PvF4H1/7rNNue+6vfcYX8gau5MerANmxWc YsMLwiNreEn5dFn+dtnJM+r0ZeoNhBBfta8nhPXa0j9eHR4bgMRz1svvgtjvnT2cuvnBNVH8Tc23 05bGT/Th8mFuSeYQnx/y3D8fFnms+HTbhzZlQjOP8G1jMvWs/UrlegoavvVW0/XMSwZMj4sdW7tH Hu2cWcE2FD4ThB/UwwElh/PqKg6TTCfsGntg6bFjwy3bTaJtZMZs1GbN+sj3Fu4t+N+YL/XAY//r 3Ya5ma/i/Wa7fnzkbtX/B1dz2pD0uQcA ------=_20080417135952_29866 Content-Type: application/x-gzip; name="test.out.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test.out.gz" H4sICFQuB0gAA3Rlc3Qub3V0AM1Sy07DMBC89ysszjlQ7jmkCoJGQiC1fMDG2SQGezey3UKE+u+4 hQoKCJIokTjFys5jZ2zDhSpbRZVA8rYVZ5JiyVSq6mw2g6LYTwifjlPW8naLVkMbu5ZkY3kbhX8p eMjBYfxyvntjR591zFeT/0L5HvAwtbhHOVmjgS54p6gXI8A926pB65j6ELlB0gU0fTikXGf4SWPz XV7kfxN+fw9dRAoZ4zOYRmMUjpLNz1ab+A75HdQNf2V507ju+ERvDCmROMdSgVfhcga4Lqlkaw50 sUZZE2uuWpGqrXJDJEN5idZi5aEso76pDuSPVMNVFmBzsCAyJIeHEBPkXDywpWktUrbs6zYUgdvg E41z7UF4uU6Ht5uBQScSkTGF73y8rU6FLyYqNQNCkTKOuDcSqRKtWBnl6xF1uabjphMUcQMEFdo+ BPsoLrVW7McLeW/dRoO4DljnwzZTvqbewq8JAdV0cggAAA== ------=_20080417135952_29866--

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 16 Apr '08

16 Apr '08

fails on test005 tests> ./run -b ldif test005 Cleaning up test run directory leftover from previous run. Running ../../head/tests/scripts/test005-modrdn... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd modrdn operations... Testing modrdn(deleteoldrdn=0)... Testing modrdn(deleteoldrdn=1)... Using ldapsearch to retrieve entries using new rdn (cn=James A Jones III)... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Using ldapsearch to retrieve entries using new rdn (cn=James A Jones II)... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Using ldapsearch to retrieve entries using removed rdn (cn=James A Jones 2)... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Testing modrdn(deleteoldrdn=1), modrdn with new rdn already an att val... Using ldapsearch to retrieve entries using new rdn (cn=James A Jones 1)... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Testing modrdn to another database (should fail with affectsMultipleDSAs) Testing modrdn with newSuperior = target (should fail with unwillingToPerform) Testing modrdn with newRdn exact same as target... ldapmodrdn failed (68)! -- -- 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#5470) Sporadic failures with RE24
by hyc＠symas.com 16 Apr '08

16 Apr '08

Raphaël Ouazana-Sustowski wrote: > Re, > > Le Mer 16 avril 2008 10:41, hyc(a)symas.com a écrit : >> If you can get it to fail more regularly, let me know... > . > In fact test050 fails with or without your patch on syncprov.c. > > Logs attached (RE24+last syncprov patch). OK, please try again using the latest syncrepl.c patch. The syncprov.c patch has been reverted since it did nothing helpful. -- -- 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#5473) double-free in test030
by hyc＠symas.com 16 Apr '08

16 Apr '08

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24 > OS: OpenSUSE 10.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > This seems to have been a corrupt build. Never mind. Seeing some out-of-bound memcpy's in rwm_config on HEAD with x86_64, but they aren't showing up for regular x86. > Sometimes (but not always) caused a SEGV during the run. Valgrind shows: -- -- 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#5473) double-free in test030
by hyc＠OpenLDAP.org 16 Apr '08

16 Apr '08

Full_Name: Howard Chu Version: RE24 OS: OpenSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Sometimes (but not always) caused a SEGV during the run. Valgrind shows: ==2991== ==2991== Thread 5: ==2991== Invalid free() / delete / delete[] ==2991== at 0x402312F: free (vg_replace_malloc.c:233) ==2991== by 0x8097D57: ch_free (ch_malloc.c:139) ==2991== by 0x455496B: rwm_op_cleanup (rwm.c:64) ==2991== by 0x808BFB3: slap_cleanup_play (result.c:341) ==2991== by 0x808ECD6: send_ldap_response (result.c:522) ==2991== by 0x808F4A5: slap_send_ldap_extended (result.c:698) ==2991== by 0x80AE46C: fe_extended (extended.c:240) ==2991== by 0x80AE91B: do_extended (extended.c:180) ==2991== by 0x807C8B4: connection_operation (connection.c:1084) ==2991== by 0x807CD41: connection_read_thread (connection.c:1211) ==2991== by 0x816E4C3: ldap_int_thread_pool_wrapper (tpool.c:663) ==2991== by 0x42BB111: start_thread (in /lib/libpthread-2.5.so) ==2991== Address 0x4704DA8 is 0 bytes inside a block of size 65 free'd ==2991== at 0x402312F: free (vg_replace_malloc.c:233) ==2991== by 0x80AF9B3: passwd_extop (passwd.c:317) ==2991== by 0x80AE430: fe_extended (extended.c:225) ==2991== by 0x80AE91B: do_extended (extended.c:180) ==2991== by 0x807C8B4: connection_operation (connection.c:1084) ==2991== by 0x807CD41: connection_read_thread (connection.c:1211) ==2991== by 0x816E4C3: ldap_int_thread_pool_wrapper (tpool.c:663) ==2991== by 0x42BB111: start_thread (in /lib/libpthread-2.5.so) ==2991== by 0x438D2ED: clone (in /lib/libc-2.5.so) ==2991==

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 16 Apr '08

16 Apr '08

On Apr 16, 2008, at 7:58 AM, pere(a)hungry.com wrote: > Full_Name: Petter Reinholdtsen > Version: 2.1.30 > OS: Debian GNU/Linux Etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:700:100:6:213:72ff:fe93:c639) > > > I ran into this problem when trying to use nss-ldapd with LDAP > from an Microsoft Active Directory server. The problem only appear > if there > are more than 1500 members in a group. When there are fewer than > 1500 members, > the result from the LDAP server look like this: > > member: CN=user1,OU=Elever,OU=ULS,OU=VG,OU=Skoler,DC=SKOLEN,DC=LOCAL > member: CN=user2,OU=Ansatte,OU=ULS,OU=VG,OU=Skoler,DC=SKOLEN,DC=LOCAL > > This is properly handled by ldap_get_values(), and the nss-ldapd > module work > properly. For groups with more than 1500 members, the result from > the LDAP > server > look like this: > > member;range=0-1499: > CN=user1,OU=Elever,OU=OVO,OU=VO,OU=Skoler,DC=SKOLEN,DC=LOCAL > member;range=0-1499: > CN=user2,OU=Ansatte,OU=OVO,OU=VO,OU=Skoler,DC=SKOLEN,DC=LOCAL > > This notation is not handled by ldap_get_values(), and it return > NULL, resulting > in > a group with zero members. This is proper and well-intended behavior. You asked for values of returned under the attribute description "member", not the (invalid) attribute description "member;range=0-1499". Two attribute descriptions which share the same attribute type do not necessarily refer to the same attribute. > Is there a way to parse such "paged" attributes > using > the openldap library, and could ldag_get_values() be changed to > handle these? > > Is the range= notation legal LDAP notation? No. Attribute description options cannot contain equal signs. See RFC 4512. > I have been unable to find > information > about this in any RFC, but our resident LDAP expert mentioned that > it could be > according to some extention specification. Microsoft might offers some specification for this crap. But I note that it's an improper extension as extensions should be truly optional (per RFC 4521 and common sense). > Have not been able to find > information > about it. > > To get the rest of the members I have to ask for attribute > 'member;range=1500-*' > and > repeat this until the result show for example 'range=6000-*' to > indicate that > this is the last batch of members. If you want to implement this crap, you can do so without additional support from LDAP API. Use ldap_first/next_attribute API. -- Kurt

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 16 Apr '08

16 Apr '08

Raphaël Ouazana-Sustowski wrote: > Re, > > Le Mer 16 avril 2008 10:41, hyc(a)symas.com a écrit : >> I have committed a patch to syncprov.c for this, but I haven't reproduced >> the >> original problem so I can't verify that it is fixed. Running test050 by >> itself >> 20 times never showed any problem for me. (Dual core OpenSUSE 10.2) >> >> If you can get it to fail more regularly, let me know... > . > In fact test050 fails with or without your patch on syncprov.c. OK, thanks. I actually reproduced the failure once as well. Will need a different workaround. -- -- 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#5472) ldap_get_values() should handle paged results from LDAP/AD
by pere＠hungry.com 16 Apr '08

16 Apr '08

Full_Name: Petter Reinholdtsen Version: 2.1.30 OS: Debian GNU/Linux Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:100:6:213:72ff:fe93:c639) I ran into this problem when trying to use nss-ldapd with LDAP from an Microsoft Active Directory server. The problem only appear if there are more than 1500 members in a group. When there are fewer than 1500 members, the result from the LDAP server look like this: member: CN=user1,OU=Elever,OU=ULS,OU=VG,OU=Skoler,DC=SKOLEN,DC=LOCAL member: CN=user2,OU=Ansatte,OU=ULS,OU=VG,OU=Skoler,DC=SKOLEN,DC=LOCAL This is properly handled by ldap_get_values(), and the nss-ldapd module work properly. For groups with more than 1500 members, the result from the LDAP server look like this: member;range=0-1499: CN=user1,OU=Elever,OU=OVO,OU=VO,OU=Skoler,DC=SKOLEN,DC=LOCAL member;range=0-1499: CN=user2,OU=Ansatte,OU=OVO,OU=VO,OU=Skoler,DC=SKOLEN,DC=LOCAL This notation is not handled by ldap_get_values(), and it return NULL, resulting in a group with zero members. Is there a way to parse such "paged" attributes using the openldap library, and could ldag_get_values() be changed to handle these? Is the range= notation legal LDAP notation? I have been unable to find information about this in any RFC, but our resident LDAP expert mentioned that it could be according to some extention specification. Have not been able to find information about it. To get the rest of the members I have to ask for attribute 'member;range=1500-*' and repeat this until the result show for example 'range=6000-*' to indicate that this is the last batch of members.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 16 Apr '08

16 Apr '08

------=_20080416144959_68772 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Re, Le Mer 16 avril 2008 10:41, hyc(a)symas.com a écrit : > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: OpenSUSE Linux 10.3 >> URL: >> Submission from: (NULL) (84.163.88.4) >> >> >> HI! >> >> I already reported different test scripts failing every now and then. >> I ran 'make test' a couple of times and finally it failed once in >> test050 (see >> below). Running test050 again succeeds. >> >> I've also attached the debug logs. > > As noted in the other email thread, I'm pretty sure this is the same as > http://www.openldap.org/lists/openldap-devel/200804/msg00067.html > > I have committed a patch to syncprov.c for this, but I haven't reproduced > the > original problem so I can't verify that it is fixed. Running test050 by > itself > 20 times never showed any problem for me. (Dual core OpenSUSE 10.2) > > If you can get it to fail more regularly, let me know... . In fact test050 fails with or without your patch on syncprov.c. Logs attached (RE24+last syncprov patch). Regards, Raphaël Ouazana. Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... ldapadd failed for consumer database (32)! ------=_20080416144959_68772 Content-Type: application/x-gzip; name="test.out.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test.out.gz" H4sICMn0BUgAA3Rlc3Qub3V0AM1VTUvtMBBde3/F4EqhCz92QhdXKuoF9YG+9WOaTttoMlOS9L5X Hv53c6+Kn2hbesFVQuacM3NOArFS6LLTXAFxcB1sK06VcKmr7dkMi2JVYfr7XBWjrpbkDHap71g1 TpZJPMswYI6e0v9794/s5LWOfd/kp1A+GlxXHa1QXtVksQ/eax7EiPAgrmrIeeEhRGmITYHNEA5r 3xv+JrH9+7zIvyd8/R76iBQqpX9oG0NJ3Cqxn7dq018kT6B++FMnbeP74+emtaxh7r0ojUHHyxnR 9ZxLcXZNhxtSNYuRqoNML7UfIxnDmxsD1wHLMhnqak1+cTVe5Rhdjg5hQexpbWIDPo9vxfFmW2Ti JNRdDIKWsU8yzbVH4fObbHy6C7TkYQ4L4bjuTzfVW+GDDYW6QCbIhCacm5h1SQ6urQ71hLpS8/Ok GwjiAhkrckMI7g5OjNESpjP52/nWIJxFrA9xmjHCq2/mT1Q/gksB36oaJL8lFWDn8GB3thVjix9K AdnlEXwh1PtRDp7vAWg9VyS5CAAA ------=_20080416144959_68772 Content-Type: application/x-gzip; name="slapd.1.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.1.log.gz" H4sICMn0BUgAA3NsYXBkLjEubG9nAOxdeXPbOJb/u/UpUO6uGrnXVsRDsqRtpcZXOq5xHK/lTNf2 1paKIiGbE4rU8HDs7sp3n4eDJHiKlKlY7ih9RAQeHoCHd/wAAuDf2z/uo58+LrF9eXZ8PUKepS0N JHfUziNqHy9dJPWR3O0OkKSOZHnUk4G69YOrLe81bP2d/z164y+WbxxgYhna8o2H3Qfsem8orxZJ mi4f/Okd9u8dz5892doCT7URIk9jzuIAueNuy9DwwrGnpm36I0QKjt68sRxdswjpaNiVpDcpGtPz sY0cuxK1xOmhcch3EGlwp9NhLQxca7rUXA9P8aPfzue2z9mNIj6IMDY1y/wDG7WbQOrHRouJnGUz dj4wY0LstGbGbDrT9M/TuKaRUCs6OTtBJB/bRj7tCXY/Yws/ISBUO/2OLI1Qe4KXPl7MoAPy0QEZ 4KP91v2Kmt4LNeXSVq6Jc5l6vub6wXLq2FCaPpj2HdrT7bHu2HPzbq81fgvproxt330aoT0DRB/l tpzZv7Dun1qa542QY+m/Ws5Ms1o6IeIUlj6hcrw4A9G3gFWg+4GrWR/zi9J6Pn0i1IN5d6Yoknw4 nM/xodSV9UMYzuGhrAwG2lw2hoPerKW7WPMd17sCjRZbRtPxrbnA0KvFckRNqKtKfUlWVUn+nVV0 OrlK53S6/Z6i9H7/sUv//Mj/gz+thWOYcxNnK6MZTyWV7bXevn2LDPvaxb7/dOW4C80aoV8iDm+J mKkRzB5kw25HGQfd/dYv49ys/XEXRcUMW549tOUjOSZnSc8i/+WXX8oafZDoAeshI6PK+O27x9pb 0IRtbx8UjAxNKIcO36Lu40BW8Hyo51kj2M6Z5mszzcPjPw+lr3PXsX3iIdLGGVKd5tvuO17uNDLc sMAIJfla+qXm+R8cY4Rubz6dk4QP2uMZdvH8DHzN/Qh1SdoN1oyPtgXtfHd8OaFkE/0eL7SzK2o8 k2Dm0WfKwAE35rjgfULyYleR6kjaZehHetJlzL6By+j3+4LLkDbmMopGO63CRXRZjS6irKbgGyyd 630K+39QJpttt/1tb1/CNxUOmuCqsF4Y8SKzz+lZlJfbuSi3cv/ql/ASJYoCYNwHFgO9uE/fabdX Babu1wLImI5KibATl4Jw4jj+9W8jcKJnv//v7bvlzeTXu/H6UUIzBskooX2LKCENvwmwzBV9aYgI iVbEh5BsDffeVNHVYSHqcDomxJLYdoe77e0rDgjRWCWjgUdmm7QuF3uB5dMJoj0+lGAODrXBfzkk 2HUhb6H54GSM8d4e8vGjD3+3aBJgxakbWHgaeJjOglsI/kgduTNQux1JUnq9fkfqqB2wGNQ2IUbd YffE9D+6H0jx/REK2dwAl0/E4bSLil8dfzhHf8vw+Bs6vr6+vDifQEkvWC4d18cGWcb5Jxiz6djo J0RFdOtb8DMwjauATsR/QnfCb5AfOCk9cF1s609Rgg2g+hpkQmbkOWnHgX/P0i8MizokJ/B5gm3g R+Ksffdi/sG0L7Gdl6E95mUc208FyRMfL4X0C9uPCC/Jistk8o49JWYDLOkGLy1T13wQCpTD7oNm sYyJo3+eBaQxF7buLKLOZtPjDt/egxM2PP7gOFYi4Wx2qoHCvHMxTiRMyBIKTzi70tNJF2eXmTSY 40S/J1hz9fuJr+mfo6T7xT8wH7DJcoI9MuaWc4f20X6xMiqiMh7bRl1tVDLaGDLZqeNOHcvVUekw LZI6ktqHn90h6JbakVFbB+99cWc7Lr447pWqZCEPppZZRqJaapbP1gMjWdBosbqJEmvi+aOm+2u2 UBJamOBTp4Fyp9eRlI7Sg/Zg1wfcBmqEw+aIFGqCglaYR9ZFbYaJLwwwTooD35mu5586i6VjQ1JJ V2MerGcVGOX6COij7zrEBKKk80eY03GnESW+A+wbQHSGNBKoJ0+2rz3CY0o48jBycXW7AkUT3q1q D3ZebuflUkp4hNp35DUPezdExqqC+h1x9csrKSpeahoIzUnN1TLNAXewdB3f0R3rwp4TWE3GJccj yAAQAtv8d4A/0Nc2eSQyYYYBMfuUy7FhwJOXRwnuxccWXt6DATHlz6GSQFaO7mN/4pMl2NVykkI5 pUuJMgJc7l7DdPyL4xqRUrhPS5+MX0o8Uh+1Z2aqfjE/hvAVWpcC7Du3sXMbVd2GBNY3g2Ziza6g aCEWF0uIinaveTAkoP+mDe6Cd/pX0DMLv/90zR7fm4YRjQ17scKHxnRdx437Fb8jCceJvWAJn8gr f3zpOJ+DZdjrKwditB5J0nT9J1IqTLg0bZAU1ZBQMlfONXMsYcINthzNeA+mlBGVJMLGS9PLwzcD 1LaDBXZNvdC2jwRoxxQY6PKcWV8g/OgauIBfTyBbPYa9NCos9haT48nlB6zfa7bpLchgPoB5Oy5Z tYseYm8CRgX/t1mmbjOnQpCTNgOHbHy6uYAHA3u6ay59VoQ5DoCb70wLi88wcuzxWNdBdflvy3K+ hL/dOy8udOyDDGeBjz9Szl4q9fZpGeoiMdSLsxv8xTV9HCf9ce2AC3gSEm7AkT5yvTphuwe4FvGl H/5keprQrDPTP6VvB3wieC/0SLoVhEp9aS5M3ws9k9BxeLgElbZC3TeAwaUT6i57vtZCNyOs/obV fEyBYZ4KVmJpvGdhdKJRaQLQ/x2Ny8nM95rHK7k2jbh911ZwZ9ri70Tzb/Acu27oOblLTTwkh4wn JqogaUme/w5MN+zfDSaWovPWkuXxs8l5/HD9G7dgzbPeO54fP4EHsBbx4wTr166z5FzhKQBdCD0l 37vBn8Dd0vEK3b7r/1OzwoKxn+MJ4Hlc6AF3/RD0hLK3l5PT49N4ehR3Mp0TjzHJKSoRp4OXT2aZ y3vsToJIv0nazeXpPQ6DA0tIFLrRbCORAGYN6O7UMiPPCIln7681V1vEhJ+WBrTghhp+6HFBBx33 KYpupNqlY4ZcOCKKWUBwi90xeGgIrWfYx3rkjwUOKX+siu641JEqImWJJ02sC1RAz5klgJ0v3fnS nS/d+dLX40vJkrvS7xwN+0eyPJDIGiL1l66RN1cHBGwA7gVvGJjePTaI+6owbeB+Mr9oZpmBv4VG fI0hfFGMyMIcfwEPCkMnr4hPYs+umLsE7tRnPFK3oFkmOBeDGTNnYZDNwCbROB8mYYQq0ypSEcbH ludwSeK5FpBlUjLJOoncFbWaKy5avtErVOf53HwUhzXMgcmFllkLyFkRXS3ToiXQBhc9STPZVmG+ bVbYLdypsaWW/c127xqzKdmEHKUFpmVMw10UZIsFFeRey4KBZyU0wxCzDgTGjj7ViUZPXebcDKYM qJ1DvX+AhK0YaC8atNM0MxqDgJcPkQ7o4kKFNLpdXDwbS8pok2F2NVcetAoJc7eLFFJHe0aKeyrY ZzlRvFZYXt3p5KqQIGH+5VRPQnUp3YFQOkJd+i59hBp+MS+YB2g9fZyG2+2nMLc2H0AS7SOwZLrF IZFfuOWfNqiL5sZ4gI5PT8+vb9HcdRbo4nosyUedLvwjjZRetwcAOJFGyrPiMNRg1eQARHuQkzJC d45PO24a0GEhn6xVUQIqaWLJc4ecOVgGPjnzQMln0DfgM7VBCImHEfK1O9R9VLrIwjaSZFIFAXDe KFmI95BK3HCmM5McJQACT9fsOZovfNT+01z4+wgSR+mcxVeenrsV6G3+hhmyN+Ztot6Ti6szoCOj uSDnRAwQ5KDFWzNCDwyLj5UsTYEKdUMNUmppkEi6BLwNXnTh3YGgJSLN8fCIlaVSmFuBdy+PkKSi 2RNZX/Md5BlokOjYzfnk0+VtojCrTeicgjTbsZ8WTuAhKv2tURrlaLXSSERpPBqOM2qzMOHPbG0N mdycvkcwPF34B/6Qv7oZBeTcCcHctHz4HUZw6l/HP+9nmvXh61ehlAZuHron9ohWTLcUQe2eDkGS 2AZZqSaugNYy3kvVwk6r0CBMhREGUsIXGk4VN6E3vW5Kb8i+psLy+NH0O6XaLjWn7TJVWKkr1VN3 ENz5MRGdoPURE0Teobom9ogtUQvYGjXvFWm5+EC4zqG/aK4BxjdIp2wHutWeBHQqn2i9bjkePU5A mvlEWsel5JE4QlpKKHC6CAyAQaebqRKCjGViboEd+Ykw9dMV8aFJCRHYBQ4GFBwvlhQJ8nZleCfb kFMzjX8022gysEoVAmuvkcAq1VMeqbLyyMNSHyltJLD+pQ5viXKKgEA8s6iACPKJV/PV78eTiw/X l+fI8+bkAKoQk9kPkR4cnjiTKvDF0ksjD2kV8tga05GkwWrbofiCTSuy+ILbSC41+FIbCXqZKY3/ XPzfb///9Xs0NImv5rAX7SD8H8gCn6bjkbhY2PrhhwWorbm0MHrQrAB7CRYfPqZNKpNNsNVY5Fi2 SlC4NsCO525qVWCrp+WC7F5g6l75YHzzpPJGuCr1uO7On+/On+/On2/F+XOs72LHK4odZeD4eQsV jTLLXfVQ6kFtKbncoWwp1lal1VibLi5oRnaamgXaISlD2fH7+LH3ZOtL13k4ELYUCEc8S/D44s/f IjBeI68Uv6/RsJyjqnVZ5B5krS2gqmdVt4tx0RHZ2sNwsOboiTp6fMamKGswKnmjuY5oct54QtFr KHr6/HeecYPqRqosMBA6B/0I+/c2J34XUaZfF+fTNSP/Ggy3dQi2Ayxs0/tfbrwNooTnMUugBIXH +V49lCAnUUJvO1FCX1ZXowSl1oqckl6Rq40LUut06yzj1Q/5tcN7IxH32zCpfotFJhxXDb1KZoGR mj/3uWQ/ZM7iYkQTHz4BKsfmBAdERe/8e6QmKgqXIVfGk3ShaHGStyhVc1n4qRlnktfBPDfOhNzK aNjG0dcZioQtp2U08VB986C27cspu/bt2rdrX2kTdheG7S4M210Y9n2Ye+0Lw3bQbwf91nixoTS5 ZPE8ZoklC3W9FxtK2YuN8Vuy7Tc8GeaS/ZZdhb1bZ4Nd+5W8p3kW3X419VIJ/JH0j184Tw0ThoTl 2PjLNF4QQRL802U5pu3TIy5CNm8je576zpQ2BN2eXqNku7ZnVeab7U+Vau9PlYRdolRp1PT+VJ66 xv5UqXR/arJmcX9qnmrK66imvKWqKce8PUf/jIFmwD+0AV3WXJxOzrJ06aAnNtUq8bc6OP0IxAo8 kL8YoUMJaUSmo7D9Yu3D/NqHNWqXC2of5tdOJQe6SGhHyGMqPg8sYTzYJzSi4cjsvC3YePunKaSH XlKREl6Sd4y5ZAAlFDr0BsZRl3lcJLW+aKavwkNuLmr7/BoeiYFqcl2Rvh8XIvZu2gHOLw0hCmr4 +edk7mmkR+AmfkZM1JHeIEQOFII8QdQItQ12jJIcfXRBijbkQDLEOD+ACQlnBbaEEMADnzQPxuI3 cCv8ozCSOlLVkaRQjN9qZRrzMfCBGbuT6IaNALQK/Rz24QAhxzX5T1YtugCc7NyRu6TIuQxH4ODy M9ge6h4gomI2cboB/L9LWihWzIebZ4OkAS/ZhmND0wFxppt5wyMl+p8AB5ieBzkHV/SU5crpwlqZ Yt9/DhmQC2jKBiuXHmYFgWt7yXJXny4vYw/hYQsGghcn7k0wbbrPXqcnmWOb+XRzMc4Ps+jsKrH9 Oe3ZwsDRPpT2W4IHHYXRnbSXWW5bpb9NMAgLz0GLSBiRoMejMhmsdVRtBWfAZZ52hxlay91hj4+P uUEXsCInU77EKiaQAcpyPwsatVhaGIziIN/iQzqDHr4tIPGmNC6PiCLzJ8dlB57II4d19GAUHZ+5 i3HowmD6EZkM57gvUAlhphtqXCpjxI09zGbhj7mxrB+MBFew4YKygIaQSkK/y04uwfgCzpmG57HC o1J6dFRKzPVMIleaxH7G5RLF+IZUdkqZ1wSSQce3tzeTEbiW/1oVjJ8VFnKigtQ7SoUFEXrISehR HCzk0mAhx8GiVpiQqdV1X3WYkOMwIf+lw0Q4WM8ME6n5yTAzYxmmT9TlY+WdGu/U+AXVuDTmh3VU RRNq4oDeCtYJOMFizCFdScqEg8dHHhAESwmRkkxtjBXnK4dfTP+e6D69EXHik7t1dHYFSDKM1rfg YpgghzBBLoAJUogDaGDkk3YxwKXDWz6m0HQ/gDF5QiTHyIOOcgl0bPA0qbz6NGm/28hpUrneUo/c 1GlSeXeatNIhN3lDp0lL+W7iNKn80qdJ5aZPk27MdKRuBdt53m0VfylDYbdrCBopb+yaDegGGQvd d2F+XbRlsKBGsewIOaASe+JHFlS5q8BfQ3JX2h5q2w5EHpj6QXjINsgsrymVPCuf/cI4CO0ia9Cu DmNATAMsML5YhE5MRQUULhcRhM9uGZFX3zKSYUW3sZFKylxI7WMyJZeZyOlTv4lbTfpK9WtNZH6t ycrKEu9dxS9KFrSiP+xvoBV63r1niWViZXg03HT387Y2Jvy4pMqbacNau/gTw9Lt1W9Zo2odk5Lr +d0FNsgNemEB4l0KnItKYsy4r64+Pybn3ZozTKtFg7BXIbB3WA57K91OtnK2oWRi97AsditNwV5l B3srwV5lQ7C3lO8mYK/yYrB3mOhxZdj7cqYjQdApv9tPiYDvyqOdCVLhAhUXH+QEv8aOcG7k6GdJ w3MNPp+0wAUUCKS6lW+SQbHjKBDHwQppiboRHqksKbAnFghvwyAaxYKuTdoTvYwsYIFsB8Vb1cRt df9N38QFPjYSm+1Sd8iCY3LvsJG/N5ECFRfnHWoUc3PuveV5+b0uu6CgpODL3Ybb9A23f5Ezi/V2 Tq5zwlFp8h6EBpjl3oNQ4YTjMOEaSk44lsHdKvOuUrtLNlAaHNWfZNSE3CqB3FK3HHP3q2BuqZuX lIAOagY6UIpC7KA2BbvVHeyuBLvVDcHuUr6bgN3qi8FuqZvo8ivA3cOjYXc17K52o0qCVIDdnmm/ VuBd1PRcoy8iLnAEhWKpbu2bZlHsRAoFc7BScqKuJGB4URERiMurgHghk81Ccekrq7oIjMf5eXA8 zF0DkJcV3UHy7xOSN3XpSAPM1r10ZJhwE9UvHXlRILrq3a26e3e7e3f7ku9u1ebe3ao13t2qTb+7 Veu8uwVQXjJ1Vle/OVQbeXnbUDPWeHvbXM111i/k3qYaUY6WEs3oqtlmVFqoqVXHOks1WzMDlJV+ 4cnMOAYr1WeASnoGCGIEZHa3BLjk2K9yIriyBznReGWZ3EC9WlZVg/K35lQU+VfL7qCqjEUdE2aO K0vuPRcl0s/RMpIvGrU3J/CJsVGzCyFi6BEGUj/t+lHbxYc0f7/5YFR7K01zEbHxvTTVmtYoztiS zTTh2iHT7/JljtUav9nVDvlrogVFix4Zsry1jxTRGksgFTjsVkK+z5WQpu4yaYBZ7l0mNVdClLKV kErYuZK1ia2Rh12p2eAhN9iY1wW1B/3yL1Eq0dUj1ZC2mkba5D4Jom+vEmSXNT4HX5eR50LrUuFU xcLfhkkRli4V0UEFKYq6IyDoskLi2xe1HJaUstksIlG+hpUXgRGRIg+HxPlrQJDywq/jQ+E7/NE8 /lCbxB/PY5bAH7318If6bPyxysoq4YZVTBK9UYaZ5eDS/ME3xgsVAEwJpOgpvfKvT9Jx61XHFL00 prBN71XCiYJ25yCJAspcEFEkjaqhf5Pli1BDkSQOyuUk6oSAFQro96rMCgSW5UiiqJLNggj1K9Rb hB94Zh50oFlroIbCcrvliu8TLvSahAvPY5aAC/314ELv2XChxLISr3yHg8GmFinWbcLrWpqocznr 8DmXsyrkwtNhnctZWQlBrfrpy1l56hqXswq8cy5nTdZMj6fyy1kbPPfaq3Du9aiRc6+9esrTa2oD fm+3Ab/SBvzehjbgl/LdxAb83kufe+01vf9+Y6YzVMpPvfaqn3pNkOZ8pEz6OjNmWzSB26oJY5mk Sj/ikaJd8S2P9BjU/y7HZjis/sBHWibp73xkZCbqpPAB08ISyc+qQPWGPsaPGrlK9QB+wuwuPQ4Z gqzwMyTV5JVfTBRSfvuy08ot7cSKJqZGAsbog2Zrd9g9WNmfMtrcgFxIXTnolnNIjVp5XwSlLVmg KFXjdZYoToxZ3vpEyh63TpcasKOSzh2sVE0RVr1eBa3CYVFZxavJhKHPQq5vW6DTU/iXXEA9Qhfs GmrzD4J1Ts5OkMG1f6enOz19WT3NXcjdZhlXkVCqO7W6v3XGVwNw7IZxN4y7YXz5YSSvLujCta+5 frCc0k+B0AcCAPYyJfZCuEBey49WE3zRXJtwOiRY+exkevrx6t3Fr+TAGUZzJ7ANZNrIMF2AyI77 hDpvjNkIteX9Tuv8cQmJaOk4Llpid076YeuYLsB4wXxuPubV3klWH6KXPFLInWH7gVK2ScX7rPDC +U97197kto3k/775FKy5StUoN2OLb0pXMxWvx7dxKrFzsV1blasrlx5URo5GmtPDib/9AQQp8dEA AaKpxwib2sQWwe4mGujuH9BokBhosdwRSX+gnzGergbDWTz+zxQxbJZx9njHa72w4jltVtlBFINi uUscy5i+un+4hRj7uLzxfnifaU94SWKisbpbIO/5u3n190QiX8VodjLrdzJ9zKpQCMQ0q0L5tVWh oNtHgud1ieSWdnZvl+3Dl+Vlv1eJKtzVZ/uV6/KgPvab9PEJ3YZoB5w+DhT6mHcjoR1I9fEzuwy1 2schp49DjHEcHuO1j9mnFe9ACodDn3/vY+Gp8r2PxbfL9z6yp6+32qy5CclFuwnJAW5CYsIc4N5H xlj2JiTWuv4mpIyqwk1IkLLA9qWbkNh7/Hsf9zzovVJCUAAO+mgyjviDPv9UfdAX3q4M+uSp9KDH u/4LHPSJMIcY9Alj6UGftJYY9ClVlUEPKEtq0CfvHe2g92FLHw1Flj73tIGlz79dtfT06dFYeirM QSw9ZSxv6WlrGUvPqCpZ+qqy5Cw9fU/uzjtoYsnmxohv0C1S1rpBl5FqfoNu0Y2AN+iWm2xv0PV6 z+wKXaX7nJ3tfc7cZVXBFc9eD+dKwCw4aHAnoC+4ExC+ldRgVlzMqlIppbK6Wlz+ccIGSeTHgOhM cGuC270Gt8bPq/r57jNz86lhY2aR6JdefL+98f6qcOV957LwdDWl/Zr8xP64e6/w2iXjMdxMZ1sD THrGevXx428fWFHLGqenZXcBs2v7lbhB+o7x/MCo3jFeeKpwx3jxvfId46dnh9u4Y/wo7bDKHeMC O6x256Ja+NPKAbbWDlLYrvgcvC9/j0Gh6fYgRVbqDq5z19bhirpDC0pSAQcZlN4HDzeo9YvscYVj oco7GKHW79dNdJUfi7kDFEpULoUnFZWguvtyd8kCS3Tn4vIbv6MTzaii97Axendz6N0tofeGndNk HWPP/eU37q9AsNqRG67ioxNqA7hRxQdCmYQMX6EzFfnUN7iAKVQAgteSGB2aHZZ4Rupw+tZ8zMmA qzZdjGioPN/MZp3La2uwpkctqQf7e53k/SQ5a3MneeEKoNjJSJJG0zHcgljAbYs+rRafjrk+Tbt7 9/7jf73/9O6+b71bsCwaqtg/428vadYaiaemyzQd7+rG7faiZLWtkrtWWwJWKaVNlRpUKaOgfd10 t1QgkxaGkhaGdTMJAjHNm0l85ZtJgmrN6aAYHMMpOI4BmQZkHhJkCpfkMh7StSIcW3a1zymu9uWr c+eXswq/C1Zxcj8P4J/fwz+vOVT+51//q7pgZqarma4nNV174XOZrZw7lsxcNXP1cHNVsVZUkFzY 7AuLRYUeWCwK5TYP4QJyELRSKB5drtNa195bYTZfuTCbnyuP5m9vfsoXZkt/bVCYzRcWZityzhdm KyMsvwq6/KLmgup1kL5IdYG06rxAuCMRtFUWTXBCtXLgltsWPHArPi6rf+C2vRID/D6pLTGQV1a+ hppgpVeqXJvc+7fpIh8jQhcXRa82E1auBpyARFoWjt+Ct44THO6qdr/QV/xScYilHsP6Uo+hL1Pq 8aBmzbaFt5ioeM0wp4P8vbhKvjSs7qfmr9EtCChbr0bWqksc5i/wlznZnw6VgnMADCPfX8jUAeD5 lBMplcNuDgYskcwNwmpVJ5rdN6xeq2J3PbGEsh9BVdeyqemQHEONO48VPbYo33W/VyS3UJ4ob95y ty4DA1ft9uU8ybrbl4OWjtBDdxqKnCwR980rKnBhzySlYs0pCpvGq8L2SWYG85EMVxuVwrclh8mP xJqSLDlcMFTj0tbzz416pxznScJOOBwUcErDQX6L4rdwxm24iw0BrGv7OmA3oACSktiiXYWpUQuM U+q5se+UkXH6a4qMpQNaFQidSVG7lwkA7MIXhDLVlLdrUzAQlwwFFYM+mXDVjcTVyUP5CsuFpiwx sOrTDl3m+JieCVcqjq421iFi3/y4ypL8eOWzjiwXiBLbLuD3U3dOLzZdEtpgjLOzpVtfySZSxTce 4/fmOVK5iYmx4VSvPOddy+SwGnEA8d9pEhh5ckWz+6CuSsSXbpydOKMcWPN4PlqM46vu3+w8V9fu 8Lo50QD5F/GkSWIJa84biCJffdAyTWFtmaaj8Ui259V7JLlU9RBIVd/c/hovUp0dmW8SZ7PzBa8k rvObAjnqgg6RSxxHIPAkIgAnmQu64zp5zKN5Vxgb29RxPr2yfxHQrlhecds9+xzRN+4MEPD9BXck oHIyHQU4K4fm6wqESL5tOp59nhJDvFx/JvRp8sB31U4A/JvD82/OtSVWC+zp6l+r93lOp16XoPdz 6ieMyA8eNC81VM1LPZwflAFmrrwbdMtu8J/LxeZp1aIbrHNnPAEAd8ZrCroz7ofJeiNtAn+ICPDc Gbc7mDvj0bwr6Djnznj0AHfGow1ZaUHb/bsz7jcquTMelZPpKMCducydcYUA3Zkr6c5cnjtzmV/i qwV2Z/Wv1bszt1OvS9CdufUTRuTOXDx35jVzZ+5JuDPbcev9mSfvz7yyP3s12zzOp9ar1Woxmg6o /Nf7AHt1Xk5NLMD3qREAPaJi18i6uZbIDhjZQZFsI4io2PnM06rxvyuMyZz/VeMNeGU1OSAXpExh /x5csZd2BlXYl2UPr8blWaoCiBE8FiMoigZGDp71neAdzis/iF4Bwg6PF3Z4LH5QHUtwMNKUWH2I 4nWaDkYwcPGaWhpROOPhhTN+s3DGO4lwJrI9uz6e8eXjGb8cz7ydJ/e3JDUMPsajh/litvjjm3U/ /Tpd7Su40Ql8NOQHoiANamBIpNO7soHMPnhMczzWOx7jHI9GkZOO9lgYpSHZXWFe5GIqDamAAEtD QsjF65Hbf+il05kN4zANlmemPiBc81m4piMnGIj56rGbrxy7+bzYzWfhltZghAM5FMr1UZ3fQRna YIjnoxg+Ubzn48V7QbN4zz+JeK8XcI8a7j4lkA/3gkK4N5qTIH5mfVgPJpPrfezN7D0glP1C4BCe 1HvggTy5PpU9WodLjR6QXmXU1DeMpPuTJeFLcbsrjM8s7JLldFlQ/PFfbiqmkO/02m+pfvg/Bsvh YDmwfoqJgUzMMyIcwqYPdjAqB2ml4HOtKhJZN1Xl/zSYx9b9Ir7WXv7XIgaqtTk5aR1qsqgqTKc/ Ae0sHuYZNdxJiUQZ1hsObXklIvIDNIqlA8jlLP+03sxm08UaZf5p0eO4Lg2KCu5NlwvkArX6FrKU jwQTvLJ+WszJf20kg6lJk2M3NakqmE8MTpAV1e7rOgU6LdhUVAYSqtVl0VDPKGzrlK6vH2AExAR4 T+Kl9eFxun7AmcGaJGEtaxKV1ysGI0CT2v1c1d39YrlYP3wj2C7+SoJhFOVp0wS1p01VWn04nKr6 Q+jrqgI/LVeb2cD6kbRbrQk2xVCgNk1QgdpUpRWIw6mqQIS+BtYJviyW8/ZWCfCow2sEePTlVwiQ eQLrA5g6qZbVP/JlMZkCYqXPEVT4AD/fLI41U80w5fplyxVn97+kHlQ2nCFw5ktkXyiLMWPRON21 1KXNafJ0ZBbKZFRJ+aXd3sp0RGLAdUVmuYy5PcIl3nLBmpRaZLm20yyaVQ0q5UR81o4Tnl3VJC2l RrN01ljbTnumF5UPbxyYBbSSdjNGq4wR2lTWpMzRoFlGqypxnHJa7ThhaVGbNEeNZjGtqsYN4/SQ 44SlRm3SvNUFs6Smuq6Q8Gx7VQGPyd3FeP4LzUy1bvzuxb/V1FZPniNyv9xxt1Pu2iFiq1J6kn2E 8BVbnmFGsumaBL5MQUoRB07jy2czitpmsQVtpqJpO94WRPOysa2Bs1vQpZNOaMyl1PYUqxsXt9CB LkRSF4Gdr5zHq+kbtyfpnrRFL3sCrL5o7uN2neDK+mgEZrhjAcErZJJ5uH5G0ylkUrmo3YUk1I2L FGFhyXO8MYLdoolGdvC73nSQkUU7coZtej+sQL1k9luJybBlvQlw9Y8uYKuBDwIG2kckjihmK+AU Ub4b0Ig2H4+IorU5EFtZkGlxRLa0gNTG4EQV9cxPnp5temGxJshI8pxzpfqHwot7LtMykj18XSjI wj+iXSjIIkv8GXQzUE4lYBd1yUkEVkEJksIpvHc4r/wgegUonBLwCqcE15bC8IBLpCjSqC+GEnQU hxVY9iRQLDwgKnAS4BU4CZsVOAlOosBJ4AvvrWWfEsoXOAmrBU52O9TPvtKJyqeCJU9UCHBqnyh1 t3wRlFbI5oN/7bIoSp2f1UdR4X9XGOeFQikqvM8+bjVnEZ/RWUSTlnzyZ/nP+kzOsZetMWnCJ3vO 3hyyOaGaNCYN+ATP1J/tCqg5kPB8DySYiPqZHPQ767j6NM66m+j6xA/hmRj75A6ym0j71A7cKZ8p QkwOPuIMUzANUiNZDyHJO8TurBNLckfOV8M7fIA9itEE26Wc6p7ZQxPJw1UiUqq7OaVw8qcUjiiN 9cy3gM924Q7IqVNJQYCT6xQpHCKZUSlBonFWowqXZ6kKIOExzBIelUQD0xhD9czHUDnzMeRlPoZZ 1qLaWIJTIJsSq8+FDDtNByOYFBk2TTISZUeGeNmRUbPsyPAksiNDL6jPjozksyOjcnYkbkXZQydI mmf7TTg1FZWbhXTPq45z2+Piuo3y0HmbmMukRZUcQlnncxtlFZVJfjuI0E6931Tv3Sx9vuRFmhVI gXvaE0Ac2Az2jw1xp3wBOmrZjjK6RJXTjBQZ6Box6Ip8ZBqCqVGCbDXIcqj+0BpV7isApI54kDpi KBh5CsKIuyVe9YA86rQ0f0G8HrUUyojgfIQH53vN4Hx0EnA+6Dn1cL4nD+d7FTiPWMb10ODTPNsz mDcFjFVh/LMpmtzuaLjGr8Sct4F5+I4ntQHvBrwfGrwj1iqCABkq+QMAd8TJ3iJsx5PSjJA6wN5L ATtmkS8IAvdageu9VuB6Txmu93hwvZdCaMyJB4P1VjjVQ/Vep5U5CwL1XitBiwim9/Bgut1thtN7 p4HTnV49TiddIA3Ut223SF3/BOKh8aR51gxnm1OybVWc2fd53DZ0e411tLdgfHIQWVtEA4wNMD4w MNY/AwGAHQyi+wfB+tO5AH1VTUEZ7WqLc8bKBvDsgOFZhDM/EDIcJChWjRKH0A+YhFSw6oCHVe0u g5AIEwSGqJgM6pHpoIM4v0A8OkCMEEQolIQjeDDUbgZDiQyngEO90JXAobYCDrXLOPTtx/tnXhVX 6guBGEvqPTDGkutT2RgLl9p0PdYsdCvXnwzHSHG7Kw7QHFaRYmXOMp7rWUb6+fPBY/zp7X3j+r/H 3FuII4U2Vu8q4I3CYvX7T3pZIlV1oJIXJ6HoUa9PQtGjf7AklOqwQk0M4gxEVB6coVusFuegsBHV R9bnUFNGT5eBRE09XRYNS1ajsK2rX62vH85gbmOgQWzoxVhpET3sgYxFujqCcSjDQxeHtvyYReQH DFYsHfBGKe7wOesotNLeJNOqKqWdxNaSWlBzUCWK55oQoHGNXd2rNGUL7ury4Y0D40FlVI5zt6dA 1zgMciUofckSlO3cieq2QLyVe2xP8qpur7XeRb+o2wski1pica7sy0qt7UJ7r7Iv7n8zXW69uWF1 MCniz6CbgW3sIdvGlpMI3Bgeqlf+GipX/hpy95JtttUrOT44+8WKROr3hIcdxYEF7vsOFXdbhHu7 NuLertNwb9c+ib3dQGpv11HY23XKe7v612Mcem/XPMPfDzfXu7R1YeK+L5JpQ7fXWHfSFAxTbk9f W0STf2zyjw+cf6xfxxuI1zGI7h8y6U9n1PxjbXHOWNkAcBsx4IZQtx5CaCOs/OMRVv7xSDn/eMTF jA6DewgThIMnERnUY81RB3F+gTh0hBghCDGqg4hR3YYY1TkRjCpRr4r0gTxGdcUYVXuv6dDgyzzD AKVm2/SwmVMH3a1tfXBAEFd/F7hg5Lh4V1d4A34N+D0q8Ku9lVsLjhA4HBoWa8/69spT4QpqRosc rh5DuFo/KwKCtONWSlWNWylVNVaG32Mu/HYhdKw/ETlYvC1u9cB8DAFzlHkMovRxW3GNELK7iJDd awjZ3dOA7K4MZPcUILtXhezzOEsSNPvJz/5ZPXRvOhxAmN6UGAeSNx6q8vC7dRbNr7GtgdWNFZdB 6KZy3RUNTAEuNxXKQGMDjQ8OjRvfNw0CGw1qh4C8jWcu8hZwUznOSqEAKo0zVNr81nQI1cVY27wx 1jZvrIwzYy7O9DLk13z0czAlBuV6/Bh3MGYNiBVjDKcuxIUeIi70G+JC7zRwoS1T0thXwIV+BRfG 5BOIh7A+PE7XDwYdPptntQhQU/EQDtQkCaNB3QEqjQn3xehLxmiVMcLEh7pqTVGipox3RaOTx4qa AhrEaBDjoRGj5uQAYYY+zQOgR925jIshNaU5W0UDqHKSokpdYUEkN8HClhMsbDlRxpYTLrb0UwSo PTc4CBOPfj3OnHTwZhaINid4YYEQc/qImDNoiDn908CcrswR10ABcwYVzIlUsOTQEMs8awg9TZmd PReqO0xZn/Y0f41bJ6hgrPJYFUdcA1kNZD00ZEWqKAQBGjTSBwCwSBO8xVRfHAnNiOAhXbubQl3M mltlfGl3W0noJWTbyOhNyarAYdqLHDwcpHgVa6pxYDE6m1p0bHc76FMUAsn0HlLkeESIlQNErBw2 xMrBSWBlu+dLYOVQASuHZazML5x8aJSngwCPudD0fkpVq/TJdV0168IAyuEXLkmgMiS/JiXg4UWN 9x/F8T9zZ60kQi0umRPqLCjAsVmAIyg6CgYBtvWdnOu3ua4/ZD5ZoB+OM5d4sd492x0JtYIO15aY QEIXGiK60KihCw1PwoUGjifhQiMFFxpVXejyT+vNbDZdrE1+07N5Vh9iaGgdDEM06HFCFZ1xKR/O 7IPLI+USb7kgJjTp6TELnTSkuysal0J4pSGaWRQ2i8IHXhTWmhZwpKtH8BDQQWcKo6YvaYlyhsqF oI6TQR0dUWE45GAlLRFKSFlLKSWldVqHC9aiDHNpzQgOoEMiXg/6nA7SZAKBoYPk+oXgMUIEj72G 4DE6CfDoRzLnY3oK4LFXBo+flqTzB9aPRH+rdbw0APKkntWBRG3tAkGlNk0w4NQfh7LB6P44bRin hxwnROCor1sGHrWlvCsamByA1BbRgEgDIg8MIrWnB4Q1MIjuH0zqT2dUQKktzhkrGwKXLgOX+uLC YM5FA5guGsB01QGmywWYPYYBEWYJB2QiMqgHmm4HcZKBYNNFDBOEgLOHBzidbkPA2TsNwMmDm/m/ UKoT8nmpCaJfMl+Qb7n6wMZUQfrRbLEiMvUtKuY3Kl3aKavxbS+RlLaIy6+QDh8nvqj0Rq5LiSoI lt3Mh2SiFH/+9O4fb9/dF/toRXVMxuB6HT8+rROqTLIK9aIUAO8JlTx5PCbTh8iw+jYfLeOnmbVM Brd/kQwd8tNgHbM/b5azz0+D5Sr+TPrviv7Uf/lythgNZg+L1brf69rOyw5ruhqsZp/pN31elX5I /0rH5nQ+XU8HM/Jd/7eJV2v2ZB7/9Xn3AZZN/umyJ9P5+vPiKZ7nHqcysr9/Xi8+J4JYH1//ahXl 2tEmU/HPmLTpsZ+eyCcPlnH55yrJZaJ22wlfdMk/do7q09d11r5PupXQsNaPfevGJlad9Gk/kz+R nYwH2rafma7JZpbrEWLUv5IxmnVIGUNP1xxwPc39ns1jLyrN45zVIEEpmS6RMxzYo4gZBcu++Gsw XXvkL+BT62o9fYwXZDrazPJZm1U86uxeonNuOt/E8Ns0cLUvvv+++PT1VpNkqn5vsa7eas6ynhZL qhO6pGddka4bENk7FxaZhpPRnDwhP5NoeL0hkV5Kioxmy5oNyMtEPKKLf5Gp/eppadkBMWx9z+s7 keV0u9HFRUWY95s1ITYfUz3/xjRApLK+z77h2rIWy2n6R8bWekuAzeKPJfVBFnmco7ANQq3utUWH 2Jwavg35d5dKmGecqjt9THp6MCREFnMiOgEkZTF/S4259d+beBP3Kd83xBh8q1JN22Vc2cB++DMj 8PN0BQ+EVFlgewLjNsv5qvjeu08//7ybo6t4RhRxQU2lTSj2RTykczjzpVdrKD8SbQz+iK31t6fY SkxOebrEr16lE4ZDqmsRU7FTYa6Zlexa7DRG/TcZdNfwjMraUWXC0pImq8+J7+nTgZL+bbEkcO+O /TX17PQH1seTZRxnJsK62g3JlGIn1ypnSLuZRksP+ulkyh4zA8/MRNXObDuOs4SXkCCCUCZZeM4i sz+odZ2PCT8wy6/SdEEvyLqab2azzuU18Xg0rKcj4O/16w/vypmRENgo0VuObruZpR0sRw/Uh12Q 6OLzZDoj4Rplthh+IX0yItZjdft957LwdDWl1JOf2B937xVeu2Q8hpvpbJxxIrqyXn38+NuHPjEm /1HnALUcAeAH7MAvOYK8u3eK7p7vHhyhe3C03IOTWIPuSbsHZ+cenGftHjJltekeMh747sEpugc2 Q2845m5PfsKp9xMOlp9wMj/hHI+fAOWwM0aJPUwBUt6uhVB4WxF6MFpvyFj6ZtEnMNJxmyAd90iR jgt+YqD1iciwyT1q2OTazwg2uXh+sWdg015g03EalYodsH3YEGS/a1kCWjD2CExBaQXFhmPkkd8T 2IL8U3VbUHi7YguSp8diCxJhDmELEsbStiBpLWELUqoqtgBQlpQtSN4DbcFqRl+fTcmH7ybIp9/e 3sLu2rp/dys+Q2aVrUu2+n114+fjQeXVBcVoLZtKdeFaLpLpZ6EM7T9mS67c5M9TQnYWT8iobthf pOlk+sfRdI5kKAv0jZvrGwfqmxkZf/GccCa0pl9JLHgVdvpWkmlReA7Gg/ZLtidyG7HNg1evX7/5 9SORZvFovf31dmfZXb8budZV4Tf6PrAhVLNFFKltEUXSgNELhCmJEd2DSXZmwPXD6SPHjTzWpbIJ jgdXUla4bcE0FfFxZv0D0e0dqeb3idyR6lRZdLcs24sVWMDHeP2wGJORGV2k6u1bJGKg1RhuXbX3 s1QORoQubYpebSbs6OH2w9tffv35jUUindtuTmbXYn+oIUFsSs25Ys6ucyopXpZzsmncC6W3nFMB cjvO2csNN5xbsya2HdabE5uaE7beVE2OnZL/DUW2o9ZgSFiJhhMb9TXQCIAzH/jiD7+9/hHaPiBB bJfEcORf3XTRMG+T026lDbI1+3Sp/3W61F/Rxy/bVGXymVSXo/VytuKmpnM45t/tWwsypC7tF+6L 4IX9wqP/d7ou+U+P/N++tK7mC+LMCaIjHrcq0FTMqfTzULz4RvSUk2tORibdHEmmFpnBtJ8G6/Vy xXYr8gM46f/hYBVDlRqs1Yjgs1vHGsckcCf0WGffXpY6+7JKkrK7pcxSg5rNkto9nnSDZUQBw5iE M0Rmrni7erl2J5O1kEE2g3mkTQjQJbZtFOeYFYYR23ACBCJqJ0B2Ml2u1uR7Ka66tekejJXiVbYZ Rb+RGV4rShwDlJCWM5mRE5RsJtEqn2L893T9op6pMDspz97vlU02Entegm2Jvddth71qxlaxT1pS iVYRqcKgCRy3BRFlk6QvS06/lSGcCLNTorJUBLK0I9U/BsvhYDmwfopJUDTXLg5WENrx2hL6y2I5 b0Vku1deaEcS+X6xXKwfvhHFx1+J3E3yMIuC2uVEKiRB3368Vx2dPbcNszsqXzlt63da4OxDUP27 sYtSh611b/Nb2kqDsS0JtSv7F+XstmSQ0Iorlox+S3NcVNstJ0DgteQKNU9Al3Taa0dIhMz5gqDd sIE2RasgNmLqfZo6b0PLIHY5OisgpTevKFYqJOCnVKw5/aJpvEqOkidrI/hZAGZPsrwneQbJJNU+ Djl9HGL0cXgU+76lFJDs084+B8QNTA7I/nJAjjLZYegPBYM+/1R90Bfergz65OmxDPpEmEMM+oSx 9KBPWksM+pSqyqAHlCU16JP3MJMdjmzzPnMWmrv3Nk5mw9lkgpSzHc7xRCNK+Ms703hSKXmnEprh HVtxzalGc6rRnGrc22mVMz9DSOyuOUTYgjU2hwjNIUJziPBghwhlwUj9wq9g+V1hOTgPVerwx15W mZuAnDZXpk97/8Asru+mnLoUtcCPK2YjRMj7NiWkKIKy4TEs8XuOWuRSu0YsDTQbLSYrxENK686o wZNwEVs6spLW/54BMf5wM4vrR7O4fqD14yPZCsgHjUh7A/qxp/7uQt1aennvoX4tHS0R4shX2085 k0MyIaitDQWFrmsldDb7FEexT+GZfYpT36doBYmazQ+z+fH8Nz/qIoOz2Bxp7ALM5shz3hw5TFRc jSMjThwZYTi+6CiWYMvBaVS1XEM/6vb4uZ7lx4q2qfJ6MT7dPj7EAmjFOm2l2XuEuuUsZ5+2zesM VI6utIXiqKzeRG1fxMx0PrGdVO5sPfotVp45Qdh6rZ6yQFocO/uUdTDCMqvq576qrrJSHTVeZ96t JB/LMv5xZPR7Eqvq5oDmuRSNPT+n5HvGKRmndARHhcqGeDyIHymV1cNmPV78Nc+GBflAMhosZjDJ 315IXAjn0CvWIuGFcLl2F+mfJ/QddhWbdUXVN94KI3MLXVR/C12uXaGEa3OmHiVmd+u5pg0v0r9M krd4fIt/71vUyGWlGW1r/UBlSIbDOl4+Tue8vWenXAjSDiq1IclPheKQXR0wpjqSA7mRXO6O7VhM ymqsl05ayOIyrT3KIqeLXFW6vrWYjf45WwwHs4vRPFEJbUHe3RBWxEy+h9smhD99envft6JJd+i6 tnPTm0ziG7vrjG6I4ejdOG4UDSbOuBf5w4skZFksV+8Gj3FeFBbKfCQejBjox6d+4gO6nh3YjufZ zu8XhOWHxPtSVrYF2Sj7ZbGVA7ZySq1csJX7kn3a6w/vSrK4L7qR7wb27//O3Cz5j53+8eJxMZ5O pnH185IH33if5/5+ccmtBMwoAGV/2QOwxi97JF2Ot3lzXqneVOjrwheA93Tv9/PAu7JPRT5anCab y7n3rJu7xNX3Rl5vxCtPQ6LdtEpvt3F9Gm1qtPAlmwl9q+56at5Nbex9GsfEyzkdbrtqnTyilVeo BxiMYrZRkdwTx70YuGt3xGT71uaJFvDMXfXbtXmFOXG78/Y2Kyw9GpBn5IVZPCAAkDiG1COMiblZ LoiM1E1Q/7j6RuKVRxp6LjZLgm9eZK5jvXh6oqHL/wMh1M/3MtwCAA== ------=_20080416144959_68772 Content-Type: application/x-gzip; name="slapd.2.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.2.log.gz" H4sICMn0BUgAA3NsYXBkLjIubG9nAOxde3PbOJL/e/wpUJ6pWjmnKHxItsQapdaxnYnr/DrL3qnb qysVRUI2LxSpJanE3ql892uAL5AEKUqRLMlGpjIRgUYDaDS6Gz+AxN8bvx6g366n2Lk4Pb7RkG/r UxMprXbrCTWOpx6SD5EiSV0ktzVF0ToKUO/94unTRx3bf4/+1T4Ek+kHF5jYpj794GPvG/b8D5TX HkkaTr8FwwccPLp+MHp29Ake6hoiT/2IRRN5fWnP1PHEdYaWYwUaIgW1Dx9s19BtQqr1JFn5kKOx /AA7yHVqUcsRPTQOBS4iDW61WmELZ549nOqej4f4KWjwuR1E7LSEDyKMLd22/o3NhZtA6sfmXijy MDtkFwCzUIitvZE5Go504+swrUljakWfTj8hko8dk0/7CXtfsY2fERC2W4ctRdZQY4CnAZ6MoAPK UZMM8NHB3uOcmr4wNXFpa9cUcRn6ge4Fs+nQdaA0fbCcB7RvOH3DdcbWw/5e/yOkewp2Au9ZQ/sm iD7J3XNH/4eN4MTWfV9Drm38Ybsj3d4zCFFEYRsDKsfzUw0pe8BqZgQzT7ev+UVpPff3hLo7lvRD daS/743H+L0sKcb7blcy36vq2FDG7a7ZgaEzPKwHrudfgUazLaPp+M6aYOjVZKrRKSS15UNZabdl 5Z9hRSeDq3xOSzqUpPbRP3+V6J9fo7/wZ2/imtbYwsXKaMZzRWX7ex8/fkSmc+PhIHi+cr2Jbmvo 94TDRyJmOglG3xTTaSQZTelg7/c+N+ugL6GkmOkoo28N5UhJycOknyL//fffqxrdzPQg7GFIRpXx 5bsXtrekCdvePiiYTDSmHHr/EUlPXUXF457Bm40wd071QB/pPu7/9V7+MfZcJyAWIj85Y6oT/tz9 HJU7SSZuXEBDWb62caH7waVrauju9v6MJFzqT6fYw+NTsDWPGpJI2i3WzWvHhnZ+Pr4YULKB8Ygn +ukVnTyD2cinz5SBC2bM9cD6xOTlpiLXkbzJGOndrMkYv4DJUBWZMRnK2kxG2WjnVbiMrqjRZZT1 FHyNpbnWp7T/zSrZbPvc3/b2ZWxT6aAxpgobpR4vmfacniV53M4lubX7t3gJP1OizAGmfQh9oJ/2 6Y12e55jkn6UhIx5r5RxO2kpcCeuG9z8qYERPf3nf999nt4O/njoL+8ldEXJegn8Al5COeq+SGDJ FX2li4iJ5viHmGwJ876qovPdQtLhvE9IJbHtBnfb21fuEJKxynoDn6w2aV0e9md2QBeITv+9DGtw qA3+ckiw50HeRA/AyJj9/X0U4KcA/t2jSRArDr2ZjYczH9NV8B6CP3JLaXXbUkuW1U7nsCW32i2Y MahhgY96wN4nK7j2LknxAw3FbG6Byz0xOI2y4lfHl2fobwUef0PHNzcX52cDKOnPplPXC7BJYJx/ wGS2XAf9hqiI7gIbfs4s82pGF+K/oQfmN8gPjJQx8zzsGM9JggNB9Q3IhKzIOWnHs+AxTD83bWqQ 3FkQJTgmfiLGOvDOx5eWc4EdXob+xMs4dp5LkgcBnjLp506QEF4QxGUw+Bw+ZVYDYdItntqWoQcg FCiHvW+6HWYMXOPraEYac+4Y7iTpbDE97fDdIxhh048eXNfOJJyOTnRQmM8expmEAYFQooTTKyOf dH56UUiDNU7ye4B1z3gcBLrxNUl6nPwnjgZsMB1gn4y57T6gA3RQrowqq4zHjrmoNqoFbYyZCHUU 6litjmor1CK5JbcP4afUA91qtxTUMMB6nz84rofPjzuVKlnKI1TLIiNWLXU7CPHARBbUW8xvohw2 8exJN4IlWygzLczwWaSBSqvTktWW2oH2YC+AuA3UCMfNYSnaGQpaIY9MQo0wJj43YXLSOPCz5fnB iTuZug4kVXQ15RH2rAYjro2APgaeS6ZAknT2BGu6yGgkiZ8h9p2Bd4Y04qgHz06gP8FjTjhKLzFx i3YFimasW90eCCsnrFxOCY9Q44Fs84R7Q2SsaqjfUaR+vJKs4uWWgdCc3Fqt0BwwB1PPDVzDtc+d MQmrybhwLIICAcLMsf41w5d024ZHohBmGCLmgHI5Nk148nmUYF4CbOPpI0ygUPk5VDLIyjUCHAwC AsHOl5McyylfipURxOXeDSzHv7uemSiF9zwNyPjlxCMfosbIytXP5qchfI3W5QJ2YTaE2ahrNmSY fSNoJtadGooWx+JsCVbRHnUfhgT033LAXESd/gP0zMZf7m/Cxy+WaSZjE26sRENjeZ7rpf1K90ji cQo3WOInsuWPL1z362wa9/rKBR9tJJK0vOCZlIoTLiwHJEU1JJbMlXsTGpY44Rbbrm5+galUEJXM ho0Xls+Lb7qo4cwm2LOM0rl9xIR2oQIDHc+YHTKE156JS/h1GLL5Y9jJR4Xl1mJwPLi4xMaj7lj+ hAzmN5jerkdQu+QhtSYwqeD/TphpOKFRIZGTPgKDbN7fnsODiX3Ds6ZBWCQ0HBBufrZszD7DyIWP x4YBqhv9tm33e/zbe/DTQscByHA0C/A15eznUu+ep7Eukol6fnqLv3tWgNOkf9+4YAKemYRbMKRP kV59Ck8PRFoUQT/Rk+XrTLNOreCE7g4ERPB+bJEMexYr9YU1sQI/tkxMx+HhAlTajnXfBAYXbqy7 4fONHpsZBv2Nq7nOBcNRKswSW496Fnsn6pUGEPp/pn45m/lF96NKbiwzbd+NPXuwHPZ3pvm3eIw9 L7ackUnNPGSHLErMVEHSsjz/NbO8uH+3mMwUI2otgcdPB2fpw82f0QzWffuL6wfpE1gAe5I+DrBx 47nTiCs8zUAXYksZnd2InsDc0vGKzb4X/EO344KpnYsSwPJ40IPI9IPTY8reXQxOjk/S5VHayXxO OsYkp6xEmg5WPptlTR+xN5gl+k3Sbi9OHnHsHMKETKFb3TEzCTCtIbo7sa3EMkLi6Zcb3dMnKeH9 1IQW3NKJH1tc0EHXe068G6l26loxlygiSlmAc0vNMVhocK2nOMBGYo8ZDjl73GbNcaUhVVnKCkua wQVqRM8FCEDYUmFLhS0VtnR3bCmB3NXD1lHv8EhRujLBEKm99EzeWh0iYBPiXrCGM8t/xCYxXzWW DZGd5BctwAzRLjSKMIZ4oxgRYC7agAeFoYtXFC1iT69Ccwncqc14omZBty0wLmY4mSMWJjkMbBGN C2ARRqgKrSIVYXxs+24kSTzWZwQmJYusT4m5orPmKhJtdNArVufx2HpihzXOgcWFXsACOIjofJmW QaArBD1JM8OjwtGxWea0cGuBI7Xhv+HpXXM0JIeQk7SZZZvD+BQFOWJBBbm/Z8PAhyV002Szmgxj 1xgaRKOHXmjczFAZUINDfdBEzFEMtJ8M2kmeGfVBwCsATwd0aaFSGsMpL170JVW0WTc7n2vktEoJ ucdFSqmTMyPlPWXmZzVRihVWV3cyuColyEz/aqpnprqc7oAr1ZBE99I1tOKNeWZ6gNbTx2F83H4I a2vrG0iicQQzmR5xyOSXHvmnDZLQ2Ox30fHJydnNHRp77gSd3/Rl5aglwX+y1jlqH/ZQI5NGyofF YahhVpMXIBpdToqGHtyAdtwyocNMPsGqKAGVNJnJY5e8czCdBeSdB0o+gr4Bn6EDQsg8aCjQH5D0 pErIxg5SeqQKEsD5WrZQ1EMqcdMdjizyKgEQ+IbujNF4EqDGX9YkOECQqOVzJj+i9Nd/xpyV06fz q1Mo2WcsK5qQF1xM0IDuXiRGDX0LFxF9tYJ4Pl/jsT84v7y5OEO+PybvySTsVRT+YOkDN2PwS+aY FE8xdaEpxpJOYUECbmbiP4AmykTd+r2jsCxVk7E98x8VDcltNHomACS0zDdRtse3Z4P7i7tM4bC2 7Zk6cqc9f+7IZO74NCopzJ6JBX9Gb2aiDG5PvmQ0UgGLD38k8l/BgERiIQRjyw7gdxyBUf/Yf3dQ kOflj9jqQDfIWBiBZ/tFsZeYLE5ZDbmgEvvs7n1bkSBYbvVIEL6PGo4LiyCIt8A9FBtkVdeUSx7x k+M+wTgw7XJAszwDxoBMDZiBRE46BCaQ9Q79R0YBqdzpQThW+L4BMV5fQSbZaCGejAq5v58T8n6R FammTyoh52tpdEnVO44QCT2MaNZaZSZ+W1VzM58c3SvlhJ+soDW/MgaqyL5dUNKKw7a8hlZwY2C2 WlXtKXnDt/LuJydnSxrRkaXFm1DlMeTVeQyFGn1ZkhdzGaCcZ8dEPRnPkTBB5KCGZ2G/3942L9Ip 8yHsA+E6hv6isW7ZZAnleY4L3WoMZhQvzLTesF2fvrNEmvlMWhdJySfBKmkpocD5IjAAJsW0ciUY GSvEmc0cGgqyqfdXJEDJSojMAohAwFjgyZQuN6N2FXhn28CpmQbZNNtcZfQuz4/ej6SVRO/yYsoj 1w9BlMoIRF5L9P6R7/aJt/+YqTeJWusEwRmaElMjbzo4lecFp2wIrkNs8DxxZz5KJsxWKI16NF9p fi5srdSQMAzcp2HfeqK/NBbK9IiJg+LwR5of/lQ4XjlU3KxnXcCxytWOVd64Y5UXcKzyko51bWr+ Yo5VXtixyox7k7mOVV7ascqVjjVb85ocq1LDscorcazKYsqjrAoWUwQsVgsWU9YEi1XyXQcspmw6 8lBWDYutbeocKtWwmJLEF+GmQCk+w6UGW+qgktdEU20t8MR/Tf7nz/9NIoQ52fXfX22Wztk55DXf aW0uOGFfjEn9N16bGQsxV4rsqId7S+GpX9ClX+hWUXTygJyd2PvllwnMQGtqY/RNt2fYT2nSg6pA 5ToRQZOo6EPwiNqZii6vT+uBKPlCFAtjWpSruXTzc56Iixuh2VfHf2orlOFWRRMeMtnNbUvmeEoV TTpUL74Buu1vU4v2ifaJ9lU2QXxcRHxcRHxc5G1M94U/LiJCPxH6lYR+VRjDz+G9K2XGBY/VxRAL OYsaq9sJWbwYVKwsDBUrDGCrcKFiZWmoWKmEiqPc/keyExQf9ffI3rakhh9HDmckl0LOUBgMKhzB zTR7/teV1Q8HdUnlmNTXfZsifkN/XgL/kUyC6AvG1HrDvJ2X4+Dvw1SOSIb/pDDHcgJ6mprJjmQT Pg8Dd0i7gO5OblC2Rylv3zW+YqDpRh/OBlHrHs4nF1l6VPcyMLucfns7otdgZIAHCiYaei8jnYyl Frefth2UktBqyA91fTyzGYmEH6VOBFJAw0vA8MzxqOR4TP5QDmO4wHVTB9tRD9tSaJeQvPddt4I2 PHBzUSOIXmyXw9CTfADAOEgLkYlvOTPMLw2GHGp49y6be5KMJNiLdygUdTJyCJEj+hoiokaoYYYv JpCXCTyQogM5CiKnkYMZhO0RK5gQCIETDUjzYCz+BPsSfWZdbmvttgYmlkTCe3uFxlzPAmAWvuV/ G44AtAq9i/vQRMj1rOhnWC06h2jSfSBfZyB7pS7DwYveavKR1ERExRxifWfwf4m0kK04Gu4oGyQN UYVjug40HeKyfDNvI3+C/muGZ5ju0Z6BTXouco3o4lpDxX78GjMgr3RXDRaXHmLnmef42XJX9xcX 6Rz1sQ0DsUfstQwctao6ljqeMYczRAe+/oDDmIG7q4SPj6MJU8KK7MZ+T4eQIQNf731lRmwytTEo XZM/o2I6k74uUkLiD6kD1IiiRE+uF27yk8couKCHAaiMxx7GsYmAIDhRyYjjAUPFGFIpHtFchhZN pjg7dA2hmSjamURwJUcrKQtoCKkktmvhbj2MLwQUw/gMQnw8wEiOB7C5vkXkSpPCn2m5TLH9sI7w vZqoJpAMOr67ux2E5zfrOKJlzS7H6spy3uyyTl3JOvVyY6xUGmMlNcYLmWGFzjppp82wkpph5VWb 4XiwftIMry+oUotBVY8fVPUWCKrUkqCqxw+qaBDMVEQPVxj05dO0/P3teZ8fE6PTq8yedz7KjZco jfdgV5ngXIvjdzISYS8abfrbgqlv43GwzJtJ/PhfGBBhQDZoQCqjrbiO2vhAp1c3kFOygVzo3d9T JKngiJ+eSjy0zk93y04vTNg4hvTBdIaQUDxZYf/1Zs4fFfr+Z9nhD5HD5rCasTkUnlf/tm8RCMkJ yW1ecpu706MoxUH+CpJcL16yrbzbRHLNYa4OWe0XCNiy8S105LsHJGDBnkP8WC6i1226cUBeEIA4 cPnmHHYX2DNasneL4vP17lTcKOkC2w6Eq7iPUNxHKO4jfOlTGGm55OTFWDpsr/rrMau3lRmkWYAh AgzZKTDksFd7V2uXwZD5n5Oofb1l3Zc+uGV+7tLKNfFZ6BrMihdASuS6eRRE5CyGEW31qlMACwKS 2ZjkXqUfyY1OnT4Wh+0VS2bRbu6YQRUwXhWMV+NDZDuF781704np4tyXnXLZn6NycXbmXagM3+Qa Gg3d3d6fkYTMLUHkaIWbXj+joc/HFwNKFn/2mYJRicJRBsndNTH50i9XjfRuFoIbvwAEpyoyA8Ep L/NyVeYO+5rmubZR/jlTvILSCy1sqpYzuxKnbG/7yt+4YgdNQH8C+hPQ3wtBf6raO+q8BfDPKH7F lWMT8yRc61i446B2pLvSgmXbVIVuNkt6v3nU6e3kCPBFwFabl9x2WsCihIvt5Mp6m7szt6kCIHpF ABFnhHcLERJLGbGU2fGljCyr3bewkhFfrVzs3MKSX63c/Jrh7eSIGF+sjrZpU3+XrWrVRj6vX3N2 8XdfFAt1TazKXtGqbN63n8UKTazQxArtBc+ZS/IbWaBdf8OerT8Tq0M+mDH13G/Nxd3qEly43nYJ PrWd8DbyLlsTLjMqzeXHc/Prqm3OESsXsebb/JpPGOrF15NLyYy7zBTSX2oJ+xMDIFa2272ytU1r PBzp5Ivj5Naj/eVGu8AH6tNQ+JFuDYkzlWKZK5a561vm9o6WXOVS9GqCTYt8YZ02MfxQSSY9H1Hz A+2Spe81Pzko4TLhJ8ch/E9+JGXuV1F+7hWL5F2OkarK7EU5MEV77xW129XHitnrdkbZz7XI1B0U v3WT+6gLl0rJUalcKvVD2UsgakvqgoKwL4HIP/kSiCq+w7I9S4/tbd+877DQG3BE4CACBxE4sIHD Cu/YVsltKr3qO7aP6tyx3eOkZD7wrBZu3elV3bqj1o585tyxrYo7tmvdsa2u6Y7tSr7ruGNb3dgd 271Mj2vfsb25qSNL7NzJNUJ8sl14x130jqs939uWu+pO7B+Xua/6+8olvlMmvjPsS7GwBX9Gb8ZR Dm5PvmQ8kgLmCP6QO5OkMhyDEMQX+DQYgKL/7qAgz8sfDMxBxsIIPNsvir0aOWHLasgFA7wvt9TW YUtutclfRVLhnx78lfdRw3HBUluBBcav2CBrIYxmVA3dwDgw7XJAszwDxoC4RvDARE56EHh+eHUR q4BU7hR3ZoXvG+4Uk4sMydc7gE8o5P5+Tsj7RVakmj6ppCqEWPjWS4JMhRcqhZc+hQgVYYjyUVIm ijhU5FwYQdbFpZzwkxW05ldW4/Mx2Vb0DtfQCoPzjlKmWvIueG/d3edtVmTiOLmtrKcNS+2jZIZF 6izespWqdUrKQsJxAWJdSoxLm3jQfv5zGrzrYGECFIPrXl4tyvwLlaGHmxxd4zidCmquJ6qgr+1v XoJHmSOrkk5zvvw2f2bnteWIkzTiDNLmJbf7RrM4GpV94g7Ra5HCIt0SZ3J28UxO9aju8NkbsZ+/ G/v5FAN7CvjV9VS5w6tOHALYFt+/ve0ThwDENofY5lh4m6MO9FYZMWQ3MuXu0eI4k9gxFFPpFUyl 1e4YSu03s2NYisjKYHd8y6m9sK6i5y+tq0rUX1y/EJdSbLZSTs06stw8nvnacgTKKPDZzUvu9ZhQ Dk5b3Tc+UvvK5LFY9wRmu6uYbdW4CtRWoLabQm07LbkjqZ0jgdpuc0Swve0TqK2AmgTUtB7Utjpm yOC2UlvgtmIyvdHJtFLcVuku/QmFVwPbKj/A6kDY/TCFWNN16i61axTjr7hrFKy/8N4Is1Jkt44o mwtIffO46GvLEWilwHk3L7m3YXM5GHCtfvOh4DcksqW6LtDiXUWLawyvAI0FaLxJ0FjttHsCNN7m 8GJ72ydAY4FzCZxrPaBxrdCBxY4VUAYBHYsp9San1GqP/Krd3luHjtUf7hQ7hFHd5Xh1Cf5KvLpM /UX4C/IpRYjnSKxZT66bx1FfW45ANwUuvHnJvT6DysGA5/WRD/++Usks2k2B8u4qyls9sgLgFQDv JgHeQ0gQAO82xwnb2z4B8Ao0SqBR6wF450UNmXPBak8V2K6YTW9yNq0U2+30uu23ju22fziWX3et XUrMX2aXktdfYa+dRSmEWy6Y5lzJbR7ofG05An4UwO3mJbfb1pID0lb0h4/PvgIBLNAlAcPuKgxb OqgCgRUI7CYR2N5Rj1udQGC3xeFvb/sEAiswI4EZrQeBrQgYWPC10+t2l7lNqgilqlG3qHMNf888 ewgD5OMhzBfu3b7qh/9v71p/G7eR+Pf8FUIOBRLAyVqynj54cWm3XWxxzRbdLQ7ol0C25datYxl+ tEmL/d+PD0kmxYdIWY7kmHeH21h8D8khOTO/mWucdRNvFiic6sOm9CH7CXs0X86383jxkE0rTlkm fz3sRb9gku2cwpBkUAxNJGd9xL8ftukD3hifv/nRovu1r3uTTv5IttB9Bf62AmMGi475zla6fobL lYpFnNW7+nOb5x9asymsxNo+Di3AhmJI1mE+BNR9sD1h5qG12U0mYEPMdguCKBt0WyhoUhY5zAUh g6loeUWAM9rIOh8azdTCiW3nK9pmmBqVumdqNr4WVLE2ujTcLTaxTXGqMmsbNMfaIpa14c5UsDZ7 z9rsplgbbliVteHc1awtr1WDtfEmS4W14XLiaOGTxRwMfL9Bfv7pw4jPPKx391SUxTIrsWbxfAEo cnXjZXwGntT5XrGu9lOTjYLMRTMVYsftlkV07nzjBNx9U6pmaMXgvQLo9GzBlOkFwUSHOReFxMKM 4wr/PQfVLpIZWMINhlJ3YSh1MAmyWOqhoxJL3e7zPlGqN5cJCY1yTEQxoV1lhYfrS8Opu8cKp/4Y L+Nfk3VvOhklT+DNtEjgn5P0kXOtFubl3rSFuZUv38euQfRCEtOkV0UzcrLI2OvCIoph3tXKC54E blVodjc6IDa7G5ViGpQZCNkHNjo7aJsbnr3V3eiJNiP5A9Y6gyPMeTMYzjIFg7z6hG831AAmC+hc 7FfAHUFHEVfM6LJB7Av2FWZJymUA0afoLC0XIeiKYkVnvJz8+vM9XIM0leAlGqyweLtNwLGJKsU9 Yyune8FrG7NelGHaJFP3VJi62xBT9zSXkafu3CqSMnXvWEz99cilSDqR/DS/JikxT07m6nonv40+ ffjhx/9+a4FnyqhPVD+w8B9kfsDsyDjTAkbsVTHiakGPmA/3VdiwJ2LD/dpc+Hjbx/bc6v2DeB9+ 4LNK6jn4z/hsNgsKsk6uSsfqw/DuffhfholkZIEZcAj3oVUK4c7Q84cvOecZEbHuWbLLo9eTZYco kvWlIJS1fWldLVPwrJhv5+CYYDs0l7dU+jzmf87HBOaB6NcSrKz1BMwB3B1gF0I6wQD2IAmGsCcX IKI7iitOEn8zSVfJyAGnN3gLg3owkUeXJSJfslXBZkawERkbOSCg+JlUVituuh36NQOnOw7Dcrs0 sKYCwtN3Q2OwapQPp6p8aNYZgeucdfixdDF5F29jdAr+Y38ZT8diAyRZXva6JcutdqV6gRq49zQp TXpVNGvfstOkNGIRWylaVZCn1hSBVss9+f1jzS06OoiKLrJWgj9oyLuFeblvQmFu5XefvAbWylAy FmNabIyyW6bcSd8ISrMgHws7Ma9g7OrDMabYp2CKzb21d+5Ub+BGIxlcr/KSQMpYT/eqcDzVuJgm lapxwDUewP+g5dvQ+oDt3+Z/Q0nE1+++tqYZfzHr1KzTdtcp95ToMo1VKFQajtbwO7f5NJ5+ZhrN NJppbH8aIagPmXhv4/V2t3pIlyAj+gEvAJdMicv8ugDNxofVGf6K10tY0421TK13Xz988/H+uw/v oc41sWbpbjm15ktrOl8nk226frZu30zHQ+vKub69+PZpBT5aqzRdW6tkPYPjWE4SZLaw2c1m8yde 67d08/nthZcVpI6T5Z8o5xVs+BoXfkzBHShd7yvJPsBhTOebeLxIpv/OEIK7dZIn79vaplayhNkY mKXsvWZQlgZl2SLK0u8HkWtQll2W4HW3fwZlaQwdjKFDDZQla33jc7+6FPKxEp1Zdc+IOwycJMCd E1UQZfVg7I6iQO2ScbBTI3x50bsCL+oJcKReEzhSj48jpTrgCzrgN445VR+QLbRSFQzUZwZKzpVL g5pz2tLnRjAB90shkJVK1Qay0qXLQFacqnx6NAdkdQbs6YE783JAVvkis+huqZ4tOLfwbBEuXaa5 0qFTsbT5pxFv8qXLu+KUwvWhU0q2yH3mDOMt+nHki9HbVKr+oqdKM4sepbZwZeIuetSZFtDbuGHl ZY1yV1+Z8lo1rky8yVJajKicmm0orw1l21BHZhlK10xZhnJhYcndXbbhBFX1LXBG7qeQyAaeJOs/ iBmDYiqw6Hr8HZXnmyJhnSDL5gGhHodwoWS/0jV4tb3FP7M3EPxwCGq9n88og0PHmylPxpczzCZY PlUQTgAAoV5n4PILpXToIgQndmgtpwJJJJs1Bcf45dVyt1hcX/aseAvBYoVQJBNdLrN3LKfG67xK kGk+5ecAF7YixxACVzIU6hCKP+8/fv7u48/374bWfYrfoXBX/5E8v4HSQ7Cj5+tMLHp1M+hHYZTf WrPbH1jPq932IccF5ZiVSYFZIVM3c9gz9An/uS9HFcteBOPdfFHcM8FKsO4+f/7pE0bVVFyND/IS wnESYttR+dzhYRLcqtOHfapTqQedPuyDvb3Th/NgVzp9jvFg7+Tpo/Ngl5w+BmBj5E6vQO7UKMDG 94Izx9d8BMfeIn4e/dP/Avf0ap3+2dM0NNWtgmt/qluJsllqtyoWQXq0p6FXc/baB7J0OcXY6RuE Q/sIB8OT1dAT+nTigioMuZUBG3UpbnAc1X1tE8chlR9qo9aVJZP8O7VA0vZCIkqnWkTpNCWidHIR pdMdESW3H7oOPn01B5813ZlK/BaW1eRteTj1ans49QkPp27Jw+n5iY8ZE1TdE8hYphrL1DYtU307 9I1lapdfXt3tn7FMNRoCoyFoPv5HrWsEedkDXN0EBVEKCtKGMWfLQUE4tpRjP+i7biQypiwna6r2 meK0ZVmR3IY9pVfmeUVvXty2rGhZjesV2avYHlGvMt8TTFk14ysKvubwIPUfz2R4EOd44UF85Ene k3uSj5Q8yXu8T5Qdhs+6wvZkrrD9psKD+CY8yOmEB/HbCg8yysRCuJJMSCEsWq+zam7zJVVknvTF OUQPH7895/oeRSt15/ptchTbd6pZymHO9TvnqqANrz3YKT9noRvn/Md1zu8zzvk5k6DnpN/XcNLv H+4Kn+eivc9z0S7jR6C7397BDhNsqajFWsLnL7h4dZJFaUVh8g6JwuSjsEaeThSmrAhBaacchSn7 WiMKE1k5JwpTqW18w82iMPHBvkZ2ceqyCzUcaDSWBDSlUvVBCVRpBhKHUtuQW3ACmuLOtAGJQw0r gxJQbgVQQlarDiiBM1kqslpcrkmJxdlYAJRjnBoh8utkxApCZLiP9roSHiMmUmswYrI0y4i1lGbN MWJAFw4jVlCaHYcR6yjNcG4VRqytNONNlhojFirNjOiY4Lq2Atd163Dd7npyOQ7XtbvNdRWvvyfC dZszVRjwMLmG6zbPdVlLZk4bDdldUzUf5hECVXWAuTW1o/jm1qUsr9YjRMbYzttDgqfhIYFYGBwP CWTqQdyY4yHh5LjxUTwkdJEba3lIqMmNdVEwoaPMjluFliMi1IeQG3XcowFVv8aUM4/yd+bBEcy8 d3/sR533zp1r5xxf1UDGm4CMZ4Z6ueVVB/GelegjkdmLzQdQZiNAuE/WFLGLFCBbhP0GbwWbD/Al W97nhE7brPlymjxl0F+QcgUFHzw7JdR95cy5OBa2gLMny0k6Ta76T/h53beveWQ+S9uRCh/ih6ks Wd/eXRCe+3zci+MKnYiXk2vgXqjiLO4FJbehtvR5uBfUm1ZwL6hlddwLyq6Ce8nq1cK9cKasWm5T FDwzKxJFRxoVViRlKMxZWpGcAUsuW5FwWHLoBLHtSsI6kKn6EnSqNKPPRKltsOOAI0FHnWlDn4ka Vpago9wKEvSsVh0JOmeylCToqNxrtiKpz3X3ViRN4g0DZI3ty/CGHticKnhDn/eJMr0PWNN7X2Z6 HzSFNwwM3vB08IbBKeENdTvbHt4waA9v6FO0UscbtslRqvCGgcEbGrzhKeMNg+bxhoEG3jBoEW/o 0909BG/YJovSwhv6h+ANAwTg83XwhlkRgtIM3jCojTckK+fgDUtt4xtuhjcspPbg/wA10NUai5jR +a1+nlarDmo5LjNWaMYK7SSs0Lyofw5WaOlu9GOSZvxAfl2TZOV4ZRdnVvS+3kAFK1kF/IAiEnL0 ULKoTmPLZizJjEXRUSyKOj52M+9HmveTPZvKAVdk4+AEVunwsBVO1NJQxOelsVbrhrVahmyawGfE NN4m4GkjFJiQJku59IQyvVpI7cHAswP0eftMNGZdFU7xC6MwTrYhmc9apltsfpW9eDlDQCLc2Xy9 2YJ/4fNsZBNZoTf9aQpahzWhZ2wm+2n4OUwZ0kk2YGmaJPuGMa6T530BMzsH4uYknUBjAysDPNU2 yXr7AOqH7+ivWCJwLPMckWUeeBFfSggqstGrLlZtredcy+fS2O29TiMRY7cnFnK5jrHbM3Z7nbHb U/FDYuz2Tp8lK9jtnS9LHhiW3H2W/Bot+Nj4ew2a9IUqJn1BQyZ9oaZ2O2zKpC88lklfl6WJLyOP 1KGJmklfyFrJCatUNOlTK8816RMWrddZNZM+SRWZSZ84h0jmErZu0hc2b9J3PI7iB0KLmf1gkElf PGU5Sq5PZrPChWXBzfV9/AgodGd9D47rjeX00t3obrF7XM6tuw24XM5jOKaeTMzMtvrP/74I9YAm rQtpVQfKwauCc/AcXCf3gDp8/aoeQy/X0u+opdj6fd9SjFuK6Zb0bSEamVt8gB7cy7cUX7p7Vxxd B/fwkqOHugMPgk/beDbrQTnv+3W6W216LECbs3AVS3KXp2JZ5aWxr29fnaqOWqmsQDOmWFZCO0m5 CspVjVSFbvA5uMlr+7WabqXhKxV/W1L4NLFHeJoh7RoafKhF6KEWSB9qNj/W21lqUEKBuC5sQlwX MuK68j01YK+uAX11jdirayC7ukZNPYYjg287HXxbdEr4Nt3Otodvi9p7DAcUrcSP4S7oZEMe6CB2 w1AM3KdStUEHdOkycB+ntiH8D1nQAe5MC8B93LAq6ADnrgYd5LVqgA54k1Ut98/LccX+XTpGq0Cd kQF1GlDnKYM6o+ZBnZEGqDNqEdQZ0N09BNTZJovSAnUGh4A6I4SSDHRAnVkRgtIMqDOqDeokK+eA Oktt46dzBup8vdY+YQPWPmLMq4Pu9FLhn0G/GvSrQb+ybHpASmReM/pVVUCtJZM+WAzdRAUKomsN cmD0q0Se3TpatMspBtFoEI3dH7uZ9+MhWU/znGGRrDrK4C4PW1OxKz37DJLVIFmPimS9KUFZHSUo K5nHaQXuKtqlLNxVtLl4Rg2SvC8Adx1guKuwE433AVZWvG6HmbDPBf+uQd0NGUHtJ1MqLaHmt4mG u2oGw4MsDxQhywMRZHmAsceiTSGCLFcXq4YsD67l+/EsDW4CgcFN0ITBTdAJfFxZPR7w1eOzqThO N5VaQz1OlmbV4zC1BfW4x5FK4s60oh6HDaurx2FuFfU4rlVLPc5Olpp6HJY7M6By0AhQuQyUE+oy BrkuQ3gOGF2G0WUYXQbPk+dZxJM+GHdTF2TT+GMH8b9s2Rev1uQJLCEpUlBmmEGGOZS+g9SNNjxU 8cBhZVM1oD7UnY3xaaAizzoGvqhBMFEt5FANmFAd5Qy5hCiLmnyKMzua9tVIRl1l1BZGXWXm/fjq qnauEgefo0c6KVk1mC59uMqxV0zk2veGEol0z3+jijOquBdVxQ0aU8WReQatqOsO0t20o6h5AYWf ixV+ml3jqpBc6ytJGUGR/8iKcPRPrkj/5GJFkq5qkK+VqltZta7Kva6zGLvkieflIleF+pGrQjJ6 VMgFOYS1QQ6hPHJVqW0qctU0Th6h/Hzz2247Tf9a5qJNQBnAgS2sKgS/bhXIMoDtRFKqEPkusr9n sAzujXUFFRfTojMqc+GhwfWrW80yXmQ/ZqiUqF3699CCMvN8dTrW9jfYByQqAsfD43wJVbU8Za5d 3g0hsz9Cenv0JcoUJ1emOM0oUxRhIELliJsrR3R9vxiViVGZGJUJc4CFvh01oTNhN8SLsBPbU+Mn Zd5anDHwcrLZrvHVFlz/MmcSE+Sr9YLAkYKbymLyfpGO48XFZIm4B8wByu5AU2A9fhTkhUY16Xpz Hz8mZNXY2OYz2PpgZT+uhmjz9F3btx3XtZ1fLor3ytAKZ/3xYGA7N9FsltzYfWdyA7ZudOMMwjCe OdMo9MYXoMlPyJ4ElrAtntbdfkPncri5nFKuATfX4A3u4Tef7kt9H9z2Q2/g27/8C/Mz8I+d/Xnx mE7ns3nCkgMlPIvIMfjlAq3Rpy3TnDO49b1B6Ee85i6F/mBws5zHN07gvrxxkvKzu352kcOWrNM9 agRc8cLLDo8rUjiV/oGCBQMgylk3b7HFi28nbvXtoV8bJ35wbfCuhLfPkPUhpyDA2ZeHp0yyXsLl thfUiCplisA7aDxJrP1OFb/87Gt5tUNrt4KSmGbi2mqRczTKhSWTGKSBAosk3iQP4DTJjpEp4FHr FPQRni3wSrJ5Bo+XR3gxSHdr8KC7zc+bbbpawXfM/wF09q8vGVwCAA== ------=_20080416144959_68772 Content-Type: application/x-gzip; name="slapd.3.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.3.log.gz" H4sICMn0BUgAA3NsYXBkLjMubG9nAOxd+XPbOJb+uf1XoNxdNXKvovCQLInVSo1jOx3XOrbHcqZr e2tLRZGQzQ1FakjKsacr//s8gId4gJd8iJKRVHdE3Hh4+PDeR4D4e+vnA/TL5QJb5ydHVwpyTXWh I6nT7Tyg1tHCQeIhkgRhgMSuIklKT4LUez856uJOxebfg3+V99588d6GQkxdXbx3sXOPHfc9LWuP BE0W997kFnt3tutNHy11jieqgsjTKCiijZyRsKereG5bE8MyPAWRjMr796atqSZJqgwFUX6fSmO4 HraQbVVKLQbpoXHIsxFpcKfT8Vu4dMzJQnVcPMEPXotd2kFQnBKVg0jBhmoa/8Z67SaQ+rG+54vc j/aL86AwX4idvak+nUxV7dtkVZMSqxV9PPmISDy2dHbaj9j5hk38iCBht3PYkUQFtcZ44eH5FDog 9dtkgPsHe3clNX2O1cRMW7mmoJSJ66mOt1xMbAty0wfDukX7mjXSbGtm3O7vjT5AuCNhy3MeFbSv g+ij2D17+v9Y845N1XUVZJva76Y9Vc09jSQKUpjamMrx7ERB8h4UtdS8paOal+ystJ6vX0nqwUwY qqKI3w1nM/xOFCTt3bDXG7xT+/1hdzYQZoPD7p7mYNWzHfcCNDreMhqOb4w5hl7NFwqdQkJXPBSl bleU/vQrOh5fpGM6Qq8ndId//izQPz8H/8GfvbmtGzMDZyujEY8Fle3vffjwAenWlYM97/HCduaq qaDfohI+EDHTSTC9l3SrFUW0hYO930bMqIORgKJsuiVN71tSX1ol94OelPy3334ranQ70QO/h34y qoyv3z2/vTlNaHr7IGM00WL50LsPSHgYSDKeDTXWbIS5c6J66lR18eivd+KPmWNbHkGI9OQMUx2z 5+6nIN9xNHHDDApKlmtq56rrfbF1Bd1cfz0lAV/UhxPs4NkJYM2dggQSdo1V/dIyoZ2fjs7HNNlY u8Nz9eSCTp7xcurSZ1qADTBmO4A+YfJ8qEh1JA0Z6lBLQob6CpAh9wcxyJBfDDLyRjutwnnpshqd l7Kagr9gbib65Pa/XSSbps/9prcvgU25gxaDKqzlrnjRtGf0LIpjdi6Krdy/+jncRI68BXDVB38N dFd9eqPdLluYhB85JmN6VUosO6tcsJzYtnf1hwIgevLn/9x8WlyPf78drb9KDLTD5CoxfI1VQuq9 imHJFH3hEhEmKlkfwmRrwPtzZS1fFqIOp9eElSSaDrhNb1/+ghCNVXI1cIm3SetysLs0PeogWqN3 IvjgUBv8x0iCHQfi5qoHIKOP9veRhx88+HePBoGtOHGWJp4sXUy94D0Ef8SO1Bl0hY4oyr3eYUfs dDswY1DLgDXqFjsfDe/S+UKyHygoLOYaSvlKAKeVl/3i6Msp+lumjL+ho6ur87PTMeR0l4uF7XhY JzTOP2EyG7aFfkFURDeeCT+Xhn6xpI74L+g29hvkByClLR0HW9pjFGCBUX0FMiEeOSPsaOnd+eFn ukkByV56QYCl4wcC1p5zNvtiWOfYYkWoD6yII+sxJ3js4UUs/MzyooTnhHEZjz/5TwlvwA+6xgvT 0FQPhAL5sHOvmn7E2Na+TZekMWeWZs+jzmbDVx2+uQMQ1t3gwbbNRMDJ9FgFhfnkYJwIGBMKJQg4 udDSQWcn55kw8HGi32OsOtrd2FO1b1HQ3fy/cTBg48UYu2TMTfsWHaCDfGWU48p4ZOl1tVHOaGNY CFdHro7F6ih3fC0SO2L3EH4KQ9CtbkdCLQ3Q++zWsh18dtQrVMncMny1zBYUV0vV9Hw+MJIFXS3K myj6TTx9UDVvzRaKsRYmyqnTQKnT64hyR+5Be7Djgd0GaoTD5sRTdBMpaIWsZAJq+TbxmQ6Tk9qB nwzH9Y7t+cK2IKigq6sy/J5VKIiJEdBHz7HJFIiCTh/ApwtAIwr8BLbvElZnCCML9fjR8tQHeEwJ RxpGEFe3K5A1gW5Ve8BRjqNcSgn7qHVLXvP474bIWFVQv36gfqycccVLuYHQnJSvlmkOwMHCsT1b s80za0bMajIuDESQwEBYWsa/lvgLfW3DSiKRwjBYzB4t5UjX4cllpQR48bCJF3cwgXzlZ6QSQVa2 5mFv7BEKtlxOYiindK64jMAud67AHf9uO3qkFM7jwiPjlxKPeIhaUyNVfzx+ZcJXaF3KYOewwWGj KmyIMPum0EysWhUULbTF4zniinanujAkoP+GBXARdPp30DMTf/565T9+NnQ9Ghv/xUowNIbj2M6q X6t3JOE4+S9Ywifyyh+f2/a35SLs9YUNa7QWSdJwvEeSKww4NyyQFNWQUDIX9pUPLGHANTZtVf8M UykjKjFuNp4bLsu+GaCWtZxjx9By53Y/Ztr5CgzpWGB2GEt46eg4p7xeLFn5GPbSVmE+WoyPxudf sHanWoY7J4N5D9PbdghrFz2s0AQmFfzf8iM1ywcVYjmpUwBk/ev1GTzo2NUcY+H5WXzgAHPzk2Hi +DOMnP94pGmgusFv07S/h7+dW3eV6cgDGU6XHr6kJbup0JvHRaiLZKKenVzj747h4VXQv69sgIDH WMA1AOlDoFcf/d0DgRYF1E/wZLhqrFknhndM3w54RPBuiEiauQyV+tyYG54bIlOs4/BwDipthrqv QwHndqi7/vOVGsJMjP0Nq7lMGcNBKMwSUw16Fq5OdFUag+n/ia7LycjPqhtUcmXoq/Zdmctbw4r/ TjT/Gs+w44TIGUBq4iE5ZEFgogoSlizzX0vDCft3jclM0YLWEnr8ZHy6erj6I5jBqmt+tl1v9QQI YM5Xj2OsXTn2IigVnpagCyFSBns3gieAWzpeIew73j9VM8y4wrkgAJDHgR4E0A+LXizvzfn4+Oh4 5R6tOpmOWY0xicnLsQoHlE9GGYs77IyXkX6TsOvz4zscLg5+QCLTtWrpiQCY1mDdHZtGhIwQePL5 SnXU+Srh14UOLbimEz9EXNBB23mMVjdS7cI2wlICi2hVBCxuKzgGhIal9QR7WIvwOFZCCo+7cTgu BFI5nrIASRO8QAXrOUMBcCzlWMqxlGPp9mApodzlw05/eNiXpIFIOESKl47O8tXBAtbB7gU0XBru HdYJfFVwGwKcZGfN0AzBW2gUcAzhi2JEiLngBTwoDHVeUeDEnlz4cAmlU8x4oLCgmgaAi+5P5qAI nWwGNojGeeCEkVSZVpGKMD4yXTuQJJ6pS0KTEifrYwRXdNZcBKINNnqF6jybGQ/xYQ1jwLlQM1wA gxEtl2keBfqMpCdppr9VONg2G9st3Kmxpdb/19+9q08nZBNyFLY0TH0S7qIgWyyoIPf3TBh4P4eq 6/GodqxgW5toRKMnjg9uuq8MqMVIfdBGsa0YaD8atON0YXQNgrI8WOkg3SpTbhrNys+eXUuK0iaX 2fJSg0UrNyFzu0hu6mjPSH5PY/OzONGKKyyu7nh8kZsgMf2LUz3GqkvpDiylChLou3QFPfOL+dj0 AK2nj5Nwu/0EfGvjHiTR6sNMplscEvG5W/5pgwQ000cDdHR8fHp1g2aOPUdnVyNR6ncE+Csq3YE8 ADROhJH8fnYYapjV5ABEa8AIUdCt7dGOGzp0OBZPuCqagEqazOSZTc4cLJYeOfNAk0+hb1DOxAIh JB4U5Km3SHiQBWRiC4kSqYIYcK6SzBT0kEpctydTgxwlgASuplozNJt7qPWXMfcOEAQq6Zj5jyCc uRXoA3vDDNkb8yFR78ezixNIR0ZzTs6J6CDIwV7QGgXd+7b4SM6myVEhIdQguZYGxZMuwN4GFJ27 tyBokUhzNOz7eakUZubSvZMUJHbR9JHwa56NXB0NEh27Ph1/Pb9JZPZri3VORqplW49ze+kiKv3G KI3cL1cakSiNS5fjjNrMDfgzXVtDxtfHnxEMjwB/4Q/5R8goYFA6STAzTA9+hys4xdfRrweZZn35 8SOWSwWYh+7Fe0QrpluKoHZXg0WSzA3CVBMooLWM9lO1+KdV6CJMhREupKRcaDhV3ITe9ISU3pB9 Tbn58YPhdQq1XXw+bZeowoqCWE/dQXCnR0R0Ma2PCkHkHapjYJfMJToDGqPmvTwtjz+QUmfQXzRT wcbXSacsG7rVGi+pK59ovWbaLj1OQJr5SFoXSMkl6whpKUmB01lgAHTqbqZyxGQskem2tCKcCEO/ XhAMTUqImF0AMKDgeL6glmDQrkzZyTYwaqbrH43Wn3NhFSssrNKzLKxiPeURKyuPNCzESPFFFtad OrwVl1NkCKw8iwoWATtxebna3Wh89uXq/BS57owcQI2tyf6PeHoAvLgnlYPF4qYtD7HM8mjM1DmU uuVzh9oXvluRtS+COcJMDVhqoZyN5ittzZSJ/5r/7x//F1kIJdHVd8C3c+dsSfKKu+LbNSfsqxVS fc98O4EQpVKMj7rvnfr7BkCXfqLOZsBdEvZ176ef5jADjYWJ0b1qLrG7SrN61Q2pbCtI0CYqeuvd oW6ioi+XPo6UtG4/k4mYmaNYi1I159InZSLOUinJwydPIlNipRWl8Wnq7SQ+YgR3UZrVUL06hdL0 8xi8fbx9vH2FTeDHE/nxRH488W1M99rHE7npx02/HNOviGN4Gt/7rIUxyWO5HmMhJlljuZmUxatR xWJtqliMEbYikyoW16aKxUKqOFlznCoefSAvh8L9Qw5h5QXJ/+KaP0mrfn1Nen/gJ3VV16Qk3cRN BQSPRC+Dz5JRQIWp5MdY+Ptk1QEkwl/BjzEsj26EiEUHbfSfJ549oQ1BN8dXKNmuVdmurX3DkGYQ fPMOuqw6OB2cLdKhg57gt6XVZ/OC9AqIFcpA3lxB70SkEpkqYftp20EbSFoFub6SzZZmTCL+9+Qi gWRo6BwW+i8jFh5OYllMTeIYYsCaSVe2niz3BB8QkLj3XTW8LjwwY1HLC86kiL7NR87uaAerTGTG GdYSs3MDgkINv/6ajD2ORhIm6q/IF3U0cgiR3TUKIqJGqKX7e4rIPiAHpGhBDAQDBHtLsJeDokCb EYLVyyPNg7H4AyZ28IVEsat0u4rYoybo3l6mMZdLDwrzD+hc+yMArUK/hn1oI2Q7RvDTrxadgRln 35KDVeQlpR0rwQk2JLpIaCOiYhaBvSX8XyAtjFccDHcQDZKG5dzSbQuaDgZRupnXAZCjfyzxEtOX o6cABo/ZUoN0Ya2+Yt99CwsgpzGKBouZHozWpWO5yXwXX8/PV3PUxSYMBBNUxHVARWwoqIhZUBmy QWVYA1TEHFAZNhFUhkxQ6cpSAajEY+uDSiJ3BlRobGVQEV8WVGhjNgEqtOLKoEJTVwCVoNQ6oMIY rEqgQvMxQYVYXyKUqBQB11qbrUpKBlvfVW+x7wEw3xHjo6NgwuQURfZWfF8NYSwZWO7Ot9iIzRcm BqVrs5fpMJ1Ot4/mJHEn1JxViKIET7bjb9khj4GrQLf2UBnPHIxDiACXNlLJoMSDWKoYkArhiKYi lGAyhdE+wPswkcWZSHCpmPDtHS0CGkIqCXHN33sD4wvuwSTcURRu9tGizT7xWNcgcqVB/s9VvkS2 fb8Of59tUBNIBh3d3FyPFZi6/1W23DwJdhmoK4ppWy6+uEpJiz3fwpMKLTxpBca1bDuJzjphq207 aQXD0k7bduFgPdG2yyIcA+qfCYYTJT8NhmlRT4DhhGHDhuFUEg7DOwzDQyYMi2U2MQOG47F1YDiR LwPDW2cNvwgMN9EargXD+dZwXb5VyGH6uDXBrYlGWROMOirvVhT7Vb06KWlO+GvMO/qSKLMcPDzk rBMqO9zO25g4j6+mpA+6NYGA7KZJ8683s7U40/c/8vZ18phqMXGd2dyrd1b9Td8XwCXHJbd5yW3u KoCsFMfpmwtSvXjNtrIuIUg1J3bjwPMeXI7nDS+vIseliSmDHYuscCcXiaMrqkl3C5BTgWAhrt+c w0GNjSJr9q7uy7hqV7HV3TfwrKXWTMqvMePXmPFrzF6hfWXXmM0EUPdn/ujE82NlggnlNAmnSbaL JhlWfvm9zTRJYm92/I67asc8mTmq34/3pHOaL19OrdvzCk595sh18ywIj6nHETXa6+TEAqdkNia5 nVxHUqNTpY/ZYdthydTt5pYBKqfximi88gHfLn6PXwtefqKaXwvOrwXn14Jv8lpwTv1x6o9Tfy9L /cnysN97C+Sflv2kOQMT00mY6Jj5NHplS/dZM+a9psp0s53T+82zTm8nhpMvnLbavOSaiYBZCWfb yZR1k7tT2lROEO0QQcQY4e1ihLTkWZFh5vTIsMrpEbGJh6Be1Etr1AmrZ3QZN3ZW6xmd1Zc588Vd 4M27wGVH7+q7yIUdeP7DegUeuSjKg6pnoMPWPMlrT9AETXbh+Tfa623YWfMb7Zt3lt9ODHduOS3Q pN0s24yqRTtYWP0q2b6y/aKo1TVOR2wDHVFgN/Z6w+pm41a/x3ldLOVn3ZsXwxd/bjZxyW2v5Lhp 0TzTIkGTV3ztUXaj2la9AnnR9wR8Nxensl/hIKcgvoW9XAA7l/fYMdVHgjrkbePCse/b9d33NUph evVrlFPZ2W9i2Xnc8zqj0l5/PDfviDQ5hhus3NTfPLfMgbo+b72WzJh0Npf+WlT5EwaAu7lNd3ON 2WSqknv8yF3i++uNdqYcqE9B/tV3CuKHlriby93cl3Nzh+t+1ZmyV3OsG9GNY/6XABPhaYuabWjn uL6X7GAvp5Q5Ozg04Z/4FcLSzw4+7QxzdFh6KsuiFD8sLYjDd5I8GKgzSR8OetPk9xBFuhxkPyaZ TCUxU0mpVDIzlfw+75S13BEGPflQjJ2yFp94ylrmHzpsjuvR3PaVfeiQ3ivNDQduOHDD4cUMB7Er DuStYMjTdsKP52HOAXeoN+Ng4stUOD9XkJoJngXpKyPqa5SRt/QVSaddLr/Ns767FsO5WM5ib15y 2w+a2dEo7BNziHZFCnW6xVndbWR1i0d1i9lbzghtByNEfYwHj13dUBZ7rOo4jdSUtb+57eM0EqeR OI20YRpJ6HIaSQTzyjWsyt5AUXq2P1CUo7pH8Eql5BJKhXJqV5Hl5kmYXYvh1AgnlTYvud2BUAa5 VNw3Nr20Y/Ko1z1ONG0r0VQ0rpxq4lTTpqimXkfsCXKvz6mmJlsEzW0fp5o41cSpps1STdJg7c3O O8M0ST/AuAJL4XYBy6NtVfUOKmRjOwkVMlb3FTZSWC4ZVUWU7RpS3zyVs2sxnGDh1NTmJfc2MJdB W1XqN5u9ekMiW6vrnODaVoKrwvBynovzXJvkueRed8h5riabF81tH+e5OM/Fea4Nb6mSB8Wfr34D PJf8w15gixRU1XcozsF2G4rzVPcYXrGcXDqrRGLtanLdPOmzazGciuEk1uYlt3uAyiCsyvrI5qp2 VDJ1u8kpqW2lpIpHlrNRnI3aJBt1CAGcjWqyndDc9nE2irNRnI3aLBvVGw66b52N6v6wDLeqd5Cb mO0Y5Cav7hO8eBG5pFO+YNqlkts8NbNrMZww4VTT5iW33WjJoJUK+sNmlHZAADW6xImjbSWOcgeV c0acM9okZzTsD5nVcc6oKQt+c9vHOSPOGXHOqDZnNPqg2xNy5Y+DFyZyDH0EuJsIlaJQllJ2ZalA KeOxdZQykS+jlDS2slKKL6uUtDGbUEpacWWlpKkrKGVQah2lZAxWJaWk+SoSmYw6qhKZh0OpkMdM FL3VF8Kubut6J/6YObTPer4XWp6DeYNdSZ5qC/srl5N3WWuZxNrV5Lp5CpDH1CNIG01VcD6SM7kb k9xOriPZ+2VL+8i8S3ZXJVO3m1sGqG+W+y1hFLjzxp23Zjtvsjzs996C+1btrWGld4VrvyF83ox5 7HfOlhG+UaRZHhI3n7nj8dqSayYCZiVccUNIk7tT2lRu4m+DiR/PG25mIFs3/OvcLbLmnlyM9hkj vA+WGLGmHhF+AAPPXb9hh4MGvBzlrgx3ZZrtyohdURLfiCuz/bdkPkcZ/ILlLYnhNjz3fjYvue0H TX7Bcv5Oen7B8rb7WtwH4T7ItvsgQvft+CA7c5Xa85TCb+fcohhuV3OPZPOS2x0I5bdzVvFR+O2c 3EvhXgr3UjbtpYjy4C04KYmdtoQfostC7oJSkrxkK3E2wxr7iF+ykPIzOgwRpQ/osKS4eWv+7cRw 65v7LRuW3M6gatGhFVa/Sk6sbL8oanWNeyvb4K1o1favlYw238vGPTTuob3mNxWEN/EWCWDn8h47 pvpIUId8D2Xh2Pft+svqGqUwV9s1yqm8CDex7DyfcJ1Raa8/npv3q5ocwz0X7vNt3ufjQF3fn1xL Zkw3k0t/LRf2CQPAPdtme7bcy+Ne3pZ7ecP+mk4eJW/mWDdUL9B9GAsXTxLhaYOSbWfmeH6X7GAv p5Scu0ISV4Xwucrn6vbOVWmw9mxt0HU94RzUIrUn/W0ND7IhCrq1PbpCk6/T8u/Y8hm+4zO89Hp4 PsP5DOczfItneOmVe1s1w10THkwQJ7YguQoT4B7M/lYf5jVlBhLxLZI1ezeJjwojCc30kSigo+Pj 06sbNHPsOTq7GolSvyPAX1HpDuRBH7USYaSADKqIAisogTRSPAEZAz8F+PfaN6LzM9sBB2cB6GD/ p72r+20UB+Lv/BW+3ksiNSkfSZZw6j6k3VtFus2e1OtLXyLARvEdmIiPbvuw//uNHUgIEKCn7CXp uqpaYo/HnvF4PCa/AYYEfecYrei/OxtFoU2mDHE7AtyeQxkulGm8LGWV0sfFbL64P9whl8PDCPTr 2dSH9QhLmoXQRe8hdV2wsj2VuT6HiINRii/cuUKyvmIxRVw7nISU2xALYeEtyk0qZkaDpMXO3v/b YIozzWcPWoqn+OR4h4AkqxC0p5tKZggWeiZRDNq+NRqI2/m6q9uH+Zc///iE4tiDbXfH3kCbiyJ9 EhY/7q8cfl8NyO0kIeC6xbRvbGd/+jvbyXGYV6q33kUQ4GP6LaOL3zK7+C0ZH8n46KePj7SRblx+ fHSkfAHtu4OdjljOEm0LkLNE/R9QnD+GQ3uCQFkn5eyAis5OD544XFPy92ZlBzC77AB67Q6gyxeM yReMXeBL6Vt3gHf+Unq5A/xMO4CseQPsELu35MUO1j65hks3DMrroUJQXQQVkm52W9+sBI2pGV8V H3OmQrQMsQpI+mIzcLzRdas8TbS1t2sOUne+JdPMoQpoapBF4jcl8vX0yNfLjQiaMhwrsrSkN16m 7N3FkajPS0B9nj4sOucaGbLJkE2GbO8j8JCakyGbDNlkyHbxIVvtjdaz29WPENE0CHfdGiQUESuX Gyp04RB0Dja66WQD7DnI9aMCXmMJv5RRMNM5/KXc7PmXR7P7GcKZf5F2Ku30tHZau0ucs467aKgk zpvEP7vF94ajn5xGOY1yGk8/jY7t/sNj1TixoyRdL0MGhOIDDwCuKi2u8nAhXBNmtRN8syPGOQ0Q C9H9bHn3dfH7/DPyqE+QF6YMI8oQphFxkzB6RcMb7Fiop/eHyqeXNRSidRhGaE0ij8vBXCIQ3nHq efSlrvfhfvd59FJHCrUOYc+Cssc7hk6bwLfYJkEIPONVmuDwG8sBMwQjW8jBIyf4NOwAVzc6wNWL hPt43g1SGPX4aPF2PH1l/zNXPk3ylAETJSs+hphjpnkaNGUiCxpUBVJR0P5Oa1kBb4ppbDs+wb9l D8dLI5JX75QLHAnjZIqPqbfkNsUfogfm0XRAvSpTwxHJQqo4GIG6j3vKOi43WJFxEukCzMMXAehs K5YSOn/DRN75dhxbCBTw2Q8d21dclj9gUIG2qZukke1/PUALMwUajhd2QIqsRTn5iwZgdmDLlsCQ qSNtoumjkaY/KWJEj4/zewuZnuoYhqYPpp5HBpqqu4Opqk0HumGatqfjqTl2FOjygUTPJOItNOFT ymhy7WafSq+l0ktURi2VcbMZ4d3DojR2Y6iaY2OiPf2qih/4p2WXShCCnVBSVYeoeD2kDuNJEVCt l6Ta3XioTdQP01FddweO5P/7Pb0fmd9xGbcsz3d80HDrAArt0OCjwAEanjYenbUHE1RNj5yQYFwJ xj1vMO5k3PzEiY5Y3L2V8HbQu2jO2y7zKevtLCLrvV+g2vGDWc0yocS6zTInucCen8Yr3UIfkPOa EBGxxRiZtVwsBFFqCpp7RbwGKwUMvpXD7fkURSL67I3ENQWuPvFg4dSB9se1paOuyawFEVm4WXT1 Oa1wJNiV/1KT3bYJGfvb0Nt2XbKGXoyJYapTXe3vp4xOUW9m483hApPYjegaoqh6GfXaUk35F6vq zBjcvQEA ------=_20080416144959_68772--

1 0

Re: (ITS#5470) Sporadic failures with RE24
by michael＠stroeder.com 16 Apr '08

16 Apr '08

Howard Chu wrote: > > I have committed a patch to syncprov.c for this, but I haven't > reproduced the original problem so I can't verify that it is fixed. > Running test050 by itself 20 times never showed any problem for me. > (Dual core OpenSUSE 10.2) Note that I reported it especially for RE24 since I've only tested it there. I will check HEAD more thoroughly with your patch in HEAD. Any chance to see exactly this patch in RE24 any time soon so that I can test with this particular code-base? Yes, I could port your patch to RE24 myself but I'd prefer if we have exactly the same code-base. Ciao, Michael.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 16 Apr '08

16 Apr '08

Le Mer 16 avril 2008 10:41, hyc(a)symas.com a écrit : > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: OpenSUSE Linux 10.3 >> URL: >> Submission from: (NULL) (84.163.88.4) >> >> >> HI! >> >> I already reported different test scripts failing every now and then. >> I ran 'make test' a couple of times and finally it failed once in >> test050 (see >> below). Running test050 again succeeds. >> >> I've also attached the debug logs. > > As noted in the other email thread, I'm pretty sure this is the same as > http://www.openldap.org/lists/openldap-devel/200804/msg00067.html > > I have committed a patch to syncprov.c for this, but I haven't reproduced > the > original problem so I can't verify that it is fixed. Running test050 by > itself > 20 times never showed any problem for me. (Dual core OpenSUSE 10.2) > > If you can get it to fail more regularly, let me know... All tests passed now twice here, plus 5 times for test050/hdb only. Ubuntu Hardy/i386/dual core. Regards, Raphaël Ouazana.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 16 Apr '08

16 Apr '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: OpenSUSE Linux 10.3 > URL: > Submission from: (NULL) (84.163.88.4) > > > HI! > > I already reported different test scripts failing every now and then. > I ran 'make test' a couple of times and finally it failed once in test050 (see > below). Running test050 again succeeds. > > I've also attached the debug logs. As noted in the other email thread, I'm pretty sure this is the same as http://www.openldap.org/lists/openldap-devel/200804/msg00067.html I have committed a patch to syncprov.c for this, but I haven't reproduced the original problem so I can't verify that it is fixed. Running test050 by itself 20 times never showed any problem for me. (Dual core OpenSUSE 10.2) If you can get it to fail more regularly, let me know... > Ciao, Michael. > >>>>>> Starting test050-syncrepl-multimaster ... > running defines.sh > Initializing server configurations... > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Starting consumer2 slapd on TCP/IP port 9013... > Using ldapsearch to check that consumer2 slapd is running... > Configuring syncrepl on consumer2... > Adding schema and databases on producer... > Using ldapadd to populate producer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapadd to populate consumer... > ldapadd failed for consumer database (32)! >>>>>> ./scripts/test050-syncrepl-multimaster failed (exit 32) > make[2]: *** [hdb-yes] Error 32 > make[2]: Leaving directory > `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory > `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' > make: *** [test] Error 2 > > --------------------------- end of test.out ---------------------------- > ldap_add: No such object (32) > matched DN: ou=People,dc=example,dc=com > adding new entry "cn=James A Jones 2,ou=Alumni > Association,ou=People,dc=example,dc=com" > > > -- -- 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#5471) Object-Deletions (some) missing in syncrepl consumers
by marian.eichholz＠freenet.ag 16 Apr '08

16 Apr '08

Full_Name: Marian Eichholz Version: HEAD-20080411 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) When I made a consistency check with our two syncrepl consumers, I found several irritating differences. After the initial refresh cycle, the DNs were complete. But when the consumers got all new objects after, they now have objects that were deleted on the provider in the meantime. Unfortunately I cannot tell when that happened to a specific DN. The set of undeleted objects is not identically on the two consumers. So I guess that it is not a problem with the data itself. So the consumers are corrupted now. Both consumers suffer from hanging replication sessions. This is why we switched from 2.4.8 to HEAD (11.4.2008, see ITS 5463). They were stopped and restarted repeatedly, of course. The daemons have never been killed. So the DBD backend SHOULD be OK. Any idea how to find such events in the LOCAL4-Log? I did not apply "any" as loglevel for predictable performance issues and so liked to keep the entries to a reasonable volume. Thank You very much for any idea. Yours sincerely - Marian Eichholz (freenet AG)

1 0

Re: (ITS#5470) Sporadic failures with RE24
by michael＠stroeder.com 15 Apr '08

15 Apr '08

This is a multi-part message in MIME format. --------------080605090300070207070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See slapd's debug logs attached as tar.gz --------------080605090300070207070602 Content-Type: application/x-gzip; name="sporadic_failures_re24.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sporadic_failures_re24.tar.gz" H4sIAESiBUgAA+xde3PiuJaff4dPoc1M1SV3E9ovksAOqUtC0kktSbiQzFTN1hZlbBG8bWzG NukwU/3d90jyQza2McR0k2noOzdYOjqWjs7jpyeuqc70mlgz7ecftvUR4HOiKPTv6Qn7K/rP wol0Kgv1H0QR0mRJFGT5B0GUZKX+AxK2ViPuM3c91UHoh6mhTVRs5tBhx/0aFfq6n39VfzpE Pz/MsNXttHtN5BJ9QFJNqb2ianvmILGOJEE4Q+JpU2w0ZQmoKz/6wvqXNZKaHyb2FH/wUz64 jvbBBm6mrs4+PPSu7gnbYf+qO7y6/ziUhkqUCwJ9AZl+oK+skKTh7MUbPmNvYrveaGGpUzxU m4g8teBNR8hpCRVdxVPbGhqW4TURKdT88MG0NdUkZM2GIIofEjSG62EL2VYhatGnh4ohz0ak srVajdVu7pjDmeq4eIhfvWo6t0OfXRPd9l5OkGtrn7BXPURj1TCxjrDjWHarcQqy1XUHuy5k TA1zgSzbQ+58NrMdD8hGCzRzbM/WbDNiGFQMkZoaqmn8CZRF2iRxbSINwr60NQerHq6Y3jHr dUbNuJNasA6qVUju0FVdc8hT0Pf/R2Wkj4YjVfs0jFJ5CnTRuUAkH1t6Ou0Fdj5hEy8QECq1 ek0Smqg6wDMPT0fQWEk8Igp4eliZrHjTDfemVNrCb2q1zt0/zCSD6mHll1YrPQNKIM9RLdec a9jyuMyKX6Uh8TPefDa0LagKfTCsZ3SgWS3NtsbG80EFeLieI0F5Z9FEBzr0eZhbsUf/hzXv 0lRdt4lsU/to2iPVrGiEyKcwtQHtsdsO6HEFWM01b+6o5kN6UfqepydCfSaoQkM5lY4b44Z8 LAqSdnymCY1jPMLSqDEWRKxLFaoutuPeg13yNWNq9GhMMbRqOmtSfyEoYl2S66d18Xf2osvB fTKndiqdycLp7z/RQCD85P8Hn8rU1o2xgZdfRjMWOS87qJyfnyPd6jnY8xb3tjNVzSb6JeRw TsRM1X/0IulWNcw4Ekj/pmYdtgQUFtMtafRSlU6liJwlvYn8l19+yav0UawFrIWMjGr2128e q29GFXa9flAwNDSuHDo+R8LrmaSfNGQtzRrBdjqqp45UF7f+Oha/jB3b8oi7SRpnQHWZbrvX frnL0HCDAk0U52tqXdX17my9iR77T1ck4U597WAHjzvguCZNJJC0Plb1B8uEel63uwNKNtAm eKp27qnxDOYjlz5TBjY4J9sB7xOQZ7uKREMSLkPVT87iLmO0fZfREBXeZYhbcxlZvZ1U4Sy6 ZY3Ooiym4Fssnep9Mtt/lCebXbf9Xa9fzDdldhrnqs60zIgXmn1Ky8K81MaFuYXbt34JN1Yi KwBGbWAx0I3a9J02e1VgEr5kQMZkVIqFnagUhBPb9nq/NZvo95v+r13rSX68tlubR4lGQ4lH CfUrRAlBFr4KsEwVfW6ICIhWxIeAbAP3XlbR1WEhbHAyJkSS2HWHu+v1yw4IYV/Fo4FLRpv0 XQ5256ZHB4hW61iEwT+8Df5LIcGOA3lT1QMno7cODpCHXz34W6FJgBWHztzEw7mL6di2guAj 1qTamSLURFGu109qYk2pgcWgqgEx6hk7F4b34NyR4odNFLDpA5cn4nCqWcXv23dX6B9LPP6B 2r1e9/ZqACXDiRIyufQrGLNhW+hnREX06JnwdW7o93M6qv8ZPXPfQX7gpLS542BLW4QJFoDq HsiEjMhT0tpzb8LSb3WTOiR77vkJlo5fibP2nNvxnWF1sZWWob6mZbStRUbywMMzLv3W8kLC LpnqGQyu2VNsNMCS+nhmGprqgVCgHHZeVJNlDGzt02hOKnNrafY0bOxyetTgxwk4Yd31H2zb jCV0RpcqKMy1g3EsYUDmY/yEzr2WTLrtdJfSYIwTfh9g1dEmA0/VPoVJk+l/46DDJqpBeqeP x6C2qsm1vTPq+fNmkVqwakGHQsyClB40Agr7GZ3BFCRI5hoNjYU1v2nA53VBG/PvOXYM7CcP ZgPsEsam/YwO0WG2Ici8IbQtfV1LkJcsIWCyN4W9KeyuKcg1psFiTVRO4KvQAL1WahKqahC1 bp8t28G37XquOWTyYCaxzIg3CdX02Dwo12CIkqurKLIqXr2qmrdhDUWuhjE+61RQqtVrolyT 61Af7HiAV0GFcVAdnkKJUdAXppEJqMrGArc6OAaKf68Nx/Uu7enMtiApp6kRD9ayAoxS/RO0 0XNsYn5h0tUrjGV9zQwTrwHzzx2qYwSgDBaWp77CY0I4UiN0r+s2BYrGPGvRFuw97N7D7oCH DbT4FFWfyZoeW4gjelJA9U991U8rySt9YugN1UmMjyFl9lkH4VjPjAVLaGuaPQf9IcueXPK1 aphg1FHCR0fVSN1oSrJl4NWC1c9ba0xGRUSUKY5NAow1t4w/5viOLuGlkUiEGYYBj0e5+Muu aZTgJT1s4tkE/ACz4RQqEcRuax72Bh6ZQV8tcjEQebIUL26yuaCnuu5n29FDJXIWM4+pIQjs xnA921kkZSWeoOrISFSGz4+GYwWqmhh87V3h3hW+B1coghsYAXesWgWUPBhX8SV4JZ+oLqgD GKJhgQv0X/8RdNzEN0899nhj6HqoF2yBzlcLw3FsJ5JptNYW6AhbqAueyAYY3LXtT/NZILF7 GzCPFvai4XgLUipI6BoW9BLVTq5XqMCe+rdcUh8DjrKuSH2Csn08Miy97YJEIuwJ7cVBj7pc b74ufpvY7eltqAnQCJNM8YZ9S/w3BtjkqM4iSocQAD3VtZ8Hc/ot7HCIG14gFuquH8bwXjAV 5uH64KR94+71bLCkxY3qTi6hjxwyFxXLeSJC0z6F3oBWd6C+xHWm/3kazqndqbMZ1gNdurd7 LCYECX1s2io42SDlMdrLQXyrtpx8b380535znmgM8gmTyinyA58uuPEUN32GqtZ8ClXXMj35 KTc4Ye4K6NLi2AlH+ODoOINfnSNbbTX15LgmOzYM2oPuHdYAGRjulPTECzhz2yHz7eFD5CTA hcL/WyxTs1gIIdhfHUEs1plK69jVHGPmhX6FDZiuDRPzz2ArvAr6303T/hx8d57dqFDbAxmO 5h5+oJzdROrjYhYoEnHLt50+/uwYgQaTpD+ZMnIJfQibr74lX7B9P776+5O2/pPhqly1OoZ3 Sdf1PCJ4N4g/mjkP3EjXmBqBgwTLitoAD11wImbgbXRg0LUDb8Gee2rgpbl1m+A1D4nhnJ8K fslU/ZYFwIQCkgEMXq8pJItnElv1Uww9ql/PnD8bFv89Vv3A78QCaOwh3mV+YuwVJC3O84+5 4YQ+ALuc/ZKFrc7gKnro/eZ7ANU1b2zXi57A55rT6HGAiZOZBdEIA5QxvEXwxHZd+U/gbWh/ BUHe8X4NPSsXWfwE8PUOtMD3LwBxuLKP3cFl+zIa4EeNTOZEfUxyskpE6RDT41nGbIKdwTzU b5LW715OcAAFWEKsUF+19FgCmDWMES5NI/SskNi56amOOo0In2Y61KBPDT+IcaCDBN2GMQle O7NDb+yD4YgFQJkoAEJMhFjQwR4OupnGP/BjF3iivhhR/AsDJEQzsgEPahc8ty+7VJV1LuHC CM0XoFMbjMbx4kRBaholD6yCNOokrh17GmQ8Xg+Y3wwTeJALBZO4lyEqBrYZXMAe2N+nJJFq aTik+fccegAM3IqQHt2XGmlNkBJOyQSeLwjmD7NkSm/uPOMklakvpxCPGvhI3fBixgqNAfuE 3vJCv8sDxKid8GhY/KOOx+rc9PgkI4a6IcEDhOcQSfgpH8lLemoQJjpdFZ4HAeoIQEkHxrRm iNiC1I+OPZ89XMYT2d92Jy31YZxMDxhzmCxCu9wzqWWEhUgKgVlm6DNoEji2GQgPX16ErnRZ ioCAYlELnhMaBykAjQIYlDQ8Du/Q4c9Sah9P7YA5Q0EM5/ApiTqxxNAUwTcSF0mVJAGdFB45 5WIemafMAT2xSegC0yVL88172LOHPXvYs4c9e9izhz172LOHPaXCHrINRD6pnTZOTiXpTCRr yxTaOHra4oeIqrrhkkNEc8OdYJ0gjQLTnz6kSS+6tATk78pE/vpPsHESkQVbf0Mq+Ha6AID8 hYDOPUM2wJ2G91cawVXTABygs7jrs9DZ9C8w8BxMI9dSrciLMG6bru3rLlN/NlF9ESILGuDu /e70Dz4EkWc8Nl55DxzkUF9HPJPWCWc0eYcVJvdxiAlC++4Q9Zv6Cp5Qd8J/9llnKImTjh1O X/qt4DX43vYmofExXaHNS0DilJX81X2etXRf4mI9qWZ4jtA/6cYdJaytcQqO/WVn7PTRkBxY DNPmhqkPg43PZFc07euDigm6yUqous5nHXGMbW2oEUMfOgwq6UxfUTWF+vAIcbun0UGoV5dJ ZhTRAi8PcDPQRYUyaTQru/gyMs2jjYP21Vx9CJxJmLrDO5M63Oad3VLOheQTRUvN+a+7HNxn EsQ8VD7VgntdQncAmDeRQLe/NlHJe2k58wCtZ+dqg6O5Q1XzjBeQRPUUjJnuSo7lZ543phUS 0FhvnaH25eVV7xGNCdS67bVE6bQmwD+xWZfPFIgksTRSnhVnC3Tk5HX1LCWliZ5tjzbc0KHB XD5ZkqQEVNLEksc2OZ88A0gGnoKSg1MkfIYWCCH20ESe+oyEV1lAJraQKJFXkOGg24wX8ltI Ja7bQ7KGRQlcTbXGaDz1UPUvY+odIkhsJnOmX/z01N375+l73Ml29vPYey9u7ztAR3pzSg6o 6yDIs4pfmyZ6YSP7lrxMk6FCQqBB8loaxJNSIASO330GQYtEmuRkOS1LpTA25+5EaiJRQaMF Wcr0bOTq6CzWsP7V4Kn7GCvM3sY1TkaqZVuLqT13EZX+ziiNfLpaaUSiNC5FDEtqMzXgM9pY Qwb9yxsE3SPAP/iQP8KSAvrcCcHYMAGrN4MgTv1r65+HS9W6+/KFK0XgOjSPbxF9MT0FAG93 NQiSxDbIhgTiCuhbWgeJt7AD5jQIU2EEgZTwhYpTxY3pTV1I6A05ipBZHr8aXi1X28XytF2i CisK4nrqDoK7ahPRcVofMkFk+x9ZPSa2RC1gZ9S8vlrLJaLlcys0zyD16Z64Lr5immm79PAv qeGCVMynd0kIIZUkFDjeFgKQwBWAKsKYjGI2nw1fOPkW3FzKDSIVzdbLDIFigRColBICxfW6 WSzczVIjt5/FrYTAv9XNCLycwpAdjQEKxO504tV8tUlrcHvX614h1x2Te2q46Mm+8PTgmvgx T4bXFL81RhBXYYSdMR1RPFttOxQJsAHAMhLwbSSVugn9jTi9XCqN/5r+z2//++V7NDTRnxpi Ox9B+D+SiX1Vw01+kaDy449TUFtjZmL0oppz7MZY3D0kTWopm6CgFs8xbzyfOYpnd99sa/y+ 0wNoTnbfYJBd+P6s8kmlrXCV1+O6v9xpf7nT/nKnnbjc6Uzbx453FDvywPHbphRKZZY6PyGv B7XF+MSEvKNYWxFXY206H6Hqy8PUZaAdkDKUHe3DabkLS5s59suRbabdn5KDx6d//RaC8TXy cvH7BhVLuQdmXRapt8SsLaCiF8HsFuOs+2fW7oajDXuP19F2hw1RNmCUs/a4iWhS1iahaA+K Xr59dTKq0LqRahkYcI2DdgTtO0+J31mUyYXddLpy5L8Gw13tgt0AC7u0Uusbb4ko4W3MYihB 9uN8fT2UIMVRQn03UcKJpKxGCfJaM3JyckZubVyQmKfbZBpv/ZC/dngvJeJ+HSbFr4hbCsdF Q6+8NMFIzd/3uWQfdMrkYkgTncgFKtvyCY6Iij57E6TEXhRMQ66MJ8lC4eSkX6PEm/PCz5px Jn7X4lvjTMAtj4ZtGH+fociOtprn0URd9dWD2q5Pp+zrt6/fvn65Vdjfxru/jXd/G+/3Ye5r 38a7h3576LfBwoZc5pTF25jFpiyUzRY25HexsJG/zZI2RElus/RTC2+zFN+yzVLM3WbJ5Qa7 If1tlq1zsgU6OHPrkL2nghz/EbA1Nz3QnwMjUhi6iQT/kWiQ/ytY1PWB0rMcC38eRg1AIvwT WI5hefS4D5ft15E9Dz17SCuCHi97KF6viDf7yTUAO/5PykGTVQcnk5dZOrSPYntD5ehX6Xz6 JogVeCBv2kTHIlKJTJtB/amwuRelSV3aROrSjkpdWpb6scj29Gr0NHQktqf+bStdoVDnPraV MtnQ4KfzqsfiYYUTaDPQYzAwj3VeVaHfyQVgJh57h1tRCultSvFmiUlvlpiUI7ESN2RLqzdk 14VSNmRL6wUEqawN2dJ+Q3ahfaLSljZk5/LdxoZs6RtvyN4JoxCFAlbxtkNXfysTYIfEOF2T tnZaDJpB+kLzHNPNXE/LeCNftolsUIkD/pp7RRJk+NMgtxIcoKplQ0wBnAGOf7lCRv6bEsmj /L040A9cvQiydTToA2IxYFvR+Tj0T/SfMQXkzshxwmeH5aTVh+WWWNE1HvKSPOew9h6ynDN5 UnJLfOxw3olc/HSe5J/OW/my2KQE/1uGGbU4aZxsoRZa2vH92GtFcenFb/KP9LIQSvFZpe7R nnvEN1IvGTjH0DVLgpLwzqjq4GOaf1h+P6QtQMbqIyrSdnRho702sY4S6uvXrFT7ikjpPTlT rJMbKYICxM1leDmFBLvWibJ6l6eUdgq10UibDJFWHagqEX/LBH838vF3oQORjZSUmCnJS1Cj kQc15LLwt7zH34Xwt7wl/J3Ldxv4W/5m+LsRa3HhA5HfznRWoXR5j9L3KP1bonS5PJQur4HS 5bJRetJL5qL0Rh7+kVcjM7kUlF5OLTZA6Y23+UeG0htZKF1egdIbBVH6Zv2wNkovTRdKR+mF alaqfe0ISm+Uib8Vgr9FIR+A14sAcFFIS4rZibKEIyhFJpBQysLgyh6DF8LgypYweC7fbWBw 5ZthcFGINbkwCP+m5iPKciP/ZjslROIrj0vGSLlLSRx8lBKNSzsWuZXjlDkVTzX6dNIMN5Ah kOKWvk0G2c4jQxxHK6TF60ZwTDGnwAFfILhhgmgUC74WqU+4xJzBAlk2irZ/8VvV/gsYTsFS sB7bwJa4QRWck/OM9fT9fhSwODjtoCCfm3Lrq5+X3uq8Q/85Bb/dXbBl3+/6NzkHuN5uxE1O DSpl3i1QArPUuwUKnBqMRczE5QLxY4NF1mRyjSteC/HstNQVCbmEOhQa1ewSdGicNoTVyKHY RQsxUg45uIb1XrFDVtVT0UMWcQZ+yBRLcQCwbRbZKCJTMEcrJcfrSgxJZBXhsYS0CktkMtku mhC/sFdn4YkoPw1RBLkbYIq8ontU8X2iirLuIiiB2aZ3EcRQRe5lBIVQRb6BxeohKFvDFW+p xbtDFpJ8kn/WQQmvWyiGLOQksgBJgsU/z8AMbetdAoyVLUjBGSvLpMKN1bIqChm+NqcsDLJa dkdFZczrGIdIVpbkgYmcD0xW89ouPpG+xGqQBVOWyNLQSoJoA9BSgMMeu3yf2KWsQ4klMEs9 lLgudpHfjF0KmRtfHakhiFtCMG+vy7vDMWcn+b//ooRHNovBGCUJY8jBOKJy7xLB5FU+Bbzk kafillzhFAUaX4dJFlDJFdFRASnyusPBk7xCPDJR8pFJLpvtghL5S/DyLDzCU6RBkSh/AxSS X/h9/DzfHoKUD0GUMiHI25jFIEh9QwiibAhBorC/ysxiNZEb5e5HlMqpRiEQtEvAoy7X839v hnZuvTjyqCeRh2W47xJ0ZNQ7BW9kUKZCjSxpFAUI2yyfhS2yJHGULydeJzhEkUHPg4l6PpjI 4rBdHKF8gfdmQQg/Mw090KwNgENmuf2kxfeJGOplIoa3MYshhpMNEUP9zYghx7RiZxcaZ2db Agub1uD94YTVIOEkeaOUn1r4RimFXPskChteKeWXzrpTis8Od7SX/+Od9SJ75U9K2itfX7O7 62Xtla/v98oX2itf39Je+Vy+29grX//me+Xr5e+V3575NOT8nfL14jvlY6QpPxYgfpnoox0a Vu3UMC5PUrmX6SZoV9ypm+yD9e/H3Q6H1RftJmWSvG93SWa8TnI/JJRZIn69Mbxe11r4FWCz iY/gKwzLkv2wRLAs/CWSYvJKL8YLKb1+y+PBHW3EiiomegL66E611GfsHK1sTx5talDOpC4c ePM5JHotvy2c0ubMLOSq8SZzCzf6KG1iIWGPO6dLJdhRTuOOVqomD63er4IW4TAtrOLFZMIQ aCbX8wro9BD+Ry5WbaJbdr2q8SfBOjedC/T/7X1rc9tIduh+Xf0KXCVVkSayjAffN3JFluwZ 7ZVlrWRnqjaVUoEEaGFNAVwAtKVszX+/p7vxRjfQIEACpNqbjE109+n3eZ/TRnD6xTkV57Td c0rVwHZ5jXlWKDOdStPv3OWrwHCIbRTbKLax/W1ENgescfZ1118tHxwbKuIfiAE4zLU4DNkF ZA+flFf4qbs2gvQG8cqX7x8uPt98vPoVZTwypbmzsg3JsiXDcoFFdtwX6fStMZ1IR+rx6cGH 5yV8lJaO40pL052jedgzEytgvNV8bj3Tej9Ndx9yL7SqUDo17R+45hHq+Jg0fnKAB3LcGEjw AU3DsDx9ujCN/xtIDCvXDIvjvnxHMm1UjfbAa4FQzPeYSlamzxv+IhFjG4+oXE4vw90rfKwE 71jZayyXbDNc+XstDT+JIkyQ5SbI/prpxvIvRwz2670O2hT7+/U4RqNHotF8AP06+QAouc9y iDo9BnWNcLlqKZKrDYDLjBydjPChDqVPfzwk/J4/EhWelFH69OdD8OEzzDmqDGzHajYzPW++ WiSOtGe6P2C24YnOWRUZRsVU/sdwqXppe3s4NXI6gaFCD5tpsm4qI3L4JOXgp275PfhBLZWO fMC2zsqHo4f/SCvPnB3HjZC5x7JXJr01oGXo4Zdf0qUX0V30Jge/SGSxo7snAUPkwge02JJ0 BGunw9iPDyTJhWW0oUSVEP/mr7xJCMo0oBiQvI+GB7vxO5CC86UrKQNJVib9IfwffoHw4CA3 mM8rH4DZBtrpO7IFMCrpl3AOJ5IEjFHwT9KtdAViv/MNFtVDmTGdBAQYItxCfeFJ8omETpmN zG4r+K+MRpjsONjvoBhWGq6CbQB3CpWOc8O8C5CG9NeVuTJx5tIPT0v/JQ81qBf2So724/cQ wLXl0Q9CsFnU+q4J1NT20u1uvl5fx1jWMxewEZRbN2DcukGFW8d6swf2t4u3bkC9dVN5WHDr kqXVb12qde7W4VLuW6du9tbhwbRx63DH3LcO1+a4dQHUKreOsllctw63o966LjkBKFqxZ3Wf P+lNqmrkBBCmS6XnSt2UY0CZwb3SqChG+ErtqYb5auvCa2rvClSWUb/aup+ss1fJs5gw/leC cniALpkCt35ShAe4L1nS0aYEMkjLnv7NJLIx1XHNPD8PTjcDlCwBSY/RbKIaiDru9wRWReon IAwndKoX1jOwEo5RxXuAXmxngpB58MsBSf0/3pGfgWyFPhA8OHdNM6TjgCAishFAPE7USgiJ coh1MwWTgOCFxUR4JaQ8zwxEC8fAFhgEDAR1gi7G1JgSYQVt7ESyDYaGMV/VAe7m8MheLRbH hyeS7iN3NnQCnn2sV0G14XaRd40pEI8RyEdSyTLoNeCWRjUmKB188BDhBKk1bz5/+fj5683l RLpxiHyLyMR38+Ut0goC1bXcQN159EaTx6NxKNUHEhqcZ6AmD2G2/TAT/CzKBJ8s9Sw0MvyJ /DNul2p2SPqYrqxFJAvCSZDOv3y5uye56ktUB7V4QQorqCjjLC+Y1JSoaU0Jm0NUCzlEtRaH qGJkI+80h6jGHKK61xxiuFk1OcRCGhH20Tz1UdPUh1zRNwxsuiUypJaTITVJhjS1Bh1SQzqk tk+HYAKq5yMrT+JVWTV8VbYvHWnqMcLuIC8/BiaXNAGjTkAJR4hRaRAIkUSJQ6pwnJuuPvNX cAxfJFRiUI4ARVnR0IFNQa7HLmFQNc5pSjVHP6eZKoJdEuzS/rBLfSq7RFeoJS4ChV1KltZS Y1PYpZ1TY2+EXeqiGrsSu8RWYxfSiIbZpRTkhtilBskQi13KVHlt7NJgS+xSn49dSuioin39 q2mt1sotAJABsfygBQEkfbXoL1/RUg2war4+DiHnbFX6dlglH6yq0Gg5GVK7X9c/KxiQ8GNq xI+pqdzVDQCrm7u6Xyd3Nf/Le4V+KYPBGukXG3m2u9Kw+N7sbi4XwADnAugX5gIYyFy5APq0 Tyk75iBvx+wX2TEH3Fxbb1BoxhxsKhdAgUt2zsOcWZfqYV7sH17fw3xzMTXsNSmNqUluVjJx ALMJZ44CvvZnAZNAgCDmpKjpeoPlS3xQACLIhcCuwaIDg/bSI/RTa8WfHqFNjKIoxdluB/Wf 9O5ciEYb0YrkKXDKQRdPgm/2SfBB7klwyiZUexo8CTJ6GjxAquEt6aCkVoQwi1zHlTV9x8nb yJrKjTNhST+co0VNcdAhGMlGq2mZXifxKDMpV/IHgjpHkw52UsLqKZjP0T1xB01NgJGaa4Cz Z/XpqbmCNFsG1q9lmySWWs0mCAu+5hOElSb7SgKnJPvK9E3Y8CDZV5dcBIuzqvWjB2mSixZ8 5c6q1q+VVa1fnFUtWRzlPms+q9qQI6saCHvNZFUbVtzuYVOS1HBTklSXY3V3MDtBcrOSwgkT JKckxdeeKkkxm643WD5JqgBEIEmxa7AYg2HrieaGzSea2xxG0UbFiRqH/InmUlWJj3n+RrWd 7a1LZYVYV8ifKUQZJ4ujoIIuyi0IWGQwngRSAXqeyQXYVHEuRksRiiYXKYeSuzjfZI9o3IBi FLoBMdlzXFNGEIAymM+BaRFKjpA3FW2p8PC5K4dha6gHUt20Z45hHsnPxIdFVhBLGS04/Aek HGybJqWsc1dEgtoNax6WhjV3iQgpvV45EeILdBpSAp1WZ7emE+xbx8hRcSwUe+C5sCd2VUqE U8GC8IUdNQBgWQSAHqJUsBwnuJgF813qbESBR2x4WZJSADuHbIvrbpnMFM0xRkKU+acoUAGU nVkoCn1SkeNHwSBolEplUSr1RCpebTrNKm9WTr3UQuqllh/2IjrWrnPCsNQ5oUEl0YjH3K41 ZG4fVVTqjppSEo2EuX13zO2jXTK3Vx1se+b2Uevm9lHz5vbNYZQyc/tImNuFuX2Xze2j5s3t oybM7YGb4QwFkwBna8KYmcNLajPCsaa43gVTVYQGsgScBoylmegsdYyO8XApA4Jtf6PAYrie D/NFMTekX5af5IipxUtgzZE6yKLNAtfLUblH6IhD5DOT72311+i/iNpsQB+k0MiNorHpTZGr ghx7KqgdVBHxmCk0fg2RltUQ/eo6q6W3QQ1RmaaHNQCKpodVlarpYU6MV1FTG8C3IgAsTQ9z OYimhwXzXWqPE5oeFjyKpocFm6bAKKi7fU0Pc46VND0sKDuzUBRNj0Y0PcxB0DQ9GkvToxGV DXu16Zqe8mblmh6tUNOjlR/2Ik2P1hyF6q2p6dF2xmKhauX0qMdPj3pZenS+WD3ZlnTuec7M 0tEETrZhxyijUtWGRaFd1QBQKVrFpeElUxsCqxOwehrsWtaPiotPKGW1/t+lzmSCflbrm0JV q42DRkIqQ9g+Ba64SjFSLVzLLIWu1stebgWFxvcIja84NBrl77Eof4+Q8Kq7TOcH1gVWziX0 CrmE3rpXuoh36DXHO/TX5B16u8I7jJSeUs489PmZh36Webiy8QsoOEvCF3P2aDsL59uLdGn9 sLxtcRJ1uIwa46ewHDWgUfmPOqvLyzVsow8r0Ycf92Ek+liLTamze4RnqTGyd6l7kWBgaoyK ws3UGCGNntYDt30+p85irsn01OjylW0fhTfqE96ozjhpjFKfxSj1CW9T65jQuaZGIJezUP1C FqrfCFIp4qf6zfFTgzX5qf6u8FPjQXEUHJ7NgJ+dGqTYqZkNjPJCuvf1+fxkG4aCrTNcvDOk uPFwtaO69PCtKa9zTrPQUE46L4RW3XrBvZ7EBYirt3ep8xmyNbw9Hb7el9vzE3+vu1Pd1aW/ mIAkMYpuUNxoGj51gRvtgXtTmu81v5EN701+8/+i26Z06ZgntXXZtYBRt3V9cNx7WLOL/IbV WU/K7jiPdgit2UvZEGT6vjUDm38TG+yPsqNN7QGN5LjfpQ+LheX4jdy/WvAYpKsGxArkrW4v NBJYa21pmPIJ5IJz6S+ODX8rDSHMmjAZeLMm1Aros4meaFi09lqXbaC6AZzaaAccW1u3izX3 uZFuyza9/v5QToAJkvfcdKX7J8t/bOYG1wRJ3+WaQPn3tYmOKDtZe53ze3fpuI7/+AKynfkD mOFGNq82TOru1YbKvX3N9JTfvwbWOr+BX11vtdCl36Ce54Ns2sQG1oZJ3cDaULk3sJme8hvY wFpT9AR/d1x7c1qC5qDTdQTNwefXEDTcJ0U/0OSe5PPod1wtxhOCmJlOQXwhdfpCObbe1kyD Xv8e9dqMdT2zPY12wzgCr1xF9nfUhUG6WNt3M7Ok68Nk7ZFQlPFsJeovWPaNXMeGOmCSIqEu I2QPejGjXpq6lLXAMnGnUJrlESrqCWhW3FNzeLUmaK5tFKqztXdb3RzqbbQf1jkQCrTM7oYd eWFHjV3lmpAZOyjUaPlNNIKevLinpnaxNmjGNgplWn4bV6Snx0RPTW1jbdAs7YJQqVXVK+A+ N61VaK6TdweG/Ql5p0pv+vLBn0uyM+HyBns/jHtXgt5rs4gbHWWPc40amEXU5zAEua5Oovkx DQKIzYjTzY9PIRBro8UN7GYwtNqEdwND64Vnu4acvYG9VIML3aQqdXMbW5cv3sACajSQdSWw 1zvO7u70G23MSZ5qDz1LCZpai/VpXLwIGi+NbqCzZs9CA1QhHFmvWTpTkyiEo9IaXa6GBvVG a4jDamo83eURlA2i6IYJfLyaasOSxWbGOdwk9WuKUc+g/Y3wZE2P9c2g2f1vfIAbZXwakIG2 wYk3OMyNCKcNju8NFYmufx4bHNomD+JGFDIbPJEbUiBt4nA2OtRXHnn6at0L0zk3Zpxxzrns GhUabjkNyow3+DqV8IQdop1KeMILfA+WmZKuZEBefuAbES0xyYCVmGRwIlXYOHoKkoowypON DAqTjQwqhvoXpRUZNJdWZLhmWpHBrqQVGfSLH73AsxnypxUZ5tOKxHbhvc8vUmWq1EQjVQAw Mo5UWm7+1CMbAZtkuWsnI6m0+GFWkir9v0ud81R6kip9v3puUUQA7lEEoHAG3vkI+lcdCdP1 ZDHCOXdno9tFaMsOZYIRzrc7GMn+avWOIgxgf8MABEe9J+F1r5qv3o0Ic8Fd73jom+Cxdy58 XHDauxbmVjmSp0GX3A77dVKdD2u4yDXgWj1serF2zLW8YS+x5lz+mz7FjQ0sdvSsGynX2JB6 zW5iQw7mIjZg52MDOuQ8+spNwK9WcUfxZKvigkB3aasIoQ0XwkoOEmv7ElbpZS+3guJmOAzd DCsNjeZvOGT5Gw5DX8Fqu0x3PFwXWLkH4hB5IJ69M5wH78WeueZyIbnYA1E7wFcePum+Sf69 chcPS931zAfz2T9CnyZv3y6cmb54dDx/MpYV7e0xqerp3uJhCvN48DIfgp/Iu9CyLd/SF3BP /rEyPZ+U2ObPh9ixT1LgfzIpsWz/wVmadqI4GCP5/eA7D3gg0peLWyk9LuoU1XWmqHZ0iirb j3S4rk9WkUPpsDmH0tGaDqXDIofSaKVhrt9NGJgyIN+WcAJ018x9zy+x+4Jwi6IOT2X4n0IO EoHxww/rT6S5gYBI/tMEmCpAJnDIJuGG4s00zDmqPAlv43y1SBwRz3R/wITDE5L1vbR8hlOm lfgerpampFcrmBrZG6DhgLBG2mA6N0Zk6UEE+6lbfg9+UEulI996Mp2VDwuP/0grz5wdx42Q m6xlr0x6a+TGrRz88ku69CI6297k4BeJLHZ0liVp6bjwAS22JB3B2ukw9uMDSQJyOrOhRJUQ rvZXQFYDUKYBxQsdGsPwYDd+h+N/vnTRrsjKpD+c9EeSKsujg4PcYD6vfABmG2in78gWwKik X8I5nEiS41rBP0m30hXwdc43F+FVCYoTECKKL8knEjplNnJXXsF/ZTTCZMfBfgfFsNL6FIAA Ew6VjnPDvAuujPTXlbkyJ6jfD09L/yUPNagX9kqO9uP3EMC15dEPQrBZ1PrAxa5c20u3u/l6 fR1jLc9cwEZQbt2QceuGFW6dyrp1w07euiH11hmKJrNvXbK0+q1Ltc7dOlzKfevUzd46PJg2 bh3umPvW4docty6AWuXWUTaL69bhdtRb16XgiWFvUB48MeIPnhhlgyeaTfPedvyEKNtuPIp4 5mA9jc9+Pa6w6XNxsok3G5I4MRFo0+jIaUrY1/NEdF5pyzl3qgJ319et6mPYmelzvm6d0zg2 m4KBopBsuoPtq46bvfIpzXIt3JFVPjc6TnFSeDTbI6LZbjiPCUXxPWIpvkdEV93wGaXrxTfU V7nafFQYuD/aEG0u0seOmtPHjtfUx452JsB/rJbLqGN+GXWck1EbTBjetkQlyrYsoYpU+VVl 071Jz7/Z03DSfM7/JA5MyqTNjVpIpEIibVsibTArHk3KaBR8C9Jog5d9g7Joc6MUJ6RMCh0H UmiT6SQpMuiYJYOOA7mwyZNJl0A30lO5/DkulD/HG6HDRdLnuDnpU5HXFD/HOyN+quNy8ROW gVv+jOpGAmj9YPK2xSRRtp74KBIebCp52LZTK2xib0+aytKQQj4Jya/2EIW8J+S9luW9+uFs FB6+CaDbl+3qX+eURFcVFWSFuNrDecWbTRHTdCKmNRC+SRHOdJZwpshEZmrgbNFlsiY7KBfF 9EJRTG+QMBYJYECFm5PAlDUlMBjEjohgvaHGIYIpFUQwJSuCXX253PPc3lwzpLAXXO2o7AXf mvKyF81Cs3yjZrpuvvUkLDxXb+/SBzTBpnN1JSKyX2tENpq+rT+ZX68u185i3uXVavCkoMrV l4rSIqWr/fy1nt0/vx2Ngi92K6gHvdytoB781twK8seqUVcPxkFstA/G0U3nvFQb6aYoy3v9 HkqSgdbtgCMzaN0u1ky830i3ZVn46+8P4zBv4qDRukGP6gWpQJs+yE2Bzp/gZiDTj24zsPnP bIP9UQ5rU3vAOqXNHp9XzYXm6gv3yKqbshlXxcy2NOpVyJECXLAAa2cKr/sML2/a8Lr9sM6B oKA8W97Mu8AFe91MB4lEun3ORLqbeU9Z2wDwjbyBXZhpt6Entht/mb63sdVteqRvegPO1LxN 9ZwzSXLpdmlmR96G27cj8+mb18xxyAV8D5aZYsGdEgsu34hoVtop00qrECMq584xLLEVgZRb W6eF1tZpRftGoUVVadCiqq5rUVV2xaI64LKoqhUsqmrWolr/aZ22LaqirHkrtHgaalOPrW77 EapN7O1JU+9ZpRBTwpJee4jC4VU4vLbs8Fr/DQAKl9wE0O0LKvWvc6MOr7WH84o3myIuzYi4 1MCbFxRRasYUpVQiBTVwthhiVoMdlItgs0IRbNYgYSwUz9QGxTNtXfFM3R3xjCPlDawDv3im FYtntY0bbcsdoqwJeUzY6dp11WnVPLjxw0GT7uqbHVNIjinq1R28kPuE3Ncpua+27bBULmig h7Ylwtq3fnMZbpodqDgtfCKlQRMp65vhKfKlwZQvNZr4V/+kMoTNTfVWLnkahZKnsSk6XSiG ag2Kob11xVBtZ8RQjUcM7VUQQ3t5MdQ2Q08rYR7c+7JycXTd40AVPdcFxhAz1z6q/CLlxrtY /0XjElFx7Y0LxcJ1x/UujWBSIuC6gxLinhD3Whf31n56nMqs14DWhhi39s1t2KK37jhe1YZS JC0zlLTWHiZNqjKZUlUvlHPWPzgMCaoJyOXSklkoLZlNkLRCyajXoGTUX1cy6u2MZKTwJAXt V5CM+jnJyIQ5AI6U7p8s/1HIR3tTVioD1dx4miRUEyRdHqp7QLmlom119PewIy/sqEkJqe62 BnJSzTG+SyOdpLRUc4BCZhIyU9syU83LQWW068NsQX6qe5eblaJqjubVbjRFrpoHclXdwdKk qzlTuuoHMlDtY8WQsZqDXy5pzQslrXlz5LBQ3uo3KG8N1pW3+jsjb2k88WqDCvLWICdvNRTz 37Z4IcrWFLtEpoot53pqJzPG5nb+pNlUGylklZTTmhmuENeEuNa2uNZQUg4aM98Y6BaEt4Yu +AadF5sZoTgRLClPkQMxr6m0NRRpD/XBEPcGgTjW1EFkSH2Nd1Mq/GF5hCn8oZfZGqaxhTLg oEEZcLiuDDjYFRlQGfc5ZMBhBRlwmJUB2Tk125Ze6kg2Xc5Bup0splXW5KQs0WnqACX4ciZI StIwdroyCuUqqrx97oQ9zRhjcbAQTDA7tFg0wq0Qwl2Qj45GihUmKR4SGlmw6gziytGwnFwq heRS4Tj6hQRw2CABHK1LAIe7QgAHao+DAI4qEMBRngC636UPi4Xl+MLjZG/KyhmEGrtOZSJq wGMwGnXOJT8zso1enlAvZtRLgy4m9fYxZHxqjO5dGrmkmKMaQxOqSqGqbFlVWeta0PnUegDb YPzrXOFGHUpqDeUVbi5NUFFDQaXOUKnCjMoUZkahTFLrJDEEnoaAlwtFaqFQpDZE8goFp1GD gtN4XcFptCuCU3/E460/riA4jbOC01cXNkCXfoM99HyQhIXwtEtlZQJS7d2lMFS1YVKZrfrn kJcR215PK9LTY6KnBoWm+ntLBKfao3yXRjAJ4an2EIUAJQSolgWo2teDxmc3AXT7glT969yo MFV7OK94s2mClUYEq/rDpQpXGlO4GhP5p4HTxRCwGuygXMjSCoUsrUHSWChojZsTtFR5XUFr vDOCVrmYBasAotPKnsL5Sn/+evP+6uYyObbZwvFgQBMJDfIFDS1o4IHYKuNxoipmej4e2hI4 Mr5vPi193IrASbXO9mNO8sXwY457whWMAzQMBTZzAiQVJj3SBtO5MSLbKykSIo0KvztLMrdW CeQnuCr6N1PyX5amhFcuK9yY5+eBDMMAJUu2+VOKCFOimoRVQK75j5XpoTOCLodvGifUoRyE 9QzHNumjhSreA/RiO4CqTqTgl+MC//CO/AyuDfpwgK/K3DXNhxDykeNaGNBJCPE4USveNpiS Qi1A52U+s/2weKm7nhnc3NzCWdHCMWRCDAIGgjohPzxTd2ePD2h/4ZI8zK0FYB5A+kfO9O8w gtkCEPzZL8eHqVLPQuuKP5F/xu1SzQ5JH9OVtTDCnmBlpPMvX+7uJ9Iv0r+HgwA8Y9mWb+mL cOkSJZ7p/oD5hAW5WfsMITnxOUJN/WEaNw0Aa8Md9l7smWsuVcnFeFk7SCBI2sFQD37qlt+D H9RS6ci3nkwHsI4srTxzdhxXR/fEslcmvR26dvLBL7+kSy+i4wDX6xfp0fHgAi6cmb5A/5Sk pePChzEiJdKRYc51GPXxgRQcnQnARWyuvwIWLgAFCECSYJN8NDw4vL8DRTpfurAekqxM+sNJ fySpsjw6OMgN5vPKB2C2gZDQHdkSGBVsZjCHE0kKDj38k3QrXYHE4nxzEZGUoDgBIbrE6HrB 4QYUAku0gv/KaITJjuNbjYoV6UifAhC4ulDpODfMu4BiSX9dmStzgvr9ACj0JQ81qBf2ind+ 9vg9BHBtefQjEGwWtT7IZyvX9tLtbr5eX5Pqlg03x1zARuTo2yBP8gZpkienjuwiOrLiIIuD 3OJBLiT7YR+8DIXW52Uo1DRDAQMy3SfTAGbZTFLM1PcCQpH4rNM/f6Z/9hlQ2KRXXEpxKbdN Xfp56tJPU5dRXqDqFwlUo/oCVfIHgjoHvqwfKDMkzHyDgHh0T6TsYw6haoTlnj5dqAoEJAMf jWyTg+AHkuKysl3wNS/alYppSeAUMS3T9xyPnSmmGQqs50bEtBTkemIaBlVDTEsOhSGmZaoI MW2fxbQhlbtVqYQ0cTAohDRZWoWQptrlCCku5SakanOEdEwhpHgwbRBS3DE3IcW1OQhpALUK IaVsFhchxe24COkwT0iHPGKaKg6yOMhtHuRCst+wmJaCvCdimriU4lI2filplKIfAIVrFd6R lbsI7glcxSP0afL2bXQEJmjv3waMq6d7iwfEtj94mQ9lvBzw7EmOV4H/yfGAnaVpJ4qDMZLf D77zQI7ll4tbKT0u6hQH60xR6+gUtRi258y+m1BHCaAuYc5wqnPf80BdLMQq6vBUhv8pZOkI jB9+WH8CIiICIvlPE+kNCIFoWSfhFPDw4f6jypPQNj1fLRrg1C0Kq94bZY29FKwp97RpbFPL Ys1UaYw1FWIfL8Od6dZEII7xACndOu4cTeRhHneSwZTgTiXGnUpTuJN0zIs7Se1y3BlCrYA7 aZvFgztJOz6GhtZHMxqSNORaGhICan0NSfpGUTUk2SpCQ7JPGpJBP4t3aYJlvwwb53nYVGkt bJznZHcPG2+Ck+0kNq7Cya6LjauKl0ONFxt3Xbz879//p57cKe6suLM7cWcVebTmpSV09Q2D JdgSL6WW81JqU7yUGvJSaiu81D8ZqM0pxlR8aPOpGMgmWDTGCAK3dnK6Mu79NLf6gL2bIexg AJ0AjDXVPZOWCEqKE7Erx5I3A9H7TE350S/ofUAVNJAlbJlpz8xEZ1KwGBdoVsd4uJQBAW8H cv/ccj3/TMFI9EwZs5y/oaazPJOrOn+HoRWGiW7LrkRXBMPdYOxCqoNc+AKUbjZ8ofEO4vCF s7PgXM50OAzBRFFnEokECk8C+XvLIQzNneIOJ1xIHK4NpDRIAWec3A1lNWgUePmJHZWe2A1n NmjytDaeWzBxECpm+Es1ZJygNZL8cTcs3/lh6c7XSPTX3K7uWNLpxMZvNJlzqhvG+dp4PucN dVN+dgelZ3drOZ0bPOldfy8rPnSbeY4qCZ5xpDf3IlXT8MsPcV86phhC+wxDaGjk5jGEaixD aL+ThlCK6n3aH8uD+YBlCc0WV1Tk5ZqnbaFR8db9/WmqvGg0W7eGRj3zKfOi6mXavARcbnUe Y8vK9XlRQx6FHqOXJmyiOdA1jKIRrHU1ebnrRVHlUeoIu+g+20X7VLvooBQ5Z40s2eJ6yDlr ZtlN5Ny8oaXDyJnf2FIHOTdpIs2B3msbqbi/4v7u3v0tNJcWX+A17aVNs1lUiymljjCZCpPp 6zOZ/kW3zVBRV1vxhWAFOteGVF5moPJaHzJD2WUylV29QBm19sIw1VxNQC5XcPXKtLRbeHZ9 z89nfWiFuRGvP1/8P5Qg8de785svHy4n0rUz+y7Zji99c3Ub7SXOiTjuHedWDPgErJk8PT0t OQRmdAjWP47b2H5gKaRz6S9Auj2gro2bozB8Xfp7DH8TVikjRGON9sZAbQYTtWkhAmpyUZno blO9laNADYYEP/QX6UzqyX1k17dXTw/oclgwhjNgsoovhxFfjkYHv+0LozSDNpOnVmmQus9o 12KdDhg3Yca8CSrtbK6xWszD32AH5eddLSX5M/qBXmdAmz/DV18uy3Nw58+p5Rvl2bKZZ3FK ziIfEMZ5mzLPm0KOA9fMmGeqIpDyc6NIx7vLJa2RQfo/zt6kzprtoDV6lIh8VpPdXPtaKHKd FON7yz1tpoc2jlSjm9DUMavFg+02A9IY0LYP0zqr20E0tUV6X6nh9reXbyWa2kI271CwWZeO 6/iPLzBM84dpe03cbyMA6cUgGxIwdMLU1e+AwfDpTIZPJrxa7dViMoMNdlDOKMqlAoYeChj1 B7R5AeP93x3Xlv4CwzPtxpmiKQb+9wj4JvRJY3Kum+yKccLHrBMeRPg0uJSso76RnkrPfGlQ kTwOj3yTI9vC4dfdqe7qGzv+AfjNXoBRcAEa7YxxBUasKxCECzW6oKxLsKG+Sq9BaaSSPA2v AZ9eYvMHfAc4lMaAFm/NKMJQjR6bzW9hcr/WEQ2S61hDJzgkWKYiNAYaGbLQSBBXVm3OLDyx LrBSRDCU2hCI6t/lDsq7O8p+bgB8Mfoahuir4mneBn7ieCWUhpY43vNkYqNBiI14gDCQ0ICF hAYh3uCYGAv3VIRRinIGraCcJm9n15W1OywLbKSDFk5bozvQ9fPWKl+3HoTtH4mKi9SqNniL hLBSwzZ2jWcl2tusRnH7hrQ6feQBvhEdTp/F96DQ881obBqBHPFI3gIOxMLyfNM23Qd95ls/ dOCRhuHLzWwuehBz0Tx82YaZ51d/DInnbg6h4IobcAIO3SAH8mg8zLtBvnv3TkodLWpKe+Ut eU3mbIwf/xpJ5xcXH26/SHPXeZKubs/iNAh9bTRUpKPUNwQg/xrNiPYp9UDNOP/S26jopbcx d1BTb1D4dvaYnHTDeaAGiFtPjHjfpzAUBq2qYd/CQvsvN+gMLSbSfxSlMXqHTiIJVf6hGvZR Ud0TGeMbztrHMJEIOByy6Y8jdajGEMinLUD4j//4j4prclK2ZsnNQm/ehYiOnS1KejL9RweO sDo6CLZ3Iv0wXXSfz7Rq7cNbR4AYNuaHmE3XG+zs8ez+6tPt9QfJ8+ZncmLMmkT+UQLCd8ry ZzHQ/XgtbJ+qiqMXJyQe7kxBN/BsPCRt0yHxvXRE/Ci1Vncf7r9ef0m1Jt11CqMoA7UcpSgI pYRBaxmk8mTBn2kR/ihFGhyYYs3L3WgzKiKg3n7KjO/vLn6TaGF7qiRL8Ac96iizwgZRhTDS MBmTd/bLcW4/Pv3xRxxsiPZy5rsLL79txaGSybbA+8CROlROtdPBqXLaQ/+vyhr8NYb/Vw6l I9uxZ67lW0B58wOyKgVlTotjNWGfEuOy4WS6M9gbdLvgFqN10n3f9UiGjOQBxuvPjJ0MwiWB CXVNQFfBYp8dZhb7MA8SdXeGOutwaKf5j5W+sPyXVGgnHtrF/Q0++4xak0Q1zMFhWcE0qoWC xssCKBO5VHsYFsbCwUqn6mgcdXocdfqMOiytbb/UYtzHtK/bRsi6RuPmfNh6RBppxmGtx5KD e0RabcY5bV1gpRYBFNtaxLAolbe9u+hmO5Hk6y1bXDWZjSVsgOgcg8z1ELd01h8VcIoq5vUU VaGwimMtyyp2eAMtm49iUOsxacZmTgcPcYGeg2xYJGMXGh45RdI4xOhstVJyG/s9JbuPsBZs 4Oaz5Z9u6gQzzp9MO3+KIrNlFWBlPpwjZiYhskRgJBtNyTI9JAlh8aWYRvbCFe2W8yy/ln8d C7dGSF1VozYzz71G6FBVO3Z5s1JCpZUyQVr5lWl2K/PZqbK5aZQw+QyGurIj7Vd4/IfUDKK5 TDb6zAd8tniRUImxSZ1tA+C2bCnqiIG3uvW2bYZ4PQjb392W3NPW2tDGUXlZ3e1vx2YtsQXL 3Ty6lfnQbZfUov1ypaiKlKLB5JNfv94gLXlyZLOF48FwkH1LN3D67aC+h21SaJSoipmejUey tum+bz4tfdyKwEm1zvZjTvLFkfULVzAKTbIV7WpwphBoudiwpnEZ1mTap9R+w0nKbbhctOEK f77AEtMaTFHY1nbGthbu1m4Y1yqPtj3rWjjUNsxrcnq1+O1r7SKWMgsbmY8wsQkT266a2MIT 3KSNLQUzMrIVYqUtqdL6SgFa4lSldRNTMZne5A8Edo6mHUhAEk4+DDM6uieqpWMO1hdae5ht pPK+AR9r4ATKuTbJ5c7x4OHnPBNeylCn4FM46lz/hPENeOrkWwiL9FsI8CnKBL9yF0GGZFhK KmutvQ0SMHu6t8Bk/cHLfCh7+gE9EJQW18Ls3CjbNn69Jy5mvRN0cSulx0WdYn+dKaodnaJK eV9JZryvJLOAVnlfSe7k+0oy/QkA1dTlgveVksVrPAGQap5/XwkXt/AEgEJ9AgCPppX3lXDP /E8A4Oo8TwAEcCs9AUDZMmqD3BMAuCHvEwCUXpp6XykFuub7ShhWncT/qevFSPyfqSPeV9rn 95XkKu8rJU4G7X2WZHE95Ex7n2X3kPNm3mfpKHKu9j7Lusi56vssvTE3cm7ueZYmsTTzeZZM HfE8S8nzLCX6iNbsUU2aSRQeM8moKTOJUlVHwM9TlZlJFGEm2SEzibJTZpKqo23RTLKep1Oj ZhJlA2aSDSKWUjOJIswkwkyy02YSZQNmEqWKmUTpgJlE2Y6ZZIOYaotmEmUNM4mSMlModDOJ sr6ZRCkxk2T7T5lJNqNgV3dewT7S5J42HTH065nSihqcbOu0dj0s5dbfqBvU34SD2bpuPeyY T3sT1i5T3sRQuXU39M0qV92E7Xg0N/Q+mtCqZyHXUKqHoNbV1mRvFEVZk68iNOqvT6PeL8PG WYV6prQWNs6q03cRGzevTO8oNuZXpK+PjZtUo2chN6FFbxYtU3Xo+SpChb6jKnRDN5/QZ+9x 5RvOTzs8FnCB4SJLhAzAr1MOYUhFcgUjWiIpgJB6B8G/56gNET6kI6SxN6LB8EhgGgI2Lu+U 1DsI/j1HbVidpn9PJEQnQokUBOpHNAC8zig+3bKRXxXN80rNicDDvFQ8TEvFcp3rUfWIDPmO CG1uWm4ig/zcBi3ObcA3t4X/Jrvb0ZHHUem+qwYB44eBDhygza1vBwllz0RyFrNfF85UXxzM bHzeUA1ou4LeAPl+ptfFgL9+vbqcSCNZl8e9ofpmPB9rbxRZnb0ZzeTxG3NqqtPxXFZMA44T 8uFzXO9GfzKTQyG+fV+AxwES/rScYC5B7il9VesP+8rfDqDLe8y1oa4UiW4IS9dSqbXUTC2N Wkt7exAmGMiMRTvty9pIGf7tXwgjBn8pwT8PnhzDmltmfnq44IU1Pe1vB4dMkxSBQLE/kQKq sYkUcduF1q/OshkFgz5JzYDMkFSz/tdsY3pkvIwhdH18KAlEeJcT7aQ37zA/0x/NRrPywE15 ba1sbWjIFkduwkQqi6qlxcdOo/YksYqNjluchYQFNNcEEQF9ZhKe9tmHO472iaQ4MO2ZY5jJ 3CZBCtlw4KslShWSzFWgYDvhOhkKKq1eNpmCC4y+DjwikIKYBhiAYFwHholoAyL43gswQk+I g3VW7sz0TkPWwHeWS8QT/Un8WfcPXslT9XThfNtYHzhHca+H/x4OyN9K8FvuDWRVHvxJUeCb piqypv0JCJzWU/4kyRsbUeLPCqiZK0l/erJmj7q5KKgHNHEbA9run/88+pdj6V8/L037+vL8 diKRm6We9k6fpSOs9uhjQg9s6kQZTzQVah/8OVis/7Sn6uTto/Nkvg2+vPXc2VtkNUD44O3n 2w83COzD3Yfrhw83vz6oD724lGiwvLe4y9gw8Q05P3j+9MUGBuRBn2Cdzhn0BDIs8k3AkhJW jE1YzFG6DnY8QmYmntqKFDoqYR4WDRYlWa4QsBGKcle3PwYSsdIcHaeNW+MhrK1hIKUPFDxZ wAejXEzeaonUVVBt+iItXcd3Zs4iBhgOLGCNEXE1uOakJuaEJhSal8JglBDxktoR4y2RDSLY lkScJGvg/v8Ppk5Tffb9If6arCG9v3wvoXLTNuh135vudyADLxJU7J32T1V5Ih3dm0tA+SBY SKpygg7gkGTbKerpt0RP1LrcPQGR8v6xyAI4QnzPGb0AkTXf1W1vsZoBEU4UHgRDekB4xl8t H7D+Bv9AtO0wYoIO6wo6acGhotwz7o0MQ07IPWNtOnozU4y53J/3B7rSW1/uYUghyumgN+6N tYQUIteUQhQhhXSBy+/6+IqlENUYjLUZ7TbC3bnUfR27pPzzjfLH3MUaZSN3OcNaF/S7+zFo dxFd3LDBRErDXcyudc//5BgT6cvd1w/owyf9+RK5vFwC4npElnr4dmfqxmd7AeP8eH59j6vd A3/9pF/e4Mtzv5p6+DcG4AByclysxCPV2agiM5EMytCHsppGGfrGUUZfBt4wgTLUjaEM1m5n jzCrXv5Es2ryHfANtqZiH+b8T4rWput3v+vjS+Em5qYlUNVoxqR40bWnzCwqo04uKuWeX/UW XqoFiwDGcyA00Ivn9EqnXUaY5D8YLGOWKqXITtwKyInj+Le/TybS3367+69r+6v25aNztj6V 0HoZKjHeApVQ1cFWGEvq0heSiLBSCX0Iq62B3ptqWk4WoglnaUK8El1HuF0fH5sgRHuVpgbN qmzDNI0P7mphPqw8E8u22G9bOVVPRz35VFG0fp/4mcONkY6Qlvqb6b63/M/uJ9T8eBJle7wD KF8RwjliNb85//RB+rccjH+Tzm9vr68+3EPLSFGClEv/RQJrpH8l2u8v/gL+ubKMmxWW6v9V +pb4N6wfIKnZynVNe/YSfbCBqb41idsN5dv5yn8k36+MBUZIyIuJfECphRGy9t2r+SfLvjZt WoH+TCs4t18Yn+99c5n4fmX7UcVrpOq5v/9IfqWkAfLpzlwurBlOTHqF7AU/9AUpuHdm36cr NJgre+Y8RZPNf48n/CUws5MfjrNIfbicXiA9/kfXNFMf7pE+JvhweTPLfrq6vM59Axkn+vc9 drm59/XZ9+jT49P/M8MNe9QttDt3gVNNYu6X09tAbxYfCzKsyPh8C5OAxkHB5f0TrCDSNVoz QtaCqQGc5xc8mb+uTPyaGlmr5b3pIcAL55t0LB2zL4KWvAjntlH1Jmi5mxACEVdBXIXuXoU4 5EjpDeCf8hjOde9UlY5mQLWuvtmOa16d9wuvAxMGuRJ5QMkroS98ogdNTBioZPkQFTLED8/6 zF9zhEpihCk4VQaonvZPFe1U68N4TNcHfhWOsBkOJ1mjl6qBO6RVk8MQtCsDEAPmfz+i5yEu nKelg4KICqYawyAz4wBExU8wR9910PWLPn14Blk2OJnRx4/A869cfMYQg3L/Yvv6M/zMLI46 jtBr1alA0xRm5Z2BwLACw3YAw4aneCgdfUM2PWKIQ+eE4+gPg6NPa5k89BnRG4aTkY/hy/Kn AYtjfyMgyIfzGfYVRy/ZJj9/1K0FXOr4w6+uPkNjw1+yMwOsFlo/Ey8pUBCbCjzWyrb+sTI/ YRMerYqKgKGXdHwMJTC70moClvTNhbl8BDxA7jCllgLL7sx807/3kQa9fMmVcMmzrZLLjZwL bnXP++m4RnSI3JelT44hLNhvluc77kt2rZSBdDS1MoNJlsfiGMdQM8KXQIUCFe4CKlQADUwB uqnbHIc8lKuSLZKH/FH34DjARcQu5UH3v8IZX5i/fb0lP3+zDCM6F8RAFxwLC0VcxGsa29rC M0IMdeEv5ABjXjvO99UyXLEbB3ieWbSLluu/oFbhh2vLhl3CpzOxK3jBvt5dJT7d4TibD2g8 Yds7E/lrn3uwIjHvCfM176JQo3g3n19+f3TOn66ikwCTWCAVb7S3CH+bwDa5uvsSfz/HQcLX zrcgfjvacBTwFC4LRtef59AvXBWC4e4ASQeX+/bWgZv08pvuPV7AHrlIF5Uq+YoWbfY9wgZ4 uPf6j/SZufv5FOnUPunIVTA8SzfOLaEJ4Yc7c+HogGTDL19iXw6EW2f5zzfOr4tVMJ2vmAYF FbOHU0kKPigCioKmR9KRvXqCoc+YmHyYEE4IuoJ6NDo2SFT87BomA14/Ua381vSzcg2bNtyf 319/MmfAGVjeE9qJH4DMHRfp26MfMZIAFAr/tUnhzCYkBPH++hRosUGOtGF6M9da+hFeIQLT R2thJn/DXUkeweDfi4XzM/y3+82LG537sIbTlW9+xpC9zNcvL8vwICG0fHV5Z/50rfAEo0// Sw5j4sMdkM3n4Ca/J34/wfEPlLbBL8vTE8O6tPwLEpqGFt4L6c9ssQrRyLX1ZIUIEm5WPAf4 cQ1IZBFiGwMAXDshtiC/b/UQSyfsNmE3nzPiXPAV8NJCD2YWMiaYIbkH4fUjZsnSheiuBl8s Ix7f7WL1zbKT/04NP8Q7KQKa+pHesuBjqgv0LQ3zHyvLjXAAciaO7i8ybF3ef4h/3P4eYADd W/yGAkajX4BzF0/xz3sTIZllSI1MYGUs/yX8Rbyugl+AbfB+hUTe9f8rwqwJyhJ8CAN6CH4B FifR9sv1/cX5RSzgx5PMlsR7jEpYLeLvQNPTRdby0XTvV9H5Rt/uri9QFpDkh1SjO902Uh/g WoOMcLGwIswKHy9/u9Vd/Smu+BV7n9/hix/SODiDiLuNaBJ0u3QibBwwwzEIYGViAgg0EWjB pemb4TZj+gd47L35qP+wYvoXEUigZsgBD0YX/j6/uMZH2Uh8eG9F1xdYp3O4NK6frhR+pdVM MlbhN4wkPqKcdkHBl4/3BG9GH5JMLjTM8r2EoyLMNmEXTB/u3/dsJd2emVGdv65gB1Bsdczp Yb/U+NSEXyKVTIj5QmL+eZn9crtyv5nZWgsj/wVh1BBHGpafuqwwGbifsFt+hHeTDGI8T/hp 2cmfQSx38pOV4rrhgw8cnotWIvjyK+rkVg/JxOU1SgR0H3IdIVNyCTLtIuLYwq/4mbHPF+mP 5O/zS9rXz/Ps9xBwgieLud3EbzTKmBdCXxCbtYhwBv4UxlRfvI9QaX4VgQNKUS34nTlx8AVY o5ANyl68BL+DxZ/c1zvzyQmBEy6I8DnJL5kxkY/RVQTciFAkPiQZ1qmX5JwKeR4tWbOA6Ukp oTnUJTl9s2B7BNsj2B7B9gi2R7A9gu0RbE+jbA9yA9EGp8PxYKiqIwXZljFr4xo044ciHRmW h4KIVpb3aBqI0+BQfwYsDb1pzgQUeGVKgf0ndJyUkME2cEgF3I4NAFJgCLi8IZwNQL8gwcno CukLC/gAg9DdAIRB1L8AwHdNTLlyo0Idmeb5wnOCs0uOP1FUv484C0zgboLtDAIfQsozn1vP SQwclmBchzDT7DLSaCYRVvT5zox4guh+X6Lj9xQc8MxxR/CXPw3CJSVWx4nUl8Eskif4xvEf o8tHzgqeXoYlpljyy/ecZbpv0FiPhhkn8SCRbpNk2hr+KDjyN4mxM6Y4BWX0DedMCx2fkVc0 3muUUc2akxa6YSSLThKAndkDzmqKs54A7TXIeZWOKLWPT6SE97R0GJ2riywwzNECLJwr6jDR iFlnZrOb5znTorpppr0casACMytSPbyZtSM3b/ZMEyikuFJsai7u7uL+hlkhhaGKa70kusuc HWDMJxLJpzuRmk5FEV8POPUNvJughu8myCR/E/PVBE1T5HH+1QQ1ly0o/5b4KJs+KFGO8wUX viRe4fnX4rTmm3lW+h3dxx25s79L9Rvl0ufJ7p+qwzhC7b0PPEpNjJ32PvkKgG479suTs/Kk KDdyJw6NNiw/NPVS4ReeEJIi/hCngt9MRvg4P3pqRonU6GEmdLk8EzqKHCK5Q0l+U0JIEVwY OD646czkcubcoFAEZnvz2fJPC0/7lhKqFxx3znTqCj2denvHnJlJPZ5aLnU584FXRgY/uSBt YGmycznOJUhJ+pcoDSlVkOa8QRKolJNARW6EBOZT5hduM3/GaHVcuM8bezJou9FOm8yMkFyn 5PM3gQzA9zIPpXI5XL43dML6wYM5oWjCeoeibR6h6tM47V2dgdorvzuYEyACAPN1FWpt9PKS xIjijE9rPjnwP5/++/f/+YOVojZTzB9eesK8syXVOUNOType2K0B4Q9IPUlhiNJVTO46kSOJ IyecpT9jsTCwWSCry8Gf//wEN9BaLkzph75YmV5cJ/b/g1qOHVQ4QUf0m/8o9VIdffpM8EjJ 6A5zjfD7NYkRZXpmKjrKljiv9EhHdtdSeySgFdUh5qndVFEkDFtFdeKt2rqyo+vBzmJ8Ynxi fIVDELk/RO4PkfvjdVz3yrk/BOsnWD8G61ekY6inmW0UGFXNq1XTWChp/a7WTZVFsVKX8R5l RaWuUkepqxQqdROloe41UOrSXypJpRxG/y5Pp6y9DZ4hwcmH0So8eJkPZW+loSc04wmg90vC d6nQQ1P4fcu4mPWS5sWtlB4XdYrKOlNUOjpFJf8C6Yj+AOmowvujGuP90RH9+VF8nrIdNTwk pdqQtvwiqqZkkFwCowaPgKlzTVeYD6KmS6s+wZdpnXkQNSi94H2CT2noCb7hpN/PPcEXDGb7 D6IGHXM+wRfULn2CL4LK/wQfdbOo9dNP8AXtqE/w5W7cG4XY7GbY2zm+Ml/vrs7oKFy6vEmZ SrLYLkyNf/RGOT5IYNVJSDnQcMnFPerhf6MA34U5h0OUfXOPugSNvNeagVznvdYA1NoPA2Yu PO1hwFwV8V7rPr3XqmSpAu25VqWMVuSea02XxrSiEpXIPdS6g1RiAw+1dpNKVHiotYhKVBWp ZAb/LI6xOMYtHuNCml/1veF+v+jB4Qxo2oPDWA+UIwfPz428mvtP8ylJTdEcDPsBPuT9Ihb/ fDXeQ7m5/85y3RAlyZLkyWhPh07rv+sKfrFyYuXaX7n2HszIr+J99n2PzCy2OVbaUx2Z4STe 5Wg2VijZNnziDUUoJd6AzShW9AXW/SNHfOAD1x/OYLT5Z3Srasf5nl5stapWDap47E889ice +9u2D0XcLvab0OVep58cz+s7hTJEKEN2ShkyGHPbVnZZGZJyskq+BMkXr0Ftwf+KZK2Ai83D qfTGZEH4BmNd29eCiJJqOqJOS51CsSBUMq2t3F7Skczu8Mwxv217vDJVp7ljCFWo8YrUeOUb vlv6vbI4pdQj9yWhSpnij0G7sDgVyZSCG73NMZG+3H39gD6knm1BTp1O/CbHRPp4fn2Pq4U5 5LAyKjpwGED0oEdYfe3QqKGcCY3StxAapfWUhApO3U5oVOqBeE70zI2U66HiBlpXEmyKxJld 4VO6Oz52vFRy04TqT6j+hOpvW6o/RXkdyr9ZPosoBSdmq1CxYy4bKTen22hDlpkqN80Txuzb 1zq9nhKhfBFqq/ZXrpsYML/C+XFS17rL0ykdqlAQ7ZGCiLLDu6UREqKMEGV2XJRRFG30GiQZ kXOymt/Cmjkn25cZXk+J4PGFdNQlo/4uY9UiQz5tXiVW/N1fikpTE1LZHkllZZmbhYQmJDQh oW3R2CQrr0RAC54qRlgHJcxYus6Pk+pkdQ0oVGq7BhxuItxF2CyZcJ1dOVl/P9uXq7pcIiQX IfO1L/MJRF1dnlxrzahiplj9tUTYGhsgJNtuS7bZp5LX2+3tPpsrxFwh5goxNxZzx8M1pVys vXoyDSvKUE4SlaS+ZzlqOqPNEH0/0z/7DChP9M8hC18zSUppVpR6IRZhLIcuj3vDZCzHaCaP 35hTU52O57JiGmo6XYuCyUE+100mqQu1lpqppVFraW9ZQSDaaV/WRsowEQSi1AwC0UQelu6I Ht0dX2keFvR+jWAcBOMgGIck49DgC9kqeqVlXPxCdp/nhewx5UsqwbOaezNnXPRmjsrN+ZS8 kK2KF7K5XshWN/RCdiHcTbyQrbb2QvY4NWPuF7LbuzqKzHF38JvXxBaW16xb8Gf6ai7K/d3F b6kTqQKxhj8y+h9LjkEVwmckjhICytkv+dfBP/2REHPQXsx8d+Hll71Yckq2BdEGjsShcqqd Dk6V0x76f1XW4K8x/L9yKB3Zjj1zLd8C8pAfkFVJRpsWi26wD4lxoSfC3BnsAboacAPROqFX rD3ygEbyAOJ1x3qn5OJ7M2dpovfQUPQ+wCGLfHaYWeTDPCj8WDbqpAiFVH6zDkmm5FkP8vQI kVARQDgnadSXwiIDVcmgEcQXMyGZz5Z/Wt4ZR/qI9CjGgw2MYkaJUUh3qyi5jmvhx59wlk1c 46eO0SOwjgg3YiwZIscIgatyL4PDpSPXfIPLj5vfB5rWNDUepadu5iyspdBNbZTcrz6yRu9X XDWpmwobIDTHwHI9ROzOBr0CIh+8Kgk3MU/lx+Pi8yneNhFi5C6Kkc0GwvSUkbYTjlYsOa+m AxagTYxDXfOEQvQo3G9BbSpLXFCfm/HdBgwWR120Oifl69e+89C+lQiXHuEM1f7K7T7SzO9G 4ZyoW7Qvq1BlWsI5aBedg4p3dYedgIRjwW44FmAZ49mndzcYqiqtO+GN0BXa393xCW8EoUYS aqTKaiQeG0Ahx5C2qCqjYXU9s9DIiqu0B1epWY2s3BMaWQXwjmfZ3IJ1UX26aF3Ugl+43hIU pm62cJ1OeNayfX3mvpUILaPQz7a/cvuDQil62uK50TW1e7Ye1aYndLa7qrMt2lehtRVa27a0 toPTkaqN+prQ2naZI+ju+ITWVqiahKppM1rbYp4hpbeVe0JvKy7TK71Mjept1dHauRz2Rm2r /gFYB9jub0vgNR2bV9TmaEaXuDka8gverQBjanZ5lvKkwqq3rxfdtxKhrRR63vZX7nXgXIoO mGvedFXwK1qytaYutMW7qi3m2F6hNBZK4xaVxgNVGw2E0rjL7EV3xyeUxkLPJfRcm1Eac7EO Sd2xCodBqI7FlXqVV6pZl19tNH7tqmPtD2dp2ggQrzhe3IIuiRe34RfCtwiHqSEuWbETvnVt X4+6byVCuyn0wu2v3P4hVIoOuGyOdPXvnq5M1WkKLe+uanmLd1YoeIWCt0UF70juD8ZCwdtl PqG74xMKXqGNEtqozSh4y7iGlF+wNtaEblfcpld5mxrV7fbHo95r1+32/rAtj1fWZlami9nM 6vwS9sZBMFW47IU5KV259hWd+1Yi1I9Ccdv+yu02tqQoaQvmQ9fP7sECVJiSUMPuqhqWualC Ays0sG1qYMcDRWhgO03wuzs+oYEVOiOhM9qMBraAYUgqX/vj0UgoX8VFepUXqeHXzdRXnUo3 9VKk8sejMWUL00V18wxIUW0+nmQLEKiMY+GanJStWftaSlHSiHbXmJ2ZzyBaLcwT+OfMecre h1yF/CXIVeE7t/RmGd0LZXx50aGjkygZYl7j9Um3AfG6J6XzKapLlZKYtbkFp2IIeY1ZwVyE mlwYGFpeuZ3mCDK7UDyX/Mbswdz5pyPMCrtgVqBy7Z2j6g1wNAWTOyllEpJK391lFXggPHEz G3xrQnTjTKjvDgBrPMD/WbYFx/QK/muhY480Eb9dvpeMAL+IcyrOabvnlEolurzGPCuUmU6l 6Xfu8lUQ/cQ2im0U29j+NiIHFWxV8nXXXy0fHBsq4h+IATjMtTgM2QUUSDApr/BTd20E6Y1k O9Ll+4eLzzcfr36V5tbClObOyjYky5YMyzVnvuO+SKdvjelEOlKPTw8+PC/ho7R0HFdamu4c zcOeoVau5K3mc+uZ1vtpuvuQe6FVhdKpaf/ANY9Qx9Cpt4BFXVieb9qm+6DPfOuH7ptHw+OJ hAE/OcAfOW7cQfABTdGwPH26MI3/G3jCrFwzLI7H4TuSaaNqOXeiIlluq95E6Gin1uEItcv7 xBDr4pkmzY0zpSedX1x8uP0izV3nSbq6PVPU4akM/1MmmqaosnSU+oYAHFOtj4PAeoSdgci/ V+7iYam7nvkAI6QORoPB4Kqe7i0ephY60JkPwU+0DBbhcR8C6xkpsc2fD7G1VFLgf3JsmUKb nSgOxkh+P/jOA7E/frm4ldLjok6xt84UlY5OURHeZ8L7LON9Nh6P1Z7wPuuyNri74xPeZ8Jp RjjNVHaayXh6Kb2c8xd8Snl/ackKyC+G1IDjPPuOlhQx2pa9hMMHzAKuz+tz0xskPG5SjQKO EV8rYIww15K111tPfolLDIuIFMhrOcTGrEvFdcXCY33xc3MKN/aalCrckpv1/urmMnRiZDY5 lJ5M/9EBcUAdHQTbO5GAbfHgiAGkSu3PYE2QyEWABHwgs+l6g509nt1ffbq9/iB53hywfDxm TSL/KAEB4lxxDRZt0ULSoq1NqDCWmBAscqagG3g2HpK26UD+XsqTVOml1uruw/3X6y+p1qS7 cn/WYok1PQS1/hNjraI0RRmW4zQF4TQyobwXkgV/pkUIrHMKpDZsKfd3F7/RlDVwKGQgvfAf OXD+TBKGYFlRhbm18OHf0lFCVjz75Ti3H5/+CKkJTBPt5cx3F15+2xikiNIWpEw4UofKqXY6 OFVOe+j/VVmDv8bw/8qhdGQ79swFwRwYrvyArOKeMp+n9M/hnGCfEuOy4WS6M9gbdL0BjaB1 0n3fhaJfpH9PHWC8/vhG0zbBmzlL8wxuvwn8FsAji312mFnswzxI1N0Z6izA6uEtQco6O2D2 KT0eh/WhkmXQa8BcoxoTNG1prlsLxI1evn+4+fzl4+evNyA23zgEoyI88N18eYtUcsApWm6g hzx6o8nj0fi4EGMrBRhbqYiyVYx0FVnBrTWVG2nDkn44R4uawN0xGMlGq2mZXoTIu4RH+yws mvyBoM7RpIOdRDOzHZjP0f1qNgPuPzWB2QK9dPltIqGBvqDhBUvlYb0kGiuqYmbbwEYYWGrI NkkstYow+srGfGry69cbxGOkVwm5h8Chg5NugoCAgZKR5YGnR0Hrm+hUcQVDxHUIEXUfRNRG 4zoG/Vf91Cbw3p9BsFroL2f/lP9Ad3rpOj9OKvo3VgVBdXusCoTbG7JbgFmRJJW34WTN3Ws/ fqLLJcI9XDjWt+9YL3Ayn9N+9XWi+vKL5eaOE1h3xUX4QPlY2wwfKPJYirw+PGf23fSRVoF8 W4IACAJI7nve3cPFAnXKcUcLYPzww/oTEFexysJ/mkgwDx2dsEkoMGDHEhDVUOWJ5BEJfr5a JNxVPOzcEHmr5FRjDINQSmcWak56o6zmJC/gavK0r8uBeKBkBdx0aSzgKsSLoUTMzbRGUo0S i2xBKbeYqzUn5g5zYm4wmBIxV4nFXKUhMTfomFPMDWqXirkRVH4xl7pZHGJu0I4q5uZvXZ9x 6/oVbp3CunX9Tt66Pv3WjSKhnHbrEqVr3Lpk6/ytG7WkXKLeulG5cmkzt27Er1wKavPculFF 5RJ1s/hu3YhXuUTtg9vapxboljKQU7olqkODeX4e3BgGKFkCdBFvYaIaUHz3e2LHkOUDDt0J /UaF9Qzsxc2o4j1gbfoEHZTgl+MCk/KO/AxYDPSBrDFyYwpxhHQUH8kA4nGiVqyVhikp1IJJ cJnCYuL0StBEHtFEC8cwc6VcrYBTQ+YkrNdDGzuRbIPhop6v6gDmPDyyV4vF8eGJpPvI8h95 OB520k4VIHJiPofzvFz5D6H1M7TIzSKLXLLUs9DI8Cfyz7hdqlngyzZdWYvIUA8nQTr/8uXu ntgOS1yOa9EZCplRlHGWztCMGgyeb8Q2aqRLa1GfnGljB6nPBkwb3aQ+FUwba1OfqqaNkcpN flo1bdQ0YQh/lyeh1N/Hklee3OiVx4SKfe/+3De6752ja685rZwwWTRhsthZp83YqFLNazMM PsDB1vlggy6uQLJHNG6QFRS69iPZc1wTOQ1Klm2Yz4FeBEqOkKKH5giMh89dOVQ/ox5IddOe OYZ5JD8T8VpWwgB7vODwHxAHsSRPSnG4AX9wRfmulwfuUcSuvKWgKX1iEnJNfSICVUefmLSL MfSJ6SpCn7gRfWIGHnLfFxo/Ys+lafwGZVZemsYvUVrLykvT+LVl5R2taeXdjMavg1beaho/ ppW3EItXTlLPTR/oCj8GvtsSoVDLCYWaJBSaWoNSqCGlUNunFDAB1fNR/MhBAiNNQpQkHWnq MWLggP15lAiepWQHyE5ACUeIUWkQfJJEiUOqg0tuuvrMX8ExfJFQidFJcpbLgFTVS61rz6xV zJ3U48mdpFBzJ4mUOhJtafc0pc54POrLA5FSp8t+4N0dn0ipI+IVRbziGg+60XL3CX8T4W+y X/4m/bHyGvxNnNXZrekEUkmxcaugKiX+h12ZM86nAQDLIgD00NWC5TjBxSyYwmtF+IwI3wHh MyL2vbF931nalA3tLZoHJYS3w9PmoKiZqbDppfBL6YZfSmDRnCExwtB9E0QbZq6zpHNCmPgs 5WSxYHp+YGX3P1YwZv8l0Zl0FCk88cwZ1SbJepLt+MTRAoSvaTTXVHWc/nFuuZ4PfyPx7Ew5 iJcFaUoNB3pHkLBuJUjb1nTi9qTLTMEFzGxTwb3JudEU192CQ42KrBQFg6C51qgs1xoQdA8L 1onlZFPerNzdRkXuNjz5PavbY5KGqsFAqZ71k+kFFAyqYOrb1ToKBY9Q8OyGgkdRaip41vEv aC6wlelfkK7SiCNay+4FFXVjLL1Ck6lkybNHyHS5nifsNGqPzrfp2kj7FPNWLKC5JkgJr89M KbaScriThgNfLRGv1IxPaU0aUtfdo8/n7hEX8SZ97VVM+trjxj/s9wCKtNJbyxTbq54ptpfM 1toT7xlsSqHS/HsGvV16z6DqYLfwnkEKR5SkPO4xUx6XXiclm3g5+LpG4mX2KGh9pxIvFyXX qujq1edx9RpSXb2qo/J+RVTe58bK6rjwGYT+plDh/jgzJdcpebEDAZoP5VAql8Plww5h/QAV hHI9gy3qt/6OSb/sHZMuXR+l3yu/P/WeEdmry0KeA0mcSvEMyGafAennngFJLH615z/6tOc/ itBI0eMaVZwM6wLDMueTaVhA68MGaE8ZW9pDN/tMLX/pQ1UoWE3LefPT3M60/XoVN4LdaIpE ZmLSbqRI1JR9SpHYVMjaaCIrIkWiSJEoUiRuIaQ5QGyvK4C4n1Og0ly4tcYsfNu17XUADwvb XjU8nJU++3mBtM/zoJcmDrI4yHtjpNb6vAxFxkadFNeSFDP1nc9CyrC+fqZ/9hlQ2KRXXEpx KTd9KRu0WQywzWJQbLMYc9ksBrRPKRo3yCtdB0VK10ED5udglsJ8uzPm28EumW+rDra95+gH 7ZlxBqm14jfjtIlRyl6DH4jX4AsRAfX2U2YsXoNvyQw0aP41+AHNHNThAI4l4DTTnpmpAI7E zI4LwjHeZOIx1CJn+wHLEzGJNUejHNos8KUfBL70pb0WetMn+++P+2v0X0Rt6ln7aPY1mWZf U0CGYdIbOI4fztGBTJCdCIxkoylZpofgd44EMd0j49nlHq8fsB6vZzhGDrBr1IDuGFnqdxW0 ZvldJYsjSaN5v6shhwyj0VNsVd/uYcXtHjYlwwyFDLM7Msxwl2SYqoNtT4YZti7DDJuXYTaH UZSBWo5ShAwjZJhdlWGGzcswwx2TYdhB6Bf3Nzwx6KgaZwh6XubhiUFP1lGrxakP15IiOrxb ls23X9R6jezYuiutKDu21M0K940e0Jp+qD15TUfUYU7A7/D+beaqbORwdBILrqtLkdl8L6cu pYuscKVQ00GdUNNhkUaFHhs3TOpJhlS9zpCl1ynV0QyLdTSZvlM6GppH0mDf3dQHDDf1AQto FTf1QSfc1Huj7B2nuK70tF5PZrqpp0oru6mnW2fd1ElpGw4slJdVyGBacFMnHfM6sJDa5Q4s IdQKDiy0zeJxYCHt+LzKaH0046aehlzLTZ2AWt9NPX2jqG7q2SrCTX2f3NQHFP6b852r5MHI OxKmSmth47w74e5h4024E3YSG1dxJ1wXG1f18S1ONJ6G3G0f3//+/X/qOf+KOyvu7E7c2b42 XPPS7trrAL+6zmrplZu6C6pSUxGzKnOnIq4N4FsRANbrAMzlIK8DsGCK1wFEpn+R8V1k+hf7 Tt33naUz+Uz/7HlQM/13dtoc1DEzFTbtE5n+Rab/jWb637qBMU58W83PIvMcAOuW5p8DYF0u 2nMABXW38ByARp4DYA6C9hyAxnoOQCN5/VnrxHoOoLxZ+XMAWpgumZp3XwsjBZh9NHx0hOpE qE72QnWiwLbVUp1Uz7vfpBmKkXc/W0Xk3V8v734IZBPWLbZzb1e5qCadrmjUpg5BEk8gNEvO 6z6BMOB7AoH+fvMaHkpKRz2UlA15KIWoVHgobcFDqanHmYBJHAsPJeGhJDyUhIdSmx5KvZ0W 2TuAjYXI3qLI3hsLiV1I7CWxqK1JNA3mxRjx5MUYNJQXY1QxdGfUVF6MkciLsTt5MUa7lBej 6mDby4sxajsvRldwRVnGi5HIeCEyXuxyxotR8xkvRrSMF0WIZkuhyH2FGok82kok8uZQ1PYi kUfVI5FHyWjgETUSebR2JPKIGYlcOgrOjEs1hkDreEMJ66qdxHHFkzhuirEeC8Z6dxjr8S4x 1lUH2x5jPW6bsQ5HUIz+oFa5qN9rKgXm5jBSGfs+Fuy7YN93mX0fN8++jyuw7+P22ffxVtj3 zaGo7bHv4+rs+zjJv46p7Pt4bfZ9XMw7Z/reVLJnReYhdSqV1L2CfEbVr4oiV7wrSgVTW7GE AXu5IRGjy7Fn24leq7ImfCJGuFtJtp0Jk1PG4GtPlTGYTdccLZ+QUQAiEDLYNVhUORxqi1JG OIQm81pvErEMhsWPI5D5YElBN/KIJWT3KHXR+ZLQJfuL/gTLdC79xbHhb/XEWZ2dL1ZPtiWd e54zs3Q0rZOC1zXyzOfTP3//gxk9Lsq6UFZGWGqfCgoBqg2TSqjqn19ecrS9nv6Oe9Klv8c9 6aQnPd3TsqgnFoGsv7eEkNYe5bs0Yjq/jChY7SEeUsKXzxcL6d7X5/OTRBRnPmCBcnI5W1LP J2db7rMRw6sY5s7blhFQzdm2YO0qRcNXminPuiHnOS+EVjFOnrf5u0wETROXhBYrXBlC0xHE CFjk4TcJ9Bo9+NsF2A3d4JgXLLznqejsJjp+TXuIFy3wtI1C6c1nC6T3Qia+MIO+zLdzFfRu fQxYU9OxM3TFWzjAlMotBNBJJp+Hxc/pt8LP3C+gQYM6T6CFzVlqsVR5rL0KFGOGbj4hJ1Dv ceUbzk87dAI2DUmHM0k0R/DrlKq7UrK7M8rt1yi9XXIdb9+KHq8jPofX8h1S0QqOC/WgiXoH wb/nqA1ZZukIKRiNaJV5tK99vG298l6DigfBjzluxeo3/XsioYiH8JbAJXxEY8Drh3JeWjZS SdI2Pq/n6+dvar+9rVf6fHufi20c0kMbhw3kXh/SAxvxTmU7Sg7pjULU17OFBagohvn17uqM rhuWLm/KbNpZ5XFoJzh6oxwfJPZ7EmqpUbAEmexRD//bgsVemHMfNsx/kz1WEd7Az4P6rhq8 3HkY6M5gEnPr20HCnjSRnMXs14Uz1RcHMxsfbVQD2q5gy4Cb+cyoi/TmjuvdACuQBE306V8s YBB8mPoEB8rIPaWvav1hX/nbQZQVZyKNZF0e94bqm/F8rL1RZHX2ZjSTx2/MqalOx3NZMQ31 ALq8x4FOqIUi0WN407VUai01U0uj1tLeHoQPiGTGrp32ZW2kDP/2LyR2Cf5Sgn8e4EBsy8wv B4nQZi2H9reDWRTvnSkbnvZGfXWg0ro7ZKopSLcUqYMUUMUKUsQtN6xfnSV/B4M+Sc2AKnNt d3pUuWdXxoee8A0RQKKd9OYdjhsaqD19Vp4NQF5bMV0bmsjMUGf1zs7OguwbMx3KoMHC1IHg ARGOCYcBWMl1YJiIKiMa470AC/qEIsWclTszvdOQcfGd5RJxo38Sf1r6gzfiVDtdON821gc6 n4NeD/89HJC/leC33O+pSk/5k6LAN01VZE37ExBVDT5J8sZGlPizAgrqStKfnqzZo24uCuoB Hd7GgLb75z+P/uVY+tfPS9O+vjy/nUjkYqqnvdNn6QhHJ/cxAyEpw4kynmgq1D74c7BY/2lP 1cnbR+fJfBt8eeu5s7fI2wChk7efbz/cILAPdx+uHz7c/PqgPvTiUhJo7r3FXcZc9jdkqPX8 6YsNTM+DPsGh12fQ04mErI9ExMVOEBMWq5Wug/1AkLqAp7YihX4jWPhAgz09Pa3iyBHK4Fe3 PwYS4fqPjtOOO+MhrK1hoNhsKHiyQIBBCiFvtURR5VBt+iItXcd3Zs4iBhgOLGDHEW02uOak JuaEJhRKSqGTSoi3Se2I2ZfIBhFkTaSLZA3c///BxG2qz74/xF+TNaT3l+8lVG7aBr3ue9P9 DlTkRYKKvdP+qSpPpKN7cwkUAyRCSVVO0AEcEkVaUU+/JXqi1uXuCWic949FFsARYpvO6AWI KvqubnuL1QyJdXHhQTCkB4Rn/NXyAYdZ4x+INB5GPNRhXeEqLYaUy1opkWk01HXNTIpM09Hw jTxXlOHQMA1lOqopm+VFEeW0P+jLqpYQReSakg90JoSY9oWEro+vWIhRjcFYm9FuI9ydS93X saftP98of8xdrFA2cpczrHVBv7sfg3YX0cUNG0ykNNzF7Fr3/E+OMZG+3H39gD580p8vkSfv JSCuR6R3gm93pm58thcwzo/n1/e42j1Og3x5gy9PlGsZA3AAOTkuVlKS6mxUkZlIBmXMtP4s jTLGW0AZo8E4gTK0jaEM1m7nso8z6lFSjzNqcuYd31xr+oMerPmfFK1N1+9+18eXwk3MTUug qtGMSfHaSyS/bjr3ojmcZDO8v9JplxEm+Q8Gy5ilSimyE7cCcuI4/u3vk4n0t9/u/uva/qp9 +eicrU0lpvPRKE0lRlugEkgNvg3Gkrr0hSQirFRCH8Jqa6D3ppqWk4VowlmaEK9E1xFu18fH JgjRXqWpQbMa39DJ5cFdLcyHFX5B0fJxNJpyqp6OevKpomj9PomegxsjHSEl9zfTfW/5n91P qPnxJPKVuQMoXxHCOWI1vzn/9EH6txyMf5POb2+vrz7cQ8tIUYKUS/9FggCkfyXK8y/+Av65 soybFZbq/1X6lvg3rB8gqdnKdU179hJ9sIGpvjVJdjzKt/OV/0i+XxkLjJBQskHyAb2ugJC1 717NP1n2tWnTCvRnWsG5/cL4fO+by8T3K9uPKl4jVc/9/UfyKyUNkE935nJhzbCr0xUyN/zQ F6Tg3pl9n67QYK7smfMUTTb/PZ7wl8CHgPxwnEXqw+X0ApkBPrqmmfpwj/QxwYfLm1n209Xl de4byDjRv+9xNO69r8++R58en/6fGW7Yo26h3bkLPOMSc7+c3gZ6s/hYkGFFXgO3MAloHBRc 3j/BCiJdozUjZC2YGsB5fsGT+evKxOZxslbLe9NDgBfON+lYOmZfBC15Ec5to+pN0HI3IQQi roK4Ct29CnEgtdIbwD/lMZzr3qkqHc2Aal19sx3XvDrvF14HJgxyJfKAkldCX/hED5qYMFDJ 8iEqZIgfnvWZv+YIlcQIU3CqDFA97Z8q2qnWh/GYrg/8KhxhMxxOskYvVQN3SKsmh4H1VwYg Bsz/fkSvH1w4T0sHhUcXTDWGQWbGAYiKn2COvuug6xd9+vAMsmxwMqOPH4HnX7n4jCEG5f7F 9vVn+JlZHHUcodeqU4GmKczKOwOBYQWG7QCGDU/xUDr6hmx6xBCHzgnH0R8GR5/WMnnoM6I3 DCcjH8OX5U8DFsf+RkCQD+cznNL5Gpk9E58/6tYCLnX84VdXn6Gx4S/ZmQFWC62fV/YcSUVo KSmITQUea2Vb/1iZn7AJj1ZFRcDQQzE+hhKYXWk1AUv65sJcPgIeIHeYUkuBZXdmvunf+0iD Xr7kSrjk2VbJ5UbOBbe65/10XCM6RO7L0ifHEBbsN8vzHfclu1bKQDqaWpnBJMtjcYxjqBnh S6BCgQp3ARUqgAamAN3UbY5DHspVyRbJQ/6oe3Ac4CJif/mg+1/hjC/M377ekp+/WYYRnQti oAuOhYUSo8drGtvawjNCDHXhL+QAY147zvfVMlyxGwd4nlm0i5brv6BW4Ydry4ZdwqczsSt4 wb7eXSU+3eF0+B/QeMK2dyZyDz/3YEVi3hPma95FLwLEu/n88vujc/50FZ0EmMQCqXijvUX4 2wS2ydXdl/j7Oc5Ic+18C3LTRBuO3iUIlwWj689z6BeuCsFwd4Ckg8t9e+vATXr5TfceL2CP XKSLSpV8RYs2+x5hAzzce/1H+szc/XyKdGqfdORpGJ6lG+eW0ITww525cHRAsuGXL7EvB8Kt s/znG+fXxSqYzldMg4KK2cOpJAUf9FABBU2PpCN79QRDnzEx+TAhnBB0BfVodGyQqPjZNUwG vH6iWvmt6WflGjZtuD+/v/5kzoAzsLwntBM/AJk7LtK3Rz9iJAEoFP5rk8KZTUgI4v31KdBi gxxpw/RmrrX0I7xCBKaP1sJM/oa7kjyCwb8XC+dn+G/3mxc3OvdhDacr3/yMIXuZr19eluFB Qmj56vLO/Ola4QlGn/6XHMbEhzsgm8/BTX5P/H6C4x8obYNflqcnhnVp+RckMg0tvBfSn9li FaKRa+vJChEk3Kx4DvDjGpDIIsQ2BgC4dkJsQX7f6iGWTthtwm4+Z8S54CvgpYUezCxkTDBD cg/C60fMkqUL0V0NvlhGPL7bxeqbZSf/nRp+iHdSBDT1I71lwcdUF+hbGuY/VpYb4QDkixzd X2TYurz/EP+4/T3AALq3+A296xL9Apy7eIp/3psIySxDamQCK2P5L+Ev4nUV/AJsg/crJPKu /18RZk1QluBDGIlF8AuwOIm2X67vL84vYgE/nmS2JN5jVMJqEX8Hmp4uspaPpnu/is43+nZ3 fYHCLpMfUo3udNtIfYBrDTLCBY5sij5e/naru/pTXPErdl6/wxc/pHFwBhF3G9Ek6HbpRNg4 YIZjEMDKxAQQaCLQgkvTN8NtxvQP8Nh781H/YcX0LyKQQM2QAx6MLvx9fnGNj7KR+PDeiq4v sE7ncGlcP10p/EqrmWSswm8YSXxEKcaCgi8f7wnejD4kmVxomOV7CUdFmG3CLpg+3L/v2Uq6 PTOjOn9dwQ6gJ5BiTg/7pcanJvwSqWRCzBcS88/L7JfblfvNzNZaGPkvCKOGONKw/NRlhcnA /YTd8iO8m2QQ43nCT8tO/gyeXEp+slJcN3zwgcNz0UoEX35FndzqIZm4vEYJDu9DriNkSi5B pl1EHFv4FSdG+HyR/kj+Pr+kff08z34PASd4spjbTfxGo4x5IfQFsVmLCGfgT+HTRxfvI1Sa X0XggFJUC35nThx8AdYoZIOyFy/B72DxJ/f1znxyQuCECyJ8TvJLZkzkY3QVATciFIkPSYZ1 6iU5p0KeR0vWLGB6UkpoDnVJTt8s2B7B9gi2R7A9gu0RbI9gewTb0yjbg9xAtMHpcDwYqupI QbZlzNq4Bs34oUhHhuWhIKKV5T2aBuI0ONSfAUtDb5ozAQVemVJg/wkdJyVksA0cUgG3YwOA FBgCLm8IZwPQL0hsM7pC+sICPsAgdDcAYRD1LwDwXRNTrtyoUEemeb7wnODskuNPFNXvI84C E7ibYDuDwIeQ8szn1nMSA4clGNchzDS7jDSaSYQVfb4zI54gut+X6Pg9BQc8c9wR/OVPg3BJ idVxIvVlMIvkCb5x/Mfo8pGzgqeXYYkplvzyPWeZ7hs01qNhxolDSKTbJJlviD8KjvxNYuyM KU5dHX3DTxuHjs/IKxrvNXr42JqTFjjTVlx0kgDszB5wGimcrgZor0HOK87Omq19fCIlvKel w+hcXWSBYY4WYOEnXQ8TjZh1Zja7eZ4zLaqbZtrLoQYsMLMi1cObWTty82bPNIFCiivFpubi 7i7ub5gVUhiquNZLorvM2QHGfCKRLMUTqelMFvH1gFPfQBp7LUxjj/OAjdhJ7PvauNfPJ7HX KAm+SlN+JcpxgrZRUX42/vRsSvFbLZvJ7f6O7uOO3NnfpfqN8n7zZCJP1WEcofaSdI9SE2On 6E5mLNdtx355claeFKXG68Sh0Yblh6beAz+FJ4Q8fHOIH7jZzDs38asvqRklXnwJH3iRyx94 QZFDmAjjxQgJKYILA8cHN/3kipw5NygUgdnefLb808LTvqWXYgqOO+dDMQo9f2V7x7zKKzGj Oo/E4OySoypvxJAWiTXOpdBkZtAsTYaZgE3JlJjuGdO/xt6HiQirwkFYKW+er0FYlWqHR+E+ POq4OPHpph5N2W4M1SbzLSTXKfkASCBZ8L1NQqlcDpfvFZGwfvBkSCjwsFILt815KBUfB2nv 6gzUXvndwfwFEStKXgbJ1CZvgyTMJInY0Pi05mCa/3z679//h/kaRaaYP2j1hHlnS6pzBrKe VLywWwPCH+Z6ksIQpauY3HUinRL3UDhLf8bCZmAJQbacgz//+QluoLVcmNIPfbEyvbhO7FUI tRw7qHCCjug3/1HqpTr69JngkZLRHeYa4df+EiPK9MxUn5QtcV6Vko4Xr6VMSUArqkOMXrup +EiYy4rqxFu1dRVK10OoxfjE+MT4CocgMoqIjCIio8jruO6VM4oI1k+wfgzWr0jHUE/f2ygw qvJYq6axyLx1pHVTZVHyyhH9kaOqbxwVaInLXzgqVOomSkPda6DUpT1co67z2rba0de2Vcaj TGtMUenoFJX8ezgj+hM9owpP9KiMJ3pG9Cd68NgNc47qTiSPGEfmq0ViRUjm62hBcjpxhkr8 n1bie4hRNIX2jBVBX0DAMZmdD8zZKHgzSTlArzj14Ae1VDryA59HhTCgKHh8dhw3Qtffslcm vTV6X1E5+OWXdOlFtJOANX6RyFJHOydJyNtnIqGllqSjwAUR+SW5sIo2zjCOvBr8FTDvASi4 sJIEpNRHw4O9+B1ICE4nP5BkZdIfTvoDzA8fHOQG83nlAzASFH5HdgBGJf0SzuFEkoJ3puCf pFvpCnhK5xuK7EcWUycBIXo+UZJPwif4cI4COA5SuuPwGStSDCsNvIVtODYMHbiz7DBDT0Tp rytzZWJL7QfAdy95qEG9sFdysB+/hwBQTGjRZlHruzi610u3u/l6fR3fUc9cwEYcINStAMRJ UR9rOWmUQAYewdO/mYRzoNqWzPPz4MIwQCGb7M94CxPVgOK73xM7ht48gUN3Qr9RYT0Du50x qngP2GI6QQcl+OW4xNSPfgYsBnYJwGtMffpMCZ8+UxhPn8nhjuYeMyOXKSwmCJ6giTyeiRaO 8d40BgEDQZ2EeI3Y7GF/ga14CD0RQieBWeQkkCz1LLSu+BP5Z9wu1eyQ9EH884KeYGWk8y9f 7u4ncHX/vYzc1EK7FKyrKFm0mySuapp/YCNjtRAZqzEyroSGVXzr5J1Gw2qMhtW9RsPhZm0S DYd9cNsllSEvHlbTeJhczjdYHMzdo+dnxgXT6d8dlgnyKYmG0BwM+wE+5M2ji3++GieC3Nx/ Z1lwRQlfSf7p+TaUbLT+u64BFCsnVq79lWsvT39+Fe+zzwpkZrHNsdJeCMgMJ/EcQGmIQiWt aU4/M6brZ8YV9DMKQz8z7qJ+ZkwVCTR9ILP1M8nS6vqZVOucfgaXcgsGymYFAzyYNvQzuGNu wQDX5hAMAqhVBAPKZnEJBrgdp2BA6aMh/UwKcj39DAZVQz+TulF0/UymitDP7LF+ZkzVzyhl yJiin0mWVtHPpNrl9DM7h4Y3op/pIhqupJ9ZEw1X1c/0+2NePCz0M0I/s9MlQiIWugSxcru7 ckIL0z0tTLJt+L43Sk/xgHM92YiOXd6kQgX1BXbRQlHYwAeuP5zBqIJjXh0dUwUnpvKqGn9V dSNQK1YVL72Ll97FS+9bGF/pS++6yvFgZhNOzHVwZUpRJJxVhLPKbjmrjLmdBndZGZKKhUm8 1c4ZVk9tURLQRW2zRojW5uGUx33RVywbBMZY1/a1IKKkmo6o01KnUCwIlUxrK7eXdCSzOzxz zG/bHq9M1WnuGEIVarwiNV75hu+Wfq8snURiiqUZJTLFH4N2YXEq4UQKbvQw40T6cvf1A/qQ erMTuZs58YOME+nj+fU9rhYmEMfKqOjAYQDRa45h9XUzWMy0/iytghtvQQU3GowTKjhtOxks ErvCjZ65kXI9VNxA60qCTZE4syt8SnfHx05rkdw0ofoTqj+h+ttanJryOpR/s/wTEhScmK1C xY65pyi4Od1GG7LMVLlpnjBm377W6fWUCOWLUFu1v3LdxID5Fc6Pk7rWXZ5O6VCFgmiPFESU Hd4tjZAQZYQos+OijKJoo9cgyYinAar5Laz5NED7MsPrKRE8vpCOumTU32WsWmTIp82rxIq/ +0tRaWpCKtsjqazsgR0hoQkJTUhoWzQ2ycorEdA+/zDdhf6CsA5KmLF0nR8n1cnqGlCo1HYN ONxEuIuwWTLhOrtysv5+ti9XdblESC5C5mtf5hOIuro8udaaUcVMsfpribA1NkBItt2WbBeG NX+Y6uhZJ/S07OF6u52DA/1NJPIS0kQSPpVCzBVi7ubE3PG6qf+x9urJNKzoISmSqCT1PctR 0xlthuj7mf7ZZ0B5on8OWfiaSVJKs6LUC7EIYzl0edwbqslYjpk8fmNOTXU6nsuKaajpdC0K Jgf5XDfpWiq1lpqppVFraW9ZQSDaaV/WRsowEQSi1AwC0UQelu6IHt0dX2keFvTMqGAcBOMg GIck48BpidpXm5NI9CwSPXc70XNZbqM9SfS8l5kXRG4jUSJyGwnDjjCJteMGuS90ROQ2ErmN XqMpSQhvQnjbbeGtNDvFnohvs64GM4vsFK+hRLDPQvBof+W6iQFFdgrB4neVxee3Pu15dgoh yghRptuiTGl2ij2RZPYmeFhkpxAlQjoS0lEnVm5vsKrITsFrexExPHsulb2u7BRCQhMSWrcl tLLsFPsjoImw2/ZDekV2ik6XCMlFyHzty3wCUYvsFN1ffZGd4rVItkLKE1Lejkt5JckZ2ELe riVnEHdV3NXt39VZtLfoAh6Nj/NfJtI3x8dkyDLOZKB5hvOAGAXXXC4kF32TldRXNfoqjrE4 xrtHcpSeMtJ2QrWYpTB/NKNyBJYUM/2uecLnF1lQm8pFF9Tn5qu3AYPlFF+0Oifl69e+umzf SoQSS6j/2l+53Uea+d0onBN1i/ZlFapMS6jDWlKHyXWStRbvat2krJWG1iw0kehxNxI9Yhnj 2ad3NxiqKq07kR2yK7S/u+MrzQ6py71OYzChDRVqpNa1oaOcNnTEow1VqdpQVSQ5FUlOdzA7 erk2tCvPgBVqQ0NaIq64uOLiimeuuNzbhytez+Ch/DFzPMvm1lsV1adrropa8OuutgSFafoo XKcTnrVs31ywbyVCiS/MH+2v3P6gUIoZpHhudEPInq1HtekJk8iumkSK9nWrRpGZcE4TWsXd 1yo265xWKqu9Aue0vSGsQlZ7dSVC4hCyWvsrtz8oVMhqQlZ7HbKa8Oraca+uwelI1UZQRXh1 dZhMdnd85V5dQ443f4VXl9C/vCr9y5bPsPD3EP4eG3m3WrgtiWO848e4UbcldVSSHOQVeC2p f4BQD0LbtyVIKo7Nq73gaEZXYnA05NdltAKMqSznWcqTCqvevqp530qEAliozttfudeBcylq da5507Xrr2jJ1pq6UMDvggKe5izFsb0ikFyYHFo0OQxUbTQQJocusxfdHd/+B5ILPZfQc21a XSs8l4XlbBctZ416Lpeqa3fCcZkRRy5uuLjhr/6GK9povPs3vJ5BRvvDWZo2AsSr5CpuQddv FbfhV21tEQ7T7lKyYid869q+dWLfSoTNQFhb2l+5/UOoFMtK2RzpRpU9XZmq0xS2k121nRTv rDCbCLNJi2aTkdwfjIXZpMt8QnfHt/9mE6GNEtookX9XWP+E9W/TyTnLlKo74eUuzCaCUO0R oWrUbNIfj3qv3WzS+8O2PF41FrMyXYPFrM6vvNo4CKZ1hL0wJ6Ur174NYd9KhGZf2ETaX7nd xpYU+0fBfOimjz1YgApTEhaOXbBwCOWFUF4I5UVF0WYnlBdCtBGizd6XCAZdiDbtr9xuY0sh 2gjRZh9FG5rzFnNThd+W8Ntq029rPFCE31anCX53xyf8toQ5XJjD1/LbCk9sSA0R7Ud1TNdG KOvy5qyEbYChIP3Qi2Q+Q+/e+hdjMOrAPRO6WaGbFWklBLkQ5GLTQec99VW/hwfi2aXuw7nw TPTMz6MxZauMiurm2eyi2nyc9xYgUMWjwjU5KVuz9nXxoqQRG4YxOzOf9aflwjyBf86cp+x9 yFXIX4JcFb5zS2+W0TBSxpcXkDs6iZIh5vW6n3QbEK97UjqforpUXQCzNrd6oBhCXi9cMBdh DBJmtJZXbqc5gswuFM8lvzF7MHf+6Qjj2S4Yz6hce+eoegMcTcHkTkqZhKRpY3dZBR4IT9zM Bt+aEAsQE+q7A8AaD/B/lm3BMb2C/1ro2CNNxG+X7yUjwC/inIpz2u45pVKJLq8xzwplplNp +p27fBVEP7GNYhvFNra/jcgNC/Gqnq+7/mr54NhQEf9ADMBhrsVhyC6g1FyT8go/dddGkN5I tiNdvn+4+Hzz8epXaW4tTGnurGxDsmzJsFxz5jvui3T61phOpCP1+PTgw/MSPkpLx3GlpenO 0TzsGWrlSt5qPreeab2fprsPuRdaVSidmvYPXPMIdQydegtY1IXl+aZtug/6zLd+6L55NDye SBjwkwP8kePGHQQf0BQNy9OnC9P4v4GFe+WaYXE8Dt+RTBtVyznNFclyW/WZQ0c7tQ5HqF3e p4tYF89UaW6cKT3p/OLiw+0Xae46T9LV7ZmiDk9l+J8y6WvjviIdpb4hAMdU62M/sB5hlzfy 75W7eFjqrmc+wAipg1FhMLiqp3uLh6mFDnTmQ/ATLYNFeNyHwHpGSmzz50NsLZUU+J8cW6bQ ZieKgzGS3w++80Dsj18ubqX0uKhT7K0zRaWjU1SEj6Xwscz4WI7HY7UnfCy7rA3u7vjKfSxn M+FjKZxmhNOMyI0nXBj3zYWx2dx4Zb5fOxFezsiNp/RyVxw+pe64mqyAZk9qAMGafUenDYnS lr2EewniAK7Pu7K9QWJdU40CmRATTsAkWC7Jztt68ksmzmITCzQyOdaFWZfKzRSrh+ormDan UmevSalKPblZ769uLgE+dsNnNjmEW+I/OiDwq6ODYHsnEggmHhyxM61a+zNYE6RUIUACSY/Z dL3Bzh7P7q8+3V5/kDxvDkQvHrMmkX+UgPCdkhos7lENmUdtbVYUI9AJQVBnCrqBZ+MhaYtv znyx8h5VkC570vTFNz00WM+An6m1uvtw//X6S6o16a5TGEVRhuUoRUEohaDmvJufBX+mRfij cxraNoyV93cXv9G0oUAAZWAK4D9yQGGTeDlYVlRhbi18+DdQtVjBcvbLcW4/Pv0RInOYJtrL me8uvPy2MSgBpe1EcuBIHSqn2ungVDntof9XZQ3+GsP/K4fSke0A32r5FrCC+QFZxT1lPk/p n8M5wT4lxmXDyXRnsDfodsEtRuuk+74LRb9I/546wHj9sZKXtgnezFmaUNUwgRMEeGSxzw4z i32YB4m6O0OdBUg1vCVIG24H0jSlx+OwPlSyDHoNmGtUY4KmLc11a4H45Mv3Dzefv3z8/PXm ciLdOAShITzw3Xx5i3TewMNabqDoP3qjyePR+LgQYSoFCFOpiDFVjPMUWcGtNZUbZ8KSfjhH i5pAnTEYyUaraZleJ/Fon4VFkz8Q1DmadLCTaGa2A/M5ul/NZsAHpyYwWzgeDGoi4fg7NLxg qTys+EdjRVXMbBvYCAPLM9kmiaVWEUZf2ZhNTH79eoNIfHqVkP8VHDo46SaILhgoGVkeeHoU tL6J0QJXMETglNAB7YMOqNHAqUF/D57jrRU39RnkmoX+cvZP+Q90p5eu8+OkogNxVRBUv+Kq QLjdjbsFmBWqVXkbTtbcvfYDlLpcIuIvRORK+5ErAifzRcVUXydqsIxYbu5AnHVXXMTnlI+1 3eR2geuU58y+mz7SHJBvSxDyQMjIfc/7TLlYaE55vwUm1eUPP6w/AZEUqyX8p4kEY9XRKZqE QgH2zgJxDFWeSB6R0uerRcLny8MeQpHLV079xbC5pPRioXakN8pqR/JCrNbry2ZoPlOyQmy6 NBZiFeIKVCLKZlojyUWJxbKgtA078DAnygaDKRFllViUVRoSZYOOOUXZoHapKBtB5RdlqZvF IcoG7aiibP7W9Rm3rl/h1imsW9fv5K3rU2/dcDiU2bcuWVr91qVa524dLm1DgUS7dXgwbdw6 3DH3rcO1OW5dALXKraNsFtetw+24FEjUPrgtemqB/igDOaU/ovoMmOfnwY1hgJIlQBfxFiaq AVV3vyd2DFk34NCd0G9UWM/AoRCMKt4D1phP0EEJfjkuMCLvyM+AjUAfyBojB44QR0hH8ZEM IB4nasWaZ5iSQi2YBJcpLCae4wRN5BFNtHAMU1bKyQS4MWQywro7tLETyTYYcR75qg5gzsMj e7VYHB+eSLqPjOuRm/BhJ21RASJHCkvken+wXPkPoYUztLrNIqtbstSz0MjwJ/LPuF2qWcBB TlfWwgh7gpMgnX/5cndP7IMlfvu16AyFzCjKOEtnaIYLOs+XuAg5w0W6tBb1yZkvdpD6bMB8 0U3qU8F8sTb1qez7x0196NYLBjbdEhlSy8mQmiRDmlqDDqkhHVLbp0MwAdXzkcX4IIGRJiFK ko409Rhhd+DFHyWCZykO99kJKOEIMSoNzM1JlDikMt656eozfwXH8EVCJUZhtCAumy0sOICx rPH17uoMQc6H+IQJcAs80cgE4uiv0HZ/9KZ/XIfLqLo4Pb7FSdjHw+3rI2RAxLKjHv63BWAX 5tw/foWMRy78s6oGUbykIKL82ovyG49HfXkgovy6bDnr7vhElJ/w8BIeXpU9vCrmZtB4cjMM qLkZinjb6v6uWkV/V62pSCRNRCLtTiSStkuRSFUH214kktZ6JJJWFolUEa/1MF7rF+O1ERWv ZRFVn/Yphbt6edzVL8JdPW7cpY4LcVdvU7hrf9jw5Dolb2IgIPPhCErlcrh81zmsH9zdUG5n XNReexe1n5pykyGDmyP9ZSGDmggZFCGDuxwyqDUfMqjtVcig1oWQQa2JkME22RCl3yvnQ+rh 0b1iOgg+TFB3gQc3iwd7OTyYWPxq+K9Hw39F7FgRdqmiZqwLDD+V+WQalu6bYQO0p4wt7aGb faaWozpVoXCHWs4e2iW+b3shzlr1EGctGWasUUOctbVDnLXiEOdM30UhziI/mMgP9urzg5WF OO9UerAihX1F9Vqfw2wwkLnUa+V0ol+RTvSbUq/1hXqNS73W35B6rRDuJtRr/db14P3m1Wub uz5lYmFfiIVCLGxTLOw3Jxb2K4iF/SbFwrrAWhULe6/hBYcIdhRxOGBEIg6aiP8ddDIScUCL BRlNhzo7/jdVWjkWJN06G4lISrcu540mspaPBSGDaSESkXTMGwtCapfHgoRQK8SC0DaLQ84L 2vHFgtD6aCYWJA25ViQiAbV+CEj6RlFDQLJVRCTi3gQE6CIScUDVL1Lj4JMXIR+JmCqtRX3y kYi7R302EYnYSepTJRJxXepTVcs4Gsm85KdVLSNehPUTJgpXmSeRQvB1leQTeHX5AdRiCPkE YAVzEY+/in0X+945ipfZS64N7OgkuF6fFqkTy8daLXXiznqCxlGc1VxBw8gfHD+fj/Tp4gok e0TjBilCoetFkj3HNZFnj2TZhvkcaEyg5AipgGjexXj43JVDxTTqgVQ37ZljmEfyMxG8ZSV8 SRsvOPwHBEUs45NSbAjmj2wq3/V1YneFakGoFnZDtdAfK69BteCszm5NJ8AHxdxKQVVKYml2 Zc4E0g0AWBYBoL+JULAcJ7iYBVMoKIQSQAiDQgkg9r2xfd9Z2pR9M6JoHpS3ITo8bQ6KmpkK m14KRUM3FA2BuXqGxAiQjE0QbZgRsUlpM/QDTEnNC6Yoj90I/rGCMfsvic6koygvHJ45o9ok WU+yHZ9IziB8TaO5pqpjJ+K55Xo+/I3EszPlIF4WlFDOcKB3BAmLsYEXY8PicEoHUnABM9tU cG9yepHiulvQkKjIGaJgEDRdicrSlYCge1iwTiytSXmzcv2JWqg/UbH+pKgPoUkRmhShSaHl EqmpSameL7pJZ0FGvuhslUacBVtOF11RCcUS4JsMXUD4mKRSXc+GMI3aE39+G6l5YiaGBTTX BDnh6zNTil0dORTx4cBXS8SUdEIbXzdD9YAvQzUteCF8w6tS8ILS0eAFpcmg0AEOCh0UB4X2 uIJCB7RPqai2QT6qbVAU1TbgRvQl+SIHIl/k7uSLHOxSvsiqg20vX+SgvTjZQWqt+ONk28Qo ykAtRykiDZ1IQ7ercbaD5tPQDZpIQ9cJnSAw2TwqQVSNUyP4JqMSVLlUgsk6ajW14WCtGOQO 75Zl8+0XtV4jO7buSivKji31EkYPoqWZWujElT/eyrJtIki+J68ZJT/s52PaOrt/m7kqGzkc ncSCvKlEM2yvIrP53qJUonI+k2ikPojyEAwZ+QmGTbyUPOxkfoLhTucnaOohltFEprxVKfIT iPwEIj9B4/kJAsT2uuL1B/0s3uV+OXhnTMEdwMbCFNyiKXhtn/qkmJFEN6nvfHZIho3zM/2z z4Dy37//T1WEJu6suLM7eGf7WlEm330KhPnVdVZLj8vrllWV6nXLqsztdVsbwLciAKxAGOZy kEAYFkwRCCOCWkRwgwhqEfvOCmrZTTqTD2phz4Ma1NLZaXNQx8xU2LRPBLWIoJaNBrVs3XjT UOQL65bmI19Yl4sW+VJQdwuRLxqJfGEOghb5orEiXzQSwsJaJ1bkS3mz8sgXjfbyeJt+X8xn qGJTXu7ppwHr6SfGA1QD/KLTgP4AVelzUUFr1nNRyeLIvTd4LooZYqSFIUbMzRQhRkJHJXRU FCufPBIhRiLEiOG1GQLZhBmR7aHaVXa1Sc8hGrWpQ5BEtFe3or2GfNFeDYZCDXlCoQYNhUIN KzKww6ZCoYYiFGp3QqGGuxQKVXWw7YVCDVsPhRo2Hwq1OYxSFgo1FKFQIhRql0Ohhs2HQg1F KFQFVr6qHlmrpkce7lso1FYEqfVWrWZ8Tn+0ZnzOWBPxOZs4HDxXEzoOfJKJ3zQaHTlEINWV KpaTu9jvKdlthKVgAzefLf90Uwe4idifYYXYH6WDvB/THJL8gaDO0ZwDO5eElYUwtaN7Yv85 5jCKDIuMIoGBw8DazmyTxErnTDNDlmmm1MwyLDazZPpOmVnE+7mv+P3cwUgZycz4tFRpZctV unU2Po2UtpAcT6EkxyODaSE+jXTMa7kitcstVyHUCpYr2mbxWK5IOz7LFa2PZuLT0pBrxacR UOvbq9I3imqvylYR8Wn7HJ9W4T3Z5MHI+xGkSmth47wfwe5h4034EXQSG1fxI1gXG1f1I+iN ebFxU24ETaJlhhtBtopwIyhxIyhRbTZvZhVJNTeQVHPEYUkeKg1ZkkcVZf9RU5bkkbAk744l ebRLluSqg23Pkjxq3ZI8at6SvDmMUmZJHglLsrAk77IledS8JXlEsyQXoaMtWTz6OUtNarhV kp11CUVtz+Axqm7wGCWNDiOqwWO0tsFjVGzwyPSdMnhsxhrAzFa3O9YAdd4z2Nnq0qVV9U+Z 1hlrQFDaQhyLko9jCQazfWtA0DGn/imoXap/iqDy65+om8WhfwracemfqH00Yg3IQK5jDQhA ra12ytwomtopV0VYA16fNYCWrS51MHLWgHRpLWycswbsIDbegDWgm9i4gjVgbWzcqDUgA7kR a0CjaJluDchVEdaAHbUGGLr5hD57jyvfcH7a4bGACwwXWSJkAH6dUu0Gala4G+XEvVFa2pPr 7H/FNRitbxBRstMY5yY2bm9iY76JlcutfSwI9grl1mTFg+DHHLciEqN0hMwpRnSCeOTlHgbX L+83qHgQ/JjjVqx+078nEqLvoQZBlvxHNAa8hMiZ2bKxqct/k20VHXnsC+u7auCmehgovGEo c+vbQULBM5GcxezXhTPVFwczG48c1YC2K9gQQL6fGXWRuc1xvRv9yUyCJma4L8CzAEl+Wk4w 1Zd7Sl/V+sO+8reDKN3LRBrJujzuDdU34/lYe6PI6uzNaCaP35hTU52O57JiGuoBdHmPuTbU QpHoxrx0LZVaS83U0qi1tLcHoVdzZuzaaV/WRsrwb/9CGDH4Swn+eYADXy0zvxwkIpa1HNrf DmZRfG2mbHjaG/XVgUrr7pBpsyLdUgxUpIBqjSJF3Iaj9auzjErBoE9SM6BmZ9ru9KgZmXZl fMhfPUQAiXbSm3fYJWKoDPu98uhreW0Fbm1oIhK+zuqdnZ0FcRgzHcqgwcLUgbEEEhsTDgOw kuvAMBHNRdTGewHu6Qmxvc7KnZneaUiXfGe5RIzUn8Qf8Uf8EX/EH/FH/BF/xB/xR/wRf8Qf 8Uf8EX/EH/FH/Gnrz/8He2hzYQBwCAA= --------------080605090300070207070602--

1 0

(ITS#5470) Sporadic failures with RE24
by michael＠stroeder.com 15 Apr '08

15 Apr '08

Full_Name: Michael Ströder Version: RE24 OS: OpenSUSE Linux 10.3 URL: Submission from: (NULL) (84.163.88.4) HI! I already reported different test scripts failing every now and then. I ran 'make test' a couple of times and finally it failed once in test050 (see below). Running test050 again succeeds. I've also attached the debug logs. Ciao, Michael. >>>>> Starting test050-syncrepl-multimaster ... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... ldapadd failed for consumer database (32)! >>>>> ./scripts/test050-syncrepl-multimaster failed (exit 32) make[2]: *** [hdb-yes] Error 32 make[2]: Leaving directory `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2 --------------------------- end of test.out ---------------------------- ldap_add: No such object (32) matched DN: ou=People,dc=example,dc=com adding new entry "cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com"

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: Updated: (gdb) print *si $4 = {si_be = 0xde8540, si_re = 0xde9960, si_rid = 100, si_bindconf = {sb_uri = {bv_len = 30, bv_val = 0xde1aa0 "ldap://neo-ldap-1.tamu.edu:389"}, sb_tls = 2, sb_method = 128, sb_binddn = {bv_len = 33, bv_val = 0xdd2d98 "uid=zmreplica,cn=admins,cn=zimbra"}, sb_cred = {bv_len = 8, bv_val = 0xde44c0 "9Yew3bqm"}, sb_saslmech = {bv_len = 0, bv_val = 0x0}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x0}, sb_authcId = {bv_len = 0, bv_val = 0x0}, sb_authzId = {bv_len = 0, bv_val = 0x0}}, si_base = {bv_len = 0, bv_val = 0x885c70 ""}, si_logbase = {bv_len = 12, bv_val = 0xde44d0 "cn=accesslog"}, si_filterstr = {bv_len = 15, bv_val = 0xde4510 "(objectclass=*)"}, si_logfilterstr = {bv_len = 46, bv_val = 0xdc6b10 "(&(objectClass=auditWriteObject)(reqResult=0))"}, si_scope = 2, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0xdd2e10, si_exanlist = 0xdd2dc0, si_attrs = 0xdea120, si_exattrs = 0x0, si_allattrs = 0, si_allopattrs = 0, si_schemachecking = 0, si_type = 3, si_ctype = 3, si_interval = 60, si_retryinterval = 0xde4530, si_retrynum_init = 0x885c60, si_retrynum = 0x885c58, si_syncCookie = {ctxcsn = {bv_len = 32, bv_val = 0x24886708 "20080415180631Z#000001#00#000000"}, octet_str = {bv_len = 44, bv_val = 0x23d01a80 "csn=20080415180631Z#000001#00#000000,rid=100"}, rid = 100, sc_next = {stqe_next = 0x0}}, si_manageDSAit = 0, si_slimit = 0, si_tlimit = 0, si_refreshDelete = 0, si_refreshPresent = 0, si_refreshDone = 0, si_syncdata = 1, si_logstate = 0, si_conn_setup = 1, si_msgid = 3, si_presentlist = 0x0, si_ld = 0x24ebc800, si_nonpresentlist = { lh_first = 0x0}, si_mutex = {__data = {__lock = 1, __count = 0, __owner = 19761, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\0001M\000\000\001", '\0' <repeats 26 times>, __align = 1}} -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:52 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: > > (gdb) break do_syncrepl > Breakpoint 1 at 0x494cc5: file syncrepl.c, line 1030. > (gdb) cont > Continuing. > [Switching to Thread 1098918208 (LWP 13474)] also: Breakpoint 2, syncrepl_message_to_op (si=0x8cd800, op=0x43805850, msg=0x2547b230) at syncrepl.c:1281 1281 in syncrepl.c (gdb) up #1 0x0000000000493c1e in do_syncrep2 (op=0x43805850, si=0x8cd800) at syncrepl.c:722 722 in syncrepl.c (gdb) print syncCookie $2 = {ctxcsn = {bv_len = 0, bv_val = 0x0}, octet_str = {bv_len = 0, bv_val = 0x0}, rid = 0, sc_next = {stqe_next = 0x0}} --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 8:38 PM +0000 quanah(a)zimbra.com wrote: (gdb) break do_syncrepl Breakpoint 1 at 0x494cc5: file syncrepl.c, line 1030. (gdb) cont Continuing. [Switching to Thread 1098918208 (LWP 13474)] Breakpoint 1, do_syncrepl (ctx=0x41801e70, arg=0xde9960) at syncrepl.c:1030 1030 syncrepl.c: No such file or directory. in syncrepl.c (gdb) print *si $1 = {si_be = 0xa265d60, si_re = 0x63, si_rid = 1208292709, si_bindconf = {sb_uri = {bv_len = 0, bv_val = 0x43804a20 ""}, sb_tls = 0, sb_method = 0, sb_binddn = {bv_len = 515842056, bv_val = 0x0}, sb_cred = {bv_len = 515842072, bv_val = 0x200000002 <Address 0x200000002 out of bounds>}, sb_saslmech = {bv_len = 18446744073709551615, bv_val = 0xde8614 "ï¿½ï¿½ï¿½ï¿½"}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x1ebf23e0 "ï¿½"}, sb_authcId = {bv_len = 309, bv_val = 0x1ebf2d00 "(&(objectClass=amavisAccount)(|(mail=sentto-11913093-6627-1208292689-evanclark=neo.tamu.edu@returns.groups.yahoo.com)(mail=sentto-11913093-6627-1208292689-evanclark=neo.tamu.edu)(mail=@returns.groups."...}, sb_authzId = {bv_len = 0, bv_val = 0x0}}, si_base = {bv_len = 0, bv_val = 0x0}, si_logbase = {bv_len = 0, bv_val = 0x0}, si_filterstr = { bv_len = 0, bv_val = 0x0}, si_logfilterstr = {bv_len = 0, bv_val = 0xa265dd8 ""}, si_scope = 128, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0x0, si_exanlist = 0x22, si_attrs = 0xa230b68, si_exattrs = 0x22, si_allattrs = 627063816, si_allopattrs = 0, si_schemachecking = 256, si_type = 0, si_ctype = 256, si_interval = 610570800, si_retryinterval = 0x0, si_retrynum_init = 0x43804a00, si_retrynum = 0x0, si_syncCookie = {ctxcsn = {bv_len = 0, bv_val = 0x0}, octet_str = {bv_len = 0, bv_val = 0x0}, rid = 32, sc_next = {stqe_next = 0x8fa0}}, si_manageDSAit = 148281848, si_slimit = 0, si_tlimit = 33, si_refreshDelete = 3, si_refreshPresent = 0, si_refreshDone = 0, si_syncdata = 1132486256, si_logstate = 0, si_conn_setup = 512128712, si_msgid = 0, si_presentlist = 0x619b00, si_ld = 0x3736333d6e6e6f63, si_nonpresentlist = {lh_first = 0x32333d706f203836}, si_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}} -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > I have a replica spitting out the following error in its logs (master and > replica running OpenLDAP 2.3.41): This is happening again. With loglevel = sync, I see: Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=A-B-C,ou=people,dc=abc,dc=123,dc=edu (0) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=neo,dc=tamu,dc=edu (0) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: do_syncrep2: rid 100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Apr 15 13:06:36 neo-ldap-3 slapd[13469]: null_callback: error code 0x14 Apr 15 13:06:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu (20) Apr 15 13:06:36 neo-ldap-3 slapd[13469]: do_syncrepl: rid 100 retrying and then it forever more retries: Apr 15 13:07:36 neo-ldap-3 slapd[13469]: null_callback: error code 0x14 Apr 15 13:07:36 neo-ldap-3 slapd[13469]: syncrepl_message_to_op: rid 100 be_modify uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu (20) Apr 15 13:07:36 neo-ldap-3 slapd[13469]: do_syncrepl: rid 100 retrying On the master, we see: Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD dn="uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu" Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD attr=zimbraPasswordLockoutFailureTime Apr 15 13:06:34 neo-ldap-1 slapd[18587]: conn=313538 op=1 MOD attr=zimbraPasswordLockoutFailureTime Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 fd=24 ACCEPT from IP=10.1.15.23:52299 (IP=10.1.15.21:389) Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=0 STARTTLS Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=0 RESULT oid= err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 fd=24 TLS established tls_ssf=256 ssf=256 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=1 RESULT tag=97 err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313539 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=1 RESULT tag=103 err=0 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: Entry reqStart=20080415180532.000001Z,cn=accesslog CSN 20080415180532Z#000000#00#000000 matches ctx 20080415180532Z#000000#00#000000 Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=2 SRCH base="uid=XXXXX,ou=people,dc=abc,dc=123,dc=edu" scope=0 deref=3 filter="(objectClass=*)" Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 op=3 UNBIND Apr 15 13:06:35 neo-ldap-1 slapd[18587]: conn=313538 fd=23 closed So what I think is of particular interest here, is that the replica hits the master right as the modification has started, but before it has finished. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by hyc＠symas.com 15 Apr '08

15 Apr '08

Howard Chu wrote: > jwm(a)horde.net wrote: >> Full_Name: John Morrissey >> Version: 2.3.41 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.133.190.110) >> >> > OK, the backtraces helped a lot. Thread 6 hit the assertion while trying to > close the connection, and thread 5 was already trying to close the connection. > And Thread 5 was waiting for thread 2 to wake up and give up the connection > handle. Seems like a bug in connection.c, aggravated by the presence of > persistent searches on the connection. Please try the patch in slapd/connection.c 1.416 and report your results, 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#5469) Assertion failure causes slapd crash
by hyc＠symas.com 15 Apr '08

15 Apr '08

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.3.41 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.133.190.110) > > OK, the backtraces helped a lot. Thread 6 hit the assertion while trying to close the connection, and thread 5 was already trying to close the connection. And Thread 5 was waiting for thread 2 to wake up and give up the connection handle. Seems like a bug in connection.c, aggravated by the presence of persistent searches on the connection. > (continuing the openldap-software thread starting at > http://marc.info/?l=openldap-software&m=120654684131594&w=2) > > An assertion failure causes slapd to crash every few days in our environment. > The assertion seems to be in servers/slapd/connection.s:680: > > assert( c->c_writewaiter == 0); > -- -- 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#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 3:49 PM -0400 John Morrissey <jwm(a)horde.net> wrote: > On Tue, Apr 15, 2008 at 11:12:20AM -0700, Quanah Gibson-Mount wrote: >> --On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: >> > moduleload pw-netscape >> >> What is this? > > http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/passwd/net > scape.c > >> > threads 32 >> >> How many CPUs does your server have? > > Two physical cores, four if you count x86 hyperthread "processors." So two. ;) You could set tool-threads to 2 then, it'd increase slapadds if you ever do them. >> This is a particularly high thread setting. Most often, a lower setting >> results in better performance (I generally use 8 threads on dual-CPU >> systems). Having too many threads has resulted in strange behavior for >> me in the past as well. > > FWIW, slapd has been rock-solid on this hardware with this (or essentially > similar) configuration since before 2.1.30 up through 2.3.30. We skipped > forward to 2.3.41, and started seeing these crashes. However, we weren't > using syncrepl until 2.3.41, either. Yeah, just noting my past experience. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5469) Assertion failure causes slapd crash
by jwm＠horde.net 15 Apr '08

15 Apr '08

On Tue, Apr 15, 2008 at 11:12:20AM -0700, Quanah Gibson-Mount wrote: > --On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: > > moduleload pw-netscape > > What is this? http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/passwd/netsc… > > threads 32 > > How many CPUs does your server have? Two physical cores, four if you count x86 hyperthread "processors." > This is a particularly high thread setting. Most often, a lower setting > results in better performance (I generally use 8 threads on dual-CPU > systems). Having too many threads has resulted in strange behavior for me > in the past as well. FWIW, slapd has been rock-solid on this hardware with this (or essentially similar) configuration since before 2.1.30 up through 2.3.30. We skipped forward to 2.3.41, and started seeing these crashes. However, we weren't using syncrepl until 2.3.41, either. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5468) You can put irrevant thing on LDIF file "add" line
by hyc＠symas.com 15 Apr '08

15 Apr '08

Thanks for the report. This is a known bug in 2.3 and was fixed in OpenLDAP 2.4.4. The fix will not be backported to 2.3. This ITS will be closed. patrick.ni(a)strangeloopnetworks.com wrote: > Full_Name: Patrick Ni > Version: 2.3.30-5 > OS: Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12etch2) (dannf(a)debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.77.66.100) > > > > Hello, > > I have a group entry for myself "patrick" in the LDAP database as follows: > > dn: cn=patrick,ou=Group,dc=strangeloop,dc=net > objectClass: posixGroup > objectClass: top > cn: patrick > userPassword:: e1NTSEF9eA== > gidNumber: 500 > memberUid: patrick > > > Recently, I realized I could add my 2nd openLDAP account > "dn:uid=patrick2,ou=Accounts,dc=strangeloop,dc=net" into my group "patrick" > using the following LDIF file: > > > ldap1:~/ldap# more group2_patrick.ldif > dn: cn=patrick,ou=Group,dc=strangeloop,dc=net > changetype:modify > add:membership > memberUid:patrick2 > > This should not have succeeded because the "add:membership" line is wrong; It > should have been "add:memberUid". > > thanks > -Patrick > > > -- -- 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#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 15 Apr '08

15 Apr '08

--On Tuesday, April 15, 2008 5:33 PM +0000 jwm(a)horde.net wrote: > moduleload pw-netscape What is this? > threads 32 How many CPUs does your server have? This is a particularly high thread setting. Most often, a lower setting results in better performance (I generally use 8 threads on dual-CPU systems). Having too many threads has resulted in strange behavior for me in the past as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5469) Assertion failure causes slapd crash
by jwm＠horde.net 15 Apr '08

15 Apr '08

Full_Name: John Morrissey Version: 2.3.41 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) (continuing the openldap-software thread starting at http://marc.info/?l=openldap-software&m=120654684131594&w=2) An assertion failure causes slapd to crash every few days in our environment. The assertion seems to be in servers/slapd/connection.s:680: assert( c->c_writewaiter == 0); Program received signal SIGABRT, Aborted. [Switching to Thread -1917846608 (LWP 13701)] 0xb7c02947 in raise () from /lib/tls/libc.so.6 Thread 11 (Thread -1958761552 (LWP 13860)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f8106a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8db12ee8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0xa1, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x89aff008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x4c, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2336205744 i = 549 keyslot = 549 hash = 549 #3 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1954567248 (LWP 13859)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f8106a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x830d410, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0xa2, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x892fe008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x4d, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2340400048 i = 613 keyslot = 613 hash = 613 #3 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1949320272 (LWP 13858)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x90389d60, mutex=0x90389ca8) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0x08083dcc in send_ldap_ber (conn=0x90389c98, ber=0x8bcface4) at /var/jwm/o2/openldap/servers/slapd/result.c:198 err = 11 sd = 31 bytes = 118 #3 0x080871db in slap_send_search_entry (op=0x8bcfb0c0, rs=0x8bcfaef0) at /var/jwm/o2/openldap/servers/slapd/result.c:1137 berbuf = {buffer = "\002\000\001\000\000\000\000\000ˇˇˇˇ\000\000\000\000\000\000\000\000$¡\177\213\232¡\177\213R\177\213\000\000\000\000n¡\177\213∏0\b@≠\213(∞\177\213\001\000\000\0008≠\213Æ\213\005Æ\213ˇˇˇˇ\000\000\000\000ˇˇˇˇ\a\000\000\000\020\000\000\000V\211Q\206\000\000\001\000\000\000\000\000ˇˇˇˇ", '\0' <repeats 12 times>, "\201∞\177\2138¿\177\213\000\000\000\000\000\000\000\000∏0\bøÌ∑\030\000\000\000∏0\b\000\000\000\000\001\000\000\000\f∞\177\213\232c∑\016\000\000\000\222\021∑\220±\213Æ\213ÿ≠\213ÛÙ∑\f∞\177\213¯≠\213\f\000\000\000\037\035"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8bcface4 a = (Attribute *) 0x0 i = -1949323552 j = 0 rc = 118 bytes = 1030648675 edn = 0x8651892f "reqStart=20080331134601.000004Z,cn=log" userattrs = 1 acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x816cd90 e_flags = (char **) 0x0 #4 0xb7a098e8 in syncprov_sendresp (op=0x8bcfb0c0, opc=0x8bcfaf6c, so=0x825f118, e=0x8bcfaf98, mode=3) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:798 on = (slap_overinst *) 0x81bec18 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x8bcfaee8, sr_un = {sru_sasl = {r_sasldata = 0x8bcfaeb8}, sru_extended = {r_rspoid = 0x8bcfaeb8 "", r_rspdata = 0x21}, sru_search = {r_entry = 0x8bcfaeb8, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} ctrls = {0x8b7fb024, 0x0} cookie = {bv_len = 12, bv_val = 0x8b7fb00c "csn=,rid=001"} e_uuid = {e_id = 0, e_name = {bv_len = 38, bv_val = 0x86518908 "reqStart=20080331134601.000004Z,cn=log"}, e_nname = {bv_len = 38, bv_val = 0x8651892f "reqStart=20080331134601.000004Z,cn=log"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x8169d00, a_vals = 0x0, a_nvals = 0x8bcfaf84, a_next = 0x0, a_flags = 0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #5 0xb7a09b5b in syncprov_qplay (op=0x8bcfb0c0, on=0x81bec18, so=0x825f118) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:853 sr = (syncres *) 0x865188e0 e = (Entry *) 0x0 opc = {son = 0x81bec18, smatches = 0x7, sdn = {bv_len = 38, bv_val = 0x86518908 "reqStart=20080331134601.000004Z,cn=log"}, sndn = {bv_len = 38, bv_val = 0x8651892f "reqStart=20080331134601.000004Z,cn=log"}, suuid = {bv_len = 16, bv_val = 0x86518956 "\214(gæ\223t\020,\206∑o_ÓK_◊0"}, sctxcsn = {bv_len = 0, bv_val = 0x86518967 ""}, sreference = 0} rc = 0 #6 0xb7a09d20 in syncprov_qtask (ctx=0x8bcfb2b4, arg=0x8db02d38) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:898 rtask = (struct re_s *) 0x8db02d38 so = (syncops *) 0x825f118 on = (slap_overinst *) 0x81bec18 opbuf = {buffer = "\220±\213c\000\000\000Æ\\\003H\000\000\000\000¿Ø\213\006\000\000\000\221Û%\b\006\000\000\000\230Û%\b\002\000\000\000\000\000\000\000ˇˇˇˇˇˇˇˇ\024Í\033\b\000\000\000\000\224Ú%\b»%\b.\000\000\000\237Û%\b", '\0' <repeats 12 times>, "\001", '\0' <repeats 39 times>, "Ï±\213\200", '\0' <repeats 11 times>, "\025\000\000\000{Û%\b\025\000\000\000{Û%\b", '\0' <repeats 48 times>, "\001\000\000\000\005\000\000\000\230\2348\220\002\000\000\000\003\000\000\000\000\000\000\000¥≤\213∏0\bž⁄\025\bconn=5 op=1", '\0' <repeats 172 times>, ialign = -1949322864, lalign = -1949322864, falign = -8.00006661e-32, dalign = 2.1123648563677196e-312, palign = 0x8bcfb190 "\001"} op = (Operation *) 0x8bcfb0c0 be = {bd_info = 0x81beb18, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81be8e0, be_nsuffix = 0x81be8f8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x81be798 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x81be980 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x81be970, be_acl = 0x81ae418, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8237f48, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x81be5f8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a44ce0, be_private = 0x81be630, be_next = {stqe_next = 0x81bee50}} rc = -1208475305 #7 0xb7f80fd9 in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x830a060 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x830a0b8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0xa3, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x8238260, ltk_data = 0x4b, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x88afd008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2345647024 i = 709 keyslot = 709 hash = 709 #8 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1945125968 (LWP 13857)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x9038a320, mutex=0x9038a268) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0x08083dcc in send_ldap_ber (conn=0x9038a258, ber=0x8c0face4) at /var/jwm/o2/openldap/servers/slapd/result.c:198 err = 11 sd = 35 bytes = 118 #3 0x080871db in slap_send_search_entry (op=0x8c0fb0c0, rs=0x8c0faef0) at /var/jwm/o2/openldap/servers/slapd/result.c:1137 berbuf = {buffer = "\002\000\001\000\000\000\000\000ˇˇˇˇ\000\000\000\000\000\000\000\000$\221\212\232\221\212R°\212\000\000\000\000n\221\212Pm)\b@≠\017\214(\200\212\001\000\000\0008≠\017\214Æ\017\214\005Æ\017\214ˇˇˇˇ\000\000\000\000ˇˇˇˇ\a\000\000\000\020\000\000\000N¬\035\210\000\000\001\000\000\000\000\000ˇˇˇˇ", '\0' <repeats 12 times>, "\201\200\2128\220\212\000\000\000\000\000\000\000\000Pm)\bøÌ∑\030\000\000\000Pm)\bHRQ\f\000\000\000\000\f\200\212ºF§∑\bÆ\017\214r\222£∑\220±\017\214Æ\017\214ÿ≠\017\214ÛÙ∑\f\200\212¯≠\017\214\f\000\000\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8c0face4 a = (Attribute *) 0x0 i = -1945129248 j = 0 rc = 118 bytes = 1030648675 edn = 0x881dc227 "reqStart=20080331134601.000004Z,cn=log" userattrs = 1 acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x816cd90 e_flags = (char **) 0x0 #4 0xb7a098e8 in syncprov_sendresp (op=0x8c0fb0c0, opc=0x8c0faf6c, so=0x8262030, e=0x8c0faf98, mode=3) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:798 on = (slap_overinst *) 0x81bec18 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x8c0faee8, sr_un = {sru_sasl = {r_sasldata = 0x8c0faeb8}, sru_extended = {r_rspoid = 0x8c0faeb8 "", r_rspdata = 0x21}, sru_search = {r_entry = 0x8c0faeb8, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} ctrls = {0x8acf8024, 0x0} cookie = {bv_len = 12, bv_val = 0x8acf800c "csn=,rid=001"} e_uuid = {e_id = 0, e_name = {bv_len = 38, bv_val = 0x881dc200 "reqStart=20080331134601.000004Z,cn=log"}, e_nname = {bv_len = 38, bv_val = 0x881dc227 "reqStart=20080331134601.000004Z,cn=log"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x8169d00, a_vals = 0x0, a_nvals = 0x8c0faf84, a_next = 0x0, a_flags = 0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #5 0xb7a09b5b in syncprov_qplay (op=0x8c0fb0c0, on=0x81bec18, so=0x8262030) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:853 sr = (syncres *) 0x881dc1d8 e = (Entry *) 0x0 opc = {son = 0x81bec18, smatches = 0x7, sdn = {bv_len = 38, bv_val = 0x881dc200 "reqStart=20080331134601.000004Z,cn=log"}, sndn = {bv_len = 38, bv_val = 0x881dc227 "reqStart=20080331134601.000004Z,cn=log"}, suuid = {bv_len = 16, bv_val = 0x881dc24e "\214(gæ\223t\020,\206∑o_ÓK_◊0"}, sctxcsn = {bv_len = 0, bv_val = 0x881dc25f ""}, sreference = 0} rc = 0 #6 0xb7a09d20 in syncprov_qtask (ctx=0x8c0fb2b4, arg=0x8db02300) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:898 rtask = (struct re_s *) 0x8db02300 so = (syncops *) 0x8262030 on = (slap_overinst *) 0x81bec18 opbuf = {buffer = "\220±\017\214c\000\000\000Æ\\\003H\000\000\000\000¿Ø\017\214\006\000\000\000©\"&\b\006\000\000\000∞\"&\b\002\000\000\000\000\000\000\000ˇˇˇˇˇˇˇˇ\024Í\033\b\000\000\000\000š!&\b¯˝%\b.\000\000\000∑\"&\b", '\0' <repeats 12 times>, "\001", '\0' <repeats 39 times>, "Ï±\017\214\200", '\0' <repeats 11 times>, "\025\000\000\000\223\"&\b\025\000\000\000\223\"&\b", '\0' <repeats 48 times>, "\001\000\000\000\t\000\000\000X¢8\220\002\000\000\000\003\000\000\000\000\000\000\000¥≤\017\214Pm)\bž⁄\025\bconn=9 op=1", '\0' <repeats 172 times>, ialign = -1945128560, lalign = -1945128560, falign = -1.10697526e-31, dalign = 2.1123855789828658e-312, palign = 0x8c0fb190 "\001"} op = (Operation *) 0x8c0fb0c0 be = {bd_info = 0x81beb18, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81be8e0, be_nsuffix = 0x81be8f8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x81be798 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x81be980 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x81be970, be_acl = 0x81ae418, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8237f48, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x81be5f8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a44ce0, be_private = 0x81be630, be_next = {stqe_next = 0x81bee50}} rc = -1208475305 #7 0xb7f80fd9 in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x8310ec8 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8296d50, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0xa0, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8a4f7008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x4a, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2349841328 i = 518 keyslot = 518 hash = 518 #8 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1922040912 (LWP 13704)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f8106a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8261fe0, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x48, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x8240a18, ltk_data = 0x57, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8c9fe008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2372926384 i = 679 keyslot = 679 hash = 679 #3 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1917846608 (LWP 13701)): #0 0xb7c02947 in raise () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb7c040c9 in abort () from /lib/tls/libc.so.6 No symbol table info available. #2 0xb7bfc05f in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #3 0x08071d03 in connection_destroy (c=0x90389f78) at /var/jwm/o2/openldap/servers/slapd/connection.c:680 sd = -2049090272 connid = 2377118104 close_reason = 0xb7c40022 "e\203=\f" sb = (Sockbuf *) 0x8a300010 __PRETTY_FUNCTION__ = "connection_destroy" #4 0x080726ab in connection_close (c=0x90389f78) at /var/jwm/o2/openldap/servers/slapd/connection.c:900 sd = -1 __PRETTY_FUNCTION__ = "connection_close" #5 0x080740bd in connection_resched (conn=0x90389f78) at /var/jwm/o2/openldap/servers/slapd/connection.c:1722 sd = 33 op = (Operation *) 0xb7fb8478 __PRETTY_FUNCTION__ = "connection_resched" #6 0x08073009 in connection_operation (ctx=0x8daff2b4, arg_v=0x8a30deb8) at /var/jwm/o2/openldap/servers/slapd/connection.c:1179 rc = 0 op = (Operation *) 0x8a30deb8 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 66 opidx = SLAP_OP_UNBIND conn = (Connection *) 0x90389f78 memctx = (void *) 0x824eef0 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #7 0xb7f80fd9 in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x8242fe0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x824eef0, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0x58, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8c0fc008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x49, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 keyslot = 743 hash = 743 #8 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1538593872 (LWP 13662)): #0 0xb7d16189 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7d12f6d in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0xa44ac278 in ?? () No symbol table info available. #3 0x00000021 in ?? () No symbol table info available. #4 0xa44ac298 in ?? () No symbol table info available. #5 0xb7d1639a in __write_nocancel () from /lib/tls/libpthread.so.0 No symbol table info available. #6 0xb7fb8478 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #7 0x00000021 in ?? () No symbol table info available. #8 0x00000084 in ?? () No symbol table info available. #9 0xa44ac298 in ?? () No symbol table info available. #10 0xb7f82111 in ldap_pvt_thread_mutex_lock (mutex=0x9038a028) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:333 No locals. #11 0xb7f82111 in ldap_pvt_thread_mutex_lock (mutex=0x9038a028) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:333 No locals. #12 0x08072431 in connection_closing (c=0x90389f78, why=0x8116ac0 "connection lost") at /var/jwm/o2/openldap/servers/slapd/connection.c:851 sd = 33 __PRETTY_FUNCTION__ = "connection_closing" #13 0x08073928 in connection_read (s=33) at /var/jwm/o2/openldap/servers/slapd/connection.c:1457 rc = -2 c = (Connection *) 0x90389f78 __PRETTY_FUNCTION__ = "connection_read" #14 0x0807014a in slapd_daemon_task (ptr=0x0) at /var/jwm/o2/openldap/servers/slapd/daemon.c:2468 rc = 1 fd = 33 ns = 1 at = 0 nfds = 9 revents = (struct epoll_event *) 0xb7b60008 tvp = (struct timeval *) 0xa44ae3a4 cat = {tv_sec = 1208266580, tv_usec = 0} i = 0 nwriters = 3 now = 1208266286 tv = {tv_sec = 294, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x81bea68 l = 4 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #15 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #16 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875350608 (LWP 13663)): #0 0xb7d13c01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f8106a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x824b618, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x2c, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8ee85008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8240a18, ltk_data = 0x50, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419616688 i = 483 keyslot = 483 hash = 483 #3 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1879544912 (LWP 13664)): #0 bdb_delete (op=0x8ff85f54, rs=0x8ff85f18) at /var/jwm/o2/openldap/servers/slapd/back-bdb/delete.c:27 bdb = (struct bdb_info *) 0x81be630 matched = (Entry *) 0x8ff85f54 pdn = {bv_len = 6, bv_val = 0x865fd8f0 "cn=log"} e = (Entry *) 0x821d9880 p = (Entry *) 0x0 ei = (EntryInfo *) 0x8a309750 eip = (EntryInfo *) 0x8000 manageDSAit = 0 children = (AttributeDescription *) 0x816cf20 entry = (AttributeDescription *) 0x816cd90 ltid = (DB_TXN *) 0x44 lt2 = (DB_TXN *) 0x809a1f58 opinfo = {boi_bdb = 0x8ff85f54, boi_txn = 0x8ed8cc0c, boi_err = 1, boi_locker = 135247857, boi_acl_cache = 0, boi_locks = 0x0} eid = 213912 locker = 136047640 lock = {off = 0, ndx = 2415419220, gen = 2415418584, mode = 3080766465} plock = {off = 2396572940, ndx = 0, gen = 2415418456, mode = 3080782120} num_retries = 136047896 rc = -1898394628 preread_ctrl = (LDAPControl **) 0x8ed8cc0c ctrls = {0x0, 0x821d9a68, 0x0, 0x0, 0x8ff85d28, 0xb7f820cb} num_ctrls = 1 parent_is_glue = 68 parent_is_leaf = -2053373400 #1 0x080ded7e in overlay_op_walk (op=0x8ff85f54, rs=0x8ff85f18, which=op_delete, oi=0x81beb18, on=0x0) at /var/jwm/o2/openldap/servers/slapd/backover.c:650 func = (BI_op_bind **) 0xb7a44e0c rc = 32768 #2 0x080def35 in over_op_func (op=0x8ff85f54, rs=0x8ff85f18, which=op_delete) at /var/jwm/o2/openldap/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x81beb18 on = (slap_overinst *) 0x81bec18 be = (BackendDB *) 0x81be528 db = {bd_info = 0xb7a44de0, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81be8e0, be_nsuffix = 0x81be8f8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x81be798 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x81be980 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x81be970, be_acl = 0x81ae418, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8237f48, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x81be5f8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a44ce0, be_private = 0x81be630, be_next = {stqe_next = 0x81bee50}} cb = {sc_next = 0xb7a19e20, sc_response = 0x80de204 <over_back_response>, sc_cleanup = 0, sc_private = 0x81beb18} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #3 0x080df063 in over_op_delete (op=0x8ff85f54, rs=0x8ff85f18) at /var/jwm/o2/openldap/servers/slapd/backover.c:754 No locals. #4 0xb7a13496 in accesslog_purge (ctx=0x8ff862b4, arg=0x81bfb60) at /var/jwm/o2/openldap/servers/slapd/overlays/accesslog.c:589 i = 80 rtask = (struct re_s *) 0x81bfb60 li = (struct log_info *) 0x81c03e0 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = 0, c_close_reason = 0x0, c_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x8111618 ""}, c_peer_name = {bv_len = 0, bv_val = 0x8111618 ""}, c_listener = 0x81174e0, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 27 times>, __align = 0}, c_currentber = 0x0, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x8084ab6 <slap_send_ldap_result>, c_send_search_entry = 0x8085754 <slap_send_search_entry>, c_send_search_reference = 0x80875cd <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {buffer = "$`¯\217J\000\000\000(Æ\004H\000\000\000\000(]¯\217&\000\000\000b¡\205&\000\000\000X¡\000\202\001\000\000\000\000\000\000\000ˇˇˇˇˇˇˇˇ\000\000\000\000\001\000\000\000 ÿ\025\bž^¯\217\033\000\000\000\f@ÿ\216", '\0' <repeats 52 times>, "\200`¯\217", '\0' <repeats 12 times>, "\016\000\000\000\230Á\033\b\016\000\000\000\200È\033\b", '\0' <repeats 24 times>, "žÀÿ\216\000\000\000\000 \000\000\000\202^¯\217", '\0' <repeats 12 times>, "ˇˇˇˇ\000a¯\217", '\0' <repeats 12 times>, "¥b¯\217\000\003%\bž⁄\025\bconn=-1 op=0", '\0' <repeats 171 times>, ialign = -1879547868, lalign = -1879547868, falign = -2.44917201e-29, dalign = 1.5822106429110247e-312, palign = 0x8ff86024 ""} op = (Operation *) 0x8ff85f54 rs = {sr_type = REP_RESULT, sr_tag = 107, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x815d820, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0xb7a12f75 <log_old_lookup>, sc_cleanup = 0, sc_private = 0x8ff85ed8} f = {f_choice = 166, f_un = {f_un_result = -1879548176, f_un_dn = 0x8ff85ef0, f_un_desc = 0x8ff85ef0, f_un_ava = 0x8ff85ef0, f_un_ssa = 0x8ff85ef0, f_un_mra = 0x8ff85ef0, f_un_complex = 0x8ff85ef0}, f_next = 0x0} ava = {aa_desc = 0x81a8cc8, aa_value = {bv_len = 15, bv_val = 0x8ff85ec2 "20080401133120Z"}} pd = {slots = 11100, used = 11024, dn = 0x80770630, ndn = 0x807ab2e8, csn = {bv_len = 32, bv_val = 0x8ff85e82 "20080331133120Z#000000#00#00000008x\204˚∑Ë^¯\217\220\027¯∑∞k¯\217∞k¯\217"}} timebuf = "20080401133120Z\000∑\020\0000\212" csnbuf = "20080331133120Z#000000#00#00000008x\204˚∑Ë^¯\217\220\027¯∑∞k¯\217∞k¯\217\000\000\000\000\000\000\000\000¥b" old = 1207056680 #5 0xb7f80fd9 in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x825eef8 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8250300, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0x46, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8dc81008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x43, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415422384 i = 674 keyslot = 674 hash = 674 #6 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #7 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (Thread -1883739216 (LWP 13665)): #0 0xb7d16189 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7d18192 in _L_mutex_cond_lock_29 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0x0000002c in ?? () No symbol table info available. #3 0x00000076 in ?? () No symbol table info available. #4 0x0000005c in ?? () No symbol table info available. #5 0xb7d12e17 in pthread_mutex_lock () from /lib/tls/libpthread.so.0 No symbol table info available. #6 0xb7d13c8b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #7 0xb7f820a0 in ldap_pvt_thread_cond_wait (cond=0x9038a040, mutex=0x90389f88) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #8 0x08083dcc in send_ldap_ber (conn=0x90389f78, ber=0x8fb85ce4) at /var/jwm/o2/openldap/servers/slapd/result.c:198 err = 11 sd = 33 bytes = 118 #9 0x080871db in slap_send_search_entry (op=0x8fb860c0, rs=0x8fb85ef0) at /var/jwm/o2/openldap/servers/slapd/result.c:1137 berbuf = {buffer = "\002\000\001\000\000\000\000\000ˇˇˇˇ\000\000\000\000\000\000\000\000$A»\216\232A»\216RQ»\216\000\000\000\000nA»\2167%\b@]∏\217(0»\216\001\000\000\0008]∏\217^∏\217\005^∏\217ˇˇˇˇ\000\000\000\000ˇˇˇˇ\a\000\000\000\020\000\000\000\0268\206\000\000\001\000\000\000\000\000ˇˇˇˇ", '\0' <repeats 12 times>, "\2010»\2168@»\216\000\000\000\000\000\000\000\0007%\bøÌ∑\030\000\000\0007%\bHRQ\f\000\000\000\000\f0»\216ºF§∑\b^∏\217r\222£∑\220a∏\217^∏\217ÿ]∏\217ÛÙ∑\f0»\216¯]∏\217\f\000\000\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x8fb85ce4 a = (Attribute *) 0x0 i = -1883742496 j = 0 rc = 118 bytes = 1030648675 edn = 0x86389fef "reqStart=20080331134601.000004Z,cn=log" userattrs = 1 acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x816cd90 e_flags = (char **) 0x0 #10 0xb7a098e8 in syncprov_sendresp (op=0x8fb860c0, opc=0x8fb85f6c, so=0x825fb18, e=0x8fb85f98, mode=3) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:798 on = (slap_overinst *) 0x81bec18 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x8fb85ee8, sr_un = {sru_sasl = {r_sasldata = 0x8fb85eb8}, sru_extended = {r_rspoid = 0x8fb85eb8 "", r_rspdata = 0x21}, sru_search = {r_entry = 0x8fb85eb8, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} ctrls = {0x8ec83024, 0x0} cookie = {bv_len = 12, bv_val = 0x8ec8300c "csn=,rid=001"} e_uuid = {e_id = 0, e_name = {bv_len = 38, bv_val = 0x86389fc8 "reqStart=20080331134601.000004Z,cn=log"}, e_nname = {bv_len = 38, bv_val = 0x86389fef "reqStart=20080331134601.000004Z,cn=log"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x8169d00, a_vals = 0x0, a_nvals = 0x8fb85f84, a_next = 0x0, a_flags = 0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #11 0xb7a09b5b in syncprov_qplay (op=0x8fb860c0, on=0x81bec18, so=0x825fb18) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:853 sr = (syncres *) 0x86389fa0 e = (Entry *) 0x0 opc = {son = 0x81bec18, smatches = 0x7, sdn = {bv_len = 38, bv_val = 0x86389fc8 "reqStart=20080331134601.000004Z,cn=log"}, sndn = {bv_len = 38, bv_val = 0x86389fef "reqStart=20080331134601.000004Z,cn=log"}, suuid = {bv_len = 16, bv_val = 0x8638a016 "\214(gæ\223t\020,\206∑o_ÓK_◊0"}, sctxcsn = {bv_len = 0, bv_val = 0x8638a027 ""}, sreference = 0} rc = 0 #12 0xb7a09d20 in syncprov_qtask (ctx=0x8fb862b4, arg=0x8db02330) at /var/jwm/o2/openldap/servers/slapd/overlays/syncprov.c:898 rtask = (struct re_s *) 0x8db02330 so = (syncops *) 0x825fb18 on = (slap_overinst *) 0x81bec18 opbuf = {buffer = "\220a∏\217c\000\000\000Æ\\\003H\000\000\000\000¿_∏\217\006\000\000\000\221˝%\b\006\000\000\000\230˝%\b\002\000\000\000\000\000\000\000ˇˇˇˇˇˇˇˇ\024Í\033\b\000\000\000\000\224ž%\bH%\b.\000\000\000\237˝%\b", '\0' <repeats 12 times>, "\001", '\0' <repeats 39 times>, "Ïa∏\217\200", '\0' <repeats 11 times>, "\025\000\000\000{˝%\b\025\000\000\000{˝%\b", '\0' <repeats 48 times>, "\001\000\000\000\a\000\000\000x\2378\220\002\000\000\000\003\000\000\000\000\000\000\000¥b∏\2177%\bž⁄\025\bconn=7 op=1", '\0' <repeats 172 times>, ialign = -1883741808, lalign = -1883741808, falign = -1.81813805e-29, dalign = 2.1126888698355955e-312, palign = 0x8fb86190 "\001"} op = (Operation *) 0x8fb860c0 be = {bd_info = 0x81beb18, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81be8e0, be_nsuffix = 0x81be8f8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x81be798 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x81be980 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x81be970, be_acl = 0x81ae418, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8237f48, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x81be5f8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb7a44ce0, be_private = 0x81be630, be_next = {stqe_next = 0x81bee50}} rc = -1208475305 #13 0xb7f80fd9 in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x82604e8 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x82537d0, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8240a18, ltk_data = 0x47, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0xb7a2fe55, ltk_data = 0x8e482008, ltk_free = 0xb7a2fe2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x42, ltk_free = 0xb7a3e64d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2411228080 i = 610 keyslot = 610 hash = 610 #14 0xb7d110bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0xb7ca601e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212397344 (LWP 13658)): #0 0xb7d12183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f81f9b in ldap_pvt_thread_join (thread=2756373424, thread_return=0x0) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08070524 in slapd_daemon () at /var/jwm/o2/openldap/servers/slapd/daemon.c:2579 listener_tid = 2756373424 rc = 0 #3 0x0805a58d in main (argc=9, argv=0xbffb3d54) at /var/jwm/o2/openldap/servers/slapd/main.c:859 i = 9 no_detach = 0 rc = 0 urls = 0x8162008 "ldap:/// ldaps:///" username = 0x8162030 "gidNumber" groupname = 0x8162020 "\202æ∑∞\237∑" sandbox = 0x0 syslogUser = 160 g_argc = 9 g_argv = (char **) 0xbffb3d54 configfile = 0x8162040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = 0xbffb3ea7 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x81112bb "" l = 3086380280 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" #0 0xb7c02947 in raise () from /lib/tls/libc.so.6 # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/qmail.schema include /etc/ldap/schema/radius.schema include /etc/ldap/schema/isis.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_monitor moduleload back_bdb moduleload accesslog moduleload syncprov moduleload pw-netscape threads 32 # Number of threads to use with tools (slapindex, etc.) tool-threads 1 allow bind_v2 TLSCACertificateFile /etc/ldap/isis-ca.pem TLSCertificateFile /etc/ldap/slapd.crt TLSCertificateKeyFile /etc/ldap/slapd.key password-hash {CRYPT} # Use MD5-based crypt(3) password-crypt-salt-format $1$%.8s sizelimit 500 # Enable the monitor (cn=Monitor) backend. database monitor # The log database, for delta-syncrepl. database bdb suffix cn=log directory /var/lib/ldap/log cachesize 10000 checkpoint 5000 5 rootdn cn=root,cn=log limits dn.exact=cn=replica,o=org size=unlimited time=unlimited index objectClass,entryCSN,entryUUID eq index reqStart,reqEnd,reqResult eq overlay syncprov syncprov-checkpoint 100 5 syncprov-reloadhint true syncprov-nopresent true # The main database. database bdb suffix o=org directory /var/lib/ldap cachesize 10000 checkpoint 5000 5 replogfile /var/lib/ldap/replog replica host=172.16.4.10:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.4.11:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.4.12:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.4.13:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.81:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.82:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.83:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.84:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.85:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] replica host=172.16.5.86:389 binddn=cn=replica,o=org bindmethod=simple credentials=[elided] rootdn cn=root,o=org rootpw [elided] limits dn.exact=cn=replica,o=org size=unlimited time=unlimited index entryCSN,entryUUID eq index objectClass,accountStatus,group eq index uid,sn,businessName eq,subany index mail,mailAlternateAddress eq index uidNumber,gidNumber eq index parent eq index billingTelephoneNumber,telephoneNumber eq,subany index fictitiousTelephoneNumber eq,subany index filterName subany index hasPriv pres,eq index dslCircuitId eq,subany index statusChangeTimestamp,scheduledStatusChange eq index outsideAgent eq index radiusFramedIPAddress eq index lanNetwork eq,subany index routerName,routerInterface eq index serviceType,billingType eq index realm eq index accountUniqueID eq index domainNames pres,eq index dc pres,eq index registrationType,orderId,registrationStatus eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint true overlay accesslog logdb cn=log logops writes logsuccess true # Scan the log DB every day, and purge entries older than 14 days. logpurge 14+00:00 01+00:00

1 0

Re: (ITS#5467) aliases broke on hdb/bdb ?
by h.b.furuseth＠usit.uio.no 15 Apr '08

15 Apr '08

cowboy(a)linux.vnet.ibm.com writes: > Sorry for the noise - I would've started on the mailing list, but > I was given erroneous advise on howto achive a goal - and after > reading the relevant rfc - thought it might indeed do what I wanted. Definitely take this to a mailinglist. openldap-technical, I guess. > It looks like to do what I want, I need in DIT referrals :( I haven't tested, but the server shouldn't apply the filter to referral objects either. The referred-to server will apply the filter. As far as I understand, the baseDN and scope says what to search, while the filter is applied to candidate entries for being returned to the user. My guess is you need another approach entirely. Keep the concepts separate - if something is called an "alias" in Samba or whatever,d that doesn't mean it makes sense to use an alias in LDAP. -- Hallvard

1 0

Re: (ITS#5467) aliases broke on hdb/bdb ?
by cowboy＠linux.vnet.ibm.com 15 Apr '08

15 Apr '08

Hallvard B Furuseth wrote: > Not a bug. A search which dereferences aliases, checks the filter > against the _aliased_ entry, not against the _alias_ entry. Sorry for the noise - I would've started on the mailing list, but I was given erroneous advise on howto achive a goal - and after reading the relevant rfc - thought it might indeed do what I wanted. It looks like to do what I want, I need in DIT referrals :( > So, try ldapsearch -a always uid=wilfinge. Well, that, of course, works fine - but misses what I need entirely I have an extant DIT holding Unix/Samba/Kerberos user information, and have a need to provide a few accounts with an 'alias' - due to these users having used differing account names on other systems. I want both 'wilfing' and 'wilfinge' to windup providing the account data for the 'wilfinge' entry. -- Richard A Nelson (Rick) cowboy(a)((linux.)?vnet|us).ibm.com Phone: 1-408-463-5584 Fax: 1-408-463-3873 COBOL Development IBM Silicon Valley Laboratory http://www.ibm.com/software/awdtools/cobol/

1 0

Re: (ITS#5460) unresolved symbol
by hyc＠symas.com 15 Apr '08

15 Apr '08

st-wong(a)cuhk.edu.hk wrote: > Full_Name: ST Wong > Version: 2.4.8 > OS: CentOS 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.189.29.184) > > > Got error when compiling Openldap 2.4.8 with BerkeleyDB 4.6: > > > ---------------------- cut here ----------------------- > ... > checking for db.h... yes > checking for Berkeley DB major version... 4 > checking for Berkeley DB minor version... 3 > checking for Berkeley DB link (-ldb-4.3)... (cached) no > checking for Berkeley DB link (-ldb43)... no > checking for Berkeley DB link (-ldb-43)... no > checking for Berkeley DB link (-ldb-4-3)... no > checking for Berkeley DB link (-ldb-4)... no > checking for Berkeley DB link (-ldb4)... no > checking for Berkeley DB link (-ldb)... yes > checking for Berkeley DB version match... yes > checking for Berkeley DB thread support... yes > checking Berkeley DB version for BDB/HDB backends... no > configure: error: BDB/HDB: BerkeleyDB version incompatible > ---------------------- cut here ----------------------- > > In config.log: > ---------------------- cut here ----------------------- > configure:17625: checking for resolver link (default) > configure:17691: cc -o conftest -g -O2 -I/usr/local/BerkeleyDB.4.6/include > -L/usr/local/BerkeleyDB.4.6/lib conftest.c>&5 > /tmp/ccczbyKW.o: In function `main': > /usr/local/src/openldap-2.4.8/conftest.c:113: undefined reference to > `__res_query' > /usr/local/src/openldap-2.4.8/conftest.c:132: undefined reference to > `__dn_expand' > collect2: ld returned 1 exit status > ---------------------- cut here ----------------------- Your config.log extract doesn't match the error text above. > Have to add "-lresolv" to LDFLAGS in order to resolve the problem. I suppose > configure will add all libraries required. Configure finds -lresolv automatically. That's certainly not the cause of your problem. Your configure session indicates that your system's default db.h came from BerkeleyDB 4.3 which is explicitly not supported. There's no indication of any software bug here; this ITS will be closed. Use the openldap-software mailing list if you need more help, these questions have been covered many times there and searching the list archives will give you the right answers. -- -- 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#5325) Build error: __lock_getlocker undefined symbol
by hyc＠symas.com 15 Apr '08

15 Apr '08

ando(a)sys-net.it wrote: > As Hallvard pointed out, probably that function was not meant to be > exposed, since it's not declared in Berkeley's headers, but > unfortunately OpenLDAP code seems to need it. At some point (soon) we'll have to remove that dependency and go back to using a per-thread read-only transaction for back-bdb's entry cache locking. The __lock_getlocker() function is no longer exported in BDB 4.7. Fortunately we still have the old read-only txn code in CVS. -- -- 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#5468) You can put irrevant thing on LDIF file "add" line
by patrick.ni＠strangeloopnetworks.com 14 Apr '08

14 Apr '08

Full_Name: Patrick Ni Version: 2.3.30-5 OS: Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12etch2) (dannf(a)debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.77.66.100) Hello, I have a group entry for myself "patrick" in the LDAP database as follows: dn: cn=patrick,ou=Group,dc=strangeloop,dc=net objectClass: posixGroup objectClass: top cn: patrick userPassword:: e1NTSEF9eA== gidNumber: 500 memberUid: patrick Recently, I realized I could add my 2nd openLDAP account "dn:uid=patrick2,ou=Accounts,dc=strangeloop,dc=net" into my group "patrick" using the following LDIF file: ldap1:~/ldap# more group2_patrick.ldif dn: cn=patrick,ou=Group,dc=strangeloop,dc=net changetype:modify add:membership memberUid:patrick2 This should not have succeeded because the "add:membership" line is wrong; It should have been "add:memberUid". thanks -Patrick

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ghenry＠OpenLDAP.org 14 Apr '08

14 Apr '08

>> People interested in the overlay are able to download it from >> the maintained location at: >> >> http://techpubs.spinlocksolutions.com/openldap/ > > Well, in that case you have to guarantee that the URL remains valid over > time. If you put it in contrib/ the OpenLDAP project guarantees (sort > of) it remains available. To the average potential user, I guess it's > the same level of guarantee :) > It could also be listed at: http://www.openldap.org/doc/admin24/appendix-contrib.html as it wasn't in contrib format when I wrote this section. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5467) aliases broke on hdb/bdb ?
by h.b.furuseth＠usit.uio.no 13 Apr '08

13 Apr '08

Not a bug. A search which dereferences aliases, checks the filter against the _aliased_ entry, not against the _alias_ entry. So, try ldapsearch -a always uid=wilfinge. -- Hallvard

1 0

(ITS#5467) aliases broke on hdb/bdb ?
by cowboy＠linux.vnet.ibm.com 12 Apr '08

12 Apr '08

Full_Name: Richard Nelson Version: 2.4.7-6.1 (Debian) OS: Linux (Debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.245.249.50) Here's the alias ldif (modelled after the FAQ 1111 entry) $ ldapsearch -a never uid=wilfing dn: uid=wilfing,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com uid: wilfing aliasedObjectName: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com objectClass: alias objectClass: extensibleObject And the aliased entry: $ ldapsearch -a never uid=wilfinge dn # wilfinge, Users, cobpli.svl.ibm.com dn: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com When I try to actually use the alias, it fails: $ ldapsearch -a always uid=wilfing # base <dc=cobpli,dc=svl,dc=ibm,dc=com> (default) with scope subtree # filter: uid=wilfing # requesting: ALL # # search result search: 4 result: 0 Success The logs seemed to imply that, rather than the expect DN replacement and search, that the slapd-hdb actually scanned the entire subtree (curiously missing the alias entry) and returned no data In case it matters, here's the index entry for uid: index uid pres,eq,sub I renamed the alias from 'wilfing' to 'alias' to make sure it wasn't due to the alias being a substring of the true name - but that didn't help either

1 0

(ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 12 Apr '08

12 Apr '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch Submission from: (NULL) (213.41.141.172) This patch adds attribute remapping capability to slapo-dynlist. If you configure it that way: overlay dynlist dynlist-attrset groupOfURLs memberURL bar:foo And if you have an object like this in your directory: dn: cn=list,o=home objectClass: groupOfURLs cn: list memberURL: ldap:///o=home?foo?sub?(objectClass=fooClass) Then searching for cn=list,o=home will display the expantion of the LDAP URI, with foo attributes been displayed as bar.

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Saturday, April 12, 2008 10:14 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > I realized last night that this is likely due to the race condition issue > between syncprov & syncrepl when check pointing the cookie. The > replica's run the syncprov overlay so that we can see the cookie as it's > a glue DB. They also have a check point line. I'll have the checkpoint > line removed on the replicas. Never mind, I was incorrect. The syncprov-checkpoint line is not present on the replicas, only "overlay syncprov", so this isn't it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > So it's clear that the update took on the replica. I restarted slapd, > and it started replicating correctly. So it looks like there's a problem > where internally it thinks it is on a previous cookie to what it has > already committed. I realized last night that this is likely due to the race condition issue between syncprov & syncrepl when check pointing the cookie. The replica's run the syncprov overlay so that we can see the cookie as it's a glue DB. They also have a check point line. I'll have the checkpoint line removed on the replicas. Does this sound correct, as per the note Howard made recently about this issue? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ando＠sys-net.it 12 Apr '08

12 Apr '08

docelic(a)spinlocksolutions.com wrote: > The contrib section does not have usable makefiles (nor the system > to create them). Usually, building a contrib does not require much makefile stuff. > Putting this overlay in contrib, where it would be unmaintained > and practically broken right away from the start (due to missing > build integration) doesn't make any sense. It makes sense: if we integrate it in the mainstream source and it breaks because it's unmaintained, then the distribution is broken > People interested in the overlay are able to download it from > the maintained location at: > > http://techpubs.spinlocksolutions.com/openldap/ Well, in that case you have to guarantee that the URL remains valid over time. If you put it in contrib/ the OpenLDAP project guarantees (sort of) it remains available. To the average potential user, I guess it's the same level of guarantee :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 11 Apr '08

11 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Here are a bunch of back-ldif bugs some questions. I have code for most > of it, but need advice/discussion on functionality changes. > - When back-ldif uses OS-specific escaping, we can't move a directory > tree between Windows and Unix hosts if some RDN in the tree contains > characters with OS-specific escaping. This is never a priority. The only documented way to move databases is via slapcat/slapadd. I'm perfectly fine with a Windows-specific special case that simply maps all forbidden characters to control-characters, or some other equally obscure approach. (E.g. map all forbidden characters to the same character.) The typical Windows admin will never see the raw filenames anyway. -- -- 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#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 11 Apr '08

11 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) I have a replica spitting out the following error in its logs (master and replica running OpenLDAP 2.3.41): Apr 11 13:28:03 123-ldap-3 slapd[21846]: syncrepl_message_to_op: rid 100 be_modify uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu (20) It's syncrepl cookie is: contextCSN: 20080410145621Z#000000#00#000000 Looking at the accesslog on the master, I see (for this time period): dn: reqStart=20080410145621.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000001Z reqEnd: 20080410145621.000003Z reqType: modify reqSession: 190486 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: zimbraPasswordLockoutFailureTime:- 20080410145230Z reqMod: entryCSN:= 20080410145621Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ac9202-9b5a-102c-8816-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z dn: reqStart=20080410145621.000027Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000027Z reqEnd: 20080410145621.000028Z reqType: modify reqSession: 190494 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=yyyy_07,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: entryCSN:= 20080410145621Z#000001#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ee59c6-9b5a-102c-8817-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000001#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z So as I understand (delta)syncrepl, the replica knows it already received the update for uid=xxxxx, and yet it is still trying to process that update, rather than the next one for uid=yyyy_07. The entry on the replica has: dn: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu zimbraPasswordLockoutFailureTime: 20080410145515Z zimbraPasswordLockoutFailureTime: 20080410145516Z zimbraPasswordLockoutFailureTime: 20080410145519Z zimbraPasswordLockoutFailureTime: 20080410145539Z zimbraPasswordLockoutFailureTime: 20080410145547Z zimbraPasswordLockoutFailureTime: 20080410145548Z zimbraPasswordLockoutFailureTime: 20080410145621Z So it's clear that the update took on the replica. I restarted slapd, and it started replicating correctly. So it looks like there's a problem where internally it thinks it is on a previous cookie to what it has already committed. --Quanah

1 0

Re: (ITS#4890) Default Values overlay (patch)
by docelic＠spinlocksolutions.com 11 Apr '08

11 Apr '08

The contrib section does not have usable makefiles (nor the system to create them). Putting this overlay in contrib, where it would be unmaintained and practically broken right away from the start (due to missing build integration) doesn't make any sense. People interested in the overlay are able to download it from the maintained location at: http://techpubs.spinlocksolutions.com/openldap/ Davor Ocelic Spinlock Solutions http://www.spinlocksolutions.com/

1 0

Re: (ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

On Fri, Apr 11, 2008 at 11:34:33AM +0200, Rein Tollevik wrote: > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. OK, we switched to the CVS version (openldap-20080411). The patch is rejected, as You might guess :-) The problem persists more or less, anyway. FYI: Whenever the replication stops, in the provider-log (sync, conns) there is a line: Apr 11 15:30:12 1 slapd[8994]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" I don't know if this is really meaningful. Just for those people not too familiar with CVS: How can I retrieve that very branch, where the hunk in ITS 5454 would succeed? Thank You very much in advance, anyway, and the help in the past! -- Mit freundlichen Gruessen / Yours sincerely Marian Eichholz Postmaster

1 0

Re: (ITS#5463) syncrepl stops or pauses
by hyc＠symas.com 11 Apr '08

11 Apr '08

rein(a)basefarm.no wrote: > marian.eichholz(a)freenet.ag skrev: >> Full_Name: >> Version: 2.4.8 >> OS: Linux 2.6.23.13 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.97.7.65) >> >> The replication may suddenly stop, and we see no reason for that. Sometimes it >> recovers by itself, sometimes it recovers only when the consumer slapd is >> stopped and restarted. >> Is there a "golden path" to debug this issue? > > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. > > An alternative version is implemented in the CVS head release, but that > lacks a change from trylock to real mutex lock before the race condition > is fully closed. > > We experienced a lot of replication problems after upgrading from a > slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are > currently using the CVS head version (as it was about a week ago), and > most of our problems has been solved there :-) You should consider the > cvs version, as it has many syncrepl and syncprov fixes. At this point it would be better to test RE24, not 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#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> OK, reverted the trylock (which was put there in rev 1.376). I >> unfortunately don't remember what prompted that commit; certainly >> there was no ITS associated with it. > > It was committed 9 minutes before this message: > http://www.openldap.org/lists/openldap-devel/200802/msg00032.html > Thanks for that reference. test050 is fine right now; I think rev 1.381 was the more correct fix for that problem. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by h.b.furuseth＠usit.uio.no 11 Apr '08

11 Apr '08

hyc(a)symas.com writes: > OK, reverted the trylock (which was put there in rev 1.376). I > unfortunately don't remember what prompted that commit; certainly > there was no ITS associated with it. It was committed 9 minutes before this message: http://www.openldap.org/lists/openldap-devel/200802/msg00032.html -- Hallvard

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

hyc(a)symas.com wrote: >>> It also occurs to me that we probably don't even need to manipulate the >>> slapd runqueue in persist mode, when si->si_conn is already set. I.e., >>> in that case we can only have gotten here because of a listener event, >>> and not because of a runqueue schedule. >> That is probably true. > > Right, my patch avoids that now. Having looked at it again I think replacing > the trylock with a regular lock is fine. OK, reverted the trylock (which was put there in rev 1.376). I unfortunately don't remember what prompted that commit; certainly there was no ITS associated with it. -- -- 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#5463) syncrepl stops or pauses
by rein＠basefarm.no 11 Apr '08

11 Apr '08

marian.eichholz(a)freenet.ag skrev: > Full_Name: > Version: 2.4.8 > OS: Linux 2.6.23.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > The replication may suddenly stop, and we see no reason for that. Sometimes it > recovers by itself, sometimes it recovers only when the consumer slapd is > stopped and restarted. > Is there a "golden path" to debug this issue? This sounds a lot like the problems we had, see ITS#5454. Replication has been running smootly since we implemented the patch included there. An alternative version is implemented in the CVS head release, but that lacks a change from trylock to real mutex lock before the race condition is fully closed. We experienced a lot of replication problems after upgrading from a slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are currently using the CVS head version (as it was about a week ago), and most of our problems has been solved there :-) You should consider the cvs version, as it has many syncrepl and syncprov fixes. -- Rein Tollevik Basefarm AS

1 0

(ITS#5464) ucred guarded by __USE_GNU in glibc 2.8
by rhafer＠suse.de 11 Apr '08

11 Apr '08

Full_Name: Ralf Haferkamp Version: Any OS: Linux (glibc 2.8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.17) Newer glibc Version guards the definition of struct ucred (e.g. used in liblutil/getpeereid.c) by __USE_GNU, hence it is only available when _GNU_SOURCE is defined. The matching glibc changelog only say "Cleanup namespace.". Here's the diff: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/…

1 0

(ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

Full_Name: Version: 2.4.8 OS: Linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Were still migrating von slurpd to syncrepl. We have a 2.3-slurpd-fed provider under OpenLDAP 2.4.8 used by currently two OpenLDAP 2.4.8 consumers with "refreshAndPersist" and a retry-interval of "180 +" (see below) The database is fairly large (8 Mio objects, 15 GB BDB files) and the consumers have a syncrepled database (pulled once, then cloned). There are ongoing updates "each second". We see two issues: When a consumer (re-) connects, the replication for the running consumer pauses until it continues on both nodes. This could become a problem, where a single consumer can be a SPOF for the whole cluster. The replication may suddenly stop, and we see no reason for that. Sometimes it recovers by itself, sometimes it recovers only when the consumer slapd is stopped and restarted. Is there a "golden path" to debug this issue? For the logs: We have "sync" as log level. Consumer 1 (rid 000) [...] Apr 10 16:15:18 0 slapd[27548]: connection_input: conn=192 deferring operation: binding [...] Apr 11 08:45:21 0 slapd[27548]: connection_input: conn=5182 deferring operation: binding Apr 11 08:50:11 0 slapd[27548]: connection_input: conn=5207 deferring operation: binding Apr 11 08:51:09 0 slapd[27548]: connection_input: conn=5212 deferring operation: binding Apr 11 08:53:05 0 slapd[27548]: connection_input: conn=5222 deferring operation: binding Apr 11 08:54:03 0 slapd[27548]: connection_input: conn=5228 deferring operation: binding Consumer 2 (rid 002): [...] Apr 11 02:00:16 2 slapd[22272]: connection_input: conn=3151 deferring operation: binding [...] Apr 11 08:52:09 2 slapd[22272]: connection_input: conn=5224 deferring operation: binding Apr 11 08:53:07 2 slapd[22272]: connection_input: conn=5229 deferring operation: binding Provider (filtered for last syncprov_sendresp entries per rid) Apr 10 16:06:43 1 slapd[27917]: syncprov_sendresp: cookie=rid=000,csn=2008041014 0643.069039Z#000000#000#000000 Apr 11 01:57:58 1 slapd[27917]: syncprov_sendresp: cookie=rid=002,csn=2008041023 5758.696324Z#000000#000#000000 I see no indicators for failing operations, missing resources or any other trouble, incept for the "connection_input" entries. Any idea how to get sync replication running smoothly and reliably? Thank You very much in advance, of course! OK, here are configuraiton snippets for provider and consumer, if it helps. To be honest: I am not quite shure about a reasonable size for syncprov-sessionlog, even after reading the slapo-syncprov. The actual number is meant as "big, but finite". Consumer: --------- syncrepl rid=2 provider="ldap://provider:389" type=refreshAndPersist bindmethod=simple binddn=... credentials=... searchbase=... retry="180 +" provider: --------- database bdb dbnosync cachesize 200000 suffix ... rootdn ... updatedn ... rootpw ... directory /var/ldap/db lastmod on index objectClass eq ... index entryCSN,entryUUID eq checkpoint 512 15 overlay syncprov syncprov-sessionlog 300000 database monitor

1 0

(ITS#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 10 Apr '08

10 Apr '08

Full_Name: Peter O'Gorman Version: 2.4.8 OS: multiple URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch Submission from: (NULL) (24.76.165.223) gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows the conf file option to work when building openldap with gnutls on systems that do not have a /dev/random.

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠tollevik.no 10 Apr '08

10 Apr '08

On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). > I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. > (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if > and only if rs.sr_entry->e_private != NULL. Which is possibly true with > back-bdb but seems a shaky assumption in general.) Almost, except that it triggers an abort.. Using be_entry_release_r() was not correct, as it ended up calling entry_free(). It works if I changes it to use overlay_entry_release_ov() instead, as in the alternative patch at the end. I have put a test script that shows this deadlock on: ftp://ftp.openldap.org/incoming/test053-syncprov-glue It deadlocks without this patch, it and the rest of the test suite succeed with it :-) I haven't tested it in production though.. Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.14 OpenLDAP/servers/slapd/overlays/syncprov.c:1.14 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.14 Thu Apr 10 17:31:24 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Thu Apr 10 17:34:36 2008 @@ -2389,7 +2396,14 @@ if ( !ap ) { if ( !(rs->sr_flags & REP_ENTRY_MODIFIABLE) ) { - rs->sr_entry = entry_dup( rs->sr_entry ); + Entry *new = entry_dup( rs->sr_entry ); + if ( rs->sr_flags & REP_ENTRY_MUSTRELEASE ) { + overlay_entry_release_ov( op, rs->sr_entry, 0, (slap_overinst *)op->o_bd->bd_info ); + rs->sr_flags ^= REP_ENTRY_MUSTRELEASE; + } else if ( rs->sr_flags & REP_ENTRY_MUSTBEFREED ) { + entry_free( rs->sr_entry ); + } + rs->sr_entry = new; rs->sr_flags |= REP_ENTRY_MODIFIABLE|REP_ENTRY_MUSTBEFREED; a = attr_find( rs->sr_entry->e_attrs,

1 0

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

10 Apr '08

Howard Chu writes: > I have the feeling that MUSTBEFREED and MUSTRELEASE should be > consolidated into a single flag. be_entry_release_r() should simply > call entry_free() if e->e_private is NULL. Maybe. But consider translucent - it grabs incoming entries and remembers them. It can "steal" a MUSTBEFREED entry (though it doesn't now), but must duplicate a MUSTRELEASE entry so that it won't hold on to a lock in an underlying database. -- Hallvard

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

Howard Chu writes: > h.b.furuseth(a)usit.uio.no wrote: >> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). >> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. >> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if >> and only if rs.sr_entry->e_private != NULL. Which is possibly true with >> back-bdb but seems a shaky assumption in general.) > > That is a requirement, yes. If you implement a backend that has > cache/locking constraints on its entries and you don't provide a > pointer from the entry back to your cache state, then you're an idiot. OTOH you can send an entry without setting MUSTRELEASE, and release it after sending instead. In particular if you didn't about the undocumented sr_flags and their purpose. Or if you don't use be_release for unlocking but just to clean up e_private. ... have I gone blind? I don't see back-bdb setting that flag. Did I just read ITS#3671 and trust it to have updated bdb? -- Hallvard

1 0

Re: (ITS#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 10 Apr '08

10 Apr '08

> Is this entry still in your database now? Clearly this condition should never > happen - if zero-length values are valid for the syntax, then it should have > been preserved in the (normalized) a_nvals. If not, then it should not have > been in the a_vals in the first place. No, it got deleted last night. But from the core I see: at_syntax_oid = 0x100495d80 "1.3.6.1.4.1.1466.115.121.1.26" IA5String, so empty string is valid. (And makes no logical sense in this situation, but that's for another day...)

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by hyc＠symas.com 10 Apr '08

10 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > - REP_ENTRY_MUSTRELEASE and REP_ENTRY_MUSTBEFREED: > > Callers that set these flags when sending an entry, *allow* the > callee to release/free rs->sr_entry. > Callers cannot depend on it being release/freed, but some do anyway. > > It should simplify things to make the send functions always obey > this flag, but I'm not sure how much cleanup that requires. > There is partial code for that in slap_send_search_entry(), along > with a FIXME note. > > Free MUSTBEFREED-entries with entry_free(), and MUSTRELEASE-entries > with be_entry_release_r(). There is no "use be_entry_release_w()" > flag, but no OpenLDAP code sends write-locked entries anyway. I have the feeling that MUSTBEFREED and MUSTRELEASE should be consolidated into a single flag. be_entry_release_r() should simply call entry_free() if e->e_private is NULL. > + REP_ENTRY_MUSTRELEASE: > > Created for ITS#3671 to ensure that network hangs don't delay > cache entry unlocks: > > Modules should release their cache entry locks before sending > anything. They can't do that with cached entries they send in > rs->sr_entry, so instead they should set REP_ENTRY_MUSTRELEASE. > Conversely, anything which does network I/O (and other potentially > slooow ops I guess) should first obey this flag. > > Several overlays don't obey, nor some other code for sending an > entry when it decides to send an error response instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by hyc＠symas.com 10 Apr '08

10 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). > I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. > (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if > and only if rs.sr_entry->e_private != NULL. Which is possibly true with > back-bdb but seems a shaky assumption in general.) That is a requirement, yes. If you implement a backend that has cache/locking constraints on its entries and you don't provide a pointer from the entry back to your cache state, then you're an idiot. That means every time you want to manipulate the cache state for that entry you'll have to do an expensive search for it, instead of simply dereferencing e_private. If you maintain private state for the entry, you point to it with e_private. If e_private is not set, then there is no private state. -- -- 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#5459) threw assertion in attr_dup
by hyc＠symas.com 10 Apr '08

10 Apr '08

Aaron Richton wrote: > Ergh, didn't realize there was more past that. > > (dbx) print a->a_vals[0] > a->a_vals[0] = { > bv_len = 28U > bv_val = 0x11925f250 "fixed-address 172.16.143.152" > } > (dbx) print a->a_vals[1] > a->a_vals[1] = { > bv_len = 0 > bv_val = 0x117e9a810 "" > } > (dbx) print a->a_vals[2] > a->a_vals[2] = { > bv_len = 0 > bv_val = (nil) > } > (dbx) print a->a_nvals[0] > a->a_nvals[0] = { > bv_len = 28U > bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" > } > (dbx) print a->a_nvals[1] > a->a_nvals[1] = { > bv_len = 0 > bv_val = (nil) > } > Is this entry still in your database now? Clearly this condition should never happen - if zero-length values are valid for the syntax, then it should have been preserved in the (normalized) a_nvals. If not, then it should not have been in the a_vals in the first place. -- -- 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#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 10 Apr '08

10 Apr '08

Ergh, didn't realize there was more past that. (dbx) print a->a_vals[0] a->a_vals[0] = { bv_len = 28U bv_val = 0x11925f250 "fixed-address 172.16.143.152" } (dbx) print a->a_vals[1] a->a_vals[1] = { bv_len = 0 bv_val = 0x117e9a810 "" } (dbx) print a->a_vals[2] a->a_vals[2] = { bv_len = 0 bv_val = (nil) } (dbx) print a->a_nvals[0] a->a_nvals[0] = { bv_len = 28U bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" } (dbx) print a->a_nvals[1] a->a_nvals[1] = { bv_len = 0 bv_val = (nil) }

1 0

Re: (ITS#5459) threw assertion in attr_dup
by hyc＠symas.com 10 Apr '08

10 Apr '08

Aaron Richton wrote: >> Definitely an oddball. Can you print i, j, and a->a_vals[0] thru >> a->a_vals[i], >> plus a->a_nvals[0] thru a->a_nvals[j]. > > Just got back to my desk and started looking at this. So when the two > slaves that threw this were restarted, they went into an infinite loop > trying to replicate the entry that killed them: > > <= entry_decode: slap_str2undef_ad(^Zethernet 01:aa:aa:aa:aa:a1): AttributeDescription contains inappropriate characters > null_callback: error code 0x50 > syncrepl_entry: rid 110 be_add (80) > syncrepl_entry: rid 110 be_add failed (80) > do_syncrepl: rid 110 retrying > > and retrying, and retrying, and retrying...hence my thought that > the database was hosed...UNTIL... > > Apparently the entry was DEL'd a few hours later. I've now got perfect > sync from the master to the assert'd slaves. The entry_decode error definitely implies a corruption somewhere. It was looking at a 26 byte value as if it was the name of an attribute. I wonder if slapcat will run cleanly on it now, or if it will also encounter some decode errors. -- -- 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#5457) bdb_add() does not always release entries
by hyc＠symas.com 10 Apr '08

10 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p ); >>> (...) >> Releasing entries is somewhat irrelevant, since all locks are released when >> the transaction commits. Note that this function is a no-op in proto-bdb.h. >> All of those statements are just relics from the first entry cache design, >> before we switched to using BDB locks for everything. > > OK. Does that apply to bdb_cache_return_entry_r( bdb, oe,&lock ); > after > bdb_cache_add( bdb, ei, op->ora_e,&nrdn, rlocker,&lock ); > failed TXN_COMMIT( ltid, 0 ); > too? bdb_cache_return_entry_r() is not a no-op. No, that call obviously matters. But I'm not sure that this commit can ever actually fail, or what to do about it if it does. Since all of these write ops use a nested transaction, and there is nothing outstanding in the outer transaction, and the inner transaction has already committed successfully, the only thing that could cause the outer commit to fail would be something like running out of disk for the transaction log. -- -- 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#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 10 Apr '08

10 Apr '08

> Definitely an oddball. Can you print i, j, and a->a_vals[0] thru > a->a_vals[i], > plus a->a_nvals[0] thru a->a_nvals[j]. Just got back to my desk and started looking at this. So when the two slaves that threw this were restarted, they went into an infinite loop trying to replicate the entry that killed them: <= entry_decode: slap_str2undef_ad(^Zethernet 01:aa:aa:aa:aa:a1): AttributeDescription contains inappropriate characters null_callback: error code 0x50 syncrepl_entry: rid 110 be_add (80) syncrepl_entry: rid 110 be_add failed (80) do_syncrepl: rid 110 retrying and retrying, and retrying, and retrying...hence my thought that the database was hosed...UNTIL... Apparently the entry was DEL'd a few hours later. I've now got perfect sync from the master to the assert'd slaves. There's nothing secret in this particular backend; it's DHCP backing store, so I can give you full values. Both slaves died with an identical: i = 2 j = 1 *a->a_vals = { bv_len = 28U bv_val = 0x11925f250 "fixed-address 172.16.143.152" } *a->a_nvals = { bv_len = 28U bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" }

1 0

Re: (ITS#5459) threw assertion in attr_dup
by hyc＠symas.com 10 Apr '08

10 Apr '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.41 > OS: Solaris 9 > URL: > Submission from: (NULL) (68.192.238.168) > Crazy part is that I hit this on two slaves during the same replication cycle > ... yet four slaves DIDN'T crash during said replication set. I think that > database is hosed on those two slaves; I'll check more thoroughly tomorrow (I'm > off site today). Provider is 2.3.39, so perhaps "it fed 2.3.41 garbage" -- but > still, 2.3.41 should be able to gracefully handle it? Or maybe an assert() is a > graceful handler, but I don't know about that, it kills my slave in the process? Definitely an oddball. Can you print i, j, and a->a_vals[0] thru a->a_vals[i], plus a->a_nvals[0] thru a->a_nvals[j]. -- -- 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#5461) rs->sr_tag/sr_msgid uninitialized at abandon
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slap_send_ldap_result() does not initialize rs->sr_tag and rs->sr_msgid if rs->sr_err == SLAPD_ABANDON || op->o_abandon. It does call send_ldap_response() which calls slap_cleanup_play(). Some cleanup handlers dispatch on rs->sr_tag. If this is deliberate, it's a design bug: Any cleanup callbacks that depend on this suffer at least a race condition, since o_abandon could get set just after slap_send_ldap_result checks for abandon. The code is from slapd/result.c rev 1.252. The fix should be to first check that the cleanup callbacks handle abandon properly, then always initialize these SlapResponse fields.

1 0

Re: (ITS#5458) whitespace parsing in schema files
by mf＠14v.de 10 Apr '08

10 Apr '08

--On Donnerstag, April 10, 2008 11:29:13 +0200 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > Not a bug. The 'attributetype' format is contained inside the > slapd.conf format. The slapd.conf format is that each directive is > written in one conceptual line: one line plus any additional slapd.conf > continuation lines - i.e. lines which start with whitespace. Ok, thanks for replying, bug can be closed (if it isn't already). That was my fault, I had simply assumed from looking at the other schema files that schema definitions were in some context-free grammar like C or Pascal. The log message containing input from an earlier schema include is still somewhat confusing. Best regards Matthias Ferdinand

1 0

Re: (ITS#5458) whitespace parsing in schema files
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

mf(a)14v.de writes: > attributetype ( 1.3.6.1.4.1.22558.2.1.1 > NAME 'o4vdescription' > DESC 'RFC2256: descriptive information' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} > ) > > If I leave out the blank preceding the closing paranthesis, so that > there is just the newline between the "{1024}" and the ")", slapd > refuses to start Not a bug. The 'attributetype' format is contained inside the slapd.conf format. The slapd.conf format is that each directive is written in one conceptual line: one line plus any additional slapd.conf continuation lines - i.e. lines which start with whitespace. Though if the documentation is unclear on this point, feel free to suggest how to improve it. -- Hallvard

1 0

(ITS#5460) unresolved symbol
by st-wong＠cuhk.edu.hk 10 Apr '08

10 Apr '08

Full_Name: ST Wong Version: 2.4.8 OS: CentOS 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.189.29.184) Got error when compiling Openldap 2.4.8 with BerkeleyDB 4.6: ---------------------- cut here ----------------------- ... checking for db.h... yes checking for Berkeley DB major version... 4 checking for Berkeley DB minor version... 3 checking for Berkeley DB link (-ldb-4.3)... (cached) no checking for Berkeley DB link (-ldb43)... no checking for Berkeley DB link (-ldb-43)... no checking for Berkeley DB link (-ldb-4-3)... no checking for Berkeley DB link (-ldb-4)... no checking for Berkeley DB link (-ldb4)... no checking for Berkeley DB link (-ldb)... yes checking for Berkeley DB version match... yes checking for Berkeley DB thread support... yes checking Berkeley DB version for BDB/HDB backends... no configure: error: BDB/HDB: BerkeleyDB version incompatible ---------------------- cut here ----------------------- In config.log: ---------------------- cut here ----------------------- configure:17625: checking for resolver link (default) configure:17691: cc -o conftest -g -O2 -I/usr/local/BerkeleyDB.4.6/include -L/usr/local/BerkeleyDB.4.6/lib conftest.c >&5 /tmp/ccczbyKW.o: In function `main': /usr/local/src/openldap-2.4.8/conftest.c:113: undefined reference to `__res_query' /usr/local/src/openldap-2.4.8/conftest.c:132: undefined reference to `__dn_expand' collect2: ld returned 1 exit status ---------------------- cut here ----------------------- Have to add "-lresolv" to LDFLAGS in order to resolve the problem. I suppose configure will add all libraries required. Thanks a lot.

1 0

(ITS#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 09 Apr '08

09 Apr '08

Full_Name: Aaron Richton Version: 2.3.41 OS: Solaris 9 URL: Submission from: (NULL) (68.192.238.168) (dbx) where current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff457fe390, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x30, 0x0, 0x30, 0x7efefeff, 0x81010100, 0xff0000), at 0xffffffff7f03e688 [4] __assert(0x10023d488, 0x10023d490, 0x8d, 0x1, 0xffffffff457fe758, 0x11b369c59), at 0xffffffff7f03e98c =>[5] attr_dup(a = 0x1174b0470), line 141 in "attr.c" [6] attrs_dup(a = 0x1174b0470), line 166 in "attr.c" [7] hdb_modify_internal(op = 0xffffffff457ff618, tid = 0x11b369b70, modlist = 0x118ea8bd0, e = 0xffffffff457feab8, text = 0xffffffff457fefd8, textbuf = 0xffffffff457feb4c "^X\xea\x8b\xd0", textlen = 256U), line 55 in "modify.c" [8] hdb_modify(op = 0xffffffff457ff618, rs = 0xffffffff457fefb8), line 480 in "modify.c" [9] syncrepl_entry(si = 0x1004b5050, op = 0xffffffff457ff618, entry = 0x118d17870, modlist = 0xffffffff457ff328, syncstate = 2, syncUUID = 0xffffffff457ff3c0, syncCookie_req = 0xffffffff457ff360, syncCSN = 0xffffffff457ff390), line 1987 in "syncrepl.c" [10] do_syncrep2(op = 0xffffffff457ff618, si = 0x1004b5050), line 735 in "syncrepl.c" [11] do_syncrepl(ctx = 0xffffffff457ffc30, arg = 0x1004b5230), line 1095 in "syncrepl.c" [12] ldap_int_thread_pool_wrapper(xpool = 0x10041e700), line 478 in "tpool.c" (dbx) list 130,150 130 131 if ( a->a_nvals != a->a_vals ) { 132 int j; 133 134 tmp->a_nvals = ch_malloc( (i + 1) * sizeof(struct berval) ); 135 for ( j = 0; !BER_BVISNULL( &a->a_nvals[j] ); j++ ) { 136 assert( j < i ); 137 ber_dupbv( &tmp->a_nvals[j], &a->a_nvals[j] ); 138 if ( BER_BVISNULL( &tmp->a_nvals[j] ) ) break; 139 /* FIXME: error? */ 140 } 141 assert( j == i ); 142 BER_BVZERO( &tmp->a_nvals[j] ); 143 144 } else { 145 tmp->a_nvals = tmp->a_vals; 146 } 147 148 } else { 149 tmp->a_vals = NULL; 150 tmp->a_nvals = NULL; Crazy part is that I hit this on two slaves during the same replication cycle ... yet four slaves DIDN'T crash during said replication set. I think that database is hosed on those two slaves; I'll check more thoroughly tomorrow (I'm off site today). Provider is 2.3.39, so perhaps "it fed 2.3.41 garbage" -- but still, 2.3.41 should be able to gracefully handle it? Or maybe an assert() is a graceful handler, but I don't know about that, it kills my slave in the process?

1 0

(ITS#5458)
by mf＠14v.de 09 Apr '08

09 Apr '08

Looks like newline does not count as whitespace. Regards Matthias

1 0

(ITS#5458) whitespace parsing in schema files
by mf＠14v.de 09 Apr '08

09 Apr '08

Full_Name: Matthias Ferdinand Version: 2.4.8 OS: Linux/SuSE10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.102.180.118) Platform: SuSE Linux 10.0 OpenLDAP 2.4.8 from pkgsrc (http://www.netbsd.org/docs/pkgsrc/) gcc-4.2.1 (also with OpenLDAP 2.4.7 from Debian Testing) I tried the following simple attribute definition (located at /opt/pkgsrc/etc/openldap/schema/test2.schema): attributetype ( 1.3.6.1.4.1.22558.2.1.1 NAME 'o4vdescription' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) If I leave out the blank preceding the closing paranthesis, so that there is just the newline between the "{1024}" and the ")", slapd refuses to start with some syntax error: AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType ... and at loglevel 64 some strange syslog entries: Apr 10 00:45:08 vestatest slapd[25297]: line 6 (attributetype ( 1.3.6.1.4.1.22558.2.1.1 NAME 'o4vdescription' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}) Apr 10 00:45:08 vestatest slapd[25297]: /opt/pkgsrc/etc/openldap/schema/test2.schema: line 6 attributetype: Missing closing parenthesis before amavisBannedFilesLover $ amavisBypassBannedChecks $ amavisBadHeaderLover $ amavisBypassHeaderChecks $ amavisSpamTagLevel $ amavisSpamTag2Level $ amavisSpamKillLevel $ amavisWhiteli Apr 10 00:45:08 vestatest slapd[25297]: /opt/pkgsrc/etc/openldap/slapd.conf: line 13: <include> handler exited with 1! (the amavis entries are from a schema included just before this one) Looks like the parser reads the attribute definition correctly, but is confused afterwards. Regards Matthias

1 0

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

09 Apr '08

Below I'll summarize SlapReply.sr_flags as I now understand it after un-confusing myself a little, since this ITS is getting rather long. Mostly about how code which receives a filled SlapReply should use it, which I presume is primarily overlays, slap_callbacks, maybe back-relay. About discussion so far: The sr_flags are inconsistent about when which ones may or must be obeyed. E.g. REP_ENTRY_MUST<RELEASE/BEFREED> does not mean the entry will be released/freed, but REP_<MATCHED/REF> does in some functions. This needs to be normalized. We can state that overlays with a bi_entry_release_rw function must keep track of which module should release which entry, like glue does. At least for now. Never mind my worries about which overlay/backend should release an REP_ENTRY_MUSTRELEASE'd sr_entry. That doesn't matter with current OpenLDAP code. As far as I can see glue is the only overlay with a release function, and glue can dispatch on the entry DN. rs.sr_ref bugs, fixing now: - slap_send_ldap_result() forgets to free rs->sr_ref if it does not call send_ldap_response(). - send_ldap_response() can return with sr_ref set to a freed value. I'll make it return with sr_ref to NULL if REP_REF_MUSTBEFREED. ando(a)sys-net.it writes: > Similarly, the existence of REP_ENTRY_MUSTBEFREED is not totally clear: Looked a bit at cvs logs... Since you are the one who introduced MUSTBEFREED and MODIFIABLE (slap.h 1.503 for rwm) I think we can take it the intent of REP_ENTRY_MUSTBEFREED is indeed unclear/forgotten:-) Anyway, I think I've gotten the flags straight now: * REP_<ENTRY, MATCHED, REF>_MUST<RELEASE, BEFREED>: Overlays/callbacks may modify the rs->sr_<entry, text, ref> pointers. If they do, they must release/free the old value if and only if the corresponding MUST<RELEASE/BEFREED> flag is set. They should (re)set the relevant flags to describe the new value. Many overlays don't, or not thoroughly enough. - REP_<MATCHED, REF>_MUSTBEFREED: Callers setting these can depend on send_ldap_response() to free sr_<matched, ref>. That is, "send response/disconnect" calls. These flags do apparently not apply and should not be set when sending an entry or search continuation reference. Dunno why not REP_REF_MUSTBEFREED when sending continuation references. - REP_ENTRY_MUSTRELEASE and REP_ENTRY_MUSTBEFREED: Callers that set these flags when sending an entry, *allow* the callee to release/free rs->sr_entry. Callers cannot depend on it being release/freed, but some do anyway. It should simplify things to make the send functions always obey this flag, but I'm not sure how much cleanup that requires. There is partial code for that in slap_send_search_entry(), along with a FIXME note. Free MUSTBEFREED-entries with entry_free(), and MUSTRELEASE-entries with be_entry_release_r(). There is no "use be_entry_release_w()" flag, but no OpenLDAP code sends write-locked entries anyway. + REP_ENTRY_MUSTRELEASE: Created for ITS#3671 to ensure that network hangs don't delay cache entry unlocks: Modules should release their cache entry locks before sending anything. They can't do that with cached entries they send in rs->sr_entry, so instead they should set REP_ENTRY_MUSTRELEASE. Conversely, anything which does network I/O (and other potentially slooow ops I guess) should first obey this flag. Several overlays don't obey, nor some other code for sending an entry when it decides to send an error response instead. * REP_ENTRY_MODIFIABLE: Overlays and callbacks may modify the entry which rs->sr_entry points at if this flag is set. If they want to modify an incoming sr_entry when REP_ENTRY_MODIFIABLE is not set, they can use entry_dup(), release or free the old entry if sr_flags says so, put the new entry in sr_entry, and maybe set REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED. Thus code which creates a temporary Entry struct and sends it as rs->sr_entry, should set REP_ENTRY_MODIFIABLE if the entry is of no further interest to it (and it has set no pointers into it, e.g. rs->sr_matched). That allows overlays that wish to modify the entry being sent, to use this entry instead of copying it. * REP_NO_<OPERATIONALS, ENTRYDN, SUBSCHEMA>: Set by the chain overlay to "tell the frontend not to add generated operational attributes". Only backend.c reacts to these flags. Dunno if overlays should reset these flags when replacing sr_entry with a "private" entry (with another DN) rather than a dup of the current one, or something. Some overlays set sr_flags to fresh values while others only update some bits in sr_flags, so the effect is likely somewhat ad-hoc. Leaving that worry to someone else. I've been fiddling with some functions to generalize this, but they seem to need a lot of flags or variants for different modes... Should maybe just commit some draft variants with warnings that they may change, and clean up later. After my changes don't cause slapd to crash, anyway:-) -- Hallvard

1 0

Re: (ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 09 Apr '08

09 Apr '08

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> - back-ldif escapes the directory separator as \<hex value>. But >> Windows uses "\" as directory separator, so that doesn't help. It >> needs another escape character. >> >> To avoid double hex-escaping of DNs that contain "\", we can pick >> another escape char, e.g. "^", escape that too, and translate "\" to >> it. Thus DN "cn=x^y\2Cz" gets filename "cn=x^5Ey^2Cz.ldif". > > That sounds fine. Is there any reason not to use %, which is already > used for URL encoding? Good point. The filenames I suggested will not be valid URLs but will resemble them, but that can be fixed by using proper URL-encoding of RDNs. Filenames for RDNs with \ in them get a bit longer though. >> - More characters should likely be hex-escaped: >> + ":" (as in "C:\") and "/" on Windows? I've seen programs use the >> latter as directory separator even on Windows. Others? >> + 8-bit chars in case the OS gets clever about charset handling. >> + Control chars. >> >> I don't use Windows myself though. Nor Mac... > > Again, the rules for URL encoding probably already cover any cases we > should worry about. I don't think so. At least "/" is not "unsafe", if I read it right. >> - RDNs ending with ".ldif" should be escaped. Currently "cn=foo.ldif" >> is the name of both RDN "cn=foo"'s entry file and RDN "cn=foo.ldif"'s >> non-leaf directory. > > Perhaps we should escape '.' Hm, true. "." is (was?) a special character on some filesystems. E.g. a file can only have one of them, or the 2nd is followed by a version number. >> - Sorted-value RDNs: No reply? :-) Ok, sort order can be adjusted separately anyway. One error in my previous attempt: bconfig.c mentions "pseudo-indexed" entries (cn=Include{xx}, cn=Module{xx}) which I presume must be sorted by {xx} too, so back-ldif can't treat only "attr={number}val" as indexed. I guess I'll either check both variants or allow {number} anywhere, depending on convenience. -- Hallvard

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 09 Apr '08

09 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23, RE24 > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/back-ldif.c > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Here are a bunch of back-ldif bugs some questions. I have code for most > of it, but need advice/discussion on functionality changes. > > I've been sitting on it too long and would keep sitting if I waited > until I'd cleaned up everything, so, posting now instead. I enclose an > URL for a *draft* back-ldif/ldif.c. > > > Functionality changes. > > * Some LDIF files/directories with special chars need to be renamed: > > RE24 or RE25 change? If anyone uses back-ldif as a regular database, > they may need to slapcat/slapadd to upgrade past these changes. > > - back-ldif escapes the directory separator as \<hex value>. But > Windows uses "\" as directory separator, so that doesn't help. It > needs another escape character. > > To avoid double hex-escaping of DNs that contain "\", we can pick > another escape char, e.g. "^", escape that too, and translate "\" to > it. Thus DN "cn=x^y\2Cz" gets filename "cn=x^5Ey^2Cz.ldif". That sounds fine. Is there any reason not to use %, which is already used for URL encoding? > - More characters should likely be hex-escaped: > + ":" (as in "C:\") and "/" on Windows? I've seen programs use the > latter as directory separator even on Windows. Others? > + 8-bit chars in case the OS gets clever about charset handling. > + Control chars. > > I don't use Windows myself though. Nor Mac... Again, the rules for URL encoding probably already cover any cases we should worry about. > > - When back-ldif uses OS-specific escaping, we can't move a directory > tree between Windows and Unix hosts if some RDN in the tree contains > characters with OS-specific escaping. > > Should we special-case both Unix' and Windows' directory separators > on both OSes? Then instead there will be more directory trees which > can't be move between OpenLDAP versions, before and after the > change. Assuming anyone uses back-ldif in the first place:-) Might as well break it all at once. > > - The database suffix must be hex-escaped like the rest of the > filenames. > > - RDNs ending with ".ldif" should be escaped. Currently "cn=foo.ldif" > is the name of both RDN "cn=foo"'s entry file and RDN "cn=foo.ldif"'s > non-leaf directory. Perhaps we should escape '.' > > - Sorted-value RDNs: > > + In dn2path() when IX_FSL != IX_DNL (filename '{' != RDN '{'): > IX_FS[LR] must be hex-escaped. They are treated as equivalent to > '{' - '}', thus different RDNs can map to the same filename. > > The "{1}" in path "/foo/cn=x{,cn={1}y" is not recognized. > The IX_DN[LR] (i.e. '{', '}') to IX_FS[LR] translation is a bit > strange: It translates the first '{' it sees, then the next > '}', then the next '{', etc. Any reason not to just translate > all '{' and '}' chars? If so, we should at least reset at > each filename and '+'. > > + Sorting (in ldif_r_enum_tree()): > > Should "a={1}x" sort before or after "a=x"? Currently it sorts > like "a={". "a=" (normally before) or "a=<CHAR_MAX>" (normally > after) would be better. > > RDN "attr=foo{bar}baz" is treated as a sorted value. Can easily > check for '={'<successful strtol parse'> '}' instead. > "attr={0<octal>}val" and "attr={0x<hex>}val" are recognized as > sorted values, should they be? > > Some of this is from ITS#4627 (back-ldif issues). -- -- 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#5457) bdb_add() does not always release entries
by h.b.furuseth＠usit.uio.no 09 Apr '08

09 Apr '08

hyc(a)symas.com writes: >> bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p ); >> (...) > Releasing entries is somewhat irrelevant, since all locks are released when > the transaction commits. Note that this function is a no-op in proto-bdb.h. > All of those statements are just relics from the first entry cache design, > before we switched to using BDB locks for everything. OK. Does that apply to bdb_cache_return_entry_r( bdb, oe, &lock ); after bdb_cache_add( bdb, ei, op->ora_e, &nrdn, rlocker, &lock ); failed TXN_COMMIT( ltid, 0 ); too? bdb_cache_return_entry_r() is not a no-op. -- Hallvard

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠tollevik.no 09 Apr '08

09 Apr '08

On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). > I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. > (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if > and only if rs.sr_entry->e_private != NULL. Which is possibly true with > back-bdb but seems a shaky assumption in general.) I have found out how to reliably reproduce this bug in our master server, and it definitely involves syncprov. I'm now working on reproducing it in a minimalistic test configuration, I'll try your patch there and report back. Rein

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by hyc＠symas.com 09 Apr '08

09 Apr '08

quanah(a)zimbra.com wrote: > --On Friday, April 04, 2008 1:23 PM +0200 Hallvard B Furuseth > <h.b.furuseth(a)usit.uio.no> wrote: > >> Since it crashes on >> if ( so->s_op->o_connid == op->o_connid&& >> so->s_op->o_msgid == op->orn_msgid ) >> please try >> frame 0 >> print *op >> print *so->s_op >> and maybe >> backtrace full >> while you are at it. So far there don't appear to be any invalid pointers anywhere, so there's no clue why you hit a SEGV here. Can you reproduce this situation using valgrind? -- -- 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#5451) syncprov_checkpoint deadlock bugfix?
by h.b.furuseth＠usit.uio.no 09 Apr '08

09 Apr '08

Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if and only if rs.sr_entry->e_private != NULL. Which is possibly true with back-bdb but seems a shaky assumption in general.) Index: syncprov.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.227 diff -u -2 -r1.227 syncprov.c --- syncprov.c 3 Apr 2008 06:43:48 -0000 1.227 +++ syncprov.c 9 Apr 2008 10:29:40 -0000 @@ -2390,7 +2390,13 @@ if ( !ap ) { if ( !(rs->sr_flags & REP_ENTRY_MODIFIABLE) ) { - rs->sr_entry = entry_dup( rs->sr_entry ); - rs->sr_flags |= - REP_ENTRY_MODIFIABLE|REP_ENTRY_MUSTBEFREED; + Entry *new = entry_dup( rs->sr_entry ); + if ( rs->sr_flags & REP_ENTRY_MUSTRELEASE ) { + be_entry_release_r( op, rs->sr_entry ); + } else if ( rs->sr_flags & REP_ENTRY_MUSTBEFREED ) { + entry_free( rs->sr_entry ); + } + rs->sr_entry = new; + rs->sr_flags = (rs->sr_flags & ~REP_ENTRY_MASK) | + REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED; a = attr_find( rs->sr_entry->e_attrs, slap_schema.si_ad_contextCSN ); -- Hallvard

1 0

Re: (ITS#5457) bdb_add() does not always release entries
by hyc＠symas.com 09 Apr '08

09 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, 2.3, 2.4 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > back-bdb/add.c has several code paths where the parent entry > "p" is not released - it does "goto return_results;" without > first doing > > if ( p&& p !=&slap_entry_root ) > bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p ); > p = NULL; Releasing entries is somewhat irrelevant, since all locks are released when the transaction commits. Note that this function is a no-op in proto-bdb.h. All of those statements are just relics from the first entry cache design, before we switched to using BDB locks for everything. Probably could stand to do some cleanup. The diffs would be quite drastic though. Again, this may be something that's best deferred until 2.3 is dropped. -- -- 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#5457) bdb_add() does not always release entries
by h.b.furuseth＠usit.uio.no 09 Apr '08

09 Apr '08

Full_Name: Hallvard B Furuseth Version: HEAD, 2.3, 2.4 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-bdb/add.c has several code paths where the parent entry "p" is not released - it does "goto return_results;" without first doing if ( p && p != &slap_entry_root ) bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p ); p = NULL; The code looks like it expects that to be done below the return_results lablel, since it sets p to NULL before the goto. I don't know how the bdb cache code works though. Also I imagine the 'if ( !bvmatch( &pdn, &p->e_nname ) )' branch should check that p != &slap_entry_root before releasing p. Not sure when the parent needs to be freed. By ITS#3671 entries should be released before doing network I/O - but maybe the parent must be held until the slap_graduate_commit_csn()? I don't know what that does. Is it bdb_cache_add(,,op->ora_e,,,) or the following TXN_COMMIT which makes it necessary to bdb_cache_return_entry_r the entry? HEAD and RE24 only do bdb_cache_return_entry_r( bdb, oe, &lock ); if rs->sr_err == LDAP_SUCCESS at the return_results label, but rs->sr_err can change after the bdb_cache_add(). (A bit hard to read since the entry is referred to as both 'oe', op->ora_e and op->oq_add.rs_e. Not sure what the 'oe' variable is used for anyway.)

1 0

ITS#5378 delta-sync issues
by hyc＠symas.com 09 Apr '08

09 Apr '08

A fix is in HEAD. delta-syncrepl will now fallback to regular refresh in additional cases - LDAP_ALREADY_EXISTS, which may occur for old Adds, LDAP_NO_SUCH_OBJECT, for cases already covered in ITS#5376, LDAP_NO_SUCH_ATTRIBUTE, for old Modifies, and LDAP_TYPE_OR_VALUE_EXISTS also for old Modifies. Pretty sure that covers all of the possible out-of-sync cases. Please test. -- -- 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#5409) paged results invalid sizelimit error
by hyc＠symas.com 08 Apr '08

08 Apr '08

Thanks for the test program. I was able to compile it with JDK 1.5 and reproduce the error in both 2.3.41 and in HEAD. This is now fixed in RE23 and HEAD. Phoebe Shao wrote: > when connection pooling is off: > > if page size = 1000 > test 1 failed at the second iteration > test 2 failed at the third iteration > > if page size = 999 > test 1 always works > test 2 failed at the second iteration > > > I have not tried other tests where expected result is other number. > > > phoebe > > > > ----- "Howard Chu"<hyc(a)symas.com> wrote: > >> pshao(a)zimbra.com wrote: >>> ------=_Part_3887_1760018525.1205731478084 Content-Type: >> text/plain; >>> charset=utf-8 Content-Transfer-Encoding: 7bit >>> >>> >>> I did more testing and found there is more to the bug, page size is >> not the >>> only factor. The number of results in the next search also >> matters. >>> However, in all cases, if JNDI connection pooling is disabled, then >> it >>> always works. >>> >>> Test description: >>> >>> create 10000 account: user-1 to user-10000 search size limit = 5000 >>> >>> test 1: step 1. search with filter (uid=*user*): expect >>> SizeLimitExceededException step 2. search with filter >> (uid=*user-9999*): >>> expect 1 entry >>> >>> test 2: step 1. search with filter (uid=*user*): expect >>> SizeLimitExceededException step 2. search with filter >> (uid=*user-10*): >>> expect 112 entries >> Please be more descriptive, re: intermittent failure - how many >> iterations of >> a test a required (on average) before the problem shows up? >> >> -- >> -- Howard Chu >> Chief Architect, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- 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#5451) syncprov_checkpoint deadlock bugfix?
by h.b.furuseth＠usit.uio.no 07 Apr '08

07 Apr '08

Can you post your master and slave slapd.conf files, after removing passwords? -- Hallvard

1 0

Re: (ITS#5456) inaccurate interpretation of LDIF in back perl
by Uwe.Werler＠o3si.de 07 Apr '08

07 Apr '08

Hello Howard, in my last message (see below) the question was not wether is an entry starting with a blank line or not or what is a correct ldif. My question was if back_perl is only accepting "ldif-like" entries starting with dn-spec. If I return an entry like this: version: 1 dn: ou=foo,dc=bar ou: foo objectClass: organizationalUnit objectClass: top description: users from foo or with SEP after version-spec version: 1 dn: ou=foo,dc=bar ou: foo objectClass: organizationalUnit objectClass: top description: users from foo then the debug output from slapd is: "str2entry: entry -1 has no dn" That means that back_perl doesn't accept ldif files but only "ldif-like" entries without version-spec. If this is intended than I suggest to explain this in the man page or at least in the example shipped with back_perl. Thank You for Your attention. Regards Uwe Am Sonntag, den 06.04.2008, 12:41 -0700 schrieb Howard Chu: > Please do not email me directly unless you are a paying client of my company. > This thread started on the ITS. It should remain on the ITS. > > I already explained to you what the RFC spec says about valid LDIF. Valid LDIF > does not start with an empty line. There is nothing further to explain. > > Uwe Werler wrote: > > Dear Howard, > > > > after some testing again I determined that back_perl doesn't accept > > ldif_entries which are starting with an empty line. Then slapd tells me > > "str2entry: entry -1 has no dn". > > > > Is this behavior correct? If so it will be good to explain in the man > > page or the example that an entry should start with a dn line and > > shouldn't contain any empty lines nor the version information at the > > first line. > > > > I think that my mistake was to use sample code I've found like this: > > > > sub search > > { > > > > my $this = shift; > > my($base, $scope, $deref, $sizeLim, $timeLim, $filterStr, $attrOnly, @attrs ) = @_; > > if (! defined($this->{'LDAP'})) { > > $ldap = Net::LDAP->new( 'localhost' ) ; > > $this->{'LDAP'} = $ldap; > > } > > $mesg=$this->{'LDAP'}->search(base=>$base, > > scope=>$scope, > > deref=>$deref, > > sizelimit =>$sizeLim, > > timelimit =>$timeLim, > > filter =>$filterStr, > > attrs=> @attrs ); > > > > my @list = (); > > > > > > foreach $entry ($mesg->all_entries) { > > my $data; > > $LDIF = new IO::Scalar \$data; > > $dump=Net::LDAP::LDIF->new($LDIF,"w"); > > $dump->write($entry); > > $LDIF->close; > > push @list,$data; > > } > > return ( 0 , @list); > > > > } > > > > Because the entries returned by Net::LDAP::LDIF are starting with a leading SEP it won't work as is in back_perl. > > > > Thank You very much for Your attention. > > > > Regards Uwe > > > > > >

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠basefarm.no 07 Apr '08

07 Apr '08

rein(a)basefarm.no skrev: >> We have seen deadlock/hang situations in our master server today, which looks >> like a deadlock caused by the si_csn_rwlock lock being held while >> syncprov_checkpoint() is running. The patch at the end should (I hope) fix >> this. > > Hm, I looks as if I was a bit to quick here, it just hung got again :-(. > And this time without anyone competing for this lock, only the lock on > the glue suffix entry. I wonder if it can be the upgrade from db 4.6.18 > to 4.6.21.1 I dit yesterday that is the real problem. I'll try to > downgrade and see if that helps. And it didn't :-( The problem seem to be that something readlocks our glue suffix entry before forgetting about the lock. Which quickly causes the entire server to deadlock when the writelock required to update the contextCSN in the suffix entry locks out all the readers. So far the problem seem to be triggered by someone attempting to modify an entry in a subordinate syncrepl consumer backend that results in a referral to the backend master. But I haven't had very much time to look into this problem yet, so I'm still on very thin ice here. I'll return with a new ITS when I have found out more. We are currently running with a workaround that simply grants the writelocks on the glue suffix entry without actually doing it. As the glue entry is the only entry in that database it should be pretty safe, and a potential corruption of the database is not any big problem. > Please put this case on hold. Sorry! It currently looks as this patch addresses the symptom and not the real problem, although I'm not sure what could happen if a checkpoint is triggered while the suffix entry is locked by another thread. I do believe it should be considered if not a bug so an enhancement, as holding locks for as short time as possible is always a good thing. You'll have to choose whether to close this ITS or use the patch. Rein

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 07 Apr '08

07 Apr '08

Rein Tollevik wrote: > Howard Chu skrev: >> How about just moving the enable to after the runqueue manipulation is >> done? > > That would still leave a glitch in the window open, unless the initial > trylock is changed to a regular lock as your checking message suggests. > > But, doing that could result in all the threads ending up waiting for > the lock if do_syncrepl of a refresh only replication is configured to > run too often. I assume the trylock is there to avoid this? Yes, but I don't think that's a problem any more. If the scheduled task is still running when the next interval hits, the daemon task will just reschedule; it won't fire off a new thread for the task. >> It also occurs to me that we probably don't even need to manipulate the >> slapd runqueue in persist mode, when si->si_conn is already set. I.e., >> in that case we can only have gotten here because of a listener event, >> and not because of a runqueue schedule. > > That is probably true. Right, my patch avoids that now. Having looked at it again I think replacing the trylock with a regular lock is fine. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 07 Apr '08

07 Apr '08

Howard Chu skrev: > rein(a)basefarm.no wrote: >> Hm, I hope I have found the race condition that causes this :-) I'm now >> running with the patch at the end to see if that solves it, only time >> will tell.. And we haven't seen any replication problems since this was implemented friday afternoon :-). But it is still a bit too early to conclude that it has been fixed. >> The race is that between the time selecting on the syncrepl socket is >> enabled by the call to connection_client_enable() and the release of the >> si_mutex a new message may arrive. If so, the next call to do_syncrepl >> may fail in its attempt to trylock the mutex and no-one will re-enable >> selecting on it again. My patch delays enabling of the socket until the >> mutex has been released, which looks safe to me. Or can the access to >> si->si_conn without a lock be a problem? > > How about just moving the enable to after the runqueue manipulation is > done? That would still leave a glitch in the window open, unless the initial trylock is changed to a regular lock as your checking message suggests. But, doing that could result in all the threads ending up waiting for the lock if do_syncrepl of a refresh only replication is configured to run too often. I assume the trylock is there to avoid this? What about starting out with deferring the next scheduled call, as a scheduled call is not wanted until the first has completed anyhow? And a rescedule is already being done before do_syncrepl finishes. Deferring should not be necessary if rtask->next_sched.tv_sec is zero, i.e it has already been deferred. That would remove these calls for all the cases when do_syncrepl is called as a result of a new message on a persistent syncrepl connection. > Just need to be sure that do_syncrepl() isn't entered again before > si->si_conn gets initialized. I'm not quite sure what you mean here. As I see it, the problem is that do_syncrepl() must not be called after si->si_conn is enabled and the lock is still held. > It also occurs to me that we probably don't even need to manipulate the > slapd runqueue in persist mode, when si->si_conn is already set. I.e., > in that case we can only have gotten here because of a listener event, > and not because of a runqueue schedule. That is probably true. Rein

1 0

Re: (ITS#5456) inaccurate interpretation of LDIF in back perl
by h.b.furuseth＠usit.uio.no 07 Apr '08

07 Apr '08

I wrote: > You two seem to be saying the same thing: An entry should end with a > line terminator, but not with several line terminators (which give > blank lines). Duh, sorry, I didn't see you said it _begins_ with a newline. Anyway, Net::LDAP::LDIF is doing the right thing: When you write multiple entries to the same Net::LDAP::LDIF object, it puts an empty line between them. -- Hallvard

1 0

Re: (ITS#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ghenry＠OpenLDAP.org 06 Apr '08

06 Apr '08

toby(a)inf.ed.ac.uk wrote: >> Please test and report; >> >> servers/slapd/back-ldap/bind.c >> new revision: 1.244; previous revision: 1.243 >> >> The patch applies straightforwardly to re23 only if the first chunk is >> omitted. > > Been running for 3+ weeks now on various test machines with no > recurrence of error, so I'd consider this resolved. > > Many thanks > Toby > > > Thanks for the followup. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5456) inaccurate interpretation of LDIF in back perl
by hyc＠symas.com 06 Apr '08

06 Apr '08

Please do not email me directly unless you are a paying client of my company. This thread started on the ITS. It should remain on the ITS. I already explained to you what the RFC spec says about valid LDIF. Valid LDIF does not start with an empty line. There is nothing further to explain. Uwe Werler wrote: > Dear Howard, > > after some testing again I determined that back_perl doesn't accept > ldif_entries which are starting with an empty line. Then slapd tells me > "str2entry: entry -1 has no dn". > > Is this behavior correct? If so it will be good to explain in the man > page or the example that an entry should start with a dn line and > shouldn't contain any empty lines nor the version information at the > first line. > > I think that my mistake was to use sample code I've found like this: > > sub search > { > > my $this = shift; > my($base, $scope, $deref, $sizeLim, $timeLim, $filterStr, $attrOnly, @attrs ) = @_; > if (! defined($this->{'LDAP'})) { > $ldap = Net::LDAP->new( 'localhost' ) ; > $this->{'LDAP'} = $ldap; > } > $mesg=$this->{'LDAP'}->search(base=>$base, > scope=>$scope, > deref=>$deref, > sizelimit =>$sizeLim, > timelimit =>$timeLim, > filter =>$filterStr, > attrs=> @attrs ); > > my @list = (); > > > foreach $entry ($mesg->all_entries) { > my $data; > $LDIF = new IO::Scalar \$data; > $dump=Net::LDAP::LDIF->new($LDIF,"w"); > $dump->write($entry); > $LDIF->close; > push @list,$data; > } > return ( 0 , @list); > > } > > Because the entries returned by Net::LDAP::LDIF are starting with a leading SEP it won't work as is in back_perl. > > Thank You very much for Your attention. > > Regards Uwe > > -- -- 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#5456) inaccurate interpretation of LDIF in back perl
by h.b.furuseth＠usit.uio.no 05 Apr '08

05 Apr '08

hyc(a)symas.com writes: > uw(a)o3si.de wrote: >> The database backend "back_perl" expects LDIF entries beginning with >> "dn:" and ending with an empty line. (...) > > Wrong. (...) all records must end with LF or CR/LF. You two seem to be saying the same thing: An entry should end with a line terminator, but not with several line terminators (which give blank lines). >> After some testing with back_perl I noticed that the LDIF entries >> produced by the perl module Net::LDAP::LDIF were not acceptet because >> they are beginning with an empty line and ending only with a simple >> CR charakter. If you really mean CR (\r), that's a Net::LDAP::LDIF bug. However Net::LDAP::LDIF on my host correctly ends an entry with LF (\n). And back-perl (at least the search operation) accepts entries ending with both zero, one and two '\n's, as well as with '\r'. There was however an entry parsing bug (ITS#4852) in 2.3.32 which was fixed in 2.3.35. I don't see how it'd be related, but I suggest you upgrade anyway. Then if you still have trouble, try a simple perl script which does something like sub search { 0, "dn: o=foo\no: foo\nobjectClass: organization\n" } instead of going via a module like Net::LDAP::LDIF, so you can be quite sure the problem is what you think it is. -- Hallvard

1 0

Re: (ITS#5456) inaccurate interpretation of LDIF in back perl
by hyc＠symas.com 05 Apr '08

05 Apr '08

uw(a)o3si.de wrote: > Full_Name: Uwe Werler > Version: 2.3.32 > OS: SLES10 SP1 Kernel 2.6.16.54-0.2.3-xen > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.56.68.221) > > > The database backend "back_perl" expects LDIF entries beginning with "dn:" and > ending with an empty line. RFC2849 only describes that an entry is everything > except an empty line and a line not beginning (after a CR/LF) with a single > white space character. Wrong. The grammar in RFC2849 quite explicitly states: ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) ldif-changes = version-spec 1*(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*attrval-spec ldif-change-record = dn-spec SEP *control changerecord That means an LDIF file must start with 0 or 1 version-specs, then a dn-spec. And, all records must end with LF or CR/LF. > After some testing with back_perl I noticed that the LDIF entries produced by > the perl module Net::LDAP::LDIF were not acceptet because they are beginning > with an empty line and ending only with a simple CR charakter. > > This behavior breaks RFC2849. After changing LDIF.pm from that module to produce > the CR after the entry back_perl accepts this entries too. > > IMHO this is a misbehavior so I'm very glad if You'll take a look at this > issue. Apparently it Net::LDAP::LDIF is broken. Since that is not a piece of OpenLDAP Software I don't see what we can do about it. This ITS will be closed. Contact the author of Net::LDAP::LDIF to pursue this further. -- -- 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#5456) inaccurate interpretation of LDIF in back perl
by uw＠o3si.de 04 Apr '08

04 Apr '08

Full_Name: Uwe Werler Version: 2.3.32 OS: SLES10 SP1 Kernel 2.6.16.54-0.2.3-xen URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.56.68.221) The database backend "back_perl" expects LDIF entries beginning with "dn:" and ending with an empty line. RFC2849 only describes that an entry is everything except an empty line and a line not beginning (after a CR/LF) with a single white space character. After some testing with back_perl I noticed that the LDIF entries produced by the perl module Net::LDAP::LDIF were not acceptet because they are beginning with an empty line and ending only with a simple CR charakter. This behavior breaks RFC2849. After changing LDIF.pm from that module to produce the CR after the entry back_perl accepts this entries too. IMHO this is a misbehavior so I'm very glad if You'll take a look at this issue. Thanks in advance. Regards Uwe

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 04 Apr '08

04 Apr '08

rein(a)basefarm.no wrote: > Hm, I hope I have found the race condition that causes this :-) I'm now > running with the patch at the end to see if that solves it, only time will > tell.. > > The race is that between the time selecting on the syncrepl socket is > enabled by the call to connection_client_enable() and the release of the > si_mutex a new message may arrive. If so, the next call to do_syncrepl > may fail in its attempt to trylock the mutex and no-one will re-enable > selecting on it again. My patch delays enabling of the socket until the > mutex has been released, which looks safe to me. Or can the access to > si->si_conn without a lock be a problem? How about just moving the enable to after the runqueue manipulation is done? Just need to be sure that do_syncrepl() isn't entered again before si->si_conn gets initialized. It also occurs to me that we probably don't even need to manipulate the slapd runqueue in persist mode, when si->si_conn is already set. I.e., in that case we can only have gotten here because of a listener event, and not because of a runqueue schedule. -- -- 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#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 04 Apr '08

04 Apr '08

--On Friday, April 04, 2008 1:23 PM +0200 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > Since it crashes on > if ( so->s_op->o_connid == op->o_connid && > so->s_op->o_msgid == op->orn_msgid ) > please try > frame 0 > print *op > print *so->s_op > and maybe > backtrace full > while you are at it. #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) frame 0 #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) print *op $1 = {o_hdr = 0x42002ac0, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x42002830, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_e = 0x4, rs_modlist = 0x0}, oq_bind = {rb_method = 4, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x4}, oq_modify = {rs_modlist = 0x4, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 4, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 4, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 4}, oq_cancel = {rs_msgid = 4}, oq_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x42002810, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x0}} (gdb) print *so->s_op $2 = {o_hdr = 0x11d8fd60, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_e = 0x0, rs_modlist = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_modlist = 0x0, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x11d8fdd8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x12307c00}} (gdb) backtrace full #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 on = (slap_overinst *) 0xde1c40 si = (syncprov_info_t *) 0xde2ee0 so = (syncops *) 0x12392240 soprev = (syncops *) 0x12394bd0 #1 0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640 func = (BI_op_bind **) 0xde1c98 rc = 32768 #2 0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, which=op_abandon) at backover.c:702 oi = (slap_overinfo *) 0xde1e00 on = (slap_overinst *) 0xde1c40 be = (BackendDB *) 0xddf540 db = {bd_info = 0xde1c40, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xdd7920, be_nsuffix = 0xdd7900, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 12, bv_val = 0xdd8410 "cn=accesslog"}, be_rootndn = {bv_len = 12, bv_val = 0xdd8490 "cn=accesslog"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8b0000, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xf35a40, be_pcl_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0xddf680, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x2a972f0fe0, be_private = 0x889c80, be_next = {stqe_next = 0xde1a80}} cb = {sc_next = 0x0, sc_response = 0x49b297 <over_back_response>, sc_cleanup = 0, sc_private = 0xde1e00} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #3 0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at backover.c:760 No locals. #4 0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at abandon.c:115 No locals. #5 0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792 o = (Operation *) 0x11d8f900 next = (Operation *) 0x0 op = {o_hdr = 0x42002ac0, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x42002830, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = { oq_add = {rs_e = 0x4, rs_modlist = 0x0}, oq_bind = {rb_method = 4, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x4}, oq_modify = {rs_modlist = 0x4, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 4, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 4, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 4}, oq_cancel = {rs_msgid = 4}, oq_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x42002810, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 583, oh_conn = 0x12603dd0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_log_prefix = '\0' <repeats 49 times>} rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} #6 0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0 "connection lost") at connection.c:840 sd = 38 __PRETTY_FUNCTION__ = "connection_closing" #7 0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at connection.c:1457 rc = -2 c = (Connection *) 0x12603dd0 __PRETTY_FUNCTION__ = "connection_read" #8 0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at connection.c:1254 rc = 42 cri = {op = 0x11d8f900, func = 0, arg = 0x0, nullop = 0} s = 38 #9 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x88ce10 ctx = (ldap_int_thread_ctx_t *) 0xf375d0 ltc_key = {{ltk_key = 0x48717a, ltk_data = 0xe658c0, ltk_free = 0x486f64 <slap_sl_mem_destroy>}, {ltk_key = 0x976100, ltk_data = 0xf, ltk_free = 0x2a971e9cf9 <bdb_locker_id_free>}, {ltk_key = 0x2a971dae1f, ltk_data = 0x159be000, ltk_free = 0x2a971dadff <search_stack_free>}, {ltk_key = 0x976680, ltk_data = 0xf, ltk_free = 0x2a971e9cf9 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1107310944 i = 219 keyslot = 219 hash = 219 #10 0x0000003342606137 in ?? () No symbol table info available. #11 0x0000000000000000 in ?? () No symbol table info available. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5455) EntryInfo state not reset if entry_db lock fails
by rein＠basefarm.no 04 Apr '08

04 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) In bdb_cache_find_id() in servers/slapd/back-bdb/cache.c it decrements the bei_finders of the EntryInfo and resets the loading flag in bei_state. These statements are only run if locking the entry_db succeed, but as they reset state the function has altered they should always be run. I.e, move these statements and the surrounding lock calls out of the block they currently are in. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 04 Apr '08

04 Apr '08

On Thu, 3 Apr 2008, rein(a)basefarm.no wrote: > Our persistent syncrepl consumers stops receiving data after a while, with no > indication of why :-( They don't recognize restarts of the producer, so the > only way to get the replication running again is to restart the consumers. > > So far it looks to me as if the syncrepl thread has managed to return without > adding the connection socket back to slap_daemon.sd_readers. But whether that > is correct or not, and how it has managed to do it if so, I cannot tell. Hm, I hope I have found the race condition that causes this :-) I'm now running with the patch at the end to see if that solves it, only time will tell.. The race is that between the time selecting on the syncrepl socket is enabled by the call to connection_client_enable() and the release of the si_mutex a new message may arrive. If so, the next call to do_syncrepl may fail in its attempt to trylock the mutex and no-one will re-enable selecting on it again. My patch delays enabling of the socket until the mutex has been released, which looks safe to me. Or can the access to si->si_conn without a lock be a problem? Rein Index: OpenLDAP/servers/slapd/syncrepl.c diff -u OpenLDAP/servers/slapd/syncrepl.c:1.9 OpenLDAP/servers/slapd/syncrepl.c:1.10 --- OpenLDAP/servers/slapd/syncrepl.c:1.9 Fri Mar 28 14:25:55 2008 +++ OpenLDAP/servers/slapd/syncrepl.c Fri Apr 4 16:54:05 2008 @@ -1166,6 +1166,7 @@ ber_socket_t s; int i, defer = 1, fail = 0; Backend *be; + int enable_conn = 0; Debug( LDAP_DEBUG_TRACE, "=>do_syncrepl %s\n", si->si_ridtxt, 0, 0 ); @@ -1271,11 +1272,7 @@ * If we failed, tear down the connection and reschedule. */ if ( rc == LDAP_SUCCESS ) { - if ( si->si_conn ) { - connection_client_enable( si->si_conn ); - } else { - si->si_conn = connection_client_setup( s, do_syncrepl, arg ); - } + enable_conn = 1; } else if ( si->si_conn ) { dostop = 1; } @@ -1342,6 +1339,14 @@ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); ldap_pvt_thread_mutex_unlock( &si->si_mutex ); + if ( enable_conn ) { + if ( si->si_conn ) { + connection_client_enable( si->si_conn ); + } else { + si->si_conn = connection_client_setup( s, do_syncrepl, arg ); + } + } + if ( rc ) { if ( fail == RETRYNUM_TAIL ) { Debug( LDAP_DEBUG_ANY,

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by h.b.furuseth＠usit.uio.no 04 Apr '08

04 Apr '08

Since it crashes on if ( so->s_op->o_connid == op->o_connid && so->s_op->o_msgid == op->orn_msgid ) please try frame 0 print *op print *so->s_op and maybe backtrace full while you are at it. -- Hallvard

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 04 Apr '08

04 Apr '08

On Fri, 4 Apr 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> So far it looks to me as if the syncrepl thread has managed to return >> without >> adding the connection socket back to slap_daemon.sd_readers. But whether >> that >> is correct or not, and how it has managed to do it if so, I cannot tell. > > Since you're working with HEAD ... Were there any write operations on > cn=config just before the hang? (Thinking it may be connected to the > SYNC_PAUSED handling at line 1303, except any subsequent request would wake > up the listener anyway.) No, the config backend isn't even configured into the server. I have also tried without the auditlog just to make sure that wasn't involved, but it happend anyhow. We have also added a linux server on one of the sites to see if the problem is related to solaris. So far it hasn't stopped receiving updates, but is has only run since last evening so it is far too early to conclude anything. Rein

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 04 Apr '08

04 Apr '08

rein(a)basefarm.no wrote: > So far it looks to me as if the syncrepl thread has managed to return without > adding the connection socket back to slap_daemon.sd_readers. But whether that > is correct or not, and how it has managed to do it if so, I cannot tell. Since you're working with HEAD ... Were there any write operations on cn=config just before the hang? (Thinking it may be connected to the SYNC_PAUSED handling at line 1303, except any subsequent request would wake up the listener anyway.) > Any pointers as to what can be wrong are highly appreciated. I have a core file > from a server that has stopped receiving if there is anything I should look for > there. > > Rein Tollevik > Basefarm AS > > > -- -- 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#5444) slapd seg. fault using mulitmirrored mode
by ando＠sys-net.it 03 Apr '08

03 Apr '08

hyc(a)symas.com wrote: > OK, I've reproduced the crash and patched it in HEAD, and added a consumer > write to the test050 script. Please test. Works for me. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Thursday, April 03, 2008 6:41 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u > zimbra -h ldap://'. also: (gdb) print so $1 = (syncops *) 0x12392240 (gdb) print *so $2 = {s_next = 0x12393510, s_base = {bv_len = 12, bv_val = 0x1238dd50 "cn=accesslog"}, s_eid = 1, s_op = 0x11d8fc00, s_rid = 100, s_filterstr = {bv_len = 0, bv_val = 0x0}, s_flags = 1, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_qtask = 0x0, s_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} from frame 0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by hyc＠symas.com 03 Apr '08

03 Apr '08

quanah(a)zimbra.com wrote: > --On Tuesday, April 01, 2008 6:24 PM +0000 > sahullameerbasha.nagore(a)etrade.com wrote: > >> Full_Name: ameer basha >> Version: 2.4.8 >> OS: Red Hat linux As3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.93.33.254) >> >> >> I am getting the following error while adding the data into the ldap >> through siteminder gui. >> >> slapd: schema_init.c:2215: integerIndexer: Assertion `i> 0' failed. >> >> Do you have any idea why this error is getting > > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> > > may also be related to this bug report. It includes reproduction data, > although the assert in this case triggered on the stringIndexer. Thanks for the data, that helped. 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#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 03 Apr '08

03 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: solaris8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Our persistent syncrepl consumers stops receiving data after a while, with no indication of why :-( They don't recognize restarts of the producer, so the only way to get the replication running again is to restart the consumers. The consumers have a single bdb backend database that is replicated from the producer, and uses the auditlog overlay on this backend. There are 4 of them, running in pairs as load-balanced search servers on two sites. The two servers in each pair are identical configured, and they are all running 64bit solaris8 if that matters. There are two master servers, one on each site, with a more complicated configuration. They replicate subordinate backend datebases between each other, the consumers replicate the glue suffix of these backends. These servers are running linux in 32- and 64bit mode, and I have not seen the same type of replication stops between these master servers. Using netstat it shows that the send queue is full on the producer side, and the receive window is empty on the consumer, which to me looks as if the consumer has stopped reading from the provider. I have used a debugger to look at the servers after they have stopped receiving, and the syncrepl task is sitting at the end of slapd_rq.task_list, with next_sched.tv_sec==0 (which mean it will not be scheduled normally?) The syncrepl is configured with "retry=60 +". The si_conn of the syncinfo_t looks normal, and its c_sd socket is on slap_daemon.sd_actives fd_set, but not on sd_readers nor sd_writers. And none of the threads are running any syncrepl code. Looking at "slapd -d sync" output and the auditlogs it seem to stop receiving in the middle of a burst of updates (although that could be a coinsident). The other slave in the pairs continues to receive updates, so I assume this is a consumer side problem. So far it looks to me as if the syncrepl thread has managed to return without adding the connection socket back to slap_daemon.sd_readers. But whether that is correct or not, and how it has managed to do it if so, I cannot tell. Any pointers as to what can be wrong are highly appreciated. I have a core file from a server that has stopped receiving if there is anything I should look for there. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5453) slapd binding error at startup
by hyc＠symas.com 03 Apr '08

03 Apr '08

m_hannini(a)yahoo.com wrote: > Full_Name: Mohammed > Version: 2.3.37 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.146.102.46) > > > Hi, > I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: > daemon: bind(7) failed errno=67 (Address already in use) > slapd starting > > This is even though there is nothing running on port 389 but the ldap server > itself. > # netstat -an |grep 389 > tcp4 0 0 *.389 *.* LISTEN > > > Any ideas? There is no indication of a bug in OpenLDAP software here. This ITS will be closed. Software usage questions should be directed to the openldap-software mailing list. -- -- 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#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Tuesday, April 01, 2008 6:24 PM +0000 sahullameerbasha.nagore(a)etrade.com wrote: > Full_Name: ameer basha > Version: 2.4.8 > OS: Red Hat linux As3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.93.33.254) > > > I am getting the following error while adding the data into the ldap > through siteminder gui. > > slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed. > > Do you have any idea why this error is getting <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> may also be related to this bug report. It includes reproduction data, although the assert in this case triggered on the stringIndexer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5453) slapd binding error at startup
by m_hannini＠yahoo.com 03 Apr '08

03 Apr '08

Full_Name: Mohammed Version: 2.3.37 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.146.102.46) Hi, I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: daemon: bind(7) failed errno=67 (Address already in use) slapd starting This is even though there is nothing running on port 389 but the ldap server itself. # netstat -an |grep 389 tcp4 0 0 *.389 *.* LISTEN Any ideas? Thanks

1 0

(ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://'. Program terminated with signal 11, Segmentation fault. #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) bt #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 #1 0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640 #2 0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, which=op_abandon) at backover.c:702 #3 0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at backover.c:760 #4 0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at abandon.c:115 #5 0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792 #6 0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0 "connection lost") at connection.c:840 #7 0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at connection.c:1457 #8 0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at connection.c:1254 #9 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at tpool.c:478 #10 0x0000003342606137 in ?? () #11 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) l 1021 syncops *so, *soprev; 1022 1023 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); 1024 for ( so=si->si_ops, soprev = (syncops *)&si->si_ops; so; 1025 soprev=so, so=so->s_next ) { 1026 if ( so->s_op->o_connid == op->o_connid && 1027 so->s_op->o_msgid == op->orn_msgid ) { 1028 so->s_op->o_abandon = 1; 1029 soprev->s_next = so->s_next; 1030 break; (gdb)

1 0

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

03 Apr '08

ando(a)sys-net.it writes: > That's why I'm not so happy with MUSTRELEASE. Seems to be required though. cvs log for slap.h revision 1.678. But it does look to me like SlapReply needs a BackendDB *e_owner member. I haven't observed buggy behavior related to that (or tried to provoke any), but it looks hairy for a backend with a be_release() function to make sure to intercept every entry from elsewhere and record previous owner info in e_private or callbacks. > OK, makes sense. But perhaps creating entries on the stack could be > deprecated now that entries are pooled and reused by calling > entry_alloc() entry_free(). This is just food for thoughts, we could as > well leave all those flags 'round, if we can streamline their handling. I think we might as well leave them. Since most are for saving memory, might even want to expand them eventually. (E.g. separate flags for _which_ parts of an entry are modifiable. Modifiable attribute list, DNs, values _in_ attribute list, etc.) For that matter, looking at entry_free/entry_alloc, I don't see how that pooling saves more than it costs. It saves 1 malloc for the Entry structure, but not the mallocs for the DN and attribute list. And it costs two global mutex lock/unlocks per entry, in entry_alloc() and entry_free(). An entry on the stack avoids both malloc and locks. Anyway, I guess one conclusion of all this is that the code really is as sloppy as it looked, there are no magic saving throws in there. (Except with finding the backend for be_release if I'm still missing something about that.) -- Hallvard

1 0

Re: (ITS#5444) slapd seg. fault using mulitmirrored mode
by hyc＠symas.com 03 Apr '08

03 Apr '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> ando(a)sys-net.it wrote: >>>> mohel(a)web.de wrote: >>>> >>>>> The above log was generated using the test050 script just adding a line which >>>>> enters information also to a second server. Perhaps this test would also make >>>>> sense for further releases. >>>> Can you please post the modification to the script? >>> Never mind, I could reproduce it. It seems to be a duplicate of >>> ITS#5437. What actually happens is that if modifications are applied to >>> all three servers, those applied to consumers do not persist, nor get >>> replicated; on the contrary, the consumers crash later on as described >>> in ITS#5437. >> #5437? What you're talking about doesn't seem to match any text in ITS#5437. > > Well, sorry for not providing more details, I was going to investigate > it a little bit more but I had to leave. The crash to me occurs in > syncprov_done_ctrl(), as indicated in ITS#5437. What happens is that > syncprov_done_ctrl() with an invalid cookie (unset; clearing it in > syncprov_search_response(), as suggested in ITS#5437 leads to the > behavior I described (writes to consumers are simply ignored, don't > persist in the consumers and are not replicated). To reproduce, add > something to a consumer close to the end of test050, before killing the > servers, and wait a little bit to let things proceed to the crash. OK, I've reproduced the crash and patched it in HEAD, and added a consumer write to the test050 script. Please test. -- -- 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#5437
by ando＠sys-net.it 02 Apr '08

02 Apr '08

The issue pointed out in this thread <http://www.openldap.org/lists/openldap-software/200804/msg00036.html> could be related. ITS#5444 could be related as well. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 02 Apr '08

02 Apr '08

--XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kurt, On Mon, Mar 03, 2008 at 02:50:49PM -0800, Kurt Zeilenga wrote: > In your rights statement, you claim this patch is only derived from =20 > OpenLDAP Software. Is this correct? Are there are works from which =20 > your work is derived? That is, did you copy any material from any other= =20 > work (e.g., Samba)? Please document any in the rights statement and,=20 > when complete, update the ITS (by email reply-all) indicating so. > > The rights statement needs to be amended to include a statement that the= =20 > modifications are not subject to Stefan's employer. And then Stefan=20 > needs to send a copy of both statements from his email address to=20 > openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements"=20 > confirming they are correct. I've cc'ed Stefan on this note. Have you received Stefan's copyright statement ? cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH81vZHvdfyv3qiKkRAhI2AKCWKZOTtjG4F+eSqYiAMN6MlCtCdwCgoCOb Ir40KCUW32l9HAkhiqyYCxA= =coUh -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--

1 0

Re: (ITS#5440) back-meta opens too many connections in case of error
by ali.pouya＠free.fr 02 Apr '08

02 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote : > > issue I observed does not show up any longer. Probably, as an outcome > of this ITS, we should change the default to "yes". > Yes. I agree with you. Because in all my configurations I have to set : pseudoroot-bind-defer yes Thanks for the improvement. Best Regards Ali

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠basefarm.no 01 Apr '08

01 Apr '08

On Tue, 1 Apr 2008, rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > > > We have seen deadlock/hang situations in our master server today, which looks > like a deadlock caused by the si_csn_rwlock lock being held while > syncprov_checkpoint() is running. The patch at the end should (I hope) fix > this. Hm, I looks as if I was a bit to quick here, it just hung got again :-(. And this time without anyone competing for this lock, only the lock on the glue suffix entry. I wonder if it can be the upgrade from db 4.6.18 to 4.6.21.1 I dit yesterday that is the real problem. I'll try to downgrade and see if that helps. Please put this case on hold. Sorry! Rein

1 0

(ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠basefarm.no 01 Apr '08

01 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) We have seen deadlock/hang situations in our master server today, which looks like a deadlock caused by the si_csn_rwlock lock being held while syncprov_checkpoint() is running. The patch at the end should (I hope) fix this. The scenario is a server with a the syncprov overlay on a glue database with multiple bdb backends as subordinate. One of them is a syncrepl consumer, although I don't know if that matters. A modify operation on the syncrepl consumer causes a checkpoint of the contextCSN. The resulting modify on the glue backend hangs in bdb_cache_modify() awaiting the bdb_cache_entry_db_relock() to return a write lock on the glue suffix entry. At the same time is a modify on one of the other backends hanging in syncprov_op_response() waiting for a lock on the si_csn_rwlock which the first thread holds. The remaining threads quickly blocks waiting for a read lock on the glue suffix entry (the most common search base). I recon the read locks are queued to give priority to the thread waiting for the write lock. What I haven't figured out is who that holds the lock on the glue suffix entry in the first place... Anyway, holding the si_csn_rwlock while the contextCSN is written to the database should not be necessary. But I don't know what consequences it whould have if more than one thread should end up checkpointing competing values, so I have added a new flag to the syncprov_info structure to prevent simultaneons checkpoints from occuring rather than using locks to do it. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.13 OpenLDAP/servers/slapd/overlays/syncprov.c:1.12 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.13 Mon Mar 31 17:29:48 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Apr 1 21:54:05 2008 @@ -128,6 +128,7 @@ int si_numops; /* number of ops since last checkpoint */ int si_nopres; /* Skip present phase */ int si_usehint; /* use reload hint */ + int si_check; /* are we checkpointing? */ time_t si_chklast; /* time of last checkpoint */ Avlnode *si_mods; /* entries being modified */ sessionlog *si_logs; @@ -1308,8 +1309,10 @@ slap_callback cb = {0}; BackendDB be; + ldap_pvt_thread_rdwr_rlock( &si->si_csn_rwlock ); mod.sml_numvals = si->si_numcsns; mod.sml_values = si->si_ctxcsn; + ldap_pvt_thread_rdwr_runlock( &si->si_csn_rwlock ); mod.sml_nvalues = NULL; mod.sml_desc = slap_schema.si_ad_contextCSN; mod.sml_op = LDAP_MOD_REPLACE; @@ -1335,6 +1338,8 @@ if ( mod.sml_next != NULL ) { slap_mods_free( mod.sml_next, 1 ); } + + si->si_check = 0; } static void @@ -1612,7 +1617,7 @@ } si->si_numops++; - if ( si->si_chkops || si->si_chktime ) { + if ( !si->si_check && (si->si_chkops || si->si_chktime) ) { if ( si->si_chkops && si->si_numops >= si->si_chkops ) { do_check = 1; si->si_numops = 0; @@ -1627,12 +1632,14 @@ } } } + + if ( do_check ) + si->si_check = 1; + ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); if ( do_check ) { - ldap_pvt_thread_rdwr_rlock( &si->si_csn_rwlock ); syncprov_checkpoint( op, rs, on ); - ldap_pvt_thread_rdwr_runlock( &si->si_csn_rwlock ); } opc->sctxcsn.bv_len = maxcsn.bv_len;

1 0

(ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by sahullameerbasha.nagore＠etrade.com 01 Apr '08

01 Apr '08

Full_Name: ameer basha Version: 2.4.8 OS: Red Hat linux As3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.93.33.254) I am getting the following error while adding the data into the ldap through siteminder gui. slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed. Do you have any idea why this error is getting

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by ando＠sys-net.it 01 Apr '08

01 Apr '08

Hallvard B Furuseth wrote: > Pierangelo Masarati writes: >> Hallvard B Furuseth wrote: >>> But I don't see how the be_release() code can work now. It sounds like >>> be->be_release() functions must check (how?) that the entry was created >>> by 'be', and otherwise pass it on to the next overlay/backend or >>> otherwise to entry_free(). Might involve mucking with op->o_bd and >>> sr_entry->e_private, I suppose. Except maybe I'm missing some existing >>> magic since slapd doesn't regularly crash... >> Yes, but that's trivial: e_private must be NULL for temporary entries, >> and copying the entry loses it (no one is supposed to muck with it >> expect the entry's creator). > > OK... > >> And the appropriate o_bd of a >> (non-modifiable) entry can be easily computed from the entry's DN. > > Hm? Can only the "outermost" backend/overlay create non-modifiable > entries? > > I think any overlay can replace a non-modifiable rs->sr_entry value, as > long as it restores it on the way out (unless mustbe<freed/released>). That's why I'm not so happy with MUSTRELEASE. >>>> Similarly, the existence of REP_ENTRY_MUSTBEFREED is not totally clear: >>>> in principle as soon as REP_ENTRY_MODIFYABLE is set, it should imply >>>> REP_ENTRY_MUSTBEFREED; the only difference in the semantics of the two >>> That's not my impression. (...) > > Some functions create entries on the stack an send them MODIFIABLE - but > obviously without MUSTBEFREED. They use entry_clean() instead. > > Others set MODIFIABLE but not MUSTBEFREED on non-stack entries, and call > entry_free after sending it. Or forget to free it - back-perl/search.c > if LDAP_SIZELIMIT_EXCEEDED. (Not patching yet - don't have time to test > it at the moment.) OK, makes sense. But perhaps creating entries on the stack could be deprecated now that entries are pooled and reused by calling entry_alloc() entry_free(). This is just food for thoughts, we could as well leave all those flags 'round, if we can streamline their handling. >> (...) A copy might be created by an overlay after receiving a >> read-only entry, but the same overlay might not actually perform the >> copy if it receives the entry from another overlay that already copied >> it, or from a proxy backend. However, after the entry is copied the >> overlay will have no means to determined who actually created the copy. > > I don't think it matters who created a MUSTBEFREED copy: right. >> This might be an issue depending on the order cleanup handlers are >> called (didn't check what order they're called). My point is that >> temporary entries need to be freed at some point; who frees them should >> not be relevant... > > Right, someone must call entry_free() and clear rs->sr_entry (so it's > not freed again), but entry_free() is not passed a backend parameter. > > OTOH a MUSTBERELEASED entry must be released by the right > backend/overlay, and it would be strange for such an entry to be > MODIFIBALE. Though I guess it could be - if the backend has no cache, > and be_release just exists to clean up some data in e_private. > >>> Others apparent problems (also not tested, I've just browsed the code): >>> Overlays that obey and reset MUSTBEFREED or MUSTRELEASE, do not >>> necessarily clear or set MODIFIABLE when setting a new entry. >>> (...) >> It seems to me that we should provide "smart" handlers to deal with >> preparing sr_entry for modification, and to take care of cleaning things >> up as appropriate. Those helpers should then be consistently used in >> the code. > > Yup. And add some aggressive asserts - at least #ifdef LDAP_DEVEL. > Don't know when I'll have time for it though. Making room in my todo list... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5448) CONTRIB: Java slapd
by Kurt＠OpenLDAP.org 01 Apr '08

01 Apr '08

On Mar 31, 2008, at 8:01 PM, hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 0.0.1 > OS: > URL: ftp://ftp.openldap.org/incoming/jslapd.tgz > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Given the increasing popularity of Java, I decided it was time that > the > OpenLDAP Project had its own Java implementation of an LDAP server. It > gave me a good opportunity to explore all of the benefits of rapid > development, introspection, and other advantages of the Java system. > Indeed, drawing on my experience with the existing OpenLDAP code base, > it took only a matter of hours to create my first working server, > which > I present here. Of course it's still experimental in nature. > > Invocation is similar to the regular C-based slapd, and it accepts all > of the same arguments and reads all of the same config settings. In > addition, the first commandline argument must be the name of the > directory > where slapd resides, so that the java app can locate the config files, > schema, etc. > > E.g. for a typical OpenLDAP installation in /usr/local you would run > java jslapd /usr/local/libexec -h ldap://:389 > > A small shell script has been provided to simplify this invocation. > In my initial testing, I found jslapd to have performance on par with slapd(8)! And the memory footprint doesn't appear all that much larger. Good work! -- Kurt

1 0

Re: (ITS#5440) back-meta opens too many connections in case of error
by ando＠sys-net.it 01 Apr '08

01 Apr '08

Ali Pouya wrote: > Hi Pierangelo; > > When trying to reproduce the problem with test035 material I found a > problem in my own JAVA code ! > There is no such problem in back-meta :-) > Sorry for misreporting and thanks for your help. OK, no problem. I note that the issue I fixed in HEAD is basically related to not using pseudoroot-bind-defer yes The default is "no", basically to preserve the original behavior. The original behavior consisted in always binding to all targets when bound as the rootdn. When "pseudoroot-bind-defer" is set to "yes", the bind only occurs locally at the proxy, and is propagated to the targets only when they actually need to be used. The reason is that binding as the rootdn might only be needed to operate on a subset of the targets, so there is no need to add extra traffic to those outside this set. When "pseudoroot-bind-defer" is set to "yes", this no longer occurs, and the issue I observed does not show up any longer. Probably, as an outcome of this ITS, we should change the default to "yes". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

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

01 Apr '08

Pierangelo Masarati writes: > Hallvard B Furuseth wrote: >> But I don't see how the be_release() code can work now. It sounds like >> be->be_release() functions must check (how?) that the entry was created >> by 'be', and otherwise pass it on to the next overlay/backend or >> otherwise to entry_free(). Might involve mucking with op->o_bd and >> sr_entry->e_private, I suppose. Except maybe I'm missing some existing >> magic since slapd doesn't regularly crash... > > Yes, but that's trivial: e_private must be NULL for temporary entries, > and copying the entry loses it (no one is supposed to muck with it > expect the entry's creator). OK... > And the appropriate o_bd of a > (non-modifiable) entry can be easily computed from the entry's DN. Hm? Can only the "outermost" backend/overlay create non-modifiable entries? I think any overlay can replace a non-modifiable rs->sr_entry value, as long as it restores it on the way out (unless mustbe<freed/released>). >>> Similarly, the existence of REP_ENTRY_MUSTBEFREED is not totally clear: >>> in principle as soon as REP_ENTRY_MODIFYABLE is set, it should imply >>> REP_ENTRY_MUSTBEFREED; the only difference in the semantics of the two >> >> That's not my impression. (...) Some functions create entries on the stack an send them MODIFIABLE - but obviously without MUSTBEFREED. They use entry_clean() instead. Others set MODIFIABLE but not MUSTBEFREED on non-stack entries, and call entry_free after sending it. Or forget to free it - back-perl/search.c if LDAP_SIZELIMIT_EXCEEDED. (Not patching yet - don't have time to test it at the moment.) > (...) A copy might be created by an overlay after receiving a > read-only entry, but the same overlay might not actually perform the > copy if it receives the entry from another overlay that already copied > it, or from a proxy backend. However, after the entry is copied the > overlay will have no means to determined who actually created the copy. I don't think it matters who created a MUSTBEFREED copy: > This might be an issue depending on the order cleanup handlers are > called (didn't check what order they're called). My point is that > temporary entries need to be freed at some point; who frees them should > not be relevant... Right, someone must call entry_free() and clear rs->sr_entry (so it's not freed again), but entry_free() is not passed a backend parameter. OTOH a MUSTBERELEASED entry must be released by the right backend/overlay, and it would be strange for such an entry to be MODIFIBALE. Though I guess it could be - if the backend has no cache, and be_release just exists to clean up some data in e_private. >> Others apparent problems (also not tested, I've just browsed the code): >> Overlays that obey and reset MUSTBEFREED or MUSTRELEASE, do not >> necessarily clear or set MODIFIABLE when setting a new entry. >> (...) > > It seems to me that we should provide "smart" handlers to deal with > preparing sr_entry for modification, and to take care of cleaning things > up as appropriate. Those helpers should then be consistently used in > the code. Yup. And add some aggressive asserts - at least #ifdef LDAP_DEVEL. Don't know when I'll have time for it though. -- Hallvard

1 0

Re: (ITS#5448) CONTRIB: Java slapd
by ando＠sys-net.it 01 Apr '08

01 Apr '08

hyc(a)OpenLDAP.org wrote: > Given the increasing popularity of Java, I decided it was time that the > OpenLDAP Project had its own Java implementation of an LDAP server. It > gave me a good opportunity to explore all of the benefits of rapid > development, introspection, and other advantages of the Java system. > Indeed, drawing on my experience with the existing OpenLDAP code base, > it took only a matter of hours to create my first working server, which > I present here. Of course it's still experimental in nature. > > Invocation is similar to the regular C-based slapd, and it accepts all > of the same arguments and reads all of the same config settings. In > addition, the first commandline argument must be the name of the directory > where slapd resides, so that the java app can locate the config files, > schema, etc. > > E.g. for a typical OpenLDAP installation in /usr/local you would run > java jslapd /usr/local/libexec -h ldap://:389 > > A small shell script has been provided to simplify this invocation. Howard, many thanks for the contribution. I haven't stressed it yet intensively, but at a first glance it seems to be as performing as the latest 2.4. Will this be released in 2.4, or do we need to wait until 2.5 (what about making it 3.0?). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5440) back-meta opens too many connections in case of error
by ali.pouya＠free.fr 01 Apr '08

01 Apr '08

Hi Pierangelo; When trying to reproduce the problem with test035 material I found a problem in my own JAVA code ! There is no such problem in back-meta :-) Sorry for misreporting and thanks for your help. The issue is to be closed. Best regards Ali Pierangelo Masarati a écrit : > ali.pouya(a)free.fr wrote: > >> I precise that The behaviour is not the same if the client binds with >> rootdn. > > I've committed a fix that removes dangling connections as the rootdn; > I have been unable to reproduce the issue with regular users. Please > provide more useful info in order to track the issue (slapd.conf, LDIF > and requests). > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

(ITS#5449) X-PIGLATIN password hashing functions
by mbackes＠symas.com 31 Mar '08

31 Mar '08

Full_Name: Matthew Backes Version: 2.x OS: any URL: http://www.symas.net/~lucca/piglatin-patch.txt Submission from: (NULL) (76.88.99.93) In order to improve the variety of security options available to LDAP administrators, I am submitting an additional password hashing method for liblutil. This patch implements the {X-PIGLATIN} hash, e.g.: $ slappasswd -s feep -h '{X-PIGLATIN}' {X-PIGLATIN}eepfay The standard with -yay variation for leading values is used, as described in http://en.wikipedia.org/wiki/Pig_latin y is considered a vowel unless it is the leading char. The patch will need additional review for EBCDIC support. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Matthew Backes <mbackes(a)symas.com>. I have not assigned rights and/or interest in this work to any party. diff -u -r1.107 passwd.c --- passwd.c 7 Jan 2008 23:20:06 -0000 1.107 +++ passwd.c 1 Apr 2008 03:13:13 -0000 @@ -119,6 +119,9 @@ #endif #endif +static LUTIL_PASSWD_CHK_FUNC chk_piglatin; +static LUTIL_PASSWD_HASH_FUNC hash_piglatin; + /* password hash routines */ #ifdef SLAPD_CLEARTEXT @@ -154,6 +157,7 @@ { BER_BVC("{CLEARTEXT}"), NULL, hash_clear }, #endif + { BER_BVC("{X-PIGLATIN}"), chk_piglatin, hash_piglatin }, { BER_BVNULL, NULL, NULL } }; @@ -1127,3 +1131,78 @@ } #endif +static int +chk_piglatin( + const struct berval *sc, + const struct berval * passwd, + const struct berval * cred, + const char **text ) +{ + struct berval credhash; + int rc; + + rc = hash_piglatin( sc, cred, &credhash, NULL ); + if( rc != LUTIL_PASSWD_OK ) return rc; + + rc = passwd->bv_len == credhash.bv_len + && memcmp( passwd->bv_val, + credhash.bv_val, + credhash.bv_len ) == 0 ? + LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK; + + ber_memfree( credhash.bv_val ); + return rc; +} + +/* Implement {X-PIGLATIN} + * See http://en.wikipedia.org/wiki/Pig_latin + * -yay variation for leading vowels used + * y is considered a vowel unless it is the leading char + */ + +static int +hash_piglatin( + const struct berval *scheme, + const struct berval *passwd, + struct berval *hash, + const char **text ) +{ + struct berval digest; + int c, rc, first_vowel = 0; + + hash->bv_len = scheme->bv_len + passwd->bv_len + 2; + hash->bv_val = ber_memalloc( scheme->bv_len + passwd->bv_len + 4 ); + if( !hash->bv_val ) return LUTIL_PASSWD_ERR; + + for( c = 0; c < passwd->bv_len; ++c ) { + switch( passwd->bv_val[c] & -33 ) { + case 'Y': + if( c==0 ) break; + case 'A': + case 'E': + case 'I': + case 'O': + case 'U': + first_vowel = c; + goto got_vowel; + } + } + +got_vowel: + if( first_vowel ) { + char * pos = hash->bv_val; + pos += sprintf( pos, "%s%s", + scheme->bv_val, + passwd->bv_val+first_vowel ); + snprintf( pos, first_vowel+1, "%s", + passwd->bv_val ); + pos += first_vowel; + sprintf( pos, "ay" ); + } else { + sprintf( hash->bv_val, "%s%syay", + scheme->bv_val, passwd->bv_val ); + hash->bv_len += 1; + } + + return LUTIL_PASSWD_OK; +} Also available from the provided URL.

1 0

(ITS#5448) CONTRIB: Java slapd
by hyc＠OpenLDAP.org 31 Mar '08

31 Mar '08

Full_Name: Howard Chu Version: 0.0.1 OS: URL: ftp://ftp.openldap.org/incoming/jslapd.tgz Submission from: (NULL) (76.91.220.157) Submitted by: hyc Given the increasing popularity of Java, I decided it was time that the OpenLDAP Project had its own Java implementation of an LDAP server. It gave me a good opportunity to explore all of the benefits of rapid development, introspection, and other advantages of the Java system. Indeed, drawing on my experience with the existing OpenLDAP code base, it took only a matter of hours to create my first working server, which I present here. Of course it's still experimental in nature. Invocation is similar to the regular C-based slapd, and it accepts all of the same arguments and reads all of the same config settings. In addition, the first commandline argument must be the name of the directory where slapd resides, so that the java app can locate the config files, schema, etc. E.g. for a typical OpenLDAP installation in /usr/local you would run java jslapd /usr/local/libexec -h ldap://:389 A small shell script has been provided to simplify this invocation.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2008