- openldap-bugs - openldap.org

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 20 Nov '09

20 Nov '09

<hyc(a)symas.com> wrote: > Peter Palmreuther wrote: >> <hyc(a)symas.com> wrote: [...[ >>> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >>> testing the RE24 code now, not 2.4.19.) >> [...] ran several thousand test iterations without a single failure yet. [...] >> Is this fix "back-portable" to 2.4.19 source, so I can compile a >> 2.4.19-custom version??? [...] > > The patch will be in 2.4.20, which will be released soon. Thanks a lot :-) Just for the record, so I can - close this case internally, and - justify the upcoming upgrade toward our change and release management: What was the problem? The second server sending back received synced operations or the first server processing those "send backs"? Or was it just "some pixie dust" on the WLAN cable? ;-) -- Regards, Peter

1 0

Re: (ITS#6390) test020 seg faults
by hyc＠symas.com 20 Nov '09

20 Nov '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.84.65) > > > Relevant build options: > CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" The SLAP_LIGHTWEIGHT_DISPATCHER symbol no longer exists in RE24; it was made the default long ago. Why are you testing a release candidate with -DDEVEL? You have no business defining this, not for release testing. That's for private test builds and *un*released features; i.e. things we are specifically excluding from consideration in the release process. You're still missing the majority of symbols in this trace. > Core was generated by > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. > Program terminated with signal 11, Segmentation fault. > #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 > Thread 1 (Thread 20194): > #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 > #1 0x000000000048e304 in syncrepl_add_glue (op=0x2b469b681e10, e=0x817aa8) at > syncrepl.c:2889 Your source seems to be corrupt or out of date. There is no call to memrchr anywhere near line 2889 in syncrepl.c > #2 0x00002b4697aa4b93 in ?? () > #3 0x00002b469b682024 in ?? () > #4 0x00002b469b681d2f in ?? () > #5 0x00002b46ffffffff in ?? () > #6 0x00002b469b683c20 in ?? () > #7 0x00002b469b682490 in ?? () > #8 0x00002b469505e460 in ?? () from /lib64/libc.so.6 > #9 0x0000000000000000 in ?? () Try to get a consistent build first... -- -- 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 20 Nov '09

20 Nov '09

Peter Palmreuther wrote: > <hyc(a)symas.com> wrote: >> Peter Palmreuther wrote: >>> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >>> I'fe corrected configuration and rerun test. >> >> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >> testing the RE24 code now, not 2.4.19.) > > I've checked out HEAD from CVSROOT > ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several > thousand test iterations without a single failure yet. > So I'd guess it seems to be fixed. > > How to continue best, getting a version ready for production? I > hesitate to simply compile HEAD for productive use, as I can't make > sure there's no change between latest stable / release and HEAD that > could lead to other trouble ... > Is this fix "back-portable" to 2.4.19 source, so I can compile a > 2.4.19-custom version??? > > Thanks in advance, The patch will be in 2.4.20, which will be released soon. -- -- 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#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 20 Nov '09

20 Nov '09

<hyc(a)symas.com> wrote: > Peter Palmreuther wrote: >> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >> I'fe corrected configuration and rerun test. > > Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be > testing the RE24 code now, not 2.4.19.) I've checked out HEAD from CVSROOT ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several thousand test iterations without a single failure yet. So I'd guess it seems to be fixed. How to continue best, getting a version ready for production? I hesitate to simply compile HEAD for productive use, as I can't make sure there's no change between latest stable / release and HEAD that could lead to other trouble ... Is this fix "back-portable" to 2.4.19 source, so I can compile a 2.4.19-custom version??? Thanks in advance, -- Regards, Peter

1 0

(ITS#6390) test020 seg faults
by michael＠stroeder.com 19 Nov '09

19 Nov '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.84.65) Relevant build options: CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" $ gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) Core was generated by `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. Program terminated with signal 11, Segmentation fault. #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) info threads 9 Thread 20130 0x00002b4694de831e in ?? () from /lib64/libc.so.6 8 Thread 20146 0x00002b4694de831e in ?? () from /lib64/libc.so.6 7 Thread 20083 0x00002b4694de831e in ?? () from /lib64/libc.so.6 6 Thread 20162 0x00002b4694dd4712 in select () from /lib64/libc.so.6 5 Thread 20082 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 4 Thread 20240 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 20067 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 2 Thread 20178 0x00002b4694dcde7b in write () from /lib64/libc.so.6 * 1 Thread 20194 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 9 (Thread 20130): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000aa1470 in ?? () #6 0x00002b469967d730 in ?? () #7 0x00002b469967d7c0 in ?? () #8 0x00002b469967d640 in ?? () #9 0x000000000099753a in ?? () #10 0x09802b469967d6f0 in ?? () #11 0x0000000000997538 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 8 (Thread 20146): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000bad820 in ?? () #6 0x00002b4699e7e730 in ?? () #7 0x00002b4699e7e7c0 in ?? () #8 0x00002b4699e7e640 in ?? () #9 0x0000000000aa2812 in ?? () #10 0x09802b4699e7e6f0 in ?? () #11 0x0000000000aa2810 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 7 (Thread 20083): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697430565 in ?? () #5 0x0000000000000000 in ?? () Thread 6 (Thread 20162): #0 0x00002b4694dd4712 in select () from /lib64/libc.so.6 #1 0x00002b4697430353 in ?? () #2 0x0000000000000000 in ?? () Thread 5 (Thread 20082): #0 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042ffd3 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2642 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () ---Type <return> to continue, or q <return> to quit--- Thread 4 (Thread 20240): #0 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b4692c72f85 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:672 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 20067): #0 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042d04c in slapd_set_write (s=<value optimized out>, wake=0) at daemon.c:962 #2 0x000000000041af37 in cfAddOverlay (p=0x2b469867e9e0, e=0x0, ca=0x4e72) at bconfig.c:4579 #3 0x0000000000000000 in ?? () Thread 2 (Thread 20178): #0 0x00002b4694dcde7b in write () from /lib64/libc.so.6 #1 0x00002b4694d78c53 in _IO_file_write () from /lib64/libc.so.6 #2 0x00002b4694d788ca in ?? () from /lib64/libc.so.6 #3 0x00002b4694d78bbe in _IO_file_xsputn () from /lib64/libc.so.6 #4 0x00002b4694d6df73 in fputs () from /lib64/libc.so.6 #5 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #6 0x00002b4697420e45 in ?? () #7 0x00002b469ae80b50 in ?? () #8 0x00002b469ae808f0 in ?? () #9 0x0000000000000100 in ?? () #10 0x0000000000000000 in ?? () Thread 1 (Thread 20194): #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 #1 0x000000000048e304 in syncrepl_add_glue (op=0x2b469b681e10, e=0x817aa8) at syncrepl.c:2889 #2 0x00002b4697aa4b93 in ?? () #3 0x00002b469b682024 in ?? () #4 0x00002b469b681d2f in ?? () #5 0x00002b46ffffffff in ?? () #6 0x00002b469b683c20 in ?? () #7 0x00002b469b682490 in ?? () #8 0x00002b469505e460 in ?? () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > Sorry, misconfiguration on my side when I replicated the real setup at my home server. > I'fe corrected configuration and rerun test. Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be testing the RE24 code now, not 2.4.19.) > 'debug-03' is put on known URL, server configuration is > > , [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap1/run/slapd.pid > argsfile /home/pit/esolution/ldap1/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap1/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 1 > mirrormode on > database monitor > ` > > , [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap2/run/slapd.pid > argsfile /home/pit/esolution/ldap2/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap2/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:10389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 2 > mirrormode on > database monitor > ` -- -- 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#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 19 Nov '09

19 Nov '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> This is low priority. Few platforms provide support for >> process/socket-specific keepalive settings. Usually you just set it >> system-wide in the kernel. (Note that a single setting is insufficient, there >> are 3 parameters that need to be set in concert.) > > I suggest moving this info into the slap_bindconf structure, to allow > its exploitation anywhere connections need to be set up, and defining a > syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty > value would mean use the default. Sounds OK. Ultimately we should consider moving syncrepl into its own config entry. Perhaps for 2.5. Not sure if that affects slap_bindconf or not; that still seems to be useful in its current form. -- -- 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#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.19 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.131.62.113) > >> When configuring a replica using syncrepl, it should be possible to have an >> option that sets the keepalive used for the tcp connection between the replica >> and master. Support for this was added to libldap, but no corresponding support >> was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for >> configuring this, based in seconds. > > This is low priority. Few platforms provide support for > process/socket-specific keepalive settings. Usually you just set it > system-wide in the kernel. (Note that a single setting is insufficient, there > are 3 parameters that need to be set in concert.) I suggest moving this info into the slap_bindconf structure, to allow its exploitation anywhere connections need to be set up, and defining a syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty value would mean use the default. p.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > Peter Palmreuther wrote: >> I modified slapd.conf to contain 'retry=3D"5 +"' instead of a 60 = second >> timeout. >>=20 >> I started both servers and checked "do_syncrepl" in server #1 was = followed >> by log information stating it connected to server #2. >>=20 >> I then rerun the test and this time it did not that much iterations, = but >> failed during the first run (with each run being 100 round of "add, = mod, >> delete"). >>=20 >> The URL with new log output is still the same, it's the = "debug-02.tar.*" >> files. >=20 > In both the new and old logs, the 2nd server is sending updates back = to the > first server. This can only happen if the serverID is misconfigured. = Please > post your slapd configs for both servers. Sorry, misconfiguration on my side when I replicated the real setup at = my home server. I'fe corrected configuration and rerun test. 'debug-03' is put on known URL, server configuration is ,=97=97=97=97=97 [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap1/run/slapd.pid argsfile /home/pit/esolution/ldap1/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap1/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:11389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 1 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 ,=97=97=97=97=97 [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap2/run/slapd.pid argsfile /home/pit/esolution/ldap2/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap2/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:10389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 2 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 --=20 Regards, Peter.=

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 19 Nov '09

19 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.19 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.131.62.113) > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. This is low priority. Few platforms provide support for process/socket-specific keepalive settings. Usually you just set it system-wide in the kernel. (Note that a single setting is insufficient, there are 3 parameters that need to be set in concert.) -- -- 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > I modified slapd.conf to contain 'retry="5 +"' instead of a 60 second > timeout. > > I started both servers and checked "do_syncrepl" in server #1 was followed > by log information stating it connected to server #2. > > I then rerun the test and this time it did not that much iterations, but > failed during the first run (with each run being 100 round of "add, mod, > delete"). > > The URL with new log output is still the same, it's the "debug-02.tar.*" > files. In both the new and old logs, the 2nd server is sending updates back to the first server. This can only happen if the serverID is misconfigured. Please post your slapd configs for both servers. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 19 Nov '09

19 Nov '09

CVS HEAD, including the two changes related to assertions (the change = log references ITS#6361), may fix this issue. I have been running the = new slapd for over 24 hours with no problems. This is much longer than = slapd would run for me before the new code.=

1 0

Re: (ITS#6166) Overlay/backend restructuring
by hyc＠symas.com 19 Nov '09

19 Nov '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE25/RE30 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Some wishes/loose thoughts about overlay/backend code: > > * Remove backends internally, making them like overlays? (RE30) > * Reduce copying of overlay data -op->o_bd->bd_info (RE25?) > * Lose slap_overinst, move its members into BackendInfo. * Re-factor Bind response handling to behave the same as every other request. (Instead of always deferring SUCCESS result to the frontend.) * Likewise for Extops. -- -- 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#6387) Valgrind reports issues in pcache
by hyc＠symas.com 19 Nov '09

19 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> Leaks are now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 18 Nov '09

18 Nov '09

hyc(a)symas.com wrote: > pitpalme+openldap(a)gmail.com wrote: >> [...] >> The logs are available here: >>=20 >> <url:http://pitpalme.is-a-geek.net/ldap/> >> [...] >=20 > The log shows that the problem is because the two servers are not = synchronized > before you begin your test. If you search for "do_syncrep" in the = ldap1 log, > you'll see that it was unable to connect to its provider at the very = beginning > of the file. It doesn't successfully connect until much later, 97% of = the way > down in the log file, after the majority of your testing has already = been > running. That delay is based on your syncrepl retry setting. Thanks for your analyses. I understand the servers were not immediately = synchronising, when I started to test. But the servers *were* = synchronized before the test started. I copied data directory of server = #1 to server #2, so they contained the very identical information. > When it finally connects it sends a somewhat out of date cookie to the = peer > server, and so it starts receiving results back. You get the "already = exists" > error because the entry you're trying to add has just been added by = syncrepl > itself. OK. > Part of the problem is the out-of-date cookie; the consumer checks = with > syncprov to make sure it has an up-to-date cookie but obviously in = your case > the cookie continues to change since you're still making changes to = the DB. > You can avoid this issue by making sure both servers' consumers are = connected > before performing any write ops, and you can assist in that by using a = faster > initial retry time in your syncrepl config. I modified slapd.conf to contain 'retry=3D"5 +"' instead of a 60 second = timeout. I started both servers and checked "do_syncrepl" in server #1 was = followed by log information stating it connected to server #2. I then rerun the test and this time it did not that much iterations, but = failed during the first run (with each run being 100 round of "add, mod, = delete"). The URL with new log output is still the same, it's the "debug-02.tar.*" = files. Thanks in advance. Regards, Peter=

1 0

(ITS#6389) Allow setting syncrepl keepalive
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.131.62.113) When configuring a replica using syncrepl, it should be possible to have an option that sets the keepalive used for the tcp connection between the replica and master. Support for this was added to libldap, but no corresponding support was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for configuring this, based in seconds.

1 0

Re: ITS#6290 dynamic group documentation
by gavin.henry＠gmail.com 18 Nov '09

18 Nov '09

Thanks all. Will fix next week. On 16/11/2009, jonathan(a)phillipoux.net <jonathan(a)phillipoux.net> wrote: > This is a multi-part message in MIME format. > --------------060504090007030105050009 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 16/11/2009 03:30, hyc(a)symas.com wrote: >> Yeah, the example should have used groupOfURLs instead of groupOfNames. >> Notice >> that "member" is not a valid attribute in the groupOfURLs class: it can >> not be >> used to store static members, only dynamic references. > > Quick patch to fix this attached. Note that the PNG image in > admin/allusersgroup-en.png needs to be regenerated from source SVG - the > PNG is also attached. > > -- > -------------------------------------------------------------- > Jonathan Clarke - jonathan(a)phillipoux.net > -------------------------------------------------------------- > Ldap Synchronization Connector (LSC) - http://lsc-project.org > -------------------------------------------------------------- > > --------------060504090007030105050009 > Content-Type: text/x-diff; > name="admin-guide-its-6290.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="admin-guide-its-6290.patch" > > Index: images/src/allusersgroup-en.svg > =================================================================== > RCS file: > /repo/OpenLDAP/pkg/openldap-guide/images/src/allusersgroup-en.svg,v > retrieving revision 1.1 > diff -u -p -u -r1.1 allusersgroup-en.svg > --- images/src/allusersgroup-en.svg 7 Nov 2007 22:52:55 -0000 1.1 > +++ images/src/allusersgroup-en.svg 16 Nov 2009 10:15:30 -0000 > @@ -106,7 +106,7 @@ > y="78.033184" > id="tspan5379">objectClass: <tspan > style="font-weight:bold" > - id="tspan5396">groupOfNames</tspan></tspan><tspan > + id="tspan5396">groupOfURLs</tspan></tspan><tspan > sodipodi:role="line" > x="116.88309" > y="92.036435" > Index: admin/overlays.sdf > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/overlays.sdf,v > retrieving revision 1.46 > diff -u -p -u -r1.46 overlays.sdf > --- admin/overlays.sdf 19 Aug 2009 17:23:43 -0000 1.46 > +++ admin/overlays.sdf 16 Nov 2009 10:15:31 -0000 > @@ -551,18 +551,23 @@ directory. > > In {{F:slapd.conf}}(5): > > +> include /path/to/dyngroup.schema > +> ... > > overlay dynlist > -> dynlist-attrset groupOfNames labeledURI member > +> dynlist-attrset groupOfURLs labeledURI member > + > +Note that we must include the {{F:dyngroup.schema}} file that defines the > +{{F:groupOfURLs}} objectClass used in this example. > > Let's apply it to the following entry: > > > cn=allusers,ou=group,dc=example,dc=com > > cn: all > -> objectClass: groupOfNames > +> objectClass: groupOfURLs > > labeledURI: > ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson) > > The behavior is similar to the dynamic list configuration we had before: > -whenever an entry with the {{F:groupOfNames}} object class is retrieved, > the > +whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the > search specified in the {{F:labeledURI}} attribute is performed. But this > time, > only the distinguished names of the results are added, and as values of the > {{F:member}} attribute. > Index: admin/allusersgroup-en.png > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/allusersgroup-en.png,v > retrieving revision 1.1 > diff -u -p -u -r1.1 allusersgroup-en.png > Binary files /tmp/cvsEkGNLJ and allusersgroup-en.png differ > > --------------060504090007030105050009 > Content-Type: image/png; > name="allusersgroup-en.png" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="allusersgroup-en.png" > > iVBORw0KGgoAAAANSUhEUgAAAaMAAABsCAYAAADHXN0hAAAABHNCSVQICAgIfAhkiAAAIABJ > REFUeJztnXecFEX2wL87s5HdZZe4JIkCKmIigyhggMPjlKAIKEbEAKbzPL3g6ZnwZzgVFRUV > 9cSAopJEPZKCZMlIhiUvcQPLApvm98frdnp6e7p7dnd2dqG+n898dru7pqr6dU29rqpX70Wh > KE98ka6AQqFQVEWiI12B05CmQE6kK6FQKBRViHeVMip/soDsSFdCoVAoqhD5nkjXQHFakQ60 > t/hfUfl5CRgT6UpEgHTKp52eqfIrN5QyqhjWIetJxcioaTFwP+A1pckBahnO3Qgsr6A6KhQK > RcRQyqjiuAWIBZoBzwKjgc9MaQqAv1ZwvU4Hqvp0c1Wvv0JRZpQyqjiKgULgKDAN+CMwEOhg > SPMf4G6gXpA8BgJDbMpoouWdA2QCHxmuZSCK7hdgG/A5EBPqTQDPAXuA48BvQG8X3ykk8J5e > BZ4xHL8AHELW27YBnbTzjZD7ydbq/3fDdzKAx4FlwGqHfMycDywAcpFpmttCqKtb2gNrkecw > HXiPwGkcq/qXpV4ZwD+B+cAG4GMg3qZ+lwBrDPVLNV23a0tuCfb8WiC/g0u04wbIc+uhHdu1 > sQzgXmATIqeXgbOAn4A8YBaQbErvVi527c1MRcjPLg+7thKqjBSnIT4gxeL8OuAmi/OrgYcN > aQYhDe517Zx5mu5t4JMgZXuB9cArQAKiaLoYrmcgIzGv9llCYAN2y0CgJhAFDEc6/mratXSs > 14zsOtIuWto62nEjoCHyorQK6cBjkQ5rIyIj/X6+1u4zyiYfMzHADqSj8SAvAzlANxd1dUsM > sBsYpR13RToFszIy1r+s9coAvkGerUfL+zmb+u0EHtLKvhzppPT6ObUlNzg9vxGIoqkG/ICs > uejYtbEMLX0q0Bw4AiwEWgNJiNJ51JCXk1zSkXbqVF8jFSE/uzyc2kqoMqoMTIx0BU43QlVG > s4CnDWkGIY3nGPImE8qaUVek0QWb8snA31hBpgpfMxxP0tJYfWbYlLsV/wgkndCV0YXAQaAX > gSO1TsgbqnFdbTQyotPvp6fhWrB8zHRH3sKNswLjgDdc1BXcyekyYK+p3C8pqYyM9S9rvTKA > qwzHvZDRoRXdgQNIR6rzraF+Tm3JjQycnh/AVGT0uAaIC1IWBLaxDOBKU72NcniQwI7NSS7p > SDt1U1+dipCfXR5ObSVUGVUGJqq56shSB5muMLId+BR4ApgdQl71gV1IpxUMo8n5CQKNJUYS > vEPIN6W7B6itldUAedsqLauBfwAvAi2BmUgn0Eirz3pD2lj8U1ogP0infA6ayktDpoCKDed2 > Au1c1teNnOoC+0zX9likN9a/rPUC6SCN/6cFSZem5W3cpL3D8L9TW3IjAzfPbzyikO4CTpny > t2tjGYb/T1ocm+vmRi5u6qtTEfKzy8NNWwlVRhFHKaPI0RKZ951vce0ZZH47PYT89iGjKS9Q > VIr6vIdMN1ixHOgDtAGeR97aNmrXNhP4hmhFPoGNPwWZttJ5V/vUAiYg0w+TgMPAubj3bGGV > zwOmNAeQjseD/8fcGH+H5VRXN3I6iHSgRhoRfKRSHvUC2XC9xvD/Aaw5gChMI3WRqUVwbktu > ZJCB/fNLQkZ37wNPApORF7PStjE7muIsF6f6GqkI+dnl4dRWqiTKgKHi8CDKvwZwDbLoORnr > abjdwAf415N07AwYliCN8XlkgTbUeeqRwEVBPjdraZKREVW6dnwVolSdWI1/2qAx0M9w7Txk > ztuDTE8e1/5fhHROTyFz5gCtCL4nJFg+ELjWthiZ339Uu94OGIZ/OsauruBOTouQDu0+7bgL > 0sHYUdZ6ATyCrBOkAH9DFLqOWQYeoK923BQxqNFxaktuZWD3/F5D2v6dyNTU29r50rYxO+zk > ouNU34qWn10eTm1FobBdM/JpnxxgKfLGHm1KY1wsrYd0qG4NGEB+FDOQzjgT+NBwLQMZien8 > A38H4JYoZF56KzAHMbRYh7+TTMd6zagTMtJbjiwmT8Q/h90JeWvNQRaqp+A3QmiIKOws7br+ > 1mh1P3b5zECsi3QuQBZ0c5GpkDtN+QSrayh0RKZ8dGurD5B1Oh1z/ctarwykTW1CZPAJ/k4V > SsqgPbASsa6chkwNG9e0mhK8Lbkl2PO7FllTq6mlS0La1DCc25hZbp/jNxQBsUb9ynDsJJd0 > /O3Urr1FQn52edi1lVBlVBmobGtYVZ5gykgRObxIJx7pOfLJyBpWuLBSbjqVRQaRwE4ubjmT > 5VdRKGVUzihlpNDpjN9ApBfyBnt2GMsrj073dETJpWqgrOkUijBxATJVGIuY6I5App4UCoUi > 7KiRkUKhUITORGVNp1AoFIqIo5TR6U06KqSDQqGoAihlpFAoFIqIo5SRQqFQKCKOUkYVQ1lC > OziFjShNSAeFQqGoVChlFH68wHfAFsTBYV1Kej64CPH03AoJvmf08H0V4j4oGL8iZsRJyA7w > L/C721coFArFGYiVaXdZQzuEipuQDgqFQlGZUKbdFUBpQjuE4nZkJBIUbA+icBpTtpAOCoVC > UeEoDwzhp6yhHewIh7t9hUKhqHDUyCj8lDW0g50BQzjc7SsUCkWFo5RR+ClGDBDaIJE9DyJT > a26xM2BYgoQTWIe42+9HYKRKhUKhUJyBKN90CoVCETrKgEGhUCgUkUcpI4VCoVBEHKWMFAqF > QhFxlDJSKBQKRcRRyijyOIVFTicynhMiVe7pRGNgAVCAGLcMimx1FIrKi1JGlZ8ngJ1lzGMP > 1oplILAYyANygf8BPcpY1pnCtcB84Biy12s1MJrADcd/R1w9LQIewu8pw0eg/8H3tHOfGM7p > 6XzI9oAjwGSgkUUaY14KRZVEeWCo/HwcpnzvAv4PGAXMQDq1K4EbgXlhKjNcxCCjj4rifvz+ > A1ciHtO7AK8jTm/v0K410/5O0D6lYRVwGLgUGADEIvvJFAqFIijB9hmdj0zX5CLTX7cZrmUA > DwCbEB91HyOeGnTS8Y9qGiGhKLK17/3dkC5YmIq3EL94+7S8hgMJWpphFnXV3+yN5dqFqXgB > 2cybhYTA6ORw3ikkRjetjBPIht63Ebm+YUhTqJ0bpdVzh3a+JTAFkc9JZNSn1zUV/0gjUTv3 > qnY8xiLvR7W8TwCf4veEXkOTgw940vC9fob8OyLP22f6nEPoIyM93SPa8TabNEY8wEvAfu2e > jiIjuTSLtApFpJkY6Qqcblgpoxiks/w70kF0QBSG7qk7AxmJpGrfnY90/jrpiFLwIG/JY5C3 > 4waIP7pBiN+79cAriKIxuxwyT9NdinRQRqVnRi8XRIHURBTVcETBVNPKSAfqaOkaAQ1tzoMo > F2OnayQFGQX4EJl8ifjzC6aMjiPxn/6LuEbSO+c5iAIpRkZMHQhURrpisVNG64G/aH99yKgH > ZHpOnzozP+vN2rV/IqOnXdrxj1pZdSmdMooDxmvHk4OkMdNHu7YGeBwZBS8FWlikVSgijVJG > 5YyVMuqOjBCM63Pj8HeuGQS6++lD4NtvOqIUOiFv/F7DtdFIZ+wUpsKsjK5FRkZ26OVaoYep > uBBxb9SLwICAwc47cSMiwz347/N7giujEYZzN2nn0vHLeqJ2bjyBykhXwnbKqKd23Es7Pqod > 36EdH7Oo/zwCFdcs7fhWQ5rSrBnpnzmIQrPLS2eAdm0B8sJyHsqBrqLyojwwVABpSKdRbDi3 > k8Dpkj2m/62mUhohb8jrkRHRRmRRPA53YSqMHEFGEnYjIyPBwlSsBv4BvKjl+QXSWQY770Q9 > 7e9m/B7ON9ikn2v4Xx95bcYv699M18x4g5wHv9GI/rcGIuvD2nEiUN30nfra38MER39GxrL1 > lwirda/5iBICGeE1tsnbyExgOvKi8iXSbrYhU4UKRaVDKaPwcwBRJEZZN9bO6xg7y0amazoZ > SCd3LtKhnAM0B/oTGKbCCp/p+FfkzX6ARVrz27MepuJGrW5NEYWkp3sXaIcs1ifgX8cKdt6O > fdrflvjvpY1N+pOG//cavqvL+lzDtXxDWn30amdS39aUJhM4hSiHE8j9P2BI3xeJ1Avwg02+ > unLrqP2NRuRkvGbkXeAKZNoxCVkDdMNJZB2rNjI6n4I8i1tdfl+hUFRhgq0Z7QQeQzrJdsh0 > 26Xa9QzkzTcFedP+Cen8ddLxrxmtAf6NdO4gnZ9+bT2yLmAVpmI1cL2pXiORDnYoMoWViqwN > jTOV2xnpzPVR1FX4Le/OQ97WPcg61mfAWJvzYG/AUB3/mtFiYCr+aTOraTqjmXMyosx8wM/I > aKxYS6t3/Fu061OBD/BPf1lN0+1Dps8OWJT/kOG7v2rl6d/70JDOapruVsN3lyJTnj5EwRnD > f5in4FoYyuhtSrMVkZf+uQy4Gpk2fBZpe6vwG2YoFJUNtWZUzgSzprsAWIhY0+0C7jRc063p > NiKGDZ/gVzYQuHbTEFnAztLSLkfWmEBGLDOQEU8mgZ3iUK2cLALXWQYhYSis9hnp5UYhHfFW > RGm+joSsuBJZN1qj1SULefuuY3Me7A0YQAw7NiBv9t8gIwMfsr6jY6WMAFrjtyg8hXT2fQ3X > eyHGJCcRhfQpwZXRndo9n0DW5RIJZCB+C8mT2v0+SOAI2EoZAdyLvDzkI0YYP1Nyf5fVepC+ > BvazKY35cx0yoluIyL8IWbccj994Q6GoTChlVM6EI4TETuDics6zMpNsOp6NyPXhCio/mKJT > KBThY6La9Fq5qY2MKPY4JTyNeBNZR1mDTPX1QkZ6n0ayUgqFQlGVKM+RUQdkCmiMU8LTjEcQ > 5VuIKKFp+I0JKgI1MlIoKh41TVfOqEivCoVCETpqn5FCoVAoIo9SRgqFQqGIOEoZhZ/ayPTd > xnJOW57fBVkryTUd+7R8Ac7Wjg9bpPEh3gM2EGiKbM7DDjf1N9exvBmE7EVyexxujPItQszt > K2KfUFnbkplwP7fKhJKdbLHQt4wcR7yB1Lc5DyhlpCgf/oVsED0H2d9UzzZ15aU/8G0IxxXF > v5DNq6mIN3Q7r+cKRaSph/imfATZu9gH8cAS7LwiDFgZMFi9Ka1AvDAUIZtRX0Hc3+hptyCb > S48hm2T/ZPhuX2Sz6ynE79t7yN4cq3KCpQW4G2kYRxGvzmUZGelpdC/V7YNc18MqWLnhsaq/ > Ux2d5JiOKMfjlJSjuS4xiPVeV5fH/bTy87X6/RfxbA5+WS3TjqO14wxD+V7tvNVHxyw/3bHr > m9qx3fO1q5+TfEJtS2acnttVSMDBE1rZH4Qol2B1GarV+3Mt3Wva8SPacbD2Ug//7+5d5M19 > OeLFZK5WzlzEP2FVl53d9+3aTCgyMroUG6F9722b86Cs6codt8ror4hLlyuAr7XrNxvS+hC3 > PI8hD/k44mj0fGQ6bIn2/b/id0FjLscu7UWIq5wsxPuDXofSKqPzEM8JJ5EfUmKQPEJRRm7q > 6EaOjyLTa8fwy9GqLlcjHZTHxfEF2r0dRtwq6a6FvjPJaol2bKWM1hnqaP4kaWl0+V2slblS > O34c++frVD8n+YTSlsw4Pbc2SGeXB/wNCUlifDt2kotTXSbgV9jFiFcSvRMM1l7qGcr4APgK > /9ToS0gnq8uqKsvO7vtObSYUGen00up+CPlN2J1XyqiccaOMEpE3i52I25qT2vWXDGkP4P8B > 6Q1yINKA9AZQiL+z2mtRjl1aPVCbHq20BiU7+gKsldEhQxrjmoYP+UF2tbiu56G/uVlhrr9T > Hd3IUXe8CjAJvxyt6vIW8I7LY122/6cdxyAvDUWIDz9dVou161bK6GLEP6HVR1eAZvnqeaZg > /3yd6uckn1Dakhmn5/Y303UzTnJxqkuiVm/j70I/H6y96B3tIeR31107Xql9d4h2/Banh+ys > vu/UZkKREYjbqWyt7rrDYrvzygNDBBihfSYjQdiuB54ieCdtFYNmAoG+2oot0til1f216V6v > T1l87yjyplcPeVvS14GswiMMQUZGo5A30o5Yh0PwIj8KPWCeG4LV0Y0cYxD5+ZDwD8HqAhLj > SfcZGOVw7IT+PHTP47Us0vyX4B7Jkwl8MdADGu7B7/BUx+r5XueynnbysSKUdmfXtiB4bCUn > uTjVpZohXRJ+57tu2ssRRBZ629W95+vyNq6xV2XZlSWulVsZRQH3If2IMQxMsPNBO8BIcTbi > HLMxMnx8wz55lSRW+5uDPMB+FmnqIm8Y6YjiyEOcY25GfkD9kWmmg8gbSpJ23sg0m7R6MLeh > iPPT3pRkCvLj/QQZqvfXzlst4M9C5ukvQUZG9+APMGdkDqK02iJTCnb8z6GObuRYG5mT3oEs > lupyNNclEZHLbO1aR4fj6Yj39NuRZ9RRq893SEeSgXQkbYDBWCuHwQQ6xDWSZzqeScmXALvn > O96hfvo0oJ183JY1GnmrronEsHJ6blO1vEZo97Qb8XbxtHbdSS52dbkf+Bix0Por8Azivb0r > 7tpLKFRF2dl936lNh0oq8CQSU+w7F+cB/zxjMTJ8Wow8VK8pTQ6Bb3g3IgtY5clY4OVyzrMi > cTNNVwPpvPMR5fKxdv1VQ9otiCLORRqM2YBhKdLZnUDCQ9xmUY5dWpCF0kPIM3+VkgulSci6 > VYZ2bS/ybIxvgeZpuK74h/LVLa6XxoAhWB3LKkdjXcbgX/TGxTFIZ7ZSKz8TUdrG38e92vmj > iAWceZrODU6m8XbP165+TvIJtS2la+lTtWOnttUbWUM5iUztvm8rBff3/RetHq9o6fT1mZex > by/6FJR+v5214++1Yz0C8dtUfdnZfd+uzYQiI5AoAj5kJG8k2PmJIIpmODJKqqlVaAsyD6qz > Dhme/Z/hXDiU0de4nwqJJDWRuETdTOetlJGi4gl1r8dGpD27Pa7qlOdemASkg53LmRHWXMku > PPyujG4yXWiNzKV30I7XIcPIHPxrB2Zl9AKi0bOQ8MadghR6Pv44MOn43xA+QoaSh7XzrSy+ > W5E0Q95o7kUWOScjZo9ZyFvDCkqO4pQyqhyU98bD043ylE8fpF9oWg55VQWU7MJDUAOGTYgC > 6o5/r8RGZD3nb8g0npEuyHzleYhCaoT1AnUMMof6HhKNsh0yD78ZuAXpyKdr1yuKGKTeF5k+ > Oci85g7tswhRktsRZaSovBxGvWnaUZ7y+R6Zkj1TULILE3YGDIeQeVYjTyHznS+azuchVixt > gfkEj7/TGVmLeB5Zo1qGDM+GAL+EUvEykARcjti6X46YF25H5jBXIcpwJTLXr1AoFIoKwE4Z > 1aFkh7wdCXL2BH7LIhAF9Q9ESbVErH9GI5YjRtIQRWU0a9yJjJDCRQyytnMF0BNRmEuQ+t+n > 1b001iIKhUKhKCeCKaOWyNrOfItrzyD24emm8+9qn1qITf3fkV3ERg4gU3ge/AqpMX5b9fKk > CzAMuAExyJiFKMxFBLffVygUCkUE8Bj+RiPTctcgU1WTsbaW2424g3jYcO48xNjBg981hpUT > 1sXIlN6j2vV2iMIwm82WluaIDftWZLf8LmTvSzfE2eQ8lCICGaH+gMhpL+L+w8iPiNNTJ+w2 > rp5Edm6Xlicoucnw38j64lbkBeM/2vnyKK8slEfZ5vuNQwxntiH3uwpxPVMWDiO/ie1avreW > Mb/ywouYPteJdEUUkcXozygHaRQPEDhqWkfgD6EeonB0ZdUJWKN9PwvZMBmsYV0ALESs6XYR > aMr9LaUz7W4PfImMsF7UyogEVcWargFwofb/hci+Ar0zvQrxO+UGO2XUkbIt9BYS2AY/QV6Q > 9HXMeMSQRt+fEUllVNZ7hZL3+wXSpvUNqm2QF8EBQb7vDXLeyGH8e7y6IM+9fvDkpS6nNNxJ > 1d5jqCgbVd43XTNkDSsdWaNKtE0dfsKljAYgLwRrEUMP46jFh4z6vkTWvwYbrvVE1sfWIG/W > fSzy7oW8FOhv5V8Q+OLhVPZTyIh3i6lso3Kwq8dVwK/atTVa2ue1vH9CRrMXICNqO9kay/sM > MY7ZgOzyNvon+xpYr5U51eG8W4xll+Z5BLvfVAK5Bb8vML2sZ7X63qOduxl5FgsRy9dCQ3qj > MgJZE9Z9Cdo9I3M5dvIqbVtNQdaYw6XsFJWbKquMopAfxUFkbSqYC4yKJhzKqBEy2myhHd+B > /JCNZeq7v5vhd+BYBzHH1/eFnYVMyRkVdjvEbN1oQHJAS+u27NHa/02QjdH6m7beQdvVo572 > nYu1ax788jOOFG5AOj07jArBaAX6ODLdBSXjESU7nAeZzkwP8qlmUXZpn4eb+22JrLXqHbaP > wA79LEThNNCO7ye4MuqDTFnXcVE3cznB5FXatqqzlvAaMykqL1VSGcUjb76LkR9nZSIcymgI > fpcbIB3RKfxv+z78frdA3qhjkQ7tIPKmrX82IxuadRYha4Q6MVp++jqMm7KN9zsd/6hK76Dt > 6nEj4uLfirIoo4eQkcHPyFu+fg9NkFHgG0jnmuxw3i1mZVSa51FaZVTNcH0IshdQJ4WSymgv > cq+r8Hswd6qbuZxg8iptW9X5EfdOXhWnF1XOa7cXmUbKQfYIKWMEId/wfzEywvAgb5pX2HzP > i2xw1tFd3Mdj7XW7NNjV4yLcrbWsRPaDpSA+u+zohvj36qil/QPwZ+3aTmTtpZdWn+eRkUKw > 83mIFWYwY45WlHRqCqV/HjqrEKMg8/12RabRigznrMq3ozclndS6qZuxnGDycoOVbHTiEfc4 > CkWl5zlkIbuy7q4P5zSdHoTKaurDSC7yo07TvtfDcK29Ke0fKVnf1YgFotuy9Wm6plhP09nV > Iw15W9en6bz410myCZxu+wwxYNAjT8YDD1LSgKEv8mav8yGiUECmr/Qp3ThgP2KBGey8W8wj > IyNun4f5fr9E/EPqBgznIQYMxvU8c1mNcT9NZ8SpbuZygsmrtG1V54Ch7oozi0oxTZeBu7eq > 1oh7nkhZTLkhXAYMA5F7/w2ZfjIGpbL7gffAv5C/EenMjWQgoxMjTyHejt2W/S+tjG0EOhM9 > id/Dt109rkRGAr8hb+c9tPPP4DdpTkCmc57VyklHFulfoqRpdwxiDfg/ZBT9Fn5l1BsZWazW > 6vG0w3m3uFFGYC8H8/0mIKbruhm2ecHfqiwQc+3tiFXs08hWC51gysipbuZy7ORV2rZ6If7I > uIozjyqljF7H/xZeWakqpt121EOmxcpi1ZSMTOtU1hHs6YxxbWc4fkVc2XkTCXinODMJuzJy > syblVhktp/Jb2pwOygikUzjbMZU1bZA1BXOwP0XF8CzyW1mPeMePtPd7N3iRjfCKM5eJEDz0 > QyPEw3Y2ojD+bvjic4iPuePIcNwYkTADMaddhvwgQKxvpiGGB5lIuAhj+ru0fPIQbwwxlGQd > wUPqVhZOF2WkUCgUFclEkPl33VtCI6AhYuGyColwGYssKm7Ev3g6EFlIjkKmArLwTw9kIBvi > 9BjxXkQpvYLMg8cgu78xpP8B8WlXVyvnNkryGZU/wJlSRgqFQhE6E6OQ/QU3Ik5RdXPeTojN > f038ZqSjEbNZK4WwFfExtwRRLkOQ6IUg5qjTEIudQovvmtM/jyg2s5PV3oiJ7tVu7y4C+IDU > Sa9MyvckxLnx7aZQKBRnJPkez+6hI/sd1g4nRmMd+qERYgm13vDdWPxmmiMRDwi1EQXTAL8J > Ksi0n059ZIOclSKySn+cknGUQEZPoxGXKB9ZXK80xKXERZ8s8IXq8yvsjHnj6WmAZ9A1g285 > u1mrw45fqEBefnvMhG4duj/XuV23LeZrE74Yf0dUVFTxrTfcOaG88jTy4rjnJl5x6dV/u6Rt > +52h1vtMw61MnSjtM63qKPn5iZatIMZjy9APkxAz0HMpaY7ZBhm9dMUfenczwS2n9iHuRbwE > btYrDXcj/rsOIT7HFKcJLZqe/UnD+meZ419VujwVCkV48GAd+mER4kTxKfyb21ohG+GSkV3S > 6dr5q7B3y7ME2cz2PP59IF1s0tuxB7H0egfZUKeIMCdOnigXLx7X9Rk0+6wGjZ28K0Q8T4VC > ER6igfeR3fPFyKjj39r/f0D29uxHFNRmZErvB8T/1Tpk+m0dgdN5ZooR/2dvIiOaQiTExKJS > 1nkF4mH4G8Ql0GicXcRElDFvPD0DoEXTlm/u3JN+Q3FxcULjho0/q1+3wdZf1yy7v6CwoE5q > So35t99416sx0THFABs2r683d9HsO3OPH7vA5/PFVEtI3NCtQ/d39Kmk0uSps2bDqkum/PjN > DYWFBbVSklMXDel/82spySmnXJY7DfA0b9zi7d37dg0AfH+++7HbZ8ya2q2ouCj6T1f3/ymI > DKbdeO1Nw5ue1SwT4IPP373L6/WevOX6Oz6GwOmLpSsXtfhl2fyHCwoL6iRWS/wtNiY2MyYm > NidUuRvzXLF2eZMFS38adfLkyeZerzenWeMWnw7oe/3/9LQ7dm07d96iOY8XFOSnpSSnLL7l > hjtfTohPKASZxmtYr9E3h44c6lxYVFAjMSFxs/G6GbuynOTglhfHPTexft0G049mHbm4sLAw > JbFa0uah/YePTU5KzgfYumNz7R9+mnnf8bzc86OiovIbpDWcOmzALV841c8pXyN2ZZhxeqab > tm2oO2v+j/ccz8ttCxSnVE9dPPKm+14JRSbB6rN+09r6M2ZPe7VHl55/63hxl207dm2r+dWM > L97scGGn53p0vWLtR5Pev+XQ0YNXFBUVJcXExB684JwL373yst4rdHk0bdTs0937dl1bWFhY > q06tujMv7XjZlJlzZzxy4mReq2oJib8N6z/8mZo1ap2o6vKzy8OpzYQio2B4EHf11RG3Ktfi > X7/Zi1jNpWrX2yNOEH3AKGQfSi/E5cj5+DfX1aOk76t0RCElI+tBtxqumdM/g0zH2bEVMbI4 > hijCYVSBDZbpu7cPS4iPTy8uLkpK373jzqUrF/8jLi5+D0Bm1tErZs6Z3h3gaOaRhBlzpr6Q > cyy7S/Wk6r/WqVV35vG83LazF/z43P4De5NLk6eR7Tu33Vw9KXmtx+Nm7zjrAAAORUlEQVTJ > y8rJvPyr6Z/fFmq5O3Zvvy2xWuLGpMSk3wD2H9x78f4DezuUVUYnTp6I/nnJT/+sn9bgf4/c > /djgNq3aTj6adbRHWfOc+8usf9WqUXv5I/c8Nqhr+0uf35q+eeT8JfPO09PsP7iv25Brh/1l > yHU335Z3Iq/5zDnTexrzyDmW3eLeW+9/9P47/jziVP6peubroZRVXuTk5rS455b7H3twxCN3 > FxUXJXz93aQhAMXFRVHTZk15MrFa4q7Rtz88ZNA1g0cfOJTRa/qsKZe6qV+wfI3YlWElE7tn > WlBY4Plu9rSnEuIT9t0z/P6ho29/eOj5rdqGNA1vV582rdvub9GkxYQFy+b/JftYdtyM2VMf > ql2zzqweXa9YC1C7Zp2tw/oPv+8v9zw+sHnj5l+uWLf8sexj2br3EA4czuh808BbH+p31XX3 > HT566Mrv5kx7rEeXXmNHDL1nqM9XHPP9vBlGZ8NVUn52ebhpM6HKyIqq5ijVSB5wH/AxMup6 > EPgngV6DKxVtWrd9o2+vfoteeeeFd/IL8hvVrlXnf7cNHvH++IlvPXAk88jVR7OONAd+mr/0 > p86FhYW142Ljdva7uv84gG9nftXw2PFj7Rcs/fmy6/sNmRFqnsZ6tD33wrG9e/Rd+sO87zqu > XPfrv45kHukJvB1KuWc3bfnuwGsG/y7rO4fe80Z5yGjZqsWtfb7imBv6DZni8Xh9Pbpesfa3 > zetWGNOM+3js47nHj1lulK6WUG3Lfbc++KQ5z2JfccKQ626a5PF4fV3aX7p5/eZ1czdv33R5 > 9049fgNo07rtl/XTGh4DqFWj9qKs7KMBvunatG47TR9hpqbUWGm+HkpZdoRyb62bnzNDr9M5 > Z587beW6X+8HPlr868JWBQX5acMG3PJRTHRMcbPGLY42qn/W9D37dnVbtmpxplP9guVrrItd > Gchm2wCZ2D3TJSsWti4sLKwxbMAtH8TFxhUBdOt4mb4e7UomTvUZeM3g79/88LWOH3z2zn8A > 3w39hv5bz+OaK//0i/7/dX0GzX75nReGrN+4pmnXDt03AZzb8vzJdWunHa9bO+343IWz1icm > Ju284LyL9gCk1a73S2ZOZsDG4qooP7s83LTpUGVkRVVWRjpLkHWvgYhV4PPAOCToXm4E61WC > 5o1bbAfwer3HKYBaNWpvBYiOjskFKC4ujgE4npdbC+BU/qkm//1qwmfGPHLzcuuVJk8jjRs0 > 2QXQqP5Zu1eu+5Xi4qKk43nHY0Ipt3WLc9eUVg525OTm1IiNiT3o8Xh/N5yJj084YEzTv8+g > sSdPnbTaGE1cbGyJqbOc3JwaMdExh415VkuodjD7WPbvXiZSklN/n+r1er0nCwrzjdahJFZL > Ov77dY83v8CXXz1Y/Z3KsiOUe0upnpql/59avUZWUWFRKkBmdmZtn88XM/b9V8bp130+X0xC > QrXtrmQRJF8jdmWY0zo90+yc7JoxMTGH9E6wNDJxU58WTc7+YdX6FU+0bNZqbGK1xN+90n81 > /fM/7N6/+5qiosLqUUQVFRYV1jxx6uTvMdJqpNTI1P/3eDz5CXEJ/mOvt8Bn+o1VRfnZ5eGm > zYQqIytOB2UEMnX4FeLcsSdwL+IW5XNEMTm+kZqIR5xflivR3uiAB+3xeCwbT2K1pCMAsbFx > uy887+K3jdeMDz2UPI3s2rfzrHNbtcnYs393I/mONzexWmJBKOXGx8WXmAO3IyoqqvBUvv8H > UVhYmOj1ekvIuHpS9czCwsKAH29+QX5KfFz876boX8/88oHjx3PbWpWTkJCwZdRtD/3TnGdB > YUHt4uKiKP0HlXcir05sTGyWVR5lwaksJzmEcm+Hjx6qiwRH5NCRg3W90d4sgOrJ1TO9Xm/O > gyMeudvYgQD8vHhuGydZBMs34D5tyrCSid0zTa2eeqSgoKBOQWGBx7y+6VYmTvU5mnkkYf3m > tXfVqlHrxx27tg/bf2DvL/XTGh5bsXZ5k+27tt/ap0ffP+tv8q+888J4u/txoirKzy6Pivr9 > nC7KSMcHzNE+DYARyObdfYjBw7eIV2InHkOmAccSgfgq3TtevnjL9k1H8/NPnbVl+8be1ZNT > tp88eaJmVk7WJZe0bV/m6bC1G1Y/kL5nx4qcY9ntAWrVqDWvrOU6GTDEx8VvX79p7UWtW5z7 > 45btm+pk52R1qlsnrcS8doeLOm9aumpJ1A/zvuvQu0ffZRu3/paWcyy7Y3xc/O9pr+09YOyJ > E3mx5u8CxMXFl4jDpOV56vMpEwfdeO2wr5atWtLiaNaRnp0v6fqk3T255b1Px40qKiqKH3nz > qJecynKSQyj3tnn7xoGXtG2/DmDj1g2Da9eoMx+gW4fuG5avXnrsk68/Gta/z/WTkpOS89du > WN3weF5uNTeyCJavEbsyOrfrtsVCJkGfaZf23TYtXbU4c+Lkj24deM3gT6Kjo4tXrFl2tj5N > 5EYmTvWZ/N0Xd1VLSNwyYti9r42fOG70tz98Peqe4aOfP3EiL8ETFZXfrHGLgwCz5/94cX5B > fpnCWFRF+dnlEe7fj05FKqN0xJ3Q8goqbx9imv4M4jniOiSqaD6ilL5F3OyXeJNAIoTORtak > HkNGWLZvL+VJzRq1TvTpec1ff14y7/ac3Jx2WTlZl0ZHR2cmVUta36j+WfvLmn+zxi3+m75n > x/XFxcUJqdVTfx7Q94YJZS13/8G9FxcVFcVjWp/S6XBhp3cXr1j48KvjX7wmNjbuUHJydcvI > rQnxCYWXduj+7OIVC+/fuHXD4Ojo6GPVk1KWGdM0rNcoJMu6hPiEwh5dej31y7KfR700bsyN > Hq/3WIsmLd+7rHNPOytQ15zKP1W7bq20ZW7KcpJDKPeWVrveL59M/vA/hUWFNVOSUxYP6HvD > pwAej9f3p94Dnvhh3nd3j/v49U8AT2xM7N42rdt+7EYWwfI1YleGlUzsnqnH4/X9odcfn5y9 > 4Md7xn38+qdollx6Z+pGJnb1mTlneufsnOz2wwYMvxdgYN8b3psw6b2xU374ume/q66dt3Hb > hoXvTnzrrdiYmEPVEhJ3xsXGlWnzc1WVX7A8wv370alIC7R0/MpoD6IcKkoxGblIK/taxNPE > AkT5LEBCJxQiFn7GzncpEuNnnkPePiB1yvtTik8W+EpYsSkqlpfeHvPhZZ0uf7rjxV22hauM > gsICz9j3Xxk38uZRo4zrEOEmXF4jyiPfSMmkMqDk556oKO+6G0b226Udlgg7Ho29257TgVXa > 50nEVVF34FLE3LwJYhBhfmvviPjO+wZxdb+1YqqqKC17M/ZULyoqTKmf1jCsbo9iomOKHx75 > 15HhLKOqoWRSNs5U+XkIDPmg+56zCx8RLOSEPqLQeRWZIjPzlpZuKjJaGu6QbzjZj7g+uh+J > NNkU2eibFiR9f8QY4i3EL5+iErJo+YJWEyd/NCGtTr2pygODQlE1iEKUzUIkpHGhdm4Fsl/n > CaTTnYN4X9iLhHLogCiORsjU1F7tu420/ECUUa72PbCfputik28kuBfZu2RHEaKkX8Nveaem > 6RQKhcIFwabpxuIPH9ERaIZ0tEWIIcCbiCLRwzu0RUJO7CmneuWFKd/SEIVY4VmRh0zxrUVC > b8zALzeFQqFQlBKP9tcYwsEYPmKj9nlIO7caf8iJI8AXSEC8shKufEvDXYiRQx4yYhyLrCe1 > RdwidUPcFT2BuDEqqyfyCmPMG09PG/PG0zO27thc6aYYX357zITFv/5i6XB3whfj7/hw0ntW > ARcVlQC7ZxcKZ+pzVvITPBbnMvCHjzhH+zRH1ktAwk20Q0ZPCfjXk/IRhaVjF/HUykw6WL4V > SRwSGt2oeHRXHlVK8VQ1VLgHheLMxkoZ2YWPOA/rkBMgo5srtf8bA/1syj2KKB0du3wrklPI > 2pVSPC6pzCEkwsWp/FPeSNdBoTjdsOpI7MJHZALjKRlyAsRR6YdIBNjdSKiJYLyATH+NB/4C > rLHJt8qjQkhEJoREqK7tnUIJNEhrOOXQkUNdfb7iuHp16s/KzMk8595b7n9WL+/9z965Owp8 > tw8Z+Y65LiqsRElUWInKL79whpXo0fXKocayPFiHfAgWPmIJwUNOLEGm9tojU3rD8FvSgSga > 3XruU63cVEQJ2eV72qBCSDhT3iEkQnFt7xRKIPtYdquRN9/3yAN3/vnezu26zj2Wm9Pu4OED > iSCjpaNZRy5r07rtbKt7UmElSspEhZWo3PILd1iJSVMn3mws73TzTVepUSEknCnvEBKhuLZ3 > DiVw3lQ9oF6zxi2OJlZLXD9/ybzuA68Z/P28hbPbeb3ROZ0u6VpiQ7QKK6HCSlRF+YU7rMSu > vTsDXsaUMqpAVAgJZ8o7hEQoru2dQgkYw0wANG7YdFb67h19ge937NrWM6122pxg96TCSgSi > wkpUfvmFPayEzxfgvFUpowpEhZCITAgJN5QmlEDPrlcuGvfx6/etWLu8Sc6xnI5XXHr1B1bp > VFgJa5mosBKBVDb5VXRYCaWMKiEqhET5hpBwQ2lCCSQnJefXSKnxy0+L5jyakJCwuWXz1r+v > c6qwEpEPi6DCSlStsBJKGVVCVAiJ8g0h4YYu7bttKk0ogdYtzp21cPmCq5s0avaq8bwKK1E5 > wiKosBJVJ6xERYaQOBNQvunOMLZs31Tn65lfvnvHkJHDateskwcqrIQVZ0pYBCuU/KxxCiGh > UChCYMGyn/+UmlJjvq6I4MwNAWCHkknZOBPkp5SRQlEKMrMz48dPfOuTmOiYQ3/o9ccnI10f > haKqo6bpyhcfkDp37tzjezYfrRPpyigUCkVlJZXY7H4j++kzChMjWpnTEB/2DmIVCoVCURK1 > ZhQGLkKCCioUCoXCHTXVNF35si3SFVAoFIqqyP8DrqC+qm2XwigAAAAASUVORK5CYII= > --------------060504090007030105050009-- > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6382) Error in set example (groups of groups)
by gavin.henry＠gmail.com 18 Nov '09

18 Nov '09

Thanks. Will fix this next week as I'm with my son in hospital until Friday. Gavin. On 16/11/2009, andreas(a)canonical.com <andreas(a)canonical.com> wrote: > Full_Name: Andreas Hasenack > Version: head > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz > Submission from: (NULL) (63.133.153.66) > > > The picture set-recursivegroup.png has a typo in the reference to > accountadm. It > should be under ou=group, not ou=people, in the upper left box. > > For reference, it's published here: > http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… > > The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg > file > (the source) as well as an exported png one. > > I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete > that > one. > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6371) problem with ber_flatten2
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

dave.daugherty(a)centrify.com writes: > Version: 2.2.6 and 2.4.17 This bug was fixed in OpenLDAP 2.4.18. > 1) Is the zero terminator really necessary? Yes. Much OpenLDAP code expects bervalues to be \0-terminated. lber.h now has a LBER_BV_NOTERM flag for not \0-terminating it. > 2) If so, seems like it should only be done if we actually allocated > a new buffer (which does leave one byte at the end). That would have been a cleaner default for the input value, but not for the output value:-( In any case, this function was probably first written for internal use - for accessing a BerElement. That code does deal with \0-termination. This quirk should be documented though. Currently ber_flatten is not documented at all. -- Hallvard

1 0

Re: (ITS#6386) Usage of ldap_init_fd
by hyc＠symas.com 18 Nov '09

18 Nov '09

vitaly.kroivets(a)gmail.com wrote: > Full_Name: Vitaly > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.115.180.11) > > > I try to use function ldap_init_fd, but it fails . Thanks for the report, a fix is now in CVS HEAD. Please test. > > ldap_init_fd (sockfd , 1 ,host_uri , &server); > > ... > rc = ldap_simple_bind_s(server, bind_dn, password); > if (rc != 0) { > fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); > return 1; > } > > rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, > ludp->lud_filter, ludp->lud_attrs, 0, &result); > > ... > fails with segmentation fault: > > #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 > #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, > errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 > #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, > lc=0x8073ae8, > result=0x8071ce0) at result.c:805 > #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, > timeout=0x8073ae8, > result=0x8071ce0) at result.c:390 > #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", > scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at > search.c:428 > #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 > (gdb) p lc > $1 = (struct ldap_conn *) 0x8073ae8 > (gdb) p *lc > $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, > lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, > lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, > lconn_ber = 0x0, lconn_next = 0x0} > (gdb) quit > > > > > -- -- 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 18 Nov '09

18 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Hello, > > hyc(a)symas.com wrote: > >> Paste the debug log somewhere we can see it then. Might as well use = > debug >> level -1 while executing this sequence. And provide the debug output = > from both >> servers. > > I=92ve got 60MiB of log files (cumulated from both servers) from running = > slapd with "-d Any=93.=20 > Sadly this erroneous behavior did only happened after a couple of test = > runs, so it=92s a lot of "everything works normal" in this files. > > The logs are available here: > > <url:http://pitpalme.is-a-geek.net/ldap/> > > They're both equal regarding contents, just compressed differently for = > faster download if 'xz' as compression tool is available. > > The test DN that fails is "cn=3DMax = > Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= > de". The log shows that the problem is because the two servers are not synchronized before you begin your test. If you search for "do_syncrep" in the ldap1 log, you'll see that it was unable to connect to its provider at the very beginning of the file. It doesn't successfully connect until much later, 97% of the way down in the log file, after the majority of your testing has already been running. That delay is based on your syncrepl retry setting. When it finally connects it sends a somewhat out of date cookie to the peer server, and so it starts receiving results back. You get the "already exists" error because the entry you're trying to add has just been added by syncrepl itself. Part of the problem is the out-of-date cookie; the consumer checks with syncprov to make sure it has an up-to-date cookie but obviously in your case the cookie continues to change since you're still making changes to the DB. You can avoid this issue by making sure both servers' consumers are connected before performing any write ops, and you can assist in that by using a faster initial retry time in your syncrepl config. -- -- 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#6387) Valgrind reports issues in pcache
by hyc＠symas.com 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD,re24,2.4.19 >> OS: irrelevant? >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.175.154.146) >> Submitted by: ando >> >> >> See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> > > The fix to ITS#6388 fixes the first valgrind warning of this ITS. The 2nd warning is just noise, you can shut it off in BerkeleyDB with "configure--enable-umrw" but the condition is harmless, and shutting it up imposes a performance penalty. -- -- 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#6383) Very Slow Query Response
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

