openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8696) deadlock with 3-way delta-MMR and syncprov-checkpoint
by ryan＠openldap.org 19 Jul '17

19 Jul '17

Full_Name: Ryan Tandy Version: 2.4.45 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan This is rather similar to ITS#8429 (the deadlock is at the same location), but not enough for me to be sure it's the same. cat > slapd.conf << EOF include /path/to/core.schema include /path/to/cosine.schema serverid 1 ldap://:9001 serverid 2 ldap://:9002 serverid 3 ldap://:9003 database mdb directory db maxsize 104857600 envflags writemap index objectClass,cn,entryCSN,entryUUID,uid eq suffix dc=example,dc=com rootdn cn=root,dc=example,dc=com rootpw secret access to * by * read sizelimit unlimited syncrepl rid=1 provider="ldap://:9001" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncrepl rid=2 provider="ldap://:9002" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncrepl rid=3 provider="ldap://:9003" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" mirrormode on overlay syncprov syncprov-checkpoint 10 1 syncprov-reloadhint TRUE overlay accesslog logdb cn=accesslog logops writes logsuccess true logpurge 07+00:00 01+00:00 database mdb directory accesslog maxsize 104857600 envflags writemap index entryCSN,objectClass,reqEnd,reqResult,reqStart eq suffix cn=accesslog access to * by * read sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE EOF cat > data.ldif << EOF dn: dc=example,dc=com objectClass: domain dn: uid=u0,dc=example,dc=com objectclass: account dn: cn=g0,dc=example,dc=com objectClass: groupOfNames member: EOF Start up all three slapds and get them synced and settled. I also executed no-op modifications on each node to ensure every server had CSNs from all the others. cat > groupmod.ldif << EOF dn: cn=g0,dc=example,dc=com add: member member: uid=u0,dc=example,dc=com dn: cn=g0,dc=example,dc=com delete: member member: uid=u0,dc=example,dc=com EOF Execute the above modification on one node and watch the other two. After a few times, I reliably get one or both nodes hanging. If I disable syncprov-checkpoint, I cannot reproduce the hang. Backtrace from a hung node: Thread 6 (Thread 0x7f77093d0700 (LWP 28817)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f77093d0700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 5 (Thread 0x7f7709bd1700 (LWP 28816)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f7709bd1700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 4 (Thread 0x7f770a3d2700 (LWP 28815)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b993fc8, mutex=0x560c5b993fa0) at thr_posix.c:277 #2 0x0000560c5a9ac942 in ldap_pvt_thread_rmutex_lock (rmutex=0x560c5b993f68, owner=140149249615616) at rmutex.c:129 #3 0x0000560c5a98bd4c in accesslog_op_mod (op=0x7f770a3d14e0, rs=0x7f770a3d1120) at accesslog.c:1994 #4 0x0000560c5a941763 in overlay_op_walk (op=0x7f770a3d14e0, rs=0x7f770a3d1120, which=op_modify, oi=0x560c5b992a00, on=0x560c5b993d20) at backover.c:661 #5 0x0000560c5a941a50 in over_op_func (op=0x7f770a3d14e0, rs=0x7f770a3d1120, which=op_modify) at backover.c:730 #6 0x0000560c5a941b84 in over_op_modify (op=0x7f770a3d14e0, rs=0x7f770a3d1120) at backover.c:769 #7 0x0000560c5a92ef07 in syncrepl_message_to_op (si=0x560c5b992580, op=0x7f770a3d14e0, msg=0x7f76f4103bd0) at syncrepl.c:2417 #8 0x0000560c5a929f7e in do_syncrep2 (op=0x7f770a3d14e0, si=0x560c5b992580) at syncrepl.c:1014 #9 0x0000560c5a92c160 in do_syncrepl (ctx=0x7f770a3d1c10, arg=0x560c5b992980) at syncrepl.c:1565 #10 0x0000560c5a8b11cd in connection_read_thread (ctx=0x7f770a3d1c10, argv=0xc) at connection.c:1296 #11 0x0000560c5a9ade15 in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:696 #12 0x00007f7718a4a494 in start_thread (arg=0x7f770a3d2700) at pthread_create.c:333 #13 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 3 (Thread 0x7f770abd3700 (LWP 28814)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f770abd3700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 2 (Thread 0x7f770b3d4700 (LWP 28813)): #0 0x00007f771878d083 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 #1 0x0000560c5a8ac6b3 in slapd_daemon_task (ptr=0x560c5bd176e0) at daemon.c:2539 #2 0x00007f7718a4a494 in start_thread (arg=0x7f770b3d4700) at pthread_create.c:333 #3 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 1 (Thread 0x7f7719293400 (LWP 28812)): #0 0x00007f7718a4b6cd in pthread_join (threadid=140149266401024, thread_return=0x0) at pthread_join.c:90 #1 0x0000560c5a9af2f8 in ldap_pvt_thread_join (thread=140149266401024, thread_return=0x0) at thr_posix.c:197 #2 0x0000560c5a8ad99c in slapd_daemon () at daemon.c:2932 #3 0x0000560c5a88c105 in main (argc=8, argv=0x7ffd119da7b8) at main.c:1017

1 0

(ITS#8695) _sleep is deprecated
by quanah＠openldap.org 19 Jul '17

19 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows 10 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When building OpenLDAP, we find: C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c: In function 'do_read': C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:384:11: warning: '_sleep' is deprecated [-Wdeprecated-declarations] sleep( delay ); ^~~~~ In file included from C:/msys64/home/build/sold-master/openldap/include/ac/stdlib.h:26:0, from C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:24: C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:613:24: note: declared here _CRTIMP void __cdecl _sleep(unsigned long _Duration) __MINGW_ATTRIB_DEPRECATED; ^~~~~~ This comes from: include/ac/unistd.h The correct function call is Sleep #ifdef _WIN32 #define sleep Sleep #endif should resolve it.

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 19 Jul '17

19 Jul '17

On Tue, Jul 18, 2017 at 05:27:40PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > Using the behaviour above, I have been able to trigger a desync, the > script and testrun directory from it happening are available here: > ftp://ftp.openldap.org/incoming/its8444-desync.tgz It's super easy to reproduce the desync when upping MMR to 6 in that script even without memberof (no process re-nicing necessary actually). --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8694) Windows builds fail to install event information
by quanah＠symas.com 18 Jul '17

18 Jul '17

--On Tuesday, July 18, 2017 5:15 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Running "slapd.exe install" is supposed to add the event information in > windows for startup/shutdown (1280/1281). However, this broke at some > point, and no longer provides that information. This causes the event > viewer in Windows to complain that the installation may be corrupt. Windows 10 and Windows 2012 both show this behavior. I don't have anything older than that to test against yet. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 18 Jul '17

18 Jul '17

On Thu, Jun 08, 2017 at 06:36:02PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > A more self-contained log of the same issue, available at > ftp://ftp.openldap.org/incoming/its8444.log >=20 > (line numbers below are against current master, commit > 91f4d3a6b75e73bf4ea498e83e2e4cb4e7a320e0) >=20 > There are some things that occur in all the failures I have seen so far= : > - the server that received the operation (#1) sends the accesslog entry > with no CSN in the cookie, then another provider (#2) picks up this > message and relays it to its consumers, this one with a CSN in the > cookie > - a consumer picks up these two in short succession, in the log above, > processing of the one from #2 is finished first (they are being > processed concurrently) >=20 > Usually, once one of them gets processed, the new CSN should be noted > and the other threads should just skip it (syncrepl.c:943 and onwards). > In this one, having no CSN in the cookie seems to allow both to process > so far as to run syncrepl_message_to_op(), and one of them will then > inevitably fail to add the entry. >=20 > I don't understand yet why server #1 sends the operations without a CSN > in the cookie and (especially if I reorder the overlays to set up > memberof last), the race goes the other way around and the operation to > fail is the one from server #2. >=20 > My take on it was that in a delta-sync environment all entries would be > passed with a new CSN and that should end up in the cookie, allowing > syncrepl.c:986 to do its job. Using the behaviour above, I have been able to trigger a desync, the script and testrun directory from it happening are available here: ftp://ftp.openldap.org/incoming/its8444-desync.tgz In srv3, looking at cn=3Daccesslog, we can see that the increment by 2 ha= s been applied (and logged) twice with the same entryCSN, as: reqStart=3D20170718155142.000007Z,cn=3Daccesslog reqStart=3D20170718155142.000009Z,cn=3Daccesslog also seen in the log around those two DNs above. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8694) Windows builds fail to install event information
by quanah＠openldap.org 18 Jul '17

18 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Running "slapd.exe install" is supposed to add the event information in windows for startup/shutdown (1280/1281). However, this broke at some point, and no longer provides that information. This causes the event viewer in Windows to complain that the installation may be corrupt.

1 0

Re: (ITS#8472) slapd killed after ldapadd
by hyc＠symas.com 14 Jul '17

14 Jul '17

ondra(a)mistotebe.net wrote: > On Fri, Jul 14, 2017 at 09:02:18AM +0000, russell(a)samknows.com wrote: >> 59687dbf ch_calloc of 1 elems of 0 bytes failed >> slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion >> `0' failed. >> Aborted > > If no indexes remain, mdb_attr_dbs_open calls ch_calloc(1, 0), but > ch_malloc/ch_calloc do not expect that. > > I'd fix ch_calloc/ch_malloc, but depends whether that's the right thing > to do, is it intentional to assert when a zero size is requested? Yes. > ber_memalloc has an assert there if LDAP_MEMORY_DEBUG has the second bit > set. Hallvard, Howard? > > If it's fine to change the ch_ functions, then a patch is available at > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170714-ITS-8472.patch No. In this case, back-mdb never expects the number of indexed attributes to be zero. (At the least, objectclass must always have an equality index.) back-mdb can be patched to avoid this particular crash. But as a rule, you're expected to make all changes to the index config in a single Modify op. Not delete all the indices in one operation, and then define new indices in a new operation. -- -- 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#8472) slapd killed after ldapadd
by ondra＠mistotebe.net 14 Jul '17

14 Jul '17

On Fri, Jul 14, 2017 at 09:02:18AM +0000, russell(a)samknows.com wrote: > 59687dbf ch_calloc of 1 elems of 0 bytes failed > slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion > `0' failed. > Aborted If no indexes remain, mdb_attr_dbs_open calls ch_calloc(1, 0), but ch_malloc/ch_calloc do not expect that. I'd fix ch_calloc/ch_malloc, but depends whether that's the right thing to do, is it intentional to assert when a zero size is requested? ber_memalloc has an assert there if LDAP_MEMORY_DEBUG has the second bit set. Hallvard, Howard? If it's fine to change the ch_ functions, then a patch is available at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170714-ITS-8472.patch -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8472) slapd killed after ldapadd
by russell＠samknows.com 14 Jul '17

14 Jul '17

--001a113c349ed7ce5c0554434d63 Content-Type: text/plain; charset="UTF-8" Hi Support It appears I have just manage to hit the exact same issue as Dominik here. I have attached a back-trace for this issue to this email: gdb.txt (though I'm not sure how ITS will handle an attachment - will repost if necessary). --------------------------------------------- Command as it was used/run: --------------------------------------------- ldapmodify -Z -D cn=admin,dc=sk,dc=lan -w[redacted] -H ldapi:/// dn: olcDatabase={1}mdb,cn=config delete: olcDbIndex modifying entry "olcDatabase={1}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) ---------------------------------------------------------------------------------------------- Debug function call trace from the exact moment LDAP aborted: ---------------------------------------------------------------------------------------------- 59687dbf connection_get(22): got connid=1002 59687dbf connection_read(22): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 58 contents: 59687dbf op tag 0x66, time 1500020159 ber_get_next 59687dbf conn=1002 op=2 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 59687dbf >>> dnPrettyNormal: <olcDatabase={1}mdb,cn=config> 59687dbf <<< dnPrettyNormal: <olcDatabase={1}mdb,cn=config>, <olcDatabase={1}mdb,cn=config> 59687dbf >>> dnNormalize: <cn=sysadmin,ou=groups,dc=sk,dc=lan> 59687dbf <<< dnNormalize: <cn=sysadmin,ou=groups,dc=sk,dc=lan> 59687dbf mdb_dn2entry("cn=sysadmin,ou=groups,dc=sk,dc=lan") 59687dbf => mdb_dn2id("cn=sysadmin,ou=groups,dc=sk,dc=lan") 59687dbf <= mdb_dn2id: got id=0xf 59687dbf => mdb_entry_decode: 59687dbf <= mdb_entry_decode 59687dbf mdb_entry_get: rc=0 59687dbf >>> dnNormalize: <cn=sys-replication,ou=system,dc=sk,dc=lan> 59687dbf <<< dnNormalize: <cn=sys-replication,ou=system,dc=sk,dc=lan> 59687dbf mdb_dn2entry("cn=sys-replication,ou=system,dc=sk,dc=lan") 59687dbf => mdb_dn2id("cn=sys-replication,ou=system,dc=sk,dc=lan") 59687dbf <= mdb_dn2id: got id=0x9 59687dbf => mdb_entry_decode: 59687dbf <= mdb_entry_decode 59687dbf mdb_entry_get: rc=16 59687dbf syncprov_matchops: sid 002 fscope 1 rc 6 59687dbf oc_check_required entry (olcDatabase={1}mdb,cn=config), objectClass "olcMdbConfig" 59687dbf oc_check_allowed type "objectClass" 59687dbf oc_check_allowed type "olcDatabase" 59687dbf oc_check_allowed type "olcDbDirectory" 59687dbf oc_check_allowed type "olcSuffix" 59687dbf oc_check_allowed type "olcAccess" 59687dbf oc_check_allowed type "olcLastMod" 59687dbf oc_check_allowed type "olcLimits" 59687dbf oc_check_allowed type "olcRootDN" 59687dbf oc_check_allowed type "olcRootPW" 59687dbf oc_check_allowed type "olcSyncrepl" 59687dbf oc_check_allowed type "olcMirrorMode" 59687dbf oc_check_allowed type "olcDbCheckpoint" 59687dbf oc_check_allowed type "olcDbMaxSize" 59687dbf oc_check_allowed type "structuralObjectClass" 59687dbf oc_check_allowed type "entryUUID" 59687dbf oc_check_allowed type "creatorsName" 59687dbf oc_check_allowed type "createTimestamp" 59687dbf oc_check_allowed type "entryCSN" 59687dbf oc_check_allowed type "modifiersName" 59687dbf oc_check_allowed type "modifyTimestamp" 59687dbf ch_calloc of 1 elems of 0 bytes failed slapd: ../../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion `0' failed. Aborted ---------------------- Exact Version: ---------------------- @(#) $OpenLDAP: slapd (Ubuntu) (May 30 2017 19:20:53) $ buildd@lgw01-18:/build/openldap-JXEADB/openldap-2.4.42+dfsg/debian/build/servers/slapd Hope this all helps to diagnose the issue and get a fix out for it. I appreciate that the version I have is not the latest, but I have seen nothing in the Changelogs of the latest versions to suggest that a newer version could actually fix this, and besides, Dominik experienced the issue in a newer release already (2.4.44) Full_name: Russell Knighton Version: 2.4.42 OS: Ubuntu 16.04 -- Russell Knighton (Systems Administrator) SamKnows Ltd, 135 Park St., London, SE1 9EA --001a113c349ed7ce5c0554434d63 Content-Type: text/plain; charset="UTF-8"; name="gdb.txt" Content-Disposition: attachment; filename="gdb.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j53mlqcx0 IzAgIDB4MDAwMDdmZmZmNjcyZTQyOCBpbiBfX0dJX3JhaXNlIChzaWc9c2lnQGVudHJ5PTYpIGF0 IC4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3JhaXNlLmM6NTQKICAgICAgICByZXN1bHR2YXIg PSAwCiAgICAgICAgcGlkID0gMTEzMTcKICAgICAgICBzZWxmdGlkID0gMTEzMjQKIzEgIDB4MDAw MDdmZmZmNjczMDAyYSBpbiBfX0dJX2Fib3J0ICgpIGF0IGFib3J0LmM6ODkKICAgICAgICBzYXZl X3N0YWdlID0gMgogICAgICAgIGFjdCA9IHtfX3NpZ2FjdGlvbl9oYW5kbGVyID0ge3NhX2hhbmRs ZXIgPSAweDQsIHNhX3NpZ2FjdGlvbiA9IDB4NH0sIHNhX21hc2sgPSB7X192YWwgPSB7MCwgOTM4 MjQ5OTY0NjY5NDQsIDE0MDczNjA5NjE0OTM5MiwgNDcyNDQ2NDAyNTYsIDE0MDczNzM1NDA4NDM1 MiwgOTM4MjQ5OTMxNzEyODYsIDEwNywgOTM4MjQ5OTMxMDAyOTYsIDE0MDczNzM1MjE1OTI0OCwg MCwgMTQwNzM3MzI4NDM2NTQwLCAKICAgICAgICAgICAgICAxNDA3MzczMjk1MzM0NTYsIDE0MDcz NzMyOTU0NzEwNCwgMCwgMTQwNzM3MzI5NTMzNDU2LCA5MzgyNDk5MzE3MTI4Nn19LCBzYV9mbGFn cyA9IC0xMzQyNzA5NzYsIHNhX3Jlc3RvcmVyID0gMHg1NTU1NTU2Mzk3NTZ9CiAgICAgICAgc2ln cyA9IHtfX3ZhbCA9IHszMiwgMCA8cmVwZWF0cyAxNSB0aW1lcz59fQojMiAgMHgwMDAwN2ZmZmY2 NzI2YmQ3IGluIF9fYXNzZXJ0X2ZhaWxfYmFzZSAoZm10PTxvcHRpbWl6ZWQgb3V0PiwgYXNzZXJ0 aW9uPWFzc2VydGlvbkBlbnRyeT0weDU1NTU1NTYzOTc1NiAiMCIsIGZpbGU9ZmlsZUBlbnRyeT0w eDU1NTU1NTYyODE2OCAiLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jaF9tYWxsb2MuYyIsIGxp bmU9bGluZUBlbnRyeT0xMDcsIAogICAgZnVuY3Rpb249ZnVuY3Rpb25AZW50cnk9MHg1NTU1NTU2 MjgyMDggPF9fUFJFVFRZX0ZVTkNUSU9OX18uMTM0MTM+ICJjaF9jYWxsb2MiKSBhdCBhc3NlcnQu Yzo5MgogICAgICAgIHN0ciA9IDB4N2ZmZmEwMTNkNjkwICIiCiAgICAgICAgdG90YWwgPSA0MDk2 CiMzICAweDAwMDA3ZmZmZjY3MjZjODIgaW4gX19HSV9fX2Fzc2VydF9mYWlsIChhc3NlcnRpb249 YXNzZXJ0aW9uQGVudHJ5PTB4NTU1NTU1NjM5NzU2ICIwIiwgZmlsZT1maWxlQGVudHJ5PTB4NTU1 NTU1NjI4MTY4ICIuLi8uLi8uLi8uLi9zZXJ2ZXJzL3NsYXBkL2NoX21hbGxvYy5jIiwgbGluZT1s aW5lQGVudHJ5PTEwNywgCiAgICBmdW5jdGlvbj1mdW5jdGlvbkBlbnRyeT0weDU1NTU1NTYyODIw OCA8X19QUkVUVFlfRlVOQ1RJT05fXy4xMzQxMz4gImNoX2NhbGxvYyIpIGF0IGFzc2VydC5jOjEw MQpObyBsb2NhbHMuCiM0ICAweDAwMDA1NTU1NTU1YTliMTEgaW4gY2hfY2FsbG9jIChuZWxlbT1u ZWxlbUBlbnRyeT0xLCBzaXplPTApIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvY2hfbWFs bG9jLmM6MTA3CiAgICAgICAgc2l6ZSA9IDAKICAgICAgICBuZWxlbSA9IDEKICAgICAgICBuZXcg PSA8b3B0aW1pemVkIG91dD4KIzUgIDB4MDAwMDdmZmZlZjRjODliMyBpbiBtZGJfYXR0cl9kYnNf b3BlbiAoYmU9MHg1NTU1NTU5ZDdjYTAsIHR4MD10eDBAZW50cnk9MHgwLCBjcj1jckBlbnRyeT0w eDdmZmZhZDA0YjNjMCkgYXQgLi4vLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iYWNrLW1kYi9h dHRyLmM6MTEzCiAgICAgICAgbWRiID0gMHg3ZmZmZjdlMWQwMTAKICAgICAgICB0eG4gPSAweDU1 NTU1NWJkMTY5MAogICAgICAgIGRiaXMgPSAweDAKICAgICAgICBpID0gPG9wdGltaXplZCBvdXQ+ CiAgICAgICAgZmxhZ3MgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICByYyA9IDAKIzYgIDB4MDAw MDdmZmZlZjRiY2FhNSBpbiBtZGJfY2ZfY2xlYW51cCAoYz0weDdmZmZhZDA0YTM3MCkgYXQgLi4v Li4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iYWNrLW1kYi9jb25maWcuYzoyNTgKICAgICAgICBt ZGIgPSAweDdmZmZmN2UxZDAxMAogICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiM3ICAweDAw MDA1NTU1NTU1Nzc3MDYgaW4gY29uZmlnX21vZGlmeV9pbnRlcm5hbCAoY2E9MHg3ZmZmYWQwNGEz NzAsIHJzPTxvcHRpbWl6ZWQgb3V0Piwgb3A9PG9wdGltaXplZCBvdXQ+LCBjZT08b3B0aW1pemVk IG91dD4pIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvYmNvbmZpZy5jOjU4MTYKICAgICAg ICBlID0gMHg1NTU1NTU5NGE2ZjgKICAgICAgICBzYXZlX2F0dHJzID0gMHg1NTU1NTU5NjA0NTAK ICAgICAgICBhID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgY29sc3QgPSAweDdmZmZhMDEzMGUx MAogICAgICAgIGkgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBkZWxzID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgcmMgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvY19hdCA9IDxvcHRpbWl6 ZWQgb3V0PgogICAgICAgIG5vY3MgPSAzCiAgICAgICAgcHRyID0gPG9wdGltaXplZCBvdXQ+CiAg ICAgICAgcyA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGRlbHRhaWwgPSAweDAKICAgICAgICBt bCA9IDB4MAojOCAgY29uZmlnX2JhY2tfbW9kaWZ5IChvcD08b3B0aW1pemVkIG91dD4sIHJzPTxv cHRpbWl6ZWQgb3V0PikgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9iY29uZmlnLmM6NTkw NgogICAgICAgIGNmYiA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIGNlID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgbGFzdCA9IDB4NTU1NTU1OTVkYTkwCiAgICAgICAgbWwgPSA8b3B0aW1pemVk IG91dD4KICAgICAgICBjYSA9IHthcmdjID0gMSwgYXJndiA9IDB4N2ZmZmEwMTNkODYwLCBhcmd2 X3NpemUgPSA1MTMsIGxpbmUgPSAweDAsIHRsaW5lID0gMHgwLCBmbmFtZSA9IDB4NTU1NTU1NjFj OGUxICJzbGFwZCIsIGxpbmVubyA9IDAsIGxvZyA9ICJiYWNrLWNvbmZpZyIsICdcMDAwJyA8cmVw ZWF0cyA0MTEyIHRpbWVzPiwgcmVwbHkgPSB7ZXJyID0gMCwgbXNnID0gJ1wwMDAnIDxyZXBlYXRz IDI1NSB0aW1lcz59LCAKICAgICAgICAgIGRlcHRoID0gMCwgdmFseCA9IC0xLCB2YWx1ZXMgPSB7 dl9pbnQgPSAwLCB2X3VpbnQgPSAwLCB2X2xvbmcgPSAwLCB2X3Vsb25nID0gMCwgdl9iZXJfdCA9 IDAsIHZfc3RyaW5nID0gMHgwLCB2X2J2ID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHZf ZG4gPSB7dmRuX2RuID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHZkbl9uZG4gPSB7YnZf bGVuID0gMCwgYnZfdmFsID0gMHgwfX0sIAogICAgICAgICAgICB2X2FkID0gMHgwfSwgcnZhbHVl X3ZhbHMgPSAweDAsIHJ2YWx1ZV9udmFscyA9IDB4MCwgb3AgPSAxLCB0eXBlID0gNSwgY2Ffb3Ag PSAweDdmZmZhMDEyZDQwMCwgYmUgPSAweDU1NTU1NTlkN2NhMCwgYmkgPSAweDAsIGNhX2VudHJ5 ID0gMHg1NTU1NTU5NGE2ZjgsIGNhX3ByaXZhdGUgPSAweDAsIGNsZWFudXAgPSAweDdmZmZlZjRi Y2E2MCA8bWRiX2NmX2NsZWFudXA+LCAKICAgICAgICAgIHRhYmxlID0gQ2Z0X0RhdGFiYXNlfQog ICAgICAgIHJkbiA9IHtidl9sZW4gPSAxMSwgYnZfdmFsID0gMHg1NTU1NTU5ZGJlYjAgIm9sY0Rh dGFiYXNlPXsxfW1kYixjbj1jb25maWcifQogICAgICAgIHB0ciA9IDxvcHRpbWl6ZWQgb3V0Pgog ICAgICAgIHJhZCA9IDB4NTU1NTU1OTJlMzAwCiAgICAgICAgZG9fcGF1c2UgPSA8b3B0aW1pemVk IG91dD4KIzkgIDB4MDAwMDU1NTU1NTVmYjIwMiBpbiBvdmVybGF5X29wX3dhbGsgKG9wPW9wQGVu dHJ5PTB4N2ZmZmEwMTJkNDAwLCBycz0weDdmZmZhZDA0Yzk4MCwgd2hpY2g9b3BfbW9kaWZ5LCBv aT0weDU1NTU1NTlkNDdkMCwgb249PG9wdGltaXplZCBvdXQ+KSBhdCAuLi8uLi8uLi8uLi9zZXJ2 ZXJzL3NsYXBkL2JhY2tvdmVyLmM6Njc3CiAgICAgICAgZnVuYyA9IDxvcHRpbWl6ZWQgb3V0Pgog ICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiMxMCAweDAwMDA1NTU1NTU1ZmIzNWQgaW4gb3Zl cl9vcF9mdW5jIChvcD0weDdmZmZhMDEyZDQwMCwgcnM9PG9wdGltaXplZCBvdXQ+LCB3aGljaD08 b3B0aW1pemVkIG91dD4pIGF0IC4uLy4uLy4uLy4uL3NlcnZlcnMvc2xhcGQvYmFja292ZXIuYzo3 MzAKICAgICAgICBvaSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIG9uID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgYmUgPSAweDU1NTU1NTk0OTkzMAogICAgICAgIGRiID0ge2JkX2luZm8gPSAw eDU1NTU1NTg4M2Y0MCA8c2xhcF9iaW5mbz4sIGJkX3NlbGYgPSAweDU1NTU1NTk0OTkzMCwgYmVf Y3RybHMgPSAnXDAwMCcgPHJlcGVhdHMgMTQgdGltZXM+LCAiXDAwMVwwMDBcMDAwXDAwMFwwMDEi LCAnXDAwMCcgPHJlcGVhdHMgMTMgdGltZXM+LCAiXDAwMSIsIGJlX2ZsYWdzID0gNjkyNDgwLCBi ZV9yZXN0cmljdG9wcyA9IDAsIGJlX3JlcXVpcmVzID0gMCwgCiAgICAgICAgICBiZV9zc2Zfc2V0 ID0ge3Nzc19zc2YgPSAwLCBzc3NfdHJhbnNwb3J0ID0gMCwgc3NzX3RscyA9IDAsIHNzc19zYXNs ID0gMCwgc3NzX3VwZGF0ZV9zc2YgPSAwLCBzc3NfdXBkYXRlX3RyYW5zcG9ydCA9IDAsIHNzc191 cGRhdGVfdGxzID0gMCwgc3NzX3VwZGF0ZV9zYXNsID0gMCwgc3NzX3NpbXBsZV9iaW5kID0gMH0s IGJlX3N1ZmZpeCA9IDB4NTU1NTU1OTQ5YjMwLCAKICAgICAgICAgIGJlX25zdWZmaXggPSAweDU1 NTU1NTk0OWI4MCwgYmVfc2NoZW1hZG4gPSB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgYmVf c2NoZW1hbmRuID0ge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIGJlX3Jvb3RkbiA9IHtidl9s ZW4gPSAyNywgYnZfdmFsID0gMHg1NTU1NTU5ZDM5ZjAgImNuPWFkbWluLGRjPXNhbWtub3dzLGRj PWNvbSJ9LCBiZV9yb290bmRuID0ge2J2X2xlbiA9IDI3LCAKICAgICAgICAgICAgYnZfdmFsID0g MHg1NTU1NTU5Y2MzYzAgImNuPWFkbWluLGRjPXNhbWtub3dzLGRjPWNvbSJ9LCBiZV9yb290cHcg PSB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgYmVfbWF4X2RlcmVmX2RlcHRoID0gMTUsIGJl X2RlZl9saW1pdCA9IHtsbXNfdF9zb2Z0ID0gMzYwMCwgbG1zX3RfaGFyZCA9IDAsIGxtc19zX3Nv ZnQgPSA1MDAsIGxtc19zX2hhcmQgPSAwLCAKICAgICAgICAgICAgbG1zX3NfdW5jaGVja2VkID0g LTEsIGxtc19zX3ByID0gMCwgbG1zX3NfcHJfaGlkZSA9IDAsIGxtc19zX3ByX3RvdGFsID0gMH0s IGJlX2xpbWl0cyA9IDB4MCwgYmVfYWNsID0gMHg1NTU1NTU5ZDJlYzAsIGJlX2RmbHRhY2Nlc3Mg PSBBQ0xfTk9ORSwgYmVfZXh0cmFfYW5saXN0ID0gMHgwLCBiZV91cGRhdGVfbmRuID0ge2J2X2xl biA9IDAsIGJ2X3ZhbCA9IDB4MH0sIAogICAgICAgICAgYmVfdXBkYXRlX3JlZnMgPSAweDAsIGJl X3BlbmRpbmdfY3NuX2xpc3QgPSAweDU1NTU1NThmOGNiMCwgYmVfcGNsX211dGV4ID0ge19fZGF0 YSA9IHtfX2xvY2sgPSAwLCBfX2NvdW50ID0gMCwgX19vd25lciA9IDAsIF9fbnVzZXJzID0gMCwg X19raW5kID0gMCwgX19zcGlucyA9IDAsIF9fZWxpc2lvbiA9IDAsIF9fbGlzdCA9IHtfX3ByZXYg PSAweDAsIF9fbmV4dCA9IDB4MH19LCAKICAgICAgICAgICAgX19zaXplID0gJ1wwMDAnIDxyZXBl YXRzIDM5IHRpbWVzPiwgX19hbGlnbiA9IDB9LCBiZV9zeW5jaW5mbyA9IDB4NTU1NTU1OWQ2NDQw LCBiZV9wYiA9IDB4MCwgYmVfY2Zfb2NzID0gMHgwLCBiZV9wcml2YXRlID0gMHg1NTU1NTU4ODc4 YTAgPGNmQmFja0luZm8+LCBiZV9uZXh0ID0ge3N0cWVfbmV4dCA9IDB4NTU1NTU1OWQ3Y2EwfX0K ICAgICAgICBjYiA9IHtzY19uZXh0ID0gMHgwLCBzY19yZXNwb25zZSA9IDB4NTU1NTU1NWZhNTQw IDxvdmVyX2JhY2tfcmVzcG9uc2U+LCBzY19jbGVhbnVwID0gMHgwLCBzY193cml0ZXdhaXQgPSAw eDAsIHNjX3ByaXZhdGUgPSAweDU1NTU1NTlkNDdkMH0KICAgICAgICBzYyA9IDxvcHRpbWl6ZWQg b3V0PgogICAgICAgIHJjID0gMzI3NjgKICAgICAgICBfX1BSRVRUWV9GVU5DVElPTl9fID0gIm92 ZXJfb3BfZnVuYyIKIzExIDB4MDAwMDU1NTU1NTVhNTY4NCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4 N2ZmZmEwMTJkNDAwLCBycz0weDdmZmZhZDA0Yzk4MCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9z bGFwZC9tb2RpZnkuYzozMDMKICAgICAgICB1cGRhdGUgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICByZXBsX3VzZXIgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBvcF9iZSA9IDxvcHRpbWl6ZWQg b3V0PgogICAgICAgIGJkID0gMHg1NTU1NTU4ODkzYzAgPHNsYXBfZnJvbnRlbmREQj4KICAgICAg ICB0ZXh0YnVmID0gIlwzNDBGXDI3MlwzNjdcMzc3XDE3N1wwMDBcMDAwXHZcdlwwMDBcMjQwXDM3 N1wxNzdcMDAwXDAwMFwwMDNcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwXDM2MUpcMjcyXDM2 N1wzNzdcMTc3XDAwMFwwMDBcMDAwXDI3MFwwMDRcMjU1XDM3N1wxNzdcMDAwXDAwMFwyMDBcMjcw XDAwNFwyNTVcMzc3XDE3N1wwMDBcMDAwXDAwNlwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBc MDAwXDM0M1wzNDNcMzYzXDMyMVwwMzYvXDM3NFwyMDBcMjcwXDAwNFwyNTVcMzc3XDE3N1wwMDBc MDAwXDIwMFxuXDAwMFwyNDBcMzc3XDE3N1wwMDBcMDAwXDIwMFwyNzBcMDA0XDI1NVwzNzdcMTc3 XDAwMFwwMDBcMDIwXDAwMVwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwNzBcMzI0XDAyMlwyNDBc Mzc3XDE3N1wwMDBcMDAwXDAwMFwzNDNcMzQzXDM2M1wzMjFcMDM2L1wzNzRcMDM1XDAwMFwwMDBc MDAwXDAwMFwwMDBcMDAwXDAwMFwyMDBcMjUzXDAyMlwyNDBcMzc3XDE3N1wwMDBcMDAwXDIwMFwz MTFcMDA0XDI1NVwzNzdcMTc3XDAwMFwwMDBgXDI1M1wwMjJcMjQwXDM3N1wxNzciLCAnXDAwMCcg PHJlcGVhdHMgMTggdGltZXM+LCAiXDAwNFwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMjQ1 ZVpVVVVcMDAwXDAwMFwzMjBcMzEzXDAwNFwyNTVcMzc3XDE3N1wwMDBcMDAwXDI2MFwyNzBcMDA0 XDI1NVwzNzdcMTc3XDAwMFwwMDBcMjQwXDMxMVwwMDRcMjU1XDM3N1wxNzdcMDAwXDAwMCIuLi4K IzEyIDB4MDAwMDU1NTU1NTVhNzZiYiBpbiBkb19tb2RpZnkgKG9wPTB4N2ZmZmEwMTJkNDAwLCBy cz0weDdmZmZhZDA0Yzk4MCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9tb2RpZnkuYzox NzcKICAgICAgICBkbiA9IHtidl9sZW4gPSAyOCwgYnZfdmFsID0gMHg3ZmZmYTAxMmNmMzcgIm9s Y0RhdGFiYXNlPXsxfW1kYixjbj1jb25maWcifQogICAgICAgIHRleHRidWYgPSAiUFwzMzBcMDIy XDI0MFwzNzdcMTc3XDAwMFwwMDBcMDY1XDAzMVwzNDVcMzYzXDM3N1wxNzdcMDAwXDAwMFwzMTVc MzcxXDM1NWM2XDM2Mi1fX2kkXDM2Ntm9XDI3N1wyMDc8XDM1MEE4ZVwzNTVNXDM3MFwzNTAkdlwy MjRqU1wyNzNcMjE3XDI1MFwzNzdcMDYwITZcMjE3XDI1ND5cMDAwXDM0MlwyMzE+XDAyMW5cMjU0 XDAxN9moe1wwMjNcMDIzQUdcMDI0Q1wyMjJcMzc1IFwzNDRcMDcwXDMyN1wyNzdWXDIyMlwyNzBc MjIxS2NPdT5vXDAwM8mWy7oxXDMzMSVrXDI2NlwyMTFcMzEyXDA2NVwyNTdcMDAwXDAyNFwyMzJc MjIyRilxXDIxN8mjXGFcMDE2XDIwNlwwNjZcMjMyXDIyMlNzXDI0NlwzNTVcMzExeFwwMjJcMzE3 ZFwzNjR3XDMyMypcMjUzXDM3NlNcMDMzXDM2NGlcMzE2XDM3NmJcMjI0XDMzMNq6I316XDM0Mlwz MTZIcy9cMzQxU1wzMTZGXDMwNVdMJVwzNDdcMDMzXDM2Ny9cMjY1SVwyMjZAUFZcMjI1XDM2NmFc MjQ1XDAzMFwzMDBcMzExXtSKXDAwNUtcMDMwQlwyMTdcMDYyblwyMTUrQ1wzMDBcYlwwMDBcMjMw XDM3N1wxNzdcMDAwXDAwMFwzMzRcMzYyXDI3M1wzNjdcMzc3XDE3N1wwMDBcMDAwIi4uLgogICAg ICAgIHRtcCA9IDB4MAojMTMgMHgwMDAwNTU1NTU1NThkYTI2IGluIGNvbm5lY3Rpb25fb3BlcmF0 aW9uIChjdHg9Y3R4QGVudHJ5PTB4N2ZmZmFkMDRjYmQwLCBhcmdfdj1hcmdfdkBlbnRyeT0weDdm ZmZhMDEyZDQwMCkgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jb25uZWN0aW9uLmM6MTE1 NQogICAgICAgIHJjID0gODAKICAgICAgICBjYW5jZWwgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICBvcCA9IDB4N2ZmZmEwMTJkNDAwCiAgICAgICAgcnMgPSB7c3JfdHlwZSA9IFJFUF9SRVNVTFQs IHNyX3RhZyA9IDAsIHNyX21zZ2lkID0gMCwgc3JfZXJyID0gMCwgc3JfbWF0Y2hlZCA9IDB4MCwg c3JfdGV4dCA9IDB4MCwgc3JfcmVmID0gMHgwLCBzcl9jdHJscyA9IDB4MCwgc3JfdW4gPSB7c3J1 X3NlYXJjaCA9IHtyX2VudHJ5ID0gMHgwLCByX2F0dHJfZmxhZ3MgPSAwLCByX29wZXJhdGlvbmFs X2F0dHJzID0gMHgwLCByX2F0dHJzID0gMHgwLCAKICAgICAgICAgICAgICByX25lbnRyaWVzID0g MCwgcl92MnJlZiA9IDB4MH0sIHNydV9zYXNsID0ge3Jfc2FzbGRhdGEgPSAweDB9LCBzcnVfZXh0 ZW5kZWQgPSB7cl9yc3BvaWQgPSAweDAsIHJfcnNwZGF0YSA9IDB4MH19LCBzcl9mbGFncyA9IDB9 CiAgICAgICAgdGFnID0gMTAyCiAgICAgICAgb3BpZHggPSBTTEFQX09QX01PRElGWQogICAgICAg IGNvbm4gPSAweDU1NTU1NWExODZmMAogICAgICAgIG1lbWN0eCA9IDB4N2ZmZmEwMDAwOGMwCiAg ICAgICAgbWVtY3R4X251bGwgPSAweDAKICAgICAgICBtZW1zaXogPSAxMDQ4NTc2CiAgICAgICAg X19QUkVUVFlfRlVOQ1RJT05fXyA9ICJjb25uZWN0aW9uX29wZXJhdGlvbiIKIzE0IDB4MDAwMDU1 NTU1NTU4ZGQzYSBpbiBjb25uZWN0aW9uX3JlYWRfdGhyZWFkIChjdHg9MHg3ZmZmYWQwNGNiZDAs IGFyZ3Y9MHgxNikgYXQgLi4vLi4vLi4vLi4vc2VydmVycy9zbGFwZC9jb25uZWN0aW9uLmM6MTI5 MQogICAgICAgIHJjID0gPG9wdGltaXplZCBvdXQ+CiAgICAgICAgY3JpID0ge29wID0gMHg3ZmZm YTAxMmQ0MDAsIGZ1bmMgPSAweDAsIGFyZyA9IDB4MCwgY3R4ID0gMHg3ZmZmYWQwNGNiZDAsIG51 bGxvcCA9IDxvcHRpbWl6ZWQgb3V0Pn0KICAgICAgICBzID0gMjIKIzE1IDB4MDAwMDdmZmZmN2I5 NDNhMiBpbiA/PyAoKSBmcm9tIC91c3IvbGliL3g4Nl82NC1saW51eC1nbnUvbGlibGRhcF9yLTIu NC5zby4yCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE2IDB4MDAwMDdmZmZmNmFj YTZiYSBpbiBzdGFydF90aHJlYWQgKGFyZz0weDdmZmZhZDA0ZDcwMCkgYXQgcHRocmVhZF9jcmVh dGUuYzozMzMKICAgICAgICBfX3JlcyA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHBkID0gMHg3 ZmZmYWQwNGQ3MDAKICAgICAgICBub3cgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICB1bndpbmRf YnVmID0ge2NhbmNlbF9qbXBfYnVmID0ge3tqbXBfYnVmID0gezE0MDczNjA5NjE2MzU4NCwgLTQ5 MDIxMTgzNjcwNTgyOTI4NSwgMCwgMTQwNzM3MTg4NzgxMzI3LCAxNDA3MzYwOTYxNjQyODgsIDkz ODI0OTk2OTc4NjI0LCA0OTAxMDE3MDM1MjE0MDY1NTUsIDQ5MDE5NzE1Nzc5OTcyNjY4M30sIG1h c2tfd2FzX3NhdmVkID0gMH19LCBwcml2ID0ge3BhZCA9IHsweDAsIDB4MCwgMHgwLCAKICAgICAg ICAgICAgICAweDB9LCBkYXRhID0ge3ByZXYgPSAweDAsIGNsZWFudXAgPSAweDAsIGNhbmNlbHR5 cGUgPSAwfX19CiAgICAgICAgbm90X2ZpcnN0X2NhbGwgPSA8b3B0aW1pemVkIG91dD4KICAgICAg ICBwYWdlc2l6ZV9tMSA9IDxvcHRpbWl6ZWQgb3V0PgogICAgICAgIHNwID0gPG9wdGltaXplZCBv dXQ+CiAgICAgICAgZnJlZXNpemUgPSA8b3B0aW1pemVkIG91dD4KICAgICAgICBfX1BSRVRUWV9G VU5DVElPTl9fID0gInN0YXJ0X3RocmVhZCIKIzE3IDB4MDAwMDdmZmZmNjgwMDNkZCBpbiBjbG9u ZSAoKSBhdCAuLi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC94ODZfNjQvY2xvbmUuUzoxMDkKTm8g bG9jYWxzLgo= --001a113c349ed7ce5c0554434d63--

1 0

(ITS#8693) slaptest conversion of chain overlay generates invalid or undocumented starttls parameter
by jckidder＠aep.com 13 Jul '17

13 Jul '17

Full_Name: Jon Kidder Version: 2.4.44 OS: RHEL 6.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.239.221.87) This .conf section overlay chain chain-uri "ldaps://<myhost>" chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="<myuser>" credentials=<mycreds> mode="self" chain-tls ldaps tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error TRUE becomes this ldap backend when using slaptest # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 bdc4cf96 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldaps://<myhost>" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tl s/cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bin dmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,ou=automaton s,ou=users,dc=global,dc=aep,dc=com" credentials=<mycreds> keepalive=0:0:0 olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: 7b1cc741-120e-4ce2-b539-17791a361cb1 creatorsName: cn=config createTimestamp: 20170707202053Z entryCSN: 20170707202053.340477Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170707202053Z The starttls parameter of the chain-tls/tls/olcDBStartTLS attribute is either invalid or undocumented.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs