- openldap-bugs - openldap.org

Re: (ITS#5268) dSAOperation attributes should not be replicated
by ghenry＠suretecsystems.com 08 Dec '07

08 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24/RE23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Operational attributes like auditContext and contextCSN that are specific to a > particular DSA should never be replicated. > > It may make sense to add a check in slap_send_search_entry to skip all > dSAOperation attributes at that point. That would catch all instances, but it > would mean they were generated needlessly by whatever code manages the > attribute. > > For now, patching accesslog.c and syncprov.c seems more useful. > Excellent, this solves having to load accesslog on the consumer. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

> Pierangelo Masarati wrote: >> Should be fixed in HEAD. Please test. p. > > Nope. Synced head, make distclean and re-installed. But still it does > not start (see log below). Should be fixed now (no need to distclean; just make sure dds is re-built and re-installed!). Please, re-test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Pierangelo Masarati wrote: > Should be fixed in HEAD. Please test. p. Nope. Synced head, make distclean and re-installed. But still it does not start (see log below). slapd.conf contains: overlay dds dds-state true dds-max-ttl 86400 dds-min-ttl 1 dds-default-ttl 3600 dds-interval 60 dds-tolerance 0 dds-max-dynamicObjects 100 Ciao, Michael. ----------------------------------------------------------------------- backend_startup_one: starting "cn=accesslog,dc=block-floete,dc=de" bdb_db_open: database "cn=accesslog,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/accesslog). backend_startup_one: starting "ou=odd2006,dc=block-floete,dc=de" hdb_db_open: database "ou=odd2006,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/bv). put_filter: "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z))" put_filter: AND put_filter_list "(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z)" put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" put_filter: "(entryExpireTimestamp<=20071208175929Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=20071208175929Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=0 put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS non-expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated ====> bdb_cache_release_all ==> unique_close ====> bdb_cache_release_all slapd-odd2006 destroy: freeing system resources. ==> unique_db_destroy slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: (ITS#5269) few glitches in man pages
by hyc＠symas.com 08 Dec '07

08 Dec '07

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.3.39 > OS: > URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch > Submission from: (NULL) (82.224.237.5) > > > Some options are missing in command synopsys, while documented in available > options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R > authcid for ldappasswd). Submitted patch fix the issue. Thanks for the patch. -P should be invalid for ldapwhoami since it uses an extended operation, and those are not supported in LDAPv2. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5269) few glitches in man pages
by Guillaume.Rousse＠inria.fr 08 Dec '07

08 Dec '07

Full_Name: Guillaume Rousse Version: 2.3.39 OS: URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch Submission from: (NULL) (82.224.237.5) Some options are missing in command synopsys, while documented in available options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R authcid for ldappasswd). Submitted patch fix the issue.

1 0

(ITS#5268) dSAOperation attributes should not be replicated
by hyc＠OpenLDAP.org 08 Dec '07

08 Dec '07

Full_Name: Howard Chu Version: HEAD/RE24/RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Operational attributes like auditContext and contextCSN that are specific to a particular DSA should never be replicated. It may make sense to add a check in slap_send_search_entry to skip all dSAOperation attributes at that point. That would catch all instances, but it would mean they were generated needlessly by whatever code manages the attribute. For now, patching accesslog.c and syncprov.c seems more useful.

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

Should be fixed in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

> bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") > => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") > <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found > (-30989) > send_ldap_result: conn=-1 op=0 p=0 > DDS expired objects lookup failed err=32 Makes sense to skip searching for expired entries in a non existing database... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.18) Situation: 1. slapo-dds is defined for database ou=odd2006,dc=block-floete,dc=de in slapd.conf 2. entry ou=odd2006,dc=block-floete,dc=de does not yet exist => slapd does not start (see log below). For the ease of initial setup I'd prefer that slapd would start. bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 08 Dec '07

08 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... >>> (dbx) print assertDN->bv_val >>> assertDN->bv_val = (nil) >>> >>> don't do that... As I suspected, there's more wrong here than a bad printf argument. The assertDN should never be NULL. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... Yes, understood. That characteristic of Solaris hasn't changed. But test044 in HEAD exercises code that hasn't been included in RE24, and I was focusing on RE24. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5264) invalid printf of NULL
by richton＠nbcs.rutgers.edu 07 Dec '07

07 Dec '07

"./run test044" is sufficient to reproduce 100% of the time. Maybe the behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can remember... On Fri, 7 Dec 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

1 0

Re: (ITS#5109) ldap_int_global_options not initialized
by lighthousej＠gmail.com 07 Dec '07

07 Dec '07

------=_Part_13800_24934559.1197042335995 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries. I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program. The code seems to want to copy an array of strings which contain attributes from the global variable. The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string. The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine. I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. ------=_Part_13800_24934559.1197042335995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries.<br>I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program.<br><br>The code seems to want to copy an array of strings which contain attributes from the global variable.  The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string.  The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. <br><br>I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine.<br>I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. <br> ------=_Part_13800_24934559.1197042335995--

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

hyc(a)symas.com wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? Never mind, I'm testing RE24, not HEAD. This part of dynlist isn't present in RE24. > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5259) SIGSEGV in slap_auxprop_store during SASL/OTP bind
by hyc＠symas.com 07 Dec '07

07 Dec '07

dwhite(a)olp.net wrote: > Full_Name: Dan White > Version: 2.3.39 > OS: Linux > URL: http://support.olp.net/ldap/log.txt > Submission from: (NULL) (65.161.252.42) Nice bit of debugging there. This could be a bit tricky because the slapd auxprop code assumes it's always executing on behalf of an LDAP operation (usually a Bind request). In this case, there is no active request; it's the cleanup action on a closed connection, and most of the state that slapd needed has already been torn down. It may take some restructuring to allow this to work, we never expected sasl_dispose() to be anything other than a pure destructor. > I'm experiencing crashes in slapd when attempting to bind via SASL using the OTP > mech. > > I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). > I'm using the bdb backend. > > I'm also using Debian Etch with the following versions of software: > > Cyrus SASL 2.1.22(.dfsg1-8) > libdb 4.2.52(+dfsg-2) > libc6 2.3.6(.ds1-13etch2) > > I've compiled cyrus sasl to use it's internal implementation of OTP, rather than > OPIE: > > --enable-otp > (--with-opie is not enabled) > > The problem I'm experiencing isn't when I successfully authenticate; that seems > to work fine. It's when I run an ldapsearch, but instead of entering an OTP > password, I press ctrl-c to cancel the search. > >>From the shell, when I perform an LDAP search, all appears normal: > > hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net > SASL/OTP authentication started > Challenge: otp-md5 497 hi3182 ext > Please enter your one-time password:<ctrl-c> > hiro:~# > > However my slapd process dies. > > Here's a gdb backtrace of the server process: > > ... > Core was generated by `/usr/sbin/slapd'. > Program terminated with signal 11, Segmentation fault. > #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, > prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) > at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 > 478 op.o_hdr = > conn->c_sasl_bindop->o_hdr; > (gdb) bt > #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, > prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) > at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 > #1 0xb7eb17d7 in sasl_auxprop_store () from /usr/lib/libsasl2.so.2 > #2 0xb7973c89 in otp_server_plug_init () from /usr/lib/sasl2/libotp.so.2 > #3 0xb7ebde36 in sasl_server_new () from /usr/lib/libsasl2.so.2 > #4 0xb7eb6194 in sasl_dispose () from /usr/lib/libsasl2.so.2 > #5 0x080b2992 in slap_sasl_close (conn=0xb7ec3618) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:1331 > #6 0x0806cf27 in connection_close (c=0xb75b1148) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:715 > #7 0x0806e116 in connection_read (s=12) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:1458 > #8 0x0806a49f in slapd_daemon_task (ptr=0x0) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/daemon.c:2468 > #9 0xb7cd3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #10 0xb7c674ae in clone () from /lib/tls/i686/cmov/libc.so.6 > (gdb) quit > > I've added a debug statement within slap_auxprop_store, so the openldap debug > information below will include some additional information about what's being > modified. > > The output can be obtained from: > > http://support.olp.net/ldap/log.txt > > Notice the two lines: > > Dec 3 13:39:06 hiro slapd[11134]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0499^Ihi5935^I0e81b33e30182715^I00000000001196711046. > Dec 3 13:39:07 hiro slapd[11134]: slap_auxprop_store [conn=-1]: Getting ready > to set cmusaslsecretOTP to > md5^I0499^Ihi5935^I0e81b33e30182715^I00000000000000000000. > > If I enter a good OTP password, I get this in my logs: > > Dec 3 13:43:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0499^Ihi5865^Iec8123986aec6550^I00000000001196711306. > Dec 3 13:44:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. > > If I enter an incorrect password, I get this: > > Dec 3 13:45:21 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000001196711421. > Dec 3 13:45:22 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. > > So in the case where it's crashing, it appears the Cyrus SASL is attempting to > revert the OTP entry back to the previous version to "unlock" it. I assume that > the connection id of '-1' is relevant to the crash. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: HEAD > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.137) In a separate email you mentioned that you ran into this problem in test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly did you get this to occur? > [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = > 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" > > 1660 struct berval base = BER_BVNULL; > 1661 > 1662 sm.dn = assertDN; > 1663 sm.match = 0; > 1664 cb.sc_private = &sm; > 1665 > 1666 Debug( LDAP_DEBUG_TRACE, > 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", > 1668 assertDN->bv_val, rule->bv_val, 0 ); > 1669 > 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ > > (dbx) print assertDN->bv_val > assertDN->bv_val = (nil) > > don't do that... > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 07 Dec '07

07 Dec '07

--=-ENBDdr/KGkLnrgJWYt0i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: > db_stat -CA I've run this on all the databases. It seems clear to me the issue is with the 'user' db. [abartlet@naomi source]$ cd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/user [abartlet@naomi user]$ db_stat -CA Default locking region information: 16 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 7 Number of current locks 11 Maximum number of locks at any one time 17 Number of current lockers 18 Maximum number of lockers at any one time 6 Number of current lock objects 9 Maximum number of lock objects at any one time 73 Total number of locks requested 66 Total number of locks released 0 Total number of locks upgraded 8 Total number of locks downgraded 1 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3005 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/205 0% 360/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D16 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D15 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D14 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D13 locks held 0 write locks 0 pid/thread 347/1090525520 =20 5 dd=3D12 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D11 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D10 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 8 dd=3D 9 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 8 locks held 1 write locks 0 pid/thread 347/1090525520 =20 9 READ 1 HELD 0x59310 len: 9 data: 0x010000000000000000 a dd=3D 7 locks held 0 write locks 0 pid/thread 347/1107310928 =20 b dd=3D 6 locks held 1 write locks 0 pid/thread 347/1090525520 =20 b READ 1 HELD objectClass.bdb handle 0 c dd=3D 5 locks held 0 write locks 0 pid/thread 347/1090525520 =20 d dd=3D 4 locks held 0 write locks 0 pid/thread 347/1090525520 =20 e dd=3D 3 locks held 1 write locks 0 pid/thread 347/1090525520 =20 e READ 1 HELD objectCategory.bdb handle 0 f dd=3D 2 locks held 0 write locks 0 pid/thread 347/1090525520 =20 10 dd=3D 1 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8000000b dd=3D 0 locks held 1 write locks 1 pid/thread 347/1090525520 =20 8000000b WRITE 1 WAIT 0x59310 len: 9 data: 0x010000000000000000 8000000b WRITE 1 HELD id2entry.bdb page 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 8000000b WRITE 1 HELD id2entry.bdb page 1 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 b READ 1 HELD objectClass.bdb handle 0 e READ 1 HELD objectCategory.bdb handle 0 9 READ 1 HELD 0x59310 len: 9 data: 0x010000000000000000 8000000b WRITE 1 WAIT 0x59310 len: 9 data: 0x010000000000000000 [abartlet@naomi schema]$ pwd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/schema [abartlet@naomi schema]$ db_stat -CA Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 2 Number of current locks 4 Maximum number of locks at any one time 9 Number of current lockers 9 Maximum number of lockers at any one time 2 Number of current lock objects 4 Maximum number of lock objects at any one time 31 Total number of locks requested 29 Total number of locks released 0 Total number of locks upgraded 4 Total number of locks downgraded 0 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3016 allocations, 0 failures, 11 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/96 0% 363/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1098918224 =20 5 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1098918224 =20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 [abartlet@naomi config]$ pwd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/config [abartlet@naomi config]$ db_stat -CA Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 2 Number of current locks 4 Maximum number of locks at any one time 9 Number of current lockers 9 Maximum number of lockers at any one time 2 Number of current lock objects 4 Maximum number of lock objects at any one time 31 Total number of locks requested 29 Total number of locks released 0 Total number of locks upgraded 4 Total number of locks downgraded 0 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3016 allocations, 0 failures, 11 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/96 0% 366/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1115703632 =20 5 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1115703632 =20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-ENBDdr/KGkLnrgJWYt0i Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD4DBQBHWLFwz4A8Wyi0NrsRAsZVAJi3+Vq41t9uwEfIKjzPFyzEUIOBAJ9B744l fc4tt0W/CKELwgwaxKzTxw== =5an3 -----END PGP SIGNATURE----- --=-ENBDdr/KGkLnrgJWYt0i--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by quanah＠zimbra.com 07 Dec '07

07 Dec '07

db_stat is a tool that's part of BDB. you need the version compiled with the same version of BDB slapd is linked against. --Quanah --On December 7, 2007 2:24:10 AM +0000 abartlet(a)samba.org wrote: > > --=-/HF725u21l3Qb11U+0ES > Content-Type: multipart/mixed; boundary="=-MG7wif63bfoyDI2pqs1S" > > > --=-MG7wif63bfoyDI2pqs1S > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > > On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: >> Andrew Bartlett wrote: >> > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: >> >> This stack trace looks a little funny, but I think this should be >> >> fixe= > d now in >> >> HEAD. >> > =20 >> > BTW, this is on Fedora 8, x86_64. >> > =20 >> > ldd shows: >> > libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) >> > =20 >> > I see no positive change so far. Current backtrace looks identical to >> > me: >> =20 >> Ok, we'll also need to see the relevant config info then.=20 > > Attached.=20 > >> Also it would be=20 >> interesting to see the output from db_stat -CA. > > Is this a tool I should build in the OpenLDAP tree - I can't otherwise > find it on my system. > > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > slapd_db_stat to match, for 4.4).=20 > > Andrew Bartlett > > --=20 > Andrew Bartlett > http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Red Hat Inc. > > --=-MG7wif63bfoyDI2pqs1S > Content-Disposition: attachment; filename=slapd.conf > Content-Type: text/plain; name=slapd.conf; charset=utf-8 > Content-Transfer-Encoding: base64 > > bG9nbGV2ZWwgMA0KDQppbmNsdWRlIC9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRfM > C9z > b3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2JhY2tlbmQtc2NoZW1hLnNjaGVtYQ0KDQpwaWRma > Wxl > CQkvaG9tZS9kYXRhL3NhbWJhL3NhbWJhNC9TQU1CQV80XzAvc291cmNlL3N0L2RjL3ByaXZhd > GUv > bGRhcC9zbGFwZC5waWQNCmFyZ3NmaWxlCS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBX > zRf > MC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL3NsYXBkLmFyZ3MNCnNhc2wtcmVhbG0gc2FtY > mEu > ZXhhbXBsZS5jb20NCmFjY2VzcyB0byAqIGJ5ICogd3JpdGUNCg0KYWxsb3cgdXBkYXRlX2Fub > 24N > Cg0KYXV0aHotcmVnZXhwDQogICAgICAgICAgdWlkPShbXixdKiksY249c2FtYmEuZXhhbXBsZ > S5j > b20sY249ZGlnZXN0LW1kNSxjbj1hdXRoDQogICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQ > z1l > eGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2NvdW50TmFtZT1cJDEpDQoNCmF1dGh6LXJlZ2V4c > A0K > ICAgICAgICAgIHVpZD0oW14sXSopLGNuPShbXixdKiksY249ZGlnZXN0LW1kNSxjbj1hdXRoD > Qog > ICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY > 2Nv > dW50TmFtZT1cJDEpDQoNCmluY2x1ZGUgL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfN > F8w > L3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvbW9kdWxlcy5jb25mDQoNCmRlZmF1bHRzZWFyY > 2hi > YXNlIERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQoNCmJhY2tlbmQJCWhkYg0KZGF0YWJhc > 2Ug > ICAgICAgIGJkYg0Kc3VmZml4CQlDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iY > SxE > Qz1leGFtcGxlLERDPWNvbQ0KZGlyZWN0b3J5CS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBT > UJB > XzRfMC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2RiL3NjaGVtYQ0KaW5kZXggICAgICAgI > CAg > IG9iamVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZ > GV4 > IG5hbWUgZXENCmluZGV4IG9iamVjdENhdGVnb3J5IGVxDQppbmRleCBsREFQRGlzcGxheU5hb > WUg > ZXENCmluZGV4IHN1YkNsYXNzT2YgZXENCg0KZGF0YWJhc2UgICAgICAgIGhkYg0Kc3VmZml4C > QlD > Tj1Db25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpkaXJlY3RvcnkJL > 2hv > bWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkY > XAv > ZGIvY29uZmlnDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgZXENCmluZGV4ICAgICAgI > CAg > ICBzYW1BY2NvdW50TmFtZSBlcQ0KaW5kZXggbmFtZSBlcQ0KaW5kZXggb2JqZWN0U2lkIGVxD > Qpp > bmRleCBvYmplY3RDYXRlZ29yeSBlcQ0KaW5kZXggbkNOYW1lIGVxDQppbmRleCBzdWJDbGFzc > 09m > IGVxDQppbmRleCBkbnNSb290IGVxDQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQpkYXRhYmFzZ > SAg > ICAgICAgaGRiDQpzdWZmaXgJCURDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpyb290ZG4gI > CAg > ICAgICAgY249TWFuYWdlcixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbQ0Kcm9vdHB3ICAgI > CAg > ICAgIGxvY2FsZGNwYXNzDQpkaXJlY3RvcnkJL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQ > kFf > NF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvZGIvdXNlcg0KaW5kZXggICAgICAgICAgI > G9i > amVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4I > G5h > bWUgZXENCmluZGV4IG9iamVjdFNpZCBlcQ0KaW5kZXggb2JqZWN0Q2F0ZWdvcnkgZXENCmluZ > GV4 > IG1lbWJlciBlcQ0KaW5kZXggdWlkTnVtYmVyIGVxDQppbmRleCBnaWROdW1iZXIgZXENCmluZ > GV4 > IHVuaXhOYW1lIGVxDQppbmRleCBwcml2aWxlZ2UgZXENCmluZGV4IG5DTmFtZSBlcQ0KaW5kZ > Xgg > bERBUERpc3BsYXlOYW1lIGVxDQppbmRleCBzdWJDbGFzc09mIGVxDQppbmRleCBkbnNSb290I > GVx > DQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQojc3luY3Byb3YgaXMgc3RhYmxlIGluIE9wZW5MR > EFQ > IDIuMywgYW5kIGF2YWlsYWJsZSBpbiAyLjIuICANCiNXZSBvbmx5IG5lZWQgdGhpcyBmb3Igd > Ghl > IGNvbnRleHRDU04gYXR0cmlidXRlIGFueXdheS4uLi4NCm92ZXJsYXkgc3luY3Byb3YNCnN5b > mNw cm92LWNoZWNrcG9pbnQgMTAwIDEwDQpzeW5jcHJvdi1zZXNzaW9ubG9nIDEwMA0K > > > --=-MG7wif63bfoyDI2pqs1S > Content-Disposition: attachment; filename=modules.conf > Content-Type: text/plain; name=modules.conf; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > > --=-MG7wif63bfoyDI2pqs1S-- > > --=-/HF725u21l3Qb11U+0ES > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQBHWK7Cz4A8Wyi0NrsRAjkmAJ0bTTeKP2f5Fx9jUUbzRuzSp8VxbACgnwOk > zmJTUTdITBffKjjCbgZwazo= > =yB+p > -----END PGP SIGNATURE----- > > --=-/HF725u21l3Qb11U+0ES-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 07 Dec '07

07 Dec '07