--On November 18, 2009 9:39:02 AM +0000 Bill MacAllister <whm(a)stanford.edu> wrote: >> For historical note this was caused by Cyrus-sasl being built >> incorrectly by the debian packagers when heimdal is used. >> > > I don't understand why you refer to this finding as historical. Not a historical finding. As a record for anyone who comes across this ITS and wants to know what was found. > If I > am reading this correctly you and Howard have found the underlying > cause. Now that the problem is understood can you suggest a way for > us to cause the problem in our test environments? At this point we > will really need to convince ourselves that the problem is indeed fixed > before we try to deploy 2.4 in our production environment again. To note, first off, this issue was not a bug in OpenLDAP, and the project went beyond its scope in tracking down why cyrus-sasl was behaving the way it was. Finding out test cases for you to explore is also beyond the scope of the OpenLDAP project when dealing with non-OpenLDAP issues. However, given what is known, i.e., that the NTLM code path was being called during SASL/GSSAPI binds, I would suggest you either set up a number of windows boxes that try and do SASL/GSSAPI auth with NTLM to a test server, or write a script that does that and run it from multiple systems. Some reference points: <http://www.netid.washington.edu/documentation/ldapAuth.aspx> It also seems it may be possible to use python-ldap to do this. I don't know if it is possible with Net::LDAP or Net::LDAPapi --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it writes: > Hash marks as line-long comment indicators is documented in slapd.conf(5). > It is also documented in recent 2.4 ldap.conf(5). It doesn't actually mention the word "comment" though. I'll tweak a bit so a search for that word will find it, and expand the examples a bit. -- Hallvard

1 0

Re: (ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> The fix to ITS#6388 fixes the first valgrind warning of this ITS. p.

1 0

(ITS#6388) A timeout of { -1, 0 } allows to never time out
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Some code in back-ldap used a timeout of { -1, 0 } to disable any timeout set via ldap_set_option(). However, the code does not honor it (AFAIK). A fix that explicitly adds this feature is being committed (and documented in ldap_result(3)). p.

1 0

(ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD,re24,2.4.19 OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> p.

1 0

(ITS#6386) Usage of ldap_init_fd
by vitaly.kroivets＠gmail.com 18 Nov '09

18 Nov '09

Full_Name: Vitaly Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) I try to use function ldap_init_fd, but it fails . ldap_init_fd (sockfd , 1 ,host_uri , &server); ... rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); ... fails with segmentation fault: #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, lc=0x8073ae8, result=0x8071ce0) at result.c:805 #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, timeout=0x8073ae8, result=0x8071ce0) at result.c:390 #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at search.c:428 #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 (gdb) p lc $1 = (struct ldap_conn *) 0x8073ae8 (gdb) p *lc $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, lconn_ber = 0x0, lconn_next = 0x0} (gdb) quit

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 18 Nov '09

18 Nov '09

--On Tuesday, November 17, 2009 09:11:23 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > >> >> >> --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> >>> >>> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >>> >>>> Full_Name: Bill MacAllister >>>> Version: 2.4.19+ >>>> OS: Debian 5 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> On a system where slapd is the top CPU process and is consuming 4% >>>> of the >>>> CPU simple queries are taking ten of seconds to complete. Here is >>>> an >>>> example query: >>> >>> Last time we saw this it appeared that it might be related to DNS. >>> How long does a netstat -a take on the affected systems when the >>> LDAP queries are slow? >> >> I don't have that number. I have only see it once in the test >> environment I am not sure how long it will take me to get it. Since >> this plastered the production service today, I will have to reproduce >> it though before we attempt another production upgrade. >> >> Not clear to me why a DNS issue would appear only under load and not >> at other times. And it seems strange that it appears in >> lenny/openldap-2.4 and not in etch/openldap-2.3. >> >> Bill >> >> -- >> Bill MacAllister, System Software Programmer >> Unix Systems Group, Stanford University > > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. > > --Quanah I don't understand why you refer to this finding as historical. If I am reading this correctly you and Howard have found the underlying cause. Now that the problem is understood can you suggest a way for us to cause the problem in our test environments? At this point we will really need to convince ourselves that the problem is indeed fixed before we try to deploy 2.4 in our production environment again. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 18 Nov '09

18 Nov '09

Hello, hyc(a)symas.com wrote: > Paste the debug log somewhere we can see it then. Might as well use = debug > level -1 while executing this sequence. And provide the debug output = from both > servers. I=92ve got 60MiB of log files (cumulated from both servers) from running = slapd with "-d Any=93.=20 Sadly this erroneous behavior did only happened after a couple of test = runs, so it=92s a lot of "everything works normal" in this files. The logs are available here: <url:http://pitpalme.is-a-geek.net/ldap/> They're both equal regarding contents, just compressed differently for = faster download if 'xz' as compression tool is available. The test DN that fails is "cn=3DMax = Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= de". Thanks in advance and regards, Peter.=

1 0

(ITS#6385) Shutdown of broken syncrepl stanza cores
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando The test for SLAP_SYNC_SUBENTRY() is done on a NULL BackendDB *. A fix is coming. p.

1 0

Re: (ITS#6383) Very Slow Query Response
by rra＠stanford.edu 18 Nov '09

18 Nov '09

quanah(a)zimbra.com writes: > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. Well, rather, that's a theory which currently looks good. It definitely hasn't been proven yet. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> >> >> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >> >>> Full_Name: Bill MacAllister >>> Version: 2.4.19+ >>> OS: Debian 5 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> On a system where slapd is the top CPU process and is consuming 4% >>> of the >>> CPU simple queries are taking ten of seconds to complete. Here is >>> an >>> example query: >> >> Last time we saw this it appeared that it might be related to DNS. >> How long does a netstat -a take on the affected systems when the >> LDAP queries are slow? > > I don't have that number. I have only see it once in the test > environment I am not sure how long it will take me to get it. Since > this plastered the production service today, I will have to reproduce > it though before we attempt another production upgrade. > > Not clear to me why a DNS issue would appear only under load and not > at other times. And it seems strange that it appears in > lenny/openldap-2.4 and not in etch/openldap-2.3. > > Bill > > -- > Bill MacAllister, System Software Programmer > Unix Systems Group, Stanford University For historical note this was caused by Cyrus-sasl being built incorrectly by the debian packagers when heimdal is used. --Quanah

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by masarati＠aero.polimi.it 17 Nov '09

17 Nov '09

> sorry for two consecutive mails but I hit send before finishing to > think... where does is this bit about comments in the manual page? It > seems I'm not able to find it (nor the search facility in man too). I'm > doing man 5 ldap.conf, the man has all the configuration variables > explained well but not a word about where to put comments. Hash marks as line-long comment indicators is documented in slapd.conf(5). It is also documented in recent 2.4 ldap.conf(5). p.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

sorry for two consecutive mails but I hit send before finishing to think... where does is this bit about comments in the manual page? It seems I'm not able to find it (nor the search facility in man too). I'm doing man 5 ldap.conf, the man has all the configuration variables explained well but not a word about where to put comments.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

> Not a bug. Only lines beginning with "#" are comments as documented in > ldap.conf(5). yes, it might be a cool new feature... :)

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by rein＠OpenLDAP.org 17 Nov '09

17 Nov '09

luca.pasquali(a)dada.net wrote: > in ldap.conf if i configure like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ > dorius01 ~ # > > all works, but if I put a comment like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ # foobar comment blah blah... > dorius01 ~ # > > this does not work at all and I'm not able to login via ldap+ssh, for istance. Not a bug. Only lines beginning with "#" are comments as documented in ldap.conf(5). Rein

1 0

(ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

Full_Name: luca pasquali Version: 2.4.19 OS: gentoo GNU/Linux URL: Submission from: (NULL) (195.110.97.5) in ldap.conf if i configure like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ dorius01 ~ # all works, but if I put a comment like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ # foobar comment blah blah... dorius01 ~ # this does not work at all and I'm not able to login via ldap+ssh, for istance.

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 17 Nov '09

17 Nov '09

--On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > >> Full_Name: Bill MacAllister >> Version: 2.4.19+ >> OS: Debian 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> On a system where slapd is the top CPU process and is consuming 4% of the >> CPU simple queries are taking ten of seconds to complete. Here is an >> example query: > > Last time we saw this it appeared that it might be related to DNS. > How long does a netstat -a take on the affected systems when the > LDAP queries are slow? I don't have that number. I have only see it once in the test environment I am not sure how long it will take me to get it. Since this plastered the production service today, I will have to reproduce it though before we attempt another production upgrade. Not clear to me why a DNS issue would appear only under load and not at other times. And it seems strange that it appears in lenny/openldap-2.4 and not in etch/openldap-2.3. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 17 Nov '09

17 Nov '09

--On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.19+ > OS: Debian 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > On a system where slapd is the top CPU process and is consuming 4% of the > CPU simple queries are taking ten of seconds to complete. Here is an > example query: Last time we saw this it appeared that it might be related to DNS. How long does a netstat -a take on the affected systems when the LDAP queries are slow? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6383) Very Slow Query Response
by whm＠stanford.edu 16 Nov '09

16 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) On a system where slapd is the top CPU process and is consuming 4% of the CPU simple queries are taking ten of seconds to complete. Here is an example query: % time ldapsearch -x -h ldap1.stanford.edu -b dc=stanford,dc=edu uid=whm # extended LDIF # # LDAPv3 # base <dc=stanford,dc=edu> with scope subtree # filter: uid=whm # requesting: ALL # ...data... # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 0.001u 0.000s 0:18.13 0.0% 0+0k 0+0io 0pf+0w Here is a backtrace: ldap1:/var/log# gdb slapd 24029 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Attaching to program: /usr/sbin/slapd, process 24029 Reading symbols from /usr/lib/libtcmalloc_minimal.so.0...done. Loaded symbols for /usr/lib/libtcmalloc_minimal.so.0 Reading symbols from /usr/lib/libldap_r-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/libldap_r-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/libldap_r-2.4.so.2 Reading symbols from /usr/lib/liblber-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/liblber-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libdb-4.8.so...Reading symbols from /usr/lib/debug/usr/lib/libdb-4.8.so.debug...done. done. Loaded symbols for /usr/lib/libdb-4.8.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /usr/lib/libslp.so.1...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f89261b86f0 (LWP 24029)] [New Thread 0x44bef950 (LWP 24047)] [New Thread 0x443ee950 (LWP 24046)] [New Thread 0x40a74950 (LWP 24045)] [New Thread 0x43bed950 (LWP 24044)] [New Thread 0x433ec950 (LWP 24043)] [New Thread 0x42beb950 (LWP 24042)] [New Thread 0x423ea950 (LWP 24041)] [New Thread 0x41be9950 (LWP 24040)] [New Thread 0x413e8950 (LWP 24039)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 Reading symbols from /usr/lib/libgssapi.so.2...done. Loaded symbols for /usr/lib/libgssapi.so.2 Reading symbols from /usr/lib/libkrb5.so.25...done. Loaded symbols for /usr/lib/libkrb5.so.25 Reading symbols from /usr/lib/libasn1.so.8...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /usr/lib/libroken.so.18...done. Loaded symbols for /usr/lib/libroken.so.18 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libheimntlm.so.0...done. Loaded symbols for /usr/lib/libheimntlm.so.0 Reading symbols from /usr/lib/libhx509.so.3...done. Loaded symbols for /usr/lib/libhx509.so.3 Reading symbols from /usr/lib/libwind.so.0...done. Loaded symbols for /usr/lib/libwind.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2 Reading symbols from /usr/lib/ldap/back_monitor-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_monitor-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_monitor-2.4.so.2 Reading symbols from /usr/lib/ldap/valsort-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/valsort-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/valsort-2.4.so.2 Reading symbols from /usr/lib/ldap/dynlist-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/dynlist-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/dynlist-2.4.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb) thr apply all bt Thread 10 (Thread 0x413e8950 (LWP 24039)): #0 0x00007f8923e15b78 in epoll_wait () from /lib/libc.so.6 #1 0x0000000000438fdf in slapd_daemon_task (ptr=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2460 #2 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f8923e155ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x41be9950 (LWP 24040)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c2e2be0, buf=0x39a3740 "0\202\001�002\001\004d\202\001�\004*uid=carimer,cn=accounts,dc=stanford,dc=edu0\202\001\2170>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\003pts\004\004seas\004\bkerberos0\020\004\003uid1\t\004\acarimer0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201"..., len=458, dst=0x3c2e2c50) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x37a3f420, buf=0x39a3740, len=458) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3c2feb10, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3ca3d300, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3ca3d300, ber=0x41a674e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3a875800, ber=0x41a674e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3a875800, rs=0x41be8c90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3a875800, rs=0x41be8c90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3a875800, rs=0x41be8c90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x41be8de0, arg_v=0x3a875800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x41be8de0, argv=0x91) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 8 (Thread 0x423ea950 (LWP 24041)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df18a4 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x423e9de0, arg_v=0x3bb9b800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x423e9de0, argv=0x94) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 7 (Thread 0x42beb950 (LWP 24042)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df16f0 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #8 0x00000000004a8599 in slap_sasl_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #9 0x0000000000464126 in fe_op_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #10 0x0000000000463d2b in do_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #11 0x000000000043cbd6 in connection_operation (ctx=0x42beade0, arg_v=0x340cd800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #12 0x000000000043d162 in connection_read_thread (ctx=0x42beade0, argv=0x29) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #13 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #14 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #15 0x00007f8923e155ad in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 6 (Thread 0x433ec950 (LWP 24043)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x2e29e000, buf=0xe58cc10 "0\r\002\002\004He\a\n\001", len=15, dst=0x2e29e070) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x2e3f50f0, buf=0xe58cc10, len=15) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x2e389b70, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x2e3b88d0, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x2e3b88d0, ber=0x4326a480, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x33ce9400, ber=0x4326a480) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x00000000004528a1 in send_ldap_response (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:548 #16 0x00000000004531ee in slap_send_ldap_result (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:706 #17 0x00007f892059765d in hdb_search (op=0x33ce9400, rs=0x433ebc90) at search.c:1028 #18 0x00000000004c70be in overlay_op_walk (op=0x33ce9400, rs=0x433ebc90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #19 0x00000000004c72e5 in over_op_func (op=0x33ce9400, rs=0x433ebc90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #20 0x00000000004c73b3 in over_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #21 0x0000000000440844 in fe_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #22 0x00000000004401af in do_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #23 0x000000000043cbd6 in connection_operation (ctx=0x433ebde0, arg_v=0x33ce9400) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x433ebde0, argv=0x17) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 5 (Thread 0x43bed950 (LWP 24044)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2ebbed8) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x000000000043c414 in connection_next (c=0x2ebbec0, index=0x43beb96c) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:893 #5 0x00007f892036adfa in monitor_subsys_conn_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/conn.c:500 #6 0x00007f8920365077 in monitor_entry_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/entry.c:90 #7 0x00007f8920363420 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b680f8, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:53 #8 0x00007f89203635c7 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b68058, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:123 #9 0x00007f8920363a13 in monitor_back_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:245 #10 0x0000000000440844 in fe_op_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #11 0x00000000004401af in do_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #12 0x000000000043cbd6 in connection_operation (ctx=0x43becde0, arg_v=0x32d96c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #13 0x000000000043d162 in connection_read_thread (ctx=0x43becde0, argv=0x69) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #14 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #15 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #16 0x00007f8923e155ad in clone () from /lib/libc.so.6 #17 0x0000000000000000 in ?? () Thread 4 (Thread 0x40a74950 (LWP 24045)): #0 0x00007f8923e0ece2 in select () from /lib/libc.so.6 #1 0x00007f892193e729 in ?? () from /usr/lib/libkrb5.so.25 #2 0x00007f892193edce in krb5_sendto () from /usr/lib/libkrb5.so.25 #3 0x00007f892193f06f in krb5_sendto_context () from /usr/lib/libkrb5.so.25 #4 0x00007f892191eb34 in ?? () from /usr/lib/libkrb5.so.25 #5 0x00007f892191efbf in ?? () from /usr/lib/libkrb5.so.25 #6 0x00007f892191f89b in ?? () from /usr/lib/libkrb5.so.25 #7 0x00007f892191f94e in ?? () from /usr/lib/libkrb5.so.25 #8 0x00007f8921920054 in krb5_get_credentials_with_flags () from /usr/lib/libkrb5.so.25 #9 0x00007f89219300c2 in krb5_mk_req_exact () from /usr/lib/libkrb5.so.25 #10 0x00007f8921919a9c in ?? () from /usr/lib/libkrb5.so.25 #11 0x00007f8921919eb8 in krb5_digest_probe () from /usr/lib/libkrb5.so.25 #12 0x00007f8921bddf1b in ?? () from /usr/lib/libgssapi.so.2 #13 0x00007f8921bdbcd9 in ?? () from /usr/lib/libgssapi.so.2 #14 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #15 0x00007f8921be13f1 in ?? () from /usr/lib/libgssapi.so.2 #16 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #17 0x00007f8921df17ef in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #18 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #19 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #20 0x00000000004a8599 in slap_sasl_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #21 0x0000000000464126 in fe_op_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #22 0x0000000000463d2b in do_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #23 0x000000000043cbd6 in connection_operation (ctx=0x40a73de0, arg_v=0x3c185800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x40a73de0, argv=0x93) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 3 (Thread 0x443ee950 (LWP 24046)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df1c8e in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x443edde0, arg_v=0x354b8c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x443edde0, argv=0x96) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 2 (Thread 0x44bef950 (LWP 24047)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c934960, buf=0xfdea740 "0\202\001�002\001\004d\202\001�\004(uid=tayah,cn=accounts,dc=stanford,dc=edu0\202\001\2150>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\004seas\004\003pts\004\bkerberos0\016\004\003uid1\a\004\005tayah0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201�\004\vo"..., len=454, dst=0x3c9349d0) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x3cb61690, buf=0xfdea740, len=454) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3ca07cc0, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3caca750, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3caca750, ber=0x44a6d4e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3c185000, ber=0x44a6d4e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3c185000, rs=0x44beec90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3c185000, rs=0x44beec90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3c185000, rs=0x44beec90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x44beede0, arg_v=0x3c185000) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x44beede0, argv=0x82) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f89261b86f0 (LWP 24029)): #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 #1 0x00007f8925b1c5f3 in ldap_pvt_thread_join (thread=1094617424, thread_return=0x0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:197 #2 0x0000000000439d2e in slapd_daemon () at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2835 #3 0x000000000041afdd in main (argc=3, argv=0x7fff0941e0b8) at /tmp/buildd/openldap-2.4.19/servers/slapd/main.c:950 #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb)

1 0

(ITS#6382) Error in set example (groups of groups)
by andreas＠canonical.com 16 Nov '09

16 Nov '09

Full_Name: Andreas Hasenack Version: head OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz Submission from: (NULL) (63.133.153.66) The picture set-recursivegroup.png has a typo in the reference to accountadm. It should be under ou=group, not ou=people, in the upper left box. For reference, it's published here: http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg file (the source) as well as an exported png one. I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete that one.

1 0

RE : RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 16 Nov '09

16 Nov '09

i made the test look's good thank's Regard's=20 Olivier ________________________________________ De : Howard Chu [hyc(a)symas.com] Date d'envoi : dimanche 15 novembre 2009 19:16 =C0 : CHIROSSEL Olivier Cc : openldap-its(a)openldap.org Objet : Re: RE : (ITS#6367) syncprov ... changed by peer, ignored CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > =C0 : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry wh= ich be >> delete/add after master restart and before the reconnection of the slave= . > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set = up > this 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#6290 dynamic group documentation
by jonathan＠phillipoux.net 16 Nov '09

16 Nov '09

This is a multi-part message in MIME format. --------------060504090007030105050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 16/11/2009 03:30, hyc(a)symas.com wrote: > Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice > that "member" is not a valid attribute in the groupOfURLs class: it can not be > used to store static members, only dynamic references. Quick patch to fix this attached. Note that the PNG image in admin/allusersgroup-en.png needs to be regenerated from source SVG - the PNG is also attached. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------060504090007030105050009 Content-Type: text/x-diff; name="admin-guide-its-6290.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="admin-guide-its-6290.patch" Index: images/src/allusersgroup-en.svg =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/images/src/allusersgroup-en.svg,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.svg --- images/src/allusersgroup-en.svg 7 Nov 2007 22:52:55 -0000 1.1 +++ images/src/allusersgroup-en.svg 16 Nov 2009 10:15:30 -0000 @@ -106,7 +106,7 @@ y="78.033184" id="tspan5379">objectClass: <tspan style="font-weight:bold" - id="tspan5396">groupOfNames</tspan></tspan><tspan + id="tspan5396">groupOfURLs</tspan></tspan><tspan sodipodi:role="line" x="116.88309" y="92.036435" Index: admin/overlays.sdf =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/overlays.sdf,v retrieving revision 1.46 diff -u -p -u -r1.46 overlays.sdf --- admin/overlays.sdf 19 Aug 2009 17:23:43 -0000 1.46 +++ admin/overlays.sdf 16 Nov 2009 10:15:31 -0000 @@ -551,18 +551,23 @@ directory. In {{F:slapd.conf}}(5): +> include /path/to/dyngroup.schema +> ... > overlay dynlist -> dynlist-attrset groupOfNames labeledURI member +> dynlist-attrset groupOfURLs labeledURI member + +Note that we must include the {{F:dyngroup.schema}} file that defines the +{{F:groupOfURLs}} objectClass used in this example. Let's apply it to the following entry: > cn=allusers,ou=group,dc=example,dc=com > cn: all -> objectClass: groupOfNames +> objectClass: groupOfURLs > labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson) The behavior is similar to the dynamic list configuration we had before: -whenever an entry with the {{F:groupOfNames}} object class is retrieved, the +whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the search specified in the {{F:labeledURI}} attribute is performed. But this time, only the distinguished names of the results are added, and as values of the {{F:member}} attribute. Index: admin/allusersgroup-en.png =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/allusersgroup-en.png,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.png Binary files /tmp/cvsEkGNLJ and allusersgroup-en.png differ --------------060504090007030105050009 Content-Type: image/png; name="allusersgroup-en.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="allusersgroup-en.png" iVBORw0KGgoAAAANSUhEUgAAAaMAAABsCAYAAADHXN0hAAAABHNCSVQICAgIfAhkiAAAIABJ REFUeJztnXecFEX2wL87s5HdZZe4JIkCKmIigyhggMPjlKAIKEbEAKbzPL3g6ZnwZzgVFRUV 9cSAopJEPZKCZMlIhiUvcQPLApvm98frdnp6e7p7dnd2dqG+n898dru7pqr6dU29rqpX70Wh KE98ka6AQqFQVEWiI12B05CmQE6kK6FQKBRViHeVMip/soDsSFdCoVAoqhD5nkjXQHFakQ60 t/hfUfl5CRgT6UpEgHTKp52eqfIrN5QyqhjWIetJxcioaTFwP+A1pckBahnO3Qgsr6A6KhQK RcRQyqjiuAWIBZoBzwKjgc9MaQqAv1ZwvU4Hqvp0c1Wvv0JRZpQyqjiKgULgKDAN+CMwEOhg SPMf4G6gXpA8BgJDbMpoouWdA2QCHxmuZSCK7hdgG/A5EBPqTQDPAXuA48BvQG8X3ykk8J5e BZ4xHL8AHELW27YBnbTzjZD7ydbq/3fDdzKAx4FlwGqHfMycDywAcpFpmttCqKtb2gNrkecw HXiPwGkcq/qXpV4ZwD+B+cAG4GMg3qZ+lwBrDPVLNV23a0tuCfb8WiC/g0u04wbIc+uhHdu1 sQzgXmATIqeXgbOAn4A8YBaQbErvVi527c1MRcjPLg+7thKqjBSnIT4gxeL8OuAmi/OrgYcN aQYhDe517Zx5mu5t4JMgZXuB9cArQAKiaLoYrmcgIzGv9llCYAN2y0CgJhAFDEc6/mratXSs 14zsOtIuWto62nEjoCHyorQK6cBjkQ5rIyIj/X6+1u4zyiYfMzHADqSj8SAvAzlANxd1dUsM sBsYpR13RToFszIy1r+s9coAvkGerUfL+zmb+u0EHtLKvhzppPT6ObUlNzg9vxGIoqkG/ICs uejYtbEMLX0q0Bw4AiwEWgNJiNJ51JCXk1zSkXbqVF8jFSE/uzyc2kqoMqoMTIx0BU43QlVG s4CnDWkGIY3nGPImE8qaUVek0QWb8snA31hBpgpfMxxP0tJYfWbYlLsV/wgkndCV0YXAQaAX gSO1TsgbqnFdbTQyotPvp6fhWrB8zHRH3sKNswLjgDdc1BXcyekyYK+p3C8pqYyM9S9rvTKA qwzHvZDRoRXdgQNIR6rzraF+Tm3JjQycnh/AVGT0uAaIC1IWBLaxDOBKU72NcniQwI7NSS7p SDt1U1+dipCfXR5ObSVUGVUGJqq56shSB5muMLId+BR4ApgdQl71gV1IpxUMo8n5CQKNJUYS vEPIN6W7B6itldUAedsqLauBfwAvAi2BmUgn0Eirz3pD2lj8U1ogP0infA6ayktDpoCKDed2 Au1c1teNnOoC+0zX9likN9a/rPUC6SCN/6cFSZem5W3cpL3D8L9TW3IjAzfPbzyikO4CTpny t2tjGYb/T1ocm+vmRi5u6qtTEfKzy8NNWwlVRhFHKaPI0RKZ951vce0ZZH47PYT89iGjKS9Q VIr6vIdMN1ixHOgDtAGeR97aNmrXNhP4hmhFPoGNPwWZttJ5V/vUAiYg0w+TgMPAubj3bGGV zwOmNAeQjseD/8fcGH+H5VRXN3I6iHSgRhoRfKRSHvUC2XC9xvD/Aaw5gChMI3WRqUVwbktu ZJCB/fNLQkZ37wNPApORF7PStjE7muIsF6f6GqkI+dnl4dRWqiTKgKHi8CDKvwZwDbLoORnr abjdwAf415N07AwYliCN8XlkgTbUeeqRwEVBPjdraZKREVW6dnwVolSdWI1/2qAx0M9w7Txk ztuDTE8e1/5fhHROTyFz5gCtCL4nJFg+ELjWthiZ339Uu94OGIZ/OsauruBOTouQDu0+7bgL 0sHYUdZ6ATyCrBOkAH9DFLqOWQYeoK923BQxqNFxaktuZWD3/F5D2v6dyNTU29r50rYxO+zk ouNU34qWn10eTm1FobBdM/JpnxxgKfLGHm1KY1wsrYd0qG4NGEB+FDOQzjgT+NBwLQMZien8 A38H4JYoZF56KzAHMbRYh7+TTMd6zagTMtJbjiwmT8Q/h90JeWvNQRaqp+A3QmiIKOws7br+ 1mh1P3b5zECsi3QuQBZ0c5GpkDtN+QSrayh0RKZ8dGurD5B1Oh1z/ctarwykTW1CZPAJ/k4V SsqgPbASsa6chkwNG9e0mhK8Lbkl2PO7FllTq6mlS0La1DCc25hZbp/jNxQBsUb9ynDsJJd0 /O3Urr1FQn52edi1lVBlVBmobGtYVZ5gykgRObxIJx7pOfLJyBpWuLBSbjqVRQaRwE4ubjmT 5VdRKGVUzihlpNDpjN9ApBfyBnt2GMsrj073dETJpWqgrOkUijBxATJVGIuY6I5App4UCoUi 7KiRkUKhUITORGVNp1AoFIqIo5TR6U06KqSDQqGoAihlpFAoFIqIo5SRQqFQKCKOUkYVQ1lC OziFjShNSAeFQqGoVChlFH68wHfAFsTBYV1Kej64CPH03AoJvmf08H0V4j4oGL8iZsRJyA7w L/C721coFArFGYiVaXdZQzuEipuQDgqFQlGZUKbdFUBpQjuE4nZkJBIUbA+icBpTtpAOCoVC UeEoDwzhp6yhHewIh7t9hUKhqHDUyCj8lDW0g50BQzjc7SsUCkWFo5RR+ClGDBDaIJE9DyJT a26xM2BYgoQTWIe42+9HYKRKhUKhUJyBKN90CoVCETrKgEGhUCgUkUcpI4VCoVBEHKWMFAqF QhFxlDJSKBQKRcRRyijyOIVFTicynhMiVe7pRGNgAVCAGLcMimx1FIrKi1JGlZ8ngJ1lzGMP 1oplILAYyANygf8BPcpY1pnCtcB84Biy12s1MJrADcd/R1w9LQIewu8pw0eg/8H3tHOfGM7p 6XzI9oAjwGSgkUUaY14KRZVEeWCo/HwcpnzvAv4PGAXMQDq1K4EbgXlhKjNcxCCjj4rifvz+ A1ciHtO7AK8jTm/v0K410/5O0D6lYRVwGLgUGADEIvvJFAqFIijB9hmdj0zX5CLTX7cZrmUA DwCbEB91HyOeGnTS8Y9qGiGhKLK17/3dkC5YmIq3EL94+7S8hgMJWpphFnXV3+yN5dqFqXgB 2cybhYTA6ORw3ikkRjetjBPIht63Ebm+YUhTqJ0bpdVzh3a+JTAFkc9JZNSn1zUV/0gjUTv3 qnY8xiLvR7W8TwCf4veEXkOTgw940vC9fob8OyLP22f6nEPoIyM93SPa8TabNEY8wEvAfu2e jiIjuTSLtApFpJkY6Qqcblgpoxiks/w70kF0QBSG7qk7AxmJpGrfnY90/jrpiFLwIG/JY5C3 4waIP7pBiN+79cAriKIxuxwyT9NdinRQRqVnRi8XRIHURBTVcETBVNPKSAfqaOkaAQ1tzoMo F2OnayQFGQX4EJl8ifjzC6aMjiPxn/6LuEbSO+c5iAIpRkZMHQhURrpisVNG64G/aH99yKgH ZHpOnzozP+vN2rV/IqOnXdrxj1pZdSmdMooDxmvHk4OkMdNHu7YGeBwZBS8FWlikVSgijVJG 5YyVMuqOjBCM63Pj8HeuGQS6++lD4NtvOqIUOiFv/F7DtdFIZ+wUpsKsjK5FRkZ26OVaoYep uBBxb9SLwICAwc47cSMiwz347/N7giujEYZzN2nn0vHLeqJ2bjyBykhXwnbKqKd23Es7Pqod 36EdH7Oo/zwCFdcs7fhWQ5rSrBnpnzmIQrPLS2eAdm0B8sJyHsqBrqLyojwwVABpSKdRbDi3 k8Dpkj2m/62mUhohb8jrkRHRRmRRPA53YSqMHEFGEnYjIyPBwlSsBv4BvKjl+QXSWQY770Q9 7e9m/B7ON9ikn2v4Xx95bcYv699M18x4g5wHv9GI/rcGIuvD2nEiUN30nfra38MER39GxrL1 lwirda/5iBICGeE1tsnbyExgOvKi8iXSbrYhU4UKRaVDKaPwcwBRJEZZN9bO6xg7y0amazoZ SCd3LtKhnAM0B/oTGKbCCp/p+FfkzX6ARVrz27MepuJGrW5NEYWkp3sXaIcs1ifgX8cKdt6O fdrflvjvpY1N+pOG//cavqvL+lzDtXxDWn30amdS39aUJhM4hSiHE8j9P2BI3xeJ1Avwg02+ unLrqP2NRuRkvGbkXeAKZNoxCVkDdMNJZB2rNjI6n4I8i1tdfl+hUFRhgq0Z7QQeQzrJdsh0 26Xa9QzkzTcFedP+Cen8ddLxrxmtAf6NdO4gnZ9+bT2yLmAVpmI1cL2pXiORDnYoMoWViqwN jTOV2xnpzPVR1FX4Le/OQ97WPcg61mfAWJvzYG/AUB3/mtFiYCr+aTOraTqjmXMyosx8wM/I aKxYS6t3/Fu061OBD/BPf1lN0+1Dps8OWJT/kOG7v2rl6d/70JDOapruVsN3lyJTnj5EwRnD f5in4FoYyuhtSrMVkZf+uQy4Gpk2fBZpe6vwG2YoFJUNtWZUzgSzprsAWIhY0+0C7jRc063p NiKGDZ/gVzYQuHbTEFnAztLSLkfWmEBGLDOQEU8mgZ3iUK2cLALXWQYhYSis9hnp5UYhHfFW RGm+joSsuBJZN1qj1SULefuuY3Me7A0YQAw7NiBv9t8gIwMfsr6jY6WMAFrjtyg8hXT2fQ3X eyHGJCcRhfQpwZXRndo9n0DW5RIJZCB+C8mT2v0+SOAI2EoZAdyLvDzkI0YYP1Nyf5fVepC+ BvazKY35cx0yoluIyL8IWbccj994Q6GoTChlVM6EI4TETuDics6zMpNsOp6NyPXhCio/mKJT KBThY6La9Fq5qY2MKPY4JTyNeBNZR1mDTPX1QkZ6n0ayUgqFQlGVKM+RUQdkCmiMU8LTjEcQ 5VuIKKFp+I0JKgI1MlIoKh41TVfOqEivCoVCETpqn5FCoVAoIo9SRgqFQqGIOEoZhZ/ayPTd xnJOW57fBVkryTUd+7R8Ac7Wjg9bpPEh3gM2EGiKbM7DDjf1N9exvBmE7EVyexxujPItQszt K2KfUFnbkplwP7fKhJKdbLHQt4wcR7yB1Lc5DyhlpCgf/oVsED0H2d9UzzZ15aU/8G0IxxXF v5DNq6mIN3Q7r+cKRaSph/imfATZu9gH8cAS7LwiDFgZMFi9Ka1AvDAUIZtRX0Hc3+hptyCb S48hm2T/ZPhuX2Sz6ynE79t7yN4cq3KCpQW4G2kYRxGvzmUZGelpdC/V7YNc18MqWLnhsaq/ Ux2d5JiOKMfjlJSjuS4xiPVeV5fH/bTy87X6/RfxbA5+WS3TjqO14wxD+V7tvNVHxyw/3bHr m9qx3fO1q5+TfEJtS2acnttVSMDBE1rZH4Qol2B1GarV+3Mt3Wva8SPacbD2Ug//7+5d5M19 OeLFZK5WzlzEP2FVl53d9+3aTCgyMroUG6F9722b86Cs6codt8ror4hLlyuAr7XrNxvS+hC3 PI8hD/k44mj0fGQ6bIn2/b/id0FjLscu7UWIq5wsxPuDXofSKqPzEM8JJ5EfUmKQPEJRRm7q 6EaOjyLTa8fwy9GqLlcjHZTHxfEF2r0dRtwq6a6FvjPJaol2bKWM1hnqaP4kaWl0+V2slblS O34c++frVD8n+YTSlsw4Pbc2SGeXB/wNCUlifDt2kotTXSbgV9jFiFcSvRMM1l7qGcr4APgK /9ToS0gnq8uqKsvO7vtObSYUGen00up+CPlN2J1XyqiccaOMEpE3i52I25qT2vWXDGkP4P8B 6Q1yINKA9AZQiL+z2mtRjl1aPVCbHq20BiU7+gKsldEhQxrjmoYP+UF2tbiu56G/uVlhrr9T Hd3IUXe8CjAJvxyt6vIW8I7LY122/6cdxyAvDUWIDz9dVou161bK6GLEP6HVR1eAZvnqeaZg /3yd6uckn1Dakhmn5/Y303UzTnJxqkuiVm/j70I/H6y96B3tIeR31107Xql9d4h2/Banh+ys vu/UZkKREYjbqWyt7rrDYrvzygNDBBihfSYjQdiuB54ieCdtFYNmAoG+2oot0til1f216V6v T1l87yjyplcPeVvS14GswiMMQUZGo5A30o5Yh0PwIj8KPWCeG4LV0Y0cYxD5+ZDwD8HqAhLj SfcZGOVw7IT+PHTP47Us0vyX4B7Jkwl8MdADGu7B7/BUx+r5XueynnbysSKUdmfXtiB4bCUn uTjVpZohXRJ+57tu2ssRRBZ629W95+vyNq6xV2XZlSWulVsZRQH3If2IMQxMsPNBO8BIcTbi HLMxMnx8wz55lSRW+5uDPMB+FmnqIm8Y6YjiyEOcY25GfkD9kWmmg8gbSpJ23sg0m7R6MLeh iPPT3pRkCvLj/QQZqvfXzlst4M9C5ukvQUZG9+APMGdkDqK02iJTCnb8z6GObuRYG5mT3oEs lupyNNclEZHLbO1aR4fj6Yj39NuRZ9RRq893SEeSgXQkbYDBWCuHwQQ6xDWSZzqeScmXALvn O96hfvo0oJ183JY1GnmrronEsHJ6blO1vEZo97Qb8XbxtHbdSS52dbkf+Bix0Por8Azivb0r 7tpLKFRF2dl936lNh0oq8CQSU+w7F+cB/zxjMTJ8Wow8VK8pTQ6Bb3g3IgtY5clY4OVyzrMi cTNNVwPpvPMR5fKxdv1VQ9otiCLORRqM2YBhKdLZnUDCQ9xmUY5dWpCF0kPIM3+VkgulSci6 VYZ2bS/ybIxvgeZpuK74h/LVLa6XxoAhWB3LKkdjXcbgX/TGxTFIZ7ZSKz8TUdrG38e92vmj iAWceZrODU6m8XbP165+TvIJtS2la+lTtWOnttUbWUM5iUztvm8rBff3/RetHq9o6fT1mZex by/6FJR+v5214++1Yz0C8dtUfdnZfd+uzYQiI5AoAj5kJG8k2PmJIIpmODJKqqlVaAsyD6qz Dhme/Z/hXDiU0de4nwqJJDWRuETdTOetlJGi4gl1r8dGpD27Pa7qlOdemASkg53LmRHWXMku PPyujG4yXWiNzKV30I7XIcPIHPxrB2Zl9AKi0bOQ8MadghR6Pv44MOn43xA+QoaSh7XzrSy+ W5E0Q95o7kUWOScjZo9ZyFvDCkqO4pQyqhyU98bD043ylE8fpF9oWg55VQWU7MJDUAOGTYgC 6o5/r8RGZD3nb8g0npEuyHzleYhCaoT1AnUMMof6HhKNsh0yD78ZuAXpyKdr1yuKGKTeF5k+ Oci85g7tswhRktsRZaSovBxGvWnaUZ7y+R6Zkj1TULILE3YGDIeQeVYjTyHznS+azuchVixt gfkEj7/TGVmLeB5Zo1qGDM+GAL+EUvEykARcjti6X46YF25H5jBXIcpwJTLXr1AoFIoKwE4Z 1aFkh7wdCXL2BH7LIhAF9Q9ESbVErH9GI5YjRtIQRWU0a9yJjJDCRQyytnMF0BNRmEuQ+t+n 1b001iIKhUKhKCeCKaOWyNrOfItrzyD24emm8+9qn1qITf3fkV3ERg4gU3ge/AqpMX5b9fKk CzAMuAExyJiFKMxFBLffVygUCkUE8Bj+RiPTctcgU1WTsbaW2424g3jYcO48xNjBg981hpUT 1sXIlN6j2vV2iMIwm82WluaIDftWZLf8LmTvSzfE2eQ8lCICGaH+gMhpL+L+w8iPiNNTJ+w2 rp5Edm6Xlicoucnw38j64lbkBeM/2vnyKK8slEfZ5vuNQwxntiH3uwpxPVMWDiO/ie1avreW Mb/ywouYPteJdEUUkcXozygHaRQPEDhqWkfgD6EeonB0ZdUJWKN9PwvZMBmsYV0ALESs6XYR aMr9LaUz7W4PfImMsF7UyogEVcWargFwofb/hci+Ar0zvQrxO+UGO2XUkbIt9BYS2AY/QV6Q 9HXMeMSQRt+fEUllVNZ7hZL3+wXSpvUNqm2QF8EBQb7vDXLeyGH8e7y6IM+9fvDkpS6nNNxJ 1d5jqCgbVd43XTNkDSsdWaNKtE0dfsKljAYgLwRrEUMP46jFh4z6vkTWvwYbrvVE1sfWIG/W fSzy7oW8FOhv5V8Q+OLhVPZTyIh3i6lso3Kwq8dVwK/atTVa2ue1vH9CRrMXICNqO9kay/sM MY7ZgOzyNvon+xpYr5U51eG8W4xll+Z5BLvfVAK5Bb8vML2sZ7X63qOduxl5FgsRy9dCQ3qj MgJZE9Z9Cdo9I3M5dvIqbVtNQdaYw6XsFJWbKquMopAfxUFkbSqYC4yKJhzKqBEy2myhHd+B /JCNZeq7v5vhd+BYBzHH1/eFnYVMyRkVdjvEbN1oQHJAS+u27NHa/02QjdH6m7beQdvVo572 nYu1ax788jOOFG5AOj07jArBaAX6ODLdBSXjESU7nAeZzkwP8qlmUXZpn4eb+22JrLXqHbaP wA79LEThNNCO7ye4MuqDTFnXcVE3cznB5FXatqqzlvAaMykqL1VSGcUjb76LkR9nZSIcymgI fpcbIB3RKfxv+z78frdA3qhjkQ7tIPKmrX82IxuadRYha4Q6MVp++jqMm7KN9zsd/6hK76Dt 6nEj4uLfirIoo4eQkcHPyFu+fg9NkFHgG0jnmuxw3i1mZVSa51FaZVTNcH0IshdQJ4WSymgv cq+r8Hswd6qbuZxg8iptW9X5EfdOXhWnF1XOa7cXmUbKQfYIKWMEId/wfzEywvAgb5pX2HzP i2xw1tFd3Mdj7XW7NNjV4yLcrbWsRPaDpSA+u+zohvj36qil/QPwZ+3aTmTtpZdWn+eRkUKw 83mIFWYwY45WlHRqCqV/HjqrEKMg8/12RabRigznrMq3ozclndS6qZuxnGDycoOVbHTiEfc4 CkWl5zlkIbuy7q4P5zSdHoTKaurDSC7yo07TvtfDcK29Ke0fKVnf1YgFotuy9Wm6plhP09nV Iw15W9en6bz410myCZxu+wwxYNAjT8YDD1LSgKEv8mav8yGiUECmr/Qp3ThgP2KBGey8W8wj IyNun4f5fr9E/EPqBgznIQYMxvU8c1mNcT9NZ8SpbuZygsmrtG1V54Ch7oozi0oxTZeBu7eq 1oh7nkhZTLkhXAYMA5F7/w2ZfjIGpbL7gffAv5C/EenMjWQgoxMjTyHejt2W/S+tjG0EOhM9 id/Dt109rkRGAr8hb+c9tPPP4DdpTkCmc57VyklHFulfoqRpdwxiDfg/ZBT9Fn5l1BsZWazW 6vG0w3m3uFFGYC8H8/0mIKbruhm2ecHfqiwQc+3tiFXs08hWC51gysipbuZy7ORV2rZ6If7I uIozjyqljF7H/xZeWakqpt121EOmxcpi1ZSMTOtU1hHs6YxxbWc4fkVc2XkTCXinODMJuzJy syblVhktp/Jb2pwOygikUzjbMZU1bZA1BXOwP0XF8CzyW1mPeMePtPd7N3iRjfCKM5eJEDz0 QyPEw3Y2ojD+bvjic4iPuePIcNwYkTADMaddhvwgQKxvpiGGB5lIuAhj+ru0fPIQbwwxlGQd wUPqVhZOF2WkUCgUFclEkPl33VtCI6AhYuGyColwGYssKm7Ev3g6EFlIjkKmArLwTw9kIBvi 9BjxXkQpvYLMg8cgu78xpP8B8WlXVyvnNkryGZU/wJlSRgqFQhE6E6OQ/QU3Ik5RdXPeTojN f038ZqSjEbNZK4WwFfExtwRRLkOQ6IUg5qjTEIudQovvmtM/jyg2s5PV3oiJ7tVu7y4C+IDU Sa9MyvckxLnx7aZQKBRnJPkez+6hI/sd1g4nRmMd+qERYgm13vDdWPxmmiMRDwi1EQXTAL8J Ksi0n059ZIOclSKySn+cknGUQEZPoxGXKB9ZXK80xKXERZ8s8IXq8yvsjHnj6WmAZ9A1g285 u1mrw45fqEBefnvMhG4duj/XuV23LeZrE74Yf0dUVFTxrTfcOaG88jTy4rjnJl5x6dV/u6Rt +52h1vtMw61MnSjtM63qKPn5iZatIMZjy9APkxAz0HMpaY7ZBhm9dMUfenczwS2n9iHuRbwE btYrDXcj/rsOIT7HFKcJLZqe/UnD+meZ419VujwVCkV48GAd+mER4kTxKfyb21ohG+GSkV3S 6dr5q7B3y7ME2cz2PP59IF1s0tuxB7H0egfZUKeIMCdOnigXLx7X9Rk0+6wGjZ28K0Q8T4VC ER6igfeR3fPFyKjj39r/f0D29uxHFNRmZErvB8T/1Tpk+m0dgdN5ZooR/2dvIiOaQiTExKJS 1nkF4mH4G8Ql0GicXcRElDFvPD0DoEXTlm/u3JN+Q3FxcULjho0/q1+3wdZf1yy7v6CwoE5q So35t99416sx0THFABs2r683d9HsO3OPH7vA5/PFVEtI3NCtQ/d39Kmk0uSps2bDqkum/PjN DYWFBbVSklMXDel/82spySmnXJY7DfA0b9zi7d37dg0AfH+++7HbZ8ya2q2ouCj6T1f3/ymI DKbdeO1Nw5ue1SwT4IPP373L6/WevOX6Oz6GwOmLpSsXtfhl2fyHCwoL6iRWS/wtNiY2MyYm NidUuRvzXLF2eZMFS38adfLkyeZerzenWeMWnw7oe/3/9LQ7dm07d96iOY8XFOSnpSSnLL7l hjtfTohPKASZxmtYr9E3h44c6lxYVFAjMSFxs/G6GbuynOTglhfHPTexft0G049mHbm4sLAw JbFa0uah/YePTU5KzgfYumNz7R9+mnnf8bzc86OiovIbpDWcOmzALV841c8pXyN2ZZhxeqab tm2oO2v+j/ccz8ttCxSnVE9dPPKm+14JRSbB6rN+09r6M2ZPe7VHl55/63hxl207dm2r+dWM L97scGGn53p0vWLtR5Pev+XQ0YNXFBUVJcXExB684JwL373yst4rdHk0bdTs0937dl1bWFhY q06tujMv7XjZlJlzZzxy4mReq2oJib8N6z/8mZo1ap2o6vKzy8OpzYQio2B4EHf11RG3Ktfi X7/Zi1jNpWrX2yNOEH3AKGQfSi/E5cj5+DfX1aOk76t0RCElI+tBtxqumdM/g0zH2bEVMbI4 hijCYVSBDZbpu7cPS4iPTy8uLkpK373jzqUrF/8jLi5+D0Bm1tErZs6Z3h3gaOaRhBlzpr6Q cyy7S/Wk6r/WqVV35vG83LazF/z43P4De5NLk6eR7Tu33Vw9KXmtx+Nm7zjrAAAORUlEQVTJ y8rJvPyr6Z/fFmq5O3Zvvy2xWuLGpMSk3wD2H9x78f4DezuUVUYnTp6I/nnJT/+sn9bgf4/c /djgNq3aTj6adbRHWfOc+8usf9WqUXv5I/c8Nqhr+0uf35q+eeT8JfPO09PsP7iv25Brh/1l yHU335Z3Iq/5zDnTexrzyDmW3eLeW+9/9P47/jziVP6peubroZRVXuTk5rS455b7H3twxCN3 FxUXJXz93aQhAMXFRVHTZk15MrFa4q7Rtz88ZNA1g0cfOJTRa/qsKZe6qV+wfI3YlWElE7tn WlBY4Plu9rSnEuIT9t0z/P6ho29/eOj5rdqGNA1vV582rdvub9GkxYQFy+b/JftYdtyM2VMf ql2zzqweXa9YC1C7Zp2tw/oPv+8v9zw+sHnj5l+uWLf8sexj2br3EA4czuh808BbH+p31XX3 HT566Mrv5kx7rEeXXmNHDL1nqM9XHPP9vBlGZ8NVUn52ebhpM6HKyIqq5ijVSB5wH/AxMup6 EPgngV6DKxVtWrd9o2+vfoteeeeFd/IL8hvVrlXnf7cNHvH++IlvPXAk88jVR7OONAd+mr/0 p86FhYW142Ljdva7uv84gG9nftXw2PFj7Rcs/fmy6/sNmRFqnsZ6tD33wrG9e/Rd+sO87zqu XPfrv45kHukJvB1KuWc3bfnuwGsG/y7rO4fe80Z5yGjZqsWtfb7imBv6DZni8Xh9Pbpesfa3 zetWGNOM+3js47nHj1lulK6WUG3Lfbc++KQ5z2JfccKQ626a5PF4fV3aX7p5/eZ1czdv33R5 9049fgNo07rtl/XTGh4DqFWj9qKs7KMBvunatG47TR9hpqbUWGm+HkpZdoRyb62bnzNDr9M5 Z587beW6X+8HPlr868JWBQX5acMG3PJRTHRMcbPGLY42qn/W9D37dnVbtmpxplP9guVrrItd Gchm2wCZ2D3TJSsWti4sLKwxbMAtH8TFxhUBdOt4mb4e7UomTvUZeM3g79/88LWOH3z2zn8A 3w39hv5bz+OaK//0i/7/dX0GzX75nReGrN+4pmnXDt03AZzb8vzJdWunHa9bO+343IWz1icm Ju284LyL9gCk1a73S2ZOZsDG4qooP7s83LTpUGVkRVVWRjpLkHWvgYhV4PPAOCToXm4E61WC 5o1bbAfwer3HKYBaNWpvBYiOjskFKC4ujgE4npdbC+BU/qkm//1qwmfGPHLzcuuVJk8jjRs0 2QXQqP5Zu1eu+5Xi4qKk43nHY0Ipt3WLc9eUVg525OTm1IiNiT3o8Xh/N5yJj084YEzTv8+g sSdPnbTaGE1cbGyJqbOc3JwaMdExh415VkuodjD7WPbvXiZSklN/n+r1er0nCwrzjdahJFZL Ov77dY83v8CXXz1Y/Z3KsiOUe0upnpql/59avUZWUWFRKkBmdmZtn88XM/b9V8bp130+X0xC QrXtrmQRJF8jdmWY0zo90+yc7JoxMTGH9E6wNDJxU58WTc7+YdX6FU+0bNZqbGK1xN+90n81 /fM/7N6/+5qiosLqUUQVFRYV1jxx6uTvMdJqpNTI1P/3eDz5CXEJ/mOvt8Bn+o1VRfnZ5eGm zYQqIytOB2UEMnX4FeLcsSdwL+IW5XNEMTm+kZqIR5xflivR3uiAB+3xeCwbT2K1pCMAsbFx uy887+K3jdeMDz2UPI3s2rfzrHNbtcnYs393I/mONzexWmJBKOXGx8WXmAO3IyoqqvBUvv8H UVhYmOj1ekvIuHpS9czCwsKAH29+QX5KfFz876boX8/88oHjx3PbWpWTkJCwZdRtD/3TnGdB YUHt4uKiKP0HlXcir05sTGyWVR5lwaksJzmEcm+Hjx6qiwRH5NCRg3W90d4sgOrJ1TO9Xm/O gyMeudvYgQD8vHhuGydZBMs34D5tyrCSid0zTa2eeqSgoKBOQWGBx7y+6VYmTvU5mnkkYf3m tXfVqlHrxx27tg/bf2DvL/XTGh5bsXZ5k+27tt/ap0ffP+tv8q+888J4u/txoirKzy6Pivr9 nC7KSMcHzNE+DYARyObdfYjBw7eIV2InHkOmAccSgfgq3TtevnjL9k1H8/NPnbVl+8be1ZNT tp88eaJmVk7WJZe0bV/m6bC1G1Y/kL5nx4qcY9ntAWrVqDWvrOU6GTDEx8VvX79p7UWtW5z7 45btm+pk52R1qlsnrcS8doeLOm9aumpJ1A/zvuvQu0ffZRu3/paWcyy7Y3xc/O9pr+09YOyJ E3mx5u8CxMXFl4jDpOV56vMpEwfdeO2wr5atWtLiaNaRnp0v6fqk3T255b1Px40qKiqKH3nz qJecynKSQyj3tnn7xoGXtG2/DmDj1g2Da9eoMx+gW4fuG5avXnrsk68/Gta/z/WTkpOS89du WN3weF5uNTeyCJavEbsyOrfrtsVCJkGfaZf23TYtXbU4c+Lkj24deM3gT6Kjo4tXrFl2tj5N 5EYmTvWZ/N0Xd1VLSNwyYti9r42fOG70tz98Peqe4aOfP3EiL8ETFZXfrHGLgwCz5/94cX5B fpnCWFRF+dnlEe7fj05FKqN0xJ3Q8goqbx9imv4M4jniOiSqaD6ilL5F3OyXeJNAIoTORtak HkNGWLZvL+VJzRq1TvTpec1ff14y7/ac3Jx2WTlZl0ZHR2cmVUta36j+WfvLmn+zxi3+m75n x/XFxcUJqdVTfx7Q94YJZS13/8G9FxcVFcVjWp/S6XBhp3cXr1j48KvjX7wmNjbuUHJydcvI rQnxCYWXduj+7OIVC+/fuHXD4Ojo6GPVk1KWGdM0rNcoJMu6hPiEwh5dej31y7KfR700bsyN Hq/3WIsmLd+7rHNPOytQ15zKP1W7bq20ZW7KcpJDKPeWVrveL59M/vA/hUWFNVOSUxYP6HvD pwAej9f3p94Dnvhh3nd3j/v49U8AT2xM7N42rdt+7EYWwfI1YleGlUzsnqnH4/X9odcfn5y9 4Md7xn38+qdollx6Z+pGJnb1mTlneufsnOz2wwYMvxdgYN8b3psw6b2xU374ume/q66dt3Hb hoXvTnzrrdiYmEPVEhJ3xsXGlWnzc1WVX7A8wv370alIC7R0/MpoD6IcKkoxGblIK/taxNPE AkT5LEBCJxQiFn7GzncpEuNnnkPePiB1yvtTik8W+EpYsSkqlpfeHvPhZZ0uf7rjxV22hauM gsICz9j3Xxk38uZRo4zrEOEmXF4jyiPfSMmkMqDk556oKO+6G0b226Udlgg7Ho29257TgVXa 50nEVVF34FLE3LwJYhBhfmvviPjO+wZxdb+1YqqqKC17M/ZULyoqTKmf1jCsbo9iomOKHx75 15HhLKOqoWRSNs5U+XkIDPmg+56zCx8RLOSEPqLQeRWZIjPzlpZuKjJaGu6QbzjZj7g+uh+J NNkU2eibFiR9f8QY4i3EL5+iErJo+YJWEyd/NCGtTr2pygODQlE1iEKUzUIkpHGhdm4Fsl/n CaTTnYN4X9iLhHLogCiORsjU1F7tu420/ECUUa72PbCfputik28kuBfZu2RHEaKkX8Nveaem 6RQKhcIFwabpxuIPH9ERaIZ0tEWIIcCbiCLRwzu0RUJO7CmneuWFKd/SEIVY4VmRh0zxrUVC b8zALzeFQqFQlBKP9tcYwsEYPmKj9nlIO7caf8iJI8AXSEC8shKufEvDXYiRQx4yYhyLrCe1 RdwidUPcFT2BuDEqqyfyCmPMG09PG/PG0zO27thc6aYYX357zITFv/5i6XB3whfj7/hw0ntW ARcVlQC7ZxcKZ+pzVvITPBbnMvCHjzhH+zRH1ktAwk20Q0ZPCfjXk/IRhaVjF/HUykw6WL4V SRwSGt2oeHRXHlVK8VQ1VLgHheLMxkoZ2YWPOA/rkBMgo5srtf8bA/1syj2KKB0du3wrklPI 2pVSPC6pzCEkwsWp/FPeSNdBoTjdsOpI7MJHZALjKRlyAsRR6YdIBNjdSKiJYLyATH+NB/4C rLHJt8qjQkhEJoREqK7tnUIJNEhrOOXQkUNdfb7iuHp16s/KzMk8595b7n9WL+/9z965Owp8 tw8Z+Y65LiqsRElUWInKL79whpXo0fXKocayPFiHfAgWPmIJwUNOLEGm9tojU3rD8FvSgSga 3XruU63cVEQJ2eV72qBCSDhT3iEkQnFt7xRKIPtYdquRN9/3yAN3/vnezu26zj2Wm9Pu4OED iSCjpaNZRy5r07rtbKt7UmElSspEhZWo3PILd1iJSVMn3mws73TzTVepUSEknCnvEBKhuLZ3 DiVw3lQ9oF6zxi2OJlZLXD9/ybzuA68Z/P28hbPbeb3ROZ0u6VpiQ7QKK6HCSlRF+YU7rMSu vTsDXsaUMqpAVAgJZ8o7hEQoru2dQgkYw0wANG7YdFb67h19ge937NrWM6122pxg96TCSgSi wkpUfvmFPayEzxfgvFUpowpEhZCITAgJN5QmlEDPrlcuGvfx6/etWLu8Sc6xnI5XXHr1B1bp VFgJa5mosBKBVDb5VXRYCaWMKiEqhET5hpBwQ2lCCSQnJefXSKnxy0+L5jyakJCwuWXz1r+v c6qwEpEPi6DCSlStsBJKGVVCVAiJ8g0h4YYu7bttKk0ogdYtzp21cPmCq5s0avaq8bwKK1E5 wiKosBJVJ6xERYaQOBNQvunOMLZs31Tn65lfvnvHkJHDateskwcqrIQVZ0pYBCuU/KxxCiGh UChCYMGyn/+UmlJjvq6I4MwNAWCHkknZOBPkp5SRQlEKMrMz48dPfOuTmOiYQ3/o9ccnI10f haKqo6bpyhcfkDp37tzjezYfrRPpyigUCkVlJZXY7H4j++kzChMjWpnTEB/2DmIVCoVCURK1 ZhQGLkKCCioUCoXCHTXVNF35si3SFVAoFIqqyP8DrqC+qm2XwigAAAAASUVORK5CYII= --------------060504090007030105050009--

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 16 Nov '09

16 Nov '09

--vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * hyc(a)symas.com <hyc(a)symas.com> [2009-11-15 17:58:03 +0000]: > alexs(a)ulgsm.ru wrote: > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > >=20 > >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP= =3D"" > >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > >=20 > > Testing database consist of 1000 users accounts with minimum attributes= =2E=20 > >=20 > > On stress test load slapd Segmentation fault in 10-30 sec. >=20 > Looks like you've had a stack overrun.=20 Is it OS issue? >The "be" parameter should be the same in your frame 0 and frame 1. I don't understand. It's need to make them same? Or what i need to do? :) >=20 > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory ad= dress > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=3D0x801a853d0, db=3D0x803519= 800, > > txn=3D0x80352b040, k=3D0x8069005 > > 70, ids=3D0x806a00000, saved_cursor=3D0x0, get_flag=3D0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=3D0x803521000, rtxn= =3D0x80352b040, > > ava=3D0x7ffffda7a4f0, > > ids=3D0x806c00000, tmp=3D0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a550, > > ids=3D0x806c00000, tmp=3D0x806a00000, stack=3D0x806d00000) at filterin= dex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D161, ids=3D0x806b00000, tmp=3D0x806a00000, save=3D0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a530, > > ids=3D0x806b00000, tmp=3D0x806a00000, stack=3D0x806c00000) at filterin= dex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D160, ids=3D0x7ffffdafa760, tmp=3D0x806a00000, save=3D0x806b00000= ) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a570, > > ids=3D0x7ffffdafa760, tmp=3D0x806a00000, stack=3D0x806b00000) at filte= rindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=3D0x803521000, rs=3D0x7= ffffdbfab30, > > e=3D0x7ffffda7a71 tx > > n=3D0x80352b040, ids=3D0x7ffffdafa760, scopes=3D0x7ffffda7a760) at sear= ch.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=3D0x803521000, rs=3D0x7ffffdbf= ab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=3D0x803521000, rs=3D0x7ffffd= bfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=3D0x803521000, rs=3D0x7ffffdbfa= b30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=3D0x7ffffdbfac70, > > arg_v=3D0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=3D0x7ffffdbfac70,= argv=3D0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJLAP/dAAoJELAIdrQw5JcdEXgIAJ4KkW6gYy+Nm6XykkqGAyad HG/vIY1KeG9vJyPLzduonCaqhi32ZIuSl3qkGgywy4q/wJV0kW3rRZ2tzQLzMahr gKlVFJvyqtPhocKARppKWFSIXxJT64lvCqEabrfw2JLDhDNJGtIOcdn51TlKvfIy 4paEDvv5c+A3aDD7BFKK0QePq8E38v5evK1a8UG94rbGiKiCjtgYjJVfm03NUjmR FvyBwMV+CgcXGj4fQ+bnvfTTC8jb00oftw/7NS2orZi6EHcGaxvbeuPmrEVIRtL4 Fi82XlKfcEqFq/znja041mrkF7tnPLfysMzXEjqeOgrsedAIWS52M2LHGUYkY0k= =PI7h -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL--

1 0

ITS#6290 dynamic group documentation
by hyc＠symas.com 16 Nov '09

16 Nov '09

Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice that "member" is not a valid attribute in the groupOfURLs class: it can not be used to store static members, only dynamic references. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 16 Nov '09

16 Nov '09

mike(a)flyn.org wrote: > Followup 4 states that slapd did not initially crash when using "threads > 1" and no indexes. In this case, slapd did eventually crash as before. I have removed the two asserts you previously reported; please try the current code in CVS 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 16 Nov '09

16 Nov '09

Followup 4 states that slapd did not initially crash when using "threads 1" and no indexes. In this case, slapd did eventually crash as before.

1 0

Re: (ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by hyc＠symas.com 15 Nov '09

15 Nov '09

Jan Zelený wrote: > Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): >> jzeleny(a)redhat.com wrote: >>> Full_Name: Jan Zeleny >>> Version: 2.4.18 >>> OS: Fedora 11 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (62.40.79.66) >>> >> I'm unable to reproduce this using slapd on a debian x86-64 system, whether >> on the local LAN or from 13 hops away. I've also used the tcp-buffer >> option to set a minimum sized socket buffer and still could not duplicate >> the problem. You will need to provide more explicit information on how to >> reproduce this issue. Perhaps providing a set of CA/server certs will also >> be necessary. > I'm not sure I have much more explicit information for you. I'm sending > certificate in attachment. It's a self signed testing certificate I generated on > my system. I'm also sending you slapd.conf with relevant information and CA > bundle file. If you need anything else, just let me know. > > Just for complete information: > I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On > each system I used different self signed certificate. In both cases attached > slapd.conf file was used. To reproduce error, I just started the slapd service > (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When > I tried to connect with openssl s_client -connect fedora12-64, I received this > output (and then freeze): > > CONNECTED(00000003) > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify return:1 > > >> Please note that the bug report you reference (509230) gives inconsistent >> information; it says that no hang occurs with -d2, but that hangs occur >> with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: >> does it hang, or not, with -d -1? > > I believe what is stated there is that hangs don't occur with -d2, but they do > with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs > occur, but with -d2 they don't. (or at least I didn't encounter them during my > testing). > > Hopefully I provided some useful information. Thanks, that helped, a fix is now in CVS HEAD. I should point out that the configuration used to reproduce this problem is quite a poor one. As the OpenLDAP Admin Guide clearly states, your server should only be configured with the CA certs for which it will accept client certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are irrelevant; it's when slapd sends the client its list of acceptable CAs that the connection was getting jammed. -- -- 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#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Download testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz >> It's certainly a mystery. The *.flt shows that an entry is missing on the >> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log >> shows that the consumer received the entry and ignored it. (See slapd.4.log >> line 3307-3313. Compare with the previously received entry, lines 3161-3169.) >> >> The most puzzling part is that every code path in the consumer that rejects an >> entry logs an error message, and there is no error message in the log file. >> Without any means to reproduce this there's not much we can do. Setting a >> higher debug level might be useful, but any error messages in this path should >> have shown up regardless. > > The same problem is in your ITS#6126 logs. The entry was received on the > consumer but skipped without any error message. > > I see now, the entry was skipped because its CSN was too old. (And that CSN > too old message is only logged with SYNC debug is enabled.) This should be > fixed by the patch for ITS#6346. > > It was also suggested that we should only reject mods if their CSN is actually > older than the target entry's CSN. That's still a possibility if the current > patch is insufficient. These ITS were filed based on failed test runs on my old Pentium III Mobile 1,8 GHz laptop (now broken). I always suspected that it might be something others won't see because their hardware is faster. Maybe it would be good to run the test suite on really slow systems from time to time. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs