- openldap-bugs - openldap.org

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by hyc＠symas.com 28 Jan '09

28 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> OK, makes sense. But perhaps creating entries on the stack could be >> deprecated now that entries are pooled and reused by calling >> entry_alloc() entry_free(). This is just food for thoughts, we could as >> well leave all those flags 'round, if we can streamline their handling. > > I think we might as well leave them. Since most are for saving memory, > might even want to expand them eventually. (E.g. separate flags for > _which_ parts of an entry are modifiable. Modifiable attribute list, > DNs, values _in_ attribute list, etc.) > > For that matter, looking at entry_free/entry_alloc, I don't see how that > pooling saves more than it costs. It saves 1 malloc for the Entry > structure, but not the mallocs for the DN and attribute list. And it > costs two global mutex lock/unlocks per entry, in entry_alloc() and > entry_free(). An entry on the stack avoids both malloc and locks. Yes, using the stack is still preferable when it's doable. The point of entry_alloc() was to avoid heap fragmentation, not to generally save on mallocs. It might make sense to turn the entry lists into per-thread lists, to avoid locks in the default cases. But if you follow this path to completion, that turns into re-implementing tcmalloc ("tc" stands for "thread-caching" which is exactly what we would be duplicating...). As for the attribute list: attr_alloc() is also pre-allocated for the same reason. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by Ulrich.Windl＠rz.uni-regensburg.de 27 Jan '09

27 Jan '09

Full_Name: Ulrich Windl Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.156.178) Looking for a threaded AVL tree implementation that is supposed to work, I found libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but there's thing that worries me: tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the routine' stack. While locating the element to delete, it pushes the parent node onto the stack. So from my knowledge this means that for a perfectly filled balanced tree, the stack will overflow when the tree consists of 2^8 (2^0 + 2^1 + 2^2 + ... + 2^7) or more nodes, and you are locating a leaf node. Maybe even with fewer nodes. As the algorithm also pushes an other element onto the stack, the problem could appear even before 128 nodes. If the problem occurs, I'd suspect data corruption at least, because one stack will overwrite the other stack. I've spotted these uses (besides /libraries/liblutil/testtavl.c) of tavl_delete(): servers/slapd/overlays/translucent.c, servers/slapd/overlays/pcache.c I don't understand that code that much, but if the TAVL isn't used in a very controlled way (i.e. limiting the number of possible nodes), a problem may be triggered. I also noticed that the limitation in the code exists for some time already.

1 0

(ITS#5908) slapo-unique man page misleading
by magne.land＠citrix.com 27 Jan '09

27 Jan '09

Full_Name: Magne Land Version: 2.3.43 OS: RHEL 5.1 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.37.244.20) Currently the man page of slapo-unique says "enforce uniqueness", which I find misleading. Would it be possible to change it to say "makes the best effort to enforce uniqueness" or something to that effect?

1 0

Re: (ITS#5903) memberof stacked instance member-attr delete failure
by ando＠sys-net.it 27 Jan '09

27 Jan '09

hyc(a)symas.com wrote: > mbackes(a)symas.com wrote: >> Full_Name: Matthew Backes >> Version: 2.4, head >> OS: any >> URL: >> Submission from: (NULL) (76.88.99.93) >> >> >> If slapo-memberof is instanced more than once, deleting the >> member-attr values from a group or deleting the group object will not >> remove the memberof-attr values from the members. >> >> Adds are not affected. >> >> Internally, the operation fails because it tries using the >> memberof-attribute name from the last memberof instance in the stack. > > The memberOf code is using a single static variable to hold its state. This is > obviously broken. It's also using thread keys for its temporary storage, which > is totally unnecessary; it should simply use its own callback and the > cb_private field of that callback. As such, much of this code needs to be > gutted and rewritten. See also ITS#5654. 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

Re: (ITS#5903) memberof stacked instance member-attr delete failure
by hyc＠symas.com 27 Jan '09

27 Jan '09

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, head > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > If slapo-memberof is instanced more than once, deleting the > member-attr values from a group or deleting the group object will not > remove the memberof-attr values from the members. > > Adds are not affected. > > Internally, the operation fails because it tries using the > memberof-attribute name from the last memberof instance in the stack. The memberOf code is using a single static variable to hold its state. This is obviously broken. It's also using thread keys for its temporary storage, which is totally unnecessary; it should simply use its own callback and the cb_private field of that callback. As such, much of this code needs to be gutted and rewritten. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5907) accesslog should use overlay BackendInfo to read old entry
by rein＠OpenLDAP.org 27 Jan '09

27 Jan '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I use accesslog stacked above the glue overlay to have it log access to all of the glued databases. When accesslog reads the old entry it goes directly to the original BackendInfo, which causes it to not find entries in the subordinate DBs. A fix is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by carl.johnstone＠gmgrd.co.uk 27 Jan '09

27 Jan '09

I'm seeing the same think on a 3-way multi-master setup here. Two servers (#001 & #002) are currently sat next to each other. The third (#003) is at a remote location. We're currently doing all amends through #001, although in the long term we'll be doing amends through all the servers. When I checked them yesterday I spotted that the remote server had a corrupt contextCSN for server #001. I dropped the DB and synced both the config and data from the main server again overnight. On checking again today the contextCSN is once again corrupt. In my case it's the first 8 bytes rather than the first 4. I'm running 2.4.13 with bdb 4.7.25 (first 3 patches applied). build: ./configure --enable-dynamic --enable-crypt --enable-modules=yes --enable-backends=mod --enable-overlays=mod --enable-sql=no --enable-ndb=no Carl

1 0

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

27 Jan '09

Howard, One more comment. If you take a longer time between the ldapsearches the issue doesn't appear sometimes. So you need to start the first ldapsearh and like 15 seconds later start the second one. With this scenario the problem will for sure appear. In this way we will see large chunks of memory being allocated and after it stabilizes the query get stuck returning as the issue before 16 records per minute, or very slow and getting stuck all the time. 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, 11:16 PM > rlvcosta(a)yahoo.com wrote: > > 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. > > We may need to have sample data from you to reproduce this > situation. I > haven't seen anything like it on my tests. Running two > searches simultaneously > still behaves normally for me. > > > > The scenario was : > > Likewise, the exact commands and arguments will be > needed... > > > > 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. > > -- > -- 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 27 Jan '09

27 Jan '09

Howard, One more comment. If you take a longer time between the ldapsearches the issue doesn't appear sometimes. So you need to start the first ldapsearh and like 15 seconds later start the second one. With this scenario the problem will for sure appear. In this way we will see large chunks of memory being allocated and after it stabilizes the query get stuck returning as the issue before 16 records per minute, or very slow and getting stuck all the time. 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, 11:16 PM > rlvcosta(a)yahoo.com wrote: > > 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. > > We may need to have sample data from you to reproduce this > situation. I > haven't seen anything like it on my tests. Running two > searches simultaneously > still behaves normally for me. > > > > The scenario was : > > Likewise, the exact commands and arguments will be > needed... > > > > 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. > > -- > -- 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 27 Jan '09

27 Jan '09

--0-1644073040-1233052012=:88983 Content-Type: text/plain; charset=us-ascii Howard, Initially the search behaves normally but after some time something changes and memory starts to be consumed again until it reaches another stable condition, even very large(around 2G) and the search get stuck as before. Once search get stuck even I stop both searches and start a new one it get stuck. So in my test I stopped my 2 searches and started a new one. Then I saw the new search with only 240 returns and then get stuck entering in the same model as before with 16 entrances in bursts in order of minutes to enter in these bursts. As I tried to explain this appears to happen when the seconds ldapsearch, started at a later time than the first ldapsearch, reaches the dn cachesize. This is what appears to happen. I beleive for you to reproduce you need to have a DB large enough and a slapd.conf where dn cachesize will overpass the memory boundary imposed. Then after the second ldapsearch memory boundary is reached the issue should appear. The commands I runned were : time ldapsearch -LLL -x -D "cn=admin,ou=INDEXES,o=alcatel,c=fr" -w secret -b "ou=INDEXES,o=alcatel,c=fr" -H ldap://10.142.15.42:389 'pnnumber=*' > /backup/temp.ldif and time ldapsearch -LLL -x -D "cn=admin,ou=INDEXES,o=alcatel,c=fr" -w secret -b "ou=INDEXES,o=alcatel,c=fr" -H ldap://10.142.15.42:389 'pnnumber=*'| egrep -e '^pnnumber*' |wc -l With the first command, redirecting to a file, I can tail or wc and see it's progress. After the second ldapsearch process starts to make slapd consume memory in large chunks until the new 2G boundary is reached. Once this happen the search get stuck as before with the single process returning 16 records per minute(s). Once this condition is reached even stopping the old searches and starting new ones the rate will be very slow, like 16 reports per minute(s). It get stuck as before. Please see attached a single entrance in my DB where you can change DB keys and load it as needed. Thanks, 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, 11:16 PM > rlvcosta(a)yahoo.com wrote: > > 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. > > We may need to have sample data from you to reproduce this > situation. I > haven't seen anything like it on my tests. Running two > searches simultaneously > still behaves normally for me. > > > > The scenario was : > > Likewise, the exact commands and arguments will be > needed... > > > > 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. > > -- > -- 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-1644073040-1233052012=:88983 Content-Type: text/plain; name="one_INDEXES_entrance.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="one_INDEXES_entrance.txt" ZG46IHBubnVtYmVyPVwyQjU1NDE4NDAxMTQ5NixvdT1yYW5nZTk2LG91PW1z aXNkbixvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQpzdWJwbmlkOiAwDQpo b3N0OiBicnRsZHAxMmUNCm9iamVjdENsYXNzOiBwaG9uZWluZm8NCm9iamVj dENsYXNzOiBpbmRleG5vZGUNCnJlZmRuOiB1aWQ9MTIxOTg0Mzc5NjY1N1wy QjU1NDE4NDAxMTQ5NixvdT1SRVBPU0lUT1JZLG91PUNPTlRFTlQsbz1hbGNh dGVsLGM9Zg0KIHINCnBubnVtYmVyOiArNTU0MTg0MDExNDk2DQoNCmRuOiB3 ZWJsb2dpbj1cMkI1NTQxODQwMTE0OTYsb3U9cmFuZ2U2NyxvdT13ZWJsb2dp bixvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQp3ZWJsb2dpbjogKzU1NDE4 NDAxMTQ5Ng0KaG9zdDogYnJ0bGRwMTJlDQphY2NvdW50U3RhdHVzOiAxDQpv YmplY3RDbGFzczogY29tbW9udXNlcg0Kb2JqZWN0Q2xhc3M6IGluZGV4bm9k ZQ0KcmVmZG46IHVpZD0xMjE5ODQzNzk2NjU3XDJCNTU0MTg0MDExNDk2LG91 PVJFUE9TSVRPUlksb3U9Q09OVEVOVCxvPWFsY2F0ZWwsYz1mDQogcg0KY246 ICs1NTQxODQwMTE0OTYNCg0KZG46IG1haWw9XDJCNTU0MTg0MDExNDk2L3R5 cGVcM0RQTE1OQG1tcy5icmFzaWx0ZWxlY29tLmNvbS5icixvdT1yYW5nZTg0 LG91PW1hDQogaWwsb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KbWFpbDog KzU1NDE4NDAxMTQ5Ni90eXBlPVBMTU5AbW1zLmJyYXNpbHRlbGVjb20uY29t LmJyDQpob3N0OiBicnRsZHAxMmUNCmFjY291bnRTdGF0dXM6IDENCm9iamVj dENsYXNzOiBjb21tb251c2VyDQpvYmplY3RDbGFzczogaW5kZXhub2RlDQpy ZWZkbjogdWlkPTEyMTk4NDM3OTY2NTdcMkI1NTQxODQwMTE0OTYsb3U9UkVQ T1NJVE9SWSxvdT1DT05URU5ULG89YWxjYXRlbCxjPWYNCiByDQpjbjogKzU1 NDE4NDAxMTQ5Ng0KDQpkbjogbWFpbGxvZ2luPVwyQjU1NDE4NDAxMTQ5Ni90 eXBlXDNEUExNTkBtbXMuYnJhc2lsdGVsZWNvbS5jb20uYnIsb3U9cmFuZ2U4 NCwNCiBvdT1pbWFwbG9naW4sb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0K c3VibXhpZDogMA0KbWFpbGxvZ2luOiArNTU0MTg0MDExNDk2L3R5cGU9UExN TkBtbXMuYnJhc2lsdGVsZWNvbS5jb20uYnINCmhvc3Q6IGJydGxkcDEyZQ0K b2JqZWN0Q2xhc3M6IGNvbW1vbm1haWxib3gNCm9iamVjdENsYXNzOiBpbmRl eG5vZGUNCnJlZmRuOiB1aWQ9MTIxOTg0Mzc5NjY1N1wyQjU1NDE4NDAxMTQ5 NixvdT1SRVBPU0lUT1JZLG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9Zg0KIHIN Cg== --0-1644073040-1233052012=:88983 Content-Type: application/x-zip; name="index_simplex.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="index_simplex.zip" UEsDBBQAAgAIAC9DOzrp93S+DBEAADUEAQASABUAaW5kZXhfc2ltcGxleC5s ZGlmVVQJAAMa4X5JGuF+SVV4BADuAwEC7Z1tb+JIFoW/8yv4PlEPVS6/pRVp e9IZKVJ3Opukd2dWI43AdtKeBZsF0y+z2f++NraBlE+RgA+ku4eWZkNwcc71 fVy36jrAhslxN52dnF+8Pvvl7PooPekPg34WDY+Ck9tJJx38EQVZMOxPp/mw yV0/if/sZ3Ga9IfvkzjrpLPjbvXSTicspd68fnV5+u7i56MWsqvHh2F/PJ0N psEkHhdjptXh0/LwNM6iOLlN57HU3p1R//OD1ySD467TK/51Gs/nT+UaSX8U HXeTNPs9jG7jJArLEwrjrDhy8vr8RhxtcXb56+fRVTrH3UKoU5zTh3RaPTWY ZMNwLGQ0f74fhpOoeKnovRBKvhD2CyXnR8bpJDvuWp5fqGVfxlGV/E4/yOKP eQDhcffm6v1Z/nuQKwRpkk3S4XH3n1fnN2f5ed/exp/X0Z6kaVacc5Cc9MNR nBytHzr+lGc/CiZRlmvPg4vC0nmUhlF+AqNpPA2To0/RYJje5XKjfjw8ikf9 8fzXRn4lK7+Sl988lJuzi5tGhvOznl+w6TiazB88MfOV3lMyv2boSubrWXd+ 3XrSFXO5VClVo4LXNJp8jCZxeNI72txlRaHzQK2YdCtPlJhGX7pBOpvE0aTb fA2mNh1lFTVpd4orq/xFKKsznqQf42l+enFyV8HJJv0kZxP276J/R1+Ouz8W jE8u37y9WKTx8urdz+dvztqnckVoIX79/qfr06vzy5vzdxfV8esjpikyKN3z bNzGw6jmSIxktZxWLp2FW8G5+qViPJoW9bU/G2adLAo+JHHQH6bjcgaJl72X wcuX9+KleBm+fNkcIPMDxQCZD4QDrGqAZRqgKguVD/ww/ymrn1b1U1U/7eqn U/10C8H8p1f83hS25zELcMSpLJ15bKJ4IPOhFhjq5kOzfKhrSoBvOiB6xiOL rFZpLR7IwgaMlfVYaZSz6iGWcYgy5kLYJZh7YdfZyB/J+SMw2qlHl7mTaIxX x+OZXcu0oZfLXvVyaUygrJMijUmRdVKkMSlSGY/Y9Ytt4xC3HmK8MqRf5Ur6 5RwAk6NnnDbmCWWcSVYxZQpDq5gz2NA2vrgmazn1jHXml8H8gWWQc+sXuaZT VLWuqnQ7wzQ/HA3jab4sRMlRXr3y7cg4r1yf0klRnoodYZjm60yyKFAvBpP+ NB7m5S4K0tGL4r9BvhZ9HsflUp/MRoNokk/5fOM4X4TzJSWqpIoFa6lerdHF k/+ZpVm/mKfKs11HL8piv0VZNIvyXToMt6rI1YVpGlDPDOPEOFTkQ0U+VGRS RVZ1Ra6KqqqLqjIWVXqNrsa6xi2YU131qpqH30iNlvut0fJhjR5Gd/3gy672 zIfKfKjMi8pc6fhGnUOJblGipeHIYa/81L1yj3YL4/Rpu+WedhNj9thNDONW 2bhF/poKcFYV4LAuwNl2BdgznddXUpnbF2RzGTYUX3zEr+N9ZFcc1iU3MJbc sC65gbHkmutpWNfTwFgsg7pYblj4VF3e9ldjTvN/5hrz94c1Jk6y4jZ0eTt1 PInm9+t/sKz5HebVu9bFTebV3xvFSey7OIlmcbobpoP+0Fib5pvFYE2Nujde QdVSfV+t3c9Qs+7rlb/cCz1Sw7KWm8hq0t57poQcdpmmQlfuMosxxSOj4lOL 3yP7zTqnUhhP9akF8pE96RN3nmG98zTsoeu9uPTKLWHxoEXlrdcHyzi3rfpq s4Rp8tb1+96yjIGv2cI+3vtb9VlbXkW7eGS6NlTNXZXcfR8Nqk9LGU+rXnzu 1eIaV4tr/LtfkOS+FyTZXJCKAOMgQiuS2Hi3vOZ2Rbjpbtd0pJ7B7nwN+eY2 t+Z1wLQHpextlyW/xY2Fp+1yt63dot7l9tbU2sPm1lBLrH3XEqtZSz7Gk2y2 ZnfL6rwNtcRwYKPG+TtrmJ+9pjxfv7zdPcVDJempfVcS1awk+RM5gSwKD50y rVM+dMiHDvnQIX+rHfL3v+7Y+153bHB71vBeq6rUGVuTunkxXpx/uSVHVDdn e9/xzdmgXnrCx5eeqmIIx5QR/S0AX9fS0/4NA5u/LeDbWnqCeukJDzdnv4fl yNn3cuSAm7Px+LAaHVajw2r0F1mN/spLjSyvW1WTWSw63/9S4+57qXG1T5kE yXfxtjl5eNvc1/K2ua/53XJr6vk2f2KsL5f9lalXr56hTEnb3vPHLOzGDZrg 93rcDj7uRvnsA3taf9OfNNjbJwEe/eAVfO++ZdwkoTuuvNlstX3HfT6/Xr1+ e37x/vrsivs1BUvZ0mn+dSDzbwFZ/EWu/B6NI0YM8y/UmOU15+HT84oVRHMc nUUE81q0GkJ5aJ60PGX/Pb369fLmf3FydWtnP/05ev+P9G5ZTUqIxecTircB F++8Kt4xUfyts7jvXDT7xaao+LKZcuTye0kKBoP0890knY3LmhRPVwPsVt9g sXiuLLH50563fHLJu1vMe0utjq9i7JZ/C9Xynl91QVDkSJBTvpLYpQfMaf+P oPfhlx8v78L0X28fz+mm+UQnPJ2No0kREeWkF2qNk9aOrD1xdDZa7PPsfpqO dxd17fAw3kpEDyevSfnQHV44lQEMRuhXSn6dHEkcotx1iBKGKDcI0dp1iBYM 0dogRLXrEBUMUW0Qor3rEG0Yor1BiM6uQ3RgiM4GIbq7DtGFIbobhOjtOkQP huhtEKK/6xB9GKK/JsTcs/pmtla7uFJjIbn4lrdWorXKQnbxdXHtdLVvnStS UHwZXbsE5AoLuUk/uYvKT6Yyktut9JA+J9PrHEhJX2fRPv0GdUFGIJA+FQF0 4CKAFjQEurokI5BIn4oAOnARQAsaAl3dIiOwkD4VAXTgIoAWNAS6uiIjUEif igA6cBFACxoCXd0mI7CRPhUBdOAigBY0BLq6Q0bgIH0qAujARQAtaAh0dZeM wEX6VATQgYsAWtAQ6OoeGYGH9KkIoAMXAbSgIdDVfTICH+lTEUAHLgJoQUOg qQtydyx6SJ+JADtQEWALFoKGOrk7FgLpUxFABy4CaEFDoKuTu2MhkT4VAXTg IoAWNAS6Ork7FhbSpyKADlwE0IKGQFcnd8dCIX0qAujARQAtaAh0dXJ3LGyk T0UAHbgIoAUNga5O7o6Fg/SpCKADFwG0oCHQ1cndsXCRPhUBdOAigBY0BLo6 uTsWHtKnIoAOXATQgoZAVyd3x8JH+lQE0IGLAFrQEGjqktwdyx7SZyLADlQE 2IKFoKFO7o6lQPpUBNCBiwBa0BDo6uTuWEqkT0UAHbgIoAUNga5O7o6lhfSp CKADFwG0oCHQ1cndsVRIn4oAOnARQAsaAl2d3B1LG+lTEUAHLgJoQUOgq5O7 Y+kgfSoC6MBFAC1oCHR1cncsXaRPRQAduAigBQ2Brk7ujqWH9KkIoAMXAbSg IdDVyd2x9JE+FQF04CKAFjQEmrpF7o6tHtJnIsAOVATYgoWgoU7uji2B9KkI oAMXAbSgIdDVyd2xJZE+FQF04CKAFjQEujq5O7YspE9FAB24CKAFDYGuTu6O LYX0qQigAxcBtKAh0NXJ3bFlI30qAujARQAtaAh0dXJ3bDlIn4oAOnARQAsa Al2d3B1bLtKnIoAOXATQgoZAVyd3x5aH9KkIoAMXAbSgIdDVyd2x5SN9KgLo wEUALWgINHVF7o5VD+kzEWAHKgJswULQUCd3x0ogfSoC6MBFAC1oCHR1cnes JNKnIoAOXATQgoZAVyd3x8pC+lQE0IGLAFrQEOjq5O5YKaRPRQAduAigBQ2B rk7ujpWN9KkIoAMXAbSgIdDVyd2xcpA+FQF04CKAFjQEujq5O1Yu0qcigA5c BNCChkBXJ3fHykP6VATQgYsAWtAQ6Ork7lj5SJ+KADpwEUALGgJN3SZ3x3YP 6TMRYAcqAmzBQtBQJ3fHtkD6VATQgYsAWtAQ6Ork7tiWSJ+KADpwEUALGgJd ndwd2xbSpyKADlwE0IKGQFcnd8e2QvpUBNCBiwBa0BDo6uTu2LaRPhUBdOAi gBY0BLo6uTu2HaRPRQAduAigBQ2Brk7ujm0X6VMRQAcuAmhBQ6Crk7tj20P6 VATQgYsAWtAQ6Ork7tj2kT4VAXTgIoAWNASaukPujp0e0mciwA5UBNiChaCh Tu6OHYH0qQigAxcBtKAh0NXJ3bEjkT4VAXTgIoAWNAS6Ork7diykT0UAHbgI oAUNga5O7o4dhfSpCKADFwG0oCHQ1cndsWMjfSoC6MBFAC1oCHR1cnfsOEif igA6cBFACxoCXZ3cHTsu0qcigA5cBNCChkBXJ3fHjof0qQigAxcBtKAh0NXJ 3bHjI30qAujARQAtaAg0dZfcHbs9pM9EgB2oCLAFC0FDndwduwLpUxFABy4C aEFDoKuTu2NXIn0qAujARQAtaAh0dXJ37FpIn4oAOnARQAsaAl2d3B27CulT EUAHLgJoQUOgq5O7Y9dG+lQE0IGLAFrQEOjq5O7YdZA+FQF04CKAFjQEujq5 O3ZdpE9FAB24CKAFDYGuTu6OXQ/pUxFABy4CaEFDoKuTu2PXR/pUBNCBiwBa 0BBo6h65O/Z6SJ+JADtQEWALFoKGOrk79gTSpyKADlwE0IKGQFcnd8eeRPpU BNCBiwBa0BDo6uTu2LOQPhUBdOAigBY0BLo6uTv2FNKnIoAOXATQgoZAVyd3 x56N9KkIoAMXAbSgIdDVyd2x5yB9KgLowEUALWgIdHVyd+y5SJ+KADpwEUAL GgJdndwdex7SpyKADlwE0IKGQFcnd8eej/SpCKADFwG0oCHQ1H1yd+z3kD4T AXagIsAWLAQNdXJ37AukT0UAHbgIoAUNga5O7o59ifSpCKADFwG0oCHQ1cnd sW8hfSoC6MBFAC1oCHR1cnfsK6RPRQAduAigBQ2Brk7ujn0b6VMRQAcuAmhB Q6Crk7tj30H6VATQgYsAWtAQ6Ork7th3kT4VAXTgIoAWNAS6Ork79j2kT0UA HbgIoAUNga5O7o59H+lTEUAHLgJoQUNQqY+TZDYaRJOT337oLf4d1Z69LXrm 8Yc0ieLkNn34dJyE0eckDaNObXncXbHsTGeDcRKHx91e50M6zY67g0k2DMdC Rp1JdFuEOovDk3k8V2eX767Pb95d/Vr8dvru4ubs4kaPaX52RbZORqNp8Lf8 f14MJv1pPMxHREE6elH8N5gcbf934VxglCazaTQxnWmhlgexzr8T5GFOv0yz aNTpB0E6S7Jp1s9muY4gJqK+9jHmzf/vUx8/99rxIeX9nG1xJuXpbsL+6bP3 dDUJhdkg/fzw0DIP+XU9+lxe14uwHrsmOJnQ5rf8qaYgtp3hp3iGo3Ou5zKY 7Ln9ujOUvZ4npHBkT0mh8uHNyB87/04XXfk4ARu+2f3UcP2fPuH6F9UEePBE NQ2unzINyKmZV8eHEj9mX8bRbyeXb95ePGHagBWp022buLJo/qAHtT6mry6v 6JrbIrmLmtTpUqvSSinaNNMrBW0/KV1Tx8SyjolnqGMbXVSyGXn7OrZMwIaf GGlXx4Q+30Sr+dYyNc06JjaaauiPHjuoY2KLOvbseUXX3BbJ3W8dE7urYy1S uqaOyWUdk89Qx+QmGbCakbevY8sEbPixq3Z1TOrzTbaaby1T06xjcrOpJvZS x+QWdezZ84quuS2Su986JndXx1qkdE0ds5Z1zHqGOmZtkgHVjLx9HVsmYMPP LrarY5Y+36xW861lapp1zNpsqsm91DFrizr27HlF19wWyd1vHbN2V8dapHRN HVPLOqaeoY6pTTJgNyNvX8eWCdjwA8Dt6pjS55tqNd9apqZZx9RmU83aSx1T W9SxZ88ruua2SO5+65jaXR1rkdLO/wFQSwECFwMUAAIACAAvQzs66fd0vgwR AAA1BAEAEgANAAAAAAABAAAApIEAAAAAaW5kZXhfc2ltcGxleC5sZGlmVVQF AAMa4X5JVXgAAFBLBQYAAAAAAQABAE0AAABREQAAAAA= --0-1644073040-1233052012=:88983--

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 27 Jan '09

27 Jan '09

unix.gurus(a)gmail.com wrote: > Hi, > > On Tue, Jun 24, 2008 at 12:50 PM, Sean Burford<unix.gurus(a)gmail.com> wrote: >> namingContexts was the trickiest, since RFC 4512 defines it without an >> equality matching rule but monitor_back_register_database() compares >> it with backend suffixes. It has to deal with capitalised values >> properly otherwise we end up with duplicate namingContexts entries, so >> normalization is required. > > I have uploaded > ftp://ftp.openldap.org/incoming/sean-burford-monitor-test-080706.patch > which adds a test for various things under cn=monitor. If duplicate > namingContexts creep in (as mentioned above) it detects that. > > The duplicate naming contexts thing was fixed by comparing a_vals with > be_suffix, I just wrote the test since there was no existing > cn=monitor test. Sorry for dropping the ball on this. These last two patches are now committed 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 hyc＠symas.com 26 Jan '09

26 Jan '09

rlvcosta(a)yahoo.com wrote: > 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. We may need to have sample data from you to reproduce this situation. I haven't seen anything like it on my tests. Running two searches simultaneously still behaves normally for me. > > The scenario was : Likewise, the exact commands and arguments will be needed... > > 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. -- -- 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 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 DN cache is hierarchical; it will only free leaf nodes (entries that have no children). So depending on the structure of your tree, it's normal for the Monitor to report more elements in the DN cache than you configured. > > 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? cachefree applies only to the entry cache. The idea is to minimize the number of times it must cycle through the cache trying to free entries. Typically when we configure large servers with caches of 1 million entries or more, we configure this to 1000 or so (0.1% of cache size). -- -- 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

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

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

24 Jan '09

----- jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: irrelevant > OS: irrelevant > URL: > ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch > Submission from: (NULL) (62.147.206.193) > > > The different log/debug levels available are described in three places > in the > admin guide: for olcLogLevel attribute in cn=config, for loglevel in > slapd.conf > and for -d command line option to slapd. > > 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 propose the patch below that offers similar information in all three > places, > an example clarifying the difference between loglevels "0" and "None" > and > clarification of the cn=config default. Most text is simply copied > from the man > pages. OK, thanks. Will take a look. > On a side note, the man pages have levels "cache" and "index" (4096 > and 8192) > commented out. The output from slapd -d? include them. Which should > the admin > guide reflect? 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? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 24 Jan '09

24 Jan '09

--001485f01b2867b84704613d5bd9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > > If so, i can still see the behaviour here with 2.4.13, i can see >> operational >> attributes, but non non-operational attributes, when mapping both >> objectclass and attribute.. >> >> Bug seems to be focused on using of *, rather than an explicit list of >> non-operational attrs which works, ie : >> >> I can search for attributes with * ( get all non-operational attributes ) >> and don't get any non-operational attributes, whereas explicitly adding >> any >> non-operational attribute will result i a search returning the named >> values, >> which is allowable via the objectclass maps. >> >> seems to work the same (omitting non-oprational attrs), even if i dont >> specufy the objectclass rwm maps. >> > > Not sure I understand. Can you post simple (both working and not working) > examples? > Last time i looked at this after release of 2.4.13 it was not working. Eg: given attribute maps: # these dont work rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * I could see operational attributes, in response to having + in the attribute list when querying, and would get all operational attributes without naming them specifically. But i could not similarly use *, to return all non-operational attributes without specifying them individually. As most ldap browsers default to using *,+ in the attribute list, i could only see operational attributes when using an ldap browser with it's default settings. However if i specifically put cn,sn,givenName,etc., in the attribute list instead of using the shortcut *,+ i could get non-operational attributes (cn,sn,givenName,etc.,) showing normally in queries. The specific configs are not around anymore, but the snippit above from the ITS covers the important rwm-map bits. I will try to duplicate my previous results in detail, with debugging, to help diagnose this further... Cheers Brett --001485f01b2867b84704613d5bd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo= Masarati <<a href=3D"mailto:ando@sys-net.it">ando@sys= -net.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D= "border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd= ing-left: 1ex;"> <div class=3D"Ih2E3d"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If so, i can still see the behaviour here with 2.4.13, i can see operationa= l attributes, but non non-operational attributes, when mapping both objectclass and attribute.. Bug seems to be focused on using of *, rather than an explicit list of non-operational attrs which works, ie : I can search for attributes with * ( get all non-operational attributes )<b= r> and don't get any non-operational attributes, whereas explicitly adding= any non-operational attribute will result i a search returning the named values= , which is allowable via the objectclass maps. seems to work the same (omitting non-oprational attrs), even if i dont specufy the objectclass rwm maps. </blockquote> </div> Not sure I understand.  Can you post simple (both working and not work= ing) examples?<div> </div></blockquote></div> Last time i looked at this after release of 2.= 4.13 it was not working. Eg: given attribute maps: <pre># these dont wor= k rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute = givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o *<= br>rwm-map attribute ou * # these work rwm-map attribute hasSubor= dinates * rwm-map attribute subschemaSubentry * rwm-map attribute ent= ryUUID * # this enabled rwm-map attribute * </pre>I could see operational = attributes, in response to having + in the attribute list when querying, an= d would get all operational attributes without naming them specifically. Bu= t i could not similarly use *, to return all non-operational attributes wit= hout specifying them individually. As most ldap browsers default to using *,+ in the attribute list, i cou= ld only see operational attributes when using an ldap browser with it's= default settings. However if i specifically put  cn,sn,givenNa= me,etc., in the attribute list instead of using the shortcut *,+ i could ge= t non-operational attributes (cn,sn,givenName,etc.,) showing normally in qu= eries. The specific configs are not around anymore, but the snippit above from= the ITS covers the important rwm-map bits. I will try to duplicate = my previous results in detail, with debugging, to help diagnose this furthe= r... Cheers Brett --001485f01b2867b84704613d5bd9--

1 0

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

24 Jan '09

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Submission from: (NULL) (62.147.206.193) The different log/debug levels available are described in three places in the admin guide: for olcLogLevel attribute in cn=config, for loglevel in slapd.conf and for -d command line option to slapd. 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 propose the patch below that offers similar information in all three places, an example clarifying the difference between loglevels "0" and "None" and clarification of the cn=config default. Most text is simply copied from the man pages. On a side note, the man pages have levels "cache" and "index" (4096 and 8192) commented out. The output from slapd -d? include them. Which should the admin guide reflect?

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Andrew Bartlett wrote: > While I'm still confused about the ASN.1, I've coded to match OpenLDAP's > current behaviour. > > The deref overlay seems to be working well. Many thanks! Cool. I'd appreciate some definitive review of the correspondence of the implementation with respect to the draft (draft-masarati-ldap-deref in docs/draft, or from the IETF ID interface). That's the best I could put in place so far. 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

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 24 Jan '09

24 Jan '09

[please reply to the ITS, otherwise issues can't be tracked] Brett @Google wrote: > HI Ando, > > Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it > into RE24 in time for the 2.4.13 release ? apparently, yes. > If so, i can still see the behaviour here with 2.4.13, i can see operational > attributes, but non non-operational attributes, when mapping both > objectclass and attribute.. > > Bug seems to be focused on using of *, rather than an explicit list of > non-operational attrs which works, ie : > > I can search for attributes with * ( get all non-operational attributes ) > and don't get any non-operational attributes, whereas explicitly adding any > non-operational attribute will result i a search returning the named values, > which is allowable via the objectclass maps. > > seems to work the same (omitting non-oprational attrs), even if i dont > specufy the objectclass rwm maps. Not sure I understand. Can you post simple (both working and not working) examples? 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

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Robert Brooks wrote: > any luck with this? Not even in my priority list right now, sorry. A patch would be welcome. 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

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by jclarke＠linagora.com 24 Jan '09

24 Jan '09

Hi Andrew, andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Jan 12, 2009 at 07:47:20PM +0000, hyc(a)symas.com wrote: > > >>> For example, if I have a DIT like this: >>> >>> dc=example,dc=org--+ >>> +--dc=a--+ >>> | +--dc=people--+ >>> | +--cn=a1 >>> | >>> +--dc=b--+ >>> +--dc=people--+ >>> +--cn=b1 >>> >>> and I give read access on dc=example,dc=org (base) >>> and on dc=a,dc=example,dc=org (subtree) >>> and dc=people,dc=b,dc=example,dc=org (subtree) >>> but no access at all on dc=b,dc=example,dc=org >>> then I would not expect to be able to read the cn=b1 entry, as doing so would >>> expose the existence of dc=b. >>> >>> What actually happens is that any attempt to read dc=b itself returns >>> correctly as if the entry does not exist, but a simple subtree search >>> happily returns cn=b1. >>> > I want to make the discoverability of entries dependent on the value of > an attribute in a parent node, but I cannot see a way of doing it using > the existing ACL syntax and behaviour. > > The closest I have got so far is to use the set syntax in a deny rule: > > # Blockers - look for exampleVisibility=block in all parent entries > # > access to * > by set="this/-*/exampleVisibility & [block]" none > by * break > > This allows any entry to block its subtree to *all* users by setting > exampleVisibility=block > There does not seem to be any way to make the block dependent on > *who* is requesting access, as sets are only valid in the 'by <who>' > part of the rule. > You can refer to *who* in the 'by' part of a set-based rule. Here is an example to limit your "deny" ACL to a category of population: access to * by set="(this/-*/exampleVisibility & [block])/-100 & (user/bypassBlock & [TRUE])/-100" by * break The trick is returning a non empty set. To do this, "/-100" return the 100th parent of each entry. The algorithm is coded so as to return the highest existing parent if it less than 100 degrees away ("dc=org", in your example). However, if one or the other of the sets is empty (ie user doesn't match), this returns an empty set. Obviously, 100 is a conservative value, and some performance improvement may be obtained with a smaller value of 100. Or, a function that makes it less of a hack :) Regards, 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#5884) disclose ACL not safe on non-leaf objects
by ando＠sys-net.it 24 Jan '09

24 Jan '09

I think you're sort of overexpecting from this feature. The basic existence of "disclose" within the access privileges means that adiminstrators can get most of the advantage out of it. But think of what you are asking for: you want to be able to say "well, the whole tree must not be disclosable. According to slapd's ACL paradigm, I'll start enumerating access privileges narrow from broad, *but*, for the disclose level, I want it to work broad from narrow. I agree it would be quite useful to be able to just say "access has to be exactly what I have in mind, no more, no less", but somehow you need to be able to translate your expectation in an inevitably limited language that slapd can understand. For this reason, you need to explicitly add "disclose" access whenever you're detailing access to "narrow", since you can't expect "broad" to overcome "narrow" when "narrow" comes first. Hope I made the point. Regardless of what any of us considers the "expected" or the "favored" behavior, slapd's ACLs work like that. Either you write them the way slapd expects them, or you'll get a behavior different from expected. Of course, feel free to propose a totally different, at least identically flexible and more user-friendly way to describe access privileges. 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#5903) memberof stacked instance member-attr delete failure
by mbackes＠symas.com 24 Jan '09

24 Jan '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: Submission from: (NULL) (76.88.99.93) If slapo-memberof is instanced more than once, deleting the member-attr values from a group or deleting the group object will not remove the memberof-attr values from the members. Adds are not affected. Internally, the operation fails because it tries using the memberof-attribute name from the last memberof instance in the stack. For example, given two member/group oc/attr sets in a schema: objectIdentifier symasExample 1.3.6.1.4.1.4754.31 objectIdentifier symasExAT symasExample:1 objectIdentifier symasExOC symasExample:2 attributetype ( symasExAT:1 NAME 'memberA' SUP distinguishedName ) attributetype ( symasExAT:2 NAME 'memberOfA' SUP distinguishedName ) attributetype ( symasExAT:3 NAME 'memberB' SUP distinguishedName ) attributetype ( symasExAT:4 NAME 'memberOfB' SUP distinguishedName ) objectclass ( symasExOC:1 NAME 'groupA' SUP top STRUCTURAL MUST cn MAY memberA ) objectclass ( symasExOC:2 NAME 'groupMemberA' SUP top AUXILIARY MAY memberOfA ) objectclass ( symasExOC:3 NAME 'groupB' SUP top STRUCTURAL MUST cn MAY memberB ) objectclass ( symasExOC:4 NAME 'groupMemberB' SUP top AUXILIARY MAY memberOfB ) If we add two overlay instances: overlay memberof memberof-group-oc groupA memberof-member-ad memberA memberof-memberof-ad memberOfA memberof-dn cn=memberOfA overlay memberof memberof-group-oc groupB memberof-member-ad memberB memberof-memberof-ad memberOfB memberof-dn cn=memberOfB And start with the data, involving the ocs/attrs from the first instance: dn: cn=person1,o=example objectclass: person objectclass: groupMemberA cn: person1 sn: person1 memberOfA: cn=groupA,o=example dn: cn=groupA,o=example objectclass: groupA cn: groupA memberA: cn=person1,o=example And issue a delete: dn: cn=groupA,o=example changetype: delete Internally we see: bdb_modify_internal: delete memberOfB bdb_modify_internal: 16 modify/delete: memberOfB: no such attribute hdb_modify: modify failed (16) send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=16 matched="" text="modify/delete: memberOfB: no such attribute" slap_graduate_commit_csn: removing 0x10066cdc0 20090124095138.577730Z#000000#000#000000 conn=0 op=1: memberof_value_modify memberOfB="cn=groupA,o=example" failed err=16 text= send_ldap_response: msgid=2 tag=107 err=0 And cn=person1 has not been cleaned up: dn: cn=person1,o=example objectClass: person objectClass: groupMemberA cn: person1 sn: person1 memberOfA: cn=groupA,o=example modifiersName: o=example -- Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 23 Jan '09

23 Jan '09

hyc(a)symas.com wrote: > This behavior is by design, and has been in place since 2000. Whether the > design is correct or not may be an open question; since Kurt wrote that code > I'd ask him to comment further. > This is now fixed in CVS HEAD, 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

Re: (ITS#5881) referral problem with refreshAndPersist mode
by hyc＠symas.com 23 Jan '09

23 Jan '09

hyc(a)symas.com wrote: > Interesting, you've found a bug that has been present since syncrepl's code > was first written in 2003. The syncrepl code assumes that it will only receive > LDAP entries from the provider. But according to RFC4533, references are > supposed to be sent as-is and stored by the consumer. The syncprov overlay > obeys the spec and sends references correctly. > FIxed now 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#5881) referral problem with refreshAndPersist mode
by hyc＠symas.com 23 Jan '09

23 Jan '09

joao.alfredo(a)gmail.com wrote: > Full_Name: João Alfredo > Version: 2.4.13 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.189.117.10) > > > I am using a refreshAndPersist replication mode on OpenLdap 2.4.13. > > When I add referral OU on Master, this entrie is not replicate to Consumer. > > My test.ldif: > dn: ou=MUNICIPIOS,dc=pr > ou: MUNICIPIOS > ref: ldap://<IP>/ou=MUNICIPIOS,dc=pr > objectClass: referral > objectClass: extensibleObject > dc: MUNICIPIOS > Logs on consumer side: > Jan 8 17:50:15 ecelepar10173 slapd[2722]: do_syncrep2: rid=000 reference > received error Interesting, you've found a bug that has been present since syncrepl's code was first written in 2003. The syncrepl code assumes that it will only receive LDAP entries from the provider. But according to RFC4533, references are supposed to be sent as-is and stored by the consumer. The syncprov overlay obeys the spec and sends references correctly. -- -- 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: add option for setting minimum TLS/SSL protocol (ITS#5655)
by hyc＠symas.com 23 Jan '09

23 Jan '09

guenther(a)sendmail.com wrote: > I could have sworn I had uploaded the revised version of the patch back in > August after some cleaning by Kurt, but have no way of confirming it. So > I've uploaded it again as guenther-20081204.patch. Thanks, patch looks good, committed to HEAD. Have you got a manpage update, by the way? -- -- 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#5843) Multi-master doesn't replicate deletes under certain circumstances.
by hyc＠symas.com 23 Jan '09

23 Jan '09

ildefonso_camargo(a)yahoo.com wrote: > Full_Name: Jose Ildefonso Camargo Tolosa > Version: 2.4.13 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (190.73.138.178) > > > Hi! > > I just configured multi-master replication (with N=3) for testing > purposes, and I just found an annoying problem, under these > conditions: > > 1. Configure a N number of "masters", and have them replicate happily > (this is important). > 2. Stop slapd service on all of the servers. > 3. Start slapd service on any number of servers< N (ie, leave at > least one stopped). > 4. Delete any entry (yes, it only fails with deletes, you can combine > changes: modify, add, and delete, and only deletes will fail to > replicate). > 5. Stop slapd service on *all of the servers again* (this is the most > important part). > 6. Start slapd service on all the servers. > 7. Look for the deleted entry on the server(s) that you left stopped in steps 3 > and 4, the entry is there!, but it isn't on the server(s) that were running in > step 3 and 4. > > You will see that, on the servers that you left down on step 3, the > deleted entries are still present. > > If you leave at least one server up, it replicates just fine, the > problem is when you stop all of the masters, and then start them again. > > If you need further info, just ask! I repeated the steps you described but was unable to reproduce the problem. However, following the steps that Adrien provided in a followup, I was able to reproduce the situation and identify the problem. A fix is now in CVS HEAD, 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

(ITS#5888) configure.in changes
by richton＠nbcs.rutgers.edu 23 Jan '09

23 Jan '09

Yeah, some "working" builds were affected. I just narrowed this down to these commits three minutes ago; I'll investigate and post back.

1 0

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

23 Jan '09

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/

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 23 Jan '09

23 Jan '09

Quanah Gibson-Mount wrote: > --On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >> I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully >> patched. >> >> The interesting fact is that HEAD currently hangs all the time in >> test008. RE24 with your recent changes now fails as described in >> test039. Before these changes RE24 just worked fine. >> >> I think this is related to modifications in connection.c because trouble >> started after HEAD contained these changes. > > All tests pass for me with current RE24 and HEAD. Currently all tests pass for RE24. Hmm, strange. Maybe some lib mix problem with the OpenLDAP client libs installed by openSUSE? I've removed them in the meantime to exclude any library mix. Let's close this ITS for now. Ciao, Michael.

1 0

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

23 Jan '09

Rodrigo Costa wrote: > Howard, > > I move back into OL 2.4 and collected again the monitor information. Now I could see the cache information. > > I just execute the ldapsearch in one existent DN so I can confirm the number of entraces. The result was : > > 1000000 > > real 6m55.707s > user 0m27.292s > sys 0m8.525s > > Now that entrances are cached this reduce almost to half time if I run again. > > But at monitor I have : > > readOnly: FALSE > olmBDBEntryCache: 1001 > olmBDBDNCache: 4000264 > olmBDBIDLCache: 1 > olmDbDirectory: /var/openldap-data/bdb2/ > > Where the DNCache grew without limits and this memory is never released. > > My slapd.conf has : > > line 122 (cachesize 1000) > line 123 (idlcachesize 1000) > line 124 (dncachesize 2000) > > for my bdb2 DB. > > I beleive that in the worst case dncachesize is not defined it would be > something like twice the cachesize. > > Other thing I do not understand well is the DNcache bigger than 1,000,000 > since this is the number of entrances I have in the DB. > > By what we talked previously the dncachesize was included exactly to > control this memory consumption. But looks like for some reason it is not > accepting this configuration. > > Without this limit, 32 bits or 64 bits machine, will soon or later have > memory problems. > > Please let me know your comments. > > Thanks a lot ! Thanks for this information. Yes, there is a bug here - a single function is used to purge the entry and DN caches, but when the entry cache is already within its limits, it returns without doing any work, so the DN cache never gets purged. It will take some time to fix this. -- -- 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 23 Jan '09

23 Jan '09

--0-2080824295-1232747630=:87185 Content-Type: text/plain; charset=us-ascii Howard, I move back into OL 2.4 and collected again the monitor information. Now I could see the cache information. I just execute the ldapsearch in one existent DN so I can confirm the number of entraces. The result was : 1000000 real 6m55.707s user 0m27.292s sys 0m8.525s Now that entrances are cached this reduce almost to half time if I run again. But at monitor I have : readOnly: FALSE olmBDBEntryCache: 1001 olmBDBDNCache: 4000264 olmBDBIDLCache: 1 olmDbDirectory: /var/openldap-data/bdb2/ Where the DNCache grew without limits and this memory is never released. My slapd.conf has : line 122 (cachesize 1000) line 123 (idlcachesize 1000) line 124 (dncachesize 2000) for my bdb2 DB. I beleive that in the worst case dncachesize is not defined it would be something like twice the cachesize. Other thing I do not understand well is the DNcache bigger than 1,000,000 since this is the number of entrances I have in the DB. By what we talked previously the dncachesize was included exactly to control this memory consumption. But looks like for some reason it is not accepting this configuration. Without this limit, 32 bits or 64 bits machine, will soon or later have memory problems. Please let me know your comments. Thanks a lot ! 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 > Cc: openldap-its(a)openldap.org > Date: Friday, January 23, 2009, 7:11 PM > Rodrigo Costa wrote: > > Howard, > > > > I'm not sure the information needed. I look as : > > > > If ldapsearch finds one or more entries, the > attributes specified by attrs > are returned. If * is listed, all user attributes are > returned. If + is > listed, all operational attributes are returned. If no > attrs are listed, all > user attributes are returned. > > > > So I thought the empty attrs would return all > information. > > All *user* attributes are returned, but not *operational* > attributes. > > > Now with + I > could see some other information but notthing related with > cache. > > It appears that you're not using OpenLDAP 2.4, the > cache attributes are not monitored in previous releases. > > > > What I runned was > > > > ldapsearch -LLL -x -b "cn=monitor" -H > ldap://10.142.15.42:389 + > > -- -- 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-2080824295-1232747630=:87185 Content-Type: text/plain; name="monitor1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor1.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogT3BlbkxEQVA6IHNs YXBkIDIuNC4xMyAoSmFuIDIyIDIwMDkgMDI6Mjg6MTIpDQplbnRyeUROOiBj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUJhY2tlbmRzLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogY29uZmlnDQptb25pdG9yZWRJ bmZvOiBsZGlmDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JlZEluZm86 IG1vbml0b3INCmVudHJ5RE46IGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogVFJVRQ0KDQpkbjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBjb25maWcNCm1vbml0b3JSdW50 aW1lQ29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAyLjE2Ljg0MC4x LjExMzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAwLGNuPUJhY2tl bmRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUJhY2tlbmQg MSxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzog bGRpZg0KbW9uaXRvclJ1bnRpbWVDb25maWc6IFRSVUUNCnN1cHBvcnRlZENv bnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQplbnRyeUROOiBjbj1C YWNrZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JSdW50aW1lQ29uZmlnOiBU UlVFDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEuMTINCnN1cHBvcnRl ZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0ZWRD b250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1cHBvcnRlZENv bnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBvcnRlZENvbnRy b2w6IDEuMy42LjEuMS4xMy4xDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4x LjEuMTMuMg0Kc3VwcG9ydGVkQ29udHJvbDogMS4zLjYuMS40LjEuNDIwMy4x LjEwLjENCnN1cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4x NDEzDQplbnRyeUROOiBjbj1CYWNrZW5kIDIsY249QmFja2VuZHMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249QmFja2VuZCAzLGNuPUJhY2tl bmRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBtb25pdG9yDQpt b25pdG9yUnVudGltZUNvbmZpZzogVFJVRQ0Kc3VwcG9ydGVkQ29udHJvbDog Mi4xNi44NDAuMS4xMTM3MzAuMy40LjINCmVudHJ5RE46IGNuPUJhY2tlbmQg Myxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPUNv bm5lY3Rpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249Q29u bmVjdGlvbiAyLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvckNvbm5lY3Rpb24NCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjMzMDIxWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMzAyMloNCm1v bml0b3JDb25uZWN0aW9uTnVtYmVyOiAyDQptb25pdG9yQ29ubmVjdGlvblBy b3RvY29sOiAzDQptb25pdG9yQ29ubmVjdGlvbk9wc1JlY2VpdmVkOiAyDQpt b25pdG9yQ29ubmVjdGlvbk9wc0V4ZWN1dGluZzogMQ0KbW9uaXRvckNvbm5l Y3Rpb25PcHNQZW5kaW5nOiAwDQptb25pdG9yQ29ubmVjdGlvbk9wc0NvbXBs ZXRlZDogMQ0KbW9uaXRvckNvbm5lY3Rpb25HZXQ6IDINCm1vbml0b3JDb25u ZWN0aW9uUmVhZDogMg0KbW9uaXRvckNvbm5lY3Rpb25Xcml0ZTogMA0KbW9u aXRvckNvbm5lY3Rpb25NYXNrOiByeA0KbW9uaXRvckNvbm5lY3Rpb25MaXN0 ZW5lcjogbGRhcDovLzEwLjE0Mi4xNS40MjozODkNCm1vbml0b3JDb25uZWN0 aW9uUGVlckRvbWFpbjogdW5rbm93bg0KbW9uaXRvckNvbm5lY3Rpb25QZWVy QWRkcmVzczogSVA9MTAuMTQyLjE1LjQ2OjM4NjMzDQptb25pdG9yQ29ubmVj dGlvbkxvY2FsQWRkcmVzczogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KbW9uaXRv ckNvbm5lY3Rpb25TdGFydFRpbWU6IDIwMDkwMTIzMjMzMDIxWg0KbW9uaXRv ckNvbm5lY3Rpb25BY3Rpdml0eVRpbWU6IDIwMDkwMTIzMjMzMDIyWg0KZW50 cnlETjogY249Q29ubmVjdGlvbiAyLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUNvbm5lY3Rpb24gMCxjbj1Db25u ZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JDb25uZWN0aW9uDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1l Og0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjkwMVoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMzI5MDFaDQptb25pdG9yQ29ubmVjdGlvbk51 bWJlcjogMA0KbW9uaXRvckNvbm5lY3Rpb25Qcm90b2NvbDogMw0KbW9uaXRv ckNvbm5lY3Rpb25PcHNSZWNlaXZlZDogMg0KbW9uaXRvckNvbm5lY3Rpb25P cHNFeGVjdXRpbmc6IDENCm1vbml0b3JDb25uZWN0aW9uT3BzUGVuZGluZzog MA0KbW9uaXRvckNvbm5lY3Rpb25PcHNDb21wbGV0ZWQ6IDENCm1vbml0b3JD b25uZWN0aW9uR2V0OiAyDQptb25pdG9yQ29ubmVjdGlvblJlYWQ6IDINCm1v bml0b3JDb25uZWN0aW9uV3JpdGU6IDANCm1vbml0b3JDb25uZWN0aW9uTWFz azogcngNCm1vbml0b3JDb25uZWN0aW9uQXV0aHpETjogY249YWRtaW4sb3U9 SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KbW9uaXRvckNvbm5lY3Rpb25MaXN0 ZW5lcjogbGRhcDovLzEwLjE0Mi4xNS40MjozODkNCm1vbml0b3JDb25uZWN0 aW9uUGVlckRvbWFpbjogdW5rbm93bg0KbW9uaXRvckNvbm5lY3Rpb25QZWVy QWRkcmVzczogSVA9MTAuMTQyLjE1LjQxOjU5NTAzDQptb25pdG9yQ29ubmVj dGlvbkxvY2FsQWRkcmVzczogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KbW9uaXRv ckNvbm5lY3Rpb25TdGFydFRpbWU6IDIwMDkwMTIzMjMyOTAxWg0KbW9uaXRv ckNvbm5lY3Rpb25BY3Rpdml0eVRpbWU6IDIwMDkwMTIzMjMyOTAxWg0KZW50 cnlETjogY249Q29ubmVjdGlvbiAwLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1heCBGaWxlIERlc2NyaXB0b3Jz LGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RD bGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1v ZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4 Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JD b3VudGVyOiAxMDI0DQplbnRyeUROOiBjbj1NYXggRmlsZSBEZXNjcmlwdG9y cyxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1Ub3RhbCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yQ291bnRlcjogMw0KZW50cnlETjogY249VG90YWwsY249Q29u bmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249Q3Vy cmVudCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2Jq ZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25p dG9yQ291bnRlcjogMg0KZW50cnlETjogY249Q3VycmVudCxjbj1Db25uZWN0 aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2No ZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFz ZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y Q29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQpyZWFkT25seTogRkFMU0UNCm5hbWluZ0Nv bnRleHRzOg0KbmFtaW5nQ29udGV4dHM6IGNuPWNvbmZpZw0KbmFtaW5nQ29u dGV4dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCm5hbWluZ0NvbnRl eHRzOiBvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQptb25pdG9yQ29udGV4 dDogY249TW9uaXRvcg0KZW50cnlETjogY249RGF0YWJhc2VzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogVFJVRQ0KDQpkbjogY249RnJvbnRlbmQsY249RGF0YWJhc2Vz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVk T2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBmcm9udGVuZA0KbW9u aXRvcklzU2hhZG93OiBGQUxTRQ0KbmFtaW5nQ29udGV4dHM6DQpyZWFkT25s eTogRkFMU0UNCmVudHJ5RE46IGNuPUZyb250ZW5kLGNuPURhdGFiYXNlcyxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFzZSAwLGNu PURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogY29u ZmlnDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpuYW1pbmdDb250ZXh0czog Y249Y29uZmlnDQpyZWFkT25seTogRkFMU0UNCmVudHJ5RE46IGNuPURhdGFi YXNlIDAsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JJc1NoYWRvdzogRkFMU0UN Cm5hbWluZ0NvbnRleHRzOiBvdT1DT05URU5ULG89YWxjYXRlbCxjPWZyDQpy ZWFkT25seTogRkFMU0UNCm9sbUJEQkVudHJ5Q2FjaGU6IDANCm9sbUJEQkRO Q2FjaGU6IDANCm9sbUJEQklETENhY2hlOiAwDQpvbG1EYkRpcmVjdG9yeTog L3Zhci9vcGVubGRhcC1kYXRhL2JkYjEvDQplbnRyeUROOiBjbj1EYXRhYmFz ZSAxLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1EYXRhYmFzZSAyLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvcmVkSW5mbzogYmRiDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpu YW1pbmdDb250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KcmVh ZE9ubHk6IEZBTFNFDQpvbG1CREJFbnRyeUNhY2hlOiAxMDAxDQpvbG1CREJE TkNhY2hlOiA2MTA1NTANCm9sbUJEQklETENhY2hlOiAxDQpvbG1EYkRpcmVj dG9yeTogL3Zhci9vcGVubGRhcC1kYXRhL2JkYjIvDQplbnRyeUROOiBjbj1E YXRhYmFzZSAyLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1EYXRhYmFzZSAzLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9y DQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3Jl YXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9uaXRvcmVkSW5mbzogbW9uaXRvcg0KbW9uaXRvcklzU2hhZG93 OiBGQUxTRQ0KbW9uaXRvckNvbnRleHQ6IGNuPU1vbml0b3INCnJlYWRPbmx5 OiBGQUxTRQ0KZW50cnlETjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMs Y249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TGlzdGVuZXJzLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRh aW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KZW50cnlETjogY249TGlzdGVuZXJzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogVFJVRQ0KDQpkbjogY249TGlzdGVuZXIgMCxjbj1MaXN0ZW5l cnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JDb25uZWN0aW9uTG9jYWxBZGRy ZXNzOiBJUD0xMC4xNDIuMTUuNDI6Mzg5DQplbnRyeUROOiBjbj1MaXN0ZW5l ciAwLGNuPUxpc3RlbmVycyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1MaXN0ZW5lciAxLGNuPUxpc3RlbmVycyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvckNvbm5lY3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0Mi4xNS4x NzI6Mzg5DQplbnRyeUROOiBjbj1MaXN0ZW5lciAxLGNuPUxpc3RlbmVycyxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1Mb2csY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMy MzI4NDhaDQplbnRyeUROOiBjbj1Mb2csY249TW9uaXRvcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFtZToN Cm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0 b3JPcEluaXRpYXRlZDogNw0KbW9uaXRvck9wQ29tcGxldGVkOiA1DQplbnRy eUROOiBjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpk bjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1l Og0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMy MzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9u aXRvck9wSW5pdGlhdGVkOiAzDQptb25pdG9yT3BDb21wbGV0ZWQ6IDMNCmVu dHJ5RE46IGNuPUJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24N CmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRlZDogMQ0KbW9uaXRvck9wQ29t cGxldGVkOiAxDQplbnRyeUROOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1TZWFyY2gsY249T3Bl cmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6 DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRlZDog Mw0KbW9uaXRvck9wQ29tcGxldGVkOiAxDQplbnRyeUROOiBjbj1TZWFyY2gs Y249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Db21wYXJlLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25p dG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRlZDogMA0KZW50 cnlETjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlv bg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTIzMjMyODQ4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BD b21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1vZGlmeSxjbj1PcGVyYXRpb25z LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZHJkbixjbj1P cGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczog bW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvck9wSW5pdGlhdGVk OiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1vZHJk bixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5 OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46 IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxP YmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4 NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRv ck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5 RE46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVt YVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFM U0UNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3Jl YXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0 ZWQ6IDANCmVudHJ5RE46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFiYW5kb24sY249T3BlcmF0 aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0 b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpj cmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRlZDogMA0K bW9uaXRvck9wQ29tcGxldGVkOiAwDQplbnRyeUROOiBjbj1BYmFuZG9uLGNu PU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 RXh0ZW5kZWQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToN Cm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0 b3JPcEluaXRpYXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQplbnRy eUROOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvcmVkSW5mbzogZ2x1ZQ0KZW50cnlETjogY249T3ZlcmxheXMsY249 TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFz U3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5IDAsY249T3Zl cmxheXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpj cmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JlZEluZm86IGdsdWUNCm1v bml0b3JSdW50aW1lQ29uZmlnOiBGQUxTRQ0KZW50cnlETjogY249T3Zlcmxh eSAwLGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5 OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46 IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBt b25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1l Og0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQplbnRyeUROOiBjbj1TQVNMLGNu PU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXRpc3RpY3MsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFp bmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGlt ZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAw OTAxMjMyMzI4NDhaDQplbnRyeUROOiBjbj1TdGF0aXN0aWNzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogVFJVRQ0KDQpkbjogY249Qnl0ZXMsY249U3RhdGlzdGljcyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3Vu dGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yQ291bnRlcjogNDIzMDI4ODAN CmVudHJ5RE46IGNuPUJ5dGVzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBGQUxTRQ0KDQpkbjogY249UERVLGNuPVN0YXRpc3RpY3MsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRlck9i amVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KbW9uaXRvckNvdW50ZXI6IDE1MjY3OA0KZW50cnlE TjogY249UERVLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249RW50cmllcyxjbj1TdGF0aXN0aWNzLGNuPU1vbml0b3IN CnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QN CmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vbml0b3JDb3VudGVyOiAxNTI2NzUNCmVudHJ5RE46IGNu PUVudHJpZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9y DQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0 DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb25pdG9yQ291bnRlcjogMA0KZW50cnlETjogY249UmVm ZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlm aWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNu PVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1NYXgs Y249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogMTYN CmVudHJ5RE46IGNuPU1heCxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog RkFMU0UNCg0KZG46IGNuPU1heCBQZW5kaW5nLGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QN CmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vbml0b3JlZEluZm86IDANCmVudHJ5RE46IGNuPU1heCBQ ZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxP YmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQpt b2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0 OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9y ZWRJbmZvOiAyDQplbnRyeUROOiBjbj1PcGVuLGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U3RhcnRpbmcsY249VGhyZWFk cyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3Jl ZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogMA0KZW50cnlETjog Y249U3RhcnRpbmcsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvcmVkSW5mbzogMg0KZW50cnlETjogY249QWN0aXZlLGNuPVRocmVh ZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249UGVuZGluZyxj bj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczog bW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1l Og0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiAwDQpl bnRyeUROOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vi c2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVz OiBGQUxTRQ0KDQpkbjogY249QmFja2xvYWQsY249VGhyZWFkcyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIz MjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogMg0KZW50cnlETjogY249QmFja2xv YWQsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1TdGF0ZSxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2Rp ZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJ bmZvOiB1bmtub3duDQplbnRyeUROOiBjbj1TdGF0ZSxjbj1UaHJlYWRzLGNu PU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVJ1bnF1ZXVlLGNuPVRo cmVhZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpj cmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPVJ1bnF1ZXVlLGNu PVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249VGFz a2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZp ZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQpt b2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KZW50cnlETjogY249 VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFz czogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KZW50cnlETjogY249VGlt ZSxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVN0YXJ0LGNuPVRp bWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y ZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTIz MjMyODQ4Wg0KZW50cnlETjogY249U3RhcnQsY249VGltZSxjbj1Nb25pdG9y DQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRp bmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1DdXJyZW50LGNuPVRpbWUsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QN CmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTIzMjMzMDIyWg0K ZW50cnlETjogY249Q3VycmVudCxjbj1UaW1lLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog RkFMU0UNCg0KZG46IGNuPVVwdGltZSxjbj1UaW1lLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yZWRJbmZvOiA5NA0KZW50cnlETjogY249VXB0aW1lLGNuPVRp bWUsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVt YQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249VExTLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTIzMjMyODQ4Wg0KZW50cnlETjogY249VExTLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog RkFMU0UNCg0KZG46IGNuPVdhaXRlcnMsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQplbnRy eUROOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5 OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpkbjog Y249UmVhZCxjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToN Cm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0 b3JDb3VudGVyOiAyDQplbnRyeUROOiBjbj1SZWFkLGNuPVdhaXRlcnMsY249 TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFz U3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249V3JpdGUsY249V2FpdGVy cyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JD b3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0K Y3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yQ291bnRlcjogMA0KZW50 cnlETjogY249V3JpdGUsY249V2FpdGVycyxjbj1Nb25pdG9yDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZB TFNFDQoNCg== --0-2080824295-1232747630=:87185 Content-Type: text/plain; name="monitor2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor2.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0 ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6 IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogT3BlbkxEQVA6IHNs YXBkIDIuNC4xMyAoSmFuIDIyIDIwMDkgMDI6Mjg6MTIpDQplbnRyeUROOiBj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUJhY2tlbmRzLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkw MTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogY29uZmlnDQptb25pdG9yZWRJ bmZvOiBsZGlmDQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JlZEluZm86 IG1vbml0b3INCmVudHJ5RE46IGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogVFJVRQ0KDQpkbjogY249QmFja2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0 YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBjb25maWcNCm1vbml0b3JSdW50 aW1lQ29uZmlnOiBUUlVFDQpzdXBwb3J0ZWRDb250cm9sOiAyLjE2Ljg0MC4x LjExMzczMC4zLjQuMg0KZW50cnlETjogY249QmFja2VuZCAwLGNuPUJhY2tl bmRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUJhY2tlbmQg MSxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzog bGRpZg0KbW9uaXRvclJ1bnRpbWVDb25maWc6IFRSVUUNCnN1cHBvcnRlZENv bnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQplbnRyeUROOiBjbj1C YWNrZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JSdW50aW1lQ29uZmlnOiBU UlVFDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjEuMTINCnN1cHBvcnRl ZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0ZWRD b250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1cHBvcnRlZENv bnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBvcnRlZENvbnRy b2w6IDEuMy42LjEuMS4xMy4xDQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4x LjEuMTMuMg0Kc3VwcG9ydGVkQ29udHJvbDogMS4zLjYuMS40LjEuNDIwMy4x LjEwLjENCnN1cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4x NDEzDQplbnRyeUROOiBjbj1CYWNrZW5kIDIsY249QmFja2VuZHMsY249TW9u aXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249QmFja2VuZCAzLGNuPUJhY2tl bmRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBtb25pdG9yDQpt b25pdG9yUnVudGltZUNvbmZpZzogVFJVRQ0Kc3VwcG9ydGVkQ29udHJvbDog Mi4xNi44NDAuMS4xMTM3MzAuMy40LjINCmVudHJ5RE46IGNuPUJhY2tlbmQg Myxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVy c05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9k aWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPUNv bm5lY3Rpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249Q29u bmVjdGlvbiAzLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvckNvbm5lY3Rpb24NCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjMzNjQ0Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMzY0NVoNCm1v bml0b3JDb25uZWN0aW9uTnVtYmVyOiAzDQptb25pdG9yQ29ubmVjdGlvblBy b3RvY29sOiAzDQptb25pdG9yQ29ubmVjdGlvbk9wc1JlY2VpdmVkOiAyDQpt b25pdG9yQ29ubmVjdGlvbk9wc0V4ZWN1dGluZzogMQ0KbW9uaXRvckNvbm5l Y3Rpb25PcHNQZW5kaW5nOiAwDQptb25pdG9yQ29ubmVjdGlvbk9wc0NvbXBs ZXRlZDogMQ0KbW9uaXRvckNvbm5lY3Rpb25HZXQ6IDINCm1vbml0b3JDb25u ZWN0aW9uUmVhZDogMg0KbW9uaXRvckNvbm5lY3Rpb25Xcml0ZTogMA0KbW9u aXRvckNvbm5lY3Rpb25NYXNrOiByeA0KbW9uaXRvckNvbm5lY3Rpb25MaXN0 ZW5lcjogbGRhcDovLzEwLjE0Mi4xNS40MjozODkNCm1vbml0b3JDb25uZWN0 aW9uUGVlckRvbWFpbjogdW5rbm93bg0KbW9uaXRvckNvbm5lY3Rpb25QZWVy QWRkcmVzczogSVA9MTAuMTQyLjE1LjQ2OjM4OTE1DQptb25pdG9yQ29ubmVj dGlvbkxvY2FsQWRkcmVzczogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KbW9uaXRv ckNvbm5lY3Rpb25TdGFydFRpbWU6IDIwMDkwMTIzMjMzNjQ0Wg0KbW9uaXRv ckNvbm5lY3Rpb25BY3Rpdml0eVRpbWU6IDIwMDkwMTIzMjMzNjQ1Wg0KZW50 cnlETjogY249Q29ubmVjdGlvbiAzLGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1heCBGaWxlIERlc2NyaXB0b3Jz LGNuPUNvbm5lY3Rpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RD bGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1v ZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4 Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JD b3VudGVyOiAxMDI0DQplbnRyeUROOiBjbj1NYXggRmlsZSBEZXNjcmlwdG9y cyxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1Ub3RhbCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yQ291bnRlcjogNA0KZW50cnlETjogY249VG90YWwsY249Q29u bmVjdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249Q3Vy cmVudCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2Jq ZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25p dG9yQ291bnRlcjogMQ0KZW50cnlETjogY249Q3VycmVudCxjbj1Db25uZWN0 aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2No ZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFz ZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9y Q29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQpyZWFkT25seTogRkFMU0UNCm5hbWluZ0Nv bnRleHRzOg0KbmFtaW5nQ29udGV4dHM6IGNuPWNvbmZpZw0KbmFtaW5nQ29u dGV4dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCm5hbWluZ0NvbnRl eHRzOiBvdT1JTkRFWEVTLG89YWxjYXRlbCxjPWZyDQptb25pdG9yQ29udGV4 dDogY249TW9uaXRvcg0KZW50cnlETjogY249RGF0YWJhc2VzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogVFJVRQ0KDQpkbjogY249RnJvbnRlbmQsY249RGF0YWJhc2Vz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVk T2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZvOiBmcm9udGVuZA0KbW9u aXRvcklzU2hhZG93OiBGQUxTRQ0KbmFtaW5nQ29udGV4dHM6DQpyZWFkT25s eTogRkFMU0UNCmVudHJ5RE46IGNuPUZyb250ZW5kLGNuPURhdGFiYXNlcyxj bj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpo YXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1EYXRhYmFzZSAwLGNu PURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFt ZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogY29u ZmlnDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpuYW1pbmdDb250ZXh0czog Y249Y29uZmlnDQpyZWFkT25seTogRkFMU0UNCmVudHJ5RE46IGNuPURhdGFi YXNlIDAsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yZWRJbmZvOiBiZGINCm1vbml0b3JJc1NoYWRvdzogRkFMU0UN Cm5hbWluZ0NvbnRleHRzOiBvdT1DT05URU5ULG89YWxjYXRlbCxjPWZyDQpy ZWFkT25seTogRkFMU0UNCm9sbUJEQkVudHJ5Q2FjaGU6IDANCm9sbUJEQkRO Q2FjaGU6IDANCm9sbUJEQklETENhY2hlOiAwDQpvbG1EYkRpcmVjdG9yeTog L3Zhci9vcGVubGRhcC1kYXRhL2JkYjEvDQplbnRyeUROOiBjbj1EYXRhYmFz ZSAxLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1EYXRhYmFzZSAyLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvcmVkSW5mbzogYmRiDQptb25pdG9ySXNTaGFkb3c6IEZBTFNFDQpu YW1pbmdDb250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KcmVh ZE9ubHk6IEZBTFNFDQpvbG1CREJFbnRyeUNhY2hlOiAxMDAxDQpvbG1CREJE TkNhY2hlOiA0MDAwMjY0DQpvbG1CREJJRExDYWNoZTogMQ0Kb2xtRGJEaXJl Y3Rvcnk6IC92YXIvb3BlbmxkYXAtZGF0YS9iZGIyLw0KZW50cnlETjogY249 RGF0YWJhc2UgMixjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNy ZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCm1vbml0b3JJc1NoYWRv dzogRkFMU0UNCm1vbml0b3JDb250ZXh0OiBjbj1Nb25pdG9yDQpyZWFkT25s eTogRkFMU0UNCmVudHJ5RE46IGNuPURhdGFiYXNlIDMsY249RGF0YWJhc2Vz LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUxpc3RlbmVycyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb250 YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPUxpc3RlbmVycyxjbj1Nb25p dG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPUxpc3RlbmVyIDAsY249TGlzdGVu ZXJzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv cmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3Jl YXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yQ29ubmVjdGlvbkxvY2FsQWRk cmVzczogSVA9MTAuMTQyLjE1LjQyOjM4OQ0KZW50cnlETjogY249TGlzdGVu ZXIgMCxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kc3Ry dWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3Jz TmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkw MTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoN Cm1vbml0b3JDb25uZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUu MTcyOjM4OQ0KZW50cnlETjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMs Y249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249TG9nLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIz MjMyODQ4Wg0KZW50cnlETjogY249TG9nLGNuPU1vbml0b3INCnN1YnNjaGVt YVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFM U0UNCg0KZG46IGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25p dG9yT3BJbml0aWF0ZWQ6IDExDQptb25pdG9yT3BDb21wbGV0ZWQ6IDEwDQpl bnRyeUROOiBjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1 YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0K DQpkbjogY249QmluZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNO YW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0K bW9uaXRvck9wSW5pdGlhdGVkOiA0DQptb25pdG9yT3BDb21wbGV0ZWQ6IDQN CmVudHJ5RE46IGNuPUJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1N b25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRp b24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1l c3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRlZDogMw0KbW9uaXRvck9w Q29tcGxldGVkOiAzDQplbnRyeUROOiBjbj1VbmJpbmQsY249T3BlcmF0aW9u cyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1TZWFyY2gsY249 T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6 IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRl ZDogNA0KbW9uaXRvck9wQ29tcGxldGVkOiAzDQplbnRyeUROOiBjbj1TZWFy Y2gsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRu OiBjbj1Db21wYXJlLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0 dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQpt b25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRlZDogMA0K ZW50cnlETjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVyYXRpb25zLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJh dGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9y T3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1vZGlmeSxjbj1PcGVyYXRp b25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZHJkbixj bj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFz czogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvck9wSW5pdGlh dGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVudHJ5RE46IGNuPU1v ZHJkbixjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY3JlYXRvcnNOYW1l Og0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMy MzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9u aXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDANCmVu dHJ5RE46IGNuPUFkZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCnN1YnNj aGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczog RkFMU0UNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0K Y3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFt cDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIz MjMyODQ4Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21w bGV0ZWQ6IDANCmVudHJ5RE46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNu PU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFiYW5kb24sY249T3Bl cmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6 DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JPcEluaXRpYXRlZDog MA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQplbnRyeUROOiBjbj1BYmFuZG9u LGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjog Y249RXh0ZW5kZWQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNyZWF0b3JzTmFt ZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1v bml0b3JPcEluaXRpYXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQpl bnRyeUROOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRv cnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4 Wg0KbW9uaXRvcmVkSW5mbzogZ2x1ZQ0KZW50cnlETjogY249T3ZlcmxheXMs Y249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5IDAsY249 T3ZlcmxheXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBt b25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6 DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JlZEluZm86IGdsdWUN Cm1vbml0b3JSdW50aW1lQ29uZmlnOiBGQUxTRQ0KZW50cnlETjogY249T3Zl cmxheSAwLGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0K ZG46IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNO YW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlm eVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQplbnRyeUROOiBjbj1TQVNM LGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWEN Cmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXRpc3RpY3Ms Y249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29u dGFpbmVyDQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQplbnRyeUROOiBjbj1TdGF0aXN0aWNzLGNuPU1v bml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogVFJVRQ0KDQpkbjogY249Qnl0ZXMsY249U3RhdGlzdGlj cyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JD b3VudGVyT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0K Y3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVz dGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yQ291bnRlcjogMjc3MDYx ODQ0DQplbnRyeUROOiBjbj1CeXRlcyxjbj1TdGF0aXN0aWNzLGNuPU1vbml0 b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVBEVSxjbj1TdGF0aXN0aWNzLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50 ZXJPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JDb3VudGVyOiAxMDAwMTY0DQpl bnRyeUROOiBjbj1QRFUsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1FbnRyaWVzLGNuPVN0YXRpc3RpY3MsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRlck9i amVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KbW9uaXRvckNvdW50ZXI6IDEwMDAxNTgNCmVudHJ5 RE46IGNuPUVudHJpZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3RhdGlzdGljcyxjbj1N b25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVy T2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb25pdG9yQ291bnRlcjogMA0KZW50cnlETjog Y249UmVmZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3Vic2No ZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBG QUxTRQ0KDQpkbjogY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0b3JzTmFtZToN Cm1vZGlmaWVyc05hbWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5 RE46IGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBj bj1NYXgsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZp ZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQpt b2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5m bzogMTYNCmVudHJ5RE46IGNuPU1heCxjbj1UaHJlYWRzLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPU1heCBQZW5kaW5nLGNuPVRocmVhZHMs Y249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRP YmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIzMjg0OFoNCm1vbml0b3JlZEluZm86IDANCmVudHJ5RE46IGNu PU1heCBQZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVj dHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05h bWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEy MzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQpt b25pdG9yZWRJbmZvOiAyDQplbnRyeUROOiBjbj1PcGVuLGNuPVRocmVhZHMs Y249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249U3RhcnRpbmcsY249 VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogMA0KZW50 cnlETjogY249U3RhcnRpbmcsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJz Y2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6 IEZBTFNFDQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFkcyxjbj1Nb25pdG9y DQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3Jl YXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDog MjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMy ODQ4Wg0KbW9uaXRvcmVkSW5mbzogMQ0KZW50cnlETjogY249QWN0aXZlLGNu PVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1 YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249UGVu ZGluZyxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RD bGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6DQptb2RpZmll cnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25pdG9yZWRJbmZv OiAwDQplbnRyeUROOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRv cg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3Jk aW5hdGVzOiBGQUxTRQ0KDQpkbjogY249QmFja2xvYWQsY249VGhyZWFkcyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9i amVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRp bWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KbW9uaXRvcmVkSW5mbzogMQ0KZW50cnlETjogY249 QmFja2xvYWQsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1TdGF0ZSxjbj1UaHJlYWRzLGNuPU1vbml0b3INCnN0cnVjdHVy YWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdG9yc05hbWU6 DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIz Mjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb25p dG9yZWRJbmZvOiB1bmtub3duDQplbnRyeUROOiBjbj1TdGF0ZSxjbj1UaHJl YWRzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVJ1bnF1ZXVl LGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05h bWU6DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPVJ1bnF1 ZXVlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kc3Vic2NoZW1hU3ViZW50cnk6 IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjog Y249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY3JlYXRvcnNOYW1lOg0K bW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4 NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KZW50cnlE TjogY249VGFza2xpc3QsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZB TFNFDQoNCmRuOiBjbj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRvcnNOYW1lOg0KbW9k aWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KZW50cnlETjog Y249VGltZSxjbj1Nb25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vi c2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVN0YXJ0 LGNuPVRpbWUsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBt b25pdG9yZWRPYmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6 DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIzMjg0OFoNCm1vbml0b3JUaW1lc3RhbXA6IDIw MDkwMTIzMjMyODQ4Wg0KZW50cnlETjogY249U3RhcnQsY249VGltZSxjbj1N b25pdG9yDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1DdXJyZW50LGNuPVRpbWUs Y249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRP YmplY3QNCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIzMjg0OFoNCm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTIzMjMz NjQ1Wg0KZW50cnlETjogY249Q3VycmVudCxjbj1UaW1lLGNuPU1vbml0b3IN CnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGlu YXRlczogRkFMU0UNCg0KZG46IGNuPVVwdGltZSxjbj1UaW1lLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj cmVhdG9yc05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMy MzI4NDhaDQptb25pdG9yZWRJbmZvOiA0NzcNCmVudHJ5RE46IGNuPVVwdGlt ZSxjbj1UaW1lLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVRM Uyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JD b250YWluZXINCmNyZWF0b3JzTmFtZToNCm1vZGlmaWVyc05hbWU6DQpjcmVh dGVUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9kaWZ5VGltZXN0YW1w OiAyMDA5MDEyMzIzMjg0OFoNCmVudHJ5RE46IGNuPVRMUyxjbj1Nb25pdG9y DQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRp bmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRv cnNOYW1lOg0KbW9kaWZpZXJzTmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjMyMzI4NDhaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4 Wg0KZW50cnlETjogY249V2FpdGVycyxjbj1Nb25pdG9yDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUN Cg0KZG46IGNuPVJlYWQsY249V2FpdGVycyxjbj1Nb25pdG9yDQpzdHJ1Y3R1 cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdG9y c05hbWU6DQptb2RpZmllcnNOYW1lOg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5 MDEyMzIzMjg0OFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDha DQptb25pdG9yQ291bnRlcjogMQ0KZW50cnlETjogY249UmVhZCxjbj1XYWl0 ZXJzLGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVdyaXRlLGNu PVdhaXRlcnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBt b25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRvcnNOYW1lOg0KbW9kaWZpZXJz TmFtZToNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMzI4NDhaDQptb2Rp ZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjMyODQ4Wg0KbW9uaXRvckNvdW50ZXI6 IDANCmVudHJ5RE46IGNuPVdyaXRlLGNuPVdhaXRlcnMsY249TW9uaXRvcg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBGQUxTRQ0KDQo= --0-2080824295-1232747630=:87185--

1 0

(ITS#5902) website: repository example change
by quanah＠OpenLDAP.org 23 Jan '09

23 Jan '09

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) http://www.openldap.org/software/repo.html should have the CVSup example updated to refer to REL_ENG_2_4 instead of REL_ENG_2_3: OpenLDAP via CVSup The following supfile can be used with cvsup(1) to checkout the stable release. # # Standard supfile for CVSup OpenLDAP. # *default host=cvsup.openldap.org *default compress delete use-rel-suffix # *default tag=OPENLDAP_STABLE # *default tag=OPENLDAP_RELEASE # *default tag=OPENLDAP_REL_ENG_2_3 # *default tag=. cvs-all release=cvs prefix=/repo/OpenLDAP

1 0

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

23 Jan '09

Rodrigo Costa wrote: > Howard, > > I'm not sure the information needed. I look as : > > If ldapsearch finds one or more entries, the attributes specified by attrs are returned. If * is listed, all user attributes are returned. If + is listed, all operational attributes are returned. If no attrs are listed, all user attributes are returned. > > So I thought the empty attrs would return all information. All *user* attributes are returned, but not *operational* attributes. > Now with + I could see some other information but notthing related with cache. It appears that you're not using OpenLDAP 2.4, the cache attributes are not monitored in previous releases. > > What I runned was > > ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389 + -- -- 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 23 Jan '09

23 Jan '09

--0-155382548-1232743879=:83198 Content-Type: text/plain; charset=us-ascii Howard, I'm not sure the information needed. I look as : If ldapsearch finds one or more entries, the attributes specified by attrs are returned. If * is listed, all user attributes are returned. If + is listed, all operational attributes are returned. If no attrs are listed, all user attributes are returned. So I thought the empty attrs would return all information. Now with + I could see some other information but notthing related with cache. What I runned was ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389 + I'm also running at this time with the same problem openldap 2.2.26. Please see file attached with monitor information. Looks like that ever cache started to be used the cachesize or idlcachesize never restrict memory allocation. Also there is never a cache free. The code appears to have some LRU something that is supposed to release cache. I tested version 2.2.6, 2.3.4, 2.3.10, 2.4.11, 2.4.13 and I could never see after cache was implemented slapd restricting the memory usage. I use pre-compiled versions and compiled by myself. I do not think this is a 32 bits or 64 bits problem since the only difference is that 32 bits process will not be able to use more than 3GB of memory. Then in a 64 bits machine with 3GB of physical memory the same bahavior should occur if slapd doesn't use some memory cache restriction. By the way I see it now is that if you have a DB on disk that is bigger than your physical memory, or in 32 bits machines 3GB, then if you start a LDIF backup, have many random access or start replication slapd will consume all available memory and crash. Please let me know if this file is ok and if not which ldapsearch notation should I use. Thanks a lot! 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 > Cc: openldap-its(a)openldap.org > Date: Friday, January 23, 2009, 5:37 PM > Rodrigo Costa wrote: > > Howard, > > > > I had the monitor enabled. But I could not see nothing > related to cache in its output. > > > > I executed the command : > > > > ldapsearch -LLL -x -b "cn=monitor" -H > ldap://10.142.15.42:389> monitor_2.txt > > > > It is supposed to be all information provided by > monitor, as I know. > > No, the monitoring info is in operational attributes, as > documented in the slapd-monitor manpage. You have to specify > that all attributes be returned, using "*" and > "+" on the search. > > -- -- 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-155382548-1232743879=:83198 Content-Type: text/plain; name="monitor.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor.txt" ZG46IGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv clNlcnZlcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb25pdG9yZWRJbmZv OiBAKCMpICRPcGVuTERBUDogc2xhcGQgMi4yLjI2IChNYXkgMjAgMjAwNSAx NzozMjoxNCkgJA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0K aGFzU3Vib3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1PdmVybGF5LGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1UaW1lLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRS VUUNCg0KZG46IGNuPUN1cnJlbnQsY249VGltZSxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KbW9uaXRvclRp bWVzdGFtcDogMjAwOTAxMjMyMjI4NDlaDQpjcmVhdGVUaW1lc3RhbXA6IDIw MDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9y ZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVN0YXJ0LGNuPVRpbWUsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QN Cm1vbml0b3JUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KY3JlYXRlVGlt ZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAw OTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1h DQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1TdGF0aXN0aWNz LGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNv bnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0K ZG46IGNuPUJ5dGVzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3RydWN0 dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRl VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDog MjAwOTAxMjMyMTQwNTBaDQptb25pdG9yQ291bnRlcjogMjc3MDY3NzQ4DQpz dWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0 ZXM6IEZBTFNFDQoNCmRuOiBjbj1QRFUsY249U3RhdGlzdGljcyxjbj1Nb25p dG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2Jq ZWN0DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5 VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vbml0b3JDb3VudGVyOiAx MDAwMzIwDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1SZWZlcnJhbHMsY249U3Rh dGlzdGljcyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1v bml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v bml0b3JDb3VudGVyOiAwDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2No ZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1FbnRyaWVz LGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yQ291bnRlck9iamVjdA0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQptb25pdG9yQ291bnRlcjogMTAwMDMwNQ0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0ZVRpbWVzdGFtcDogMjAw OTAxMjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUw Wg0KbW9uaXRvck9wSW5pdGlhdGVkOiAyNg0KbW9uaXRvck9wQ29tcGxldGVk OiAyNQ0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBUUlVFDQoNCmRuOiBjbj1CaW5kLGNuPU9wZXJhdGlvbnMs Y249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3Bl cmF0aW9uDQptb25pdG9yT3BJbml0aWF0ZWQ6IDkNCm1vbml0b3JPcENvbXBs ZXRlZDogOQ0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCm1vbml0b3JP cEluaXRpYXRlZDogOA0KbW9uaXRvck9wQ29tcGxldGVkOiA4DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hl bWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUFkZCxjbj1P cGVyYXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczog bW9uaXRvck9wZXJhdGlvbg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25p dG9yT3BDb21wbGV0ZWQ6IDANCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMy MTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vi c2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVz OiBGQUxTRQ0KDQpkbjogY249RGVsZXRlLGNuPU9wZXJhdGlvbnMsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9u DQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JPcENvbXBsZXRlZDog MA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Nb2RyZG4sY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCm1vbml0b3JPcEluaXRp YXRlZDogMA0KbW9uaXRvck9wQ29tcGxldGVkOiAwDQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPU1vZGlmeSxjbj1PcGVy YXRpb25zLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9u aXRvck9wZXJhdGlvbg0KbW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9y T3BDb21wbGV0ZWQ6IDANCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2No ZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBG QUxTRQ0KDQpkbjogY249Q29tcGFyZSxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0K bW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDAN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 U2VhcmNoLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9i amVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQptb25pdG9yT3BJbml0aWF0 ZWQ6IDkNCm1vbml0b3JPcENvbXBsZXRlZDogOA0KY3JlYXRlVGltZXN0YW1w OiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMy MTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNT dWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBjbj1BYmFuZG9uLGNuPU9wZXJh dGlvbnMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25p dG9yT3BlcmF0aW9uDQptb25pdG9yT3BJbml0aWF0ZWQ6IDANCm1vbml0b3JP cENvbXBsZXRlZDogMA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hl bWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZB TFNFDQoNCmRuOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0 b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0K bW9uaXRvck9wSW5pdGlhdGVkOiAwDQptb25pdG9yT3BDb21wbGV0ZWQ6IDAN CmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1hU3ViZW50cnk6IGNu PVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249 TG9nLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRv ckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1XYWl0ZXJzLGNuPU1vbml0b3INCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY3JlYXRlVGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQw NTBaDQpzdWJzY2hlbWFTdWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJv cmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNuPVdyaXRlLGNuPVdhaXRlcnMsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ291bnRl ck9iamVjdA0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1v ZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb25pdG9yQ291bnRl cjogMA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vi b3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249UmVhZCxjbj1XYWl0ZXJzLGNu PU1vbml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvdW50 ZXJPYmplY3QNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpt b2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9uaXRvckNvdW50 ZXI6IDENCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1 Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPUNvbm5lY3Rpb25zLGNuPU1v bml0b3INCnN0cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlmeVRp bWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IFRSVUUNCg0KZG46IGNu PUNvbm5lY3Rpb24gOCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1 Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JDb25uZWN0aW9uDQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjIyODQ4Wg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIyMjg0OVoNCm1vbml0b3JlZEluZm86IDggOiAzIDogMi8xLzAv MSA6IDIvMi8wIDogcnggOiBjbj1hbm9ueW1vdXMgOiBsZGFwOi8vMTAuMTQy LjE1Lg0KIDQyOjM4OSA6IHVua25vd24gOiBJUD0xMC4xNDIuMTUuNDY6MzU0 ODAgOiBJUD0xMC4xNDIuMTUuNDI6Mzg5IDogMjAwOTAxMjMyMjI4DQogNDha IDogMjAwOTAxMjMyMjI4NDlaDQptb25pdG9yQ29ubmVjdGlvbk51bWJlcjog OA0KbW9uaXRvckNvbm5lY3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0Mi4x NS40MjozODkNCm1vbml0b3JDb25uZWN0aW9uUGVlckFkZHJlc3M6IElQPTEw LjE0Mi4xNS40NjozNTQ4MA0Kc3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNj aGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpkbjogY249Q3VycmVu dCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIx NDA1MFoNCm1vbml0b3JDb3VudGVyOiAxDQpzdWJzY2hlbWFTdWJlbnRyeTog Y249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCmRuOiBj bj1Ub3RhbCxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFs T2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjcmVhdGVUaW1l c3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5 MDEyMzIxNDA1MFoNCm1vbml0b3JDb3VudGVyOiA5DQpzdWJzY2hlbWFTdWJl bnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoN CmRuOiBjbj1UTFMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNz OiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIz MjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCnN1 YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRl czogRkFMU0UNCg0KZG46IGNuPVNBU0wsY249TW9uaXRvcg0Kc3RydWN0dXJh bE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3Rh bXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEy MzIxNDA1MFoNCnN1YnNjaGVtYVN1YmVudHJ5OiBjbj1TdWJzY2hlbWENCmhh c1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46IGNuPVRocmVhZHMsY249TW9u aXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVy DQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGlt ZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vbml0b3JlZEluZm86IG1heD0x Ng0KbW9uaXRvcmVkSW5mbzogYmFja2xvYWQ9MQ0Kc3Vic2NoZW1hU3ViZW50 cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0KDQpk bjogY249QmFja2VuZHMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENs YXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6IDIwMDkw MTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vbml0b3JlZEluZm86IG1vbml0b3INCm1vbml0b3JlZEluZm86IGJkYg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBUUlVFDQoNCmRuOiBjbj1CYWNrZW5kIDAsY249QmFja2VuZHMsY249 TW9uaXRvcg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmpl Y3QNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQptb2RpZnlU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9uaXRvcmVkSW5mbzogYmRi DQpzdXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjkN CnN1cHBvcnRlZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpz dXBwb3J0ZWRDb250cm9sOiAxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjINCnN1 cHBvcnRlZENvbnRyb2w6IDEuMi44NDAuMTEzNTU2LjEuNC4zMTkNCnN1cHBv cnRlZENvbnRyb2w6IDEuMy42LjEuNC4xLjQyMDMuMS4xMC4xDQpzdXBwb3J0 ZWRDb250cm9sOiAxLjIuODI2LjAuMS4zMzQ4MTAuMi4zDQpzdXBwb3J0ZWRD b250cm9sOiAxLjIuODQwLjExMzU1Ni4xLjQuMTQxMw0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249QmFja2VuZCAxLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCnN0 cnVjdHVyYWxPYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjcmVhdGVU aW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAy MDA5MDEyMzIxNDA1MFoNCm1vbml0b3JlZEluZm86IG1vbml0b3INCnN1cHBv cnRlZENvbnRyb2w6IDIuMTYuODQwLjEuMTEzNzMwLjMuNC4yDQpzdXBwb3J0 ZWRDb250cm9sOiAxLjIuODI2LjAuMS4zMzQ4MTAuMi4zDQpzdWJzY2hlbWFT dWJlbnRyeTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNF DQoNCmRuOiBjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3RydWN0dXJhbE9i amVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjcmVhdGVUaW1lc3RhbXA6 IDIwMDkwMTIzMjE0MDUwWg0KbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDEyMzIx NDA1MFoNCm1vbml0b3JDb250ZXh0OiBjbj1Nb25pdG9yDQpuYW1pbmdDb250 ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0KbmFtaW5nQ29udGV4 dHM6IG91PUNPTlRFTlQsbz1hbGNhdGVsLGM9ZnINCnN1YnNjaGVtYVN1YmVu dHJ5OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogVFJVRQ0KDQpk bjogY249RGF0YWJhc2UgMCxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kc3Ry dWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1vbml0b3Jl ZEluZm86IGJkYg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoN Cm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpuYW1pbmdDb250 ZXh0czogb3U9Q09OVEVOVCxvPWFsY2F0ZWwsYz1mcg0Kc3Vic2NoZW1hU3Vi ZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxTRQ0K DQpkbjogY249RGF0YWJhc2UgMSxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0K c3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1vbml0 b3JlZEluZm86IGJkYg0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1 MFoNCm1vZGlmeVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpuYW1pbmdD b250ZXh0czogb3U9SU5ERVhFUyxvPWFsY2F0ZWwsYz1mcg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249RGF0YWJhc2UgMixjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1v bml0b3JlZEluZm86IG1vbml0b3INCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0K bW9uaXRvckNvbnRleHQ6IGNuPU1vbml0b3INCnN1YnNjaGVtYVN1YmVudHJ5 OiBjbj1TdWJzY2hlbWENCmhhc1N1Ym9yZGluYXRlczogRkFMU0UNCg0KZG46 IGNuPUxpc3RlbmVycyxjbj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAx MjMyMTQwNTBaDQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0K c3Vic2NoZW1hU3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5h dGVzOiBUUlVFDQoNCmRuOiBjbj1MaXN0ZW5lciAwLGNuPUxpc3RlbmVycyxj bj1Nb25pdG9yDQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9i amVjdA0KbW9uaXRvckNvbm5lY3Rpb25Mb2NhbEFkZHJlc3M6IElQPTEwLjE0 Mi4xNS40MjozODkNCmNyZWF0ZVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBa DQptb2RpZnlUaW1lc3RhbXA6IDIwMDkwMTIzMjE0MDUwWg0Kc3Vic2NoZW1h U3ViZW50cnk6IGNuPVN1YnNjaGVtYQ0KaGFzU3Vib3JkaW5hdGVzOiBGQUxT RQ0KDQpkbjogY249TGlzdGVuZXIgMSxjbj1MaXN0ZW5lcnMsY249TW9uaXRv cg0Kc3RydWN0dXJhbE9iamVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCm1v bml0b3JDb25uZWN0aW9uTG9jYWxBZGRyZXNzOiBJUD0xMC4xNDIuMTUuMTcy OjM4OQ0KY3JlYXRlVGltZXN0YW1wOiAyMDA5MDEyMzIxNDA1MFoNCm1vZGlm eVRpbWVzdGFtcDogMjAwOTAxMjMyMTQwNTBaDQpzdWJzY2hlbWFTdWJlbnRy eTogY249U3Vic2NoZW1hDQpoYXNTdWJvcmRpbmF0ZXM6IEZBTFNFDQoNCg== --0-155382548-1232743879=:83198--

1 0

Re: Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by adrien.futschik＠atosorigin.com 23 Jan '09

23 Jan '09

> No. Replication is supposed to work regardless of mode, refreshOnly / > refreshAndPersist should yield identical results. ... > There is still a bug here. You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? Best regards Adrien Futschik

1 0

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

23 Jan '09

--0-65098359-1232716543=:26208 Content-Type: text/plain; charset=us-ascii Howard, I had the monitor enabled. But I could not see nothing related to cache in its output. I executed the command : ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389 > monitor_2.txt It is supposed to be all information provided by monitor, as I know. Please see file attached with information. I still not sure what or which cache is consuming all memory. I do not understand why we place cache size definitions to slapd and it doesn't respect them. Regards, Rodrigo. --- On Thu, 1/22/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: Thursday, January 22, 2009, 8:36 PM > rlvcosta(a)yahoo.com wrote: > > Quanah, > > > > I just used tcmalloc but I still with the same > behavior. slapd doesn't > > have limit for the cache and then it cannot run large > databases. > > As a side comment, we have already documented that about 1 > million entries is the practical limit for slapd on a 32 bit > machine. Since 64 bit machines are so common today, making > slapd perform well on a 32 bit machine is no longer a > priority. > > Also, by design, tcmalloc doesn't release freed memory > back to the OS, since it will most likely be needed again. > It's normal for the slapd process size to never shrink. > > One thing you can check is to add a "database > monitor" to your slapd configuration; one of the > entries under cn=monitor will report the number of items in > the back-bdb cache. Please provide this information here. > > -- -- 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-65098359-1232716543=:26208 Content-Type: text/plain; name="monitor_2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="monitor_2.txt" ZG46IGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yU2VydmVyDQpj bjogTW9uaXRvcg0KZGVzY3JpcHRpb246IFRoaXMgc3VidHJlZSBjb250YWlu cyBtb25pdG9yaW5nL21hbmFnaW5nIG9iamVjdHMuDQpkZXNjcmlwdGlvbjog VGhpcyBvYmplY3QgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBz ZXJ2ZXIuDQpkZXNjcmlwdGlvbjogTW9zdCBvZiB0aGUgaW5mb3JtYXRpb24g aXMgaGVsZCBpbiBvcGVyYXRpb25hbCBhdHRyaWJ1dGVzLCB3aGljaCANCiBt dXN0IGJlIGV4cGxpY2l0bHkgcmVxdWVzdGVkLg0KDQpkbjogY249QmFja2Vu ZHMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWluZXIN CmNuOiBCYWNrZW5kcw0KZGVzY3JpcHRpb246IFRoaXMgc3Vic3lzdGVtIGNv bnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IGF2YWlsYWJsZSBiYWNrZW5kcy4N Cg0KZG46IGNuPUJhY2tlbmQgMCxjbj1CYWNrZW5kcyxjbj1Nb25pdG9yDQpv YmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQmFja2VuZCAwDQpz ZWVBbHNvOiBjbj1EYXRhYmFzZSAwLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9y DQoNCmRuOiBjbj1CYWNrZW5kIDEsY249QmFja2VuZHMsY249TW9uaXRvcg0K b2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IEJhY2tlbmQgMQ0K DQpkbjogY249QmFja2VuZCAyLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCm9i amVjdENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBCYWNrZW5kIDINCnNl ZUFsc286IGNuPURhdGFiYXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3IN CnNlZUFsc286IGNuPURhdGFiYXNlIDIsY249RGF0YWJhc2VzLGNuPU1vbml0 b3INCg0KZG46IGNuPUJhY2tlbmQgMyxjbj1CYWNrZW5kcyxjbj1Nb25pdG9y DQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQmFja2VuZCAz DQpzZWVBbHNvOiBjbj1EYXRhYmFzZSAzLGNuPURhdGFiYXNlcyxjbj1Nb25p dG9yDQoNCmRuOiBjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RD bGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IENvbm5lY3Rpb25zDQpkZXNj cmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29udGFpbnMgaW5mb3JtYXRpb24g YWJvdXQgY29ubmVjdGlvbnMuDQoNCmRuOiBjbj1Db25uZWN0aW9uIDMsY249 Q29ubmVjdGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JD b25uZWN0aW9uDQpjbjogQ29ubmVjdGlvbiAzDQoNCmRuOiBjbj1NYXggRmls ZSBEZXNjcmlwdG9ycyxjbj1Db25uZWN0aW9ucyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNuOiBNYXggRmlsZSBE ZXNjcmlwdG9ycw0KDQpkbjogY249VG90YWwsY249Q29ubmVjdGlvbnMsY249 TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpj bjogVG90YWwNCg0KZG46IGNuPUN1cnJlbnQsY249Q29ubmVjdGlvbnMsY249 TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpj bjogQ3VycmVudA0KDQpkbjogY249RGF0YWJhc2VzLGNuPU1vbml0b3INCm9i amVjdENsYXNzOiBtb25pdG9yQ29udGFpbmVyDQpjbjogRGF0YWJhc2VzDQpk ZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29udGFpbnMgaW5mb3JtYXRp b24gYWJvdXQgY29uZmlndXJlZCBkYXRhYmFzZXMuDQoNCmRuOiBjbj1Gcm9u dGVuZCxjbj1EYXRhYmFzZXMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1v bml0b3JlZE9iamVjdA0KY246IEZyb250ZW5kDQoNCmRuOiBjbj1EYXRhYmFz ZSAwLGNuPURhdGFiYXNlcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9u aXRvcmVkT2JqZWN0DQpjbjogRGF0YWJhc2UgMA0Kc2VlQWxzbzogY249QmFj a2VuZCAwLGNuPUJhY2tlbmRzLGNuPU1vbml0b3INCg0KZG46IGNuPURhdGFi YXNlIDEsY249RGF0YWJhc2VzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBt b25pdG9yZWRPYmplY3QNCm9iamVjdENsYXNzOiBvbG1CREJEYXRhYmFzZQ0K Y246IERhdGFiYXNlIDENCnNlZUFsc286IGNuPUJhY2tlbmQgMixjbj1CYWNr ZW5kcyxjbj1Nb25pdG9yDQoNCmRuOiBjbj1EYXRhYmFzZSAyLGNuPURhdGFi YXNlcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0 DQpvYmplY3RDbGFzczogb2xtQkRCRGF0YWJhc2UNCmNuOiBEYXRhYmFzZSAy DQpzZWVBbHNvOiBjbj1CYWNrZW5kIDIsY249QmFja2VuZHMsY249TW9uaXRv cg0KDQpkbjogY249RGF0YWJhc2UgMyxjbj1EYXRhYmFzZXMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IERhdGFiYXNl IDMNCnNlZUFsc286IGNuPUJhY2tlbmQgMyxjbj1CYWNrZW5kcyxjbj1Nb25p dG9yDQoNCmRuOiBjbj1MaXN0ZW5lcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb250YWluZXINCmNuOiBMaXN0ZW5lcnMNCmRlc2NyaXB0 aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91 dCBhY3RpdmUgbGlzdGVuZXJzLg0KDQpkbjogY249TGlzdGVuZXIgMCxjbj1M aXN0ZW5lcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9i amVjdA0KY246IExpc3RlbmVyIDANCmxhYmVsZWRVUkk6IGxkYXA6Ly8xMC4x NDIuMTUuNDI6Mzg5DQoNCmRuOiBjbj1MaXN0ZW5lciAxLGNuPUxpc3RlbmVy cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj bjogTGlzdGVuZXIgMQ0KbGFiZWxlZFVSSTogbGRhcDovLzEwLjE0Mi4xNS4x NzI6Mzg5DQoNCmRuOiBjbj1Mb2csY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6 IG1vbml0b3JDb250YWluZXINCmNuOiBMb2cNCmRlc2NyaXB0aW9uOiBUaGlz IHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCBsb2dnaW5n Lg0KZGVzY3JpcHRpb246IFNldCB0aGUgYXR0cmlidXRlICJtYW5hZ2VkSW5m byIgdG8gdGhlIGRlc2lyZWQgbG9nIGxldmVscy4NCg0KZG46IGNuPU9wZXJh dGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JDb250YWlu ZXINCmNuOiBPcGVyYXRpb25zDQpkZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0 ZW0gY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgcGVyZm9ybWVkIG9wZXJh dGlvbnMuDQoNCmRuOiBjbj1CaW5kLGNuPU9wZXJhdGlvbnMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBCaW5kDQoN CmRuOiBjbj1VbmJpbmQsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvck9wZXJhdGlvbg0KY246IFVuYmluZA0KDQpkbjog Y249U2VhcmNoLGNuPU9wZXJhdGlvbnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBTZWFyY2gNCg0KZG46IGNuPUNv bXBhcmUsY249T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczog bW9uaXRvck9wZXJhdGlvbg0KY246IENvbXBhcmUNCg0KZG46IGNuPU1vZGlm eSxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25p dG9yT3BlcmF0aW9uDQpjbjogTW9kaWZ5DQoNCmRuOiBjbj1Nb2RyZG4sY249 T3BlcmF0aW9ucyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvck9w ZXJhdGlvbg0KY246IE1vZHJkbg0KDQpkbjogY249QWRkLGNuPU9wZXJhdGlv bnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24N CmNuOiBBZGQNCg0KZG46IGNuPURlbGV0ZSxjbj1PcGVyYXRpb25zLGNuPU1v bml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjbjogRGVs ZXRlDQoNCmRuOiBjbj1BYmFuZG9uLGNuPU9wZXJhdGlvbnMsY249TW9uaXRv cg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JPcGVyYXRpb24NCmNuOiBBYmFuZG9u DQoNCmRuOiBjbj1FeHRlbmRlZCxjbj1PcGVyYXRpb25zLGNuPU1vbml0b3IN Cm9iamVjdENsYXNzOiBtb25pdG9yT3BlcmF0aW9uDQpjbjogRXh0ZW5kZWQN Cg0KZG46IGNuPU92ZXJsYXlzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBt b25pdG9yQ29udGFpbmVyDQpjbjogT3ZlcmxheXMNCmRlc2NyaXB0aW9uOiBU aGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCBhdmFp bGFibGUgb3ZlcmxheXMuDQoNCmRuOiBjbj1PdmVybGF5IDAsY249T3Zlcmxh eXMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0K Y246IE92ZXJsYXkgMA0KDQpkbjogY249U0FTTCxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IFNBU0wNCmRlc2NyaXB0 aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91 dCBTQVNMLg0KDQpkbjogY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpvYmpl Y3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0KY246IFN0YXRpc3RpY3MNCmRl c2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250YWlucyBzdGF0aXN0aWNz Lg0KDQpkbjogY249Qnl0ZXMsY249U3RhdGlzdGljcyxjbj1Nb25pdG9yDQpv YmplY3RDbGFzczogbW9uaXRvckNvdW50ZXJPYmplY3QNCmNuOiBCeXRlcw0K DQpkbjogY249UERVLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUERVDQoNCmRuOiBj bj1FbnRyaWVzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogRW50cmllcw0KDQpkbjog Y249UmVmZXJyYWxzLGNuPVN0YXRpc3RpY3MsY249TW9uaXRvcg0Kb2JqZWN0 Q2xhc3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUmVmZXJyYWxzDQoN CmRuOiBjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25p dG9yQ29udGFpbmVyDQpjbjogVGhyZWFkcw0KZGVzY3JpcHRpb246IFRoaXMg c3Vic3lzdGVtIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHRocmVhZHMu DQoNCmRuOiBjbj1NYXgsY249VGhyZWFkcyxjbj1Nb25pdG9yDQpvYmplY3RD bGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogTWF4DQpkZXNjcmlwdGlvbjog TWF4aW11bSBudW1iZXIgb2YgdGhyZWFkcyBhcyBjb25maWd1cmVkDQoNCmRu OiBjbj1NYXggUGVuZGluZyxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVj dENsYXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBNYXggUGVuZGluZw0KZGVz Y3JpcHRpb246IE1heGltdW0gbnVtYmVyIG9mIHBlbmRpbmcgdGhyZWFkcw0K DQpkbjogY249T3Blbixjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBPcGVuDQpkZXNjcmlwdGlvbjog TnVtYmVyIG9mIG9wZW4gdGhyZWFkcw0KDQpkbjogY249U3RhcnRpbmcsY249 VGhyZWFkcyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2Jq ZWN0DQpjbjogU3RhcnRpbmcNCmRlc2NyaXB0aW9uOiBOdW1iZXIgb2YgdGhy ZWFkcyBiZWluZyBzdGFydGVkDQoNCmRuOiBjbj1BY3RpdmUsY249VGhyZWFk cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpj bjogQWN0aXZlDQpkZXNjcmlwdGlvbjogTnVtYmVyIG9mIGFjdGl2ZSB0aHJl YWRzDQoNCmRuOiBjbj1QZW5kaW5nLGNuPVRocmVhZHMsY249TW9uaXRvcg0K b2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IFBlbmRpbmcNCmRl c2NyaXB0aW9uOiBOdW1iZXIgb2YgcGVuZGluZyB0aHJlYWRzDQoNCmRuOiBj bj1CYWNrbG9hZCxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENsYXNz OiBtb25pdG9yZWRPYmplY3QNCmNuOiBCYWNrbG9hZA0KZGVzY3JpcHRpb246 IE51bWJlciBvZiBhY3RpdmUgcGx1cyBwZW5kaW5nIHRocmVhZHMNCg0KZG46 IGNuPVN0YXRlLGNuPVRocmVhZHMsY249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6 IG1vbml0b3JlZE9iamVjdA0KY246IFN0YXRlDQpkZXNjcmlwdGlvbjogVGhy ZWFkIHBvb2wgc3RhdGUNCg0KZG46IGNuPVJ1bnF1ZXVlLGNuPVRocmVhZHMs Y249TW9uaXRvcg0Kb2JqZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246 IFJ1bnF1ZXVlDQpkZXNjcmlwdGlvbjogUXVldWUgb2YgcnVubmluZyB0aHJl YWRzIC0gYmVzaWRlcyB0aG9zZSBoYW5kbGluZyBvcGVyYXRpb25zDQoNCmRu OiBjbj1UYXNrbGlzdCxjbj1UaHJlYWRzLGNuPU1vbml0b3INCm9iamVjdENs YXNzOiBtb25pdG9yZWRPYmplY3QNCmNuOiBUYXNrbGlzdA0KZGVzY3JpcHRp b246IExpc3Qgb2YgcnVubmluZyBwbHVzIHN0YW5kYnkgdGhyZWFkcyAtIGJl c2lkZXMgdGhvc2UgaGFuZGxpbmcgb3BlDQogcmF0aW9ucw0KDQpkbjogY249 VGltZSxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5l cg0KY246IFRpbWUNCmRlc2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250 YWlucyBpbmZvcm1hdGlvbiBhYm91dCB0aW1lLg0KDQpkbjogY249U3RhcnQs Y249VGltZSxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2Jq ZWN0DQpjbjogU3RhcnQNCg0KZG46IGNuPUN1cnJlbnQsY249VGltZSxjbj1N b25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvcmVkT2JqZWN0DQpjbjogQ3Vy cmVudA0KDQpkbjogY249VXB0aW1lLGNuPVRpbWUsY249TW9uaXRvcg0Kb2Jq ZWN0Q2xhc3M6IG1vbml0b3JlZE9iamVjdA0KY246IFVwdGltZQ0KDQpkbjog Y249VExTLGNuPU1vbml0b3INCm9iamVjdENsYXNzOiBtb25pdG9yQ29udGFp bmVyDQpjbjogVExTDQpkZXNjcmlwdGlvbjogVGhpcyBzdWJzeXN0ZW0gY29u dGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgVExTLg0KDQpkbjogY249V2FpdGVy cyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9uaXRvckNvbnRhaW5lcg0K Y246IFdhaXRlcnMNCmRlc2NyaXB0aW9uOiBUaGlzIHN1YnN5c3RlbSBjb250 YWlucyBpbmZvcm1hdGlvbiBhYm91dCByZWFkL3dyaXRlIHdhaXRlcnMuDQoN CmRuOiBjbj1SZWFkLGNuPVdhaXRlcnMsY249TW9uaXRvcg0Kb2JqZWN0Q2xh c3M6IG1vbml0b3JDb3VudGVyT2JqZWN0DQpjbjogUmVhZA0KDQpkbjogY249 V3JpdGUsY249V2FpdGVycyxjbj1Nb25pdG9yDQpvYmplY3RDbGFzczogbW9u aXRvckNvdW50ZXJPYmplY3QNCmNuOiBXcml0ZQ0KDQo= --0-65098359-1232716543=:26208--

1 0

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

23 Jan '09

Rodrigo Costa wrote: > Howard, > > I had the monitor enabled. But I could not see nothing related to cache in its output. > > I executed the command : > > ldapsearch -LLL -x -b "cn=monitor" -H ldap://10.142.15.42:389> monitor_2.txt > > It is supposed to be all information provided by monitor, as I know. No, the monitoring info is in operational attributes, as documented in the slapd-monitor manpage. You have to specify that all attributes be returned, using "*" and "+" on the search. -- -- 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#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 23 Jan '09

23 Jan '09

--On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> --On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: >> >>> Howard Chu wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Str?der >>>>> Version: HEAD >>>>> OS: Linux >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (84.163.100.169) >>>>> >>>>> >>>>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>>>> `!(*(&((lc))->lc_lcflags) >>>>> & (((0x00000020U))))' failed. >>>> I'm not seeing that here. Ran into a couple other problems though, >>>> fixed now in HEAD. Please re-test... >>> Now test008 hangs... >> >> Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 >> patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. >> >> Did you fully rebuild OpenLDAP after the latest commits? What version >> of BDB are you using? Is it fully patched? What backend was it using >> when it hung? Did you get a backtrace of where it hung? > > I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully > patched. > > I think this is related to modifications in connection.c because trouble > started after HEAD contained these changes. You still didn't answer most of these questions, or what kernel you're using. I ask about the full rebuild of OpenLDAP because the changes in the connection code changed the size of the connection struct, and I know it will fail without that rebuild. A backtrace of the hang would be useful for diagnosis, since so far neither Howard nor I can reproduce this. I'd also like to know the Linux kernel version, since some of the changes affect epoll (linux 2.6) specifically. I'm running a 2.6.18 kernel+patches currently. Also, what flags are you passing to gcc while building? -g? -O2? etc. I.e., are you putting optimizations into place. Thanks, 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 hyc＠symas.com 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > Quanah, > > I just used tcmalloc but I still with the same behavior. slapd doesn't > have limit for the cache and then it cannot run large databases. As a side comment, we have already documented that about 1 million entries is the practical limit for slapd on a 32 bit machine. Since 64 bit machines are so common today, making slapd perform well on a 32 bit machine is no longer a priority. Also, by design, tcmalloc doesn't release freed memory back to the OS, since it will most likely be needed again. It's normal for the slapd process size to never shrink. One thing you can check is to add a "database monitor" to your slapd configuration; one of the entries under cn=monitor will report the number of items in the back-bdb cache. Please provide this information here. -- -- 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 22 Jan '09

22 Jan '09

Quanah, I just used tcmalloc but I still with the same behavior. slapd doesn't have limit for the cache and then it cannot run large databases. My DB entrance is not large. One example is : dn: uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou=CONTENT,o=domain,c=country creationdate: 200808271329Z localelist: en,fr weblogin: +554184XXXXXX expirationdate: 200810161329Z profileid: 0 mail: +554184XXXXXX/type=PLMN@<domain> uid: 1219843773896+554184XXXXXX objectClass: commonuser objectClass: user accountStatus: 1 webpassword: 0000 cn: +554184XXXXXX optionvalues:: AAEAAAcBAgEAAQEBAQEBAAAAAQEBAAEBAQEAAQAAAAAAAAMAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== optionstates:: AAAAAAABAwAAAAAAAAABAAAAAQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== isintercepted: FALSE dn: pnnumber=\2B554184XXXXXX,uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou =CONTENT,o=domain,c=country subpnid: 0 pntype: 2 pncaps: 7 objectClass: phoneinfo pnnumber: +554184XXXXXX dn: submxid=0,uid=1219843773896\2B554184XXXXXX,ou=REPOSITORY,ou=CONTENT,o=domain,c=country secretcode: 0000 fraudaccessnb: 0 mailMessageStore: ./Maildir maillogin: +554184XXXXXX/type=PLMN@<domain> objectClass: commonmailbox objectClass: courierinfo submxid: 0 mailQuota: 1048576 mailpassword: <secret> homeDirectory: /var/mms/mail/0/00/0000000000/0 See above I have 3 DN's. In 64 bits systems with more memory and small dn's this could be hidden but with the time all physical memory will be used. So, I made an ldapsearch as (searching a single DN): time ldapsearch -LLL -x -D "cn=admin,ou=CONTENT,o=domain,c=country" -w secret -b "ou=CONTENT,o=domain,c=country" -H ldap://10.142.15.42:389 'pnnumber=*'| egrep -e '^pnnumber*' |wc -l 1000003 real 6m56.321s user 0m25.617s sys 0m8.392s So just one of the 3 DNs this DB has. Since the filesize is : 1.9G dn2id.bdb 3.1G id2entry.bdb 29M maillogin.bdb 3.3M objectClass.bdb 28M pnnumber.bdb 1.3M submxid.bdb 84M uid.bdb I have part of size load into cache(only for pnnnumber). But slapd doesn't respect cache limits and load all into memory. It also never release it. The entrances are not large and caches in the order of 1000 entrances should not make slapd process stay with almost 1GB of memory. Also once it occupies this memory it never release anymore. I use lsof and the tcmalloc is being used. Regards, Rodrigo. --- On Thu, 1/22/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: Thursday, January 22, 2009, 4:04 PM > --On Thursday, January 22, 2009 10:01 AM -0800 Rodrigo Costa > <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > Just a correction about the man, it was incorrect > since my man was > > getting from cache(and so from 2.3 version). Now it is > ok. > > > > I would like a little more directions about how can be > compiled openldap > > 2.4.13 with tcmalloc. Just need to include a lib path? > Some configure > > parameter in openldap? > > I use tcmalloc myself, so basically you go and build > google-perf-tools, and then you preload the library before > starting slapd. I have a little startup script for slapd: > > #!/bin/bash > ulimit -n 32768 > ulimit -c unlimited > export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc.so > exec /opt/zimbra/openldap/sbin/slapd "$@" > > > --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 22 Jan '09

22 Jan '09

--On Thursday, January 22, 2009 10:01 AM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > Just a correction about the man, it was incorrect since my man was > getting from cache(and so from 2.3 version). Now it is ok. > > I would like a little more directions about how can be compiled openldap > 2.4.13 with tcmalloc. Just need to include a lib path? Some configure > parameter in openldap? I use tcmalloc myself, so basically you go and build google-perf-tools, and then you preload the library before starting slapd. I have a little startup script for slapd: #!/bin/bash ulimit -n 32768 ulimit -c unlimited export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc.so exec /opt/zimbra/openldap/sbin/slapd "$@" --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 22 Jan '09

22 Jan '09

Quanah, Just a correction about the man, it was incorrect since my man was getting from cache(and so from 2.3 version). Now it is ok. I would like a little more directions about how can be compiled openldap 2.4.13 with tcmalloc. Just need to include a lib path? Some configure parameter in openldap? Regards, Rodrigo. --- On Thu, 1/22/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: Thursday, January 22, 2009, 2:53 PM > --On Thursday, January 22, 2009 4:46 PM +0000 > rlvcosta(a)yahoo.com wrote: > > > [root@brtldp12 yum.repos.d]# ll > /usr/man/man8/slapd.8.gz > > -rw-r--r-- 1 root root 4392 Jan 22 03:28 > /usr/man/man8/slapd.8.gz > > > > [root@brtldp12 yum.repos.d]# ll > /usr/man/man5/slapd-bdb.5.gz > > -rw-r--r-- 1 root root 4089 Jan 22 03:28 > /usr/man/man5/slapd-bdb.5.gz > > > > I was expecting to find information about dncachesize > in slapd-bdb but > > there isn't nothing there. > > [build@build11 man5]$ grep dncachesize * > slapd-bdb.5:.BI dncachesize \ <integer> > slapd-hdb.5:.BI dncachesize \ <integer> > > It's documented for me... > > .BI dncachesize \ <integer> > Specify the maximum number of DNs in the in-memory DN > cache. The > default is twice the \fBcachesize\fP. Ideally this > cache should be > large enough to contain the DNs of every entry in the > database. > > You can also find it in the online manual pages: > > <http://www.openldap.org/software/man.cgi?query=slapd-bdb&apropos=0&sektion=…> > > > > > In any case slapd never respects memory limitation and > consumes it > > without boundaries. It also never releases any memory. > > > > Then after sometime the process cannot allocate more > memory and crashes. > > As Howard noted, you need to use an alternative memory > allocator than > glibc. Investigate horde or tcmalloc. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by hyc＠symas.com 22 Jan '09

22 Jan '09

fethi.tekitek(a)alcatel-lucent.com wrote: > Full_Name: Fathy Tekitek > Version: 2.4.12 > OS: Solaris 10 (rev 8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.23.212.109) > > > Hi, > I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 using an > ldiff file > The first two entry are populate but It remains blocked > This problem is reproducible on SunBlade 100 servers but not in T5000, > SunBlade2500 and Ultra45 where it works OK. Make sure you have applied the patches to BDB 4.7.25 from the Oracle web site. This ITS will be closed. -- -- 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 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > Howard, > > I have the always the same DB_CONFIG file as below : > > set_cachesize 0 52428800 1 > > set_flags DB_LOG_AUTOREMOVE > > set_lg_regionmax 1048576 > set_lg_max 10485760 > set_lg_bsize 2097152 > > set_tmp_dir /var/tmp > > I just removed the comment lines so it fits better on screen. > > About versions I have : > > [root@brtldp12 yum.repos.d]# /usr/libexec/slapd -V > @(#) $OpenLDAP: slapd 2.4.13 (Jan 22 2009 02:28:12) $ > root@brtldp12:/root/openldap-2.4.13/servers/slapd > > [root@brtldp12 yum.repos.d]# db_verify -V > Berkeley DB 4.7.25: (May 15, 2008) > > About the man pages I have : > > [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz > -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz > > [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz > -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz > > I was expecting to find information about dncachesize in slapd-bdb but there isn't nothing there. According to CVS the documentation was added in August 2007. It's been online for quite a long time as well. http://www.openldap.org/software/man.cgi?query=slapd-bdb&sektion=5&apropos=… Another point is that the cache configurations are based on a specific number of items, and not on the size of each item in bytes. If you have particularly large entries or long DNs then you'll have greater memory use as well. -- -- 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 quanah＠zimbra.com 22 Jan '09

22 Jan '09

--On Thursday, January 22, 2009 4:46 PM +0000 rlvcosta(a)yahoo.com wrote: > [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz > -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz > > [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz > -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz > > I was expecting to find information about dncachesize in slapd-bdb but > there isn't nothing there. [build@build11 man5]$ grep dncachesize * slapd-bdb.5:.BI dncachesize \ <integer> slapd-hdb.5:.BI dncachesize \ <integer> It's documented for me... .BI dncachesize \ <integer> Specify the maximum number of DNs in the in-memory DN cache. The default is twice the \fBcachesize\fP. Ideally this cache should be large enough to contain the DNs of every entry in the database. You can also find it in the online manual pages: <http://www.openldap.org/software/man.cgi?query=slapd-bdb&apropos=0&sektion=…> > > In any case slapd never respects memory limitation and consumes it > without boundaries. It also never releases any memory. > > Then after sometime the process cannot allocate more memory and crashes. As Howard noted, you need to use an alternative memory allocator than glibc. Investigate horde or tcmalloc. --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 22 Jan '09

22 Jan '09

Howard, I have the always the same DB_CONFIG file as below : set_cachesize 0 52428800 1 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_tmp_dir /var/tmp I just removed the comment lines so it fits better on screen. About versions I have : [root@brtldp12 yum.repos.d]# /usr/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.13 (Jan 22 2009 02:28:12) $ root@brtldp12:/root/openldap-2.4.13/servers/slapd [root@brtldp12 yum.repos.d]# db_verify -V Berkeley DB 4.7.25: (May 15, 2008) About the man pages I have : [root@brtldp12 yum.repos.d]# ll /usr/man/man8/slapd.8.gz -rw-r--r-- 1 root root 4392 Jan 22 03:28 /usr/man/man8/slapd.8.gz [root@brtldp12 yum.repos.d]# ll /usr/man/man5/slapd-bdb.5.gz -rw-r--r-- 1 root root 4089 Jan 22 03:28 /usr/man/man5/slapd-bdb.5.gz I was expecting to find information about dncachesize in slapd-bdb but there isn't nothing there. Where at config.c I have : "( OLcfgDbAt:1.5 NAME 'olcDbDirtyRead' " "DESC 'Allow reads of uncommitted data' " "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, { "dncachesize", "size", 2, 2, 0, ARG_UINT|ARG_OFFSET, (void *)offsetof(struct bdb_info, bi_cache.c_eimax), "( OLcfgDbAt:1.12 NAME 'olcDbDNcacheSize' " "DESC 'DN cache size' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL } So the dncachesize is supposed to be in the code. In any case slapd never respects memory limitation and consumes it without boundaries. It also never releases any memory. Then after sometime the process cannot allocate more memory and crashes. Best Regards, Rodrigo. --- On Thu, 1/22/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: Thursday, January 22, 2009, 1:35 PM > rlvcosta(a)yahoo.com wrote: > > > See that I have 2 DBs and in each DB area in > slapd.conf, read without error by slapd as seen above, I > have the cachesize, idlcachesize and dncachesize specified > with small values just to monitor the memory usage by slapd. > > > > Unfortunately even with this configuration I still > having slapd consuming memory without release it. So if a > new entrance is queried by some LDAP client, slapd will > consume more memory. Since my DB dn's are bigger than > 3GB then soon or later the slapd will crash. > > > > See my DB information : > > > > 7.2G dn2id.bdb > > 12G id2entry.bdb > > 110M maillogin.bdb > > 3.3M objectClass.bdb > > 108M pnnumber.bdb > > 1.3M submxid.bdb > > 323M uid.bdb > > > > See my dn2id is much bigger than yours and maybe you > just did not saw this > issue happenig since your dn can be loaded in your memory > and you in a 64 bits > environment can use more than 3GB per process. > > > > But in any case looks like there is a problem in slapd > that do not respect > the cache limitations imposed. > > > > In this way we cannot use slapd for large databases. > Please see my > configuration above and let me know if a made a mistake(I > hope so) since > dncachesize is not documented at man pages. > > You're mistaken, dncachesize is in the 2.4 manpages. > You seem to not be > reading the documentation that came with the software > release you're using. > > > Just as example, with the DB I loaded for tests with 1 > million entrances, with the cache sizes definitions as in > the slapd.conf described above and making a ldapsearch on > all entrances from the CONTENT DB, in the end I have : > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM > TIME+ COMMAND > > 3189 ldap 15 0 842m 724m 67m S 99 6.1 > 7:00.48 slapd > > > > See the slapd process already consumed 842m and I just > read 1 million entrances, even dncachesize is defined to be > 1000. > > > > I do not see anyway to control the memory usage by > slapd. > > > > Is this "disrespect" to slapd.conf > directives a possible problem? > > Looks like slapd is behaving normally so far, though > it's hard to tell without > also seeing your DB_CONFIG settings. Test again with your > full database and > report the results. > > -- > -- 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 22 Jan '09

22 Jan '09

hyc(a)symas.com wrote: > rlvcosta(a)yahoo.com wrote: > >> See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. >> >> Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. >> >> See my DB information : >> >> 7.2G dn2id.bdb >> 12G id2entry.bdb >> 110M maillogin.bdb >> 3.3M objectClass.bdb >> 108M pnnumber.bdb >> 1.3M submxid.bdb >> 323M uid.bdb > You're mistaken, dncachesize is in the 2.4 manpages. You seem to not be > reading the documentation that came with the software release you're using. > >> Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd >> >> See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. >> >> I do not see anyway to control the memory usage by slapd. >> >> Is this "disrespect" to slapd.conf directives a possible problem? > > Looks like slapd is behaving normally so far, though it's hard to tell without > also seeing your DB_CONFIG settings. Test again with your full database and > report the results. > I'll note that this is a pathological use case for glibc malloc. With a cache of only 1000 entries, searching 1 million entries will result in several million malloc/free calls which will fragment the heap, and that will cause results like what you're seeing. You'll have better luck with hoard or tcmalloc. -- -- 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: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by hyc＠symas.com 22 Jan '09

22 Jan '09

adrien.futschik(a)atosorigin.com wrote: > I Think I found the problem. > > I have to confirm this, but the "olcSpSessionlog" parameter doesn't seem > to be necessary. > I made a mistake in my configuration. I used "refreshOnly" mode for the backend and with "refreshOnly", consumer isn't aware when a provider deletes an entry. So I understood at least. No. Replication is supposed to work regardless of mode, refreshOnly / refreshAndPersist should yield identical results. > Here is a extract from the documentation about syncrepl : "Also as a > consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in refreshOnly mode the provider cannot detect and propagate this change without the use of the session log." The above text is correct, but it is talking about partial replication where the syncrepl search filter causes only a subset of the entries to be replicated. That does not apply to your case because you haven't set any special filter in your syncrepl config. > So I guess this was not a bug, but a mistake in the documentation : > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > > Can anyone confirm ? There is still a bug here. -- -- 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 22 Jan '09

22 Jan '09

rlvcosta(a)yahoo.com wrote: > See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. > > Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. > > See my DB information : > > 7.2G dn2id.bdb > 12G id2entry.bdb > 110M maillogin.bdb > 3.3M objectClass.bdb > 108M pnnumber.bdb > 1.3M submxid.bdb > 323M uid.bdb > > See my dn2id is much bigger than yours and maybe you just did not saw this issue happenig since your dn can be loaded in your memory and you in a 64 bits environment can use more than 3GB per process. > > But in any case looks like there is a problem in slapd that do not respect the cache limitations imposed. > > In this way we cannot use slapd for large databases. Please see my configuration above and let me know if a made a mistake(I hope so) since dncachesize is not documented at man pages. You're mistaken, dncachesize is in the 2.4 manpages. You seem to not be reading the documentation that came with the software release you're using. > Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd > > See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. > > I do not see anyway to control the memory usage by slapd. > > Is this "disrespect" to slapd.conf directives a possible problem? Looks like slapd is behaving normally so far, though it's hard to tell without also seeing your DB_CONFIG settings. Test again with your full database and report the results. -- -- 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: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠OpenLDAP.org 22 Jan '09

22 Jan '09

> So I guess this was not a bug, but a mistake in the documentation : > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > > Can anyone confirm ? Yes, you are correct, apologies. Ando fixed this in test050: ----------- 1.14 Sun Nov 16 22:06:30 2008 UTC; 2 months ago by ando Changed since 1.13: +28 -10 lines Diffs to 1.13 (colored diff) add indexes when supported; syncrepl on configuration should always be refreshAndPersist ----------- and I missed it for updating the docs. The update to the guide will be in the next release, 2.4.14 I'll close this ITS now. Thanks! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

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

22 Jan '09

Quanah, I follow your recommendation and compiled the Berkeley Db 4.7.25NC and openldap 2.4.13. After that load my LDIF file to have 1million entraces in my DB just to test the dncachesize control. During my initialization I have : module back_bdb.la: null module registered line 29 (moduleload back_monitor.la) loaded module back_monitor.la module back_monitor.la: null module registered line 74 (database bdb) line 75 (suffix "ou=CONTENT,o=alcatel,c=fr") line 76 (rootdn "cn=admin,ou=CONTENT,o=alcatel,c=fr") line 80 (rootpw ***) line 86 (directory /var/openldap-data/bdb1) line 89 (index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres) index uid 0x0006 index pnnumber 0x0006 index submxid 0x0006 index maillogin 0x0006 index abookaliasid 0x0006 line 90 (index objectClass eq) index objectClass 0x0004 line 93 (cachesize 1000) line 94 (idlcachesize 1000) line 95 (dncachesize 1000) line 105 (database bdb) line 106 (suffix "ou=INDEXES,o=alcatel,c=fr") line 107 (rootdn "cn=admin,ou=INDEXES,o=alcatel,c=fr") line 111 (rootpw ***) line 114 (directory /var/openldap-data/bdb2) line 117 (index weblogin,maillogin,mail,pnnumber eq,pres) index weblogin 0x0006 index maillogin 0x0006 index mail 0x0006 index pnnumber 0x0006 line 118 (index profileid,loginname eq,pres) index profileid 0x0006 index loginname 0x0006 line 119 (index objectClass eq) index objectClass 0x0004 line 122 (cachesize 1000) line 123 (idlcachesize 1000) line 124 (dncachesize 1000) line 129 (database monitor) slapd starting See that I have 2 DBs and in each DB area in slapd.conf, read without error by slapd as seen above, I have the cachesize, idlcachesize and dncachesize specified with small values just to monitor the memory usage by slapd. Unfortunately even with this configuration I still having slapd consuming memory without release it. So if a new entrance is queried by some LDAP client, slapd will consume more memory. Since my DB dn's are bigger than 3GB then soon or later the slapd will crash. See my DB information : 7.2G dn2id.bdb 12G id2entry.bdb 110M maillogin.bdb 3.3M objectClass.bdb 108M pnnumber.bdb 1.3M submxid.bdb 323M uid.bdb See my dn2id is much bigger than yours and maybe you just did not saw this issue happenig since your dn can be loaded in your memory and you in a 64 bits environment can use more than 3GB per process. But in any case looks like there is a problem in slapd that do not respect the cache limitations imposed. In this way we cannot use slapd for large databases. Please see my configuration above and let me know if a made a mistake(I hope so) since dncachesize is not documented at man pages. Just as example, with the DB I loaded for tests with 1 million entrances, with the cache sizes definitions as in the slapd.conf described above and making a ldapsearch on all entrances from the CONTENT DB, in the end I have : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3189 ldap 15 0 842m 724m 67m S 99 6.1 7:00.48 slapd See the slapd process already consumed 842m and I just read 1 million entrances, even dncachesize is defined to be 1000. I do not see anyway to control the memory usage by slapd. Is this "disrespect" to slapd.conf directives a possible problem? I hope there is a configuration problem with my slapd.conf where this could be work around. Regards, Rodrigo. --- On Wed, 1/21/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: Wednesday, January 21, 2009, 8:30 PM > --On Wednesday, January 21, 2009 12:49 PM -0800 Rodrigo > Costa <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > That's is exactly the point. My system is a 32 > bits and with 64 bits if > > there are enough physical memory available even slapd > cache grows without > > never release it will be difficult(or very long) to > cache enough > > entrances before system consumes all memory. > > > > With the 32 bits 3GB maximum, depend on OS too, this > issue appears more > > often. My impression is if you ldapsearch all DB in a > 32 bits HW/OS slapd > > will consume all possible memory unless to keep > boundaries for its > > cache(erase and overwrite). > > As I noted, in 2.3, you cannot constrain the DN cachesize. > You can do this with OL 2.4. You need to try a current > RE2.4 release, and set the dncachesize. There was no dn > cache at all in OL 2.1. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by adrien.futschik＠atosorigin.com 22 Jan '09

22 Jan '09

I Think I found the problem. I have to confirm this, but the "olcSpSessionlog" parameter doesn't seem to be necessary. I made a mistake in my configuration. I used "refreshOnly" mode for the backend and with "refreshOnly", consumer isn't aware when a provider deletes an entry. So I understood at least. Here is a extract from the documentation about syncrepl : "Also as a consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in refreshOnly mode the provider cannot detect and propagate this change without the use of the session log." Therefore I changed "refreshOnly" for "refreshAndPersist", I removed the "olcSpSessionlog" parameter, and everything seems to be working fine. At least, deletes are correctly replicated to the second master. Here is the final configuration I am using : m1 -config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m2 - config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m1 - syncprov : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m2 - syncrepl : dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m1 - schema : include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif m1 - backend : dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshAndPersist interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshAndPersist interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov So I guess this was not a bug, but a mistake in the documentation : http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master Can anyone confirm ? Adrien Futschik

1 0

Re: (ITS#5883) [PATCH] syncrepl test enhancements
by hyc＠symas.com 21 Jan '09

21 Jan '09

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: HEAD > OS: irrelevant > URL: https://www.nbcs.rutgers.edu/~richton/syncrepl-modrdn-tests.patch > Submission from: (NULL) (67.85.181.229) > > > Per http://www.openldap.org/lists/openldap-devel/200812/msg00004.html these > patches enhance tests to detect ITS#5809-like behavior. > > The actual test changes are at the address linked to this report. They should > apply clean to HEAD and can be used immediately with, for example, back-ldif. I > note that I wasn't able to reproduce a failure under test018; if anybody can > suggest a different test there, that'd be great, or perhaps the stopping and > starting somehow masks the condition? > > While verifying the tests, I noticed that some backends (such as back-bdb) were > failing because the consumer and provider returned the attributes in a different > order. Since attribute ordering isn't guaranteed, I viewed this as a test > failure rather than a slapd failure, and used the back-ndb gawk acfilter.sh to > work around this. In the end I just made it apply to all backends: Since we want to minimize the dependency on gawk, I took a look at the ordering failure. It occurs because the syncrepl consumer internally processes renames before it processes modifies. As such, just changing the test script to execute in this order seems to avoid the problem. > > https://www.nbcs.rutgers.edu/~richton/acfilter.patch > > but we'll probably want to discuss this on -devel: it adds a gawk dependency to > the tests. > > With the acfilter.sh sorting enabled, I found three tests that don't filter the > original data prior to ldapsearch comparison. I added these filters in: > > https://www.nbcs.rutgers.edu/~richton/openldap-testflt.patch Sounds like it should be harmless to include this patch... > > We all know that nothing's free -- a couple extra commands in the name of bug > coverage is probably worth it -- but the gawk dependency may be troublesome. > Anyway, do what you will...I consider these pretty trivial, so: > > These patch files are derived from OpenLDAP Software. All of the modifications > to OpenLDAP Software represented in these patches were developed by Aaron > Richton<richton(a)nbcs.rutgers.edu>. I have not assigned rights and/or interest > in this work to any party. > > I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these modifications may > be freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5901) modrdn syncing busted
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As noted in a post to the bugs list: Hello, I have configured a central OpenLDAP, using Debian Etch, version: slapd 2.3.30-5+etch1, which is also a sync provider. Another Debian Etch box uses the sync: syncrepl rid=123 provider=ldap://example.com type=refreshAndPersist retry="5,2,30,2,60,+" interval=00:01:00:00 searchbase="basedn" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=0 timelimit=0 schemachecking=on bindmethod=simple binddn="someDN" credentials="somePwd" starttls=critical This works fine, but moddn fails: for testing purpose I ldapadd : dn: c=testtt,ou=basedn c: testtt objectClass: country then: ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww' It works on the sync provider (schemacheck on) and the result is: dn: c=testww,ou=basedn objectClass: country c: testww But on the sync consumer: : syncrepl_entry: c=testww,ou=basedn : Entry (c=testww,ou=basedn attribute 'c' cannot have multiple values : entry failed schema check: attribute 'c' cannot have multiple values : null_callback : error code 0x13 : syncrepl_entry: be_modrdn (19) The testtt entry is still present on the secondary box. If I delete "testww" on the sync provider, the "testt" entry in the consumere is deleted. As noted by Howard in follow up: Actually... this would have worked correctly in 2.4.11 and 2.4.12. In 2.4.13 I reverted back to the 2.3 behavior due to other concerns, so this will probably fail again. And the test script does a rename on an entry whose distinguished attribute is multivalued, so it doesn't catch this case. I think we'll have to revisit this patch for 2.4.14 and add an additional rename test to test017 and test018.

1 0

Re: (ITS#5701) connection.c asserting during test008
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Saturday, September 20, 2008 8:03 PM +0000 richton(a)nbcs.rutgers.edu wrote: > On Sat, 20 Sep 2008, Pierangelo Masarati wrote: > Connection code has been reworked in current RE24 and may have resolved this issue. Can you please test? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5880) back-bdb segfault
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Saturday, January 17, 2009 3:13 AM +0000 quanah(a)zimbra.com wrote: > I'm just warning that current RE24 is not expected to be at all stable. In fact, I note that both your reports are against RE24 CVS checkouts, and not a release. Please reproduce in a release (I expect it will still occur there), rather than unstable CVS. Thanks, 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 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 12:49 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > That's is exactly the point. My system is a 32 bits and with 64 bits if > there are enough physical memory available even slapd cache grows without > never release it will be difficult(or very long) to cache enough > entrances before system consumes all memory. > > With the 32 bits 3GB maximum, depend on OS too, this issue appears more > often. My impression is if you ldapsearch all DB in a 32 bits HW/OS slapd > will consume all possible memory unless to keep boundaries for its > cache(erase and overwrite). As I noted, in 2.3, you cannot constrain the DN cachesize. You can do this with OL 2.4. You need to try a current RE2.4 release, and set the dncachesize. There was no dn cache at all in OL 2.1. --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 21 Jan '09

21 Jan '09

Quanah, That's is exactly the point. My system is a 32 bits and with 64 bits if there are enough physical memory available even slapd cache grows without never release it will be difficult(or very long) to cache enough entrances before system consumes all memory. With the 32 bits 3GB maximum, depend on OS too, this issue appears more often. My impression is if you ldapsearch all DB in a 32 bits HW/OS slapd will consume all possible memory unless to keep boundaries for its cache(erase and overwrite). In 64 bits with a lot of memory this will be more difficult to happen but eventually will happen if the logic is the same. I was wondering if in a sittuation where this cache memory issue would appear, like ldapsearch, if there is a feature in openldap where it would guarantee the cache boundaries and the reutilization of the space after the limits are reached. Looks like even with the slapd.conf configurations it doesn't keeps its limits. Regards, Rodrigo. --- On Wed, 1/21/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: Wednesday, January 21, 2009, 6:41 PM > --On Wednesday, January 21, 2009 12:23 PM -0800 Rodrigo > Costa <rlvcosta(a)yahoo.com> wrote: > > > Quanah, > > > > My initial attempt was using openldap2.4.11 since this > is the stable > > version. At this version Berkeley DB 4.7 isn't > supported and then I used > > the BDB 4.6 with all patches. > > I hardly consider 2.4.11 stable, regardless of what the tag > is. I would advise trying something more current (such as > 2.4.13). And with BDB 4.7 + patches. > > > At this configuration, having the DB_CONFIG setup for > 50MB, and even > > having the idlcache and cache sizes defined I continue > to see the memory > > being allocated and never released by slapd. > > What about dncachesize as well? > > > 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in > backend library for > > BDB4.4. > > If you are looking for stability, I would hardly go with > the crappy release CentOS ships. The final 2.3 release was > 2.3.43. Use it instead if you want to use 2.3. > > Also, are you on a 32 or 64-bit system? I certainly have > no problems going over 3GB on my 64-bit systems. > > For example: > [zimbra@ldap openldap-data]$ du -c -h *.bdb > 1.1G cn.bdb > 564M displayName.bdb > 702M dn2id.bdb > 158M entryCSN.bdb > 122M entryUUID.bdb > 335M givenName.bdb > 6.5G id2entry.bdb > 1.1G mail.bdb > 5.5M objectClass.bdb > 855M sn.bdb > 121M uid.bdb > 8.0K zimbraDomainName.bdb > 122M zimbraId.bdb > 20K zimbraMailAlias.bdb > 1.1G zimbraMailDeliveryAddress.bdb > 2.1M zimbraMailForwardingAddress.bdb > 3.1M zimbraMailTransport.bdb > 8.0K zimbraVirtualHostname.bdb > 8.0K zimbraVirtualIPAddress.bdb > 13G total > > > DB is 13GB in size. > > [zimbra@ldap openldap-data]$ cat DB_CONFIG > set_cachesize 8 0 2 > set_lg_regionmax 262144 > set_lg_bsize 2097152 > set_lk_max_locks 1500 > set_flags DB_LOG_AUTOREMOVE > set_lg_dir /var/log/zimbra-ldap-journals > > Process size: > > 8447 zimbra 17 0 9.9g 8.9g 8.1g S 34 57.5 39:20.57 > slapd > > > Using OpenLDAP 2.3.42. > > > --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 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 12:23 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah, > > My initial attempt was using openldap2.4.11 since this is the stable > version. At this version Berkeley DB 4.7 isn't supported and then I used > the BDB 4.6 with all patches. I hardly consider 2.4.11 stable, regardless of what the tag is. I would advise trying something more current (such as 2.4.13). And with BDB 4.7 + patches. > At this configuration, having the DB_CONFIG setup for 50MB, and even > having the idlcache and cache sizes defined I continue to see the memory > being allocated and never released by slapd. What about dncachesize as well? > 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in backend library for > BDB4.4. If you are looking for stability, I would hardly go with the crappy release CentOS ships. The final 2.3 release was 2.3.43. Use it instead if you want to use 2.3. Also, are you on a 32 or 64-bit system? I certainly have no problems going over 3GB on my 64-bit systems. For example: [zimbra@ldap openldap-data]$ du -c -h *.bdb 1.1G cn.bdb 564M displayName.bdb 702M dn2id.bdb 158M entryCSN.bdb 122M entryUUID.bdb 335M givenName.bdb 6.5G id2entry.bdb 1.1G mail.bdb 5.5M objectClass.bdb 855M sn.bdb 121M uid.bdb 8.0K zimbraDomainName.bdb 122M zimbraId.bdb 20K zimbraMailAlias.bdb 1.1G zimbraMailDeliveryAddress.bdb 2.1M zimbraMailForwardingAddress.bdb 3.1M zimbraMailTransport.bdb 8.0K zimbraVirtualHostname.bdb 8.0K zimbraVirtualIPAddress.bdb 13G total DB is 13GB in size. [zimbra@ldap openldap-data]$ cat DB_CONFIG set_cachesize 8 0 2 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_locks 1500 set_flags DB_LOG_AUTOREMOVE set_lg_dir /var/log/zimbra-ldap-journals Process size: 8447 zimbra 17 0 9.9g 8.9g 8.1g S 34 57.5 39:20.57 slapd Using OpenLDAP 2.3.42. --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 21 Jan '09

21 Jan '09

Quanah, My initial attempt was using openldap2.4.11 since this is the stable version. At this version Berkeley DB 4.7 isn't supported and then I used the BDB 4.6 with all patches. At this configuration, having the DB_CONFIG setup for 50MB, and even having the idlcache and cache sizes defined I continue to see the memory being allocated and never released by slapd. Now I tried to evolve my OS to CentOS5.2 and then see if it could be an issue with my compilation using a community compiled openldap version that could have syncrepl available. Based in my issues I'm not using syncrepl at this time since I'm trying to check a stable sittuation for my DB. What I'm observing is that under openldap version 2.3 and 2.4 if I have a DB, at least with BDB, that could be searched and generate indexes bigger than 3GB(max OS memory space per process), the search will make slapd load all indexes in memory and never release them. This make that openldap would not be used for DBs which size would become bigger than 3GB. What would be the major part of cases. Once a DB entrance is searched, it is loaded into memory and never more released. So, for example, if I made several binds to the same entrance in DB, slapd never allocates more memory and uses the already cached entrance. But if I search for different entrances in DB, slapd always cache in memory and continues to do it until it reaches the 3GB barrier and then process cannot allocate more memory. slapd never release cache memory, respect the default idlcachesize and cachesize that is 1000, or even release cache memory. So if there is not ldapsearch for a backup, that could speed this behavior, with the time if the queries are done randomly at certain time the cache will become of size 3GB and no more memory can be allocated. My actual version now is: 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in backend library for BDB4.4. My DB_CONFIG is(without comments) : set_cachesize 0 52428800 1 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_tmp_dir /var/tmp And the slapd.conf I included(the indexes always existed) : # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/openldap-data/bdb1 # Indices to maintain for this database index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres index objectClass eq #Cache values cachesize 1000 idlcachesize 1000 This issue, by other ITSs, appear to exist before. Not sure if this is really a configuration problem. Running slapd with -d 64 showed the cachesize and idlcachesize did not return any complain. Please let me know if you have some idea about this problem. I will try to use the not yet stable 2.4.13 but I would like to have your feedback if this could really be caused by other problem or even if in openldap 2.4.13 there are some detection/solution for this kind of issue. Regards, Rodrigo. --- On Wed, 1/21/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: Wednesday, January 21, 2009, 5:57 PM > --On Tuesday, January 20, 2009 12:07 AM +0000 > rlvcosta(a)yahoo.com wrote: > > > Pierangelo, > > > > Executing some test I'm not sure anymore if this > is really a memory > > leakage or if some cache issue. > > > > I decided to install CentOS5.2 where I could have > OpenLdap 2.3.27 > > compiled by the distribution and then execute more > tests to check if some > > library in RHEL4 would be causing some problem. > > > > I then use a similar slapd.conf as in my original > e-mail just without > > explicitly define an size for cache and idlcache > there. My DB_CONFIG file > > has a cache defined as 50MB what is respected. > > > > Looking at some other ITS I found the ITS#3938 what I > believe is very > > similar to my problem. > > > > I still have a DB with 3882998 entrances and where the > DB files at disk > > is around 15GB. My machine has 12GB of memory where > for sure all the DB > > cannot be cached into memory. > > > > In any case what is happening is that every time a > transaction is done > > with OpenLdap, even a distribution formal compilation, > the cache > > continues to grow until consumes all memory. If the DB > is bigger than > > machine memory then soon or later a memory out of > range will happen. > > > > The cache is never release by OpenLdap and then if a > sequential search is > > done and since DB is bigger than memory we can speed > up the problem. > > I would suggest you use OpenLDAP 2.4, and set the > slapd.conf cachesize, > idlcachesize, and dncachesize. I would also review your > settings for > DB_CONFIG, and use a newer BDB version with OpenLDAP 2.4 > (i.e., BDB 4.7 > with all 3 patches). See if that helps resolve the issue > you face. In > OpenLDAP 2.3, there is no way to control the dncachesize. > > --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 21 Jan '09

21 Jan '09

--On Tuesday, January 20, 2009 12:07 AM +0000 rlvcosta(a)yahoo.com wrote: > Pierangelo, > > Executing some test I'm not sure anymore if this is really a memory > leakage or if some cache issue. > > I decided to install CentOS5.2 where I could have OpenLdap 2.3.27 > compiled by the distribution and then execute more tests to check if some > library in RHEL4 would be causing some problem. > > I then use a similar slapd.conf as in my original e-mail just without > explicitly define an size for cache and idlcache there. My DB_CONFIG file > has a cache defined as 50MB what is respected. > > Looking at some other ITS I found the ITS#3938 what I believe is very > similar to my problem. > > I still have a DB with 3882998 entrances and where the DB files at disk > is around 15GB. My machine has 12GB of memory where for sure all the DB > cannot be cached into memory. > > In any case what is happening is that every time a transaction is done > with OpenLdap, even a distribution formal compilation, the cache > continues to grow until consumes all memory. If the DB is bigger than > machine memory then soon or later a memory out of range will happen. > > The cache is never release by OpenLdap and then if a sequential search is > done and since DB is bigger than memory we can speed up the problem. I would suggest you use OpenLDAP 2.4, and set the slapd.conf cachesize, idlcachesize, and dncachesize. I would also review your settings for DB_CONFIG, and use a newer BDB version with OpenLDAP 2.4 (i.e., BDB 4.7 with all 3 patches). See if that helps resolve the issue you face. In OpenLDAP 2.3, there is no way to control the dncachesize. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 6:41 PM +0000 fethi.tekitek(a)alcatel-lucent.com wrote: > Full_Name: Fathy Tekitek > Version: 2.4.12 > OS: Solaris 10 (rev 8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.23.212.109) > > > Hi, > I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 > using an ldiff file > The first two entry are populate but It remains blocked > This problem is reproducible on SunBlade 100 servers but not in T5000, > SunBlade2500 and Ultra45 where it works OK. > I can enter the content of this file one bye one but all in the ldiff file > "/export/home/build26/openldap/bin/ldapadd -d 1 -H "ldaps://sunval233 " > -x -D "cn=root,dc=alu,dc=com" -f > /export/home/build26/CSA/data/installation/ngsecPopulate.ldif -w newuser1" Usage questions should generally be directed to openldap-software(a)openldap.org. I will note that (a) There are 3 patches now for BDB 4.7, make sure you are using them all, and (b) if your database is stored in NFS, that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 2:35 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully > patched. > > The interesting fact is that HEAD currently hangs all the time in > test008. RE24 with your recent changes now fails as described in > test039. Before these changes RE24 just worked fine. > > I think this is related to modifications in connection.c because trouble > started after HEAD contained these changes. All tests pass for me with current RE24 and HEAD. What Linux kernel are you using? The RE24 changes to the connection code are the same as what are in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5900) Problem to populate LDAP 2.4.12 with an Ldiff file on SUNBLADE
by fethi.tekitek＠alcatel-lucent.com 21 Jan '09

21 Jan '09

Full_Name: Fathy Tekitek Version: 2.4.12 OS: Solaris 10 (rev 8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.23.212.109) Hi, I try to populate the openldap 2.4.12 running with BerkeleyDB 4.7.25 using an ldiff file The first two entry are populate but It remains blocked This problem is reproducible on SunBlade 100 servers but not in T5000, SunBlade2500 and Ultra45 where it works OK. I can enter the content of this file one bye one but all in the ldiff file "/export/home/build26/openldap/bin/ldapadd -d 1 -H "ldaps://sunval233 " -x -D "cn=root,dc=alu,dc=com" -f /export/home/build26/CSA/data/installation/ngsecPopulate.ldif -w newuser1" here the ldap traces ldap_url_parse_ext(ldaps://sunval233) ldap_create ldap_url_parse_ext(ldaps://sunval233:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sunval233:636 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 10.0.0.233:636 ldap_pvt_connect: fd: 4 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS certificate verification: depth: 0, err: 0, subject: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC/CN=sunval233, issuer: /C=ES/ST=Madrid/L=Madrid/O=Alcatel-Lucent/OU=NGSEC TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 43 bytes to sd 4 ldap_result ld 90c48 msgid 1 wait4msg ld 90c48 msgid 1 (infinite timeout) wait4msg continue ld 90c48 msgid 1 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 1 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select read1msg: ld 90c48 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 90c48 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 90c48 0 new referrals read1msg: mark request completed, ld 90c48 msgid 1 request done: ld 90c48 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree adding new entry "dc=alu,dc=com" ldap_add_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 101 bytes to sd 4 ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ldap_result ld 90c48 msgid 2 wait4msg ld 90c48 msgid 2 (timeout 100000 usec) wait4msg continue ld 90c48 msgid 2 all 1 ** ld 90c48 Connections: * host: sunval233 port: 636 (default) refcnt: 2 status: Connected last used: Thu May 12 08:04:02 2009 ** ld 90c48 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 90c48 request count 1 (abandoned 0) ** ld 90c48 Response Queue: Empty ld 90c48 response count 0 ldap_chkResponseList ld 90c48 msgid 2 all 1 ldap_chkResponseList returns ld 90c48 NULL ldap_int_select ^C #

1 0

Re: (ITS#5899) make fails on AIX5.3
by quanah＠zimbra.com 21 Jan '09

21 Jan '09

--On Wednesday, January 21, 2009 5:12 PM +0000 masterson.andrew(a)gmail.com wrote: > Full_Name: Andrew > Version: 2.4.11 > OS: AIX5.3 64 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.98.237.232) > > > configure runs > > CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include > LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 OpenLDAP 2.4.11 does not support BDB 4.7. Use OpenLDAP 2.4.12 or later for BDB 4.7 support. And make sure you have all 3 patches for BDB 4.7. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5899) make fails on AIX5.3
by masterson.andrew＠gmail.com 21 Jan '09

21 Jan '09

Full_Name: Andrew Version: 2.4.11 OS: AIX5.3 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.98.237.232) configure runs CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib ./configure --enable-ipv6 (and gives warnings about openssl and Cyrus SASL not being installed - otherwise fine) make fails with the following error: cd back-bdb; make all rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c cc_r -g -I../../../include -I../../../include -I.. -I./.. -I/usr/local/BerkeleyDB.4.7/include -c init.c -o init.o "init.c", line 509.49: 1506-022 (S) "lk_handle" is not a member of "struct __db_env". "init.c", line 752.32: 1506-280 (W) Function argument assignment between types "int(*)(unsigned long,unsigned long)" and "int(*)(void)" is not allowed. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop.

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 21 Jan '09

21 Jan '09

quanah(a)zimbra.com wrote: > --On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (84.163.100.169) >>>> >>>> >>>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>>> `!(*(&((lc))->lc_lcflags) >>>> & (((0x00000020U))))' failed. >>> I'm not seeing that here. Ran into a couple other problems though, fixed >>> now in HEAD. Please re-test... >> Now test008 hangs... > > Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, > and HEAD CVS as of 1/20/2009 @ 12:00 PST. > > Did you fully rebuild OpenLDAP after the latest commits? What version of > BDB are you using? Is it fully patched? What backend was it using when it > hung? Did you get a backtrace of where it hung? I'm using libdb-4_5-4.5.20-94.17 from openSUSE 11.1 which is AFAIK fully patched. The interesting fact is that HEAD currently hangs all the time in test008. RE24 with your recent changes now fails as described in test039. Before these changes RE24 just worked fine. I think this is related to modifications in connection.c because trouble started after HEAD contained these changes. Ciao, Michael.

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 21 Jan '09

21 Jan '09

ghenry(a)suretecsystems.com wrote: > ----- ando(a)sys-net.it wrote: > >> Gavin Henry wrote: >>> Sorry, I presume this was a bug in the code and the docs document >> the >>> right behaviour? >>> >>> I'll revert them when you've confirmed. >> As far as I remember, the bug was in the example in >> slapo-constraint(5) >> man page ("[:digit:]" indicates the collection of values ":", "d", >> "i", >> ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct >> > > OK, it was actually this bit: > > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ > > and in HEAD it still only had one set of []. Both the admin guide and man page > have been updated for this in my last commit. Definitely my fault: apparently, I fixed it in my working copy long ago (maybe while offline) and forgot to commit. I just found it out because of a conflict when updating with your fix. Thanks, 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

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠suretecsystems.com 21 Jan '09

21 Jan '09

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > Sorry, I presume this was a bug in the code and the docs document > the > > right behaviour? > > > > I'll revert them when you've confirmed. > > As far as I remember, the bug was in the example in > slapo-constraint(5) > man page ("[:digit:]" indicates the collection of values ":", "d", > "i", > ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct > OK, it was actually this bit: constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ and in HEAD it still only had one set of []. Both the admin guide and man page have been updated for this in my last commit. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 20 Jan '09

20 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. > > Patch attached. Thanks, fixed (with minor modifications). 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

Re: (ITS#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 20 Jan '09

20 Jan '09

Howard Chu schrieb: > oliver(a)itc.li wrote: >> Full_Name: Oliver Liebel >> Version: 2.4.13 >> OS: opensuse 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.144.97.81) >> >> >> using openldap 2.4.13 (compiled from openldap.org source-package) >> i have noticed the following, reproducable behaviour when converting >> a slapd.conf to slapd.d: >> >> if slapd.conf contains serverids with ldap-urls, e.g. in this format: >> >> ServerID 1 "ldap://ldapmaster.local.site:9000" >> ServerID 2 "ldap://ldapslave.local.site:9000" >> >> the olcserverids in cn=config.ldif always contains some trailing >> (garbage) >> characters after the conversion, and are base64 encoded. when i set >> them >> manually in cn=config with ldapmodify, they are displayed "clean". >> >> the serverid-lines in slapd.conf are "clean" (they contain no >> whitespaces / tabs >> at the end of the line or similar, invisible characters). >> >> i have tested it several times, without using \"\ in the string >> and/or without >> portnumber. i have tested the conversion with both slaptest and slapd, >> in virtual and real machines, >> result was always the same. > > Thanks for the report, this is now fixed in HEAD. Note, URLs don't > need to be surrounded with quotes. By definition, they are already > "safe". okay, understood. thanks for your response. greetings oliver

1 0

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 20 Jan '09

20 Jan '09

> When using the back-ldif backend with test044, it aborts: Probably ITS#5340. -- Hallvard

1 0

(ITS#5898) test044 abort with back-ldif
by quanah＠OpenLDAP.org 20 Jan '09

20 Jan '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When using the back-ldif backend with test044, it aborts: Program terminated with signal 6, Aborted. (gdb) bt #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 #4 0x0000000004fe9748 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 452 tmplen = e->e_name.bv_len; (gdb) l 447 ecur = ebuf; 448 449 /* put the dn */ 450 if ( e->e_dn != NULL ) { 451 /* put "dn: <dn>" */ 452 tmplen = e->e_name.bv_len; 453 MAKE_SPACE( LDIF_SIZE_NEEDED( 2, tmplen )); 454 ldif_sput( &ecur, LDIF_PUT_VALUE, "dn", e->e_dn, tmplen ); 455 } 456

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 20 Jan '09

20 Jan '09

eduard.budulea(a)axigen.com wrote: > Full_Name: Eduard Budulea > Version: 2.4.11 > OS: gnu/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.230.245.6) > > > ldap_search_ext_s does not return all the messages that the server sends. > If the response from the ldap server is compose from 2 messages: > - a LDAP Intermediate Response Message > - a SearchResultDone Message > > the ldap_search_ext_s returns only the intermediate one. > > Step to reporduce: > have a ldap running with some entries. > have a the syncprov overlay deploy. > make a synchronous search with a null cookie and a filter that does not match > all the entries. > now modify an entry that is not in the previous result set. > make another synchronous search with the cookie from the previous search. > you will be able to see only the intermediate and not the done (that holds the > cookie). > > If you do the same but using ldap_search_ext and ldap_result you will get the > result done message also. This behavior is by design, and has been in place since 2000. Whether the design is correct or not may be an open question; since Kurt wrote that code I'd ask him to comment further. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs