- openldap-bugs - openldap.org

(ITS#7159) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

Full_Name: Timo Teräs Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.235.194) The back-sql crashes on startup with following backtrace: #0 0x0000045655d11efc in config_generic_wrapper () #1 0x0000045655d1187e in read_config_file () #2 0x0000045655d08fb6 in read_config () #3 0x0000045655cffc15 in main () This is because the be_cf_ocs is not initialized properly.

1 0

(ITS#7158) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

Full_Name: Timo Teräs Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.235.194) The back-sql crashes on startup with following backtrace: #0 0x0000045655d11efc in config_generic_wrapper () #1 0x0000045655d1187e in read_config_file () #2 0x0000045655d08fb6 in read_config () #3 0x0000045655cffc15 in main () This is because the be_cf_ocs is not initialized properly.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by quanah＠zimbra.com 07 Feb '12

07 Feb '12

--On Tuesday, February 07, 2012 9:03 PM +0000 alfiej(a)opera.com wrote: > Full_Name: Alfie John > Version: 2.4.23 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.245.36.226) > > > When searching for Chinese names in the "to:" field under Thunderbird, I > see asserted_value_validate_normalize() not returning LDAP_SUCCESS in > filter.c. This is because the "mail" attribute in core.schema is of type > "IA5 String" but the Chinese name falls outside the character set. > > The work around I have is to modify the "mail" attributetype in the > core.schema from: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > to: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > Dieter Kl?nter pointed out on the openldap-technical mailing list that > this breaks RFC-5322. However Charles T. Brooks suggests: > > Non-english character sets are going to become part of > hostnames and DNS. That's inevitable. > > Mail addresses are based on DNS hostnames. > > Ergo, mail attributes will one day need to support all possible > characters. > > Given that, I think the above changes to core.schema seem worthwhile. I would say then, that the proper place to bring this up would be with the IETF. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7157) UTF-8 support for "mail" attribute
by alfiej＠opera.com 07 Feb '12

07 Feb '12

Full_Name: Alfie John Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.245.36.226) When searching for Chinese names in the "to:" field under Thunderbird, I see asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This is because the "mail" attribute in core.schema is of type "IA5 String" but the Chinese name falls outside the character set. The work around I have is to modify the "mail" attributetype in the core.schema from: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) to: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) Dieter Klünter pointed out on the openldap-technical mailing list that this breaks RFC-5322. However Charles T. Brooks suggests: Non-english character sets are going to become part of hostnames and DNS. That's inevitable. Mail addresses are based on DNS hostnames. Ergo, mail attributes will one day need to support all possible characters. Given that, I think the above changes to core.schema seem worthwhile.

1 0

Re: (ITS#7156) definement missing in ldapsearch.c
by h.b.furuseth＠usit.uio.no 07 Feb '12

07 Feb '12

On Tue, 7 Feb 2012 12:19:04 GMT, Kick.Tobias(a)web.de wrote: > It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H > is missing like this: > > #ifdef HAVE_SYS_TIME_H > #include <sys/time.h> > #endif Fixed in master: Added #include <ac/time.h> which does the above. Please test. -- Hallvard

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > On Tue, 07 Feb 2012 14:36:22 +0100, Michael Ströder wrote: >> Raphaël Ouazana-Sustowski wrote: >>> Wouldn't it be possible to have a more generic solution, eg: while each >>> configuration change, OpenLDAP tests that configuration is still valid. >> >> While checking the configuration data itself seems feasible it does >> not scale well to check all entries whether they still contain a >> certain schema element. > > Again I was talking about a more generic case. ??? > For the specific case of schema modification, I don't think that OpenLDAP > doesn't start if some entries are missing some schema elements. Schema and all entries have to be consistent. Periodically checking with slapschema whether everything's still alright is a good idea. > My point is only that OpenLDAP should not bring the administrator to > a situation where he cannot restart the service. Nothing prevents an admin to do rm -rf /var/openldap/databases so to some degree an admin has to know what he does. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > Wouldn't it be possible to have a more generic solution, eg: while each > configuration change, OpenLDAP tests that configuration is still valid. While checking the configuration data itself seems feasible it does not scale well to check all entries whether they still contain a certain schema element. Also if you use slapo-accesslog and it contains removed attributes in attributes redMod or reqOld you cannot fully restore the accesslog DB with slapadd. So using OBSOLETE is best practice. Experimental things you do in your test environment without asking for support is completely up to you. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

raphael.ouazana(a)linagora.com wrote: > This is a little bit like shooting himself in the foot: > a/ Create a new attribute with back-config > b/ Create a second new attribute which inherits from the first one with > back-config > c/ Remove the first attribute with back-config > d/ OpenLDAP does not complain. But when you restart the server, you get an error > message. It boils down to that back-config should not allow to remove schema elements which are somewhere used. In this context "used" means 1. referenced in another schema element or 2. used in an entry in one of the database backends. While 1. could be easily checked by slapd thinking about 2. leads to the conclusion that schema elements should not be removable at all. There's a possibility to mark schema elements as OBSOLETE. This is what I consider best practice. Also it still keeps the old OID reserved. (My web2ldap displays OBSOLETE schema elements as struck out in the schema viewer so one can easily notice whether there are OBSOLETE attribute types referenced e.g. in an active object class.) Ciao, Michael.

1 0

(ITS#7156) definement missing in ldapsearch.c
by Kick.Tobias＠web.de 07 Feb '12

07 Feb '12

Full_Name: Tobias Kick Version: 2.4.28 OS: MinGW URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.16.0.17) When configured in portable.h #define HAVE_SYS_TIME_H 1 the compiler brings the error: make[2]: Entering directory `/mingw64/tmp/openldap-2.4.28/clients/tools' ../../build/mkversion -v "2.4.28" -s ldapsearch > ldsversion.c gcc -g -O2 -I../../include -I../../include -c -o ldapsearch.o ldapsearch.c ldapsearch.c: In function 'dosearch': ldapsearch.c:1379:17: error: storage size of 'tv' isn't known ldapsearch.c:1380:17: error: storage size of 'tv_timelimit' isn't known make[2]: *** [ldapsearch.o] Error 1 make[2]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients/tools' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients' make: *** [all-common] Error 1 It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H is missing like this: #ifdef HAVE_SYS_TIME_H #include <sys/time.h> #endif

1 0

(ITS#7153) OpenLDAP doesn't start after some configuration modifications
by raphael.ouazana＠linagora.com 07 Feb '12

07 Feb '12

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, This is a little bit like shooting himself in the foot: a/ Create a new attribute with back-config b/ Create a second new attribute which inherits from the first one with back-config c/ Remove the first attribute with back-config d/ OpenLDAP does not complain. But when you restart the server, you get an error message. More problematically, you cannot modify the configuration anymore, because slapcating the configuration to edit it gives you the same error message: $ sbin/slapcat -F etc/openldap/slapd.d -n0 olcAttributeTypes: value #0 olcAttributeTypes: AttributeType not found: "xxx" config error processing cn={22}yyy,cn=schema,cn=config: olcAttributeTypes: AttributeType not found: "xxx" slapcat: bad configuration directory!

1 0

RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 06 Feb '12

06 Feb '12

Now the new patch encode the binary data to base64 by using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the encode. *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100 *************** *** 16,21 **** --- 16,22 ---- */ #include "perl_back.h" + #include "lutil.h" int perl_back_modify( *************** *** 26,31 **** --- 27,33 ---- Modifications *modlist = op->orm_modlist; int count; int i; + struct berval b64_data; PERL_SET_CONTEXT( PERL_INTERPRETER ); ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex ); *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 63,80 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mods->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mods->sm_values[i].bv_val, ! mods->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0 ))); ! ber_memfree( b64_data.bv_val ); ! } else { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); ! } } /* Fix delete attrib without value. */ *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100 *************** *** 37,42 **** --- 37,43 ---- #include "slap.h" #include "shell.h" + #include "lutil.h" int shell_back_modify( *************** *** 50,55 **** --- 51,57 ---- Entry e; FILE *rfp, *wfp; int i; + struct berval b64_data; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 107,126 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mod->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mod->sm_values[i].bv_val, ! mod->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! b64_data.bv_val ); ! ber_memfree( b64_data.bv_val ); ! } else { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val ); ! } } } ________________________________________ De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de hyc(a)symas.com [hyc(a)symas.com] Date d'envoi : jeudi 2 février 2012 21:44 À : openldap-its(a)openldap.org Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data llg(a)portaildulibre.fr wrote: > Le 02/02/2012 20:32, hyc(a)symas.com a écrit : >> jiashun.qian(a)atos.net wrote: >>> Full_Name: Jiashun QIAN >>> Version: 2.4.28 >>> OS: CentOS 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.115.60.180) >>> >>> >>> The backend shell and the backend perl can't handle some binary data. >>> >>> This occurs only with MODIFY because when ADD the binary data is encoded in >>> base64 but not MODIFY. >>> >>> The binary data is truncated when if it contains \0. In fact, data is stored in >>> a linked list of char * and treated as characters. >>> >>> --- >>> servers/slapd/back-perl/modify.c >>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>> --- >>> >>> The type of mods->sm_values[i].bv_val is char*. >>> >>> To handle the binary data, for back-perl, just change another function mXPUSHp, >>> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >>> it's mod->sm_values[i].bv_len. So it will push the total data. >> That is obviously the wrong approach. Since these backends communicate using >> LDIF, binary values should be base64 encoded according to the LDIF rules. > The input LDIF file for ldap_modify contains base64 encoded > usercertificate, but back-perl receives binary data. > This behaviour only occured with modification action : with add action, > certificate is received base64 encoded. Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. >> Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

1 0

Re: (ITS#7152) Add -o option to ldap*.1 man pages
by fumiyas＠osstech.jp 04 Feb '12

04 Feb '12

At Sat, 4 Feb 2012 15:29:35 GMT > URL: 'http://home.samba.gr.jp/~fumiyas/openldap/openldap-2.4.28-man1-add-o -option.patch http://home.samba.gr.jp/~fumiyas/openldap/openldap-2.4.28-man1-add-o-option… is correct. Sorry. > OpenLDAP ldap*(1) tools have the -o option, but no description about it > in its manpages.

1 0

(ITS#7152) Add -o option to ldap*.1 man pages
by fumiyas＠osstech.co.jp 04 Feb '12

04 Feb '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: 'http://home.samba.gr.jp/~fumiyas/openldap/openldap-2.4.28-man1-add-o -option.patch Submission from: (NULL) (220.100.28.128) OpenLDAP ldap*(1) tools have the -o option, but no description about it in its manpages.

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

------------jL0Q7OrKgMl1NhGUUvXpqG Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu <hyc(a)symas.com> wrote: > mattias(a)centaurix.com wrote: >> On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson >> <mattias(a)centaurix.com> wrote: >> >>> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I >>> downloaded >>> the current source from RE24 (snapshot), but I'm still getting the >>> error >>> that I reported initially: >> >> I can confirm that the source does indeed include the patch, so the >> patch >> did not fix the problem. > > OK, we need to know exactly what the difference is between the > ldapsearch query and the browser query. Can you please run slapd -d7 and > record first the ldapsearch query and then the browser query and post > the output for each of those? Attached the output from the two queries. Mattias ------------jL0Q7OrKgMl1NhGUUvXpqG Content-Disposition: attachment; filename=slapd-ldapsearch.log Content-Type: application/octet-stream; name="slapd-ldapsearch.log" Content-Transfer-Encoding: Base64 NGYyYzg5Zjggc2xhcGQgc3RhcnR1cDogaW5pdGlhdGVkLg0KNGYyYzg5ZjggYmFj a2VuZF9zdGFydHVwX29uZTogc3RhcnRpbmcgImNuPWNvbmZpZyINCjRmMmM4OWY4 IGNvbmZpZ19iYWNrX2RiX29wZW4NCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRy eTogImNuPWNvbmZpZyINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNu PW1vZHVsZXswfSINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXNj aGVtYSINCjRmMmM4OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNuPXswfWNvcmU+DQo0 ZjJjODlmOCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17MH1jb3JlPg0KNGYyYzg5Zjgg Y29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezB9Y29yZSINCjRmMmM4OWY4ID4+PiBk bk5vcm1hbGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4OWY4IDw8PCBkbk5vcm1h bGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRy eTogImNuPXsxfWNvc2luZSINCjRmMmM4OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNu PXsyfW5pcz4NCjRmMmM4OWY4IDw8PCBkbk5vcm1hbGl6ZTogPGNuPXsyfW5pcz4N CjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXsyfW5pcyINCjRmMmM4 OWY4ID4+PiBkbk5vcm1hbGl6ZTogPGNuPXszfWluZXRvcmdwZXJzb24+DQo0ZjJj ODlmOCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17M31pbmV0b3JncGVyc29uPg0KNGYy Yzg5ZjggY29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezN9aW5ldG9yZ3BlcnNvbiIN CjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFiYXNlPXstMX1m cm9udGVuZCINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFi YXNlPXswfWNvbmZpZyINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTogIm9s Y0RhdGFiYXNlPXsxfWhkYiINCjRmMmM4OWY4IGNvbmZpZ19idWlsZF9lbnRyeTog Im9sY0RhdGFiYXNlPXsyfXJlbGF5Ig0KNGYyYzg5ZjggY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17MH1yd20iDQo0ZjJjODlmOCBjb25maWdfYnVpbGRf ZW50cnk6ICJvbGNPdmVybGF5PXsxfXRyYW5zbHVjZW50Ig0KNGYyYzg5ZjggPT0+ IHRyYW5zbHVjZW50X2NmYWRkDQo0ZjJjODlmOCBjb25maWdfYnVpbGRfZW50cnk6 ICJvbGNEYXRhYmFzZT17MH1sZGFwIg0KNGYyYzg5ZjggY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17Mn1nbHVlIg0KNGYyYzg5ZjggYmFja2VuZF9zdGFy dHVwX29uZTogc3RhcnRpbmcgImRjPXJzcyxkYz1jaGFsbWVycyxkYz1zZSINCjRm MmM4OWY4IGhkYl9kYl9vcGVuOiAiZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlIg0K NGYyYzg5ZjggaGRiX2RiX29wZW46IGRhdGFiYXNlICJkYz1yc3MsZGM9Y2hhbG1l cnMsZGM9c2UiOiBkYmVudl9vcGVuKC92YXIvbGliL2xkYXApLg0KNGYyYzg5Zjgg aGRiX21vbml0b3JfZGJfb3BlbjogbW9uaXRvcmluZyBkaXNhYmxlZDsgY29uZmln dXJlIG1vbml0b3IgZGF0YWJhc2UgdG8gZW5hYmxlDQo0ZjJjODlmOCBiYWNrZW5k X3N0YXJ0dXBfb25lOiBzdGFydGluZyAiZGM9Y2hhbG1lcnMsZGM9c2UiDQo0ZjJj ODlmOCA9PT4gdHJhbnNsdWNlbnRfZGJfb3Blbg0KNGYyYzg5ZjggYmFja2VuZF9z dGFydHVwX29uZTogc3RhcnRpbmcgImRjPWNoYWxtZXJzLGRjPXNlIg0KNGYyYzg5 ZjggbGRhcF9iYWNrX2RiX29wZW46IFVSST1sZGFwOi8vbGRhcC5jaGFsbWVycy5z ZQ0KNGYyYzg5Zjggc2xhcGQgc3RhcnRpbmcNCjRmMmM4OWZlIHNsYXBfbGlzdGVu ZXJfYWN0aXZhdGUoNyk6IA0KNGYyYzg5ZmUgPj4+IHNsYXBfbGlzdGVuZXIobGRh cDovLy8pDQo0ZjJjODlmZSBjb25uZWN0aW9uX2dldCgxMikNCjRmMmM4OWZlIGNv bm5lY3Rpb25fZ2V0KDEyKTogZ290IGNvbm5pZD0xMDAwDQo0ZjJjODlmZSBjb25u ZWN0aW9uX3JlYWQoMTIpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9MTAwMA0K YmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDog IDMwIDBjIDAyIDAxIDAxIDYwIDA3IDAyICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAuLi4uYC4uICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTYsIGdvdD02 DQogIDAwMDA6ICAwMSAwMyAwNCAwMCA4MCAwMCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAuLi4uLi4gICAgICAgICAgICANCmJlcl9nZXRfbmV4dDog dGFnIDB4MzAgbGVuIDEyIGNvbnRlbnRzOg0KNGYyYzg5ZmUgb3AgdGFnIDB4NjAs IHRpbWUgMTMyODMxODk3NA0KYmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9 OCBlcnJvcj1SZXNvdXJjZSB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZQ0KNGYyYzg5 ZmUgY29ubj0xMDAwIG9wPTAgZG9fYmluZA0KYmVyX3NjYW5mIGZtdCAoe2ltdCkg YmVyOg0KYmVyX3NjYW5mIGZtdCAobX0pIGJlcjoNCjRmMmM4OWZlID4+PiBkblBy ZXR0eU5vcm1hbDogPD4NCjRmMmM4OWZlIDw8PCBkblByZXR0eU5vcm1hbDogPD4s IDw+DQo0ZjJjODlmZSBkb19iaW5kOiB2ZXJzaW9uPTMgZG49IiIgbWV0aG9kPTEy OA0KNGYyYzg5ZmUgc2VuZF9sZGFwX3Jlc3VsdDogY29ubj0xMDAwIG9wPTAgcD0z DQo0ZjJjODlmZSBzZW5kX2xkYXBfcmVzdWx0OiBlcnI9MCBtYXRjaGVkPSIiIHRl eHQ9IiINCjRmMmM4OWZlIHNlbmRfbGRhcF9yZXNwb25zZTogbXNnaWQ9MSB0YWc9 OTcgZXJyPTANCmJlcl9mbHVzaDI6IDE0IGJ5dGVzIHRvIHNkIDEyDQpsZGFwX3dy aXRlOiB3YW50PTE0LCB3cml0dGVuPTE0DQogIDAwMDA6ICAzMCAwYyAwMiAwMSAw MSA2MSAwNyAwYSAgMDEgMDAgMDQgMDAgMDQgMDAgICAgICAgICAwLi4uLmEuLi4u Li4uLiAgICANCjRmMmM4OWZlIGRvX2JpbmQ6IHYzIGFub255bW91cyBiaW5kDQo0 ZjJjODlmZSBjb25uZWN0aW9uX2dldCgxMikNCjRmMmM4OWZlIGNvbm5lY3Rpb25f Z2V0KDEyKTogZ290IGNvbm5pZD0xMDAwDQo0ZjJjODlmZSBjb25uZWN0aW9uX3Jl YWQoMTIpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9MTAwMA0KYmVyX2dldF9u ZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMwIDNiIDAy IDAxIDAyIDYzIDM2IDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDA7Li4u YzYuICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTUzLCBnb3Q9NTMNCiAgMDAw MDogIDExIDY0IDYzIDNkIDYzIDY4IDYxIDZjICA2ZCA2NSA3MiA3MyAyYyA2NCA2 MyAzZCAgIC5kYz1jaGFsbWVycyxkYz0gIA0KICAwMDEwOiAgNzMgNjUgMGEgMDEg MDAgMGEgMDEgMDAgIDAyIDAxIDAwIDAyIDAxIDAwIDAxIDAxICAgc2UuLi4uLi4u Li4uLi4uLiAgDQogIDAwMjA6ICAwMCA4NyAwYiA2ZiA2MiA2YSA2NSA2MyAgNzQg NDMgNmMgNjEgNzMgNzMgMzAgMDUgICAuLi5vYmplY3RDbGFzczAuICANCiAgMDAz MDogIDA0IDAzIDMxIDJlIDMxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4uMS4xICAgICAgICAgICAgIA0KYmVyX2dldF9uZXh0OiB0YWcgMHgz MCBsZW4gNTkgY29udGVudHM6DQo0ZjJjODlmZSBvcCB0YWcgMHg2MywgdGltZSAx MzI4MzE4OTc0DQpiZXJfZ2V0X25leHQNCmxkYXBfcmVhZDogd2FudD04IGVycm9y PVJlc291cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQo0ZjJjODlmZSBjb25u PTEwMDAgb3A9MSBkb19zZWFyY2gNCmJlcl9zY2FuZiBmbXQgKHttaWlpaWIpIGJl cjoNCjRmMmM4OWZlID4+PiBkblByZXR0eU5vcm1hbDogPGRjPWNoYWxtZXJzLGRj PXNlPg0KPT4gbGRhcF9idjJkbihkYz1jaGFsbWVycyxkYz1zZSwwKQ0KPD0gbGRh cF9idjJkbihkYz1jaGFsbWVycyxkYz1zZSk9MCANCj0+IGxkYXBfZG4yYnYoMjcy KQ0KPD0gbGRhcF9kbjJidihkYz1jaGFsbWVycyxkYz1zZSk9MCANCj0+IGxkYXBf ZG4yYnYoMjcyKQ0KPD0gbGRhcF9kbjJidihkYz1jaGFsbWVycyxkYz1zZSk9MCAN CjRmMmM4OWZlIDw8PCBkblByZXR0eU5vcm1hbDogPGRjPWNoYWxtZXJzLGRjPXNl PiwgPGRjPWNoYWxtZXJzLGRjPXNlPg0KNGYyYzg5ZmUgU1JDSCAiZGM9Y2hhbG1l cnMsZGM9c2UiIDAgMDRmMmM4OWZlICAgICAwIDAgMA0KYmVyX3NjYW5mIGZtdCAo bSkgYmVyOg0KNGYyYzg5ZmUgICAgIGZpbHRlcjogKG9iamVjdENsYXNzPSopDQpi ZXJfc2NhbmYgZm10ICh7TX19KSBiZXI6DQo0ZjJjODlmZSAgICAgYXR0cnM6NGYy Yzg5ZmUgIDEuMTRmMmM4OWZlIA0KNGYyYzg5ZmUgPT0+IGxpbWl0c19nZXQ6IGNv bm49MTAwMCBvcD0xIHNlbGY9Ilthbm9ueW1vdXNdIiB0aGlzPSJkYz1jaGFsbWVy cyxkYz1zZSINCjRmMmM4OWZlID09PiB0cmFuc2x1Y2VudF9zZWFyY2g6IDxkYz1j aGFsbWVycyxkYz1zZT4gKG9iamVjdENsYXNzPSopDQpsZGFwX2NyZWF0ZQ0KbGRh cF91cmxfcGFyc2VfZXh0KGxkYXA6Ly9sZGFwLmNoYWxtZXJzLnNlKQ0KNGYyYzg5 ZmUgPT5sZGFwX2JhY2tfZ2V0Y29ubjogY29ubj0xMDAwIG9wPTE6IGxjPTB4Mjky N2ZiMCBpbnNlcnRlZCByZWZjbnQ9MSByYz0wDQpsZGFwX3Nhc2xfYmluZA0KbGRh cF9zZW5kX2luaXRpYWxfcmVxdWVzdA0KbGRhcF9uZXdfY29ubmVjdGlvbiAxIDEg MA0KbGRhcF9pbnRfb3Blbl9jb25uZWN0aW9uDQpsZGFwX2Nvbm5lY3RfdG9faG9z dDogVENQIGxkYXAuY2hhbG1lcnMuc2U6Mzg5DQpsZGFwX25ld19zb2NrZXQ6IDEz DQpsZGFwX3ByZXBhcmVfc29ja2V0OiAxMw0KbGRhcF9jb25uZWN0X3RvX2hvc3Q6 IFRyeWluZyAxMjkuMTYuMjIxLjQ6Mzg5DQpsZGFwX3B2dF9jb25uZWN0OiBmZDog MTMgdG06IC0xIGFzeW5jOiAwDQpsZGFwX29wZW5fZGVmY29ubjogc3VjY2Vzc2Z1 bA0KbGRhcF9zZW5kX3NlcnZlcl9yZXF1ZXN0DQpiZXJfc2NhbmYgZm10ICh7aXQp IGJlcjoNCmJlcl9zY2FuZiBmbXQgKHtpKSBiZXI6DQpiZXJfZmx1c2gyOiAxNCBi eXRlcyB0byBzZCAxMw0KbGRhcF93cml0ZTogd2FudD0xNCwgd3JpdHRlbj0xNA0K ICAwMDAwOiAgMzAgMGMgMDIgMDEgMDEgNjAgMDcgMDIgIDAxIDAzIDA0IDAwIDgw IDAwICAgICAgICAgMC4uLi5gLi4uLi4uLi4gICAgDQpsZGFwX3Jlc3VsdCBsZCAw eDI5MjgwMzAgbXNnaWQgMQ0Kd2FpdDRtc2cgbGQgMHgyOTI4MDMwIG1zZ2lkIDEg KHRpbWVvdXQgMTAwMDAwIHVzZWMpDQp3YWl0NG1zZyBjb250aW51ZSBsZCAweDI5 MjgwMzAgbXNnaWQgMSBhbGwgMQ0KKiogbGQgMHgyOTI4MDMwIENvbm5lY3Rpb25z Og0KKiBob3N0OiBsZGFwLmNoYWxtZXJzLnNlICBwb3J0OiAzODkgIChkZWZhdWx0 KQ0KICByZWZjbnQ6IDIgIHN0YXR1czogQ29ubmVjdGVkDQogIGxhc3QgdXNlZDog U2F0IEZlYiAgNCAwMjoyOTozNCAyMDEyDQoNCg0KKiogbGQgMHgyOTI4MDMwIE91 dHN0YW5kaW5nIFJlcXVlc3RzOg0KICogbXNnaWQgMSwgIG9yaWdpZCAxLCBzdGF0 dXMgSW5Qcm9ncmVzcw0KICAgb3V0c3RhbmRpbmcgcmVmZXJyYWxzIDAsIHBhcmVu dCBjb3VudCAwDQogIGxkIDB4MjkyODAzMCByZXF1ZXN0IGNvdW50IDEgKGFiYW5k b25lZCAwKQ0KKiogbGQgMHgyOTI4MDMwIFJlc3BvbnNlIFF1ZXVlOg0KICAgRW1w dHkNCiAgbGQgMHgyOTI4MDMwIHJlc3BvbnNlIGNvdW50IDANCmxkYXBfY2hrUmVz cG9uc2VMaXN0IGxkIDB4MjkyODAzMCBtc2dpZCAxIGFsbCAxDQpsZGFwX2Noa1Jl c3BvbnNlTGlzdCByZXR1cm5zIGxkIDB4MjkyODAzMCBOVUxMDQpsZGFwX2ludF9z ZWxlY3QNCnJlYWQxbXNnOiBsZCAweDI5MjgwMzAgbXNnaWQgMSBhbGwgMQ0KYmVy X2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMw IDBjIDAyIDAxIDAxIDYxIDA3IDBhICAgICAgICAgICAgICAgICAgICAgICAgICAg IDAuLi4uYS4uICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTYsIGdvdD02DQog IDAwMDA6ICAwMSAwMCAwNCAwMCAwNCAwMCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAuLi4uLi4gICAgICAgICAgICANCmJlcl9nZXRfbmV4dDogdGFn IDB4MzAgbGVuIDEyIGNvbnRlbnRzOg0KcmVhZDFtc2c6IGxkIDB4MjkyODAzMCBt c2dpZCAxIG1lc3NhZ2UgdHlwZSBiaW5kDQpiZXJfc2NhbmYgZm10ICh7ZUFBKSBi ZXI6DQpyZWFkMW1zZzogbGQgMHgyOTI4MDMwIDAgbmV3IHJlZmVycmFscw0KcmVh ZDFtc2c6ICBtYXJrIHJlcXVlc3QgY29tcGxldGVkLCBsZCAweDI5MjgwMzAgbXNn aWQgMQ0KcmVxdWVzdCBkb25lOiBsZCAweDI5MjgwMzAgbXNnaWQgMQ0KcmVzX2Vy cm5vOiAwLCByZXNfZXJyb3I6IDw+LCByZXNfbWF0Y2hlZDogPD4NCmxkYXBfZnJl ZV9yZXF1ZXN0IChvcmlnaWQgMSwgbXNnaWQgMSkNCmxkYXBfcGFyc2VfcmVzdWx0 DQpiZXJfc2NhbmYgZm10ICh7aUFBKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh9KSBi ZXI6DQpsZGFwX21zZ2ZyZWUNCjRmMmM4OWZlID0+IGxkYXBfYmFja19tdW5nZV9m aWx0ZXIgIihvYmplY3RDbGFzcz0qKSINCjRmMmM4OWZlIDw9IGxkYXBfYmFja19t dW5nZV9maWx0ZXIgIihvYmplY3RDbGFzcz0qKSIgKDApDQpsZGFwX3NlYXJjaF9l eHQNCnB1dF9maWx0ZXI6ICIob2JqZWN0Q2xhc3M9KikiDQpwdXRfZmlsdGVyOiBz aW1wbGUNCnB1dF9zaW1wbGVfZmlsdGVyOiAib2JqZWN0Q2xhc3M9KiINCmxkYXBf YnVpbGRfc2VhcmNoX3JlcSBBVFRSUzogKiArDQpsZGFwX3NlbmRfaW5pdGlhbF9y ZXF1ZXN0DQpsZGFwX3NlbmRfc2VydmVyX3JlcXVlc3QNCmJlcl9zY2FuZiBmbXQg KHtpdCkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoeykgYmVyOg0KYmVyX2ZsdXNoMjog NjMgYnl0ZXMgdG8gc2QgMTMNCmxkYXBfd3JpdGU6IHdhbnQ9NjMsIHdyaXR0ZW49 NjMNCiAgMDAwMDogIDMwIDNkIDAyIDAxIDAyIDYzIDM4IDA0ICAxMSA2NCA2MyAz ZCA2MyA2OCA2MSA2YyAgIDA9Li4uYzguLmRjPWNoYWwgIA0KICAwMDEwOiAgNmQg NjUgNzIgNzMgMmMgNjQgNjMgM2QgIDczIDY1IDBhIDAxIDAwIDBhIDAxIDAwICAg bWVycyxkYz1zZS4uLi4uLiAgDQogIDAwMjA6ICAwMiAwMSAwMCAwMiAwMiAwZSAx MCAwMSAgMDEgMDAgODcgMGIgNmYgNjIgNmEgNjUgICAuLi4uLi4uLi4uLi5vYmpl ICANCiAgMDAzMDogIDYzIDc0IDQzIDZjIDYxIDczIDczIDMwICAwNiAwNCAwMSAy YSAwNCAwMSAyYiAgICAgIGN0Q2xhc3MwLi4uKi4uKyAgIA0KbGRhcF9yZXN1bHQg bGQgMHgyOTI4MDMwIG1zZ2lkIDINCndhaXQ0bXNnIGxkIDB4MjkyODAzMCBtc2dp ZCAyICh0aW1lb3V0IDEwMDAwMCB1c2VjKQ0Kd2FpdDRtc2cgY29udGludWUgbGQg MHgyOTI4MDMwIG1zZ2lkIDIgYWxsIDANCioqIGxkIDB4MjkyODAzMCBDb25uZWN0 aW9uczoNCiogaG9zdDogbGRhcC5jaGFsbWVycy5zZSAgcG9ydDogMzg5ICAoZGVm YXVsdCkNCiAgcmVmY250OiAyICBzdGF0dXM6IENvbm5lY3RlZA0KICBsYXN0IHVz ZWQ6IFNhdCBGZWIgIDQgMDI6Mjk6MzQgMjAxMg0KDQoNCioqIGxkIDB4MjkyODAz MCBPdXRzdGFuZGluZyBSZXF1ZXN0czoNCiAqIG1zZ2lkIDIsICBvcmlnaWQgMiwg c3RhdHVzIEluUHJvZ3Jlc3MNCiAgIG91dHN0YW5kaW5nIHJlZmVycmFscyAwLCBw YXJlbnQgY291bnQgMA0KICBsZCAweDI5MjgwMzAgcmVxdWVzdCBjb3VudCAxIChh YmFuZG9uZWQgMCkNCioqIGxkIDB4MjkyODAzMCBSZXNwb25zZSBRdWV1ZToNCiAg IEVtcHR5DQogIGxkIDB4MjkyODAzMCByZXNwb25zZSBjb3VudCAwDQpsZGFwX2No a1Jlc3BvbnNlTGlzdCBsZCAweDI5MjgwMzAgbXNnaWQgMiBhbGwgMA0KbGRhcF9j aGtSZXNwb25zZUxpc3QgcmV0dXJucyBsZCAweDI5MjgwMzAgTlVMTA0KbGRhcF9p bnRfc2VsZWN0DQpyZWFkMW1zZzogbGQgMHgyOTI4MDMwIG1zZ2lkIDIgYWxsIDAN CmJlcl9nZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTgsIGdvdD04DQogIDAwMDA6 ICAzMCA4MiAwMyA4OSAwMiAwMSAwMiA2NCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAwLi4uLi4uZCAgICAgICAgICANCmxkYXBfcmVhZDogd2FudD05MDEsIGdv dD05MDENCiAgMDAwMDogIDgyIDAzIDgyIDA0IDExIDY0IDYzIDNkICA2MyA2OCA2 MSA2YyA2ZCA2NSA3MiA3MyAgIC4uLi4uZGM9Y2hhbG1lcnMgIA0KICAwMDEwOiAg MmMgNjQgNjMgM2QgNzMgNjUgMzAgODIgIDAzIDZiIDMwIDUzIDA0IDBiIDZmIDYy ICAgLGRjPXNlMC4uazBTLi5vYiAgDQogIDAwMjA6ICA2YSA2NSA2MyA3NCA0MyA2 YyA2MSA3MyAgNzMgMzEgNDQgMDQgMDMgNzQgNmYgNzAgICBqZWN0Q2xhc3MxRC4u dG9wICANCiAgMDAzMDogIDA0IDBjIDZmIDcyIDY3IDYxIDZlIDY5ICA3YSA2MSA3 NCA2OSA2ZiA2ZSAwNCAwOCAgIC4ub3JnYW5pemF0aW9uLi4gIA0KICAwMDQwOiAg NjQgNjMgNGYgNjIgNmEgNjUgNjMgNzQgIDA0IDEzIDY0IDZmIDZkIDYxIDY5IDZl ICAgZGNPYmplY3QuLmRvbWFpbiAgDQogIDAwNTA6ICA1MiA2NSA2YyA2MSA3NCA2 NSA2NCA0ZiAgNjIgNmEgNjUgNjMgNzQgMDQgMTAgNmMgICBSZWxhdGVkT2JqZWN0 Li5sICANCiAgMDA2MDogIDYxIDYyIDY1IDZjIDY1IDY0IDU1IDUyICA0OSA0ZiA2 MiA2YSA2NSA2MyA3NCAzMCAgIGFiZWxlZFVSSU9iamVjdDAgIA0KICAwMDcwOiAg MzIgMDQgMGIgNjQgNjUgNzMgNjMgNzIgIDY5IDcwIDc0IDY5IDZmIDZlIDMxIDIz ICAgMi4uZGVzY3JpcHRpb24xIyAgDQogIDAwODA6ICAwNCAyMSA0MyA2OCA2MSA2 YyA2ZCA2NSAgNzIgNzMgMjAgNTUgNmUgNjkgNzYgNjUgICAuIUNoYWxtZXJzIFVu aXZlICANCiAgMDA5MDogIDcyIDczIDY5IDc0IDc5IDIwIDZmIDY2ICAyMCA1NCA2 NSA2MyA2OCA2ZSA2ZiA2YyAgIHJzaXR5IG9mIFRlY2hub2wgIA0KICAwMGEwOiAg NmYgNjcgNzkgMzAgNGYgMDQgMDEgNmYgIDMxIDRhIDA0IDA4IDQzIDY4IDYxIDZj ICAgb2d5ME8uLm8xSi4uQ2hhbCAgDQogIDAwYjA6ICA2ZCA2NSA3MiA3MyAwNCAx YiA0MyA2OCAgNjEgNmMgNmQgNjUgNzIgNzMgMjAgNTQgICBtZXJzLi5DaGFsbWVy cyBUICANCiAgMDBjMDogIDY1IDZiIDZlIDY5IDczIDZiIDYxIDIwICA0OCBjMyBi NiA2NyA3MyA2YiA2ZiA2YyAgIGVrbmlza2EgSC4uZ3Nrb2wgIA0KICAwMGQwOiAg NjEgMDQgMjEgNDMgNjggNjEgNmMgNmQgIDY1IDcyIDczIDIwIDU1IDZlIDY5IDc2 ICAgYS4hQ2hhbG1lcnMgVW5pdiAgDQogIDAwZTA6ICA2NSA3MiA3MyA2OSA3NCA3 OSAyMCA2ZiAgNjYgMjAgNTQgNjUgNjMgNjggNmUgNmYgICBlcnNpdHkgb2YgVGVj aG5vICANCiAgMDBmMDogIDZjIDZmIDY3IDc5IDMwIDE4IDA0IDAxICA2YyAzMSAx MyAwNCAxMSA0NyBjMyBiNiAgIGxvZ3kwLi4ubDEuLi5HLi4gIA0KICAwMTAwOiAg NzQgNjUgNjIgNmYgNzIgNjcgMmMgMjAgIDUzIDc3IDY1IDY0IDY1IDZlIDMwIDIx ICAgdGVib3JnLCBTd2VkZW4wISAgDQogIDAxMTA6ICAwNCAxMCA2MSA3MyA3MyA2 ZiA2MyA2OSAgNjEgNzQgNjUgNjQgNDQgNmYgNmQgNjEgICAuLmFzc29jaWF0ZWRE b21hICANCiAgMDEyMDogIDY5IDZlIDMxIDBkIDA0IDBiIDYzIDY4ICA2MSA2YyA2 ZCA2NSA3MiA3MyAyZSA3MyAgIGluMS4uLmNoYWxtZXJzLnMgIA0KICAwMTMwOiAg NjUgMzAgMjYgMDQgMGQgNzAgNmYgNzMgIDc0IDYxIDZjIDQxIDY0IDY0IDcyIDY1 ICAgZTAmLi5wb3N0YWxBZGRyZSAgDQogIDAxNDA6ICA3MyA3MyAzMSAxNSAwNCAx MyA1MyA0NSAgMmQgMzQgMzEgMzIgMjAgMzkgMzYgMjAgICBzczEuLi5TRS00MTIg OTYgICANCiAgMDE1MDogIDQ3IGMzIGI2IDc0IDY1IDYyIDZmIDcyICA2NyAzMCAy NSAwNCAwZiA3NCA2NSA2YyAgIEcuLnRlYm9yZzAlLi50ZWwgIA0KICAwMTYwOiAg NjUgNzAgNjggNmYgNmUgNjUgNGUgNzUgIDZkIDYyIDY1IDcyIDMxIDEyIDA0IDEw ICAgZXBob25lTnVtYmVyMS4uLiAgDQogIDAxNzA6ICAyYiAzNCAzNiAyMCAzMyAz MSAyMCAzNyAgMzcgMzIgMjAgMzEgMzAgMjAgMzAgMzAgICArNDYgMzEgNzcyIDEw IDAwICANCiAgMDE4MDogIDMwIDJlIDA0IDE4IDY2IDYxIDYzIDczICA2OSA2ZCA2 OSA2YyA2NSA1NCA2NSA2YyAgIDAuLi5mYWNzaW1pbGVUZWwgIA0KICAwMTkwOiAg NjUgNzAgNjggNmYgNmUgNjUgNGUgNzUgIDZkIDYyIDY1IDcyIDMxIDEyIDA0IDEw ICAgZXBob25lTnVtYmVyMS4uLiAgDQogIDAxYTA6ICAyYiAzNCAzNiAyMCAzMyAz MSAyMCAzNyAgMzcgMzIgMjAgMzMgMzggMjAgMzcgMzIgICArNDYgMzEgNzcyIDM4 IDcyICANCiAgMDFiMDogIDMwIDI2IDA0IDBhIDZjIDYxIDYyIDY1ICA2YyA2NSA2 NCA1NSA1MiA0OSAzMSAxOCAgIDAmLi5sYWJlbGVkVVJJMS4gIA0KICAwMWMwOiAg MDQgMTYgNjggNzQgNzQgNzAgM2EgMmYgIDJmIDc3IDc3IDc3IDJlIDYzIDY4IDYx ICAgLi5odHRwOi8vd3d3LmNoYSAgDQogIDAxZDA6ICA2YyA2ZCA2NSA3MiA3MyAy ZSA3MyA2NSAgMzAgMTAgMDQgMDIgNjQgNjMgMzEgMGEgICBsbWVycy5zZTAuLi5k YzEuICANCiAgMDFlMDogIDA0IDA4IDYzIDY4IDYxIDZjIDZkIDY1ICA3MiA3MyAz MCAyNyAwNCAxNSA3MyA3NCAgIC4uY2hhbG1lcnMwJy4uc3QgIA0KICAwMWYwOiAg NzIgNzUgNjMgNzQgNzUgNzIgNjEgNmMgIDRmIDYyIDZhIDY1IDYzIDc0IDQzIDZj ICAgcnVjdHVyYWxPYmplY3RDbCAgDQogIDAyMDA6ICA2MSA3MyA3MyAzMSAwZSAw NCAwYyA2ZiAgNzIgNjcgNjEgNmUgNjkgN2EgNjEgNzQgICBhc3MxLi4ub3JnYW5p emF0ICANCiAgMDIxMDogIDY5IDZmIDZlIDMwIDMzIDA0IDA5IDY1ICA2ZSA3NCA3 MiA3OSA1NSA1NSA0OSA0NCAgIGlvbjAzLi5lbnRyeVVVSUQgIA0KICAwMjIwOiAg MzEgMjYgMDQgMjQgNjIgMzEgMzIgNjYgIDY0IDM5IDM2IDMwIDJkIDY1IDMyIDM2 ICAgMSYuJGIxMmZkOTYwLWUyNiAgDQogIDAyMzA6ICA2NCAyZCAzMSAzMCAzMyAz MCAyZCAzOCAgMzUgMzAgMzYgMmQgMzAgMzEgMzUgNjIgICBkLTEwMzAtODUwNi0w MTViICANCiAgMDI0MDogIDM3IDYyIDMwIDMzIDY0IDY0IDYzIDY1ICAzMCAyZSAw NCAwYyA2MyA3MiA2NSA2MSAgIDdiMDNkZGNlMC4uLmNyZWEgIA0KICAwMjUwOiAg NzQgNmYgNzIgNzMgNGUgNjEgNmQgNjUgIDMxIDFlIDA0IDFjIDYzIDZlIDNkIDRk ICAgdG9yc05hbWUxLi4uY249TSAgDQogIDAyNjA6ICA2MSA2ZSA2MSA2NyA2NSA3 MiAyYyA2NCAgNjMgM2QgNjMgNjggNjEgNmMgNmQgNjUgICBhbmFnZXIsZGM9Y2hh bG1lICANCiAgMDI3MDogIDcyIDczIDJjIDY0IDYzIDNkIDczIDY1ICAzMCAyZiAw NCAwZCA2ZCA2ZiA2NCA2OSAgIHJzLGRjPXNlMC8uLm1vZGkgIA0KICAwMjgwOiAg NjYgNjkgNjUgNzIgNzMgNGUgNjEgNmQgIDY1IDMxIDFlIDA0IDFjIDYzIDZlIDNk ICAgZmllcnNOYW1lMS4uLmNuPSAgDQogIDAyOTA6ICA0ZCA2MSA2ZSA2MSA2NyA2 NSA3MiAyYyAgNjQgNjMgM2QgNjMgNjggNjEgNmMgNmQgICBNYW5hZ2VyLGRjPWNo YWxtICANCiAgMDJhMDogIDY1IDcyIDczIDJjIDY0IDYzIDNkIDczICA2NSAzMCAy NCAwNCAwZiA2MyA3MiA2NSAgIGVycyxkYz1zZTAkLi5jcmUgIA0KICAwMmIwOiAg NjEgNzQgNjUgNTQgNjkgNmQgNjUgNzMgIDc0IDYxIDZkIDcwIDMxIDExIDA0IDBm ICAgYXRlVGltZXN0YW1wMS4uLiAgDQogIDAyYzA6ICAzMiAzMCAzMSAzMiAzMCAz MiAzMCAzMyAgMzAgMzQgMzQgMzUgMzUgMzAgNWEgMzAgICAyMDEyMDIwMzA0NDU1 MFowICANCiAgMDJkMDogIDI0IDA0IDBmIDZkIDZmIDY0IDY5IDY2ICA3OSA1NCA2 OSA2ZCA2NSA3MyA3NCA2MSAgICQuLm1vZGlmeVRpbWVzdGEgIA0KICAwMmUwOiAg NmQgNzAgMzEgMTEgMDQgMGYgMzIgMzAgIDMxIDMyIDMwIDMyIDMwIDMzIDMwIDM0 ICAgbXAxLi4uMjAxMjAyMDMwNCAgDQogIDAyZjA6ICAzNCAzNSAzNSAzMCA1YSAz MCAyZSAwNCAgMDggNjUgNmUgNzQgNzIgNzkgNDMgNTMgICA0NTUwWjAuLi5lbnRy eUNTICANCiAgMDMwMDogIDRlIDMxIDIyIDA0IDIwIDMyIDMwIDMxICAzMiAzMCAz MiAzMCAzMyAzMCAzNCAzNCAgIE4xIi4gMjAxMjAyMDMwNDQgIA0KICAwMzEwOiAg MzUgMzUgMzAgNWEgMjMgMzAgMzAgMzAgIDMwIDMwIDMwIDIzIDMwIDMwIDIzIDMw ICAgNTUwWiMwMDAwMDAjMDAjMCAgDQogIDAzMjA6ICAzMCAzMCAzMCAzMCAzMCAz MCAxZSAwNCAgMDcgNjUgNmUgNzQgNzIgNzkgNDQgNGUgICAwMDAwMDAuLi5lbnRy eUROICANCiAgMDMzMDogIDMxIDEzIDA0IDExIDY0IDYzIDNkIDYzICA2OCA2MSA2 YyA2ZCA2NSA3MiA3MyAyYyAgIDEuLi5kYz1jaGFsbWVycywgIA0KICAwMzQwOiAg NjQgNjMgM2QgNzMgNjUgMzAgMjMgMDQgIDExIDczIDc1IDYyIDczIDYzIDY4IDY1 ICAgZGM9c2UwIy4uc3Vic2NoZSAgDQogIDAzNTA6ICA2ZCA2MSA1MyA3NSA2MiA2 NSA2ZSA3NCAgNzIgNzkgMzEgMGUgMDQgMGMgNjMgNmUgICBtYVN1YmVudHJ5MS4u LmNuICANCiAgMDM2MDogIDNkIDUzIDc1IDYyIDczIDYzIDY4IDY1ICA2ZCA2MSAz MCAxOSAwNCAwZiA2OCA2MSAgID1TdWJzY2hlbWEwLi4uaGEgIA0KICAwMzcwOiAg NzMgNTMgNzUgNjIgNmYgNzIgNjQgNjkgIDZlIDYxIDc0IDY1IDczIDMxIDA2IDA0 ICAgc1N1Ym9yZGluYXRlczEuLiAgDQogIDAzODA6ICAwNCA1NCA1MiA1NSA0NSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuVFJVRSAgICAgICAg ICAgICANCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDkwNSBjb250ZW50czoN CnJlYWQxbXNnOiBsZCAweDI5MjgwMzAgbXNnaWQgMiBtZXNzYWdlIHR5cGUgc2Vh cmNoLWVudHJ5DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KNGYyYzg5ZmUgPj4+ IGRuUHJldHR5Tm9ybWFsOiA8ZGM9Y2hhbG1lcnMsZGM9c2U+DQo9PiBsZGFwX2J2 MmRuKGRjPWNoYWxtZXJzLGRjPXNlLDApDQo8PSBsZGFwX2J2MmRuKGRjPWNoYWxt ZXJzLGRjPXNlKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBsZGFwX2RuMmJ2 KGRjPWNoYWxtZXJzLGRjPXNlKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBs ZGFwX2RuMmJ2KGRjPWNoYWxtZXJzLGRjPXNlKT0wIA0KNGYyYzg5ZmUgPDw8IGRu UHJldHR5Tm9ybWFsOiA8ZGM9Y2hhbG1lcnMsZGM9c2U+LCA8ZGM9Y2hhbG1lcnMs ZGM9c2U+DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAo W1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZt dCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5m IGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3Nj YW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVy X3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0K YmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVy Og0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkg YmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7 bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10 ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYg Zm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2Nh bmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJf c2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQo0 ZjJjODlmZSA+Pj4gZG5QcmV0dHk6IDxjbj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRj PXNlPg0KPT4gbGRhcF9idjJkbihjbj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRjPXNl LDApDQo8PSBsZGFwX2J2MmRuKGNuPU1hbmFnZXIsZGM9Y2hhbG1lcnMsZGM9c2Up PTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikNCjw9IGxkYXBfZG4yYnYoY249TWFuYWdl cixkYz1jaGFsbWVycyxkYz1zZSk9MCANCjRmMmM4OWZlIDw8PCBkblByZXR0eTog PGNuPU1hbmFnZXIsZGM9Y2hhbG1lcnMsZGM9c2U+DQo0ZjJjODlmZSA+Pj4gZG5O b3JtYWxpemU6IDxjbj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRjPXNlPg0KPT4gbGRh cF9idjJkbihjbj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRjPXNlLDApDQo8PSBsZGFw X2J2MmRuKGNuPU1hbmFnZXIsZGM9Y2hhbG1lcnMsZGM9c2UpPTAgDQo9PiBsZGFw X2RuMmJ2KDI3MikNCjw9IGxkYXBfZG4yYnYoY249bWFuYWdlcixkYz1jaGFsbWVy cyxkYz1zZSk9MCANCjRmMmM4OWZlIDw8PCBkbk5vcm1hbGl6ZTogPGNuPW1hbmFn ZXIsZGM9Y2hhbG1lcnMsZGM9c2U+DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0K YmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQo0ZjJjODlmZSA+Pj4gZG5QcmV0dHk6 IDxjbj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRjPXNlPg0KPT4gbGRhcF9idjJkbihj bj1NYW5hZ2VyLGRjPWNoYWxtZXJzLGRjPXNlLDApDQo8PSBsZGFwX2J2MmRuKGNu PU1hbmFnZXIsZGM9Y2hhbG1lcnMsZGM9c2UpPTAgDQo9PiBsZGFwX2RuMmJ2KDI3 MikNCjw9IGxkYXBfZG4yYnYoY249TWFuYWdlcixkYz1jaGFsbWVycyxkYz1zZSk9 MCANCjRmMmM4OWZlIDw8PCBkblByZXR0eTogPGNuPU1hbmFnZXIsZGM9Y2hhbG1l cnMsZGM9c2U+DQo0ZjJjODlmZSA+Pj4gZG5Ob3JtYWxpemU6IDxjbj1NYW5hZ2Vy LGRjPWNoYWxtZXJzLGRjPXNlPg0KPT4gbGRhcF9idjJkbihjbj1NYW5hZ2VyLGRj PWNoYWxtZXJzLGRjPXNlLDApDQo8PSBsZGFwX2J2MmRuKGNuPU1hbmFnZXIsZGM9 Y2hhbG1lcnMsZGM9c2UpPTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikNCjw9IGxkYXBf ZG4yYnYoY249bWFuYWdlcixkYz1jaGFsbWVycyxkYz1zZSk9MCANCjRmMmM4OWZl IDw8PCBkbk5vcm1hbGl6ZTogPGNuPW1hbmFnZXIsZGM9Y2hhbG1lcnMsZGM9c2U+ DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBi ZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1dd KSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAo W1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZt dCAoeCkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoe20pIGJlcjoNCmJlcl9zY2FuZiBm bXQgKHgpIGJlcjoNCmJlcl9zY2FuZiBmbXQgKHttKSBiZXI6DQpiZXJfc2NhbmYg Zm10IChbV10pIGJlcjoNCmJlcl9zY2FuZiBmbXQgKHt4eCkgYmVyOg0KNGYyYzg5 ZmUgY29ubj0xMDAwIG9wPTE6IGJhY2stcmVsYXkgZm9yIEROPSJkYz1jaGFsbWVy cyxkYz1zZSIgd291bGQgY2FsbCBzZWxmLg0KNGYyYzg5ZmUgPT0+IHRyYW5zbHVj ZW50X3NlYXJjaF9jYjogZGM9Y2hhbG1lcnMsZGM9c2UNCjRmMmM4OWZlID09PiBy ZXdyaXRlX2NvbnRleHRfYXBwbHkgW2RlcHRoPTFdIHN0cmluZz0nZGM9Y2hhbG1l cnMsZGM9c2UnDQo0ZjJjODlmZSA9PT4gcmV3cml0ZV9ydWxlX2FwcGx5IHJ1bGU9 JygoLispLCk/ZGM9Y2hhbG1lcnMsWyBdP2RjPXNlJCcgc3RyaW5nPSdkYz1jaGFs bWVycyxkYz1zZScgWzEgcGFzcyhlcyldDQo0ZjJjODlmZSA9PT4gcmV3cml0ZV9j b250ZXh0X2FwcGx5IFtkZXB0aD0xXSByZXM9ezAsJ2RjPXJzcyxkYz1jaGFsbWVy cyxkYz1zZSd9DQo0ZjJjODlmZSBbcnddIHNlYXJjaEROOiAiZGM9Y2hhbG1lcnMs ZGM9c2UiIC0+ICJkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2UiDQo0ZjJjODlmZSA+ Pj4gZG5Ob3JtYWxpemU6IDxkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2U+DQo9PiBs ZGFwX2J2MmRuKGRjPXJzcyxkYz1jaGFsbWVycyxkYz1zZSwwKQ0KPD0gbGRhcF9i djJkbihkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2UpPTAgDQo9PiBsZGFwX2RuMmJ2 KDI3MikNCjw9IGxkYXBfZG4yYnYoZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlKT0w IA0KNGYyYzg5ZmUgPDw8IGRuTm9ybWFsaXplOiA8ZGM9cnNzLGRjPWNoYWxtZXJz LGRjPXNlPg0KNGYyYzg5ZmUgPT4gYmRiX2VudHJ5X2dldDogbmRuOiAiZGM9cnNz LGRjPWNoYWxtZXJzLGRjPXNlIg0KNGYyYzg5ZmUgPT4gYmRiX2VudHJ5X2dldDog b2M6ICIobnVsbCkiLCBhdDogIihudWxsKSINCjRmMmM4OWZlIGJkYl9kbjJlbnRy eSgiZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlIikNCjRmMmM4OWZlID0+IGhkYl9k bjJpZCgiZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlIikNCjRmMmM4OWZlIDw9IGhk Yl9kbjJpZDogZ290IGlkPTB4MQ0KNGYyYzg5ZmUgZW50cnlfZGVjb2RlOiAiIg0K NGYyYzg5ZmUgPD0gZW50cnlfZGVjb2RlKCkNCjRmMmM4OWZlIGJkYl9lbnRyeV9n ZXQ6IHJjPTANCjRmMmM4OWZlID09PiByZXdyaXRlX2NvbnRleHRfYXBwbHkgW2Rl cHRoPTFdIHN0cmluZz0nZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlJw0KNGYyYzg5 ZmUgPT0+IHJld3JpdGVfcnVsZV9hcHBseSBydWxlPScoKC4rKSwpP2RjPXJzcyxb IF0/ZGM9Y2hhbG1lcnMsWyBdP2RjPXNlJCcgc3RyaW5nPSdkYz1yc3MsZGM9Y2hh bG1lcnMsZGM9c2UnIFsxIHBhc3MoZXMpXQ0KNGYyYzg5ZmUgPT0+IHJld3JpdGVf Y29udGV4dF9hcHBseSBbZGVwdGg9MV0gcmVzPXswLCdkYz1jaGFsbWVycyxkYz1z ZSd9DQo0ZjJjODlmZSBbcnddIHNlYXJjaEVudHJ5RE46ICJkYz1yc3MsZGM9Y2hh bG1lcnMsZGM9c2UiIC0+ICJkYz1jaGFsbWVycyxkYz1zZSINCjRmMmM4OWZlID4+ PiBkblByZXR0eU5vcm1hbDogPGRjPWNoYWxtZXJzLGRjPXNlPg0KPT4gbGRhcF9i djJkbihkYz1jaGFsbWVycyxkYz1zZSwwKQ0KPD0gbGRhcF9idjJkbihkYz1jaGFs bWVycyxkYz1zZSk9MCANCj0+IGxkYXBfZG4yYnYoMjcyKQ0KPD0gbGRhcF9kbjJi dihkYz1jaGFsbWVycyxkYz1zZSk9MCANCj0+IGxkYXBfZG4yYnYoMjcyKQ0KPD0g bGRhcF9kbjJidihkYz1jaGFsbWVycyxkYz1zZSk9MCANCjRmMmM4OWZlIDw8PCBk blByZXR0eU5vcm1hbDogPGRjPWNoYWxtZXJzLGRjPXNlPiwgPGRjPWNoYWxtZXJz LGRjPXNlPg0KNGYyYzg5ZmUgPT0+IHJld3JpdGVfY29udGV4dF9hcHBseSBbZGVw dGg9MV0gc3RyaW5nPSdkYz1jaGFsbWVycyxkYz1zZScNCjRmMmM4OWZlID09PiBy ZXdyaXRlX3J1bGVfYXBwbHkgcnVsZT0nKCguKyksKT9kYz1yc3MsWyBdP2RjPWNo YWxtZXJzLFsgXT9kYz1zZSQnIHN0cmluZz0nZGM9Y2hhbG1lcnMsZGM9c2UnIFsx IHBhc3MoZXMpXQ0KNGYyYzg5ZmUgPT0+IHJld3JpdGVfY29udGV4dF9hcHBseSBb ZGVwdGg9MV0gcmVzPXswLCdkYz1jaGFsbWVycyxkYz1zZSd9DQo0ZjJjODlmZSBb cnddIHNlYXJjaEVudHJ5RE46ICJkYz1jaGFsbWVycyxkYz1zZSIgLT4gImRjPWNo YWxtZXJzLGRjPXNlIg0KNGYyYzg5ZmUgPT4gc2VuZF9zZWFyY2hfZW50cnk6IGNv bm4gMTAwMCBkbj0iZGM9Y2hhbG1lcnMsZGM9c2UiDQpiZXJfZmx1c2gyOiAyOCBi eXRlcyB0byBzZCAxMg0KbGRhcF93cml0ZTogd2FudD0yOCwgd3JpdHRlbj0yOA0K ICAwMDAwOiAgMzAgMWEgMDIgMDEgMDIgNjQgMTUgMDQgIDExIDY0IDYzIDNkIDYz IDY4IDYxIDZjICAgMC4uLi5kLi4uZGM9Y2hhbCAgDQogIDAwMTA6ICA2ZCA2NSA3 MiA3MyAyYyA2NCA2MyAzZCAgNzMgNjUgMzAgMDAgICAgICAgICAgICAgICBtZXJz LGRjPXNlMC4gICAgICANCjRmMmM4OWZlIDw9IHNlbmRfc2VhcmNoX2VudHJ5OiBj b25uIDEwMDAgZXhpdC4NCmxkYXBfbXNnZnJlZQ0KbGRhcF9yZXN1bHQgbGQgMHgy OTI4MDMwIG1zZ2lkIDINCndhaXQ0bXNnIGxkIDB4MjkyODAzMCBtc2dpZCAyICh0 aW1lb3V0IDEwMDAwMCB1c2VjKQ0Kd2FpdDRtc2cgY29udGludWUgbGQgMHgyOTI4 MDMwIG1zZ2lkIDIgYWxsIDANCioqIGxkIDB4MjkyODAzMCBDb25uZWN0aW9uczoN CiogaG9zdDogbGRhcC5jaGFsbWVycy5zZSAgcG9ydDogMzg5ICAoZGVmYXVsdCkN CiAgcmVmY250OiAyICBzdGF0dXM6IENvbm5lY3RlZA0KICBsYXN0IHVzZWQ6IFNh dCBGZWIgIDQgMDI6Mjk6MzQgMjAxMg0KDQoNCioqIGxkIDB4MjkyODAzMCBPdXRz dGFuZGluZyBSZXF1ZXN0czoNCiAqIG1zZ2lkIDIsICBvcmlnaWQgMiwgc3RhdHVz IEluUHJvZ3Jlc3MNCiAgIG91dHN0YW5kaW5nIHJlZmVycmFscyAwLCBwYXJlbnQg Y291bnQgMA0KICBsZCAweDI5MjgwMzAgcmVxdWVzdCBjb3VudCAxIChhYmFuZG9u ZWQgMCkNCioqIGxkIDB4MjkyODAzMCBSZXNwb25zZSBRdWV1ZToNCiAgIEVtcHR5 DQogIGxkIDB4MjkyODAzMCByZXNwb25zZSBjb3VudCAwDQpsZGFwX2Noa1Jlc3Bv bnNlTGlzdCBsZCAweDI5MjgwMzAgbXNnaWQgMiBhbGwgMA0KbGRhcF9jaGtSZXNw b25zZUxpc3QgcmV0dXJucyBsZCAweDI5MjgwMzAgTlVMTA0KbGRhcF9pbnRfc2Vs ZWN0DQpyZWFkMW1zZzogbGQgMHgyOTI4MDMwIG1zZ2lkIDIgYWxsIDANCmJlcl9n ZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTgsIGdvdD04DQogIDAwMDA6ICAzMCAw YyAwMiAwMSAwMiA2NSAwNyAwYSAgICAgICAgICAgICAgICAgICAgICAgICAgICAw Li4uLmUuLiAgICAgICAgICANCmxkYXBfcmVhZDogd2FudD02LCBnb3Q9Ng0KICAw MDAwOiAgMDEgMDAgMDQgMDAgMDQgMDAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLi4uLi4uICAgICAgICAgICAgDQpiZXJfZ2V0X25leHQ6IHRhZyAw eDMwIGxlbiAxMiBjb250ZW50czoNCnJlYWQxbXNnOiBsZCAweDI5MjgwMzAgbXNn aWQgMiBtZXNzYWdlIHR5cGUgc2VhcmNoLXJlc3VsdA0KYmVyX3NjYW5mIGZtdCAo e2VBQSkgYmVyOg0KcmVhZDFtc2c6IGxkIDB4MjkyODAzMCAwIG5ldyByZWZlcnJh bHMNCnJlYWQxbXNnOiAgbWFyayByZXF1ZXN0IGNvbXBsZXRlZCwgbGQgMHgyOTI4 MDMwIG1zZ2lkIDINCnJlcXVlc3QgZG9uZTogbGQgMHgyOTI4MDMwIG1zZ2lkIDIN CnJlc19lcnJubzogMCwgcmVzX2Vycm9yOiA8PiwgcmVzX21hdGNoZWQ6IDw+DQps ZGFwX2ZyZWVfcmVxdWVzdCAob3JpZ2lkIDIsIG1zZ2lkIDIpDQpsZGFwX3BhcnNl X3Jlc3VsdA0KYmVyX3NjYW5mIGZtdCAoe2lBQSkgYmVyOg0KYmVyX3NjYW5mIGZt dCAofSkgYmVyOg0KbGRhcF9tc2dmcmVlDQo0ZjJjODlmZSBzZW5kX2xkYXBfcmVz dWx0OiBjb25uPTEwMDAgb3A9MSBwPTMNCjRmMmM4OWZlIHNlbmRfbGRhcF9yZXN1 bHQ6IGVycj0wIG1hdGNoZWQ9IiIgdGV4dD0iIg0KNGYyYzg5ZmUgc2VuZF9sZGFw X3Jlc3BvbnNlOiBtc2dpZD0yIHRhZz0xMDEgZXJyPTANCmJlcl9mbHVzaDI6IDE0 IGJ5dGVzIHRvIHNkIDEyDQo0ZjJjODlmZSBjb25uZWN0aW9uX2dldCgxMikNCmxk YXBfd3JpdGU6IHdhbnQ9MTQsIHdyaXR0ZW49MTQNCiAgMDAwMDogIDMwIDBjIDAy IDAxIDAyIDY1IDA3IDBhICAwMSAwMCAwNCAwMCAwNCAwMCAgICAgICAgIDAuLi4u ZS4uLi4uLi4uICAgIA0KNGYyYzg5ZmUgY29ubmVjdGlvbl9nZXQoMTIpOiBnb3Qg Y29ubmlkPTEwMDANCjRmMmM4OWZlIGNvbm5lY3Rpb25fcmVhZCgxMik6IGNoZWNr aW5nIGZvciBpbnB1dCBvbiBpZD0xMDAwDQpiZXJfZ2V0X25leHQNCmxkYXBfcmVh ZDogd2FudD04LCBnb3Q9Nw0KICAwMDAwOiAgMzAgMDUgMDIgMDEgMDMgNDIgMDAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC4uLi5CLiAgICAgICAgICAg DQpiZXJfZ2V0X25leHQ6IHRhZyAweDMwIGxlbiA1IGNvbnRlbnRzOg0KNGYyYzg5 ZmUgb3AgdGFnIDB4NDIsIHRpbWUgMTMyODMxODk3NA0KYmVyX2dldF9uZXh0DQps ZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTANCg0KNGYyYzg5ZmUgYmVyX2dldF9uZXh0 IG9uIGZkIDEyIGZhaWxlZCBlcnJubz0wIChTdWNjZXNzKQ0KNGYyYzg5ZmUgY29u bj0xMDAwIG9wPTIgZG9fdW5iaW5kDQo0ZjJjODlmZSBjb25uZWN0aW9uX2Nsb3Nl OiBjb25uPTEwMDAgc2Q9MTINCjRmMmM4OWZlIHRyYW5zbHVjZW50X2Nvbm5lY3Rp b25fZGVzdHJveQ0KNGYyYzg5ZmUgPT5sZGFwX2JhY2tfY29ubl9kZXN0cm95OiBm ZXRjaGluZyBjb25uIDEwMDANCg0K ------------jL0Q7OrKgMl1NhGUUvXpqG Content-Disposition: attachment; filename=slapd-softerra.log Content-Type: application/octet-stream; name="slapd-softerra.log" Content-Transfer-Encoding: Base64 NGYyYzhhNTAgc2xhcGQgc3RhcnR1cDogaW5pdGlhdGVkLg0KNGYyYzhhNTAgYmFj a2VuZF9zdGFydHVwX29uZTogc3RhcnRpbmcgImNuPWNvbmZpZyINCjRmMmM4YTUw IGNvbmZpZ19iYWNrX2RiX29wZW4NCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRy eTogImNuPWNvbmZpZyINCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogImNu PW1vZHVsZXswfSINCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXNj aGVtYSINCjRmMmM4YTUwID4+PiBkbk5vcm1hbGl6ZTogPGNuPXswfWNvcmU+DQo0 ZjJjOGE1MCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17MH1jb3JlPg0KNGYyYzhhNTAg Y29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezB9Y29yZSINCjRmMmM4YTUwID4+PiBk bk5vcm1hbGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4YTUwIDw8PCBkbk5vcm1h bGl6ZTogPGNuPXsxfWNvc2luZT4NCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRy eTogImNuPXsxfWNvc2luZSINCjRmMmM4YTUwID4+PiBkbk5vcm1hbGl6ZTogPGNu PXsyfW5pcz4NCjRmMmM4YTUwIDw8PCBkbk5vcm1hbGl6ZTogPGNuPXsyfW5pcz4N CjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogImNuPXsyfW5pcyINCjRmMmM4 YTUwID4+PiBkbk5vcm1hbGl6ZTogPGNuPXszfWluZXRvcmdwZXJzb24+DQo0ZjJj OGE1MCA8PDwgZG5Ob3JtYWxpemU6IDxjbj17M31pbmV0b3JncGVyc29uPg0KNGYy YzhhNTAgY29uZmlnX2J1aWxkX2VudHJ5OiAiY249ezN9aW5ldG9yZ3BlcnNvbiIN CjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFiYXNlPXstMX1m cm9udGVuZCINCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogIm9sY0RhdGFi YXNlPXswfWNvbmZpZyINCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTogIm9s Y0RhdGFiYXNlPXsxfWhkYiINCjRmMmM4YTUwIGNvbmZpZ19idWlsZF9lbnRyeTog Im9sY0RhdGFiYXNlPXsyfXJlbGF5Ig0KNGYyYzhhNTAgY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17MH1yd20iDQo0ZjJjOGE1MCBjb25maWdfYnVpbGRf ZW50cnk6ICJvbGNPdmVybGF5PXsxfXRyYW5zbHVjZW50Ig0KNGYyYzhhNTAgPT0+ IHRyYW5zbHVjZW50X2NmYWRkDQo0ZjJjOGE1MCBjb25maWdfYnVpbGRfZW50cnk6 ICJvbGNEYXRhYmFzZT17MH1sZGFwIg0KNGYyYzhhNTAgY29uZmlnX2J1aWxkX2Vu dHJ5OiAib2xjT3ZlcmxheT17Mn1nbHVlIg0KNGYyYzhhNTAgYmFja2VuZF9zdGFy dHVwX29uZTogc3RhcnRpbmcgImRjPXJzcyxkYz1jaGFsbWVycyxkYz1zZSINCjRm MmM4YTUwIGhkYl9kYl9vcGVuOiAiZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlIg0K NGYyYzhhNTAgaGRiX2RiX29wZW46IGRhdGFiYXNlICJkYz1yc3MsZGM9Y2hhbG1l cnMsZGM9c2UiOiBkYmVudl9vcGVuKC92YXIvbGliL2xkYXApLg0KNGYyYzhhNTAg aGRiX21vbml0b3JfZGJfb3BlbjogbW9uaXRvcmluZyBkaXNhYmxlZDsgY29uZmln dXJlIG1vbml0b3IgZGF0YWJhc2UgdG8gZW5hYmxlDQo0ZjJjOGE1MCBiYWNrZW5k X3N0YXJ0dXBfb25lOiBzdGFydGluZyAiZGM9Y2hhbG1lcnMsZGM9c2UiDQo0ZjJj OGE1MCA9PT4gdHJhbnNsdWNlbnRfZGJfb3Blbg0KNGYyYzhhNTAgYmFja2VuZF9z dGFydHVwX29uZTogc3RhcnRpbmcgImRjPWNoYWxtZXJzLGRjPXNlIg0KNGYyYzhh NTAgbGRhcF9iYWNrX2RiX29wZW46IFVSST1sZGFwOi8vbGRhcC5jaGFsbWVycy5z ZQ0KNGYyYzhhNTAgc2xhcGQgc3RhcnRpbmcNCjRmMmM4YTU4IHNsYXBfbGlzdGVu ZXJfYWN0aXZhdGUoNyk6IA0KNGYyYzhhNTggPj4+IHNsYXBfbGlzdGVuZXIobGRh cDovLy8pDQo0ZjJjOGE1OCBjb25uZWN0aW9uX2dldCgxMikNCjRmMmM4YTU4IGNv bm5lY3Rpb25fZ2V0KDEyKTogZ290IGNvbm5pZD0xMDAwDQo0ZjJjOGE1OCBjb25u ZWN0aW9uX3JlYWQoMTIpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9MTAwMA0K YmVyX2dldF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDog IDMwIDg0IDAwIDAwIDAwIDEwIDAyIDAxICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAuLi4uLi4uICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTE0LCBnb3Q9 MTQNCiAgMDAwMDogIDU1IDYwIDg0IDAwIDAwIDAwIDA3IDAyICAwMSAwMyAwNCAw MCA4MCAwMCAgICAgICAgIFVgLi4uLi4uLi4uLi4uICAgIA0KYmVyX2dldF9uZXh0 OiB0YWcgMHgzMCBsZW4gMTYgY29udGVudHM6DQo0ZjJjOGE1OCBvcCB0YWcgMHg2 MCwgdGltZSAxMzI4MzE5MDY0DQpiZXJfZ2V0X25leHQNCmxkYXBfcmVhZDogd2Fu dD04IGVycm9yPVJlc291cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlDQo0ZjJj OGE1OCBjb25uPTEwMDAgb3A9MCBkb19iaW5kDQpiZXJfc2NhbmYgZm10ICh7aW10 KSBiZXI6DQpiZXJfc2NhbmYgZm10IChtfSkgYmVyOg0KNGYyYzhhNTggPj4+IGRu UHJldHR5Tm9ybWFsOiA8Pg0KNGYyYzhhNTggPDw8IGRuUHJldHR5Tm9ybWFsOiA8 PiwgPD4NCjRmMmM4YTU4IGRvX2JpbmQ6IHZlcnNpb249MyBkbj0iIiBtZXRob2Q9 MTI4DQo0ZjJjOGE1OCBzZW5kX2xkYXBfcmVzdWx0OiBjb25uPTEwMDAgb3A9MCBw PTMNCjRmMmM4YTU4IHNlbmRfbGRhcF9yZXN1bHQ6IGVycj0wIG1hdGNoZWQ9IiIg dGV4dD0iIg0KNGYyYzhhNTggc2VuZF9sZGFwX3Jlc3BvbnNlOiBtc2dpZD04NSB0 YWc9OTcgZXJyPTANCmJlcl9mbHVzaDI6IDE0IGJ5dGVzIHRvIHNkIDEyDQpsZGFw X3dyaXRlOiB3YW50PTE0LCB3cml0dGVuPTE0DQogIDAwMDA6ICAzMCAwYyAwMiAw MSA1NSA2MSAwNyAwYSAgMDEgMDAgMDQgMDAgMDQgMDAgICAgICAgICAwLi4uVWEu Li4uLi4uLiAgICANCjRmMmM4YTU4IGRvX2JpbmQ6IHYzIGFub255bW91cyBiaW5k DQo0ZjJjOGE1OCBjb25uZWN0aW9uX2dldCgxMikNCjRmMmM4YTU4IGNvbm5lY3Rp b25fZ2V0KDEyKTogZ290IGNvbm5pZD0xMDAwDQo0ZjJjOGE1OCBjb25uZWN0aW9u X3JlYWQoMTIpOiBjaGVja2luZyBmb3IgaW5wdXQgb24gaWQ9MTAwMA0KYmVyX2dl dF9uZXh0DQpsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMwIDg0 IDAwIDAwIDAwIDQzIDAyIDAxICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAu Li4uQy4uICAgICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTY1LCBnb3Q9NjUNCiAg MDAwMDogIDU2IDYzIDg0IDAwIDAwIDAwIDNhIDA0ICAxMSA2NCA2MyAzZCA2MyA2 OCA2MSA2YyAgIFZjLi4uLjouLmRjPWNoYWwgIA0KICAwMDEwOiAgNmQgNjUgNzIg NzMgMmMgNjQgNjMgM2QgIDczIDY1IDBhIDAxIDAwIDBhIDAxIDAwICAgbWVycyxk Yz1zZS4uLi4uLiAgDQogIDAwMjA6ICAwMiAwMSAwMCAwMiAwMSAwMCAwMSAwMSAg ZmYgODcgMGIgNGYgNjIgNmEgNjUgNjMgICAuLi4uLi4uLi4uLk9iamVjICANCiAg MDAzMDogIDc0IDQzIDZjIDYxIDczIDczIDMwIDg0ICAwMCAwMCAwMCAwNSAwNCAw MyAzMSAyZSAgIHRDbGFzczAuLi4uLi4uMS4gIA0KICAwMDQwOiAgMzEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgDQpiZXJfZ2V0X25leHQ6IHRhZyAweDMwIGxlbiA2NyBjb250 ZW50czoNCjRmMmM4YTU4IG9wIHRhZyAweDYzLCB0aW1lIDEzMjgzMTkwNjQNCmJl cl9nZXRfbmV4dA0KbGRhcF9yZWFkOiB3YW50PTggZXJyb3I9UmVzb3VyY2UgdGVt cG9yYXJpbHkgdW5hdmFpbGFibGUNCjRmMmM4YTU4IGNvbm49MTAwMCBvcD0xIGRv X3NlYXJjaA0KYmVyX3NjYW5mIGZtdCAoe21paWlpYikgYmVyOg0KNGYyYzhhNTgg Pj4+IGRuUHJldHR5Tm9ybWFsOiA8ZGM9Y2hhbG1lcnMsZGM9c2U+DQo9PiBsZGFw X2J2MmRuKGRjPWNoYWxtZXJzLGRjPXNlLDApDQo8PSBsZGFwX2J2MmRuKGRjPWNo YWxtZXJzLGRjPXNlKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBsZGFwX2Ru MmJ2KGRjPWNoYWxtZXJzLGRjPXNlKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8 PSBsZGFwX2RuMmJ2KGRjPWNoYWxtZXJzLGRjPXNlKT0wIA0KNGYyYzhhNTggPDw8 IGRuUHJldHR5Tm9ybWFsOiA8ZGM9Y2hhbG1lcnMsZGM9c2U+LCA8ZGM9Y2hhbG1l cnMsZGM9c2U+DQo0ZjJjOGE1OCBTUkNIICJkYz1jaGFsbWVycyxkYz1zZSIgMCAw NGYyYzhhNTggICAgIDAgMCAtMQ0KYmVyX3NjYW5mIGZtdCAobSkgYmVyOg0KNGYy YzhhNTggICAgIGZpbHRlcjogKG9iamVjdENsYXNzPSopDQpiZXJfc2NhbmYgZm10 ICh7TX19KSBiZXI6DQo0ZjJjOGE1OCAgICAgYXR0cnM6NGYyYzhhNTggIDEuMTRm MmM4YTU4IA0KNGYyYzhhNTggPT0+IGxpbWl0c19nZXQ6IGNvbm49MTAwMCBvcD0x IHNlbGY9Ilthbm9ueW1vdXNdIiB0aGlzPSJkYz1jaGFsbWVycyxkYz1zZSINCjRm MmM4YTU4ID09PiB0cmFuc2x1Y2VudF9zZWFyY2g6IDxkYz1jaGFsbWVycyxkYz1z ZT4gKG9iamVjdENsYXNzPSopDQpsZGFwX2NyZWF0ZQ0KbGRhcF91cmxfcGFyc2Vf ZXh0KGxkYXA6Ly9sZGFwLmNoYWxtZXJzLnNlKQ0KNGYyYzhhNTggPT5sZGFwX2Jh Y2tfZ2V0Y29ubjogY29ubj0xMDAwIG9wPTE6IGxjPTB4MWQ4ZmE0MCBpbnNlcnRl ZCByZWZjbnQ9MSByYz0wDQpsZGFwX3Nhc2xfYmluZA0KbGRhcF9zZW5kX2luaXRp YWxfcmVxdWVzdA0KbGRhcF9uZXdfY29ubmVjdGlvbiAxIDEgMA0KbGRhcF9pbnRf b3Blbl9jb25uZWN0aW9uDQpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVENQIGxkYXAu Y2hhbG1lcnMuc2U6Mzg5DQpsZGFwX25ld19zb2NrZXQ6IDEzDQpsZGFwX3ByZXBh cmVfc29ja2V0OiAxMw0KbGRhcF9jb25uZWN0X3RvX2hvc3Q6IFRyeWluZyAxMjku MTYuMjIxLjQ6Mzg5DQpsZGFwX3B2dF9jb25uZWN0OiBmZDogMTMgdG06IC0xIGFz eW5jOiAwDQpsZGFwX29wZW5fZGVmY29ubjogc3VjY2Vzc2Z1bA0KbGRhcF9zZW5k X3NlcnZlcl9yZXF1ZXN0DQpiZXJfc2NhbmYgZm10ICh7aXQpIGJlcjoNCmJlcl9z Y2FuZiBmbXQgKHtpKSBiZXI6DQpiZXJfZmx1c2gyOiAxNCBieXRlcyB0byBzZCAx Mw0KbGRhcF93cml0ZTogd2FudD0xNCwgd3JpdHRlbj0xNA0KICAwMDAwOiAgMzAg MGMgMDIgMDEgMDEgNjAgMDcgMDIgIDAxIDAzIDA0IDAwIDgwIDAwICAgICAgICAg MC4uLi5gLi4uLi4uLi4gICAgDQpsZGFwX3Jlc3VsdCBsZCAweDFkOGZhYzAgbXNn aWQgMQ0Kd2FpdDRtc2cgbGQgMHgxZDhmYWMwIG1zZ2lkIDEgKHRpbWVvdXQgMTAw MDAwIHVzZWMpDQp3YWl0NG1zZyBjb250aW51ZSBsZCAweDFkOGZhYzAgbXNnaWQg MSBhbGwgMQ0KKiogbGQgMHgxZDhmYWMwIENvbm5lY3Rpb25zOg0KKiBob3N0OiBs ZGFwLmNoYWxtZXJzLnNlICBwb3J0OiAzODkgIChkZWZhdWx0KQ0KICByZWZjbnQ6 IDIgIHN0YXR1czogQ29ubmVjdGVkDQogIGxhc3QgdXNlZDogU2F0IEZlYiAgNCAw MjozMTowNCAyMDEyDQoNCg0KKiogbGQgMHgxZDhmYWMwIE91dHN0YW5kaW5nIFJl cXVlc3RzOg0KICogbXNnaWQgMSwgIG9yaWdpZCAxLCBzdGF0dXMgSW5Qcm9ncmVz cw0KICAgb3V0c3RhbmRpbmcgcmVmZXJyYWxzIDAsIHBhcmVudCBjb3VudCAwDQog IGxkIDB4MWQ4ZmFjMCByZXF1ZXN0IGNvdW50IDEgKGFiYW5kb25lZCAwKQ0KKiog bGQgMHgxZDhmYWMwIFJlc3BvbnNlIFF1ZXVlOg0KICAgRW1wdHkNCiAgbGQgMHgx ZDhmYWMwIHJlc3BvbnNlIGNvdW50IDANCmxkYXBfY2hrUmVzcG9uc2VMaXN0IGxk IDB4MWQ4ZmFjMCBtc2dpZCAxIGFsbCAxDQpsZGFwX2Noa1Jlc3BvbnNlTGlzdCBy ZXR1cm5zIGxkIDB4MWQ4ZmFjMCBOVUxMDQpsZGFwX2ludF9zZWxlY3QNCnJlYWQx bXNnOiBsZCAweDFkOGZhYzAgbXNnaWQgMSBhbGwgMQ0KYmVyX2dldF9uZXh0DQps ZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgNCiAgMDAwMDogIDMwIDBjIDAyIDAxIDAx IDYxIDA3IDBhICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuLi4uYS4uICAg ICAgICAgIA0KbGRhcF9yZWFkOiB3YW50PTYsIGdvdD02DQogIDAwMDA6ICAwMSAw MCAwNCAwMCAwNCAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAu Li4uLi4gICAgICAgICAgICANCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDEy IGNvbnRlbnRzOg0KcmVhZDFtc2c6IGxkIDB4MWQ4ZmFjMCBtc2dpZCAxIG1lc3Nh Z2UgdHlwZSBiaW5kDQpiZXJfc2NhbmYgZm10ICh7ZUFBKSBiZXI6DQpyZWFkMW1z ZzogbGQgMHgxZDhmYWMwIDAgbmV3IHJlZmVycmFscw0KcmVhZDFtc2c6ICBtYXJr IHJlcXVlc3QgY29tcGxldGVkLCBsZCAweDFkOGZhYzAgbXNnaWQgMQ0KcmVxdWVz dCBkb25lOiBsZCAweDFkOGZhYzAgbXNnaWQgMQ0KcmVzX2Vycm5vOiAwLCByZXNf ZXJyb3I6IDw+LCByZXNfbWF0Y2hlZDogPD4NCmxkYXBfZnJlZV9yZXF1ZXN0IChv cmlnaWQgMSwgbXNnaWQgMSkNCmxkYXBfcGFyc2VfcmVzdWx0DQpiZXJfc2NhbmYg Zm10ICh7aUFBKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh9KSBiZXI6DQpsZGFwX21z Z2ZyZWUNCjRmMmM4YTU4ID0+IGxkYXBfYmFja19tdW5nZV9maWx0ZXIgIihvYmpl Y3RDbGFzcz0qKSINCjRmMmM4YTU4IDw9IGxkYXBfYmFja19tdW5nZV9maWx0ZXIg IihvYmplY3RDbGFzcz0qKSIgKDApDQpsZGFwX3NlYXJjaF9leHQNCnB1dF9maWx0 ZXI6ICIob2JqZWN0Q2xhc3M9KikiDQpwdXRfZmlsdGVyOiBzaW1wbGUNCnB1dF9z aW1wbGVfZmlsdGVyOiAib2JqZWN0Q2xhc3M9KiINCmxkYXBfYnVpbGRfc2VhcmNo X3JlcSBBVFRSUzogKiArDQpsZGFwX3NlbmRfaW5pdGlhbF9yZXF1ZXN0DQpsZGFw X3NlbmRfc2VydmVyX3JlcXVlc3QNCmJlcl9zY2FuZiBmbXQgKHtpdCkgYmVyOg0K YmVyX3NjYW5mIGZtdCAoeykgYmVyOg0KYmVyX2ZsdXNoMjogNjMgYnl0ZXMgdG8g c2QgMTMNCmxkYXBfd3JpdGU6IHdhbnQ9NjMsIHdyaXR0ZW49NjMNCiAgMDAwMDog IDMwIDNkIDAyIDAxIDAyIDYzIDM4IDA0ICAxMSA2NCA2MyAzZCA2MyA2OCA2MSA2 YyAgIDA9Li4uYzguLmRjPWNoYWwgIA0KICAwMDEwOiAgNmQgNjUgNzIgNzMgMmMg NjQgNjMgM2QgIDczIDY1IDBhIDAxIDAwIDBhIDAxIDAwICAgbWVycyxkYz1zZS4u Li4uLiAgDQogIDAwMjA6ICAwMiAwMSAwMCAwMiAwMiAwZSAxMCAwMSAgMDEgZmYg ODcgMGIgNmYgNjIgNmEgNjUgICAuLi4uLi4uLi4uLi5vYmplICANCiAgMDAzMDog IDYzIDc0IDQzIDZjIDYxIDczIDczIDMwICAwNiAwNCAwMSAyYSAwNCAwMSAyYiAg ICAgIGN0Q2xhc3MwLi4uKi4uKyAgIA0KbGRhcF9yZXN1bHQgbGQgMHgxZDhmYWMw IG1zZ2lkIDINCndhaXQ0bXNnIGxkIDB4MWQ4ZmFjMCBtc2dpZCAyICh0aW1lb3V0 IDEwMDAwMCB1c2VjKQ0Kd2FpdDRtc2cgY29udGludWUgbGQgMHgxZDhmYWMwIG1z Z2lkIDIgYWxsIDANCioqIGxkIDB4MWQ4ZmFjMCBDb25uZWN0aW9uczoNCiogaG9z dDogbGRhcC5jaGFsbWVycy5zZSAgcG9ydDogMzg5ICAoZGVmYXVsdCkNCiAgcmVm Y250OiAyICBzdGF0dXM6IENvbm5lY3RlZA0KICBsYXN0IHVzZWQ6IFNhdCBGZWIg IDQgMDI6MzE6MDQgMjAxMg0KDQoNCioqIGxkIDB4MWQ4ZmFjMCBPdXRzdGFuZGlu ZyBSZXF1ZXN0czoNCiAqIG1zZ2lkIDIsICBvcmlnaWQgMiwgc3RhdHVzIEluUHJv Z3Jlc3MNCiAgIG91dHN0YW5kaW5nIHJlZmVycmFscyAwLCBwYXJlbnQgY291bnQg MA0KICBsZCAweDFkOGZhYzAgcmVxdWVzdCBjb3VudCAxIChhYmFuZG9uZWQgMCkN CioqIGxkIDB4MWQ4ZmFjMCBSZXNwb25zZSBRdWV1ZToNCiAgIEVtcHR5DQogIGxk IDB4MWQ4ZmFjMCByZXNwb25zZSBjb3VudCAwDQpsZGFwX2Noa1Jlc3BvbnNlTGlz dCBsZCAweDFkOGZhYzAgbXNnaWQgMiBhbGwgMA0KbGRhcF9jaGtSZXNwb25zZUxp c3QgcmV0dXJucyBsZCAweDFkOGZhYzAgTlVMTA0KbGRhcF9pbnRfc2VsZWN0DQpy ZWFkMW1zZzogbGQgMHgxZDhmYWMwIG1zZ2lkIDIgYWxsIDANCmJlcl9nZXRfbmV4 dA0KbGRhcF9yZWFkOiB3YW50PTgsIGdvdD04DQogIDAwMDA6ICAzMCA4MiAwMSA4 MiAwMiAwMSAwMiA2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLi4uLi4u ZCAgICAgICAgICANCmxkYXBfcmVhZDogd2FudD0zODIsIGdvdD0zODINCiAgMDAw MDogIDgyIDAxIDdiIDA0IDExIDY0IDYzIDNkICA2MyA2OCA2MSA2YyA2ZCA2NSA3 MiA3MyAgIC4uey4uZGM9Y2hhbG1lcnMgIA0KICAwMDEwOiAgMmMgNjQgNjMgM2Qg NzMgNjUgMzAgODIgIDAxIDY0IDMwIDBmIDA0IDBiIDZmIDYyICAgLGRjPXNlMC4u ZDAuLi5vYiAgDQogIDAwMjA6ICA2YSA2NSA2MyA3NCA0MyA2YyA2MSA3MyAgNzMg MzEgMDAgMzAgMGYgMDQgMGIgNjQgICBqZWN0Q2xhc3MxLjAuLi5kICANCiAgMDAz MDogIDY1IDczIDYzIDcyIDY5IDcwIDc0IDY5ICA2ZiA2ZSAzMSAwMCAzMCAwNSAw NCAwMSAgIGVzY3JpcHRpb24xLjAuLi4gIA0KICAwMDQwOiAgNmYgMzEgMDAgMzAg MDUgMDQgMDEgNmMgIDMxIDAwIDMwIDE0IDA0IDEwIDYxIDczICAgbzEuMC4uLmwx LjAuLi5hcyAgDQogIDAwNTA6ICA3MyA2ZiA2MyA2OSA2MSA3NCA2NSA2NCAgNDQg NmYgNmQgNjEgNjkgNmUgMzEgMDAgICBzb2NpYXRlZERvbWFpbjEuICANCiAgMDA2 MDogIDMwIDExIDA0IDBkIDcwIDZmIDczIDc0ICA2MSA2YyA0MSA2NCA2NCA3MiA2 NSA3MyAgIDAuLi5wb3N0YWxBZGRyZXMgIA0KICAwMDcwOiAgNzMgMzEgMDAgMzAg MTMgMDQgMGYgNzQgIDY1IDZjIDY1IDcwIDY4IDZmIDZlIDY1ICAgczEuMC4uLnRl bGVwaG9uZSAgDQogIDAwODA6ICA0ZSA3NSA2ZCA2MiA2NSA3MiAzMSAwMCAgMzAg MWMgMDQgMTggNjYgNjEgNjMgNzMgICBOdW1iZXIxLjAuLi5mYWNzICANCiAgMDA5 MDogIDY5IDZkIDY5IDZjIDY1IDU0IDY1IDZjICA2NSA3MCA2OCA2ZiA2ZSA2NSA0 ZSA3NSAgIGltaWxlVGVsZXBob25lTnUgIA0KICAwMGEwOiAgNmQgNjIgNjUgNzIg MzEgMDAgMzAgMGUgIDA0IDBhIDZjIDYxIDYyIDY1IDZjIDY1ICAgbWJlcjEuMC4u LmxhYmVsZSAgDQogIDAwYjA6ICA2NCA1NSA1MiA0OSAzMSAwMCAzMCAwNiAgMDQg MDIgNjQgNjMgMzEgMDAgMzAgMTkgICBkVVJJMS4wLi4uZGMxLjAuICANCiAgMDBj MDogIDA0IDE1IDczIDc0IDcyIDc1IDYzIDc0ICA3NSA3MiA2MSA2YyA0ZiA2MiA2 YSA2NSAgIC4uc3RydWN0dXJhbE9iamUgIA0KICAwMGQwOiAgNjMgNzQgNDMgNmMg NjEgNzMgNzMgMzEgIDAwIDMwIDBkIDA0IDA5IDY1IDZlIDc0ICAgY3RDbGFzczEu MC4uLmVudCAgDQogIDAwZTA6ICA3MiA3OSA1NSA1NSA0OSA0NCAzMSAwMCAgMzAg MTAgMDQgMGMgNjMgNzIgNjUgNjEgICByeVVVSUQxLjAuLi5jcmVhICANCiAgMDBm MDogIDc0IDZmIDcyIDczIDRlIDYxIDZkIDY1ICAzMSAwMCAzMCAxMSAwNCAwZCA2 ZCA2ZiAgIHRvcnNOYW1lMS4wLi4ubW8gIA0KICAwMTAwOiAgNjQgNjkgNjYgNjkg NjUgNzIgNzMgNGUgIDYxIDZkIDY1IDMxIDAwIDMwIDEzIDA0ICAgZGlmaWVyc05h bWUxLjAuLiAgDQogIDAxMTA6ICAwZiA2MyA3MiA2NSA2MSA3NCA2NSA1NCAgNjkg NmQgNjUgNzMgNzQgNjEgNmQgNzAgICAuY3JlYXRlVGltZXN0YW1wICANCiAgMDEy MDogIDMxIDAwIDMwIDEzIDA0IDBmIDZkIDZmICA2NCA2OSA2NiA3OSA1NCA2OSA2 ZCA2NSAgIDEuMC4uLm1vZGlmeVRpbWUgIA0KICAwMTMwOiAgNzMgNzQgNjEgNmQg NzAgMzEgMDAgMzAgIDBjIDA0IDA4IDY1IDZlIDc0IDcyIDc5ICAgc3RhbXAxLjAu Li5lbnRyeSAgDQogIDAxNDA6ICA0MyA1MyA0ZSAzMSAwMCAzMCAwYiAwNCAgMDcg NjUgNmUgNzQgNzIgNzkgNDQgNGUgICBDU04xLjAuLi5lbnRyeUROICANCiAgMDE1 MDogIDMxIDAwIDMwIDE1IDA0IDExIDczIDc1ICA2MiA3MyA2MyA2OCA2NSA2ZCA2 MSA1MyAgIDEuMC4uLnN1YnNjaGVtYVMgIA0KICAwMTYwOiAgNzUgNjIgNjUgNmUg NzQgNzIgNzkgMzEgIDAwIDMwIDEzIDA0IDBmIDY4IDYxIDczICAgdWJlbnRyeTEu MC4uLmhhcyAgDQogIDAxNzA6ICA1MyA3NSA2MiA2ZiA3MiA2NCA2OSA2ZSAgNjEg NzQgNjUgNzMgMzEgMDAgICAgICAgICBTdWJvcmRpbmF0ZXMxLiAgICANCmJlcl9n ZXRfbmV4dDogdGFnIDB4MzAgbGVuIDM4NiBjb250ZW50czoNCnJlYWQxbXNnOiBs ZCAweDFkOGZhYzAgbXNnaWQgMiBtZXNzYWdlIHR5cGUgc2VhcmNoLWVudHJ5DQpi ZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KNGYyYzhhNTggPj4+IGRuUHJldHR5Tm9y bWFsOiA8ZGM9Y2hhbG1lcnMsZGM9c2U+DQo9PiBsZGFwX2J2MmRuKGRjPWNoYWxt ZXJzLGRjPXNlLDApDQo8PSBsZGFwX2J2MmRuKGRjPWNoYWxtZXJzLGRjPXNlKT0w IA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPWNoYWxtZXJz LGRjPXNlKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8PSBsZGFwX2RuMmJ2KGRj PWNoYWxtZXJzLGRjPXNlKT0wIA0KNGYyYzhhNTggPDw8IGRuUHJldHR5Tm9ybWFs OiA8ZGM9Y2hhbG1lcnMsZGM9c2U+LCA8ZGM9Y2hhbG1lcnMsZGM9c2U+DQpiZXJf c2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpi ZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6 DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBi ZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1dd KSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAo W1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZt dCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5m IGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3Nj YW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVy X3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0K YmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkgYmVy Og0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7bSkg YmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10ICh7 bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYgZm10 ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2NhbmYg Zm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJfc2Nh bmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpiZXJf c2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoW1ddKSBiZXI6DQpi ZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX3NjYW5mIGZtdCAoeCkgYmVyOg0K YmVyX3NjYW5mIGZtdCAoe20pIGJlcjoNCmJlcl9zY2FuZiBmbXQgKHgpIGJlcjoN CmJlcl9zY2FuZiBmbXQgKHttKSBiZXI6DQpiZXJfc2NhbmYgZm10IChbV10pIGJl cjoNCmJlcl9zY2FuZiBmbXQgKHt4eCkgYmVyOg0KNGYyYzhhNTggY29ubj0xMDAw IG9wPTE6IGJhY2stcmVsYXkgZm9yIEROPSJkYz1jaGFsbWVycyxkYz1zZSIgd291 bGQgY2FsbCBzZWxmLg0KNGYyYzhhNTggPT0+IHRyYW5zbHVjZW50X3NlYXJjaF9j YjogZGM9Y2hhbG1lcnMsZGM9c2UNCjRmMmM4YTU4ID09PiByZXdyaXRlX2NvbnRl eHRfYXBwbHkgW2RlcHRoPTFdIHN0cmluZz0nZGM9Y2hhbG1lcnMsZGM9c2UnDQo0 ZjJjOGE1OCA9PT4gcmV3cml0ZV9ydWxlX2FwcGx5IHJ1bGU9JygoLispLCk/ZGM9 Y2hhbG1lcnMsWyBdP2RjPXNlJCcgc3RyaW5nPSdkYz1jaGFsbWVycyxkYz1zZScg WzEgcGFzcyhlcyldDQo0ZjJjOGE1OCA9PT4gcmV3cml0ZV9jb250ZXh0X2FwcGx5 IFtkZXB0aD0xXSByZXM9ezAsJ2RjPXJzcyxkYz1jaGFsbWVycyxkYz1zZSd9DQo0 ZjJjOGE1OCBbcnddIHNlYXJjaEROOiAiZGM9Y2hhbG1lcnMsZGM9c2UiIC0+ICJk Yz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2UiDQo0ZjJjOGE1OCA+Pj4gZG5Ob3JtYWxp emU6IDxkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2U+DQo9PiBsZGFwX2J2MmRuKGRj PXJzcyxkYz1jaGFsbWVycyxkYz1zZSwwKQ0KPD0gbGRhcF9idjJkbihkYz1yc3Ms ZGM9Y2hhbG1lcnMsZGM9c2UpPTAgDQo9PiBsZGFwX2RuMmJ2KDI3MikNCjw9IGxk YXBfZG4yYnYoZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlKT0wIA0KNGYyYzhhNTgg PDw8IGRuTm9ybWFsaXplOiA8ZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlPg0KNGYy YzhhNTggPT4gYmRiX2VudHJ5X2dldDogbmRuOiAiZGM9cnNzLGRjPWNoYWxtZXJz LGRjPXNlIg0KNGYyYzhhNTggPT4gYmRiX2VudHJ5X2dldDogb2M6ICIobnVsbCki LCBhdDogIihudWxsKSINCjRmMmM4YTU4IGJkYl9kbjJlbnRyeSgiZGM9cnNzLGRj PWNoYWxtZXJzLGRjPXNlIikNCjRmMmM4YTU4ID0+IGhkYl9kbjJpZCgiZGM9cnNz LGRjPWNoYWxtZXJzLGRjPXNlIikNCjRmMmM4YTU4IDw9IGhkYl9kbjJpZDogZ290 IGlkPTB4MQ0KNGYyYzhhNTggZW50cnlfZGVjb2RlOiAiIg0KNGYyYzhhNTggPD0g ZW50cnlfZGVjb2RlKCkNCjRmMmM4YTU4IGJkYl9lbnRyeV9nZXQ6IHJjPTANCjRm MmM4YTU4ID09PiByZXdyaXRlX2NvbnRleHRfYXBwbHkgW2RlcHRoPTFdIHN0cmlu Zz0nZGM9cnNzLGRjPWNoYWxtZXJzLGRjPXNlJw0KNGYyYzhhNTggPT0+IHJld3Jp dGVfcnVsZV9hcHBseSBydWxlPScoKC4rKSwpP2RjPXJzcyxbIF0/ZGM9Y2hhbG1l cnMsWyBdP2RjPXNlJCcgc3RyaW5nPSdkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2Un IFsxIHBhc3MoZXMpXQ0KNGYyYzhhNTggPT0+IHJld3JpdGVfY29udGV4dF9hcHBs eSBbZGVwdGg9MV0gcmVzPXswLCdkYz1jaGFsbWVycyxkYz1zZSd9DQo0ZjJjOGE1 OCBbcnddIHNlYXJjaEVudHJ5RE46ICJkYz1yc3MsZGM9Y2hhbG1lcnMsZGM9c2Ui IC0+ICJkYz1jaGFsbWVycyxkYz1zZSINCjRmMmM4YTU4ID4+PiBkblByZXR0eU5v cm1hbDogPGRjPWNoYWxtZXJzLGRjPXNlPg0KPT4gbGRhcF9idjJkbihkYz1jaGFs bWVycyxkYz1zZSwwKQ0KPD0gbGRhcF9idjJkbihkYz1jaGFsbWVycyxkYz1zZSk9 MCANCj0+IGxkYXBfZG4yYnYoMjcyKQ0KPD0gbGRhcF9kbjJidihkYz1jaGFsbWVy cyxkYz1zZSk9MCANCj0+IGxkYXBfZG4yYnYoMjcyKQ0KPD0gbGRhcF9kbjJidihk Yz1jaGFsbWVycyxkYz1zZSk9MCANCjRmMmM4YTU4IDw8PCBkblByZXR0eU5vcm1h bDogPGRjPWNoYWxtZXJzLGRjPXNlPiwgPGRjPWNoYWxtZXJzLGRjPXNlPg0Kc2xh cGQ6IGF0dHIuYzoyMzY6IGF0dHJfZHVwMjogQXNzZXJ0aW9uIGBqIDwgaScgZmFp bGVkLg0KQWJvcnRlZA0K ------------jL0Q7OrKgMl1NhGUUvXpqG--

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by hyc＠symas.com 03 Feb '12

03 Feb '12

mattias(a)centaurix.com wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the error >> that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. OK, we need to know exactly what the difference is between the ldapsearch query and the browser query. Can you please run slapd -d7 and record first the ldapsearch query and then the browser query and post the output for each of those? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ~*~ [spam] Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Saturday, February 04, 2012 12:47 AM +0100 Mattias Andersson <mattias(a)centaurix.com> wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the >> error that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. Thanks for the confirmation, unfortunate that patch didn't work. Investigation will continue. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson <mattias(a)centaurix.com> wrote: > On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded > the current source from RE24 (snapshot), but I'm still getting the error > that I reported initially: I can confirm that the source does indeed include the patch, so the patch did not fix the problem. Mattias

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com >>> wrote: >>> >>>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: >>>> >>>>> Mattias Andersson wrote: >>>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> >>>>>> wrote: >>>>>> >>>>>>> Please provide a full gdb backtrace from the assertion failure. >>>>>>> I've >>>>>>> reproduced this configuration locally but see no crash using >>>>>>> ldapsearch. >>>>>>> I don't have the Softerra browser. >>>>>> >>>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>>> >>>>> Please see if the attached patch alters the behavior. Thanks. >>>> >>>> I'm getting an error that MozNSS is not found when I run ./configure. >>>> >>>> Mattias >>> >>> Hi Mattias, >>> >>> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 >>> if >>> possible. >> >> Ok, I didn't apply the patch yet, but now I'm getting a different error >> than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package >> repository): >> >> cornelian build_unix # /usr/local/libexec/slapd -d 256 -f >> /etc/ldap/slapd.conf >> 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ > > Why are you running 2.4.28? I specifically said to download the current > source from RE24, which at this time includes the patch for your issue. > When you rebuild, you must replace all the openldap packages, including > the OpenLDAP libraries, not just the slapd binary, etc. Ok, I downloaded the current source from RE24 (snapshot), but I'm still getting the error that I reported initially: cornelian openldap-ad04676 # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c6fe0 @(#) $OpenLDAP: slapd 2.4.29 (Feb 4 2012 00:34:39) $ root@cornelian:/root/openldap/openldap-ad04676/servers/slapd 4f2c6fe0 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c6fe0 slapd starting 4f2c6fe7 conn=1000 fd=12 ACCEPT from IP=83.185.96.215:52240 (IP=0.0.0.0:389) 4f2c6fe7 conn=1000 op=0 BIND dn="" method=128 4f2c6fe7 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c6fe7 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=0 deref=0 filter="(objectClass=*)" 4f2c6fe7 conn=1000 op=1 SRCH attr=1.1 4f2c6fe7 conn=1000 op=1: back-relay for DN="dc=chalmers,dc=se" would call self. slapd: attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted Mattias

1 0

Re: (ITS#7151) slapd segfaults when terminated
by hyc＠symas.com 03 Feb '12

03 Feb '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.29 - git ad04676 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.165.68.229) > > > I'm getting a slapd segfault when the server is being terminated. Looks like your libsasl is linked to a different libldap. The backtrace you provided shows source line numbers that have no code in git ad04676. This does not appear to be an OpenLDAP bug. You should probably find out which SASL plugin was being unloaded when this crash occurred. Seems to be a bad SASL build, actually. Closing this ITS. > ^C4f2c5f43 daemon: shutdown requested and initiated. > 4f2c5f43 daemon: closing 7 > 4f2c5f43 daemon: closing 8 > 4f2c5f43 slapd shutdown: waiting for 0 operations/tasks to finish > 4f2c5f43 slapd shutdown: initiated > 4f2c5f43 ====> bdb_cache_release_all > 4f2c5f43 slapd destroy: freeing system resources. > make: *** [run] Segmentation fault > > Used configuration: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /root/re24/server1/run/slapd.args > olcPidFile: /root/re24/server1/run/slapd.pid > > dn: cn=module,cn=config > objectClass: olcModuleList > cn: module > olcModulepath: /usr/lib64/openldap > > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > cn: schema > > include: file:///etc/openldap/schema/core.ldif > > dn: olcDatabase=config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: config > olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c > n=auth" manage by * none > > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: bdb > olcSuffix: dc=redhat,dc=bug > olcRootDN: cn=Manager,dc=redhat,dc=bug > olcRootPW: secret > olcDbDirectory: /root/re24/server1/db > olcDbIndex: objectClass eq,pres > olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub > > Backtrace: > > #0 __GI___libc_free (mem=0x185) at malloc.c:2972 > ar_ptr =<optimized out> > p =<optimized out> > hook = 0 > #1 0x0000555555727d29 in ber_memfree_x (p=0x185, ctx=0x0) at > ../../../libraries/liblber/memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #2 0x00007ffff489220a in ldap_int_destroy_global_options () at > ../../../libraries/libldap/init.c:496 > gopts = 0x5555559bcfc0 > #3 0x00007ffff7df0b1e in _dl_close_worker (map=map@entry=0x555555a811b0) at > dl-close.c:266 > array = 0x7ffff4abe630 > sz = 1 > imap = 0x555555a816c0 > i =<optimized out> > dl_close_state = pending > nsid = 0 > ns = 0x7ffff7ffd000 > any_tls = false > nloaded = 28 > used = '\001'<repeats 24 times>, "\000\000\000\001" > done = '\001'<repeats 24 times>, "\000\000\000\001" > maps = {0x7ffff7ffe2a8, 0x7ffff7ffe838, 0x7ffff7ffa658, 0x7ffff7ffab20, > 0x7ffff7ff3000, 0x7ffff7ff34d0, 0x7ffff7ff3998, 0x7ffff7ff2000, 0x7ffff7ff24c8, > 0x7ffff7ff2990, 0x7ffff7ff1000, 0x7ffff7ff14d0, 0x7ffff7ff1998, 0x7ffff7ff0000, > 0x7ffff7ff04c8, 0x7ffff7ff0990, 0x7ffff7fef000, 0x7ffff7fef4c8, 0x7ffff7fef990, > 0x7ffff7fee000, 0x7ffff7fee528, 0x7ffff7ffd998, 0x7ffff7fed000, 0x555555a48f30, > 0x555555a811b0, 0x555555a816c0, 0x555555a81bd0, 0x555555ac3420} > idx =<optimized out> > done_index =<optimized out> > do_audit = false > unload_any =<optimized out> > scope_mem_left =<optimized out> > unload_global =<optimized out> > first_loaded =<optimized out> > r =<optimized out> > tls_free_start =<optimized out> > tls_free_end =<optimized out> > #4 0x00007ffff7df151e in _dl_close (_map=0x555555a811b0) at dl-close.c:770 > map = 0x555555a811b0 > #5 0x00007ffff7debb66 in _dl_catch_error (objname=0x555555a81160, > errstring=0x555555a81168, mallocedp=0x555555a81158, operate=0x7ffff55660d0 > <dlclose_doit>, args=0x555555a811b0) at dl-error.c:178 > errcode = 0 > old = 0x0 > c = {objname = 0x7ffff76100d8 "X\a", errstring = 0x0, malloced = 251, > env = {{__jmpbuf = {93824997658960, -5310358512699590611, 93824997659056, > 140737488348192, 0, 0, -5310372595880576979, -5310355285852702675}, > __mask_was_saved = -142437680, __saved_mask = {__val = {0, 140737488348192, 0, > 0, 93824997688544, 140737351954868, 5, 0, 4116075984, 140737351954868, > 93824997690256, 93824997688544, 140737345918272, 140737351980421, 0, > 93824997571648}}}}} > catchp = 0x7ffff7fe9738 > #6 0x00007ffff556662c in _dlerror_run (operate=operate@entry=0x7ffff55660d0 > <dlclose_doit>, args=0x555555a811b0) at dlerror.c:164 > result = 0x555555a81150 > #7 0x00007ffff55660ff in __dlclose (handle=<optimized out>) at dlclose.c:48 > No locals. > #8 0x00007ffff76220e1 in _sasl_done_with_plugins () at dlopen.c:541 > libptr = 0x555555a81130 > libptr_next = 0x0 > #9 0x00007ffff7619ffb in sasl_done () at common.c:674 > No locals. > #10 0x0000555555624d25 in slap_sasl_destroy () at > ../../../servers/slapd/sasl.c:1190 > No locals. > #11 0x00005555555eebf0 in slap_destroy () at ../../../servers/slapd/init.c:249 > rc = 0 > #12 0x000055555558129f in main (argc=6, argv=0x7fffffffe428) at > ../../../servers/slapd/main.c:1033 > i = 6 > no_detach = 1 > rc = 0 > urls = 0x555555a480b0 "ldap://ldapserver1.redhat.bug:1389 > ldaps://ldapserver1.redhat.bug:1636" > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > pid = 32767 > waitfds = {-166376544, 32767} > g_argc = 6 > g_argv = 0x7fffffffe428 > configfile = 0x0 > configdir = 0x555555a48090 "slapd.d" > serverName = 0x7fffffffe6bd "slapd" > serverMode = 1 > scp = 0x0 > scp_entry = 0x0 > debug_unknowns = 0x0 > syslog_unknowns = 0x0 > serverNamePrefix = 0x55555572b818 "" > l = 1 > slapd_pid_file_unlink = 1 > slapd_args_file_unlink = 1 > firstopt = 0 > __PRETTY_FUNCTION__ = "main" > Id Target Id Frame > * 1 Thread 0x7ffff7fe9740 (LWP 15364) "slapd" 0x000055555558129f in main > (argc=6, argv=0x7fffffffe428) at ../../../servers/slapd/main.c:1033 > > OpenLDAP from tag OPENLDAP_REL_ENG_2_4_29 > (ad0467699d9054e32a5530e93e28bd4194344d3d), probably also present in previous > versions. > > Fedora 17 x86_64, cyrus-sasl-2.1.23-28.fc17.x86_64 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson <mattias(a)centaurix.com> wrote: > On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com >> wrote: >> >>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: >>> >>>> Mattias Andersson wrote: >>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>>>> >>>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>>> reproduced this configuration locally but see no crash using >>>>>> ldapsearch. >>>>>> I don't have the Softerra browser. >>>>> >>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>> >>>> Please see if the attached patch alters the behavior. Thanks. >>> >>> I'm getting an error that MozNSS is not found when I run ./configure. >>> >>> Mattias >> >> Hi Mattias, >> >> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if >> possible. > > Ok, I didn't apply the patch yet, but now I'm getting a different error > than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package > repository): > > cornelian build_unix # /usr/local/libexec/slapd -d 256 -f > /etc/ldap/slapd.conf > 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ Why are you running 2.4.28? I specifically said to download the current source from RE24, which at this time includes the patch for your issue. When you rebuild, you must replace all the openldap packages, including the OpenLDAP libraries, not just the slapd binary, etc. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7151) slapd segfaults when terminated
by jvcelak＠redhat.com 03 Feb '12

03 Feb '12

Full_Name: Jan Vcelak Version: 2.4.29 - git ad04676 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.165.68.229) I'm getting a slapd segfault when the server is being terminated. ^C4f2c5f43 daemon: shutdown requested and initiated. 4f2c5f43 daemon: closing 7 4f2c5f43 daemon: closing 8 4f2c5f43 slapd shutdown: waiting for 0 operations/tasks to finish 4f2c5f43 slapd shutdown: initiated 4f2c5f43 ====> bdb_cache_release_all 4f2c5f43 slapd destroy: freeing system resources. make: *** [run] Segmentation fault Used configuration: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /root/re24/server1/run/slapd.args olcPidFile: /root/re24/server1/run/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib64/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=redhat,dc=bug olcRootDN: cn=Manager,dc=redhat,dc=bug olcRootPW: secret olcDbDirectory: /root/re24/server1/db olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub Backtrace: #0 __GI___libc_free (mem=0x185) at malloc.c:2972 ar_ptr = <optimized out> p = <optimized out> hook = 0 #1 0x0000555555727d29 in ber_memfree_x (p=0x185, ctx=0x0) at ../../../libraries/liblber/memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x00007ffff489220a in ldap_int_destroy_global_options () at ../../../libraries/libldap/init.c:496 gopts = 0x5555559bcfc0 #3 0x00007ffff7df0b1e in _dl_close_worker (map=map@entry=0x555555a811b0) at dl-close.c:266 array = 0x7ffff4abe630 sz = 1 imap = 0x555555a816c0 i = <optimized out> dl_close_state = pending nsid = 0 ns = 0x7ffff7ffd000 any_tls = false nloaded = 28 used = '\001' <repeats 24 times>, "\000\000\000\001" done = '\001' <repeats 24 times>, "\000\000\000\001" maps = {0x7ffff7ffe2a8, 0x7ffff7ffe838, 0x7ffff7ffa658, 0x7ffff7ffab20, 0x7ffff7ff3000, 0x7ffff7ff34d0, 0x7ffff7ff3998, 0x7ffff7ff2000, 0x7ffff7ff24c8, 0x7ffff7ff2990, 0x7ffff7ff1000, 0x7ffff7ff14d0, 0x7ffff7ff1998, 0x7ffff7ff0000, 0x7ffff7ff04c8, 0x7ffff7ff0990, 0x7ffff7fef000, 0x7ffff7fef4c8, 0x7ffff7fef990, 0x7ffff7fee000, 0x7ffff7fee528, 0x7ffff7ffd998, 0x7ffff7fed000, 0x555555a48f30, 0x555555a811b0, 0x555555a816c0, 0x555555a81bd0, 0x555555ac3420} idx = <optimized out> done_index = <optimized out> do_audit = false unload_any = <optimized out> scope_mem_left = <optimized out> unload_global = <optimized out> first_loaded = <optimized out> r = <optimized out> tls_free_start = <optimized out> tls_free_end = <optimized out> #4 0x00007ffff7df151e in _dl_close (_map=0x555555a811b0) at dl-close.c:770 map = 0x555555a811b0 #5 0x00007ffff7debb66 in _dl_catch_error (objname=0x555555a81160, errstring=0x555555a81168, mallocedp=0x555555a81158, operate=0x7ffff55660d0 <dlclose_doit>, args=0x555555a811b0) at dl-error.c:178 errcode = 0 old = 0x0 c = {objname = 0x7ffff76100d8 "X\a", errstring = 0x0, malloced = 251, env = {{__jmpbuf = {93824997658960, -5310358512699590611, 93824997659056, 140737488348192, 0, 0, -5310372595880576979, -5310355285852702675}, __mask_was_saved = -142437680, __saved_mask = {__val = {0, 140737488348192, 0, 0, 93824997688544, 140737351954868, 5, 0, 4116075984, 140737351954868, 93824997690256, 93824997688544, 140737345918272, 140737351980421, 0, 93824997571648}}}}} catchp = 0x7ffff7fe9738 #6 0x00007ffff556662c in _dlerror_run (operate=operate@entry=0x7ffff55660d0 <dlclose_doit>, args=0x555555a811b0) at dlerror.c:164 result = 0x555555a81150 #7 0x00007ffff55660ff in __dlclose (handle=<optimized out>) at dlclose.c:48 No locals. #8 0x00007ffff76220e1 in _sasl_done_with_plugins () at dlopen.c:541 libptr = 0x555555a81130 libptr_next = 0x0 #9 0x00007ffff7619ffb in sasl_done () at common.c:674 No locals. #10 0x0000555555624d25 in slap_sasl_destroy () at ../../../servers/slapd/sasl.c:1190 No locals. #11 0x00005555555eebf0 in slap_destroy () at ../../../servers/slapd/init.c:249 rc = 0 #12 0x000055555558129f in main (argc=6, argv=0x7fffffffe428) at ../../../servers/slapd/main.c:1033 i = 6 no_detach = 1 rc = 0 urls = 0x555555a480b0 "ldap://ldapserver1.redhat.bug:1389 ldaps://ldapserver1.redhat.bug:1636" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32767 waitfds = {-166376544, 32767} g_argc = 6 g_argv = 0x7fffffffe428 configfile = 0x0 configdir = 0x555555a48090 "slapd.d" serverName = 0x7fffffffe6bd "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x55555572b818 "" l = 1 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" Id Target Id Frame * 1 Thread 0x7ffff7fe9740 (LWP 15364) "slapd" 0x000055555558129f in main (argc=6, argv=0x7fffffffe428) at ../../../servers/slapd/main.c:1033 OpenLDAP from tag OPENLDAP_REL_ENG_2_4_29 (ad0467699d9054e32a5530e93e28bd4194344d3d), probably also present in previous versions. Fedora 17 x86_64, cyrus-sasl-2.1.23-28.fc17.x86_64

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com > wrote: > >> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: >> >>> Mattias Andersson wrote: >>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>>> >>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>> reproduced this configuration locally but see no crash using >>>>> ldapsearch. >>>>> I don't have the Softerra browser. >>>> >>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>> >>> Please see if the attached patch alters the behavior. Thanks. >> >> I'm getting an error that MozNSS is not found when I run ./configure. >> >> Mattias > > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. Ok, I didn't apply the patch yet, but now I'm getting a different error than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package repository): cornelian build_unix # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ root@cornelian:/root/openldap/openldap-2.4.28/servers/slapd 4f2c5a69 hdb_db_open: database "dc=rss,dc=chalmers,dc=se": unclean shutdown detected; attempting recovery. 4f2c5a69 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c5a69 slapd starting 4f2c5ac2 conn=1000 fd=12 ACCEPT from IP=127.0.0.1:39354 (IP=0.0.0.0:389) 4f2c5ac2 conn=1000 op=0 BIND dn="" method=128 4f2c5ac2 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c5ac2 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0 filter="(objectClass=*)" 4f2c5ac2 conn=1000 op=1 SRCH attr=1.1 /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_get_message_ber This error also happens with ldapsearch. Mattias

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 22:24:36 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 03, 2012 10:19 PM +0100 Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> I'm having some problems with the BDB library: >> >> 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected >> Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January >> 28, 2011) > > You built against BDB 5.1.29, but you have BDB 5.1.25 installed. This > would definitely happen if one system was updated when the other was not. Actually I did install BDB 5.1.29, but probably I need to adjust some library path or change a symlink. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. I'm having some problems with the BDB library: 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January 28, 2011) I'll see if I can figure it out. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. > > Mattias Hi Mattias, Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if possible. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Friday, February 03, 2012 10:03 AM +0100 David Coutadeur <david.coutadeur(a)linagora.com> wrote: > > That was my first try. > I have used the option --enable-debug in the configure command, which > seems to produce AC_CFLAGS = -g -O2, itself reinjected in CFLAGS = > $(AC_CFLAGS) $(DEFS) in the Makefile. > > However this has lead to an unusable stacktrace. Thus I preferred using > the binary file (with debug symbols) pointed by > openldap-src/servers/slapd : > /opt/openldap-src/servers/slapd/.libs/lt-slapd > This gave me the stacktrace I first sent. By default, "make install" will strip the binaries of the debugging symbols. You have to prevent that by running it as: make install STRIP="" --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

Thanks. A fix for this is now in git master (5584e5b) > Le 03/02/2012 18:15, Howard Chu a écrit : >> david.coutadeur(a)linagora.com wrote: >>> I have reproduced the bug with a fresh new HEAD version yesterday, >>> including : >>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >> >> Can you include a "bt full" gdb backtrace on this? >> >>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>> dcoutadeur(a)linagora.com wrote: >>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>>> version) >>>> >>>> Which exact git version? Did you build RE24 from git already containing >>>> the fix for ITS#7113 (dup of ITS#6928)? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

Here it is. Program terminated with signal 11, Segmentation fault. #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 2118 for ( m2 = mt->mt_mods; m2->mi_next != mi; (gdb) bt full #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 m2 = 0x0 mt = 0x89cd028 mtdummy = {mt_mods = 0x889e468, mt_tail = 0x89b2fe0, mt_op = 0x89b2fe0, mt_mutex = {__data = {__lock = 48, __count = 2358971544, __owner = 135135137, __kind = 144388064, __nusers = 2358972680, {__spins = 16843008, __list = {__next = 0x1010100}}}, __size = "0\000\000\000\230\f\233\214\241\377\r\b\340/\233\b\b\021\233\214\000\001\001\001", __align = 48}} mi = 0x8bcae2a0 on = <value optimized out> si = 0x87cbfa0 cb = 0x8bcae258 opc = 0x8bcae268 have_psearches = 1 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 rc = 144388064 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 oi = 0x87c98a8 on = 0x87cbe98 be = 0x8793c48 db = {bd_info = 0x87cbe98, bd_self = 0x8793c48, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\001\001", '\000' <repeats 12 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x87c93f8, be_nsuffix = 0x8796f70, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0x87c8b30 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0x87c8d40 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0x87961f8 "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x87cbe40, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x889b1a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0x87cc1c8, be_pb = 0x0, be_cf_ocs = 0x8212020, be_private = 0x8793d48, be_next = { stqe_next = 0x87cc050}} cb = {sc_next = 0x0, sc_response = 0x80dfce0 <over_back_response>, sc_cleanup = 0, sc_private = 0x87c98a8} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x8215ca0 textbuf = "\000\000\000\000\210\032\234\b0\033\233\214@q(\000\030\000\000\000\000\000\000\000\"\203%\000\b\241%\000\270\255\234\b\030lv\b\002\000\000\000\250\016\233\214-[\v\b\270\255\234\b\224\016\233\214\001\000\000\000\000\000\000\000\340i\234\b\000\000\000\000\n\000\000\000\001\000\000\000\270\027v\b\n\000\000\000\310\f\234\b\320\032\234\b\030lv\b\270\255\234\b\370\016\233\214O>\t\b\002\000\000\000\030Vt\b\370\016\233\214\261:\t\b@et\bpu\234\b'<\202\000\000\000\000\000\f\000\000\000\227V\235\b\207~\000\000\224\225d\000\300rv\b\300rv\b\370\016\233\214\335Pa\000\000V!\b,I\337\215\030\017\233\214\325\020\b\b\000V!\bpu\234\b\000\000\000\000\270\255\234\b\200H\337\215\000\000\000\000H\017\233\214G\353\a\b\300rv\b\300rv\b\001\000\000\---Type <return> to continue, or q <return> to quit--- 000H\017\233\214\020\000\000\000@I\337\215\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 ber = <value optimized out> last = 0x89d56b1 "" dn = {bv_len = 38, bv_val = 0x89d55d8 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x89ce650 modtail = 0x89becbc tmp = {sml_mod = {sm_desc = 0x80cb2aa, sm_values = 0x89c7570, sm_nvalues = 0x0, sm_numvals = 2358972600, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x89d5697 "userPassword"}}, sml_next = 0x823c27} textbuf = "\000\000\000\000\000\000\000\000X\360\233\b\006\240\031\000\240\261\211\b\000\000\000\000\000\000\000\000@q(\000\000\000\000\000\000\000\000\000\060X\234\b\310\301|\b\000\000\000\000Te\031\000\000\000\000\000@q(\000\364_(\000\220\033\233\214\000\000\000\000\313؛\b\240\375\233\b\370\017\233\214T\213\202\000b\213\202\000;\334\022\000/\000\000\000\313؛\b\b\000\000\000\201\254\031\000\f\020\233\214<\004\023\000\270\020\233\214\312\315\022\000\260 \233\b\313؛\b\b\000\000\000\001\200\255\373\340\060\233\b\340\060\233\b\340\060\233\b\340\060\233\b\356\060\233\b\337\061\233\b\340\060\233\b\337\061\233\b,\000\000\000@q(", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000\060\000\000\000\000\000\000\b", '\000' <repeats 16 times>, "\030X\234\b\000\000\000\000\001\000\000\000\004\000\020\000\350\021\233\214\310\020\233\214" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x807f0c0}, oe_db = 0x0} #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 104 opidx = SLAP_OP_ADD conn = 0xb7efd014 memctx = 0x89b3358 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 s = <value optimized out> #7 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 task = 0x89b2970 work_list = <value optimized out> ctx = {ltu_id = 2358975376, ltu_key = {{ltk_key = 0x8076270, ltk_data = 0x89b3268, ltk_free = 0x8076340 <conn_counter_destroy>}, {ltk_key = 0x80cb0e0, ltk_data = 0x89b3358, ltk_free = 0x80cb110 <slap_sl_mem_destroy>}, {ltk_key = 0x889b1b0, ltk_data = 0x89b78b0, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x808b900, ltk_data = 0x0, ltk_free = 0x808b710 <slap_op_q_destroy>}, {ltk_key = 0x889ebe0, ltk_data = 0x89b9f78, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = <value optimized out> keyslot = 242 hash = 5209330 ---Type <return> to continue, or q <return> to quit--- __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9 0x0020346e in clone () from /lib/libc.so.6 No symbol table info available. Le 03/02/2012 18:15, Howard Chu a écrit : > david.coutadeur(a)linagora.com wrote: >> I have reproduced the bug with a fresh new HEAD version yesterday, >> including : >> 02/02/2012 Howard Chu ITS#7146 fix prev commit > > Can you include a "bt full" gdb backtrace on this? > >> Le 02/02/2012 20:25, Michael Ströder a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>> version) >>> >>> Which exact git version? Did you build RE24 from git already containing >>> the fix for ITS#7113 (dup of ITS#6928)? >

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

david.coutadeur(a)linagora.com wrote: > I have reproduced the bug with a fresh new HEAD version yesterday, > including : > 02/02/2012 Howard Chu ITS#7146 fix prev commit Can you include a "bt full" gdb backtrace on this? > Le 02/02/2012 20:25, Michael Ströder a écrit : >> dcoutadeur(a)linagora.com wrote: >>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>> version) >> >> Which exact git version? Did you build RE24 from git already containing >> the fix for ITS#7113 (dup of ITS#6928)? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

I have reproduced the bug with a fresh new HEAD version yesterday, including : 02/02/2012 Howard Chu ITS#7146 fix prev commit Le 02/02/2012 20:25, Michael Ströder a écrit : > dcoutadeur(a)linagora.com wrote: >> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >> version) > > Which exact git version? Did you build RE24 from git already containing > the fix for ITS#7113 (dup of ITS#6928)? > > Ciao, Michael.

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

That was my first try. I have used the option --enable-debug in the configure command, which seems to produce AC_CFLAGS = -g -O2, itself reinjected in CFLAGS = $(AC_CFLAGS) $(DEFS) in the Makefile. However this has lead to an unusable stacktrace. Thus I preferred using the binary file (with debug symbols) pointed by openldap-src/servers/slapd : /opt/openldap-src/servers/slapd/.libs/lt-slapd This gave me the stacktrace I first sent. I have used /opt/openldap-src/servers/slapd/.libs/slapd instead, and it seems to give a better stacktrace. (joined in this mail) Thank you for your help. Thread 10 (Thread 0xb7f66710 (LWP 32314)): #0 0x006b3402 in __kernel_vsyscall () #1 0x00822a77 in pthread_join () from /lib/libpthread.so.0 #2 0x00615314 in ldap_pvt_thread_join (thread=2623220624, thread_return=0x0) at thr_posix.c:197 #3 0x08071407 in slapd_daemon () at daemon.c:2930 #4 0x0805d421 in main (argc=9, argv=0xbffb3c04) at main.c:1012 Thread 9 (Thread 32325): #0 0x006b3402 in __kernel_vsyscall () #1 0x00203ae6 in epoll_wait () from /lib/libc.so.6 #2 0x0807426c in slapd_daemon_task (ptr=0xbffb3ac8) at daemon.c:2539 #3 0x00821832 in start_thread () from /lib/libpthread.so.0 #4 0x0020346e in clone () from /lib/libc.so.6 Thread 8 (Thread 32326): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b2390, rs=0x8ddb9108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b2390, rs=0x8ddb9108, which=op_modify, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b2390, rs=0x8ddb9108, which=op_modify) at backover.c:723 #6 0x08090926 in fe_op_modify (op=0x89b2390, rs=0x8ddb9108) at modify.c:303 #7 0x080912a7 in do_modify (op=0x89b2390, rs=0x8ddb9108) at modify.c:177 #8 0x0807759d in connection_operation (ctx=0x8ddb91e8, arg_v=0x89b2390) at connection.c:1138 ---Type <return> to continue, or q <return> to quit--- #9 0x08077f6d in connection_read_thread (ctx=0x8ddb91e8, argv=0x23) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 7 (Thread 32327): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b6930, rs=0x8d9b8108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b6930, rs=0x8d9b8108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b6930, rs=0x8d9b8108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b6930, rs=0x8d9b8108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b6930, rs=0x8d9b8108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8d9b81e8, arg_v=0x89b6930) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8d9b81e8, argv=0x20) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 6 (Thread 32328): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b1d50, rs=0x8d5b7108) at syncprov.c:2112 ---Type <return> to continue, or q <return> to quit--- #4 0x080dff34 in overlay_op_walk (op=0x89b1d50, rs=0x8d5b7108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b1d50, rs=0x8d5b7108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b1d50, rs=0x8d5b7108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b1d50, rs=0x8d5b7108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8d5b71e8, arg_v=0x89b1d50) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8d5b71e8, argv=0x2c) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 5 (Thread 32329): #0 0x0019673c in _IO_default_xsputn_internal () from /lib/libc.so.6 #1 0x0016d391 in vfprintf () from /lib/libc.so.6 #2 0x00191514 in vsnprintf () from /lib/libc.so.6 #3 0x0012b79f in lutil_debug (debug=256, level=256, fmt=0x81b2678 "%s BIND dn=\"%s\" mech=%s ssf=0\n") at debug.c:67 #4 0x0809552b in fe_op_bind_success (op=0x89a7320, rs=0x8d1b6108) at bind.c:429 #5 0x08095d04 in fe_op_bind (op=0x89a7320, rs=0x8d1b6108) at bind.c:386 #6 0x0809651c in do_bind (op=0x89a7320, rs=0x8d1b6108) at bind.c:205 #7 0x0807759d in connection_operation (ctx=0x8d1b61e8, arg_v=0x89a7320) at connection.c:1138 #8 0x08077f6d in connection_read_thread (ctx=0x8d1b61e8, argv=0x1b) at connection.c:1274 #9 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #10 0x00821832 in start_thread () from /lib/libpthread.so.0 #11 0x0020346e in clone () from /lib/libc.so.6 Thread 4 (Thread 32392): ---Type <return> to continue, or q <return> to quit--- #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b70d8, rs=0x8c5b0108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b70d8, rs=0x8c5b0108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b70d8, rs=0x8c5b0108, which=op_add) at backover.c:723 #6 0x0807eeb9 in fe_op_add (op=0x89b70d8, rs=0x8c5b0108) at add.c:334 #7 0x0807f7a3 in do_add (op=0x89b70d8, rs=0x8c5b0108) at add.c:194 #8 0x0807759d in connection_operation (ctx=0x8c5b01e8, arg_v=0x89b70d8) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8c5b01e8, argv=0x28) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 3 (Thread 32393): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b3998, rs=0x8c1af108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b3998, rs=0x8c1af108, which=op_modify, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b3998, rs=0x8c1af108, which=op_modify) at backover.c:723 #6 0x08090926 in fe_op_modify (op=0x89b3998, rs=0x8c1af108) at modify.c:303 #7 0x080912a7 in do_modify (op=0x89b3998, rs=0x8c1af108) at modify.c:177 #8 0x0807759d in connection_operation (ctx=0x8c1af1e8, arg_v=0x89b3998) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8c1af1e8, argv=0x2d) at connection.c:1274 ---Type <return> to continue, or q <return> to quit--- #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 2 (Thread 32394): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b2b78, rs=0x8bcad108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b2b78, rs=0x8bcad108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b2b78, rs=0x8bcad108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b2b78, rs=0x8bcad108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b2b78, rs=0x8bcad108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8bcad1e8, arg_v=0x89b2b78) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8bcad1e8, argv=0x21) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 1 (Thread 0x8c9b1b90 (LWP 32391)): #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 ---Type <return> to continue, or q <return> to quit--- #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 #7 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #8 0x00821832 in start_thread () from /lib/libpthread.so.0 #9 0x0020346e in clone () from /lib/libc.so.6 Le 02/02/2012 20:09, Quanah Gibson-Mount a écrit : > --On Thursday, February 02, 2012 4:58 PM +0000 dcoutadeur(a)linagora.com > wrote: > >> Full_Name: dcoutadeur >> Version: 2.4.28 >> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (109.197.176.10) >> > > Please rebuild with debugging symbols (CFLAGS=-g) and update with a > usable stack trace. Thank you. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Feb '12

02 Feb '12

llg(a)portaildulibre.fr wrote: > Le 02/02/2012 20:32, hyc(a)symas.com a écrit : >> jiashun.qian(a)atos.net wrote: >>> Full_Name: Jiashun QIAN >>> Version: 2.4.28 >>> OS: CentOS 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.115.60.180) >>> >>> >>> The backend shell and the backend perl can't handle some binary data. >>> >>> This occurs only with MODIFY because when ADD the binary data is encoded in >>> base64 but not MODIFY. >>> >>> The binary data is truncated when if it contains \0. In fact, data is stored in >>> a linked list of char * and treated as characters. >>> >>> --- >>> servers/slapd/back-perl/modify.c >>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>> --- >>> >>> The type of mods->sm_values[i].bv_val is char*. >>> >>> To handle the binary data, for back-perl, just change another function mXPUSHp, >>> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >>> it's mod->sm_values[i].bv_len. So it will push the total data. >> That is obviously the wrong approach. Since these backends communicate using >> LDIF, binary values should be base64 encoded according to the LDIF rules. > The input LDIF file for ldap_modify contains base64 encoded > usercertificate, but back-perl receives binary data. > This behaviour only occured with modification action : with add action, > certificate is received base64 encoded. Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. >> Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by llg＠portaildulibre.fr 02 Feb '12

02 Feb '12

Le 02/02/2012 20:32, hyc(a)symas.com a écrit : > jiashun.qian(a)atos.net wrote: >> Full_Name: Jiashun QIAN >> Version: 2.4.28 >> OS: CentOS 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.115.60.180) >> >> >> The backend shell and the backend perl can't handle some binary data. >> >> This occurs only with MODIFY because when ADD the binary data is encoded in >> base64 but not MODIFY. >> >> The binary data is truncated when if it contains \0. In fact, data is stored in >> a linked list of char * and treated as characters. >> >> --- >> servers/slapd/back-perl/modify.c >> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >> --- >> >> The type of mods->sm_values[i].bv_val is char*. >> >> To handle the binary data, for back-perl, just change another function mXPUSHp, >> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >> it's mod->sm_values[i].bv_len. So it will push the total data. > That is obviously the wrong approach. Since these backends communicate using > LDIF, binary values should be base64 encoded according to the LDIF rules. The input LDIF file for ldap_modify contains base64 encoded usercertificate, but back-perl receives binary data. This behaviour only occured with modification action : with add action, certificate is received base64 encoded. Llg > > Thanks for the patch, but we can't merge it since the provided solution is wrong. >

1 0

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Feb '12

02 Feb '12

jiashun.qian(a)atos.net wrote: > Full_Name: Jiashun QIAN > Version: 2.4.28 > OS: CentOS 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.115.60.180) > > > The backend shell and the backend perl can't handle some binary data. > > This occurs only with MODIFY because when ADD the binary data is encoded in > base64 but not MODIFY. > > The binary data is truncated when if it contains \0. In fact, data is stored in > a linked list of char * and treated as characters. > > --- > servers/slapd/back-perl/modify.c > XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); > --- > > The type of mods->sm_values[i].bv_val is char*. > > To handle the binary data, for back-perl, just change another function mXPUSHp, > which we can put the exacte length of mod->sm_values[i].bv_val as parameter, > it's mod->sm_values[i].bv_len. So it will push the total data. That is obviously the wrong approach. Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules. Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by michael＠stroeder.com 02 Feb '12

02 Feb '12

dcoutadeur(a)linagora.com wrote: > I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git > version) Which exact git version? Did you build RE24 from git already containing the fix for ITS#7113 (dup of ITS#6928)? Ciao, Michael.

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 02 Feb '12

02 Feb '12

--On Thursday, February 02, 2012 4:58 PM +0000 dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.197.176.10) > Please rebuild with debugging symbols (CFLAGS=-g) and update with a usable stack trace. Thank you. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 02 Feb '12

02 Feb '12

Full_Name: dcoutadeur Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.197.176.10) Hi everybody, I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git version) slapd is shutting down with no message in the logs when I try to do a load benchmark with a soft in C. The test consists in 20 threads doing 100 times these operations in the order : - 1 entry add - 1 modification on this entry - 1 deletion on this entry Of course, some operations ends up with ldap errors, because the entry does not exist, and so on... During the load testing, Openldap is reacting as expected. If I stop the test while it runs, then the bug occurs (nearly systematically) You can check my configuration and the stacktrace here. Thank you in advance for helping. # ---------------------------------------------------------------------------- # Global section # ---------------------------------------------------------------------------- sizelimit 15000 allow bind_v2 password-hash {SSHA} threads 8 loglevel 256 serverID 2 include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf pidfile /opt/openldap/var/run/slapd.pid argsfile /opt/openldap/var/run/slapd.args # ACLs definition (cutted here) ####################################################################### # SSL definitions ####################################################################### # Definition of cert files # --------------------------------- TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database monitor ####################################################################### # suffix dc=example,dc=com # -------------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "dc=example,dc=com" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 60000 dncachesize 60000 idlcachesize 60000 cachefree 100 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext # ---------------------------------------------------------------------------- # REPLICATION definitions # ---------------------------------------------------------------------------- ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=001 provider=ldap://ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # limits # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ####################################################################### # suffix o=edition # ---------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data-edition # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "o=edition" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 50000 dncachesize 50000 idlcachesize 50000 cachefree 100 # ---------------------------------------------------------------------------- # rootdn # ---------------------------------------------------------------------------- # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootdn "cn=Manager,o=edition" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext ####################################################################### # REPLICATION definitions ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=002 provider=ldap://vspar-ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="o=edition" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # Limits for current BDB # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ############################################################### ######################## STACKTRACE ########################### ############################################################### (gdb) thread apply all bt Thread 10 (Thread 32314): #0 0x006b3402 in ?? () #1 0x00822a77 in ?? () #2 0xbffb3a5c in ?? () #3 0x00822930 in ?? () #4 0x9c5b2d90 in ?? () #5 0x00000000 in ?? () Thread 9 (Thread 32325): #0 0x006b3402 in ?? () #1 0x00203ae6 in ?? () #2 0x00000000 in ?? () Thread 8 (Thread 32326): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8ccb5258 in ?? () #5 0x8ddb7cd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8ddb7ca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 7 (Thread 32327): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () ---Type <return> to continue, or q <return> to quit--- #3 0x006152a9 in ?? () #4 0x8cbb4258 in ?? () #5 0x8d9b7e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d9b7e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 6 (Thread 32328): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8c9b2258 in ?? () #5 0x8d5b6e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d5b6e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 5 (Thread 32329): #0 0x0019673c in ?? () #1 0x8d1b4fed in ?? () #2 0x089bfbd0 in ?? () #3 0x00000018 in ?? () #4 0x00000009 in ?? () #5 0x081b2684 in ?? () #6 0x0000000a in ?? () #7 0x8d1b4fed in ?? () #8 0x00285ff4 in ?? () #9 0x081b267a in ?? () #10 0x0000000a in ?? () ---Type <return> to continue, or q <return> to quit--- #11 0x8d1b4e98 in ?? () #12 0x0016d391 in ?? () #13 0x8d1b4ebc in ?? () #14 0x081b267a in ?? () #15 0x0000000a in ?? () #16 0x0012eed5 in ?? () #17 0x00000000 in ?? () Thread 4 (Thread 32392): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b6ab258 in ?? () #5 0x8c5afc98 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c5afc68) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 3 (Thread 32393): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b7ac258 in ?? () #5 0x8c1adcd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c1adca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC ---Type <return> to continue, or q <return> to quit--- Thread 2 (Thread 32394): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b5aa258 in ?? () #5 0x8bcace68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8bcace38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 1 (Thread 32391): #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 #7 0x006145e4 in ?? () #8 0x8c9b11e8 in ?? () #9 0x0000002f in ?? () #10 0x00000000 in ?? ()

1 0

(ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 02 Feb '12

02 Feb '12

Full_Name: Jiashun QIAN Version: 2.4.28 OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.115.60.180) The backend shell and the backend perl can't handle some binary data. This occurs only with MODIFY because when ADD the binary data is encoded in base64 but not MODIFY. The binary data is truncated when if it contains \0. In fact, data is stored in a linked list of char * and treated as characters. --- servers/slapd/back-perl/modify.c XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); --- The type of mods->sm_values[i].bv_val is char*. To handle the binary data, for back-perl, just change another function mXPUSHp, which we can put the exacte length of mod->sm_values[i].bv_val as parameter, it's mod->sm_values[i].bv_len. So it will push the total data. Same problem in servers/slapd/back-shell/modify.c : --- servers/slapd/back-shell/modify.c fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, mod->sm_values[i].bv_val /* binary! */ ); --- To fix this, uses a loop on mod->sm_values[i].bv_len to get all data. *** openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-perl/modify.c 2012-02-02 14:15:37.823838779 +0100 *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 61,67 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! mXPUSHp(mods->sm_values[i].bv_val, mods->sm_values[i].bv_len); } /* Fix delete attrib without value. */ *** openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-shell/modify.c 2012-02-02 14:26:40.609848244 +0100 *************** *** 49,55 **** Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, --- 49,56 ---- Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i,j; ! unsigned char *ptr; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 106,118 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: ", mod->sm_desc->ad_cname.bv_val ); ! ptr = mod->sm_values[i].bv_val; ! for(j=0; j < mod->sm_values[i].bv_len; j++) ! { ! fprintf( wfp, "%c", *ptr++ ); ! } ! fprintf( wfp, "\n" ); } } Special thanks to : Laurent Le Grandois, Cedric Pellerin, Phillipe Prados for the fix

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 02 Feb '12

02 Feb '12

Sven Hartge wrote: > On 02.02.2012 11:25, Howard Chu wrote: >> Sven Hartge wrote: >>> Um 14:47 Uhr am 01.02.12 schrieb Quanah Gibson-Mount: >>> >>>> Could you *please* try the RE24 checkout from GIT rather than 2.4.28? >>>> Thanks. >>>> That is substantially more useful than patching 2.4.28. >>> >>> I'm sorry to report: still segfaults, backtrace is attached. >> >> This patch should take care of that crash. > > Yes, works. Thank you very much! Thanks for the confirmation, committed to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7146) mdb_info.mi_adxs[] overflow
by h.b.furuseth＠usit.uio.no 02 Feb '12

02 Feb '12

Full_Name: Hallvard B Furuseth Version: master: 2e9f1f93c8acf028fffeec3fc8bafd1a19b719b7 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard mdb_info.mi_adxs[] should be a hash table. It is indexed by AttributeDescription.ad_index, which can be > MDB_MAXADS. Currently back-mdb dumps core with 'attributeoptions foo-' in slapd.conf when ldapadding an ldif which does dn: l=e$i,o=adxs objectClass: locality st;foo-$i: bar # optionally: dn: l=e$i,o=adxs changetype: delete for i = 0...66000.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by quanah＠zimbra.com 01 Feb '12

01 Feb '12

--On Wednesday, February 01, 2012 10:27 PM +0000 sven(a)svenhartge.de wrote: > Um 01:00 Uhr am 01.02.12 schrieb Howard Chu: >> Sven Hartge wrote: >>> On 02/01/12 05:56, Howard Chu wrote: >>>> sven(a)svenhartge.de wrote: > >>> > > I get a very good backtrace, but since this backtrace contains >>> > > internal information I am a bit hesitant to attach this backtrace >>> > > to a public bug-report. >>> > >>> > The backtrace you sent shows the crash at a line of code which was >>> > already patched in RE24 due to ITS#7132. I believe this bug is already >>> > fixed. >>> >>> This is good news. Do you have any commit ID so I can try to backport >>> this fix to the version currently in Debian Squeeze? >> >> commit 42faa8393e6cd41a837b526777110b892541773a > > This simple patch applies flawless on 2.4.23 but still segfaults. Will > try on top of 2.4.28 tomorrow, backtraces will follow then, after I > verified my findings. > > > (Reason for trying this on top of 2.4.23 is because this is the version > in Debian Squeeze and I want to provide the DDs with a fix for Squeeze. > I fully understand that is not supported by OpenLDAP.) > Could you *please* try the RE24 checkout from GIT rather than 2.4.28? Thanks. That is substantially more useful than patching 2.4.28. You can check out an tarball of current RE24 with: git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 > openldap-2.4.29.tar Or via the web with: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

Um 01:00 Uhr am 01.02.12 schrieb Howard Chu: > Sven Hartge wrote: >> On 02/01/12 05:56, Howard Chu wrote: >>> sven(a)svenhartge.de wrote: >> > > I get a very good backtrace, but since this backtrace contains internal >> > > information I am a bit hesitant to attach this backtrace to a public >> > > bug-report. >> > >> > The backtrace you sent shows the crash at a line of code which was >> > already patched in RE24 due to ITS#7132. I believe this bug is already >> > fixed. >> >> This is good news. Do you have any commit ID so I can try to backport >> this fix to the version currently in Debian Squeeze? > > commit 42faa8393e6cd41a837b526777110b892541773a This simple patch applies flawless on 2.4.23 but still segfaults. Will try on top of 2.4.28 tomorrow, backtraces will follow then, after I verified my findings. (Reason for trying this on top of 2.4.23 is because this is the version in Debian Squeeze and I want to provide the DDs with a fix for Squeeze. I fully understand that is not supported by OpenLDAP.) Grüße, Sven.

1 0

(ITS#7145) cn=Connection 0,cn=Connections,cn=Monitor received twice
by michael＠stroeder.com 01 Feb '12

01 Feb '12

Full_Name: Version: RE24 22ee28752e3e0d2a6910a22922fc69befd78578a OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.34.231) When querying cn=Monitor there are two entries returned with the same DN cn=Connection 0,cn=Connections,cn=Monitor This is a MMR setup with two nodes.

1 0

Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac＠gmail.com 01 Feb '12

01 Feb '12

I'm sorry, I send my issue to the wrong mailinglist at first (to the bugs list) and then tried to send it to technical twice. It doesnt seem to go through. Do you have any idea which column it is that defines this behaviour? I can't seem to find it..

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 01 Feb '12

01 Feb '12

Sven Hartge wrote: > On 02/01/12 05:56, Howard Chu wrote: >> sven(a)svenhartge.de wrote: > >>> I get a very good backtrace, but since this backtrace contains internal >>> information I am a bit hesitant to attach this backtrace to a public >>> bug-report. >> >> The backtrace you sent shows the crash at a line of code which was >> already patched in RE24 due to ITS#7132. I believe this bug is already >> fixed. > > This is good news. Do you have any commit ID so I can try to backport > this fix to the version currently in Debian Squeeze? commit 42faa8393e6cd41a837b526777110b892541773a -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

On 02/01/12 05:56, Howard Chu wrote: > sven(a)svenhartge.de wrote: >> I get a very good backtrace, but since this backtrace contains internal >> information I am a bit hesitant to attach this backtrace to a public >> bug-report. > > The backtrace you sent shows the crash at a line of code which was > already patched in RE24 due to ITS#7132. I believe this bug is already > fixed. This is good news. Do you have any commit ID so I can try to backport this fix to the version currently in Debian Squeeze? Grüße, Sven.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 31 Jan '12

31 Jan '12

sven(a)svenhartge.de wrote: > Full_Name: Sven Hartge > Version: 2.4.28 > OS: Debian Squeeze > URL: > Submission from: (NULL) (2a01:198:329:1::14) > > > I experience an easy to reproduce and consistent segfault when I setup a slapd > > syncrepl consumer on Squeeze. > > > > This segfault always happens during the replication of the same object, but the > > slapd version in Lenny has no problems with same DIT. > I get a very good backtrace, but since this backtrace contains internal > > information I am a bit hesitant to attach this backtrace to a public bug-report. The backtrace you sent shows the crash at a line of code which was already patched in RE24 due to ITS#7132. I believe this bug is already fixed. > Is there a way to privatly submit this data (backtrace and additional schemas) > > so you can have look at the problem? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 31 Jan '12

31 Jan '12

Full_Name: Sven Hartge Version: 2.4.28 OS: Debian Squeeze URL: Submission from: (NULL) (2a01:198:329:1::14) I experience an easy to reproduce and consistent segfault when I setup a slapd syncrepl consumer on Squeeze. This segfault always happens during the replication of the same object, but the slapd version in Lenny has no problems with same DIT. My oldstable replicas currently run a self-backported version of 2.4.21-1~dvz50+1, but both 2.4.17-2.1~bpo50+1 and 2.4.11-1+lenny2.1 are also fine. 2.4.23-7.2 shows the segfault as all versions up to 2.4.28-1.1 do. Even if I disable all indices and strip my configuration to the bare minimum needed (i.e. self-defined objectclasses and attributes) I get the segfault. I also did da -O0 rebuild of the Debian-2.4.28 and this also segfaults in the same way as 2.4.23 did. I have yet to test the latest RelEng24 from GIT, but I wanted to submit this issue so someone may have a look at the backtrace in parallel to my further tests. I am aware the problem my lie in my self-defined objectclasses and attributes, but then slapd should throw an error and exit instead of replicating 1/3 of the DIT and then segfault. I get a very good backtrace, but since this backtrace contains internal information I am a bit hesitant to attach this backtrace to a public bug-report. Is there a way to privatly submit this data (backtrace and additional schemas) so you can have look at the problem?

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. Are you building the latest source? You can use --with-tls=openssl (or gnutls) to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps you're on a Redhat or Fedora system. If worse comes to worse, you can configure --without-tls just to run this test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 31 Jan '12

31 Jan '12

On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > Mattias Andersson wrote: >> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >> >>> Please provide a full gdb backtrace from the assertion failure. I've >>> reproduced this configuration locally but see no crash using >>> ldapsearch. >>> I don't have the Softerra browser. >> >> Ok, see attachment. The problem is not reproducible with ldapsearch. > > Please see if the attached patch alters the behavior. Thanks. I'm getting an error that MozNSS is not found when I run ./configure. Mattias

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs