(ITS#8696) deadlock with 3-way delta-MMR and syncprov-checkpoint
by ryan＠openldap.org
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
4 years, 4 months
(ITS#8695) _sleep is deprecated
by quanah＠openldap.org
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.
4 years, 4 months
Re: (ITS#8694) Windows builds fail to install event information
by quanah＠symas.com
--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>
4 years, 4 months
Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com
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
4 years, 4 months
(ITS#8694) Windows builds fail to install event information
by quanah＠openldap.org
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.
4 years, 4 months
Re: (ITS#8472) slapd killed after ldapadd
by hyc＠symas.com
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/
4 years, 4 months
Re: (ITS#8472) slapd killed after ldapadd
by ondra＠mistotebe.net
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
4 years, 4 months
Re: (ITS#8472) slapd killed after ldapadd
by russell＠samknows.com
--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--
4 years, 4 months
(ITS#8693) slaptest conversion of chain overlay generates invalid or undocumented starttls parameter
by jckidder＠aep.com
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.
4 years, 4 months