--=-/HF725u21l3Qb11U+0ES Content-Type: multipart/mixed; boundary="=-MG7wif63bfoyDI2pqs1S" --=-MG7wif63bfoyDI2pqs1S Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: > Andrew Bartlett wrote: > > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: > >> This stack trace looks a little funny, but I think this should be fixe= d now in > >> HEAD. > >=20 > > BTW, this is on Fedora 8, x86_64. > >=20 > > ldd shows: > > libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) > >=20 > > I see no positive change so far. Current backtrace looks identical to > > me: >=20 > Ok, we'll also need to see the relevant config info then.=20 Attached.=20 > Also it would be=20 > interesting to see the output from db_stat -CA. Is this a tool I should build in the OpenLDAP tree - I can't otherwise find it on my system. I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a slapd_db_stat to match, for 4.4).=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-MG7wif63bfoyDI2pqs1S Content-Disposition: attachment; filename=slapd.conf Content-Type: text/plain; name=slapd.conf; charset=utf-8 Content-Transfer-Encoding: base64 bG9nbGV2ZWwgMA0KDQppbmNsdWRlIC9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRfMC9z b3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2JhY2tlbmQtc2NoZW1hLnNjaGVtYQ0KDQpwaWRmaWxl CQkvaG9tZS9kYXRhL3NhbWJhL3NhbWJhNC9TQU1CQV80XzAvc291cmNlL3N0L2RjL3ByaXZhdGUv bGRhcC9zbGFwZC5waWQNCmFyZ3NmaWxlCS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRf MC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL3NsYXBkLmFyZ3MNCnNhc2wtcmVhbG0gc2FtYmEu ZXhhbXBsZS5jb20NCmFjY2VzcyB0byAqIGJ5ICogd3JpdGUNCg0KYWxsb3cgdXBkYXRlX2Fub24N Cg0KYXV0aHotcmVnZXhwDQogICAgICAgICAgdWlkPShbXixdKiksY249c2FtYmEuZXhhbXBsZS5j b20sY249ZGlnZXN0LW1kNSxjbj1hdXRoDQogICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1l eGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2NvdW50TmFtZT1cJDEpDQoNCmF1dGh6LXJlZ2V4cA0K ICAgICAgICAgIHVpZD0oW14sXSopLGNuPShbXixdKiksY249ZGlnZXN0LW1kNSxjbj1hdXRoDQog ICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2Nv dW50TmFtZT1cJDEpDQoNCmluY2x1ZGUgL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8w L3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvbW9kdWxlcy5jb25mDQoNCmRlZmF1bHRzZWFyY2hi YXNlIERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQoNCmJhY2tlbmQJCWhkYg0KZGF0YWJhc2Ug ICAgICAgIGJkYg0Kc3VmZml4CQlDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxE Qz1leGFtcGxlLERDPWNvbQ0KZGlyZWN0b3J5CS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJB XzRfMC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2RiL3NjaGVtYQ0KaW5kZXggICAgICAgICAg IG9iamVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4 IG5hbWUgZXENCmluZGV4IG9iamVjdENhdGVnb3J5IGVxDQppbmRleCBsREFQRGlzcGxheU5hbWUg ZXENCmluZGV4IHN1YkNsYXNzT2YgZXENCg0KZGF0YWJhc2UgICAgICAgIGhkYg0Kc3VmZml4CQlD Tj1Db25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpkaXJlY3RvcnkJL2hv bWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAv ZGIvY29uZmlnDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgZXENCmluZGV4ICAgICAgICAg ICBzYW1BY2NvdW50TmFtZSBlcQ0KaW5kZXggbmFtZSBlcQ0KaW5kZXggb2JqZWN0U2lkIGVxDQpp bmRleCBvYmplY3RDYXRlZ29yeSBlcQ0KaW5kZXggbkNOYW1lIGVxDQppbmRleCBzdWJDbGFzc09m IGVxDQppbmRleCBkbnNSb290IGVxDQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQpkYXRhYmFzZSAg ICAgICAgaGRiDQpzdWZmaXgJCURDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpyb290ZG4gICAg ICAgICAgY249TWFuYWdlcixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbQ0Kcm9vdHB3ICAgICAg ICAgIGxvY2FsZGNwYXNzDQpkaXJlY3RvcnkJL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFf NF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvZGIvdXNlcg0KaW5kZXggICAgICAgICAgIG9i amVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4IG5h bWUgZXENCmluZGV4IG9iamVjdFNpZCBlcQ0KaW5kZXggb2JqZWN0Q2F0ZWdvcnkgZXENCmluZGV4 IG1lbWJlciBlcQ0KaW5kZXggdWlkTnVtYmVyIGVxDQppbmRleCBnaWROdW1iZXIgZXENCmluZGV4 IHVuaXhOYW1lIGVxDQppbmRleCBwcml2aWxlZ2UgZXENCmluZGV4IG5DTmFtZSBlcQ0KaW5kZXgg bERBUERpc3BsYXlOYW1lIGVxDQppbmRleCBzdWJDbGFzc09mIGVxDQppbmRleCBkbnNSb290IGVx DQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQojc3luY3Byb3YgaXMgc3RhYmxlIGluIE9wZW5MREFQ IDIuMywgYW5kIGF2YWlsYWJsZSBpbiAyLjIuICANCiNXZSBvbmx5IG5lZWQgdGhpcyBmb3IgdGhl IGNvbnRleHRDU04gYXR0cmlidXRlIGFueXdheS4uLi4NCm92ZXJsYXkgc3luY3Byb3YNCnN5bmNw cm92LWNoZWNrcG9pbnQgMTAwIDEwDQpzeW5jcHJvdi1zZXNzaW9ubG9nIDEwMA0K --=-MG7wif63bfoyDI2pqs1S Content-Disposition: attachment; filename=modules.conf Content-Type: text/plain; name=modules.conf; charset=us-ascii Content-Transfer-Encoding: quoted-printable --=-MG7wif63bfoyDI2pqs1S-- --=-/HF725u21l3Qb11U+0ES Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHWK7Cz4A8Wyi0NrsRAjkmAJ0bTTeKP2f5Fx9jUUbzRuzSp8VxbACgnwOk zmJTUTdITBffKjjCbgZwazo= =yB+p -----END PGP SIGNATURE----- --=-/HF725u21l3Qb11U+0ES--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 07 Dec '07

07 Dec '07

Andrew Bartlett wrote: > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: >> This stack trace looks a little funny, but I think this should be fixed now in >> HEAD. > > BTW, this is on Fedora 8, x86_64. > > ldd shows: > libdb-4.6.so => /lib64/libdb-4.6.so (0x000000353ac00000) > > I see no positive change so far. Current backtrace looks identical to > me: Ok, we'll also need to see the relevant config info then. Also it would be interesting to see the output from db_stat -CA. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 07 Dec '07

07 Dec '07

--=-vArXI+WqUCu1GDzWcahr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: > This stack trace looks a little funny, but I think this should be fixed n= ow in=20 > HEAD. BTW, this is on Fedora 8, x86_64. ldd shows: libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) I see no positive change so far. Current backtrace looks identical to me: (gdb) thread apply all bt Thread 6 (Thread 1082132816 (LWP 30533)): #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042af8a in ?? () #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1090525520 (LWP 30536)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:582 #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1098918224 (LWP 30538)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so #6 0x00000000004c55bf in hdb_cache_entry_db_relock () #7 0x00000000004c5d60 in hdb_cache_modify () #8 0x00000000004a03cd in hdb_modify () #9 0x0000000000500666 in ?? () #10 0x00000000005009b2 in ?? () #11 0x000000000043bd45 in ?? () #12 0x000000000043e55f in ?? () #13 0x000000000043f188 in slap_send_ldap_result () #14 0x00000000004c32ad in hdb_add () #15 0x00000000004888d2 in overlay_op_walk () #16 0x0000000000488dd5 in ?? () #17 0x0000000000434407 in fe_op_add () #18 0x0000000000434c0c in do_add () #19 0x000000000042ddb6 in ?? () #20 0x000000000042e24d in ?? () #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 ---Type <return> to continue, or q <return> to quit--- #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1107310928 (LWP 30539)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so #5 0x00000000004c5424 in ?? () #6 0x00000000004c6c09 in hdb_cache_find_id () #7 0x00000000004ca14b in hdb_dn2entry () #8 0x00000000004a3ce0 in hdb_referrals () #9 0x00000000004888d2 in overlay_op_walk () #10 0x0000000000488dd5 in ?? () #11 0x0000000000438fc0 in backend_check_referrals () #12 0x00000000004342ab in fe_op_add () #13 0x0000000000434c0c in do_add () #14 0x000000000042ddb6 in ?? () #15 0x000000000042e24d in ?? () #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1115703632 (LWP 30540)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so #5 0x00000000004c5424 in ?? () #6 0x00000000004c6c09 in hdb_cache_find_id () #7 0x00000000004ca14b in hdb_dn2entry () #8 0x00000000004a3ce0 in hdb_referrals () #9 0x00000000004888d2 in overlay_op_walk () #10 0x0000000000488dd5 in ?? () ---Type <return> to continue, or q <return> to quit--- #11 0x0000000000438fc0 in backend_check_referrals () #12 0x0000000000443ac6 in fe_op_modify () #13 0x0000000000444476 in do_modify () #14 0x000000000042ddb6 in ?? () #15 0x000000000042e24d in ?? () #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 1 (Thread 46912500832560 (LWP 30530)): #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000428cd2 in slapd_daemon () #2 0x0000000000418549 in main () #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-vArXI+WqUCu1GDzWcahr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHWIVLz4A8Wyi0NrsRAhIaAJ9diePymzMaec/iazOApBBqT5LorwCeMZyO ifzef9jmBkp9/ZDDn9y+VKY= =4wdf -----END PGP SIGNATURE----- --=-vArXI+WqUCu1GDzWcahr--

1 0

Re: (ITS#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Note: This ITS need not hold up 2.4.7; the tests fail in 2.4.6 too. I wrote: > "./run -b ldif test004-modify" gets noSuchObject when it attempts to > delete "cn=James A Jones 2,ou=Information Technology Division, > ou=People,dc=example,dc=com". The same happens in test008-concurrency. The ldapsearch output contains 4 entries that should have been deleted: dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com dn: cn=James A Jones 3,ou=Alumni Association,ou=People,dc=example,dc=com dn: cn=James A Jones 4,ou=People,dc=example,dc=com dn: cn=James A Jones 5,dc=example,dc=com The Delete operations for those got noSuchObject, but further Binds as them succeed. (At least in spot checks of Joneses #3 and #4.) slapd-addel.c contains #if 0'ed out code /* wait a second for the add to really complete */ /* This masks some race conditions though. */ sleep( 1 ); The program's Add and Delete calls are synchronous, so I'm not sure what that is about. In any case, it made no difference to put a random 0-15 second sleep there (so the slapd-addel processes would delete at different times). While I'm checking this - other tests that fail with back-ldif: test027-emptydn [cannot slapadd to a database with suffix ""] Unsupported operations, I guess: test016-subref test017-syncreplication-refresh test025-limits [didn't bump into server-side unchecked limit] test037-manage OK failure - compare fails because of entry order from ldapsearch: test012-glue-populate test026-dn test004, test008 and test017 succeed in 2.3.38. Maybe the fix to ITS#4627 (back-ldif issues) was bad? -- Regards, Hallvard

1 0

Can't compile OpenLDAP with Berkekey DB: File format not recognized
by ben＠fallinganvils.com 06 Dec '07

06 Dec '07

This is my first openldap install. I am installing by compiling from source on a debian box logged in as myself in my home directory. Berkeley DB is not installed systemwide. LDAP libraries are installed systemwide, but I want to install the whole openldap tarball in my home directory and use that/run an ldap server etc. Only libraries are installed systemwide. No ldap server software is installed systemwide. I do have root access, but I don't think I should need it. If I can get it installed under /home/ben, after some experimentation, I'll install it in /home/openldap after creating an openldap user. I don't know what the debian system uses the ldap libraries it came with for, but I should be able to use my own local version without dealing with that I would think. This is what I do : 1) Install Berkeley DB 4.6.21 in /home/ben/opt/bdb $ cd db-4.6.21/build_unix $ ../dist/configure --prefix=/home/ben/opt/bdb $ make && make install $ export LD_RUN_PATH=/home/ben/opt/bdb/lib $ export CPPFLAGS='-I /home/ben/opt/bdb/include' $ export LDFLAGS='-L /home/ben/opt/bdb/lib' $ cd 2) Install OpenLDAP $ cd openldap-2.4.6 $ ./configure --prefix=/home/ben/opt/openldap $ make depend $ make Making all in /home/ben/src/openldap/openldap-2.4.6 Entering subdirectory include make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/include' Entering subdirectory libraries make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries' Making all in /home/ben/src/openldap/openldap-2.4.6/libraries Entering subdirectory liblutil make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' /bin/sh ../..//libtool --mode=link cc -static -g -O2 -L /home/ben/opt/bdb/lib -o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv cc -g -O2 /home/ben/opt/bdb/lib -o dtest dtest.o -L/home/ben/src/openldap/openldap-2.4.6/libraries/liblber ./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv /usr/bin/ld: /home/ben/opt/bdb/lib: No such file: File format not recognized collect2: ld returned 1 exit status make[2]: *** [dtest] Error 1 make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries' make: *** [all-common] Error 1 3) Let's investigate: $ ls /home/ben/opt/bdb bin docs include lib $ ls -l /home/ben/opt/bdb/lib -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb-4.6.a -rw-r--r-- 1 ben ben 813 Nov 28 21:44 libdb-4.6.la -rwxr-xr-x 1 ben ben 1248813 Nov 28 21:44 libdb-4.6.so lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb-4.so -> libdb-4.6.so -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb.a lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb.so -> libdb-4.6.so $ vi libdb-4.6.a The first bit looks like: !<arch> / 1196286289 0 0 0 27970 ` ^@^@^E0^@^@m\xea^@^@m\xea^@^@m\xea^@^@m\xea^@^@u"^@^@ Not sure what that means, but someone might... $ vi libdb-4.so The first bit looks like: ^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^C^@^C^@^A^@^@^@\xf0i^A^@4^@^@^@x\xde^Q^@^@^@^@^@4^ @ ^@^D^@(^@^_^@^\^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@\xe8\x85^Q^@\xe8 Hey! more nonsense, but ELF is familiar and seems like a plausable for a linux library... I also get this error with openldap-2.3.39 and db-4.5.20 I could not use openldap-2.3.39 with db-4.6.21 because I get incompatible version. The configure scripts looks for db versions 4.2 though 4.5 and spits out that error otherwise. Anyway, thanks for any help.

2 1

(ITS#5266) "authorization failure: invalid authcid" during SASL auto_transition
by dwhite＠olp.net 06 Dec '07

06 Dec '07

Full_Name: Dan White Version: 2.3.39 OS: Linux URL: http://support.olp.net/ldap/log2.txt Submission from: (NULL) (65.161.252.42) If I enable SASL auto_transition, I receive the following error during authentication: SASL(-14): authorization failure: invalid authcid I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). I'm using the bdb backend. I'm also using Debian Etch with the following versions of software: Cyrus SASL 2.1.22(.dfsg1-8) libdb 4.2.52(+dfsg-2) libc6 2.3.6(.ds1-13etch2) PAM 0.79(-4) pam_ldap 184(-2) I'm using saslauthd's PAM backend, and in turn using pam_ldap for authentication, although I don't believe the problem is related to the saslauthd/pam configuration. Here's the client side output from the attempted bind: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: ldap_sasl_interactive_bind_s: Insufficient access (50) additional info: SASL(-14): authorization failure: invalid authcid If I turn off auto_transition, it works: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: SASL username: abrown(a)olp.net SASL SSF: 0 hiro:~# My slapd.conf SASL service file looks like: hiro:~# cat /usr/lib/sasl2/slapd.conf keytab: /etc/krb5.keytab-ldap pwcheck_method: saslauthd auxprop_plugin: slapd auto_transition: yes log_level: 7 And the server log (loglevel -1) is located at: http://support.olp.net/ldap/log2.txt The error appears to be occurring while transitioning the password to the auxprop store, in the slap_sasl_authorize function: /* Skip SLAP_SASL_PROP_CONN */ prop_getnames( props, slap_propnames+1, auxvals ); /* Should not happen */ if ( !auxvals[0].values ) { sasl_seterror( sconn, 0, "invalid authcid" ); return SASL_NOAUTHZ; } What I'm expecting to happen during the bind, is to have SASL overwrite my userPassword and cmusaslsecretOTP attributes, via the slapd auxprop plugin. I have a lot of passwords in crypted form (which PAM authenticates), and I'm aiming towards a clear-text password store by using this functionality.

1 0

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

hyc(a)symas.com writes: > As I recall, the only reason we needed the waking counter here was to > make sure we never filled the pipe buffer, which would cause a > single-threaded server to deadlock. We can simply set the pipe to > nonblocking instead, and eliminate the counter. Sounds good... > The other point was that if there was already a pending wake event, > there was no reason to write another one. Aha! Now the code makes more sense to me:-) And if 'waking' is just a boolean flag, we can keep it as long as it is treated that way. #define WAKE_LISTENER(w) do { \ if ((w) && !waking) { \ waking = 1; \ tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \ } \ } while (0) I need to stare at it a bit to look for race conditions with readers. I don't suggest to hold next RE24 for this though. It's hardly urgent, and should be tested a bit --without-threads first. -- Regards, Hallvard

1 0

(ITS#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/test004bug.tbz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test004-modify" gets noSuchObject when it attempts to delete "cn=James A Jones 2,ou=Information Technology Division, ou=People,dc=example,dc=com". The tests do not fully support back-ldif, but I don't see why this one should fail. The entry is present as testrun/db.1.a/dc=example,dc=com/ou=people/ou=information technology division/cn=james a jones 2.ldif. tests$ ./run -b ldif test004-modify Cleaning up test run directory leftover from previous run. Running ./scripts/test004-modify... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd modify operations... Testing modify, add, and delete... ldapmodify failed (32)! tests$ grep '^conn=' testrun/slapd.1.log | tail -n6 conn=1 op=6 do_delete conn=1 op=6 DEL dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" conn=1 op=6 RESULT tag=107 err=32 text= conn=1 op=7 do_unbind conn=1 op=7 UNBIND conn=1 fd=8 closed

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 06 Dec '07

06 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Fixed the easy cases in HEAD. > WAKE_LISTENER under --without-threads remains. > As I recall, the only reason we needed the waking counter here was to make sure we never filled the pipe buffer, which would cause a single-threaded server to deadlock. We can simply set the pipe to nonblocking instead, and eliminate the counter. The other point was that if there was already a pending wake event, there was no reason to write another one. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Fixed the easy cases in HEAD. WAKE_LISTENER under --without-threads remains. -- Hallvard

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 06 Dec '07

06 Dec '07

This stack trace looks a little funny, but I think this should be fixed now in HEAD. Andrew Bartlett wrote: > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) thread apply all bt > > Thread 6 (Thread 1082132816 (LWP 26448)): > #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 > #1 0x000000000042af5a in ?? () > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 5 (Thread 1090525520 (LWP 26453)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1098918224 (LWP 26455)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so > #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so > #6 0x00000000004c545f in hdb_cache_entry_db_relock () > #7 0x00000000004c5c00 in hdb_cache_modify () > #8 0x00000000004a03bd in hdb_modify () > #9 0x0000000000500036 in ?? () > #10 0x0000000000500382 in ?? () > #11 0x000000000043bd15 in ?? () > #12 0x000000000043e52f in ?? () > #13 0x000000000043f158 in slap_send_ldap_result () > #14 0x00000000004c314d in hdb_add () > #15 0x00000000004888d2 in overlay_op_walk () > #16 0x0000000000488dd5 in ?? () > #17 0x00000000004343d7 in fe_op_add () > #18 0x0000000000434bdc in do_add () > #19 0x000000000042dd86 in ?? () > #20 0x000000000042e21d in ?? () > #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > ---Type <return> to continue, or q <return> to quit--- > #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1107310928 (LWP 26456)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1115703632 (LWP 26457)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so > #5 0x00000000004c52c4 in ?? () > #6 0x00000000004c6a89 in hdb_cache_find_id () > #7 0x00000000004c9f99 in hdb_dn2entry () > #8 0x00000000004a3cd0 in hdb_referrals () > #9 0x00000000004888d2 in overlay_op_walk () > #10 0x0000000000488dd5 in ?? () > #11 0x0000000000438f90 in backend_check_referrals () > #12 0x000000000043427b in fe_op_add () > #13 0x0000000000434bdc in do_add () > #14 0x000000000042dd86 in ?? () > #15 0x000000000042e21d in ?? () > #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 46912500832560 (LWP 26443)): > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > #1 0x0000000000428ca2 in slapd_daemon () > #2 0x0000000000418519 in main () > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5258) memberof-Overlay issue when deleting all values of the "memberof-member-ad" attribute
by ando＠sys-net.it 06 Dec '07

06 Dec '07

rhafer(a)suse.de wrote: Found it. A fix will follow, perhaps not too shortly. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5262) test008 failures
by hyc＠symas.com 06 Dec '07

06 Dec '07

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: >> hyc(a)OpenLDAP.org wrote: >>> Full_Name: Howard Chu >>> Version: HEAD/RE24/RE23 >>> OS: Linux > I take this back; it wasn't recompiled yet. The current code in HEAD has > passed over 100 iterations. I'll leave it running overnight. This is now fixed in HEAD/RE24. I suppose it ought to be fixed in RE23 as well if we're going to do another 2.3 release. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org 06 Dec '07

06 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > The comparison fails after the first modify step, an entry that should have been > deleted is still present on the slave. > > The presentlist is still left over from the initial query, and hasn't been > emptied yet. This appears to be a missing step when the initial query > transitions from Refresh to Persist mode. This broke after patching ITS#5210. That means the corresponding fix needs to go into RE23 as well, and any syncrepl.c without this patch will not work with newer syncprov. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5264) invalid printf of NULL
by richton＠nbcs.rutgers.edu 06 Dec '07

06 Dec '07

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.137) [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" 1660 struct berval base = BER_BVNULL; 1661 1662 sm.dn = assertDN; 1663 sm.match = 0; 1664 cb.sc_private = &sm; 1665 1666 Debug( LDAP_DEBUG_TRACE, 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", 1668 assertDN->bv_val, rule->bv_val, 0 ); 1669 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ (dbx) print assertDN->bv_val assertDN->bv_val = (nil) don't do that...

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 05 Dec '07

05 Dec '07

Just to note, Howard tracked this down to the overlay not handling abandonding clients. i.e., I can trigger this behavior repeatably by issuing 3 async deletes to the master and then unbinding without waiting for the results of the deletes. Sync deletes obviously do not trigger this. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5263) ldap_parse_sasl_bind_result() returning wrong error code
by rhafer＠suse.de 05 Dec '07

05 Dec '07

Full_Name: Ralf Haferkamp Version: HEAD, RE23, RE24 OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.205.58) According to the man-pages and the C-API draft the ldap_parse_*_result() functions return LDAP_SUCCESS, when the result was successfully parsed, otherwise != LDAP_SUCCESS. The current implementation of ldap_parse_sasl_bind_result() (not sure about ldap_parse_extended_result()) however will return the LDAP Error Code of the passwd LDAPMessages as the result (e.g. LDAP_SASL_BIND_IN_PROGRESS). If this is the desired behavior we should fix our documentation. But I guess this is a bug in ldap_parse_sasl_bind_result() and probably ldap_parse_extended_result().

1 0

Authentication data not used when chasing referrals (ITS#2106)
by my-tien.sadler＠hp.com 05 Dec '07

05 Dec '07

--_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you know if this is now fixed? Per link http://www.openldap.org/lists/openldap-bugs/200209/msg00088.html Presently, all OpenLDAP clients only support anonymous chasing. The -C option was purposely removed from the usage message of all LDAP commands but mistaken left in some manual pages. These have been corrected in HEAD. If and when non-anonymous chasing is implemented, the usage and manual pages will be updated to reflect this. Implementation of non-anonymous chasing is on the TODO list. Kurt Thanks much for your time, My-Tien Sadler --_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D625072214-05122007>Do you kn= ow if this=20 is now fixed?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D625072214-05122007>Per link = <A=20 href=3D"http://www.openldap.org/lists/openldap-bugs/200209/msg00088.html">h= ttp://www.openldap.org/lists/openldap-bugs/200209/msg00088.html</A></SPAN><= /FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007>Presently, all Ope= nLDAP=20 clients only support anonymous chasing.<BR><BR>The -C option was purposely= =20 removed from the usage message of<BR>all LDAP commands but mistaken left in= some=20 manual pages.<BR>These have been corrected in HEAD.<BR><BR>If and when=20 non-anonymous chasing is implemented, the usage<BR>and manual pages will be= =20 updated to reflect this.<BR><BR>Implementation of non-anonymous chasing is = on=20 the TODO list.<BR><BR>Kurt<BR><BR>Thanks much for your time,</SPAN></FONT><= /DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007>My-Tien=20 Sadler</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007></SPAN></FONT>&nbs= p;</DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007><FONT=20 size=3D2></FONT></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007><FONT=20 size=3D2></FONT> </DIV> <DIV><BR></DIV></SPAN></FONT></BODY></HTML> --_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_--

1 0

Re: (ITS#5262) test008 failures
by hyc＠symas.com 05 Dec '07

05 Dec '07

hyc(a)OpenLDAP.org wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD/RE24/RE23 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc > >> As originally reported by Aaron Richton here >> http://www.openldap.org/lists/openldap-devel/200711/msg00097.html and further >> here >> http://www.openldap.org/lists/openldap-devel/200712/msg00026.html >> >> ITS#5257 is a secondary effect of this bug. > > The patch in HEAD seems to help; my 8-core system has now run test008 with > over 150 successful iterations. Over 200 now. > On my dual core system it still failed after > 27 iterations. Still looking at it. I take this back; it wasn't recompiled yet. The current code in HEAD has passed over 100 iterations. I'll leave it running overnight. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5262) test008 failures
by hyc＠OpenLDAP.org 05 Dec '07

05 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24/RE23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > As originally reported by Aaron Richton here > http://www.openldap.org/lists/openldap-devel/200711/msg00097.html and further > here > http://www.openldap.org/lists/openldap-devel/200712/msg00026.html > > ITS#5257 is a secondary effect of this bug. The patch in HEAD seems to help; my 8-core system has now run test008 with over 150 successful iterations. On my dual core system it still failed after 27 iterations. Still looking at it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5262) test008 failures
by hyc＠OpenLDAP.org 05 Dec '07

05 Dec '07

Full_Name: Howard Chu Version: HEAD/RE24/RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc As originally reported by Aaron Richton here http://www.openldap.org/lists/openldap-devel/200711/msg00097.html and further here http://www.openldap.org/lists/openldap-devel/200712/msg00026.html ITS#5257 is a secondary effect of this bug.

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 05 Dec '07

05 Dec '07

--=-Y3mFtyVHKLn0c8Gx/BD0 Content-Type: multipart/mixed; boundary="=-k5lHyfbmg0BMeRkyykUB" --=-k5lHyfbmg0BMeRkyykUB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-12-05 at 01:56 -0800, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: cvs 2007-12-05 > > OS: Fedora 8 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > >=20 > >=20 > > Using Samba4's 'make test', I can hang OpenLDAP's slapd. Samba4 SVN -r= 26305 > >=20 > > That is, it will not process any further requests, but is waiting in > > pthread_join(), not stuck somewhere else. > >=20 > > OpenLDAP was built with: > > `dirname $0`/configure --enable-overlays=3Dyes --enable-modules --enabl= e-dynamic > > --enable-syncprov=3Dyes > >=20 > > Samba4 was built with: > > CC=3D"ccache gcc" CFLAGS=3D"-O3" ./configure --enable-developer -C > > --prefix=3D/data/samba/samba4/prefix > > --with-winbindd-socket-dir=3D/data/samba/samba4/prefix/wb > >=20 > > Samba4 testsuite command line: > >=20 > > OPENLDAP_PATH=3D/usr/local/libexec:/usr/local/sbin TEST_LDAP=3Dyes make= test > >=20 > > This hangs during the 'provision' processing. > >=20 > > Note that this outputs an ldapi:// URL. Using that URL, this test show= s it's > > not just samba that is stuck: > >=20 > > ldapadd -H ldapi://%2Fhome%2Fdata%2Fsamba%2Fsamba4%2Fclean%2Fsource%2Fs= t%2Fdc%2Fprivate%2Fldap%2Fldapi > > -f st/dc/private/ldap/samba.example.com.ldif -D > > cn=3DManager,dc=3Dsamba,dc=3Dexample,dc=3Dcom -w localdcpass -x >=20 > You should run slapd with -d debugging enabled and (I usually start with = -d7)=20 > send the info for the last few requests prior to the hang. Also, you shou= ld=20 > use gdb to attach to the slapd and get a trace of all the threads to see = where=20 > they've gotten stuck. >=20 > http://www.openldap.org/faq/data/cache/59.html Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 (gdb) thread apply all bt Thread 6 (Thread 1082132816 (LWP 26448)): #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042af5a in ?? () #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1090525520 (LWP 26453)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=3D0x844530) at tpool.c:582 #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1098918224 (LWP 26455)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so #6 0x00000000004c545f in hdb_cache_entry_db_relock () #7 0x00000000004c5c00 in hdb_cache_modify () #8 0x00000000004a03bd in hdb_modify () #9 0x0000000000500036 in ?? () #10 0x0000000000500382 in ?? () #11 0x000000000043bd15 in ?? () #12 0x000000000043e52f in ?? () #13 0x000000000043f158 in slap_send_ldap_result () #14 0x00000000004c314d in hdb_add () #15 0x00000000004888d2 in overlay_op_walk () #16 0x0000000000488dd5 in ?? () #17 0x00000000004343d7 in fe_op_add () #18 0x0000000000434bdc in do_add () #19 0x000000000042dd86 in ?? () #20 0x000000000042e21d in ?? () #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x844530) at tpool.c:625 ---Type <return> to continue, or q <return> to quit--- #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1107310928 (LWP 26456)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=3D0x844530) at tpool.c:582 #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1115703632 (LWP 26457)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so #5 0x00000000004c52c4 in ?? () #6 0x00000000004c6a89 in hdb_cache_find_id () #7 0x00000000004c9f99 in hdb_dn2entry () #8 0x00000000004a3cd0 in hdb_referrals () #9 0x00000000004888d2 in overlay_op_walk () #10 0x0000000000488dd5 in ?? () #11 0x0000000000438f90 in backend_check_referrals () #12 0x000000000043427b in fe_op_add () #13 0x0000000000434bdc in do_add () #14 0x000000000042dd86 in ?? () #15 0x000000000042e21d in ?? () #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x844530) at tpool.c:625 #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 1 (Thread 46912500832560 (LWP 26443)): #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000428ca2 in slapd_daemon () #2 0x0000000000418519 in main () #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 (gdb)=20 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-k5lHyfbmg0BMeRkyykUB Content-Disposition: attachment; filename=logs-its Content-Transfer-Encoding: base64 Content-Type: text/plain; name=logs-its; charset=utf-8 c2VuZF9sZGFwX3Jlc3VsdDogY29ubj01IG9wPTMgcD0zDQpzZW5kX2xkYXBfcmVzdWx0OiBlcnI9 MCBtYXRjaGVkPSIiIHRleHQ9IiINCnNlbmRfbGRhcF9yZXNwb25zZTogbXNnaWQ9NCB0YWc9MTAx IGVycj0wDQpiZXJfZmx1c2gyOiAxNCBieXRlcyB0byBzZCAyMg0KICAwMDAwOiAgMzAgMGMgMDIg MDEgMDQgNjUgMDcgMGEgIDAxIDAwIDA0IDAwIDA0IDAwICAgICAgICAgMC4uLi5lLi4uLi4uLi4g ICAgDQpsZGFwX3dyaXRlOiB3YW50PTE0LCB3cml0dGVuPTE0DQogIDAwMDA6ICAzMCAwYyAwMiAw MSAwNCA2NSAwNyAwYSAgMDEgMDAgMDQgMDAgMDQgMDAgICAgICAgICAwLi4uLmUuLi4uLi4uLiAg ICANCmNvbm5lY3Rpb25fZ2V0KDIzKQ0KY29ubmVjdGlvbl9nZXQoMjMpOiBnb3QgY29ubmlkPTYN CmNvbm5lY3Rpb25fcmVhZCgyMyk6IGNoZWNraW5nIGZvciBpbnB1dCBvbiBpZD02DQpiZXJfZ2V0 X25leHQNCmxkYXBfcmVhZDogd2FudD04LCBnb3Q9OA0KICAwMDAwOiAgMzAgNzAgMDIgMDEgMDIg NjMgNjkgMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHAuLi5jaS4gICAgICAgICAgDQps ZGFwX3JlYWQ6IHdhbnQ9MTA2LCBnb3Q9MTA2DQogIDAwMDA6ICAxYSA0NCA0MyAzZCA3MyA2MSA2 ZCA2MiAgNjEgMmMgNDQgNDMgM2QgNjUgNzggNjEgICAuREM9c2FtYmEsREM9ZXhhICANCiAgMDAx MDogIDZkIDcwIDZjIDY1IDJjIDQ0IDQzIDNkICA2MyA2ZiA2ZCAwYSAwMSAwMCAwYSAwMSAgIG1w bGUsREM9Y29tLi4uLi4gIA0KICAwMDIwOiAgMDAgMDIgMDEgMDAgMDIgMDEgMDAgMDEgIDAxIDAw IGExIDIwIDg3IDBiIDZmIDYyICAgLi4uLi4uLi4uLi4gLi5vYiAgDQogIDAwMzA6ICA2YSA2NSA2 MyA3NCA0MyA2YyA2MSA3MyAgNzMgODcgMTEgNjQgNjkgNzMgNzQgNjkgICBqZWN0Q2xhc3MuLmRp c3RpICANCiAgMDA0MDogIDZlIDY3IDc1IDY5IDczIDY4IDY1IDY0ICA0ZSA2MSA2ZCA2NSAzMCAx YSAwNCAwZCAgIG5ndWlzaGVkTmFtZTAuLi4gIA0KICAwMDUwOiAgNjYgNTMgNGQgNGYgNTIgNmYg NmMgNjUgIDRmIDc3IDZlIDY1IDcyIDA0IDA5IDY5ICAgZlNNT1JvbGVPd25lci4uaSAgDQogIDAw NjA6ICA3MyA0NCA2NSA2YyA2NSA3NCA2NSA2NCAgYTAgMDAgICAgICAgICAgICAgICAgICAgICBz RGVsZXRlZC4uICAgICAgICANCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDExMiBjb250ZW50 czoNCmJlcl9nZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTggZXJyb3I9UmVzb3VyY2UgdGVtcG9y YXJpbHkgdW5hdmFpbGFibGUNCmNvbm49NiBvcD0xIGRvX3NlYXJjaA0KYmVyX3NjYW5mIGZtdCAo e21paWlpYikgYmVyOg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxE Qz1jb20+DQo9PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBs ZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy NzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRh cF9kbjJidigyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0w IA0KPDw8IGRuUHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9 c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+DQpTUkNIICJEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNv bSIgMCAwICAgIDAgMCAwDQpiZXJfc2NhbmYgZm10IChtKSBiZXI6DQpiZXJfc2NhbmYgZm10ICht KSBiZXI6DQogICAgZmlsdGVyOiAofChvYmplY3RDbGFzcz0qKShkaXN0aW5ndWlzaGVkTmFtZT0q KSkNCmJlcl9zY2FuZiBmbXQgKHtNfX0pIGJlcjoNCj0+IGdldF9jdHJscw0KPD0gZ2V0X2N0cmxz OiBuPTAgcmM9MCBlcnI9IiINCiAgICBhdHRyczogZlNNT1JvbGVPd25lciBpc0RlbGV0ZWQNCj0+ IGhkYl9zZWFyY2gNCmJkYl9kbjJlbnRyeSgiZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20iKQ0K c2VuZF9sZGFwX3Jlc3VsdDogY29ubj02IG9wPTEgcD0zDQpzZW5kX2xkYXBfcmVzdWx0OiBlcnI9 MTAgbWF0Y2hlZD0iIiB0ZXh0PSIiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTIgdGFnPTEw MSBlcnI9MzINCmJlcl9mbHVzaDI6IDE0IGJ5dGVzIHRvIHNkIDIzDQogIDAwMDA6ICAzMCAwYyAw MiAwMSAwMiA2NSAwNyAwYSAgMDEgMjAgMDQgMDAgMDQgMDAgICAgICAgICAwLi4uLmUuLi4gLi4u LiAgICANCmxkYXBfd3JpdGU6IHdhbnQ9MTQsIHdyaXR0ZW49MTQNCiAgMDAwMDogIDMwIDBjIDAy IDAxIDAyIDY1IDA3IDBhICAwMSAyMCAwNCAwMCAwNCAwMCAgICAgICAgIDAuLi4uZS4uLiAuLi4u ICAgIA0KY29ubmVjdGlvbl9nZXQoMjMpDQpjb25uZWN0aW9uX2dldCgyMyk6IGdvdCBjb25uaWQ9 Ng0KY29ubmVjdGlvbl9yZWFkKDIzKTogY2hlY2tpbmcgZm9yIGlucHV0IG9uIGlkPTYNCmJlcl9n ZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTgsIGdvdD04DQogIDAwMDA6ICAzMCAzNSAwMiAwMSAw MyA2MyAzMCAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwNS4uLmMwLiAgICAgICAgICAN CmxkYXBfcmVhZDogd2FudD00NywgZ290PTQ3DQogIDAwMDA6ICAwMCAwYSAwMSAwMCAwYSAwMSAw MCAwMiAgMDEgMDAgMDIgMDEgMDAgMDEgMDEgMDAgICAuLi4uLi4uLi4uLi4uLi4uICANCiAgMDAx MDogIDg3IDBiIDZmIDYyIDZhIDY1IDYzIDc0ICA0MyA2YyA2MSA3MyA3MyAzMCAxMCAwNCAgIC4u b2JqZWN0Q2xhc3MwLi4gIA0KICAwMDIwOiAgMGUgNmUgNjEgNmQgNjkgNmUgNjcgNDMgIDZmIDZl IDc0IDY1IDc4IDc0IDczICAgICAgLm5hbWluZ0NvbnRleHRzICAgDQpiZXJfZ2V0X25leHQ6IHRh ZyAweDMwIGxlbiA1MyBjb250ZW50czoNCmJlcl9nZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTgg ZXJyb3I9UmVzb3VyY2UgdGVtcG9yYXJpbHkgdW5hdmFpbGFibGUNCmNvbm49NiBvcD0yIGRvX3Nl YXJjaA0KYmVyX3NjYW5mIGZtdCAoe21paWlpYikgYmVyOg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8 Pg0KPDw8IGRuUHJldHR5Tm9ybWFsOiA8PiwgPD4NClNSQ0ggIiIgMCAwICAgIDAgMCAwDQpiZXJf c2NhbmYgZm10IChtKSBiZXI6DQogICAgZmlsdGVyOiAob2JqZWN0Q2xhc3M9KikNCmJlcl9zY2Fu ZiBmbXQgKHtNfX0pIGJlcjoNCiAgICBhdHRyczogbmFtaW5nQ29udGV4dHMNCj0+IHNlbmRfc2Vh cmNoX2VudHJ5OiBjb25uIDYgZG49IiINCmJlcl9mbHVzaDI6IDE2NCBieXRlcyB0byBzZCAyMw0K ICAwMDAwOiAgMzAgODEgYTEgMDIgMDEgMDMgNjQgODEgIDliIDA0IDAwIDMwIDgxIDk2IDMwIDgx ICAgMC4uLi4uZC4uLi4wLi4wLiAgDQogIDAwMTA6ICA5MyAwNCAwZSA2ZSA2MSA2ZCA2OSA2ZSAg NjcgNDMgNmYgNmUgNzQgNjUgNzggNzQgICAuLi5uYW1pbmdDb250ZXh0ICANCiAgMDAyMDogIDcz IDMxIDgxIDgwIDA0IDM1IDYzIDZlICAzZCA1MyA2MyA2OCA2NSA2ZCA2MSAyYyAgIHMxLi4uNWNu PVNjaGVtYSwgIA0KICAwMDMwOiAgNjMgNmUgM2QgNDMgNmYgNmUgNjYgNjkgIDY3IDc1IDcyIDYx IDc0IDY5IDZmIDZlICAgY249Q29uZmlndXJhdGlvbiAgDQogIDAwNDA6ICAyYyA2NCA2MyAzZCA3 MyA2MSA2ZCA2MiAgNjEgMmMgNjQgNjMgM2QgNjUgNzggNjEgICAsZGM9c2FtYmEsZGM9ZXhhICAN CiAgMDA1MDogIDZkIDcwIDZjIDY1IDJjIDY0IDYzIDNkICA2MyA2ZiA2ZCAwNCAyYiA2MyA2ZSAz ZCAgIG1wbGUsZGM9Y29tLitjbj0gIA0KICAwMDYwOiAgNDMgNmYgNmUgNjYgNjkgNjcgNzUgNzIg IDYxIDc0IDY5IDZmIDZlIDJjIDY0IDYzICAgQ29uZmlndXJhdGlvbixkYyAgDQogIDAwNzA6ICAz ZCA3MyA2MSA2ZCA2MiA2MSAyYyA2NCAgNjMgM2QgNjUgNzggNjEgNmQgNzAgNmMgICA9c2FtYmEs ZGM9ZXhhbXBsICANCiAgMDA4MDogIDY1IDJjIDY0IDYzIDNkIDYzIDZmIDZkICAwNCAxYSA2NCA2 MyAzZCA3MyA2MSA2ZCAgIGUsZGM9Y29tLi5kYz1zYW0gIA0KICAwMDkwOiAgNjIgNjEgMmMgNjQg NjMgM2QgNjUgNzggIDYxIDZkIDcwIDZjIDY1IDJjIDY0IDYzICAgYmEsZGM9ZXhhbXBsZSxkYyAg DQogIDAwYTA6ICAzZCA2MyA2ZiA2ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA9Y29tICAgICAgICAgICAgICANCmxkYXBfd3JpdGU6IHdhbnQ9MTY0LCB3cml0dGVuPTE2 NA0KICAwMDAwOiAgMzAgODEgYTEgMDIgMDEgMDMgNjQgODEgIDliIDA0IDAwIDMwIDgxIDk2IDMw IDgxICAgMC4uLi4uZC4uLi4wLi4wLiAgDQogIDAwMTA6ICA5MyAwNCAwZSA2ZSA2MSA2ZCA2OSA2 ZSAgNjcgNDMgNmYgNmUgNzQgNjUgNzggNzQgICAuLi5uYW1pbmdDb250ZXh0ICANCiAgMDAyMDog IDczIDMxIDgxIDgwIDA0IDM1IDYzIDZlICAzZCA1MyA2MyA2OCA2NSA2ZCA2MSAyYyAgIHMxLi4u NWNuPVNjaGVtYSwgIA0KICAwMDMwOiAgNjMgNmUgM2QgNDMgNmYgNmUgNjYgNjkgIDY3IDc1IDcy IDYxIDc0IDY5IDZmIDZlICAgY249Q29uZmlndXJhdGlvbiAgDQogIDAwNDA6ICAyYyA2NCA2MyAz ZCA3MyA2MSA2ZCA2MiAgNjEgMmMgNjQgNjMgM2QgNjUgNzggNjEgICAsZGM9c2FtYmEsZGM9ZXhh ICANCiAgMDA1MDogIDZkIDcwIDZjIDY1IDJjIDY0IDYzIDNkICA2MyA2ZiA2ZCAwNCAyYiA2MyA2 ZSAzZCAgIG1wbGUsZGM9Y29tLitjbj0gIA0KICAwMDYwOiAgNDMgNmYgNmUgNjYgNjkgNjcgNzUg NzIgIDYxIDc0IDY5IDZmIDZlIDJjIDY0IDYzICAgQ29uZmlndXJhdGlvbixkYyAgDQogIDAwNzA6 ICAzZCA3MyA2MSA2ZCA2MiA2MSAyYyA2NCAgNjMgM2QgNjUgNzggNjEgNmQgNzAgNmMgICA9c2Ft YmEsZGM9ZXhhbXBsICANCiAgMDA4MDogIDY1IDJjIDY0IDYzIDNkIDYzIDZmIDZkICAwNCAxYSA2 NCA2MyAzZCA3MyA2MSA2ZCAgIGUsZGM9Y29tLi5kYz1zYW0gIA0KICAwMDkwOiAgNjIgNjEgMmMg NjQgNjMgM2QgNjUgNzggIDYxIDZkIDcwIDZjIDY1IDJjIDY0IDYzICAgYmEsZGM9ZXhhbXBsZSxk YyAgDQogIDAwYTA6ICAzZCA2MyA2ZiA2ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA9Y29tICAgICAgICAgICAgICANCjw9IHNlbmRfc2VhcmNoX2VudHJ5OiBjb25uIDYg ZXhpdC4NCnNlbmRfbGRhcF9yZXN1bHQ6IGNvbm49NiBvcD0yIHA9Mw0Kc2VuZF9sZGFwX3Jlc3Vs dDogZXJyPTAgbWF0Y2hlZD0iIiB0ZXh0PSIiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTMg dGFnPTEwMSBlcnI9MA0KYmVyX2ZsdXNoMjogMTQgYnl0ZXMgdG8gc2QgMjMNCiAgMDAwMDogIDMw IDBjIDAyIDAxIDAzIDY1IDA3IDBhICAwMSAwMCAwNCAwMCAwNCAwMCAgICAgICAgIDAuLi4uZS4u Li4uLi4uICAgIA0KbGRhcF93cml0ZTogd2FudD0xNCwgd3JpdHRlbj0xNA0KICAwMDAwOiAgMzAg MGMgMDIgMDEgMDMgNjUgMDcgMGEgIDAxIDAwIDA0IDAwIDA0IDAwICAgICAgICAgMC4uLi5lLi4u Li4uLi4gICAgDQpjb25uZWN0aW9uX2dldCgyMykNCmNvbm5lY3Rpb25fZ2V0KDIzKTogZ290IGNv bm5pZD02DQpjb25uZWN0aW9uX3JlYWQoMjMpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9Ng0K YmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMwIDM3IDAy IDAxIDA0IDYzIDMyIDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDA3Li4uYzIuICAgICAg ICAgIA0KbGRhcF9yZWFkOiB3YW50PTQ5LCBnb3Q9NDkNCiAgMDAwMDogIDAwIDBhIDAxIDAwIDBh IDAxIDAwIDAyICAwMSAwMCAwMiAwMSAwMCAwMSAwMSAwMCAgIC4uLi4uLi4uLi4uLi4uLi4gIA0K ICAwMDEwOiAgODcgMGIgNmYgNjIgNmEgNjUgNjMgNzQgIDQzIDZjIDYxIDczIDczIDMwIDEyIDA0 ICAgLi5vYmplY3RDbGFzczAuLiAgDQogIDAwMjA6ICAxMCA3MyA3NSA3MCA3MCA2ZiA3MiA3NCAg NjUgNjQgNDMgNmYgNmUgNzQgNzIgNmYgICAuc3VwcG9ydGVkQ29udHJvICANCiAgMDAzMDogIDZj ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGwgICAgICAg ICAgICAgICAgIA0KYmVyX2dldF9uZXh0OiB0YWcgMHgzMCBsZW4gNTUgY29udGVudHM6DQpiZXJf Z2V0X25leHQNCmxkYXBfcmVhZDogd2FudD04IGVycm9yPVJlc291cmNlIHRlbXBvcmFyaWx5IHVu YXZhaWxhYmxlDQpjb25uPTYgb3A9MyBkb19zZWFyY2gNCmJlcl9zY2FuZiBmbXQgKHttaWlpaWIp IGJlcjoNCj4+PiBkblByZXR0eU5vcm1hbDogPD4NCjw8PCBkblByZXR0eU5vcm1hbDogPD4sIDw+ DQpTUkNIICIiIDAgMCAgICAwIDAgMA0KYmVyX3NjYW5mIGZtdCAobSkgYmVyOg0KICAgIGZpbHRl cjogKG9iamVjdENsYXNzPSopDQpiZXJfc2NhbmYgZm10ICh7TX19KSBiZXI6DQogICAgYXR0cnM6 IHN1cHBvcnRlZENvbnRyb2wNCj0+IHNlbmRfc2VhcmNoX2VudHJ5OiBjb25uIDYgZG49IiINCmJl cl9mbHVzaDI6IDU4NSBieXRlcyB0byBzZCAyMw0KICAwMDAwOiAgMzAgODIgMDIgNDUgMDIgMDEg MDQgNjQgIDgyIDAyIDNlIDA0IDAwIDMwIDgyIDAyICAgMC4uRS4uLmQuLj4uLjAuLiAgDQogIDAw MTA6ICAzOCAzMCA4MiAwMiAzNCAwNCAxMCA3MyAgNzUgNzAgNzAgNmYgNzIgNzQgNjUgNjQgICA4 MC4uNC4uc3VwcG9ydGVkICANCiAgMDAyMDogIDQzIDZmIDZlIDc0IDcyIDZmIDZjIDMxICA4MiAw MiAxZSAwNCAxOSAzMSAyZSAzMyAgIENvbnRyb2wxLi4uLi4xLjMgIA0KICAwMDMwOiAgMmUgMzYg MmUgMzEgMmUgMzQgMmUgMzEgIDJlIDM0IDMyIDMwIDMzIDJlIDM2IDM2ICAgLjYuMS40LjEuNDIw My42NiAgDQogIDAwNDA6ICAzNiAyZSAzNSAyZSAzMSAzNCAwNCAxOCAgMzEgMmUgMzMgMmUgMzYg MmUgMzEgMmUgICA2LjUuMTQuLjEuMy42LjEuICANCiAgMDA1MDogIDM0IDJlIDMxIDJlIDM0IDMy IDMwIDMzICAyZSAzMSAyZSAzOSAyZSAzMSAyZSAzMSAgIDQuMS40MjAzLjEuOS4xLjEgIA0KICAw MDYwOiAgMDQgMWQgMzEgMmUgMzMgMmUgMzYgMmUgIDMxIDJlIDM0IDJlIDMxIDJlIDM0IDMyICAg Li4xLjMuNi4xLjQuMS40MiAgDQogIDAwNzA6ICAzMCAzMyAyZSAzNiAzNiAzNiAyZSAzMSAgMzEg MmUgMzkgMmUgMzUgMmUgMzEgMDQgICAwMy42NjYuMTEuOS41LjEuICANCiAgMDA4MDogIDE5IDMx IDJlIDMzIDJlIDM2IDJlIDMxICAyZSAzNCAyZSAzMSAyZSAzNCAzMiAyZSAgIC4xLjMuNi4xLjQu MS40Mi4gIA0KICAwMDkwOiAgMzIgMmUgMzIgMzcgMmUgMzggMmUgMzUgIDJlIDMxIDA0IDFhIDMx IDJlIDMzIDJlICAgMi4yNy44LjUuMS4uMS4zLiAgDQogIDAwYTA6ICAzNiAyZSAzMSAyZSAzNCAy ZSAzMSAyZSAgMzIgMzEgMzAgMzAgMzggMmUgMzEgMzAgICA2LjEuNC4xLjIxMDA4LjEwICANCiAg MDBiMDogIDM4IDJlIDM2IDMzIDJlIDMxIDA0IDE4ICAzMiAyZSAzMSAzNiAyZSAzOCAzNCAzMCAg IDguNjMuMS4uMi4xNi44NDAgIA0KICAwMGMwOiAgMmUgMzEgMmUgMzEgMzEgMzMgMzcgMzMgIDMw IDJlIDMzIDJlIDM0IDJlIDMxIDM4ICAgLjEuMTEzNzMwLjMuNC4xOCAgDQogIDAwZDA6ICAwNCAx NyAzMiAyZSAzMSAzNiAyZSAzOCAgMzQgMzAgMmUgMzEgMmUgMzEgMzEgMzMgICAuLjIuMTYuODQw LjEuMTEzICANCiAgMDBlMDogIDM3IDMzIDMwIDJlIDMzIDJlIDM0IDJlICAzMiAwNCAxYiAzMSAy ZSAzMyAyZSAzNiAgIDczMC4zLjQuMi4uMS4zLjYgIA0KICAwMGYwOiAgMmUgMzEgMmUgMzQgMmUg MzEgMmUgMzQgIDMyIDMwIDMzIDJlIDM2IDM2IDM2IDJlICAgLjEuNC4xLjQyMDMuNjY2LiAgDQog IDAxMDA6ICAzMSAzMSAyZSAzNyAyZSAzMiAwNCAxOSAgMzEgMmUgMzMgMmUgMzYgMmUgMzEgMmUg ICAxMS43LjIuLjEuMy42LjEuICANCiAgMDExMDogIDM0IDJlIDMxIDJlIDM0IDMyIDMwIDMzICAy ZSAzNiAzNiAzNiAyZSAzNSAyZSAzMSAgIDQuMS40MjAzLjY2Ni41LjEgIA0KICAwMTIwOiAgMzIg MDQgMTggMzEgMmUgMzMgMmUgMzYgIDJlIDMxIDJlIDM0IDJlIDMxIDJlIDM0ICAgMi4uMS4zLjYu MS40LjEuNCAgDQogIDAxMzA6ICAzMiAzMCAzMyAyZSAzNiAzNiAzNiAyZSAgMzUgMmUgMzIgMDQg MTcgMzEgMmUgMzMgICAyMDMuNjY2LjUuMi4uMS4zICANCiAgMDE0MDogIDJlIDM2IDJlIDMxIDJl IDM0IDJlIDMxICAyZSAzNCAzMiAzMCAzMyAyZSAzMSAyZSAgIC42LjEuNC4xLjQyMDMuMS4gIA0K ICAwMTUwOiAgMzEgMzAgMmUgMzEgMDQgMTcgMzEgMmUgIDMyIDJlIDM4IDM0IDMwIDJlIDMxIDMx ICAgMTAuMS4uMS4yLjg0MC4xMSAgDQogIDAxNjA6ICAzMyAzNSAzNSAzNiAyZSAzMSAyZSAzNCAg MmUgMzEgMzMgMzQgMzAgMDQgMTYgMzEgICAzNTU2LjEuNC4xMzQwLi4xICANCiAgMDE3MDogIDJl IDMyIDJlIDM4IDM0IDMwIDJlIDMxICAzMSAzMyAzNSAzNSAzNiAyZSAzMSAyZSAgIC4yLjg0MC4x MTM1NTYuMS4gIA0KICAwMTgwOiAgMzQgMmUgMzggMzAgMzUgMDQgMTcgMzEgIDJlIDMyIDJlIDM4 IDM0IDMwIDJlIDMxICAgNC44MDUuLjEuMi44NDAuMSAgDQogIDAxOTA6ICAzMSAzMyAzNSAzNSAz NiAyZSAzMSAyZSAgMzQgMmUgMzEgMzQgMzEgMzMgMDQgMTkgICAxMzU1Ni4xLjQuMTQxMy4uICAN CiAgMDFhMDogIDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAzNCAyZSAzMSAyZSAzNCAzMiAzMCAz MyAgIDEuMy42LjEuNC4xLjQyMDMgIA0KICAwMWIwOiAgMmUgMzYgMzYgMzYgMmUgMzUgMmUgMzEg IDM1IDA0IDE3IDMxIDJlIDMyIDJlIDM4ICAgLjY2Ni41LjE1Li4xLjIuOCAgDQogIDAxYzA6ICAz NCAzMCAyZSAzMSAzMSAzMyAzNSAzNSAgMzYgMmUgMzEgMmUgMzQgMmUgMzEgMzMgICA0MC4xMTM1 NTYuMS40LjEzICANCiAgMDFkMDogIDMzIDM5IDA0IDE2IDMxIDJlIDMyIDJlICAzOCAzNCAzMCAy ZSAzMSAzMSAzMyAzNSAgIDM5Li4xLjIuODQwLjExMzUgIA0KICAwMWUwOiAgMzUgMzYgMmUgMzEg MmUgMzQgMmUgMzQgIDM3IDMzIDA0IDE2IDMxIDJlIDMyIDJlICAgNTYuMS40LjQ3My4uMS4yLiAg DQogIDAxZjA6ICAzOCAzNCAzMCAyZSAzMSAzMSAzMyAzNSAgMzUgMzYgMmUgMzEgMmUgMzQgMmUg MzMgICA4NDAuMTEzNTU2LjEuNC4zICANCiAgMDIwMDogIDMxIDM5IDA0IDE3IDMxIDJlIDMyIDJl ICAzOCAzMiAzNiAyZSAzMCAyZSAzMSAyZSAgIDE5Li4xLjIuODI2LjAuMS4gIA0KICAwMjEwOiAg MzMgMzMgMzQgMzQgMzggMzEgMzAgMmUgIDMyIDJlIDMzIDA0IDBlIDMxIDJlIDMzICAgMzM0NDgx MC4yLjMuLjEuMyAgDQogIDAyMjA6ICAyZSAzNiAyZSAzMSAyZSAzMSAyZSAzMSAgMzMgMmUgMzIg MDQgMGUgMzEgMmUgMzMgICAuNi4xLjEuMTMuMi4uMS4zICANCiAgMDIzMDogIDJlIDM2IDJlIDMx IDJlIDMxIDJlIDMxICAzMyAyZSAzMSAwNCAwYyAzMSAyZSAzMyAgIC42LjEuMS4xMy4xLi4xLjMg IA0KICAwMjQwOiAgMmUgMzYgMmUgMzEgMmUgMzEgMmUgMzEgIDMyICAgICAgICAgICAgICAgICAg ICAgICAgLjYuMS4xLjEyICAgICAgICAgDQpsZGFwX3dyaXRlOiB3YW50PTU4NSwgd3JpdHRlbj01 ODUNCiAgMDAwMDogIDMwIDgyIDAyIDQ1IDAyIDAxIDA0IDY0ICA4MiAwMiAzZSAwNCAwMCAzMCA4 MiAwMiAgIDAuLkUuLi5kLi4+Li4wLi4gIA0KICAwMDEwOiAgMzggMzAgODIgMDIgMzQgMDQgMTAg NzMgIDc1IDcwIDcwIDZmIDcyIDc0IDY1IDY0ICAgODAuLjQuLnN1cHBvcnRlZCAgDQogIDAwMjA6 ICA0MyA2ZiA2ZSA3NCA3MiA2ZiA2YyAzMSAgODIgMDIgMWUgMDQgMTkgMzEgMmUgMzMgICBDb250 cm9sMS4uLi4uMS4zICANCiAgMDAzMDogIDJlIDM2IDJlIDMxIDJlIDM0IDJlIDMxICAyZSAzNCAz MiAzMCAzMyAyZSAzNiAzNiAgIC42LjEuNC4xLjQyMDMuNjYgIA0KICAwMDQwOiAgMzYgMmUgMzUg MmUgMzEgMzQgMDQgMTggIDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAgNi41LjE0Li4xLjMuNi4x LiAgDQogIDAwNTA6ICAzNCAyZSAzMSAyZSAzNCAzMiAzMCAzMyAgMmUgMzEgMmUgMzkgMmUgMzEg MmUgMzEgICA0LjEuNDIwMy4xLjkuMS4xICANCiAgMDA2MDogIDA0IDFkIDMxIDJlIDMzIDJlIDM2 IDJlICAzMSAyZSAzNCAyZSAzMSAyZSAzNCAzMiAgIC4uMS4zLjYuMS40LjEuNDIgIA0KICAwMDcw OiAgMzAgMzMgMmUgMzYgMzYgMzYgMmUgMzEgIDMxIDJlIDM5IDJlIDM1IDJlIDMxIDA0ICAgMDMu NjY2LjExLjkuNS4xLiAgDQogIDAwODA6ICAxOSAzMSAyZSAzMyAyZSAzNiAyZSAzMSAgMmUgMzQg MmUgMzEgMmUgMzQgMzIgMmUgICAuMS4zLjYuMS40LjEuNDIuICANCiAgMDA5MDogIDMyIDJlIDMy IDM3IDJlIDM4IDJlIDM1ICAyZSAzMSAwNCAxYSAzMSAyZSAzMyAyZSAgIDIuMjcuOC41LjEuLjEu My4gIA0KICAwMGEwOiAgMzYgMmUgMzEgMmUgMzQgMmUgMzEgMmUgIDMyIDMxIDMwIDMwIDM4IDJl IDMxIDMwICAgNi4xLjQuMS4yMTAwOC4xMCAgDQogIDAwYjA6ICAzOCAyZSAzNiAzMyAyZSAzMSAw NCAxOCAgMzIgMmUgMzEgMzYgMmUgMzggMzQgMzAgICA4LjYzLjEuLjIuMTYuODQwICANCiAgMDBj MDogIDJlIDMxIDJlIDMxIDMxIDMzIDM3IDMzICAzMCAyZSAzMyAyZSAzNCAyZSAzMSAzOCAgIC4x LjExMzczMC4zLjQuMTggIA0KICAwMGQwOiAgMDQgMTcgMzIgMmUgMzEgMzYgMmUgMzggIDM0IDMw IDJlIDMxIDJlIDMxIDMxIDMzICAgLi4yLjE2Ljg0MC4xLjExMyAgDQogIDAwZTA6ICAzNyAzMyAz MCAyZSAzMyAyZSAzNCAyZSAgMzIgMDQgMWIgMzEgMmUgMzMgMmUgMzYgICA3MzAuMy40LjIuLjEu My42ICANCiAgMDBmMDogIDJlIDMxIDJlIDM0IDJlIDMxIDJlIDM0ICAzMiAzMCAzMyAyZSAzNiAz NiAzNiAyZSAgIC4xLjQuMS40MjAzLjY2Ni4gIA0KICAwMTAwOiAgMzEgMzEgMmUgMzcgMmUgMzIg MDQgMTkgIDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAgMTEuNy4yLi4xLjMuNi4xLiAgDQogIDAx MTA6ICAzNCAyZSAzMSAyZSAzNCAzMiAzMCAzMyAgMmUgMzYgMzYgMzYgMmUgMzUgMmUgMzEgICA0 LjEuNDIwMy42NjYuNS4xICANCiAgMDEyMDogIDMyIDA0IDE4IDMxIDJlIDMzIDJlIDM2ICAyZSAz MSAyZSAzNCAyZSAzMSAyZSAzNCAgIDIuLjEuMy42LjEuNC4xLjQgIA0KICAwMTMwOiAgMzIgMzAg MzMgMmUgMzYgMzYgMzYgMmUgIDM1IDJlIDMyIDA0IDE3IDMxIDJlIDMzICAgMjAzLjY2Ni41LjIu LjEuMyAgDQogIDAxNDA6ICAyZSAzNiAyZSAzMSAyZSAzNCAyZSAzMSAgMmUgMzQgMzIgMzAgMzMg MmUgMzEgMmUgICAuNi4xLjQuMS40MjAzLjEuICANCiAgMDE1MDogIDMxIDMwIDJlIDMxIDA0IDE3 IDMxIDJlICAzMiAyZSAzOCAzNCAzMCAyZSAzMSAzMSAgIDEwLjEuLjEuMi44NDAuMTEgIA0KICAw MTYwOiAgMzMgMzUgMzUgMzYgMmUgMzEgMmUgMzQgIDJlIDMxIDMzIDM0IDMwIDA0IDE2IDMxICAg MzU1Ni4xLjQuMTM0MC4uMSAgDQogIDAxNzA6ICAyZSAzMiAyZSAzOCAzNCAzMCAyZSAzMSAgMzEg MzMgMzUgMzUgMzYgMmUgMzEgMmUgICAuMi44NDAuMTEzNTU2LjEuICANCiAgMDE4MDogIDM0IDJl IDM4IDMwIDM1IDA0IDE3IDMxICAyZSAzMiAyZSAzOCAzNCAzMCAyZSAzMSAgIDQuODA1Li4xLjIu ODQwLjEgIA0KICAwMTkwOiAgMzEgMzMgMzUgMzUgMzYgMmUgMzEgMmUgIDM0IDJlIDMxIDM0IDMx IDMzIDA0IDE5ICAgMTM1NTYuMS40LjE0MTMuLiAgDQogIDAxYTA6ICAzMSAyZSAzMyAyZSAzNiAy ZSAzMSAyZSAgMzQgMmUgMzEgMmUgMzQgMzIgMzAgMzMgICAxLjMuNi4xLjQuMS40MjAzICANCiAg MDFiMDogIDJlIDM2IDM2IDM2IDJlIDM1IDJlIDMxICAzNSAwNCAxNyAzMSAyZSAzMiAyZSAzOCAg IC42NjYuNS4xNS4uMS4yLjggIA0KICAwMWMwOiAgMzQgMzAgMmUgMzEgMzEgMzMgMzUgMzUgIDM2 IDJlIDMxIDJlIDM0IDJlIDMxIDMzICAgNDAuMTEzNTU2LjEuNC4xMyAgDQogIDAxZDA6ICAzMyAz OSAwNCAxNiAzMSAyZSAzMiAyZSAgMzggMzQgMzAgMmUgMzEgMzEgMzMgMzUgICAzOS4uMS4yLjg0 MC4xMTM1ICANCiAgMDFlMDogIDM1IDM2IDJlIDMxIDJlIDM0IDJlIDM0ICAzNyAzMyAwNCAxNiAz MSAyZSAzMiAyZSAgIDU2LjEuNC40NzMuLjEuMi4gIA0KICAwMWYwOiAgMzggMzQgMzAgMmUgMzEg MzEgMzMgMzUgIDM1IDM2IDJlIDMxIDJlIDM0IDJlIDMzICAgODQwLjExMzU1Ni4xLjQuMyAgDQog IDAyMDA6ICAzMSAzOSAwNCAxNyAzMSAyZSAzMiAyZSAgMzggMzIgMzYgMmUgMzAgMmUgMzEgMmUg ICAxOS4uMS4yLjgyNi4wLjEuICANCiAgMDIxMDogIDMzIDMzIDM0IDM0IDM4IDMxIDMwIDJlICAz MiAyZSAzMyAwNCAwZSAzMSAyZSAzMyAgIDMzNDQ4MTAuMi4zLi4xLjMgIA0KICAwMjIwOiAgMmUg MzYgMmUgMzEgMmUgMzEgMmUgMzEgIDMzIDJlIDMyIDA0IDBlIDMxIDJlIDMzICAgLjYuMS4xLjEz LjIuLjEuMyAgDQogIDAyMzA6ICAyZSAzNiAyZSAzMSAyZSAzMSAyZSAzMSAgMzMgMmUgMzEgMDQg MGMgMzEgMmUgMzMgICAuNi4xLjEuMTMuMS4uMS4zICANCiAgMDI0MDogIDJlIDM2IDJlIDMxIDJl IDMxIDJlIDMxICAzMiAgICAgICAgICAgICAgICAgICAgICAgIC42LjEuMS4xMiAgICAgICAgIA0K PD0gc2VuZF9zZWFyY2hfZW50cnk6IGNvbm4gNiBleGl0Lg0Kc2VuZF9sZGFwX3Jlc3VsdDogY29u bj02IG9wPTMgcD0zDQpzZW5kX2xkYXBfcmVzdWx0OiBlcnI9MCBtYXRjaGVkPSIiIHRleHQ9IiIN CnNlbmRfbGRhcF9yZXNwb25zZTogbXNnaWQ9NCB0YWc9MTAxIGVycj0wDQpiZXJfZmx1c2gyOiAx NCBieXRlcyB0byBzZCAyMw0KICAwMDAwOiAgMzAgMGMgMDIgMDEgMDQgNjUgMDcgMGEgIDAxIDAw IDA0IDAwIDA0IDAwICAgICAgICAgMC4uLi5lLi4uLi4uLi4gICAgDQpsZGFwX3dyaXRlOiB3YW50 PTE0LCB3cml0dGVuPTE0DQogIDAwMDA6ICAzMCAwYyAwMiAwMSAwNCA2NSAwNyAwYSAgMDEgMDAg MDQgMDAgMDQgMDAgICAgICAgICAwLi4uLmUuLi4uLi4uLiAgICANCmNvbm5lY3Rpb25fZ2V0KDIw KTogZ290IGNvbm5pZD0xDQpjb25uZWN0aW9uX3JlYWQoMjApOiBjaGVja2luZyBmb3IgaW5wdXQg b24gaWQ9MQ0KYmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTANCg0KYmVyX2dl dF9uZXh0IG9uIGZkIDIwIGZhaWxlZCBlcnJubz0wIChTdWNjZXNzKQ0KY29ubmVjdGlvbl9jbG9z aW5nOiByZWFkeWluZyBjb25uPTEgc2Q9MjAgZm9yIGNsb3NlDQpjb25uZWN0aW9uX2Nsb3NlOiBj b25uPTEgc2Q9MjANCmNvbm5lY3Rpb25fZ2V0KDIzKQ0KY29ubmVjdGlvbl9nZXQoMjMpOiBnb3Qg Y29ubmlkPTYNCmNvbm5lY3Rpb25fcmVhZCgyMyk6IGNoZWNraW5nIGZvciBpbnB1dCBvbiBpZD02 DQpiZXJfZ2V0X25leHQNCmxkYXBfcmVhZDogd2FudD04LCBnb3Q9OA0KICAwMDAwOiAgMzAgODIg MDggZWEgMDIgMDEgMDUgNjggICAgICAgICAgICAgICAgICAgICAgICAgICAgMC4uLi4uLmggICAg ICAgICAgDQpsZGFwX3JlYWQ6IHdhbnQ9MjI3OCwgZ290PTIyNzgNCiAgMDAwMDogIDgyIDA4IGUz IDA0IDFhIDQ0IDQzIDNkICA3MyA2MSA2ZCA2MiA2MSAyYyA0NCA0MyAgIC4uLi4uREM9c2FtYmEs REMgIA0KICAwMDEwOiAgM2QgNjUgNzggNjEgNmQgNzAgNmMgNjUgIDJjIDQ0IDQzIDNkIDYzIDZm IDZkIDMwICAgPWV4YW1wbGUsREM9Y29tMCAgDQogIDAwMjA6ICA4MiAwOCBjMyAzMCAwZCAwNCAw MiA2NCAgNjMgMzEgMDcgMDQgMDUgNzMgNjEgNmQgICAuLi4wLi4uZGMxLi4uc2FtICANCiAgMDAz MDogIDYyIDYxIDMwIDE0IDA0IDA5IDczIDYxICA2ZCA2MiA2MSAzNCA1MiA0NCA0ZSAzMSAgIGJh MC4uLnNhbWJhNFJETjEgIA0KICAwMDQwOiAgMDcgMDQgMDUgNzMgNjEgNmQgNjIgNjEgIDMwIDM5 IDA0IDBiIDZmIDYyIDZhIDY1ICAgLi4uc2FtYmEwOS4ub2JqZSAgDQogIDAwNTA6ICA2MyA3NCA0 MyA2YyA2MSA3MyA3MyAzMSAgMmEgMDQgMDMgNzQgNmYgNzAgMDQgMDYgICBjdENsYXNzMSouLnRv cC4uICANCiAgMDA2MDogIDY0IDZmIDZkIDYxIDY5IDZlIDA0IDA5ICA2NCA2ZiA2ZCA2MSA2OSA2 ZSA0NCA0ZSAgIGRvbWFpbi4uZG9tYWluRE4gIA0KICAwMDcwOiAgNTMgMDQgMTAgNjUgNzggNzQg NjUgNmUgIDczIDY5IDYyIDZjIDY1IDRmIDYyIDZhICAgUy4uZXh0ZW5zaWJsZU9iaiAgDQogIDAw ODA6ICA2NSA2MyA3NCAzMCA1NyAwNCAwZSA2ZiAgNjIgNmEgNjUgNjMgNzQgNDMgNjEgNzQgICBl Y3QwVy4ub2JqZWN0Q2F0ICANCiAgMDA5MDogIDY1IDY3IDZmIDcyIDc5IDMxIDQ1IDA0ICA0MyA0 MyA0ZSAzZCA0NCA0ZiA0ZCA0MSAgIGVnb3J5MUUuQ0NOPURPTUEgIA0KICAwMGEwOiAgNDkgNGUg MmQgNDQgNGUgNTMgMmMgNDMgIDRlIDNkIDUzIDQzIDQ4IDQ1IDRkIDQxICAgSU4tRE5TLENOPVND SEVNQSAgDQogIDAwYjA6ICAyYyA0MyA0ZSAzZCA0MyA0ZiA0ZSA0NiAgNDkgNDcgNTUgNTIgNDEg NTQgNDkgNGYgICAsQ049Q09ORklHVVJBVElPICANCiAgMDBjMDogIDRlIDJjIDQ0IDQzIDNkIDUz IDQxIDRkICA0MiA0MSAyYyA0NCA0MyAzZCA0NSA1OCAgIE4sREM9U0FNQkEsREM9RVggIA0KICAw MGQwOiAgNDEgNGQgNTAgNGMgNDUgMmMgNDQgNDMgIDNkIDQzIDRmIDRkIDMwIDgyIDA4IDA2ICAg QU1QTEUsREM9Q09NMC4uLiAgDQogIDAwZTA6ICAwNCAxNCA2ZSA1NCA1MyA2NSA2MyA3NSAgNzIg NjkgNzQgNzkgNDQgNjUgNzMgNjMgICAuLm5UU2VjdXJpdHlEZXNjICANCiAgMDBmMDogIDcyIDY5 IDcwIDc0IDZmIDcyIDMxIDgyICAwNyBlYyAwNCA4MiAwNyBlOCAwMSAwMCAgIHJpcHRvcjEuLi4u Li4uLi4gIA0KICAwMTAwOiAgMTQgODAgMTQgMDAgMDAgMDAgMjAgMDAgIDAwIDAwIDMwIDAwIDAw IDAwIGY4IDAwICAgLi4uLi4uIC4uLjAuLi4uLiAgDQogIDAxMTA6ICAwMCAwMCAwMSAwMSAwMCAw MCAwMCAwMCAgMDAgMDUgMTIgMDAgMDAgMDAgMDEgMDIgICAuLi4uLi4uLi4uLi4uLi4uICANCiAg MDEyMDogIDAwIDAwIDAwIDAwIDAwIDA1IDIwIDAwICAwMCAwMCAyMCAwMiAwMCAwMCAwNCAwMCAg IC4uLi4uLiAuLi4gLi4uLi4gIA0KICAwMTMwOiAgYzggMDAgMDUgMDAgMDAgMDAgMDIgNDAgIDE0 IDAwIDIwIDAwIDBjIDAwIDAxIDAxICAgLi4uLi4uLkAuLiAuLi4uLiAgDQogIDAxNDA6ICAwMCAw MCAwMCAwMCAwMCAwMSAwMCAwMCAgMDAgMDAgMDIgNDAgMTggMDAgMDAgMDEgICAuLi4uLi4uLi4u LkAuLi4uICANCiAgMDE1MDogIDAwIDAwIDAxIDAyIDAwIDAwIDAwIDAwICAwMCAwNSAyMCAwMCAw MCAwMCAyMCAwMiAgIC4uLi4uLi4uLi4gLi4uIC4gIA0KICAwMTYwOiAgMDAgMDAgMDIgNDAgMjQg MDAgMDAgMDEgIDAwIDAwIDAxIDA1IDAwIDAwIDAwIDAwICAgLi4uQCQuLi4uLi4uLi4uLiAgDQog IDAxNzA6ICAwMCAwNSAxNSAwMCAwMCAwMCAyZiBmMiAgNWMgZGQgOTkgZDcgNzUgZjQgYWQgYjkg ICAuLi4uLi4vLlwuLi51Li4uICANCiAgMDE4MDogIDgwIDVkIDAxIDAyIDAwIDAwIDA3IDQyICAz OCAwMCAyMCAwMCAwMCAwMCAwMyAwMCAgIC5dLi4uLi5COC4gLi4uLi4gIA0KICAwMTkwOiAgMDAg MDAgYmUgM2IgMGUgZjMgZjAgOWYgIGQxIDExIGI2IDAzIDAwIDAwIGY4IDAzICAgLi4uOy4uLi4u Li4uLi4uLiAgDQogIDAxYTA6ICA2NyBjMSBhNSA3YSA5NiBiZiBlNiAwZCAgZDAgMTEgYTIgODUg MDAgYWEgMDAgMzAgICBnLi56Li4uLi4uLi4uLi4wICANCiAgMDFiMDogIDQ5IGUyIDAxIDAxIDAw IDAwIDAwIDAwICAwMCAwMSAwMCAwMCAwMCAwMCAwNyA0MiAgIEkuLi4uLi4uLi4uLi4uLkIgIA0K ICAwMWMwOiAgMzggMDAgMjAgMDAgMDAgMDAgMDMgMDAgIDAwIDAwIGJmIDNiIDBlIGYzIGYwIDlm ICAgOC4gLi4uLi4uLi47Li4uLiAgDQogIDAxZDA6ICBkMSAxMSBiNiAwMyAwMCAwMCBmOCAwMyAg NjcgYzEgYTUgN2EgOTYgYmYgZTYgMGQgICAuLi4uLi4uLmcuLnouLi4uICANCiAgMDFlMDogIGQw IDExIGEyIDg1IDAwIGFhIDAwIDMwICA0OSBlMiAwMSAwMSAwMCAwMCAwMCAwMCAgIC4uLi4uLi4w SS4uLi4uLi4gIA0KICAwMWYwOiAgMDAgMDEgMDAgMDAgMDAgMDAgMDQgMDAgIGYwIDA2IDI4IDAw IDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLiguLi4uLiAgDQogIDAyMDA6ICAxNCAwMCAxMCAwMCAw MCAwMCAwMSAwMSAgMDAgMDAgMDAgMDAgMDAgMDEgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uICAN CiAgMDIxMDogIDAwIDAwIDA1IDAwIDI4IDAwIDAwIDAxICAwMCAwMCAwMSAwMCAwMCAwMCBhYSBm NiAgIC4uLi4oLi4uLi4uLi4uLi4gIA0KICAwMjIwOiAgMzEgMTEgMDcgOWMgZDEgMTEgZjcgOWYg IDAwIGMwIDRmIGMyIGRjIGQyIDAxIDAxICAgMS4uLi4uLi4uLk8uLi4uLiAgDQogIDAyMzA6ICAw MCAwMCAwMCAwMCAwMCAwNSAwOSAwMCAgMDAgMDAgMDUgMDAgMjggMDAgMDAgMDEgICAuLi4uLi4u Li4uLi4oLi4uICANCiAgMDI0MDogIDAwIDAwIDAxIDAwIDAwIDAwIGFiIGY2ICAzMSAxMSAwNyA5 YyBkMSAxMSBmNyA5ZiAgIC4uLi4uLi4uMS4uLi4uLi4gIA0KICAwMjUwOiAgMDAgYzAgNGYgYzIg ZGMgZDIgMDEgMDEgIDAwIDAwIDAwIDAwIDAwIDA1IDA5IDAwICAgLi5PLi4uLi4uLi4uLi4uLiAg DQogIDAyNjA6ICAwMCAwMCAwNSAwMCAyOCAwMCAwMCAwMSAgMDAgMDAgMDEgMDAgMDAgMDAgYWMg ZjYgICAuLi4uKC4uLi4uLi4uLi4uICANCiAgMDI3MDogIDMxIDExIDA3IDljIGQxIDExIGY3IDlm ICAwMCBjMCA0ZiBjMiBkYyBkMiAwMSAwMSAgIDEuLi4uLi4uLi5PLi4uLi4gIA0KICAwMjgwOiAg MDAgMDAgMDAgMDAgMDAgMDUgMDkgMDAgIDAwIDAwIDA1IDAwIDJjIDAwIDAwIDAxICAgLi4uLi4u Li4uLi4uLC4uLiAgDQogIDAyOTA6ICAwMCAwMCAwMSAwMCAwMCAwMCBhYSBmNiAgMzEgMTEgMDcg OWMgZDEgMTEgZjcgOWYgICAuLi4uLi4uLjEuLi4uLi4uICANCiAgMDJhMDogIDAwIGMwIDRmIGMy IGRjIGQyIDAxIDAyICAwMCAwMCAwMCAwMCAwMCAwNSAyMCAwMCAgIC4uTy4uLi4uLi4uLi4uIC4g IA0KICAwMmIwOiAgMDAgMDAgMjAgMDIgMDAgMDAgMDUgMDAgIDJjIDAwIDAwIDAxIDAwIDAwIDAx IDAwICAgLi4gLi4uLi4sLi4uLi4uLiAgDQogIDAyYzA6ICAwMCAwMCBhYiBmNiAzMSAxMSAwNyA5 YyAgZDEgMTEgZjcgOWYgMDAgYzAgNGYgYzIgICAuLi4uMS4uLi4uLi4uLk8uICANCiAgMDJkMDog IGRjIGQyIDAxIDAyIDAwIDAwIDAwIDAwICAwMCAwNSAyMCAwMCAwMCAwMCAyMCAwMiAgIC4uLi4u Li4uLi4gLi4uIC4gIA0KICAwMmUwOiAgMDAgMDAgMDUgMDAgMmMgMDAgMDAgMDEgIDAwIDAwIDAx IDAwIDAwIDAwIGFjIGY2ICAgLi4uLiwuLi4uLi4uLi4uLiAgDQogIDAyZjA6ICAzMSAxMSAwNyA5 YyBkMSAxMSBmNyA5ZiAgMDAgYzAgNGYgYzIgZGMgZDIgMDEgMDIgICAxLi4uLi4uLi4uTy4uLi4u ICANCiAgMDMwMDogIDAwIDAwIDAwIDAwIDAwIDA1IDIwIDAwICAwMCAwMCAyMCAwMiAwMCAwMCAw MCAwMCAgIC4uLi4uLiAuLi4gLi4uLi4gIA0KICAwMzEwOiAgMTQgMDAgOTQgMDAgMDIgMDAgMDEg MDEgIDAwIDAwIDAwIDAwIDAwIDA1IDBiIDAwICAgLi4uLi4uLi4uLi4uLi4uLiAgDQogIDAzMjA6 ICAwMCAwMCAwMCAwMCAyNCAwMCBiZCAwMSAgMGUgMDAgMDEgMDUgMDAgMDAgMDAgMDAgICAuLi4u JC4uLi4uLi4uLi4uICANCiAgMDMzMDogIDAwIDA1IDE1IDAwIDAwIDAwIDJmIGYyICA1YyBkZCA5 OSBkNyA3NSBmNCBhZCBiOSAgIC4uLi4uLi8uXC4uLnUuLi4gIA0KICAwMzQwOiAgODAgNWQgMDAg MDIgMDAgMDAgMDAgMDIgIDE4IDAwIGJkIDAxIDBmIDAwIDAxIDAyICAgLl0uLi4uLi4uLi4uLi4u LiAgDQogIDAzNTA6ICAwMCAwMCAwMCAwMCAwMCAwNSAyMCAwMCAgMDAgMDAgMjAgMDIgMDAgMDAg MDAgMDAgICAuLi4uLi4gLi4uIC4uLi4uICANCiAgMDM2MDogIDE0IDAwIGZmIDAxIDBmIDAwIDAx IDAxICAwMCAwMCAwMCAwMCAwMCAwNSAxMiAwMCAgIC4uLi4uLi4uLi4uLi4uLi4gIA0KICAwMzcw OiAgMDAgMDAgMDAgMDIgMjQgMDAgZmYgMDEgIDBmIDAwIDAxIDA1IDAwIDAwIDAwIDAwICAgLi4u LiQuLi4uLi4uLi4uLiAgDQogIDAzODA6ICAwMCAwNSAxNSAwMCAwMCAwMCAyZiBmMiAgNWMgZGQg OTkgZDcgNzUgZjQgYWQgYjkgICAuLi4uLi4vLlwuLi51Li4uICANCiAgMDM5MDogIDgwIDVkIDA3 IDAyIDAwIDAwIDAwIDAyICAxOCAwMCAwNCAwMCAwMCAwMCAwMSAwMiAgIC5dLi4uLi4uLi4uLi4u Li4gIA0KICAwM2EwOiAgMDAgMDAgMDAgMDAgMDAgMDUgMjAgMDAgIDAwIDAwIDJhIDAyIDAwIDAw IDA1IDBhICAgLi4uLi4uIC4uLiouLi4uLiAgDQogIDAzYjA6ICAzYyAwMCAxMCAwMCAwMCAwMCAw MyAwMCAgMDAgMDAgZjggODggNzAgMDMgZTEgMGEgICA8Li4uLi4uLi4uLi5wLi4uICANCiAgMDNj MDogIGQyIDExIGI0IDIyIDAwIGEwIGM5IDY4ICBmOSAzOSBiYSA3YSA5NiBiZiBlNiAwZCAgIC4u LiIuLi5oLjkuei4uLi4gIA0KICAwM2QwOiAgZDAgMTEgYTIgODUgMDAgYWEgMDAgMzAgIDQ5IGUy IDAxIDAyIDAwIDAwIDAwIDAwICAgLi4uLi4uLjBJLi4uLi4uLiAgDQogIDAzZTA6ICAwMCAwNSAy MCAwMCAwMCAwMCAyYSAwMiAgMDAgMDAgMDUgMGEgM2MgMDAgMTAgMDAgICAuLiAuLi4qLi4uLi48 Li4uICANCiAgMDNmMDogIDAwIDAwIDAzIDAwIDAwIDAwIDQyIDJmICBiYSA1OSBhMiA3OSBkMCAx MSA5MCAyMCAgIC4uLi4uLkIvLlkueS4uLiAgIA0KICAwNDAwOiAgMDAgYzAgNGYgYzIgZDMgY2Yg YmEgN2EgIDk2IGJmIGU2IDBkIGQwIDExIGEyIDg1ICAgLi5PLi4uLnouLi4uLi4uLiAgDQogIDA0 MTA6ICAwMCBhYSAwMCAzMCA0OSBlMiAwMSAwMiAgMDAgMDAgMDAgMDAgMDAgMDUgMjAgMDAgICAu Li4wSS4uLi4uLi4uLiAuICANCiAgMDQyMDogIDAwIDAwIDJhIDAyIDAwIDAwIDA1IDBhICAzYyAw MCAxMCAwMCAwMCAwMCAwMyAwMCAgIC4uKi4uLi4uPC4uLi4uLi4gIA0KICAwNDMwOiAgMDAgMDAg NDAgYzIgMGEgYmMgYTkgNzkgIGQwIDExIDkwIDIwIDAwIGMwIDRmIGMyICAgLi5ALi4uLnkuLi4g Li5PLiAgDQogIDA0NDA6ICBkNCBjZiBiYSA3YSA5NiBiZiBlNiAwZCAgZDAgMTEgYTIgODUgMDAg YWEgMDAgMzAgICAuLi56Li4uLi4uLi4uLi4wICANCiAgMDQ1MDogIDQ5IGUyIDAxIDAyIDAwIDAw IDAwIDAwICAwMCAwNSAyMCAwMCAwMCAwMCAyYSAwMiAgIEkuLi4uLi4uLi4gLi4uKi4gIA0KICAw NDYwOiAgMDAgMDAgMDUgMGEgM2MgMDAgMTAgMDAgIDAwIDAwIDAzIDAwIDAwIDAwIDAwIDQyICAg Li4uLjwuLi4uLi4uLi4uQiAgDQogIDA0NzA6ICAxNiA0YyBjMCAyMCBkMCAxMSBhNyA2OCAgMDAg YWEgMDAgNmUgMDUgMjkgYmEgN2EgICAuTC4gLi4uaC4uLm4uKS56ICANCiAgMDQ4MDogIDk2IGJm IGU2IDBkIGQwIDExIGEyIDg1ICAwMCBhYSAwMCAzMCA0OSBlMiAwMSAwMiAgIC4uLi4uLi4uLi4u MEkuLi4gIA0KICAwNDkwOiAgMDAgMDAgMDAgMDAgMDAgMDUgMjAgMDAgIDAwIDAwIDJhIDAyIDAw IDAwIDA1IDBhICAgLi4uLi4uIC4uLiouLi4uLiAgDQogIDA0YTA6ICAzYyAwMCAxMCAwMCAwMCAw MCAwMyAwMCAgMDAgMDAgMTAgMjAgMjAgNWYgYTUgNzkgICA8Li4uLi4uLi4uLiAgXy55ICANCiAg MDRiMDogIGQwIDExIDkwIDIwIDAwIGMwIDRmIGMyICBkNCBjZiBiYSA3YSA5NiBiZiBlNiAwZCAg IC4uLiAuLk8uLi4uei4uLi4gIA0KICAwNGMwOiAgZDAgMTEgYTIgODUgMDAgYWEgMDAgMzAgIDQ5 IGUyIDAxIDAyIDAwIDAwIDAwIDAwICAgLi4uLi4uLjBJLi4uLi4uLiAgDQogIDA0ZDA6ICAwMCAw NSAyMCAwMCAwMCAwMCAyYSAwMiAgMDAgMDAgMDUgMDAgMmMgMDAgMTAgMDAgICAuLiAuLi4qLi4u Li4sLi4uICANCiAgMDRlMDogIDAwIDAwIDAxIDAwIDAwIDAwIDYwIDczICA0MCBjNyBiZiAyMCBk MCAxMSBhNyA2OCAgIC4uLi4uLmBzQC4uIC4uLmggIA0KICAwNGYwOiAgMDAgYWEgMDAgNmUgMDUg MjkgMDEgMDIgIDAwIDAwIDAwIDAwIDAwIDA1IDIwIDAwICAgLi4ubi4pLi4uLi4uLi4gLiAgDQog IDA1MDA6ICAwMCAwMCAyYSAwMiAwMCAwMCAwNSAwYSAgMmMgMDAgOTQgMDAgMDIgMDAgMDIgMDAg ICAuLiouLi4uLiwuLi4uLi4uICANCiAgMDUxMDogIDAwIDAwIDljIDdhIDk2IGJmIGU2IDBkICBk MCAxMSBhMiA4NSAwMCBhYSAwMCAzMCAgIC4uLnouLi4uLi4uLi4uLjAgIA0KICAwNTIwOiAgNDkg ZTIgMDEgMDIgMDAgMDAgMDAgMDAgIDAwIDA1IDIwIDAwIDAwIDAwIDJhIDAyICAgSS4uLi4uLi4u LiAuLi4qLiAgDQogIDA1MzA6ICAwMCAwMCAwMCAwMCAxOCAwMCAxMCAwMCAgMDIgMDAgMDEgMDIg MDAgMDAgMDAgMDAgICAuLi4uLi4uLi4uLi4uLi4uICANCiAgMDU0MDogIDAwIDA1IDIwIDAwIDAw IDAwIDJhIDAyICAwMCAwMCAwNSAwYSAyYyAwMCA5NCAwMCAgIC4uIC4uLiouLi4uLiwuLi4gIA0K ICAwNTUwOiAgMDIgMDAgMDIgMDAgMDAgMDAgYmEgN2EgIDk2IGJmIGU2IDBkIGQwIDExIGEyIDg1 ICAgLi4uLi4uLnouLi4uLi4uLiAgDQogIDA1NjA6ICAwMCBhYSAwMCAzMCA0OSBlMiAwMSAwMiAg MDAgMDAgMDAgMDAgMDAgMDUgMjAgMDAgICAuLi4wSS4uLi4uLi4uLiAuICANCiAgMDU3MDogIDAw IDAwIDJhIDAyIDAwIDAwIDAwIDAwICAxNCAwMCA5NCAwMCAwMiAwMCAwMSAwMSAgIC4uKi4uLi4u Li4uLi4uLi4gIA0KICAwNTgwOiAgMDAgMDAgMDAgMDAgMDAgMDUgMDkgMDAgIDAwIDAwIDA1IDBh IDNjIDAwIDEwIDAwICAgLi4uLi4uLi4uLi4uPC4uLiAgDQogIDA1OTA6ICAwMCAwMCAwMyAwMCAw MCAwMCBmOCA4OCAgNzAgMDMgZTEgMGEgZDIgMTEgYjQgMjIgICAuLi4uLi4uLnAuLi4uLi4iICAN CiAgMDVhMDogIDAwIGEwIGM5IDY4IGY5IDM5IDE0IGNjICAyOCA0OCAzNyAxNCBiYyA0NSA5YiAw NyAgIC4uLmguOS4uKEg3Li5FLi4gIA0KICAwNWIwOiAgYWQgNmYgMDEgNWUgNWYgMjggMDEgMDIg IDAwIDAwIDAwIDAwIDAwIDA1IDIwIDAwICAgLm8uXl8oLi4uLi4uLi4gLiAgDQogIDA1YzA6ICAw MCAwMCAyYSAwMiAwMCAwMCAwNSAwYSAgM2MgMDAgMTAgMDAgMDAgMDAgMDMgMDAgICAuLiouLi4u LjwuLi4uLi4uICANCiAgMDVkMDogIDAwIDAwIDQyIDJmIGJhIDU5IGEyIDc5ICBkMCAxMSA5MCAy MCAwMCBjMCA0ZiBjMiAgIC4uQi8uWS55Li4uIC4uTy4gIA0KICAwNWUwOiAgZDMgY2YgMTQgY2Mg MjggNDggMzcgMTQgIGJjIDQ1IDliIDA3IGFkIDZmIDAxIDVlICAgLi4uLihINy4uRS4uLm8uXiAg DQogIDA1ZjA6ICA1ZiAyOCAwMSAwMiAwMCAwMCAwMCAwMCAgMDAgMDUgMjAgMDAgMDAgMDAgMmEg MDIgICBfKC4uLi4uLi4uIC4uLiouICANCiAgMDYwMDogIDAwIDAwIDA1IDBhIDNjIDAwIDEwIDAw ICAwMCAwMCAwMyAwMCAwMCAwMCA0MCBjMiAgIC4uLi48Li4uLi4uLi4uQC4gIA0KICAwNjEwOiAg MGEgYmMgYTkgNzkgZDAgMTEgOTAgMjAgIDAwIGMwIDRmIGMyIGQ0IGNmIDE0IGNjICAgLi4ueS4u LiAuLk8uLi4uLiAgDQogIDA2MjA6ICAyOCA0OCAzNyAxNCBiYyA0NSA5YiAwNyAgYWQgNmYgMDEg NWUgNWYgMjggMDEgMDIgICAoSDcuLkUuLi5vLl5fKC4uICANCiAgMDYzMDogIDAwIDAwIDAwIDAw IDAwIDA1IDIwIDAwICAwMCAwMCAyYSAwMiAwMCAwMCAwNSAwYSAgIC4uLi4uLiAuLi4qLi4uLi4g IA0KICAwNjQwOiAgM2MgMDAgMTAgMDAgMDAgMDAgMDMgMDAgIDAwIDAwIDAwIDQyIDE2IDRjIGMw IDIwICAgPC4uLi4uLi4uLi5CLkwuICAgDQogIDA2NTA6ICBkMCAxMSBhNyA2OCAwMCBhYSAwMCA2 ZSAgMDUgMjkgMTQgY2MgMjggNDggMzcgMTQgICAuLi5oLi4ubi4pLi4oSDcuICANCiAgMDY2MDog IGJjIDQ1IDliIDA3IGFkIDZmIDAxIDVlICA1ZiAyOCAwMSAwMiAwMCAwMCAwMCAwMCAgIC5FLi4u by5eXyguLi4uLi4gIA0KICAwNjcwOiAgMDAgMDUgMjAgMDAgMDAgMDAgMmEgMDIgIDAwIDAwIDA1 IDBhIDNjIDAwIDEwIDAwICAgLi4gLi4uKi4uLi4uPC4uLiAgDQogIDA2ODA6ICAwMCAwMCAwMyAw MCAwMCAwMCAxMCAyMCAgMjAgNWYgYTUgNzkgZDAgMTEgOTAgMjAgICAuLi4uLi4uICBfLnkuLi4g ICANCiAgMDY5MDogIDAwIGMwIDRmIGMyIGQ0IGNmIDE0IGNjICAyOCA0OCAzNyAxNCBiYyA0NSA5 YiAwNyAgIC4uTy4uLi4uKEg3Li5FLi4gIA0KICAwNmEwOiAgYWQgNmYgMDEgNWUgNWYgMjggMDEg MDIgIDAwIDAwIDAwIDAwIDAwIDA1IDIwIDAwICAgLm8uXl8oLi4uLi4uLi4gLiAgDQogIDA2YjA6 ICAwMCAwMCAyYSAwMiAwMCAwMCAwNSAwYSAgMmMgMDAgOTQgMDAgMDIgMDAgMDIgMDAgICAuLiou Li4uLiwuLi4uLi4uICANCiAgMDZjMDogIDAwIDAwIDE0IGNjIDI4IDQ4IDM3IDE0ICBiYyA0NSA5 YiAwNyBhZCA2ZiAwMSA1ZSAgIC4uLi4oSDcuLkUuLi5vLl4gIA0KICAwNmQwOiAgNWYgMjggMDEg MDIgMDAgMDAgMDAgMDAgIDAwIDA1IDIwIDAwIDAwIDAwIDJhIDAyICAgXyguLi4uLi4uLiAuLi4q LiAgDQogIDA2ZTA6ICAwMCAwMCAwNSAwMCAyYyAwMCAxMCAwMCAgMDAgMDAgMDEgMDAgMDAgMDAg ZDAgOWYgICAuLi4uLC4uLi4uLi4uLi4uICANCiAgMDZmMDogIDExIGI4IGY2IDA0IDYyIDQ3IGFi IDdhICA0OSA4NiBjNyA2YiAzZiA5YSAwMSAwMiAgIC4uLi5iRy56SS4uaz8uLi4gIA0KICAwNzAw OiAgMDAgMDAgMDAgMDAgMDAgMDUgMjAgMDAgIDAwIDAwIDJhIDAyIDAwIDAwIDA1IDAwICAgLi4u Li4uIC4uLiouLi4uLiAgDQogIDA3MTA6ICAyOCAwMCAxMCAwMCAwMCAwMCAwMSAwMCAgMDAgMDAg ZDAgOWYgMTEgYjggZjYgMDQgICAoLi4uLi4uLi4uLi4uLi4uICANCiAgMDcyMDogIDYyIDQ3IGFi IDdhIDQ5IDg2IGM3IDZiICAzZiA5YSAwMSAwMSAwMCAwMCAwMCAwMCAgIGJHLnpJLi5rPy4uLi4u Li4gIA0KICAwNzMwOiAgMDAgMDUgMGIgMDAgMDAgMDAgMDUgMGEgIDM4IDAwIDEwIDAwIDAwIDAw IDAzIDAwICAgLi4uLi4uLi44Li4uLi4uLiAgDQogIDA3NDA6ICAwMCAwMCA2ZCA5ZSBjNiBiNyBj NyAyYyAgZDIgMTEgODUgNGUgMDAgYTAgYzkgODMgICAuLm0uLi4uLC4uLk4uLi4uICANCiAgMDc1 MDogIGY2IDA4IGJhIDdhIDk2IGJmIGU2IDBkICBkMCAxMSBhMiA4NSAwMCBhYSAwMCAzMCAgIC4u LnouLi4uLi4uLi4uLjAgIA0KICAwNzYwOiAgNDkgZTIgMDEgMDEgMDAgMDAgMDAgMDAgIDAwIDA1 IDA5IDAwIDAwIDAwIDA1IDBhICAgSS4uLi4uLi4uLi4uLi4uLiAgDQogIDA3NzA6ICAzOCAwMCAx MCAwMCAwMCAwMCAwMyAwMCAgMDAgMDAgNmQgOWUgYzYgYjcgYzcgMmMgICA4Li4uLi4uLi4ubS4u Li4sICANCiAgMDc4MDogIGQyIDExIDg1IDRlIDAwIGEwIGM5IDgzICBmNiAwOCA5YyA3YSA5NiBi ZiBlNiAwZCAgIC4uLk4uLi4uLi4uei4uLi4gIA0KICAwNzkwOiAgZDAgMTEgYTIgODUgMDAgYWEg MDAgMzAgIDQ5IGUyIDAxIDAxIDAwIDAwIDAwIDAwICAgLi4uLi4uLjBJLi4uLi4uLiAgDQogIDA3 YTA6ICAwMCAwNSAwOSAwMCAwMCAwMCAwNSAwYSAgMzggMDAgMTAgMDAgMDAgMDAgMDMgMDAgICAu Li4uLi4uLjguLi4uLi4uICANCiAgMDdiMDogIDAwIDAwIDZkIDllIGM2IGI3IGM3IDJjICBkMiAx MSA4NSA0ZSAwMCBhMCBjOSA4MyAgIC4ubS4uLi4sLi4uTi4uLi4gIA0KICAwN2MwOiAgZjYgMDgg ODYgN2EgOTYgYmYgZTYgMGQgIGQwIDExIGEyIDg1IDAwIGFhIDAwIDMwICAgLi4uei4uLi4uLi4u Li4uMCAgDQogIDA3ZDA6ICA0OSBlMiAwMSAwMSAwMCAwMCAwMCAwMCAgMDAgMDUgMDkgMDAgMDAg MDAgMDUgMDAgICBJLi4uLi4uLi4uLi4uLi4uICANCiAgMDdlMDogIDM4IDAwIDAwIDAxIDAwIDAw IDAxIDAwICAwMCAwMCBhZCBmNiAzMSAxMSAwNyA5YyAgIDguLi4uLi4uLi4uLjEuLi4gIA0KICAw N2YwOiAgZDEgMTEgZjcgOWYgMDAgYzAgNGYgYzIgIGRjIGQyIDAxIDA1IDAwIDAwIDAwIDAwICAg Li4uLi4uTy4uLi4uLi4uLiAgDQogIDA4MDA6ICAwMCAwNSAxNSAwMCAwMCAwMCAyZiBmMiAgNWMg ZGQgOTkgZDcgNzUgZjQgYWQgYjkgICAuLi4uLi4vLlwuLi51Li4uICANCiAgMDgxMDogIDgwIDVk IDA0IDAyIDAwIDAwIDA1IDAwICAyYyAwMCAwMCAwMSAwMCAwMCAwMSAwMCAgIC5dLi4uLi4uLC4u Li4uLi4gIA0KICAwODIwOiAgMDAgMDAgYWQgZjYgMzEgMTEgMDcgOWMgIGQxIDExIGY3IDlmIDAw IGMwIDRmIGMyICAgLi4uLjEuLi4uLi4uLi5PLiAgDQogIDA4MzA6ICBkYyBkMiAwMSAwMiAwMCAw MCAwMCAwMCAgMDAgMDUgMjAgMDAgMDAgMDAgMjAgMDIgICAuLi4uLi4uLi4uIC4uLiAuICANCiAg MDg0MDogIDAwIDAwIDA1IDAwIDJjIDAwIDAwIDAxICAwMCAwMCAwMSAwMCAwMCAwMCBjOSA2ZCAg IC4uLi4sLi4uLi4uLi4uLm0gIA0KICAwODUwOiAgYTMgZTIgMTcgYWUgYzMgNDcgYjUgOGIgIGJl IDM0IGM1IDViIGE2IDMzIDAxIDAyICAgLi4uLi5HLi4uNC5bLjMuLiAgDQogIDA4NjA6ICAwMCAw MCAwMCAwMCAwMCAwNSAyMCAwMCAgMDAgMDAgMmQgMDIgMDAgMDAgMDUgMDAgICAuLi4uLi4gLi4u LS4uLi4uICANCiAgMDg3MDogIDI4IDAwIDAwIDAxIDAwIDAwIDAxIDAwICAwMCAwMCA5YyAzNiAw ZiAyOCBjNyA2NyAgICguLi4uLi4uLi4uNi4oLmcgIA0KICAwODgwOiAgOGUgNDMgYWUgOTggMWQg NDYgZjMgYzYgIGY1IDQxIDAxIDAxIDAwIDAwIDAwIDAwICAgLkMuLi5GLi4uQS4uLi4uLiAgDQog IDA4OTA6ICAwMCAwNSAwYiAwMCAwMCAwMCAwNSAwMCAgMjggMDAgMDAgMDEgMDAgMDAgMDEgMDAg ICAuLi4uLi4uLiguLi4uLi4uICANCiAgMDhhMDogIDAwIDAwIDdkIGRjIGMyIGNjIGFkIGE2ICA3 YSA0YSA4OCA0NiBjMCA0ZSAzYyBjNSAgIC4ufS4uLi4uekouRi5OPC4gIA0KICAwOGIwOiAgMzUg MDEgMDEgMDEgMDAgMDAgMDAgMDAgIDAwIDA1IDBiIDAwIDAwIDAwIDA1IDAwICAgNS4uLi4uLi4u Li4uLi4uLiAgDQogIDA4YzA6ICAyOCAwMCAwMCAwMSAwMCAwMCAwMSAwMCAgMDAgMDAgNWUgNGMg YzcgMDUgZWIgNGQgICAoLi4uLi4uLi4uXkwuLi5NICANCiAgMDhkMDogIGI0IDQzIGJkIDlmIDg2 IDY2IDRjIDJhICA3ZiBkNSAwMSAwMSAwMCAwMCAwMCAwMCAgIC5DLi4uZkwqLi4uLi4uLi4gIA0K ICAwOGUwOiAgMDAgMDUgMGIgMDAgMDAgMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLi4uLi4uICAgICAgICAgICAgDQpiZXJfZ2V0X25leHQ6IHRhZyAweDMwIGxlbiAyMjgyIGNv bnRlbnRzOg0KYmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCBlcnJvcj1SZXNvdXJjZSB0 ZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KY29ubj02IG9wPTQgZG9fYWRkDQpiZXJfc2NhbmYgZm10 ICh7bSkgYmVyOg0KY29ubj02IG9wPTQgZG9fYWRkOiBkbiAoREM9c2FtYmEsREM9ZXhhbXBsZSxE Qz1jb20pDQpiZXJfc2NhbmYgZm10ICh7bXtXfX0pIGJlcjoNCmJlcl9zY2FuZiBmbXQgKHtte1d9 fSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoe217V319KSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bXtX fX0pIGJlcjoNCmJlcl9zY2FuZiBmbXQgKHtte1d9fSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAofSkg YmVyOg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20+DQo9 PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBsZGFwX2J2MmRu KERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBs ZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy NzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8IGRu UHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9c2FtYmEsZGM9 ZXhhbXBsZSxkYz1jb20+DQo+Pj4gZG5QcmV0dHk6IDxDTj1ET01BSU4tRE5TLENOPVNDSEVNQSxD Tj1DT05GSUdVUkFUSU9OLERDPVNBTUJBLERDPUVYQU1QTEUsREM9Q09NPg0KPT4gbGRhcF9idjJk bihDTj1ET01BSU4tRE5TLENOPVNDSEVNQSxDTj1DT05GSUdVUkFUSU9OLERDPVNBTUJBLERDPUVY QU1QTEUsREM9Q09NLDApDQo8PSBsZGFwX2J2MmRuKENOPURPTUFJTi1ETlMsQ049U0NIRU1BLENO PUNPTkZJR1VSQVRJT04sREM9U0FNQkEsREM9RVhBTVBMRSxEQz1DT00pPTAgDQo9PiBsZGFwX2Ru MmJ2KDI3MikNCjw9IGxkYXBfZG4yYnYoY249RE9NQUlOLUROUyxjbj1TQ0hFTUEsY249Q09ORklH VVJBVElPTixkYz1TQU1CQSxkYz1FWEFNUExFLGRjPUNPTSk9MCANCjw8PCBkblByZXR0eTogPGNu PURPTUFJTi1ETlMsY249U0NIRU1BLGNuPUNPTkZJR1VSQVRJT04sZGM9U0FNQkEsZGM9RVhBTVBM RSxkYz1DT00+DQo+Pj4gZG5Ob3JtYWxpemU6IDxjbj1ET01BSU4tRE5TLGNuPVNDSEVNQSxjbj1D T05GSUdVUkFUSU9OLGRjPVNBTUJBLGRjPUVYQU1QTEUsZGM9Q09NPg0KPT4gbGRhcF9idjJkbihj bj1ET01BSU4tRE5TLGNuPVNDSEVNQSxjbj1DT05GSUdVUkFUSU9OLGRjPVNBTUJBLGRjPUVYQU1Q TEUsZGM9Q09NLDApDQo8PSBsZGFwX2J2MmRuKGNuPURPTUFJTi1ETlMsY249U0NIRU1BLGNuPUNP TkZJR1VSQVRJT04sZGM9U0FNQkEsZGM9RVhBTVBMRSxkYz1DT00pPTAgDQo9PiBsZGFwX2RuMmJ2 KDI3MikNCjw9IGxkYXBfZG4yYnYoY249ZG9tYWluLWRucyxjbj1zY2hlbWEsY249Y29uZmlndXJh dGlvbixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbSk9MCANCjw8PCBkbk5vcm1hbGl6ZTogPGNu PWRvbWFpbi1kbnMsY249c2NoZW1hLGNuPWNvbmZpZ3VyYXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20+DQpiZGJfZG4yZW50cnkoImRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tIikNCmhk Yl9yZWZlcnJhbHM6IHRhZz0xMDQgdGFyZ2V0PSJkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbSIg bWF0Y2hlZD0iIg0KPT0+IGhkYl9hZGQ6IGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tDQpvY19j aGVja19yZXF1aXJlZCBlbnRyeSAoZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pLCBvYmplY3RD bGFzcyAiZG9tYWluRE5TIg0Kb2NfY2hlY2tfcmVxdWlyZWQgZW50cnkgKGRjPXNhbWJhLGRjPWV4 YW1wbGUsZGM9Y29tKSwgb2JqZWN0Q2xhc3MgImV4dGVuc2libGVPYmplY3QiDQpiZGJfZG4yZW50 cnkoImRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tIikNCj0+IGluZGV4X2VudHJ5X2FkZCggMSwg ImRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tIiApDQo9PiBrZXlfY2hhbmdlKEFERCwxKQ0KYmRi X2lkbF9pbnNlcnRfa2V5OiAxIFswMDk2ZGVmZF0NCjw9IGtleV9jaGFuZ2UgMA0KPT4ga2V5X2No YW5nZShBREQsMSkNCmJkYl9pZGxfaW5zZXJ0X2tleTogMSBbNWZmNjgwNmNdDQo8PSBrZXlfY2hh bmdlIDANCj0+IGtleV9jaGFuZ2UoQURELDEpDQpiZGJfaWRsX2luc2VydF9rZXk6IDEgWzZjZGRm YWYzXQ0KPD0ga2V5X2NoYW5nZSAwDQo9PiBrZXlfY2hhbmdlKEFERCwxKQ0KYmRiX2lkbF9pbnNl cnRfa2V5OiAxIFtiNTQ1Mzk5Zl0NCjw9IGtleV9jaGFuZ2UgMA0KPT4ga2V5X2NoYW5nZShBREQs MSkNCmJkYl9pZGxfaW5zZXJ0X2tleTogMSBbYTQyM2UwN2VdDQo8PSBrZXlfY2hhbmdlIDANCjw9 IGluZGV4X2VudHJ5X2FkZCggMSwgImRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tIiApIHN1Y2Nl c3MNCj0+IGVudHJ5X2VuY29kZSgweDAwMDAwMDAxKTogDQpoZGJfYWRkOiBhZGRlZCBpZD0wMDAw MDAwMSBkbj0iZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20iDQpzZW5kX2xkYXBfcmVzdWx0OiBj b25uPTYgb3A9NCBwPTMNCnNlbmRfbGRhcF9yZXN1bHQ6IGVycj0wIG1hdGNoZWQ9IiIgdGV4dD0i Ig0KaGRiX21vZGlmeTogZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20NCmJkYl9kbjJlbnRyeSgi ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20iKQ0KYmRiX21vZGlmeV9pbnRlcm5hbDogMHgwMDAw MDAwMTogZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20NCmJkYl9tb2RpZnlfaW50ZXJuYWw6IHJl cGxhY2UgY29udGV4dENTTg0KPT4gZW50cnlfZW5jb2RlKDB4MDAwMDAwMDEpOiANCnNsYXBfbGlz dGVuZXJfYWN0aXZhdGUoNyk6IA0KPj4+IHNsYXBfbGlzdGVuZXIobGRhcGk6Ly8lMkZob21lJTJG ZGF0YSUyRnNhbWJhJTJGc2FtYmE0JTJGY2xlYW4lMkZzb3VyY2UlMkZzdCUyRmRjJTJGcHJpdmF0 ZSUyRmxkYXAlMkZsZGFwaSkNCmNvbm5lY3Rpb25fZ2V0KDI1KQ0KY29ubmVjdGlvbl9nZXQoMjUp OiBnb3QgY29ubmlkPTcNCmNvbm5lY3Rpb25fcmVhZCgyNSk6IGNoZWNraW5nIGZvciBpbnB1dCBv biBpZD03DQpiZXJfZ2V0X25leHQNCmxkYXBfcmVhZDogd2FudD04LCBnb3Q9OA0KICAwMDAwOiAg MzAgM2MgMDIgMDEgMDEgNjAgMzcgMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDwuLi5g Ny4gICAgICAgICAgDQpsZGFwX3JlYWQ6IHdhbnQ9NTQsIGdvdD01NA0KICAwMDAwOiAgMDEgMDMg MDQgMjUgNjMgNmUgM2QgNGQgIDYxIDZlIDYxIDY3IDY1IDcyIDJjIDY0ICAgLi4uJWNuPU1hbmFn ZXIsZCAgDQogIDAwMTA6ICA2MyAzZCA3MyA2MSA2ZCA2MiA2MSAyYyAgNjQgNjMgM2QgNjUgNzgg NjEgNmQgNzAgICBjPXNhbWJhLGRjPWV4YW1wICANCiAgMDAyMDogIDZjIDY1IDJjIDY0IDYzIDNk IDYzIDZmICA2ZCA4MCAwYiA2YyA2ZiA2MyA2MSA2YyAgIGxlLGRjPWNvbS4ubG9jYWwgIA0KICAw MDMwOiAgNjQgNjMgNzAgNjEgNzMgNzMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZGNwYXNzICAgICAgICAgICAgDQpiZXJfZ2V0X25leHQ6IHRhZyAweDMwIGxlbiA2MCBjb250ZW50 czoNCmJlcl9nZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTggZXJyb3I9UmVzb3VyY2UgdGVtcG9y YXJpbHkgdW5hdmFpbGFibGUNCmNvbm49NyBvcD0wIGRvX2JpbmQNCmJlcl9zY2FuZiBmbXQgKHtp bXQpIGJlcjoNCmJlcl9zY2FuZiBmbXQgKG19KSBiZXI6DQo+Pj4gZG5QcmV0dHlOb3JtYWw6IDxj bj1NYW5hZ2VyLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tPg0KPT4gbGRhcF9idjJkbihjbj1N YW5hZ2VyLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tLDApDQo8PSBsZGFwX2J2MmRuKGNuPU1h bmFnZXIsZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikN Cjw9IGxkYXBfZG4yYnYoY249TWFuYWdlcixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbSk9MCAN Cj0+IGxkYXBfZG4yYnYoMjcyKQ0KPD0gbGRhcF9kbjJidihjbj1tYW5hZ2VyLGRjPXNhbWJhLGRj PWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8IGRuUHJldHR5Tm9ybWFsOiA8Y249TWFuYWdlcixkYz1z YW1iYSxkYz1leGFtcGxlLGRjPWNvbT4sIDxjbj1tYW5hZ2VyLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0KZG9fYmluZDogdmVyc2lvbj0zIGRuPSJjbj1NYW5hZ2VyLGRjPXNhbWJhLGRjPWV4 YW1wbGUsZGM9Y29tIiBtZXRob2Q9MTI4DQo9PT4gaGRiX2JpbmQ6IGRuOiBjbj1NYW5hZ2VyLGRj PXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tDQpkb19iaW5kOiB2MyBiaW5kOiAiY249TWFuYWdlcixk Yz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbSIgdG8gImNuPU1hbmFnZXIsZGM9c2FtYmEsZGM9ZXhh bXBsZSxkYz1jb20iDQpzZW5kX2xkYXBfcmVzdWx0OiBjb25uPTcgb3A9MCBwPTMNCnNlbmRfbGRh cF9yZXN1bHQ6IGVycj0wIG1hdGNoZWQ9IiIgdGV4dD0iIg0Kc2VuZF9sZGFwX3Jlc3BvbnNlOiBt c2dpZD0xIHRhZz05NyBlcnI9MA0KYmVyX2ZsdXNoMjogMTQgYnl0ZXMgdG8gc2QgMjUNCiAgMDAw MDogIDMwIDBjIDAyIDAxIDAxIDYxIDA3IDBhICAwMSAwMCAwNCAwMCAwNCAwMCAgICAgICAgIDAu Li4uYS4uLi4uLi4uICAgIA0KbGRhcF93cml0ZTogd2FudD0xNCwgd3JpdHRlbj0xNA0KICAwMDAw OiAgMzAgMGMgMDIgMDEgMDEgNjEgMDcgMGEgIDAxIDAwIDA0IDAwIDA0IDAwICAgICAgICAgMC4u Li5hLi4uLi4uLi4gICAgDQpjb25uZWN0aW9uX2dldCgyNSkNCmNvbm5lY3Rpb25fZ2V0KDI1KTog Z290IGNvbm5pZD03DQpjb25uZWN0aW9uX3JlYWQoMjUpOiBjaGVja2luZyBmb3IgaW5wdXQgb24g aWQ9Nw0KYmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMw IDZkIDAyIDAxIDAyIDY4IDY4IDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBtLi4uaGgu ICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTEwMywgZ290PTEwMw0KICAwMDAwOiAgMWEgNDQg NDMgM2QgNzMgNjEgNmQgNjIgIDYxIDJjIDQ0IDQzIDNkIDY1IDc4IDYxICAgLkRDPXNhbWJhLERD PWV4YSAgDQogIDAwMTA6ICA2ZCA3MCA2YyA2NSAyYyA0NCA0MyAzZCAgNjMgNmYgNmQgMzAgNGEg MzAgMzkgMDQgICBtcGxlLERDPWNvbTBKMDkuICANCiAgMDAyMDogIDBiIDZmIDYyIDZhIDY1IDYz IDc0IDQzICA2YyA2MSA3MyA3MyAzMSAyYSAwNCAwMyAgIC5vYmplY3RDbGFzczEqLi4gIA0KICAw MDMwOiAgNzQgNmYgNzAgMDQgMDYgNjQgNmYgNmQgIDYxIDY5IDZlIDA0IDA5IDY0IDZmIDZkICAg dG9wLi5kb21haW4uLmRvbSAgDQogIDAwNDA6ICA2MSA2OSA2ZSA0NCA0ZSA1MyAwNCAxMCAgNjUg NzggNzQgNjUgNmUgNzMgNjkgNjIgICBhaW5ETlMuLmV4dGVuc2liICANCiAgMDA1MDogIDZjIDY1 IDRmIDYyIDZhIDY1IDYzIDc0ICAzMCAwZCAwNCAwMiA2NCA2MyAzMSAwNyAgIGxlT2JqZWN0MC4u LmRjMS4gIA0KICAwMDYwOiAgMDQgMDUgNzMgNjEgNmQgNjIgNjEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLi5zYW1iYSAgICAgICAgICAgDQpiZXJfZ2V0X25leHQ6IHRhZyAweDMwIGxl biAxMDkgY29udGVudHM6DQpiZXJfZ2V0X25leHQNCmxkYXBfcmVhZDogd2FudD04IGVycm9yPVJl c291cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQpjb25uPTcgb3A9MSBkb19hZGQNCmJlcl9z Y2FuZiBmbXQgKHttKSBiZXI6DQpjb25uPTcgb3A9MSBkb19hZGQ6IGRuIChEQz1zYW1iYSxEQz1l eGFtcGxlLERDPWNvbSkNCmJlcl9zY2FuZiBmbXQgKHtte1d9fSkgYmVyOg0KYmVyX3NjYW5mIGZt dCAoe217V319KSBiZXI6DQpiZXJfc2NhbmYgZm10ICh9KSBiZXI6DQo+Pj4gZG5QcmV0dHlOb3Jt YWw6IDxEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT4NCj0+IGxkYXBfYnYyZG4oREM9c2FtYmEs REM9ZXhhbXBsZSxEQz1jb20sMCkNCjw9IGxkYXBfYnYyZG4oREM9c2FtYmEsREM9ZXhhbXBsZSxE Qz1jb20pPTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikNCjw9IGxkYXBfZG4yYnYoZGM9c2FtYmEsZGM9 ZXhhbXBsZSxkYz1jb20pPTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikNCjw9IGxkYXBfZG4yYnYoZGM9 c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5QcmV0dHlOb3JtYWw6IDxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbT4sIDxkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbT4NCmJkYl9k bjJlbnRyeSgiZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20iKQ0K --=-k5lHyfbmg0BMeRkyykUB-- --=-Y3mFtyVHKLn0c8Gx/BD0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHVof+z4A8Wyi0NrsRAk9xAJsHWQAw6AhUQp2UqZ/arCtlj/qwWQCffN3W eJg7ITzxs7KC47/6RA0cayU= =fmFU -----END PGP SIGNATURE----- --=-Y3mFtyVHKLn0c8Gx/BD0--

1 0

Re: (ITS#5257) test008 hanging in bdb
by hyc＠symas.com 05 Dec '07

05 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Hah. thr_debug found it (at least I presume it's the same bug) after 70 > iterations over test008. Just to confirm, test008 failed after 87 iterations even with this patch. So as I said in my previous email, going down this code path is just a side effect of the original bug. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 05 Dec '07

05 Dec '07

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: cvs 2007-12-05 > OS: Fedora 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > > Using Samba4's 'make test', I can hang OpenLDAP's slapd. Samba4 SVN -r 26305 > > That is, it will not process any further requests, but is waiting in > pthread_join(), not stuck somewhere else. > > OpenLDAP was built with: > `dirname $0`/configure --enable-overlays=yes --enable-modules --enable-dynamic > --enable-syncprov=yes > > Samba4 was built with: > CC="ccache gcc" CFLAGS="-O3" ./configure --enable-developer -C > --prefix=/data/samba/samba4/prefix > --with-winbindd-socket-dir=/data/samba/samba4/prefix/wb > > Samba4 testsuite command line: > > OPENLDAP_PATH=/usr/local/libexec:/usr/local/sbin TEST_LDAP=yes make test > > This hangs during the 'provision' processing. > > Note that this outputs an ldapi:// URL. Using that URL, this test shows it's > not just samba that is stuck: > > ldapadd -H ldapi://%2Fhome%2Fdata%2Fsamba%2Fsamba4%2Fclean%2Fsource%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi > -f st/dc/private/ldap/samba.example.com.ldif -D > cn=Manager,dc=samba,dc=example,dc=com -w localdcpass -x You should run slapd with -d debugging enabled and (I usually start with -d7) send the info for the last few requests prior to the hang. Also, you should use gdb to attach to the slapd and get a trace of all the threads to see where they've gotten stuck. http://www.openldap.org/faq/data/cache/59.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5261)
by abartlet＠samba.org 05 Dec '07

05 Dec '07

--=-sj7eji9lwVRllTKtUS/q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable BTW, the SVN URL is: svn://svnanon.samba.org/samba/branches/SAMBA_4_0 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-sj7eji9lwVRllTKtUS/q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHVmdyz4A8Wyi0NrsRAoR8AKClVLbCKEm+OVUqGX8lNYVAyt7QzgCfR9vh 0klH1DFlRZKV6POw3tC6lnQ= =aa6D -----END PGP SIGNATURE----- --=-sj7eji9lwVRllTKtUS/q--

1 0

(ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 05 Dec '07

05 Dec '07

Full_Name: Andrew Bartlett Version: cvs 2007-12-05 OS: Fedora 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Using Samba4's 'make test', I can hang OpenLDAP's slapd. Samba4 SVN -r 26305 That is, it will not process any further requests, but is waiting in pthread_join(), not stuck somewhere else. OpenLDAP was built with: `dirname $0`/configure --enable-overlays=yes --enable-modules --enable-dynamic --enable-syncprov=yes Samba4 was built with: CC="ccache gcc" CFLAGS="-O3" ./configure --enable-developer -C --prefix=/data/samba/samba4/prefix --with-winbindd-socket-dir=/data/samba/samba4/prefix/wb Samba4 testsuite command line: OPENLDAP_PATH=/usr/local/libexec:/usr/local/sbin TEST_LDAP=yes make test This hangs during the 'provision' processing. Note that this outputs an ldapi:// URL. Using that URL, this test shows it's not just samba that is stuck: ldapadd -H ldapi://%2Fhome%2Fdata%2Fsamba%2Fsamba4%2Fclean%2Fsource%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi -f st/dc/private/ldap/samba.example.com.ldif -D cn=Manager,dc=samba,dc=example,dc=com -w localdcpass -x

1 0

Re: (ITS#5257) test008 hanging in bdb
by hyc＠symas.com 05 Dec '07

05 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Hah. thr_debug found it (at least I presume it's the same bug) after 70 > iterations over test008. > > Compiled with > CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_REL_ENG' CFLAGS='-O0 -g' > run with export LDAP_THREAD_DEBUG=nocount > > backtrace and testrun directory: > http://folk.uio.no/hbf/test008bug-071204.tbz > > slapd.1.log ends with: > > ====> bdb_cache_delete( 146 ) > thr_debug.c:1024: ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex ) > > The mutex owner is ldap_debug_thread_none, i.e. the mutex is not locked. > > It's cache.c:874:bdb_cache_entryinfo_unlock( *eip ); in bdb_cache_find_id(). > #3 0x00000000004e1df9 in bdb_cache_find_id (op=0x1ebb46a0, tid=0x0, id=4, eip=0x45809ad0, flag=1, locker=38, > lock=0x45809b20) at cache.c:874 > > > I had to patch thr_posix.c a bit to detect Linux NPTL threads: > > diff -u -2 -r1.50 thr_posix.c > --- thr_posix.c 25 Oct 2007 04:42:40 -0000 1.50 > +++ thr_posix.c 4 Dec 2007 23:06:29 -0000 > @@ -45,6 +45,6 @@ > #ifdef LDAP_THREAD_DEBUG > # if defined LDAP_INT_THREAD_MUTEXATTR /* May be defined in CPPFLAGS */ > -# elif defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP > - /* LinuxThreads hack */ > +# elif 1 || defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP > + /* LinuxThreads and NPTL hack */ > # define LDAP_INT_THREAD_MUTEXATTR PTHREAD_MUTEX_ERRORCHECK_NP > # else Ah, that one actually makes sense. Fix in HEAD. Unfortunately, this code path is only being triggered because of the other bug, it's not the root cause. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 05 Dec '07

05 Dec '07

Just hit this again today. (gdb) info threads 10 Thread 1082132800 (LWP 15704) 0xffffffffff600410 in ?? () * 9 Thread 1090525504 (LWP 15705) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 8 Thread 1098918208 (LWP 15706) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 7 Thread 1107310912 (LWP 15707) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 6 Thread 1115703616 (LWP 32142) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 5 Thread 1124096320 (LWP 1167) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 4 Thread 1132489024 (LWP 1168) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 3 Thread 1140881728 (LWP 1431) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 2 Thread 1149274432 (LWP 1432) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 1 Thread 46912515736208 (LWP 15700) 0x00000038dcc074e5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 10 [Switching to thread 10 (Thread 1082132800 (LWP 15704))]#0 0xffffffffff600410 in ?? () (gdb) bt #0 0xffffffffff600410 in ?? () #1 0x00000038dc0862dd in time () from /lib64/libc.so.6 #2 0x0000000000428530 in slapd_daemon_task (ptr=0x0) at daemon.c:2033 #3 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #4 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #5 0x0000000000000000 in ?? () (gdb) thread 9 [Switching to thread 9 (Thread 1090525504 (LWP 15705))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xc48fc00, rs=0x41000d00) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xc48fc00, rs=0x41000d00, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xc48fc00, rs=0x41000d00, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xc48fc00, rs=0x41000d00) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xc48fc00, rs=0x41000d00) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xc48fc00, rs=0x41000d00) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x41000de0, arg_v=0xc48fc00) at connection.c:1133 #11 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #12 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) thread 8 [Switching to thread 8 (Thread 1098918208 (LWP 15706))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xd5f7600, rs=0x41801ca0) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xd5f7600, rs=0x41801ca0, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xd5f7600, rs=0x41801ca0, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xd5f7600, rs=0x41801ca0) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xd5f7600, rs=0x41801ca0) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xd5f7600, rs=0x41801ca0) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x41801de0, arg_v=0xd5f7600) at connection.c:1133 #11 0x000000000042c7b0 in connection_read_thread (ctx=0x41801de0, argv=0x1d) at connection.c:1261 #12 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #13 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #14 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) thread 7 [Switching to thread 7 (Thread 1107310912 (LWP 15707))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xc48f900, rs=0x42002ca0) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xc48f900, rs=0x42002ca0, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xc48f900, rs=0x42002ca0, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xc48f900, rs=0x42002ca0) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xc48f900, rs=0x42002ca0) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xc48f900, rs=0x42002ca0) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x42002de0, arg_v=0xc48f900) at connection.c:1133 #11 0x000000000042c7b0 in connection_read_thread (ctx=0x42002de0, argv=0x1c) at connection.c:1261 #12 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #13 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #14 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) thread 6 [Switching to thread 6 (Thread 1115703616 (LWP 32142))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xb20ac00, rs=0x42803d00) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xb20ac00, rs=0x42803d00, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xb20ac00, rs=0x42803d00, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xb20ac00, rs=0x42803d00) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xb20ac00, rs=0x42803d00) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xb20ac00, rs=0x42803d00) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x42803de0, arg_v=0xb20ac00) at connection.c:1133 #11 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #12 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) thread 5 [Switching to thread 5 (Thread 1124096320 (LWP 1167))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xd5f7c00, rs=0x43004d00) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xd5f7c00, rs=0x43004d00, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xd5f7c00, rs=0x43004d00, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xd5f7c00, rs=0x43004d00) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xd5f7c00, rs=0x43004d00) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xd5f7c00, rs=0x43004d00) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x43004de0, arg_v=0xd5f7c00) at connection.c:1133 #11 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #12 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 1132489024 (LWP 1168))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xd5f7900, rs=0x43805ca0) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xd5f7900, rs=0x43805ca0, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xd5f7900, rs=0x43805ca0, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xd5f7900, rs=0x43805ca0) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xd5f7900, rs=0x43805ca0) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xd5f7900, rs=0x43805ca0) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x43805de0, arg_v=0xd5f7900) at connection.c:1133 #11 0x000000000042c7b0 in connection_read_thread (ctx=0x43805de0, argv=0x1d) at connection.c:1261 #12 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #13 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #14 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 1140881728 (LWP 1431))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xd955c00, rs=0x44006d00) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xd955c00, rs=0x44006d00, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xd955c00, rs=0x44006d00, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xd955c00, rs=0x44006d00) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xd955c00, rs=0x44006d00) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xd955c00, rs=0x44006d00) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x44006de0, arg_v=0xd955c00) at connection.c:1133 #11 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #12 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 1149274432 (LWP 1432))]#0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaad1685e in ldap_pvt_thread_mutex_lock (mutex=0x7f7fa58) at thr_posix.c:333 #4 0x00002aaaae660500 in accesslog_op_mod (op=0xd955900, rs=0x44807ca0) at accesslog.c:1236 #5 0x00000000004a0cfe in overlay_op_walk (op=0xd955900, rs=0x44807ca0, which=op_delete, oi=0x7f86c40, on=0x7f868c0) at backover.c:640 #6 0x00000000004a0f90 in over_op_func (op=0xd955900, rs=0x44807ca0, which=op_delete) at backover.c:702 #7 0x00000000004a10da in over_op_delete (op=0xd955900, rs=0x44807ca0) at backover.c:754 #8 0x000000000044c4f9 in fe_op_delete (op=0xd955900, rs=0x44807ca0) at delete.c:179 #9 0x000000000044c126 in do_delete (op=0xd955900, rs=0x44807ca0) at delete.c:91 #10 0x000000000042c2da in connection_operation (ctx=0x44807de0, arg_v=0xd955900) at connection.c:1133 #11 0x000000000042c7b0 in connection_read_thread (ctx=0x44807de0, argv=0x1e) at connection.c:1261 #12 0x00002aaaaad154ba in ldap_int_thread_pool_wrapper (xpool=0x7c0ff00) at tpool.c:478 #13 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #14 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 46912515736208 (LWP 15700))]#0 0x00000038dcc074e5 in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc074e5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002aaaaad16767 in ldap_pvt_thread_join (thread=1082132800, thread_return=0x0) at thr_posix.c:193 #2 0x0000000000429bd3 in slapd_daemon () at daemon.c:2579 #3 0x0000000000412113 in main (argc=10, argv=0x7fffd07d4fe8) at main.c:859 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5257) test008 hanging in bdb
by hyc＠symas.com 05 Dec '07

05 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Hah. thr_debug found it (at least I presume it's the same bug) after 70 > iterations over test008. > > Compiled with > CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_REL_ENG' CFLAGS='-O0 -g' > run with export LDAP_THREAD_DEBUG=nocount > > backtrace and testrun directory: > http://folk.uio.no/hbf/test008bug-071204.tbz > > slapd.1.log ends with: > > ====> bdb_cache_delete( 146 ) > thr_debug.c:1024: ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex ) > > The mutex owner is ldap_debug_thread_none, i.e. the mutex is not locked. > > It's cache.c:874:bdb_cache_entryinfo_unlock( *eip ); in bdb_cache_find_id(). > #3 0x00000000004e1df9 in bdb_cache_find_id (op=0x1ebb46a0, tid=0x0, id=4, eip=0x45809ad0, flag=1, locker=38, > lock=0x45809b20) at cache.c:874 > Need to see the full stack trace. Obviously "this should never happen" ... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5257) test008 hanging in bdb
by h.b.furuseth＠usit.uio.no 05 Dec '07

05 Dec '07

Hah. thr_debug found it (at least I presume it's the same bug) after 70 iterations over test008. Compiled with CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_REL_ENG' CFLAGS='-O0 -g' run with export LDAP_THREAD_DEBUG=nocount backtrace and testrun directory: http://folk.uio.no/hbf/test008bug-071204.tbz slapd.1.log ends with: ====> bdb_cache_delete( 146 ) thr_debug.c:1024: ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex ) The mutex owner is ldap_debug_thread_none, i.e. the mutex is not locked. It's cache.c:874:bdb_cache_entryinfo_unlock( *eip ); in bdb_cache_find_id(). #3 0x00000000004e1df9 in bdb_cache_find_id (op=0x1ebb46a0, tid=0x0, id=4, eip=0x45809ad0, flag=1, locker=38, lock=0x45809b20) at cache.c:874 I had to patch thr_posix.c a bit to detect Linux NPTL threads: diff -u -2 -r1.50 thr_posix.c --- thr_posix.c 25 Oct 2007 04:42:40 -0000 1.50 +++ thr_posix.c 4 Dec 2007 23:06:29 -0000 @@ -45,6 +45,6 @@ #ifdef LDAP_THREAD_DEBUG # if defined LDAP_INT_THREAD_MUTEXATTR /* May be defined in CPPFLAGS */ -# elif defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP - /* LinuxThreads hack */ +# elif 1 || defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP + /* LinuxThreads and NPTL hack */ # define LDAP_INT_THREAD_MUTEXATTR PTHREAD_MUTEX_ERRORCHECK_NP # else (BTW, I tried to put it in ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-071203.tbz but got disk full.) -- Hallvard

1 0

(ITS#5260) delta-syncrepl infinite loop
by quanah＠zimbra.com 04 Dec '07

04 Dec '07

Full_Name: Quanah Gibson-Mount Version: 2.3.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.21.80.71) If the sync cookie is stale between a replica and the master, and the accesslog DB is emtpy, delta sync starts slamming the master with search requests: Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19290 SEARCH RESULT tag=101 err=0 nentries=0 text= Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19291 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19291 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19291 SEARCH RESULT tag=101 err=4096 nentries=0 text=sync cookie is stale Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19292 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19292 SRCH attr=* + Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19292 SEARCH RESULT tag=101 err=0 nentries=0 text= Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19293 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19293 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19293 SEARCH RESULT tag=101 err=4096 nentries=0 text=sync cookie is stale Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19294 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Dec 4 13:43:33 freelancer slapd[30805]: conn=3 op=19294 SRCH attr=* + (as you can see, nearly 20,000 ops in just a few seconds)

1 0

(ITS#5259) SIGSEGV in slap_auxprop_store during SASL/OTP bind
by dwhite＠olp.net 04 Dec '07

04 Dec '07

Full_Name: Dan White Version: 2.3.39 OS: Linux URL: http://support.olp.net/ldap/log.txt Submission from: (NULL) (65.161.252.42) I'm experiencing crashes in slapd when attempting to bind via SASL using the OTP mech. I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). I'm using the bdb backend. I'm also using Debian Etch with the following versions of software: Cyrus SASL 2.1.22(.dfsg1-8) libdb 4.2.52(+dfsg-2) libc6 2.3.6(.ds1-13etch2) I've compiled cyrus sasl to use it's internal implementation of OTP, rather than OPIE: --enable-otp (--with-opie is not enabled) The problem I'm experiencing isn't when I successfully authenticate; that seems to work fine. It's when I run an ldapsearch, but instead of entering an OTP password, I press ctrl-c to cancel the search. >From the shell, when I perform an LDAP search, all appears normal: hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net SASL/OTP authentication started Challenge: otp-md5 497 hi3182 ext Please enter your one-time password:<ctrl-c> hiro:~# However my slapd process dies. Here's a gdb backtrace of the server process: ... Core was generated by `/usr/sbin/slapd'. Program terminated with signal 11, Segmentation fault. #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 478 op.o_hdr = conn->c_sasl_bindop->o_hdr; (gdb) bt #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 #1 0xb7eb17d7 in sasl_auxprop_store () from /usr/lib/libsasl2.so.2 #2 0xb7973c89 in otp_server_plug_init () from /usr/lib/sasl2/libotp.so.2 #3 0xb7ebde36 in sasl_server_new () from /usr/lib/libsasl2.so.2 #4 0xb7eb6194 in sasl_dispose () from /usr/lib/libsasl2.so.2 #5 0x080b2992 in slap_sasl_close (conn=0xb7ec3618) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:1331 #6 0x0806cf27 in connection_close (c=0xb75b1148) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:715 #7 0x0806e116 in connection_read (s=12) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:1458 #8 0x0806a49f in slapd_daemon_task (ptr=0x0) at /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/daemon.c:2468 #9 0xb7cd3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7c674ae in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) quit I've added a debug statement within slap_auxprop_store, so the openldap debug information below will include some additional information about what's being modified. The output can be obtained from: http://support.olp.net/ldap/log.txt Notice the two lines: Dec 3 13:39:06 hiro slapd[11134]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5935^I0e81b33e30182715^I00000000001196711046. Dec 3 13:39:07 hiro slapd[11134]: slap_auxprop_store [conn=-1]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5935^I0e81b33e30182715^I00000000000000000000. If I enter a good OTP password, I get this in my logs: Dec 3 13:43:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0499^Ihi5865^Iec8123986aec6550^I00000000001196711306. Dec 3 13:44:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. If I enter an incorrect password, I get this: Dec 3 13:45:21 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000001196711421. Dec 3 13:45:22 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to set cmusaslsecretOTP to md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. So in the case where it's crashing, it appears the Cyrus SASL is attempting to revert the OTP entry back to the previous version to "unlock" it. I assume that the connection id of '-1' is relevant to the crash. You should be able to reproduce this error with the following steps: Compile SASL with OTP, but without OPIE Configure a dummy SASL service configuration file to be used with saslpasswd2 below, e.g.: hiro:~# cat > /usr/lib/sasl2/test.conf <<EOF > auxprop_plugin: ldapdb > ldapdb_uri: ldapi:/// > ldapdb_mech: EXTERNAL > EOF hiro:~# Create a schema including an attribute of cmusaslsecretOTP, and create an entry in the directory which can use this attribute. Configure slapd.conf with the appropriate sasl configuration to convert both the shell (root) user (connecting via ldapi:///) and the user specified in the ldapsearch, for example: sasl-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" cn=admin,dc=olp,dc=net sasl-regexp "uid=([^,]+),cn=otp,cn=auth" ldap:///ou=people,dc=olp,dc=net??one?(btcAltUid=$1) Issue a saslpasswd2 to initialize the cmusaslsecretOTP attribute for the user: hiro:~# saslpasswd2 -a test -n abrown(a)olp.net Password: Again (for verification): The cmusaslsecretOTP attribute should look something like: md5 0499 hi8351 1c19abc81f35dc63 00000000000000000000 opiekey can be used to convert the OTP challenge into the appropriate response. For instance: hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net SASL/OTP authentication started Challenge: otp-md5 498 hi8351 ext Please enter your one-time password: Using opiekey to obtain response: dwhite@zek:~$ opiekey -5 -x 498 hi8351 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: 556A 99B3 52FA CEB1 Feed the result back into ldapsearch for a successful bind. To reproduce the bug, of course just kill the ldapsearch before entering any response.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs