- openldap-bugs - openldap.org

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Quanah, In this specific test I reported in my previous e-mail it was used glibc. Now I tested with tcmalloc and the memory again was much more consumed and never released. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10652 ldap 18 0 2006m 1.8g 68m S 100 15.8 8:36.75 slapd Once it get this much memory it then stabilize but it is much more than before that was 385m. The scenario was : 1) Start a full ldapsearch for one specific dn(the DB has 4 dn's); 2) After sometime start a new full ldapsearch to behave as queries to DB when replication for LDIF backup is being done; 3) Export one of the queries to a file so speed verification can be done with grep and wc. After sometime the memory starts to be consumed in large chunks until it stopped in around 2G. Since one of the queries is being redirect to a file I can tail to have a visual rate of the entrances being returned by slapd. As the issue before after sometime the rate appears to get stuck and come in small 16 entrances chunks but only after some minutes. This behavior above appears to happen after the second ldapsearch fills its own dn cache even monitor always shows only one information as I could see. [root@brtldp11 ~]# date; grep -e '^pnnum*' /backup/temp.ldif |wc -l Mon Jan 26 21:43:31 BRST 2009 482432 [root@brtldp11 ~]# date; grep -e '^pnnum*' /backup/temp.ldif |wc -l Mon Jan 26 21:44:56 BRST 2009 482448 This behavior is similar as before with the initial issue with a single process. I just notice when slapd starts there are these threads : [root@brtldp12 ~]# ps -mu ldap PID TTY TIME CMD 10638 pts/2 00:00:00 slapd - - 00:00:00 - - - 00:00:00 - Then after the 2 queries are started I have : [root@brtldp12 ~]# ps -mu ldap PID TTY TIME CMD 10195 pts/2 00:44:22 slapd - - 00:00:00 - - - 00:00:00 - - - 00:26:09 - - - 00:18:13 - - - 00:00:00 - So 3 new threads. Looks like for some reason with multiples queries the issue with response getting stuck repeats. Even one ldapsearch is stopped the number of threads continues the same, memory continues allocated and the other search get with this slow rate. These outputs are using now tcmalloc but similar as with glibc. Regards, Rodrigo. --- On Mon, 1/26/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Monday, January 26, 2009, 9:25 PM > --On Monday, January 26, 2009 3:18 PM -0800 Rodrigo Costa > <rlvcosta(a)yahoo.com> wrote: > > > Quanah and Howard, > > > > Sorry to come back. > > > > I tried to make 2 ldapsearch to the same DB > simultaneously, doing some > > stress test like dump the LDIF and queries coming. > > > > The slapd after sometime start to get more memory. By > what I could > > observe looks like new thread was started consuming > again the same memory > > as before so the slad now is consuming around the > double of memory as > > before. > > Are you also using an alternate malloc() instead of glibc? > I know you were > investigating this, just want to confirm you are using > tcmalloc or hoard > and not glibc. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 26 Jan '09

26 Jan '09

--On Monday, January 26, 2009 3:18 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah and Howard, > > Sorry to come back. > > I tried to make 2 ldapsearch to the same DB simultaneously, doing some > stress test like dump the LDIF and queries coming. > > The slapd after sometime start to get more memory. By what I could > observe looks like new thread was started consuming again the same memory > as before so the slad now is consuming around the double of memory as > before. Are you also using an alternate malloc() instead of glibc? I know you were investigating this, just want to confirm you are using tcmalloc or hoard and not glibc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Quanah and Howard, Sorry to come back. I tried to make 2 ldapsearch to the same DB simultaneously, doing some stress test like dump the LDIF and queries coming. The slapd after sometime start to get more memory. By what I could observe looks like new thread was started consuming again the same memory as before so the slad now is consuming around the double of memory as before. I believe the cache would not grow beyond the boundary as like per thread since once cache is allocated it is never released. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10195 ldap 18 0 1913m 1.7g 68m S 100 15.0 31:25.71 slapd Then performance start to degrade again. Like before looks like the dump get stuck and comes in chunks. See example below : Mon Jan 26 21:05:16 BRST 2009 378752 Mon Jan 26 21:09:21 BRST 2009 378800 See that after around 4 minutes I have only 48 adds to the output LDIF from my first ldapsearch. Looks like if multiples queries are happening something still getting lost. Both queries are to the same DB and the monitor has : readOnly: FALSE olmBDBEntryCache: 1000 olmBDBDNCache: 1000953 olmBDBIDLCache: 1 Sorry to come back with this issue but I could detect this now. Thanks, Rodrigo. --- On Mon, 1/26/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Monday, January 26, 2009, 8:53 PM > --On Monday, January 26, 2009 10:44 PM +0000 > rlvcosta(a)yahoo.com wrote: > > > Just some last questions. Is there any expectation for > a new release, for > > example 2.4.15, with this ITS included? Just to use a > formal release. > > 2.4.14 will have the fix for this ITS. There's no set > release date at this time, but hopefully soon. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 26 Jan '09

26 Jan '09

--On Monday, January 26, 2009 10:44 PM +0000 rlvcosta(a)yahoo.com wrote: > Just some last questions. Is there any expectation for a new release, for > example 2.4.15, with this ITS included? Just to use a formal release. 2.4.14 will have the fix for this ITS. There's no set release date at this time, but hopefully soon. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Howard, Now it fits under my expectation. Under the initial load without the fix I had slapd not respecting any boundary and then all DN information being cached. In this way the first query would take longer since the information wasn't yet cached. At that time I had, without cache, a search for around 1million entrances in around 7 minutes and after cached this time reduce to around half. So now with the new load I was expecting something a little longer as the initial not cached since now slapd will not be able to cache all information and so the cache will be often overwritten. Now in my tests I obtained : First time: real 6m50.017s user 0m17.346s sys 0m9.159s Second time: real 6m47.790s user 0m17.032s sys 0m9.137s Third time: real 7m17.459s user 0m17.412s sys 0m9.320s This is more than perfect. Amazing how you guys could solve this problem so quickly. I saw sometimes the DN cache allocating a little more memory since it sometimes pass a little the boundary, like seen below : olmBDBEntryCache: 1000 olmBDBDNCache: 1000247 olmBDBIDLCache: 1 The maximum I saw was 1000268 but nothing considerable. In this way now slapd is keeping memory allocation stable as it is supposed to behave. The only comment is if dn cache is passed this memory allocated appears to never be released. The maximum size slapd obtained was : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10195 ldap 18 0 385m 266m 68m S 0 2.2 20:54.16 slapd This is more than perfect ! Thanks for all your quick solution of this problem. I believe many users of openLDAP will see their system more stable with this fix. Just some last questions. Is there any expectation for a new release, for example 2.4.15, with this ITS included? Just to use a formal release. By the tests I was expecting the cachefree as the cache size bringing some improvements, at least in a full query, since system would "cycle" pointer memory and overwritten all cache at once. What is the purpose of cachefree? Just to understand better and then tune later with some better idea about cache purposes. Best Regards, Rodrigo. --- On Mon, 1/26/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Monday, January 26, 2009, 6:00 PM > Rodrigo Costa wrote: > > Howard, > > > > I do not think the ITS is completely solved. Let me > try to explain better. > > > > I have the system respecting now the DN cachesize > boundary. At the same time I wasn't sure about the > cachefree idea and now I changed to 1, or equal the default > value. > > > > In any case what happens is : > > > > 1) I have the system doing sequential search in a > reasonable speed until the dncachesize is reached; > > 2) After dncchesize is reached the sequential search > hangs, or the output from the search get stuck for a long > time(I'm forwarding to a file so I do not have screen > actualization delays); > > Ex: > > [root@brtldp11 backup]# date; cat temp.ldif |grep -e > '^pnnum*' |wc -l > > Mon Jan 26 17:22:21 BRST 2009 > > 250016 > > [root@brtldp11 backup]# date; cat temp.ldif |grep -e > '^pnnum*' |wc -l > > Mon Jan 26 17:23:00 BRST 2009 > > 250016 > > See above that even almost after 1 minute passed not > new LDIF entrance was included. > > 3) Then query get stuck and looks like deterministic > it time by time only dumps 16 entrances and get stuck. This > behavior repeats and with these stuck that sometime gets > minutes the query never ends. > > > > olmBDBEntryCache: 884 > > olmBDBDNCache: 1000261 > > olmBDBIDLCache: 1 > > > > olmBDBEntryCache: 611 > > olmBDBDNCache: 1000261 > > olmBDBIDLCache: 1 > > > >Even with cachesize as 1000 and cachefree as 1, the > olmBDBEntryCache continues > to decrease, just slow now. > > > > I was expecting that a cachefree as 1000 would purge > all entrances and then > > cache again all 1000 new with in sequence always > answering the search. So > > the search would never hangs like it is happening now. > > I see. OK, this is now fixed in HEAD. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/

1 0

Re: (ITS#5336)
by hyc＠symas.com 26 Jan '09

26 Jan '09

quanah(a)zimbra.com wrote: > A similar bug has been reported in the debian bug tracking system, with > some debugging information and reproducibility steps. > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465915> Noting that this was closed in Debian as of 2.4.9. Closing this ITS. -- -- 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#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 26 Jan '09

26 Jan '09

Rodrigo Costa wrote: > Howard, > > I do not think the ITS is completely solved. Let me try to explain better. > > I have the system respecting now the DN cachesize boundary. At the same time I wasn't sure about the cachefree idea and now I changed to 1, or equal the default value. > > In any case what happens is : > > 1) I have the system doing sequential search in a reasonable speed until the dncachesize is reached; > 2) After dncchesize is reached the sequential search hangs, or the output from the search get stuck for a long time(I'm forwarding to a file so I do not have screen actualization delays); > Ex: > [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l > Mon Jan 26 17:22:21 BRST 2009 > 250016 > [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l > Mon Jan 26 17:23:00 BRST 2009 > 250016 > See above that even almost after 1 minute passed not new LDIF entrance was included. > 3) Then query get stuck and looks like deterministic it time by time only dumps 16 entrances and get stuck. This behavior repeats and with these stuck that sometime gets minutes the query never ends. > > olmBDBEntryCache: 884 > olmBDBDNCache: 1000261 > olmBDBIDLCache: 1 > > olmBDBEntryCache: 611 > olmBDBDNCache: 1000261 > olmBDBIDLCache: 1 > >Even with cachesize as 1000 and cachefree as 1, the olmBDBEntryCache continues to decrease, just slow now. > > I was expecting that a cachefree as 1000 would purge all entrances and then > cache again all 1000 new with in sequence always answering the search. So > the search would never hangs like it is happening now. I see. OK, this is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Howard, I do not think the ITS is completely solved. Let me try to explain better. I have the system respecting now the DN cachesize boundary. At the same time I wasn't sure about the cachefree idea and now I changed to 1, or equal the default value. In any case what happens is : 1) I have the system doing sequential search in a reasonable speed until the dncachesize is reached; 2) After dncchesize is reached the sequential search hangs, or the output from the search get stuck for a long time(I'm forwarding to a file so I do not have screen actualization delays); Ex: [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:22:21 BRST 2009 250016 [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:23:00 BRST 2009 250016 See above that even almost after 1 minute passed not new LDIF entrance was included. 3) Then query get stuck and looks like deterministic it time by time only dumps 16 entrances and get stuck. This behavior repeats and with these stuck that sometime gets minutes the query never ends. olmBDBEntryCache: 884 olmBDBDNCache: 1000261 olmBDBIDLCache: 1 olmBDBEntryCache: 611 olmBDBDNCache: 1000261 olmBDBIDLCache: 1 Even with cachesize as 1000 and cachefree as 1, the olmBDBEntryCache continues to decrease, just slow now. I was expecting that a cachefree as 1000 would purge all entrances and then cache again all 1000 new with in sequence always answering the search. So the search would never hangs like it is happening now. It get stuck and will never ends since it responds only 16 entrances in order of minutes and in bursts. The previous load was more reasonable than now since even taking much longer it would end the search. [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:31:36 BRST 2009 250128 Please let me know if you need more information, Rodrigo. --- On Mon, 1/26/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Monday, January 26, 2009, 5:18 PM > Rodrigo Costa wrote: > > Howard, > > > > I download the new HEAD version and made some testing. > Now the > olmBDBEntryCache is following the cache configuration. > > Good, then this ITS is resolved. Usage questions should be > directed to the > -software mailing list. > > > I also made some small change in slapd.conf including > cachefree > configuration. Please see below in the end how slapd is > configured related to > bdb cache : > > > line 123 (cachesize 1000) > > line 124 (cachefree 1000) > > line 125 (idlcachesize 1000) > > line 126 (dncachesize 1000000) > > Setting cachefree equal to cachesize will effectively cause > the entire entry > cache to be dumped each time it reaches its maximum size. > That's clearly not a > good idea. > > > I increase the dncachesize since with a small value > the search takes > considerable more time. > > > > First I tested with a value greater than the value > that was consuming > > before > without the memory boundary. In this way I was expecting > some order of > magnitude as before, what it achieved (line 126 > (dncachesize 5000000)): > > > BEFORE CACHED: > > 1000000 > > > > real 5m23.084s > > user 0m28.026s > > sys 0m6.686s > > > > Then Cache has : > > > > olmBDBEntryCache: 1001 > > olmBDBDNCache: 4000264 > > olmBDBIDLCache: 1 > > > > AFTER CACHED: > > > > 1000000 > > > > real 2m31.623s > > user 0m28.145s > > sys 0m8.637s > > > > Just to let clear these tests above where with the new > logic and where the > DN Cache Size is bigger than the final number I had with > the old logic where > all information is cached into memory. > > > > For each entrance I have 4 dn's that compose the > entrance. Since my filter > is for only one of the dn I was expecting this cache to be > only related with > the filter and then in 1,000,000. > > > Then I change the dncachesize to 1000000 (line 126 > (dncachesize 1000000) : > > > > The total time for a search using a filter for one > index dn became : > > > > ldap_result: Can't contact LDAP server (-1) > > 255801 > > > > real 469m26.619s > > user 0m7.027s > > sys 0m1.756s > > > > I needed to kill the server so I would have an idea > about how many > > entrances > it searched. The time is too long and I'm not sure if > it would even end. I let > all night but the process did not end. This was the same > ldapsearch as when > all entrances would be allocated in a DN cache into memory. > > > > But the cache process was something I wasn't > expecting. Before the > dncachesize was reached I had at monitor : > > > > olmBDBEntryCache: 1001 > > olmBDBDNCache: 921296 > > olmBDBIDLCache: 1 > > > > Then after the boundary was reached it became : > > > > olmBDBEntryCache: 1 > > olmBDBDNCache: 1000262 > > olmBDBIDLCache: 1 > > > > Where these numbers didn't change anymore. Not > sure why after the > dncachesize is reached the cachesize(or olmBDBEntryCache) > became 1. > > Because you set cachefree to 1000. 1001 - 1000 = 1. > > -- > -- 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#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 26 Jan '09

26 Jan '09

Rodrigo Costa wrote: > Howard, > > I download the new HEAD version and made some testing. Now the olmBDBEntryCache is following the cache configuration. Good, then this ITS is resolved. Usage questions should be directed to the -software mailing list. > I also made some small change in slapd.conf including cachefree configuration. Please see below in the end how slapd is configured related to bdb cache : > line 123 (cachesize 1000) > line 124 (cachefree 1000) > line 125 (idlcachesize 1000) > line 126 (dncachesize 1000000) Setting cachefree equal to cachesize will effectively cause the entire entry cache to be dumped each time it reaches its maximum size. That's clearly not a good idea. > I increase the dncachesize since with a small value the search takes considerable more time. > > First I tested with a value greater than the value that was consuming > before without the memory boundary. In this way I was expecting some order of magnitude as before, what it achieved (line 126 (dncachesize 5000000)): > BEFORE CACHED: > 1000000 > > real 5m23.084s > user 0m28.026s > sys 0m6.686s > > Then Cache has : > > olmBDBEntryCache: 1001 > olmBDBDNCache: 4000264 > olmBDBIDLCache: 1 > > AFTER CACHED: > > 1000000 > > real 2m31.623s > user 0m28.145s > sys 0m8.637s > > Just to let clear these tests above where with the new logic and where the DN Cache Size is bigger than the final number I had with the old logic where all information is cached into memory. > > For each entrance I have 4 dn's that compose the entrance. Since my filter is for only one of the dn I was expecting this cache to be only related with the filter and then in 1,000,000. > Then I change the dncachesize to 1000000 (line 126 (dncachesize 1000000) : > > The total time for a search using a filter for one index dn became : > > ldap_result: Can't contact LDAP server (-1) > 255801 > > real 469m26.619s > user 0m7.027s > sys 0m1.756s > > I needed to kill the server so I would have an idea about how many > entrances it searched. The time is too long and I'm not sure if it would even end. I let all night but the process did not end. This was the same ldapsearch as when all entrances would be allocated in a DN cache into memory. > > But the cache process was something I wasn't expecting. Before the dncachesize was reached I had at monitor : > > olmBDBEntryCache: 1001 > olmBDBDNCache: 921296 > olmBDBIDLCache: 1 > > Then after the boundary was reached it became : > > olmBDBEntryCache: 1 > olmBDBDNCache: 1000262 > olmBDBIDLCache: 1 > > Where these numbers didn't change anymore. Not sure why after the dncachesize is reached the cachesize(or olmBDBEntryCache) became 1. Because you set cachefree to 1000. 1001 - 1000 = 1. -- -- 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#5906) slapo-rwm and cn=config
by ando＠sys-net.it 26 Jan '09

26 Jan '09

ldap(a)htam.net wrote: > Full_Name: Mathieu MILLET > Version: 2.4.13 > OS: Linux Fedora 10 > URL: > Submission from: (NULL) (81.80.3.6) > > > When configuring the slapo-rwm overlay inside a relay database, using cn=config > style, it is impossible to load (online or offline) the attribute > olcRwmRewrite. Should be fixed in HEAD. Please test and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5906) slapo-rwm and cn=config
by ldap＠htam.net 26 Jan '09

26 Jan '09

Full_Name: Mathieu MILLET Version: 2.4.13 OS: Linux Fedora 10 URL: Submission from: (NULL) (81.80.3.6) When configuring the slapo-rwm overlay inside a relay database, using cn=config style, it is impossible to load (online or offline) the attribute olcRwmRewrite. The error message is : htam@p10891008 ldif]$ ldapadd -h localhost -x -D "cn=config" -w secret -f config_relay_database.ldif adding new entry "olcOverlay={0}rwm,olcDatabase={3}relay,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcRwmRewrite> handler exited with 1 config_relay_database.ldif : dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmNormalizeMapped: FALSE olcRwmRewrite: {0} rwm-rewriteEngine "on" olcRwmRewrite: {1} rwm-rewriteContext "default" olcRwmRewrite: {2} rwm-rewriteRule "cn=(.+),ou=ilo,dc=domain-ilo,dc=net$" "uid=$1,ou=people,dc=domain,dc=net" ":" olcRwmRewrite: {3} rwm-rewriteContext "searchEntryDN" olcRwmRewrite: {4} rwm-rewriteRule "uid=(.+),ou=people,dc=domain,dc=net$" "cn=$1,ou=ilo,dc=domain-ilo,dc=net" ":" olcRwmRewrite: {5} rwm-rewriteRule ".+,ou=groups,dc=domain,dc=net$" "$0" ":@" olcRwmRewrite: {6} rwm-rewriteContext "searchAttrDN" "alias" "searchEntryDN" olcRwmRewrite: {7} rwm-rewriteContext "matchedDN" "alias" "searchEntryDN" olcRwmTFSupport: no ------------------------------ dn: olcDatabase={3}relay objectClass: olcDatabaseConfig objectClass: olcRelayConfig olcDatabase: {3}relay olcSuffix: ou=ilo,dc=domain-ilo,dc=net olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: FALSE olcRelay: dc=domain,dc=net structuralObjectClass: olcRelayConfig I get the same result and error, if I manually put this file in the slapd.d sub-directory. I also get the same result and error, if I ldapadd the objet without the olcRwmRewrite attribute and then ldapmodify to add this attribute (even a single line like <<rwm-rewriteEngine "on">> or <<rwm-rewriteContext "default">>).

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Howard, I download the new HEAD version and made some testing. Now the olmBDBEntryCache is following the cache configuration. I also made some small change in slapd.conf including cachefree parameter. Please see below in the end how slapd is configured related to bdb cache : line 123 (cachesize 1000) line 124 (cachefree 1000) line 125 (idlcachesize 1000) line 126 (dncachesize 1000000) I increase the dncachesize since with a small value the search takes considerable more time. First I tested with a value greater than the value that was being consumed before without the memory boundary. In this way I was expecting some order of magnitude as before, what was achieved (line 126 (dncachesize 5000000)): BEFORE CACHED: 1000000 real 5m23.084s user 0m28.026s sys 0m6.686s Then Cache has : olmBDBEntryCache: 1001 olmBDBDNCache: 4000264 olmBDBIDLCache: 1 AFTER CACHED: 1000000 real 2m31.623s user 0m28.145s sys 0m8.637s I would like to reinforce this test above was using a dncachesize knew that can store all DN's from my DB. This follow the same behavior as before where all DB can be stored into memory without slapd respecting the configuration boundaries(like it). In my system I will have dn's that compose the entrance. Since my filter is for only one of the dn I was expecting this cache to be only related with the filter and then in 1,000,000. So I'm expecting something greater than 6 minutes since for the first time system caches the information, or in other way used disk to read DB, the time was around 6 minutes. With a cache smaller than 4 million entrances, I was expecting just a little more overhead since it would required slapd to flush cache and start to load the entrances more than once. In any case I would not expect something greater than 6 minutes since to flush memory and load from pieces should not cause too much overhead. Only following queries would not take fully advantage, like half time at further tries, since the cache cannot keep all information. But some strange things, by my perspective, happened. The dncache grew normally until reach the 1000000 value with cachesize following the boundary 1000 : readOnly: FALSE olmBDBEntryCache: 1001 olmBDBDNCache: 957271 olmBDBIDLCache: 1 But after the dncache limit is reached, by monitor, the cache became : olmBDBEntryCache: 1 olmBDBDNCache: 1000262 (this is a very deterministic number) olmBDBIDLCache: 1 Getting stuck here forever. Also the performance degrades considerable. From this point on I let all night and the DB was not fully passed. This means that after the DN cache enter in restrictions, even a lower performance would be expected since disk access should be more often, it becomes unpractical. I needed to stop the slapd so I could see how many entrances were parsed. This return a number around 250,000, meaning around 1/4 as the DN size. This appears to be that after cache boundary is reached for some reason the DB parse doesn't evolve anymore. I lost the correct time information from my last night query running but I can send another query I did this morning with some similar information. I can say it took more than 8 hours without moving very further than 250,000 entrance(of 1,000,000). ldap_result: Can't contact LDAP server (-1) 251512 real 121m51.697s user 0m7.327s sys 0m1.734s This is very deterministic and normally get stuck around this value without much improvement. I do not believe query will end. This was the reason I needed to kill the slapd process to have an order of magnitude the search had reached since this search is never ending. Something still looking with problems since performance is too much degraded even the disk would be more in use. Looks like search gets stuck after cache boundaries are reached. Also looks like the entrance cache becomes 1(olmBDBEntryCache) after dn limit is reached. Best Regards, Rodrigo. --- On Sun, 1/25/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Sunday, January 25, 2009, 7:46 PM > Rodrigo Costa wrote: > > Howard, > > > > I tested the HEAD load last night. The results I > believe are partial. > > Thanks for the feedback, please try the new patch in HEAD. > > > > The memory stay stable and the use was much lower. I > had in my slapd.conf the following cache boundaries : > > > > line 122 (cachesize 1000) > > line 123 (idlcachesize 1000) > > line 124 (dncachesize 2000) > > > > Which make with the new load to consume much less > memory and stay stable. > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM > TIME+ COMMAND > > 20715 ldap 18 0 184m 73m 68m S 0 0.6 > 174:05.81 slapd > > > > But by the other hand I use the monitor information to > check the cache usage. I would notice that now dncache is > keeping around the boundary I put of 20000 but the cache is > now fixed as 1, not 1000. See information below : > > > > readOnly: FALSE > > olmBDBEntryCache: 1 > > olmBDBDNCache: 2185 > > olmBDBIDLCache: 1 > > olmDbDirectory: /var/openldap-data/bdb2/ > > entryDN: cn=Database 2,cn=Databases,cn=Monitor > > > > This kept around this all the time I was making a > search in DB. > > > > Before this load with this possible DN cache boundary > solution I made the ldapsearch in around 7 minutes, for the > first time not cached yet. And around 4 minutes after the > entrances were cached. > > > > Now with this new load I made the search and it took : > > > > 1000000 > > > > real 174m6.486s > > user 0m43.746s > > sys 0m16.923s > > > > > > Almost 3 hours. It's ok that I didn't tune the > cache sizes but I was at least expecting the > olmBDBEntryCache would now follow the 1000 boundary and not > single 1. > > > > I believe this is what is not making this huge > performance difference and not the olmBDBDNCache. > > > > Please confirm this is some tuning missing or if > something else like the olmBDBEntryCache would be improved. > > > > In terms of memory usage now it is respecting but the > performance, probably based in the olmBDBEntryCache only > using 1 position, is much worst. > > > > Please also let me know if you think this performance > degradation and the olmBDBEntryCache marking 1 is a tuning > issue or something still need to be modified in the code. > > > > Thanks for the fast solution for this issue since this > would be affecting all systems and types of DB. > > > > Rodrigo. > > > -- > -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

--0-2140963594-1232966602=:67255 Content-Type: text/plain; charset=us-ascii Howard, I download the new HEAD version and made some testing. Now the olmBDBEntryCache is following the cache configuration. I also made some small change in slapd.conf including cachefree configuration. Please see below in the end how slapd is configured related to bdb cache : line 123 (cachesize 1000) line 124 (cachefree 1000) line 125 (idlcachesize 1000) line 126 (dncachesize 1000000) I increase the dncachesize since with a small value the search takes considerable more time. First I tested with a value greater than the value that was consuming before without the memory boundary. In this way I was expecting some order of magnitude as before, what it achieved (line 126 (dncachesize 5000000)): BEFORE CACHED: 1000000 real 5m23.084s user 0m28.026s sys 0m6.686s Then Cache has : olmBDBEntryCache: 1001 olmBDBDNCache: 4000264 olmBDBIDLCache: 1 AFTER CACHED: 1000000 real 2m31.623s user 0m28.145s sys 0m8.637s Just to let clear these tests above where with the new logic and where the DN Cache Size is bigger than the final number I had with the old logic where all information is cached into memory. For each entrance I have 4 dn's that compose the entrance. Since my filter is for only one of the dn I was expecting this cache to be only related with the filter and then in 1,000,000. Then I change the dncachesize to 1000000 (line 126 (dncachesize 1000000) : The total time for a search using a filter for one index dn became : ldap_result: Can't contact LDAP server (-1) 255801 real 469m26.619s user 0m7.027s sys 0m1.756s I needed to kill the server so I would have an idea about how many entrances it searched. The time is too long and I'm not sure if it would even end. I let all night but the process did not end. This was the same ldapsearch as when all entrances would be allocated in a DN cache into memory. But the cache process was something I wasn't expecting. Before the dncachesize was reached I had at monitor : olmBDBEntryCache: 1001 olmBDBDNCache: 921296 olmBDBIDLCache: 1 Then after the boundary was reached it became : olmBDBEntryCache: 1 olmBDBDNCache: 1000262 olmBDBIDLCache: 1 Where these numbers didn't change anymore. Not sure why after the dncachesize is reached the cachesize(or olmBDBEntryCache) became 1. Based in my expectation and the 3GB process limit in a 32 bits system I should have configured a DN cache of around 1/4 of the maximum size just like in this example with dncachesize equal to 1,000,000. In the end the monitor cache information remained as : olmBDBEntryCache: 1 olmBDBDNCache: 1000261 olmBDBIDLCache: 1 Not sure about how these cache behaves but even if the cache would be loaded again to answer a query I was not expecting this huge difference. Looks like something gets stuck since even if the read was directly from disk it should be faster. Regards, Rodrigo. --- On Sun, 1/25/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Sunday, January 25, 2009, 7:46 PM > Rodrigo Costa wrote: > > Howard, > > > > I tested the HEAD load last night. The results I > believe are partial. > > Thanks for the feedback, please try the new patch in HEAD. > > > > The memory stay stable and the use was much lower. I > had in my slapd.conf the following cache boundaries : > > > > line 122 (cachesize 1000) > > line 123 (idlcachesize 1000) > > line 124 (dncachesize 2000) > > > > Which make with the new load to consume much less > memory and stay stable. > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM > TIME+ COMMAND > > 20715 ldap 18 0 184m 73m 68m S 0 0.6 > 174:05.81 slapd > > > > But by the other hand I use the monitor information to > check the cache usage. I would notice that now dncache is > keeping around the boundary I put of 20000 but the cache is > now fixed as 1, not 1000. See information below : > > > > readOnly: FALSE > > olmBDBEntryCache: 1 > > olmBDBDNCache: 2185 > > olmBDBIDLCache: 1 > > olmDbDirectory: /var/openldap-data/bdb2/ > > entryDN: cn=Database 2,cn=Databases,cn=Monitor > > > > This kept around this all the time I was making a > search in DB. > > > > Before this load with this possible DN cache boundary > solution I made the ldapsearch in around 7 minutes, for the > first time not cached yet. And around 4 minutes after the > entrances were cached. > > > > Now with this new load I made the search and it took : > > > > 1000000 > > > > real 174m6.486s > > user 0m43.746s > > sys 0m16.923s > > > > > > Almost 3 hours. It's ok that I didn't tune the > cache sizes but I was at least expecting the > olmBDBEntryCache would now follow the 1000 boundary and not > single 1. > > > > I believe this is what is not making this huge > performance difference and not the olmBDBDNCache. > > > > Please confirm this is some tuning missing or if > something else like the olmBDBEntryCache would be improved. > > > > In terms of memory usage now it is respecting but the > performance, probably based in the olmBDBEntryCache only > using 1 position, is much worst. > > > > Please also let me know if you think this performance > degradation and the olmBDBEntryCache marking 1 is a tuning > issue or something still need to be modified in the code. > > > > Thanks for the fast solution for this issue since this > would be affecting all systems and types of DB. > > > > Rodrigo. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/ --0-2140963594-1232966602=:67255 Content-Type: text/plain; name="monitor_8.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor_8.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogT3BlbkxEQVA6IHNs YXBkIDIuWCAoSmFuIDI2IDIwMDkgMDE6MzM6MjcpDQplbnRyeUROOiBjbj1N b25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUJhY2tlbmRzLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2 MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogY29uZmlnDQptb25pdG9yZWRJbmZv OiBsZGlmDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JlZEluZm86IG1v bml0b3INCmVudHJ5RE46IGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog VFJVRQ0KDQpkbjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYw NDI4MjBaDQptb25pdG9yZWRJbmZvOiBjb25maWcNCm1vbml0b3JSdW50aW1l Q29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAyLjE2Ljg0MC4xLjEx MzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRz LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUJhY2tlbmQgMSxj bj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogbGRp Zg0KbW9uaXRvclJ1bnRpbWVDb25maWc6IFRSVUUNCnN1cHBvcnRlZENvbnRy b2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQplbnRyeUROOiBjbj1CYWNr ZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQpt b25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JSdW50aW1lQ29uZmlnOiBUUlVF DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEuMTINCnN1cHBvcnRlZENv bnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0ZWRDb250 cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1cHBvcnRlZENvbnRy b2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBvcnRlZENvbnRyb2w6 IDEuMy42LjEuMS4xMy4xDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEu MTMuMg0Kc3VwcG9ydGVkQ29udHJvbDogMS4zLjYuMS40LjEuNDIwMy4xLjEw LjENCnN1cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4xNDEz DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni4xMS43 LjINCmVudHJ5RE46IGNuPUJhY2tlbmQgMixjbj1CYWNrZW5kcyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1CYWNrZW5kIDMsY249QmFja2Vu ZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCm1v bml0b3JSdW50aW1lQ29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAy LjE2Ljg0MC4xLjExMzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAz LGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBj bj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNu PUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFz czogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KZW50cnlETjogY249Q29u bmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1Db25u ZWN0aW9uIDEzLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvckNvbm5lY3Rpb24NCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2 MTIxNzM2Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjEyMTczNloNCm1v bml0b3JDb25uZWN0aW9uTnVtYmVyOiAxMw0KbW9uaXRvckNvbm5lY3Rpb25Q cm90b2NvbDogMw0KbW9uaXRvckNvbm5lY3Rpb25PcHNSZWNlaXZlZDogMg0K bW9uaXRvckNvbm5lY3Rpb25PcHNFeGVjdXRpbmc6IDENCm1vbml0b3JDb25u ZWN0aW9uT3BzUGVuZGluZzogMA0KbW9uaXRvckNvbm5lY3Rpb25PcHNDb21w bGV0ZWQ6IDENCm1vbml0b3JDb25uZWN0aW9uR2V0OiAyDQptb25pdG9yQ29u bmVjdGlvblJlYWQ6IDINCm1vbml0b3JDb25uZWN0aW9uV3JpdGU6IDANCm1v bml0b3JDb25uZWN0aW9uTWFzazogcngNCm1vbml0b3JDb25uZWN0aW9uTGlz dGVuZXI6IGxkYXA6Ly8xMC4xNDIuMTUuNDI6Mzg5DQptb25pdG9yQ29ubmVj dGlvblBlZXJEb21haW46IHVua25vd24NCm1vbml0b3JDb25uZWN0aW9uUGVl ckFkZHJlc3M6IElQPTEwLjE0Mi4xNS40Njo2MDk4OA0KbW9uaXRvckNvbm5l Y3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0Mi4xNS40MjozODkNCm1vbml0 b3JDb25uZWN0aW9uU3RhcnRUaW1lOiAyMDA5MDEyNjEyMTczNloNCm1vbml0 b3JDb25uZWN0aW9uQWN0aXZpdHlUaW1lOiAyMDA5MDEyNjEyMTczNloNCmVu dHJ5RE46IGNuPUNvbm5lY3Rpb24gMTMsY249Q29ubmVjdGlvbnMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249Q29ubmVjdGlvbiAwLGNuPUNv bm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczog bW9uaXRvckNvbm5lY3Rpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODI0Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyNFoNCm1vbml0b3JDb25uZWN0aW9u TnVtYmVyOiAwDQptb25pdG9yQ29ubmVjdGlvblByb3RvY29sOiAzDQptb25p dG9yQ29ubmVjdGlvbk9wc1JlY2VpdmVkOiAyDQptb25pdG9yQ29ubmVjdGlv bk9wc0V4ZWN1dGluZzogMQ0KbW9uaXRvckNvbm5lY3Rpb25PcHNQZW5kaW5n OiAwDQptb25pdG9yQ29ubmVjdGlvbk9wc0NvbXBsZXRlZDogMQ0KbW9uaXRv ckNvbm5lY3Rpb25HZXQ6IDINCm1vbml0b3JDb25uZWN0aW9uUmVhZDogMg0K bW9uaXRvckNvbm5lY3Rpb25Xcml0ZTogMA0KbW9uaXRvckNvbm5lY3Rpb25N YXNrOiByeA0KbW9uaXRvckNvbm5lY3Rpb25BdXRoekROOiBjbj1hZG1pbixv dT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQptb25pdG9yQ29ubmVjdGlvbkxp c3RlbmVyOiBsZGFwOi8vMTAuMTQyLjE1LjQyOjM4OQ0KbW9uaXRvckNvbm5l Y3Rpb25QZWVyRG9tYWluOiB1bmtub3duDQptb25pdG9yQ29ubmVjdGlvblBl ZXJBZGRyZXNzOiBJUD0xMC4xNDIuMTUuNDE6NDE4MDYNCm1vbml0b3JDb25u ZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUuNDI6Mzg5DQptb25p dG9yQ29ubmVjdGlvblN0YXJ0VGltZTogMjAwOTAxMjYwNDI4MjRaDQptb25p dG9yQ29ubmVjdGlvbkFjdGl2aXR5VGltZTogMjAwOTAxMjYwNDI4MjRaDQpl bnRyeUROOiBjbj1Db25uZWN0aW9uIDAsY249Q29ubmVjdGlvbnMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TWF4IEZpbGUgRGVzY3JpcHRv cnMsY249Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVj dENsYXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4 MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRv ckNvdW50ZXI6IDEwMjQNCmVudHJ5RE46IGNuPU1heCBGaWxlIERlc2NyaXB0 b3JzLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPVRvdGFsLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNyZWF0 b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0Mjgy MFoNCm1vbml0b3JDb3VudGVyOiAxNA0KZW50cnlETjogY249VG90YWwsY249 Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 Q3VycmVudCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQpt b25pdG9yQ291bnRlcjogMg0KZW50cnlETjogY249Q3VycmVudCxjbj1Db25u ZWN0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vi c2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRh YmFzZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0K Y3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVz dGFtcDogMjAwOTAxMjYwNDI4MjBaDQpyZWFkT25seTogRkFMU0UNCm5hbWlu Z0NvbnRleHRzOg0KbmFtaW5nQ29udGV4dHM6IGNuPWNvbmZpZw0KbmFtaW5n Q29udGV4dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCm5hbWluZ0Nv bnRleHRzOiBvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQptb25pdG9yQ29u dGV4dDogY249TW9uaXRvcg0KZW50cnlETjogY249RGF0YWJhc2VzLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249RnJvbnRlbmQsY249RGF0YWJh c2VzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yZWRJbmZvOiBmcm9udGVuZA0K bW9uaXRvcklzU2hhZG93OiBGQUxTRQ0KbmFtaW5nQ29udGV4dHM6DQpyZWFk T25seTogRkFMU0UNCmVudHJ5RE46IGNuPUZyb250ZW5kLGNuPURhdGFiYXNl cyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFzZSAw LGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVkSW5mbzog Y29uZmlnDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpuYW1pbmdDb250ZXh0 czogY249Y29uZmlnDQpyZWFkT25seTogRkFMU0UNCmVudHJ5RE46IGNuPURh dGFiYXNlIDAsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UN Cg0KZG46IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVh dG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4 MjBaDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JJc1NoYWRvdzogRkFM U0UNCm5hbWluZ0NvbnRleHRzOiBvdT1DT05URU5ULG89YWxjYXRlbCxjPWZy DQpyZWFkT25seTogRkFMU0UNCm9sbUJEQkVudHJ5Q2FjaGU6IDANCm9sbUJE QkROQ2FjaGU6IDANCm9sbUJEQklETENhY2hlOiAwDQpvbG1EYkRpcmVjdG9y eTogL3Zhci9vcGVubGRhcC1kYXRhL2JkYjEvDQplbnRyeUROOiBjbj1EYXRh YmFzZSAxLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1EYXRhYmFzZSAyLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpz dHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRv cnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIw Wg0KbW9uaXRvcmVkSW5mbzogYmRiDQptb25pdG9ySXNTaGFkb3c6IEZBTFNF DQpuYW1pbmdDb250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0K cmVhZE9ubHk6IEZBTFNFDQpvbG1CREJFbnRyeUNhY2hlOiAxDQpvbG1CREJE TkNhY2hlOiAxMDAwMjYxDQpvbG1CREJJRExDYWNoZTogMQ0Kb2xtRGJEaXJl Y3Rvcnk6IC92YXIvb3BlbmxkYXAtZGF0YS9iZGIyLw0KZW50cnlETjogY249 RGF0YWJhc2UgMixjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNy ZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0 MjgyMFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCm1vbml0b3JJc1NoYWRv dzogRkFMU0UNCm1vbml0b3JDb250ZXh0OiBjbj1Nb25pdG9yDQpyZWFkT25s eTogRkFMU0UNCmVudHJ5RE46IGNuPURhdGFiYXNlIDMsY249RGF0YWJhc2Vz LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUxpc3RlbmVycyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb250 YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyNjA0MjgyMFoNCmVudHJ5RE46IGNuPUxpc3RlbmVycyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUxpc3RlbmVyIDAsY249TGlzdGVu ZXJzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yQ29ubmVjdGlvbkxvY2FsQWRk cmVzczogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KZW50cnlETjogY249TGlzdGVu ZXIgMCxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3Ry dWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3Jz TmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkw MTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoN Cm1vbml0b3JDb25uZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUu MTcyOjM4OQ0KZW50cnlETjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMs Y249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TG9nLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2 MDQyODIwWg0KZW50cnlETjogY249TG9nLGNuPU1vbml0b3INCnN1YnNjaGVt YVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFM U0UNCg0KZG46IGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0 MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb25p dG9yT3BJbml0aWF0ZWQ6IDQwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDM4DQpl bnRyeUROOiBjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0K DQpkbjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0K bW9uaXRvck9wSW5pdGlhdGVkOiAxNA0KbW9uaXRvck9wQ29tcGxldGVkOiAx NA0KZW50cnlETjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPVVuYmluZCxjbj1PcGVyYXRpb25zLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJh dGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTI2MDQyODIwWg0KbW9uaXRvck9wSW5pdGlhdGVkOiAxMg0KbW9uaXRv ck9wQ29tcGxldGVkOiAxMg0KZW50cnlETjogY249VW5iaW5kLGNuPU9wZXJh dGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNj aGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U2VhcmNo LGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjcmVhdG9yc05hbWU6DQptb2RpZmll cnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yT3BJbml0 aWF0ZWQ6IDE0DQptb25pdG9yT3BDb21wbGV0ZWQ6IDEyDQplbnRyeUROOiBj bj1TZWFyY2gsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1Db21wYXJlLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0K c3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjcmVh dG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4 MjBaDQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRl ZDogMA0KZW50cnlETjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVyYXRp b25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv ck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNy ZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3Rh bXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQpt b25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1vZGlmeSxjbj1P cGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1v ZHJkbixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9k aWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBa DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvck9w SW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46 IGNuPU1vZHJkbixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVt YVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFM U0UNCg0KZG46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRv cnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIw Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6 IDANCmVudHJ5RE46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJh dGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTI2MDQyODIwWg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9y T3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPURlbGV0ZSxjbj1PcGVyYXRp b25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFiYW5kb24s Y249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JPcEluaXRp YXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQplbnRyeUROOiBjbj1B YmFuZG9uLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249RXh0ZW5kZWQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpz dHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0 b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0Mjgy MFoNCm1vbml0b3JPcEluaXRpYXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVk OiAwDQplbnRyeUROOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2 MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogZ2x1ZQ0KZW50cnlETjogY249T3Zl cmxheXMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNj aGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5 IDAsY249T3ZlcmxheXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JlZEluZm86 IGdsdWUNCm1vbml0b3JSdW50aW1lQ29uZmlnOiBGQUxTRQ0KZW50cnlETjog Y249T3ZlcmxheSAwLGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN1YnNjaGVt YVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFM U0UNCg0KZG46IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVj dENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQplbnRyeUROOiBj bj1TQVNMLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJz Y2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXRp c3RpY3MsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0K Y3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVz dGFtcDogMjAwOTAxMjYwNDI4MjBaDQplbnRyeUROOiBjbj1TdGF0aXN0aWNz LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249Qnl0ZXMsY249U3Rh dGlzdGljcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNO YW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlm eVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yQ291bnRlcjog NzExNTUxMzgNCmVudHJ5RE46IGNuPUJ5dGVzLGNuPVN0YXRpc3RpY3MsY249 TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFz U3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249UERVLGNuPVN0YXRpc3Rp Y3MsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y Q291bnRlck9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvckNvdW50ZXI6IDI1NjU4 Mw0KZW50cnlETjogY249UERVLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBGQUxTRQ0KDQpkbjogY249RW50cmllcyxjbj1TdGF0aXN0aWNzLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50 ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JDb3VudGVyOiAyNTY1NTgNCmVu dHJ5RE46IGNuPUVudHJpZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3RhdGlzdGljcyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3Vu dGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yQ291bnRlcjogMA0KZW50cnlE TjogY249UmVmZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3Vi c2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVz OiBGQUxTRQ0KDQpkbjogY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2 MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCmVu dHJ5RE46IGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRu OiBjbj1NYXgsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2Jq ZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9k aWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBa DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVk SW5mbzogMTYNCmVudHJ5RE46IGNuPU1heCxjbj1UaHJlYWRzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1heCBQZW5kaW5nLGNuPVRocmVh ZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JlZEluZm86IDANCmVudHJ5RE46 IGNuPU1heCBQZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2No ZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBG QUxTRQ0KDQpkbjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBa DQptb25pdG9yZWRJbmZvOiAyDQplbnRyeUROOiBjbj1PcGVuLGNuPVRocmVh ZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U3RhcnRpbmcs Y249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogMA0K ZW50cnlETjogY249U3RhcnRpbmcsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFkcyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2 MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogMg0KZW50cnlETjogY249QWN0aXZl LGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 UGVuZGluZyxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yZWRJ bmZvOiAwDQplbnRyeUROOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249QmFja2xvYWQsY249VGhyZWFk cyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3Jl ZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI2MDQyODIwWg0KbW9uaXRvcmVkSW5mbzogMg0KZW50cnlETjog Y249QmFja2xvYWQsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1TdGF0ZSxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQpt b25pdG9yZWRJbmZvOiB1bmtub3duDQplbnRyeUROOiBjbj1TdGF0ZSxjbj1U aHJlYWRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJz Y2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVJ1bnF1 ZXVlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCmVudHJ5RE46IGNuPVJ1 bnF1ZXVlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1l Og0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYw NDI4MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KZW50 cnlETjogY249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxP YmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4 MjBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KZW50cnlE TjogY249VGltZSxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249 U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVN0 YXJ0LGNuPVRpbWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JUaW1lc3RhbXA6 IDIwMDkwMTI2MDQyODIwWg0KZW50cnlETjogY249U3RhcnQsY249VGltZSxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1DdXJyZW50LGNuPVRp bWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTI2 MTIxNzM2Wg0KZW50cnlETjogY249Q3VycmVudCxjbj1UaW1lLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVVwdGltZSxjbj1UaW1lLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0 YW1wOiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAx MjYwNDI4MjBaDQptb25pdG9yZWRJbmZvOiAyODE1Ng0KZW50cnlETjogY249 VXB0aW1lLGNuPVRpbWUsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjog Y249VExTLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTI2MDQyODIwWg0KZW50cnlETjogY249VExTLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVdhaXRlcnMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyNjA0MjgyMFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYw NDI4MjBaDQplbnRyeUROOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog VFJVRQ0KDQpkbjogY249UmVhZCxjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNy ZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTI2MDQyODIwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNjA0 MjgyMFoNCm1vbml0b3JDb3VudGVyOiAyDQplbnRyeUROOiBjbj1SZWFkLGNu PVdhaXRlcnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249V3Jp dGUsY249V2FpdGVycyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNjA0MjgyMFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjYwNDI4MjBaDQptb25pdG9yQ291 bnRlcjogMA0KZW50cnlETjogY249V3JpdGUsY249V2FpdGVycyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IEZBTFNFDQoNCg== --0-2140963594-1232966602=:67255--

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by hyc＠symas.com 26 Jan '09

26 Jan '09

ando(a)sys-net.it wrote: > toby(a)inf.ed.ac.uk wrote: >> Hi there, is there any further debugging I could usefully carry out >> for this issue, or does it need someone who understands the code a bit >> better? > > It's not a debugging problem, but rather a design issue. The current > design makes use of the first AVA of the filter to decide how two > filters are compared. In your case, the first component is common to > all filters, so only the first occurrence of a search with that template > can be cached. This fact, to my knowledge, is undocumented, but there's > little to do except redesign this weighing criterium. As I already > pointed out, you need to make the most significant filter AVA appear > first in your filter template. Unless anyone voluteers for a complete > redesign [*] of this portion of slapo-pcache(5), I take your ITS as a > request to document this aspect of template design. The filter comparison function has been rewritten to compare all terms of the filter, instead of only the first. It now passes the simple cases from your previous followup. Please 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

Antwort: Re: Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 26 Jan '09

26 Jan '09

--0__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: multipart/alternative; Boundary="1__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112" --1__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable hmm.. bummer - I really have no idea what it could be(Berkeley doesn't = have a pthread_kill either as far as I can tell) - it always occurred when t= he system started paging. I added an extra GB Memory to the LPAR and it hasn't happened since... = As soon as I get some breathing room I'll set up a test bed and see if I c= an reproduce it for a stack trace.. Thanks for your help! Howard = Howard Chu = <hyc(a)symas.com> = = An 26.01.2009 10:38 Howard Allison = <howard.allison(a)pva.sozvers.a= t> Ko= pie openldap-its(a)openldap.org = Th= ema Re: Antwort: Re: (ITS#5837) = slapd pthread_kill Core Dump = AIX = = = = = = Howard Allison wrote: > How about libraries/libldap_r/thr_posix.c ? Look again - that's in ldap_pvt_thread_kill() and nothing ever referenc= es that function. > Thanks Howard, > Howard :-) > > Inactive hide details for Howard Chu ---26.01.2009 > 10:10:33---howard.allison@pva.sozvers.at wrote:Howard Chu ---26.01.20= 09 > 10:10:33---howard.allison@pva.sozvers.at wrote: > > > *Howard Chu <hyc(a)symas.com>* > > 26.01.2009 10:10 > > > > An > > howard.allison(a)pva.sozvers.at > > Kopie > > openldap-its(a)openldap.org > > Thema > > Re: (ITS#5837) slapd pthread_kill Core Dump AIX > > > > > howard.allison(a)pva.sozvers.at wrote: > > Full_Name: Howard Allison > > Version: 2.4.11 > > OS: AIX 6.1 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (194.153.217.235) > > > > > > After running for a few hours slapd crashes and dumps core. > > here is the output from dbx: > > > > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) > > 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) > > Nothing in the OpenLDAP code calls pthread_kill. > > You should look at a complete stack trace to see what code is calling= > this. It > doesn't sound like it has anything to do with us, at the moment. > > > > slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 wit= h these > > flags: > > --prefix=3D/opt/pware/openldap-2.4.11 --with-openssl --with-shared= =3Dyes > > --enable-policy --enable-unique --enable-ssl > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> hmm.. bummer - I really have no idea= what it could be(Berkeley doesn't have a pthread_kill either as far as= I can tell) - it always occurred when the system started paging.</font= > I added an extra GB Memory to the LPAR = and it hasn't happened since... As soon as I get some breathing room I'= ll set up a test bed and see if I can reproduce it for a stack trace.. = Thanks for your help! Howard <img width=3D"16" height=3D"16" src=3D"cid:1__=3D4EBBFFD9DFA6B1128f9e8a= 93d(a)pva.sozvers.at" border=3D"0" alt=3D"Inactive hide details for Howar= d Chu ---26.01.2009 10:38:50---Howard Allison wrote:">Howard Chu ---26.01.2009 10:38:50---Howard Allison wrote:= <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D4EBBFFD9= DFA6B1128f9e8a93d(a)pva.sozvers.at); background-repeat: no-repeat; " widt= h=3D"42%"> <ul> <ul> <ul> <ul>Howard Chu <hyc(a)symas.com>= 26.01.2009 10:38</ul> </ul> </ul> </ul> </td><td width=3D"58%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA6B1128f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">An</div></td><td width= =3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA6B1= 128f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> Howard Allison <howard.allison(a)pva.sozvers.at&g= t;</td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA6B1128f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">Kopie</div></td><td wi= dth=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA= 6B1128f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> openldap-its(a)openldap.org</td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA6B1128f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">Thema</div></td><td wi= dth=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA= 6B1128f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> Re: Antwort: Re: (ITS#5837) slapd pthread_kill Cor= e Dump AIX</td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA6B1128f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 4EBBFFD9DFA6B1128f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""></td></= tr> </table> </td></tr> </table> <tt>Howard Allison wrote: > How about libraries/libldap_r/thr_posix.c ? Look again - that's in ldap_pvt_thread_kill() and nothing ever referenc= es that function. > Thanks Howard, > Howard :-) > > Inactive hide details for Howard Chu ---26.01.2009 > 10:10:33---howard.allison@pva.sozvers.at wrote:Howard Chu ---26.01= .2009 > 10:10:33---howard.allison@pva.sozvers.at wrote: > > >                   &nb= sp;     *Howard Chu <hyc(a)symas.com>* > >                   &nb= sp;     26.01.2009 10:10 > > > > An > > howard.allison(a)pva.sozvers.at > > Kopie > > openldap-its(a)openldap.org > > Thema > > Re: (ITS#5837) slapd pthread_kill Core Dump AIX > > > > > howard.allison(a)pva.sozvers.at wrote: >  > Full_Name: Howard Allison >  > Version: 2.4.11 >  > OS: AIX 6.1 >  > URL: </tt><tt><a href=3D"ftp://ftp.openldap.org/incomin= g/">ftp://ftp.openldap.org/incoming/</a></tt><tt> >  > Submission from: (NULL) (194.153.217.235) >  > >  > >  > After running for a few hours slapd crashes and dumps c= ore. >  > here is the output from dbx: >  > >  > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) = >  > 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1)= > > Nothing in the OpenLDAP code calls pthread_kill. > > You should look at a complete stack trace to see what code is call= ing > this. It > doesn't sound like it has anything to do with us, at the moment.<b= r> >  > >  > slapd was compiled under AIX 6100-00-03-0808 using gcc = 4.2.0-3 with these >  > flags: >  > --prefix=3D/opt/pware/openldap-2.4.11 --with-openssl --= with-shared=3Dyes >  > --enable-policy --enable-unique --enable-ssl > --   -- Howard Chu   CTO, Symas Corp.           </tt><tt><a= href=3D"http://www.symas.com">http://www.symas.com</a></tt><tt>   Director, Highland Sun     </tt><tt><a href=3D"http:/= /highlandsun.com/hyc/">http://highlandsun.com/hyc/</a></tt><tt>   Chief Architect, OpenLDAP  </tt><tt><a href=3D"http://www.= openldap.org/project/">http://www.openldap.org/project/</a></tt><tt><br= > </tt> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112-- --0__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFFD9DFA6B1128f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: image/gif; name="pic21074.gif" Content-Disposition: inline; filename="pic21074.gif" Content-ID: <2__=4EBBFFD9DFA6B1128f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFFD9DFA6B1128f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFFD9DFA6B1128f9e8a93df938690918c4EBBFFD9DFA6B112--

1 0

Re: Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by hyc＠symas.com 26 Jan '09

26 Jan '09

Howard Allison wrote: > How about libraries/libldap_r/thr_posix.c ? Look again - that's in ldap_pvt_thread_kill() and nothing ever references that function. > Thanks Howard, > Howard :-) > > Inactive hide details for Howard Chu ---26.01.2009 > 10:10:33---howard.allison@pva.sozvers.at wrote:Howard Chu ---26.01.2009 > 10:10:33---howard.allison@pva.sozvers.at wrote: > > > *Howard Chu <hyc(a)symas.com>* > > 26.01.2009 10:10 > > > > An > > howard.allison(a)pva.sozvers.at > > Kopie > > openldap-its(a)openldap.org > > Thema > > Re: (ITS#5837) slapd pthread_kill Core Dump AIX > > > > > howard.allison(a)pva.sozvers.at wrote: > > Full_Name: Howard Allison > > Version: 2.4.11 > > OS: AIX 6.1 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (194.153.217.235) > > > > > > After running for a few hours slapd crashes and dumps core. > > here is the output from dbx: > > > > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) > > 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) > > Nothing in the OpenLDAP code calls pthread_kill. > > You should look at a complete stack trace to see what code is calling > this. It > doesn't sound like it has anything to do with us, at the moment. > > > > slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 with these > > flags: > > --prefix=/opt/pware/openldap-2.4.11 --with-openssl --with-shared=yes > > --enable-policy --enable-unique --enable-ssl > -- -- 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

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 26 Jan '09

26 Jan '09

--0__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: multipart/alternative; Boundary="1__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809" --1__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable How about libraries/libldap_r/thr_posix.c ? Thanks Howard, Howard :-) = Howard Chu = <hyc(a)symas.com> = = An 26.01.2009 10:10 howard.allison(a)pva.sozvers.at= Ko= pie openldap-its(a)openldap.org = Th= ema Re: (ITS#5837) slapd = pthread_kill Core Dump AIX = = = = = = = howard.allison(a)pva.sozvers.at wrote: > Full_Name: Howard Allison > Version: 2.4.11 > OS: AIX 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.153.217.235) > > > After running for a few hours slapd crashes and dumps core. > here is the output from dbx: > > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) > 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) Nothing in the OpenLDAP code calls pthread_kill. You should look at a complete stack trace to see what code is calling t= his. It doesn't sound like it has anything to do with us, at the moment. > > slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 with t= hese > flags: > --prefix=3D/opt/pware/openldap-2.4.11 --with-openssl --with-shared=3D= yes > --enable-policy --enable-unique --enable-ssl -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> How about libraries/libldap_r/thr_posix.c ? Thanks Howard, Howard :-) <img width=3D"16" height=3D"16" src=3D"cid:1__=3D4EBBFFD9DFA7C8098f9e8a= 93d(a)pva.sozvers.at" border=3D"0" alt=3D"Inactive hide details for Howar= d Chu ---26.01.2009 10:10:33---howard.allison@pva.sozvers.at wrote:"><f= ont color=3D"#424282">Howard Chu ---26.01.2009 10:10:33---howard.alliso= n(a)pva.sozvers.at wrote: <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D4EBBFFD9= DFA7C8098f9e8a93d(a)pva.sozvers.at); background-repeat: no-repeat; " widt= h=3D"42%"> <ul> <ul> <ul> <ul>Howard Chu <hyc(a)symas.com>= 26.01.2009 10:10</ul> </ul> </ul> </ul> </td><td width=3D"58%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA7C8098f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">An</div></td><td width= =3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA7C8= 098f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> howard.allison(a)pva.sozvers.at</td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA7C8098f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">Kopie</div></td><td wi= dth=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA= 7C8098f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> openldap-its(a)openldap.org</td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"67" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA7C8098f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""> <div align=3D"right">Thema</div></td><td wi= dth=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D4EBBFFD9DFA= 7C8098f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""> Re: (ITS#5837) slapd pthread_kill Core Dump AIX</f= ont></td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:3__=3D4EBBFFD9DFA7C8098f9e8a93d@pva.sozvers.at" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 4EBBFFD9DFA7C8098f9e8a93d(a)pva.sozvers.at" border=3D"0" alt=3D""></td></= tr> </table> </td></tr> </table> <tt>howard.allison(a)pva.sozvers.at wrote: > Full_Name: Howard Allison > Version: 2.4.11 > OS: AIX 6.1 > URL: </tt><tt><a href=3D"ftp://ftp.openldap.org/incoming/">ftp://f= tp.openldap.org/incoming/</a></tt><tt> > Submission from: (NULL) (194.153.217.235) > > > After running for a few hours slapd crashes and dumps core. > here is the output from dbx: > > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) > 0xd04a73c0 (pthread_kill+0xa0) 80410014       &nbsp= ; lwz   r2,0x14(r1) Nothing in the OpenLDAP code calls pthread_kill. You should look at a complete stack trace to see what code is calling t= his. It doesn't sound like it has anything to do with us, at the moment. > > slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 wit= h these > flags: > --prefix=3D/opt/pware/openldap-2.4.11 --with-openssl --with-shared= =3Dyes > --enable-policy --enable-unique --enable-ssl --   -- Howard Chu   CTO, Symas Corp.           </tt><tt><a= href=3D"http://www.symas.com">http://www.symas.com</a></tt><tt>   Director, Highland Sun     </tt><tt><a href=3D"http:/= /highlandsun.com/hyc/">http://highlandsun.com/hyc/</a></tt><tt>   Chief Architect, OpenLDAP  </tt><tt><a href=3D"http://www.= openldap.org/project/">http://www.openldap.org/project/</a></tt><tt><br= > </tt> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809-- --0__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFFD9DFA7C8098f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: image/gif; name="pic15899.gif" Content-Disposition: inline; filename="pic15899.gif" Content-ID: <2__=4EBBFFD9DFA7C8098f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFFD9DFA7C8098f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFFD9DFA7C8098f9e8a93df938690918c4EBBFFD9DFA7C809--

1 0

Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by hyc＠symas.com 26 Jan '09

26 Jan '09

howard.allison(a)pva.sozvers.at wrote: > Full_Name: Howard Allison > Version: 2.4.11 > OS: AIX 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.153.217.235) > > > After running for a few hours slapd crashes and dumps core. > here is the output from dbx: > > IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) > 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) Nothing in the OpenLDAP code calls pthread_kill. You should look at a complete stack trace to see what code is calling this. It doesn't sound like it has anything to do with us, at the moment. > > slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 with these > flags: > --prefix=/opt/pware/openldap-2.4.11 --with-openssl --with-shared=yes > --enable-policy --enable-unique --enable-ssl -- -- 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#5448) CONTRIB: Java slapd
by hyc＠symas.com 25 Jan '09

25 Jan '09

This is a multi-part message in MIME format. --------------070904040708010009080404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 0.0.1 > OS: > URL: ftp://ftp.openldap.org/incoming/jslapd.tgz > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc For completeness sake, here's the source code... ;) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------070904040708010009080404 Content-Type: text/x-java; name="jslapd.java" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jslapd.java" /* * Java wrapper for slapd */ import java.util.*; import java.io.*; class jslapd { public static void main(String[] args) { args[0] = args[0].concat("/slapd"); try { Process p = Runtime.getRuntime().exec(args); InputStream stderr = p.getErrorStream(); InputStreamReader isr = new InputStreamReader(stderr); BufferedReader br = new BufferedReader(isr); String line = null; while ((line = br.readLine()) != null) System.out.println(line); p.waitFor(); } catch (Throwable t) { t.printStackTrace(); } } } --------------070904040708010009080404--

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 25 Jan '09

25 Jan '09

Rodrigo Costa wrote: > Howard, > > I tested the HEAD load last night. The results I believe are partial. Thanks for the feedback, please try the new patch in HEAD. > > The memory stay stable and the use was much lower. I had in my slapd.conf the following cache boundaries : > > line 122 (cachesize 1000) > line 123 (idlcachesize 1000) > line 124 (dncachesize 2000) > > Which make with the new load to consume much less memory and stay stable. > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 20715 ldap 18 0 184m 73m 68m S 0 0.6 174:05.81 slapd > > But by the other hand I use the monitor information to check the cache usage. I would notice that now dncache is keeping around the boundary I put of 20000 but the cache is now fixed as 1, not 1000. See information below : > > readOnly: FALSE > olmBDBEntryCache: 1 > olmBDBDNCache: 2185 > olmBDBIDLCache: 1 > olmDbDirectory: /var/openldap-data/bdb2/ > entryDN: cn=Database 2,cn=Databases,cn=Monitor > > This kept around this all the time I was making a search in DB. > > Before this load with this possible DN cache boundary solution I made the ldapsearch in around 7 minutes, for the first time not cached yet. And around 4 minutes after the entrances were cached. > > Now with this new load I made the search and it took : > > 1000000 > > real 174m6.486s > user 0m43.746s > sys 0m16.923s > > > Almost 3 hours. It's ok that I didn't tune the cache sizes but I was at least expecting the olmBDBEntryCache would now follow the 1000 boundary and not single 1. > > I believe this is what is not making this huge performance difference and not the olmBDBDNCache. > > Please confirm this is some tuning missing or if something else like the olmBDBEntryCache would be improved. > > In terms of memory usage now it is respecting but the performance, probably based in the olmBDBEntryCache only using 1 position, is much worst. > > Please also let me know if you think this performance degradation and the olmBDBEntryCache marking 1 is a tuning issue or something still need to be modified in the code. > > Thanks for the fast solution for this issue since this would be affecting all systems and types of DB. > > Rodrigo. -- -- 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#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 25 Jan '09

25 Jan '09

--0-2097254313-1232882465=:12285 Content-Type: text/plain; charset=us-ascii Howard, I tested the HEAD load last night. The results I believe are partial. The memory stay stable and the use was much lower. I had in my slapd.conf the following cache boundaries : line 122 (cachesize 1000) line 123 (idlcachesize 1000) line 124 (dncachesize 2000) Which make with the new load to consume much less memory and stay stable. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20715 ldap 18 0 184m 73m 68m S 0 0.6 174:05.81 slapd But by the other hand I use the monitor information to check the cache usage. I would notice that now dncache is keeping around the boundary I put of 20000 but the cache is now fixed as 1, not 1000. See information below : readOnly: FALSE olmBDBEntryCache: 1 olmBDBDNCache: 2185 olmBDBIDLCache: 1 olmDbDirectory: /var/openldap-data/bdb2/ entryDN: cn=Database 2,cn=Databases,cn=Monitor This kept around this all the time I was making a search in DB. Before this load with this possible DN cache boundary solution I made the ldapsearch in around 7 minutes, for the first time not cached yet. And around 4 minutes after the entrances were cached. Now with this new load I made the search and it took : 1000000 real 174m6.486s user 0m43.746s sys 0m16.923s Almost 3 hours. It's ok that I didn't tune the cache sizes but I was at least expecting the olmBDBEntryCache would now follow the 1000 boundary and not single 1. I believe this is what is not making this huge performance difference and not the olmBDBDNCache. Please confirm this is some tuning missing or if something else like the olmBDBEntryCache would be improved. In terms of memory usage now it is respecting but the performance, probably based in the olmBDBEntryCache only using 1 position, is much worst. Please also let me know if you think this performance degradation and the olmBDBEntryCache marking 1 is a tuning issue or something still need to be modified in the code. Thanks for the fast solution for this issue since this would be affecting all systems and types of DB. Rodrigo. --- On Fri, 1/23/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)OpenLDAP.org > Date: Friday, January 23, 2009, 9:57 PM > Rodrigo Costa wrote: > > Howard, > > > > Is there any expected date for this? > > A patch is now available in CVS, please test and report > back. > > -- -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/ --0-2097254313-1232882465=:12285 Content-Type: text/plain; name="monitor_7.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor_7.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogT3BlbkxEQVA6IHNs YXBkIDIuWCAoSmFuIDI1IDIwMDkgMDA6MzA6MDUpDQplbnRyeUROOiBjbj1N b25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUJhY2tlbmRzLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1 MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogY29uZmlnDQptb25pdG9yZWRJbmZv OiBsZGlmDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JlZEluZm86IG1v bml0b3INCmVudHJ5RE46IGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog VFJVRQ0KDQpkbjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUw MzIxNThaDQptb25pdG9yZWRJbmZvOiBjb25maWcNCm1vbml0b3JSdW50aW1l Q29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAyLjE2Ljg0MC4xLjEx MzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRz LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUJhY2tlbmQgMSxj bj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogbGRp Zg0KbW9uaXRvclJ1bnRpbWVDb25maWc6IFRSVUUNCnN1cHBvcnRlZENvbnRy b2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQplbnRyeUROOiBjbj1CYWNr ZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQpt b25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JSdW50aW1lQ29uZmlnOiBUUlVF DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEuMTINCnN1cHBvcnRlZENv bnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0ZWRDb250 cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1cHBvcnRlZENvbnRy b2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBvcnRlZENvbnRyb2w6 IDEuMy42LjEuMS4xMy4xDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEu MTMuMg0Kc3VwcG9ydGVkQ29udHJvbDogMS4zLjYuMS40LjEuNDIwMy4xLjEw LjENCnN1cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4xNDEz DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni4xMS43 LjINCmVudHJ5RE46IGNuPUJhY2tlbmQgMixjbj1CYWNrZW5kcyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1CYWNrZW5kIDMsY249QmFja2Vu ZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCm1v bml0b3JSdW50aW1lQ29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAy LjE2Ljg0MC4xLjExMzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAz LGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBj bj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNu PUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFz czogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KZW50cnlETjogY249Q29u bmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1Db25u ZWN0aW9uIDEwLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvckNvbm5lY3Rpb24NCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1 MTMwNTA0Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTEzMDUwNVoNCm1v bml0b3JDb25uZWN0aW9uTnVtYmVyOiAxMA0KbW9uaXRvckNvbm5lY3Rpb25Q cm90b2NvbDogMw0KbW9uaXRvckNvbm5lY3Rpb25PcHNSZWNlaXZlZDogMg0K bW9uaXRvckNvbm5lY3Rpb25PcHNFeGVjdXRpbmc6IDENCm1vbml0b3JDb25u ZWN0aW9uT3BzUGVuZGluZzogMA0KbW9uaXRvckNvbm5lY3Rpb25PcHNDb21w bGV0ZWQ6IDENCm1vbml0b3JDb25uZWN0aW9uR2V0OiAyDQptb25pdG9yQ29u bmVjdGlvblJlYWQ6IDINCm1vbml0b3JDb25uZWN0aW9uV3JpdGU6IDANCm1v bml0b3JDb25uZWN0aW9uTWFzazogcngNCm1vbml0b3JDb25uZWN0aW9uTGlz dGVuZXI6IGxkYXA6Ly8xMC4xNDIuMTUuNDI6Mzg5DQptb25pdG9yQ29ubmVj dGlvblBlZXJEb21haW46IHVua25vd24NCm1vbml0b3JDb25uZWN0aW9uUGVl ckFkZHJlc3M6IElQPTEwLjE0Mi4xNS40Njo1NTE1OA0KbW9uaXRvckNvbm5l Y3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0Mi4xNS40MjozODkNCm1vbml0 b3JDb25uZWN0aW9uU3RhcnRUaW1lOiAyMDA5MDEyNTEzMDUwNFoNCm1vbml0 b3JDb25uZWN0aW9uQWN0aXZpdHlUaW1lOiAyMDA5MDEyNTEzMDUwNVoNCmVu dHJ5RE46IGNuPUNvbm5lY3Rpb24gMTAsY249Q29ubmVjdGlvbnMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TWF4IEZpbGUgRGVzY3JpcHRv cnMsY249Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVj dENsYXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIx NThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRv ckNvdW50ZXI6IDEwMjQNCmVudHJ5RE46IGNuPU1heCBGaWxlIERlc2NyaXB0 b3JzLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPVRvdGFsLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNyZWF0 b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1 OFoNCm1vbml0b3JDb3VudGVyOiAxMQ0KZW50cnlETjogY249VG90YWwsY249 Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 Q3VycmVudCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQpt b25pdG9yQ291bnRlcjogMQ0KZW50cnlETjogY249Q3VycmVudCxjbj1Db25u ZWN0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vi c2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRh YmFzZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0K Y3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVz dGFtcDogMjAwOTAxMjUwMzIxNThaDQpyZWFkT25seTogRkFMU0UNCm5hbWlu Z0NvbnRleHRzOg0KbmFtaW5nQ29udGV4dHM6IGNuPWNvbmZpZw0KbmFtaW5n Q29udGV4dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCm5hbWluZ0Nv bnRleHRzOiBvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQptb25pdG9yQ29u dGV4dDogY249TW9uaXRvcg0KZW50cnlETjogY249RGF0YWJhc2VzLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249RnJvbnRlbmQsY249RGF0YWJh c2VzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yZWRJbmZvOiBmcm9udGVuZA0K bW9uaXRvcklzU2hhZG93OiBGQUxTRQ0KbmFtaW5nQ29udGV4dHM6DQpyZWFk T25seTogRkFMU0UNCmVudHJ5RE46IGNuPUZyb250ZW5kLGNuPURhdGFiYXNl cyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFzZSAw LGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzog Y29uZmlnDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpuYW1pbmdDb250ZXh0 czogY249Y29uZmlnDQpyZWFkT25seTogRkFMU0UNCmVudHJ5RE46IGNuPURh dGFiYXNlIDAsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UN Cg0KZG46IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVh dG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIx NThaDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JJc1NoYWRvdzogRkFM U0UNCm5hbWluZ0NvbnRleHRzOiBvdT1DT05URU5ULG89YWxjYXRlbCxjPWZy DQpyZWFkT25seTogRkFMU0UNCm9sbUJEQkVudHJ5Q2FjaGU6IDANCm9sbUJE QkROQ2FjaGU6IDANCm9sbUJEQklETENhY2hlOiAwDQpvbG1EYkRpcmVjdG9y eTogL3Zhci9vcGVubGRhcC1kYXRhL2JkYjEvDQplbnRyeUROOiBjbj1EYXRh YmFzZSAxLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1EYXRhYmFzZSAyLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpz dHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRv cnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4 Wg0KbW9uaXRvcmVkSW5mbzogYmRiDQptb25pdG9ySXNTaGFkb3c6IEZBTFNF DQpuYW1pbmdDb250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0K cmVhZE9ubHk6IEZBTFNFDQpvbG1CREJFbnRyeUNhY2hlOiAxDQpvbG1CREJE TkNhY2hlOiAyMTg1DQpvbG1CREJJRExDYWNoZTogMQ0Kb2xtRGJEaXJlY3Rv cnk6IC92YXIvb3BlbmxkYXAtZGF0YS9iZGIyLw0KZW50cnlETjogY249RGF0 YWJhc2UgMixjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0K c3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0 b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1 OFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCm1vbml0b3JJc1NoYWRvdzog RkFMU0UNCm1vbml0b3JDb250ZXh0OiBjbj1Nb25pdG9yDQpyZWFkT25seTog RkFMU0UNCmVudHJ5RE46IGNuPURhdGFiYXNlIDMsY249RGF0YWJhc2VzLGNu PU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUxpc3RlbmVycyxjbj1N b25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWlu ZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1l c3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5 MDEyNTAzMjE1OFoNCmVudHJ5RE46IGNuPUxpc3RlbmVycyxjbj1Nb25pdG9y DQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRp bmF0ZXM6IFRSVUUNCg0KZG46IGNuPUxpc3RlbmVyIDAsY249TGlzdGVuZXJz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVk T2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjUwMzIxNThaDQptb25pdG9yQ29ubmVjdGlvbkxvY2FsQWRkcmVz czogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KZW50cnlETjogY249TGlzdGVuZXIg MCxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjog Y249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3RydWN0 dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1 MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1v bml0b3JDb25uZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUuMTcy OjM4OQ0KZW50cnlETjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249 TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFz U3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TG9nLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3Jl YXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDog MjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMy MTU4Wg0KZW50cnlETjogY249TG9nLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UN Cg0KZG46IGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9i amVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQpt b2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1 OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9y T3BJbml0aWF0ZWQ6IDMyDQptb25pdG9yT3BDb21wbGV0ZWQ6IDMxDQplbnRy eUROOiBjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpk bjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1l Og0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUw MzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9u aXRvck9wSW5pdGlhdGVkOiAxMQ0KbW9uaXRvck9wQ29tcGxldGVkOiAxMQ0K ZW50cnlETjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPVVuYmluZCxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlv bg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTI1MDMyMTU4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAxMA0KbW9uaXRvck9w Q29tcGxldGVkOiAxMA0KZW50cnlETjogY249VW5iaW5kLGNuPU9wZXJhdGlv bnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U2VhcmNoLGNu PU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yT3BlcmF0aW9uDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNO YW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlm eVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yT3BJbml0aWF0 ZWQ6IDExDQptb25pdG9yT3BDb21wbGV0ZWQ6IDEwDQplbnRyeUROOiBjbj1T ZWFyY2gsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1Db21wYXJlLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3Ry dWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNTha DQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRlZDog MA0KZW50cnlETjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVyYXRpb25z LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9w ZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25p dG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1vZGlmeSxjbj1PcGVy YXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJz Y2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZHJk bixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RD bGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZp ZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQpt b2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvck9wSW5p dGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNu PU1vZHJkbixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UN Cg0KZG46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0K bW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDAN CmVudHJ5RE46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlv bg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTI1MDMyMTU4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BD b21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25z LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFiYW5kb24sY249 T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JPcEluaXRpYXRl ZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQplbnRyeUROOiBjbj1BYmFu ZG9uLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249RXh0ZW5kZWQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3Jz TmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkw MTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoN Cm1vbml0b3JPcEluaXRpYXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAw DQplbnRyeUROOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3Jl YXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDog MjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMy MTU4Wg0KbW9uaXRvcmVkSW5mbzogZ2x1ZQ0KZW50cnlETjogY249T3Zlcmxh eXMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5IDAs Y249T3ZlcmxheXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JlZEluZm86IGds dWUNCm1vbml0b3JSdW50aW1lQ29uZmlnOiBGQUxTRQ0KZW50cnlETjogY249 T3ZlcmxheSAwLGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UN Cg0KZG46IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmll cnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQplbnRyeUROOiBjbj1T QVNMLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXRpc3Rp Y3MsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y Q29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjUwMzIxNThaDQplbnRyeUROOiBjbj1TdGF0aXN0aWNzLGNu PU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249Qnl0ZXMsY249U3RhdGlz dGljcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0 b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1l Og0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yQ291bnRlcjogMjc3 MjI1OTExDQplbnRyeUROOiBjbj1CeXRlcyxjbj1TdGF0aXN0aWNzLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVBEVSxjbj1TdGF0aXN0aWNz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNv dW50ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpj cmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0 YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JDb3VudGVyOiAxMDAwNTk3 DQplbnRyeUROOiBjbj1QRFUsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1FbnRyaWVzLGNuPVN0YXRpc3RpY3MsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRl ck9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvckNvdW50ZXI6IDEwMDA1NzcNCmVu dHJ5RE46IGNuPUVudHJpZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3RhdGlzdGljcyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3Vu dGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yQ291bnRlcjogMA0KZW50cnlE TjogY249UmVmZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3Vi c2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVz OiBGQUxTRQ0KDQpkbjogY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1 MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCmVu dHJ5RE46IGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRu OiBjbj1NYXgsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2Jq ZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9k aWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNTha DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVk SW5mbzogMTYNCmVudHJ5RE46IGNuPU1heCxjbj1UaHJlYWRzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1heCBQZW5kaW5nLGNuPVRocmVh ZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JlZEluZm86IDANCmVudHJ5RE46 IGNuPU1heCBQZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2No ZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBG QUxTRQ0KDQpkbjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNTha DQptb25pdG9yZWRJbmZvOiAyDQplbnRyeUROOiBjbj1PcGVuLGNuPVRocmVh ZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U3RhcnRpbmcs Y249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogMA0K ZW50cnlETjogY249U3RhcnRpbmcsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFkcyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1 MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogMQ0KZW50cnlETjogY249QWN0aXZl LGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 UGVuZGluZyxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yZWRJ bmZvOiAwDQplbnRyeUROOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249QmFja2xvYWQsY249VGhyZWFk cyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3Jl ZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KbW9uaXRvcmVkSW5mbzogMQ0KZW50cnlETjog Y249QmFja2xvYWQsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1TdGF0ZSxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy NTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQpt b25pdG9yZWRJbmZvOiB1bmtub3duDQplbnRyeUROOiBjbj1TdGF0ZSxjbj1U aHJlYWRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJz Y2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVJ1bnF1 ZXVlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCmVudHJ5RE46IGNuPVJ1 bnF1ZXVlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1l Og0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUw MzIxNThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KZW50 cnlETjogY249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxP YmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIx NThaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KZW50cnlE TjogY249VGltZSxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249 U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVN0 YXJ0LGNuPVRpbWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KZW50cnlETjogY249U3RhcnQsY249VGltZSxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1DdXJyZW50LGNuPVRp bWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyNTAzMjE1OFoNCm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTI1 MTMwNTA1Wg0KZW50cnlETjogY249Q3VycmVudCxjbj1UaW1lLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVVwdGltZSxjbj1UaW1lLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0 YW1wOiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAx MjUwMzIxNThaDQptb25pdG9yZWRJbmZvOiAzNDk4Nw0KZW50cnlETjogY249 VXB0aW1lLGNuPVRpbWUsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjog Y249VExTLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTI1MDMyMTU4Wg0KZW50cnlETjogY249VExTLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVdhaXRlcnMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyNTAzMjE1OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUw MzIxNThaDQplbnRyeUROOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog VFJVRQ0KDQpkbjogY249UmVhZCxjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNy ZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTI1MDMyMTU4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyNTAz MjE1OFoNCm1vbml0b3JDb3VudGVyOiAxDQplbnRyeUROOiBjbj1SZWFkLGNu PVdhaXRlcnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249V3Jp dGUsY249V2FpdGVycyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyNTAzMjE1OFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjUwMzIxNThaDQptb25pdG9yQ291 bnRlcjogMA0KZW50cnlETjogY249V3JpdGUsY249V2FpdGVycyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IEZBTFNFDQoNCg== --0-2097254313-1232882465=:12285--

1 0

(ITS#5905) [patch] autoconf should check for uuid functions
by richton＠nbcs.rutgers.edu 24 Jan '09

24 Jan '09

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/openldap-uuidunparse.patch Submission from: (NULL) (128.6.68.244) The recent fix for ITS # 5888 unmasked this presumably long-standing issue. uuid_create and uuid_unparse_lower are used without autoconf verifying them first. An up-to-pat ch Solaris 9, in particular, is an example of a platform where uuid_generate exists without uuid_unparse_lower. Google seems to show that older Linux ~2006 has a similar situation.

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by jclarke＠linagora.com 24 Jan '09

24 Jan '09

Quanah Gibson-Mount wrote: > --On Saturday, January 24, 2009 3:19 PM +0000 jclarke(a)linagora.com wrote: > >> Currently, each description offers different levels and different >> descriptions. In particular, only the first mentions the keywords (as >> well as integers). None mention the "None" level. > > I disagree. From slapd.conf(5): > > loglevel <integer> [...] > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > > I see "none" documented right there. Yes, absolutely. I was referring only to the admin guide. This man page is indeed where I copied that definition from for the patch to the admin guide :) Jonathan -- Jonathan Clarke -- LinID - Open Source Identity Management --------------------------------------------------------------- Linagora 27 rue de Berri, 75008 Paris Tel: 01 58 18 68 28 / 06 99 60 03 10 --------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org/ ---------------------------------------------------------------

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by quanah＠zimbra.com 24 Jan '09

24 Jan '09

--On Saturday, January 24, 2009 3:19 PM +0000 jclarke(a)linagora.com wrote: > Currently, each description offers different levels and different > descriptions. In particular, only the first mentions the keywords (as > well as integers). None mention the "None" level. I disagree. From slapd.conf(5): loglevel <integer> [...] 32768 (0x8000 none) only messages that get logged whatever log level is set I see "none" documented right there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by quanah＠zimbra.com 24 Jan '09

24 Jan '09

--On Saturday, January 24, 2009 10:51 PM +0000 ghenry(a)suretecsystems.com wrote: > The man pages always have the most details, but I think what ever the code > has regarding options is the master source. > > Can anyone clarify? Hm, I was under the impression that -d (debug level) and LOG level were different. I.e., they don't always apply straight across. -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Some general operation and status messages are printed for any value of debug-level. debug-level is taken as a bit string, with each bit correspond- ing to a different kind of debugging information. See <ldap_log.h> for details. Comma-separated arrays of friendly names can be specified to select debugging output of the corre- sponding debugging information. All the names recognized by the loglevel directive described in slapd.conf(5) are supported. If debug-level is ?, a list of installed levels is printed, and slapd exits. And the man page for slapd seems to back that up. I.e., any LOG level setting works with -d, but there may be -d options that are beyond what LOG level supports. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs