source/0000775000175000017500000000000013225117471011043 5ustar rgerrgersource/faq/0000775000175000017500000000000013223143030011576 5ustar rgerrgersource/faq/difference_queues.rst0000664000175000017500000000314713223143030016016 0ustar rgerrgerWhat is the difference between the main_queue and a queue with a ruleset tied to an input? ========================================================================================== A queue on a ruleset tied to an input replaces the main queue for that input. The only difference is the higher default size of the main queue. If an input bounded ruleset does not have a queue defined, what default does it have? ------------------------------------------------------------------------------------- Rulesets without a queue on them use the main queue as a default. What is the recommended way to use several inputs? Should there be a need to define a queue for the rulesets? ------------------------------------------------------------------------------------------------------------- If you are going to do the same thing with all logs, then they should share a ruleset. If you are doing different things with different logs, then they should have different rulesets. For example take a system where the default ruleset processes things and sends them over the network to the nearest relay system. All systems have this same default ruleset. Then in the relay systems there is a ruleset which is tied to both TCP and UDP listeners, and it receives the messages from the network, cleans them up, and sends them on. There is no mixing of these two processing paths, so having them as completly separate paths with rulesets tied to the inputs and queues on the rulesets makes sense. A queue on a ruleset tied to one or more inputs can be thought of as a seperate instance of rsyslog, which processes those logs. Credits: davidelang source/faq/index.rst0000664000175000017500000000007413223143030013440 0ustar rgerrgerFAQ === .. toctree:: :maxdepth: 1 difference_queues source/_ext/0000775000175000017500000000000013223143030011766 5ustar rgerrgersource/_ext/edit_on_github.pyc0000664000175000017500000000331713223143030015472 0ustar rgerrger &Wc@sCdZddlZddlZdZdZdZdZdS(s Sphinx extension to add ReadTheDocs-style "Edit on GitHub" links to the sidebar. Loosely based on https://github.com/astropy/astropy/pull/347 iNsBSD (3 clause)c Cs.djd|jjd|d|jjd|S(Ns:https://github.com/{project}/{view}/{branch}/source/{path}tprojecttviewtbranchtpath(tformattconfigtedit_on_github_projecttedit_on_github_branch(tappRR((s9/home/rger/proj/rsyslog-doc/source/_ext/edit_on_github.pytget_github_urls    cCs|dkrdS|jjs-tjddStjj|jd|jj }t |d|}t |d|}||d<||ds     source/_ext/edit_on_github.py0000664000175000017500000000223112704114446015335 0ustar rgerrger""" Sphinx extension to add ReadTheDocs-style "Edit on GitHub" links to the sidebar. Loosely based on https://github.com/astropy/astropy/pull/347 """ import os import warnings __licence__ = 'BSD (3 clause)' def get_github_url(app, view, path): return 'https://github.com/{project}/{view}/{branch}/source/{path}'.format( project=app.config.edit_on_github_project, view=view, branch=app.config.edit_on_github_branch, path=path) def html_page_context(app, pagename, templatename, context, doctree): if templatename != 'page.html': return if not app.config.edit_on_github_project: warnings.warn("edit_on_github_project not specified") return path = os.path.relpath(doctree.get('source'), app.builder.srcdir) show_url = get_github_url(app, 'blob', path) edit_url = get_github_url(app, 'edit', path) context['show_on_github_url'] = show_url context['edit_on_github_url'] = edit_url def setup(app): app.add_config_value('edit_on_github_project', '', True) app.add_config_value('edit_on_github_branch', 'master', True) app.connect('html-page-context', html_page_context) source/direct_queue_rsyslog.png0000664000175000017500000002434112704114446016015 0ustar rgerrgerPNG  IHDRsBITO pHYse IDATxytڇl E¾H"•^P<^EE# ") *"v D uaI2Cfg99_[ݿj7!@ +(`wCdBJ+k"ٍ5:z(ݾ}{T(fw~nfrk֬yǖ裏tlW(Wɾ+w:WW|Տ~EPw(\ mLNB!3F P8?,X7i'86HP2`o28ǵ%L#JPǠp Sz[nEݘFqyWV\3BOzVLkT=ovsw@sM+䌠w& 7[_-oH RƠ<#& HM%#ȠlY>MG9J!KH&y{J٦b;Pz `:N^{sKI"~o)N;ְ!'Nܾ8wywӖ9UT+ңAQ!+"#ٳÇFZ4lHp0 L:T@r_|3y>{xWf1ۡP(J2'NgZw 8ΝUq=[\rNCuABp \!ظU[`Fd@^Tqr69vP(22(4!Che&0y@R(w2_4XʗgxƏB5) YPbdg3u*fK/1q"+IPȅz8x!CkW/n]) Q Ѫ̟Ν EQ81ix/_gϞm۶eff6n8<<x |۷ػwon"##SSS{b `ܸq&M-[EFF>)))aaa=0}ŋׯ:u*pӧ'&&̚5~ӂ|w]>sɓk֬zjjjcbbY JX͚q,cP@nn"///999338w灘(mIDDQ814o޼E@57nSN___!`Xrss˗/ׯ_͍JLL"##W_5pe˖%%%-ZH;/]tݺu͛{=?޽TSOٳ+W\v X,%^a 2eʹs璓_~m۶&LN+̙ӯ_?`ӦM:t8vXlllfʹ͛:4h9sxyy9rСCUVVkܸ+;֮]zA(|bX222׮]B$$$!bbbnܸ}K. !O:%8y} ;wLKKKMMݺu3g#1'Go/@ .rsSa(ǎf̘!Zj޽B̟?8tPtttڵWX! 4ibԩ{5R:?ùsiӦ !֭۳gO!ĨQk׮ >xٳg[jj*!ēO>9e!|/ !v1rĉ'/B3f|B͛7k?6LӦX,=J*z0< y‰qc5x-:ƱbiC21Z<|Ö-cNr2X/42 #̲`I&`_U$ 0;ũ? 4~/֯_~[~VV… Yz+VXB[X~{Y8WnS7o*$^gY߶)6$''fbccm*b6Ӳq'ؤ_ѴiSXlMiEnB2߿ߚ"hZ\5j6?qMT֭Mm7N:Dw/WBmSѦwyǦ6ſrM񁘘cwwj6|'ERJfx~ִ.1~zzzzzCʶb\p QF ]rŚصsl-(~2~vvvyJ(77{.\ɱa*UY~zz-t3g1TQ׮]ǧ{;ї˻C^K^M'U9996AAA<*XTCcEUZRJOOOiiN/p=r=>{=>}://"_?99ҥKŬpKEյ%Z5:O{@1~DAH ҥ fEq|wOTe*og{-Dž8y{c6Gk\K&OJDGs*3[ڟըA-Dž1/{h9@QI䗡f6r" S 3?<^t&^@-lQCQG^cx'yA4ZhÐyh"I ?Pw~m#/!ؾ{{h9fBRcH'=DםzBB֡3d5dr=•N%u;ە+؊'QD}gFk4GlГILǾiLLgxSXfǚdlly ˬHg џ5GCg1tv '~՝oZ\l';_yގa}}IHn]}4;G%fQQe%3b˗s<hGC:Q H"18ryPFRKV+꫌K-A 1Nx':)W+|\Ag0זԬɨQ׮ԭN{0Z'+0U,(Sdžedn8?SDdg!++F q9~zS a~w5mhoZhn@]Gҙ\=nt3Z`1N덷JL6\W+t&(_|uf7-Xh!΃ư01x+7(21Zk?ᦌ<*QV.VQ=•81QDTF q 1gWV2̇2" hA ,G9.#A 'y@ fEWLD y%99xz:rqٳgPtرOdK z*n' ʊ4h%p|߲«E^жv̙enٲ߿>ȃ}[--ZɩRJ1弼uG}Vc8tMr`d wWc7qر[!xeff_ hժ#+zJ*/nٲ~[↧⋯>B/۶m+}B) E}ݧ,ڵk'N(&------99cxi[".s3^^^eM~1cn]AA2z4[c 20`~ς\~ؾ}{.:'.$d$|r3w_NNg`WZJ%x'OΝ;?Ks.G<3<}N>}ɢuK!nΞ=[l5pIKSO=bŊGsO<VcV_g8VeKZ>F M;P|*UVTxyyݲ*W 6THvkIZׯߨQJ:i˔)d\fKDDݻb *lEQo Yd]r7oޭ[o^ŠWe8E*=K9|(o#orkܞt?Y$իbR 9+}c~/aC܎Ã>2e1hK,7o]*cCslR GC,g_p01:0h-kӷo1o\rvǠ1HByi)c;ygA:H@Q>!=Za10$!PÌ-mSHqnP&o;AAtﮛ6 <eA\4))`w 3\ÞTR$(Lo ر4j`0z>5A=GT,)rѤ\*aưO E … pcPanϑ/@&EfR4cPaUC&ucta|| +5A=Ge)2ݹ f О߬sc'!rk z ̈́EB .%}וICj?;y *2I:jZAaG 34}WkQAy8\T#k&E3c;]JjI˖t»=˅8ʯ;F$Tc'~ӒHETco`p~':D2aW~10$x'y2O<'u^oJ"s[IB!w *5=,s\OI^R==yߍl %;o$#g0#C"Y;)zǠ¸2b7W'xZ6QU) Ku6x`+rtPjә>qe.Ob?;Qg]zǠ¸\ #9CZ)Na.v d`gXd]Z؝;^J:ԾeͰ0dG%ftS\ /*ٳg?3; |1B11׹:צSUK.DPJBuQA l#owܳJ'5^kF37hǀ0AYW F 77>=ϭyLe E,ij x1!ƪrbP HƴL2#ư8=CMj[u<1B1w5^+1hFSXU+D{×Vaqz c,cJ QPh׎SQmg}T91x/`-o(~ & 3O<Yy.uwS(DC/Kم,ԎSuߩwGUM/z_ņǰ(l0cu$(yLe 7o~/z?0ۭlUe^7<10K Iؗ7 :aqz 61BLn1GFLrkVzcXe a H\(*G0|k`'FtB!R&W7̑c<_vn1H)"eruCɩJ2h Ά20BLnș#9U)̈20BLnY;z*L20BLnإϟ`;)3?~|VaL` wJGC QPX|+rfime׮]R;}&''[,jժ+ d۶,;}7%%q{^ꆜ5 V\J/

Hs'Nh T!DDDD6mW rtHo߾k֬qȋn|GVZ5m4[lٹs]viKڅڵkw^q.T-#hݿn+WrC 6mɓ5j ҥ… G,Y""##ׯwԖΆ F9uT ##SNݻv X,~n!((n߾}^maQ=ggg{{{+VLMMuԖ8:F1rȺuܶm[bb"pҥիW8q- wd &&cǎ@HHș3grssn:v&t~+o=֬YӡC.]hh!Ę1cz:tGѺ:Eu>N:o߾u۷oaRqF INvFI pDOPݻnZohh!C/^_zCXXXLLL.]>?&MZϣ^zΝ+\ʗ_~tR37|꼙2AP(7P( M(cP( M(cP( M(cP( M(cP( M(cP( M?^yV4IENDB`source/gssapi.png0000664000175000017500000010546612704114446013053 0ustar rgerrgerPNG  IHDRi[0#sBITO IDATxy\w?O!SVQQTZO<(RW\vbGj=^ŵjh뱞-Q;b`~|vg$$!^χ$g>a1 C@o6 w0ȝFJNNxmyy;ux<>/H?r՟?koo߶mۨTs  CCC_@޾}{ɒ%ǏӧOQQQFFF߾}8y̙Ν;^l;9[$''#F;yH$Rm\YYٻwCBΟ?rD"1˾A0l7))&NNBpܹ'N ]xqѢE `-;e„ !!!Gݲk׮R*##ҽ{f LQ&Lp6b w6͛׿N8ѣ[oG5K`z}SN1cg={?oٲeȑxV!w5kg͚USS3w\P*BSRR>kرwY*?~<--ԩSfri,[a޼y9={xO0-Nh>;@SAVLZOh<̍`T20 Y1; y FD;ejp@ FNhi233۴icZNNN&߸`0 Nn'N7ocX~~@ HIIݻwl^dͳ-Lȝ`޽ۧOBHjj*gܱcGϞ= w١CP8`,Ӓq999&''Ӆ===;vxƍM6yzz޼yc777[nqㆎhKJJ"##bEJ%!lƌ...b&p Ҷm$Ixxw}'HΝ;ot]͗_~gϞK.m?55U..^6DRڵk`WT(s̉,//ϟ;we4#Q(2`ٜ Xvvvۍ76l@dggd B8C6q_J1wTvVm0+rܹ۷ȑ#tyfffPPP\\ӧϟ?⢺VjjQ *++bgϼ !III"ѣGAAA=4hL&m9;;믡%%%cknnѢE)))b8;;GsPUiQ @|GOQQQ@@@]]]MMM׮]$IRRkFQ*[lپ};86nH[)Jy<d; HDwtttttkkk5΄B-f҅jS3T4ȝLS.YgϞ/^`ڞ={vرڵ 111.]8pݻwL`&//&ݽӧO۶mKce'g`ipr5%b뒚ڧO2I=z4**Ν; UPl޼6 aaa˗/J֭khƎnnSL /.++S*n , r'X+;߿ 44taaaEEEqqq!!!]vի`%%%6mrww\wJ//]/..ooocOOOPY!n Q))z}ҭY!vN00w&6hp0wA4{S$1EZU 4B4ZJ3aCȝ 233_y啊 omѿq!aA^xV@lq^pAU MR4 ?b&q'X7B'RRH+tj UOڵkӦMofmmӳg4ץ{n___H4|R__3fwR[E}vYmG : jN%gNV*ɓ'^^^ L&=vXUUUzzϟ?/******8R(׮]KOOʺ{Nffffee%$$;ݻ# ;1>ۿ>ZK.gdd5kׯDAJJJ۶mtٳgBaFF!axJՕ!a4`8HhG6TՍrb/۴i /ӅTk*j7˚;kڲAv!??"ԊSmtOtq;`Fȝ6úV\pVܷo_ii?0 Q)I4iNB'}VS%g1bDrrrIIɤIf͚E'7MTA>{Lj8wJw ڎ@3C4L``__ڨV$H:j3gۋba\\\\kxjLvZ#qu@3C41%Vc+t>x@[˦(٘ tj_M]]===vߺΟ?? @"p>gK0`@@@@Nt?N_.k!4'YS-4\נ<kc~\ 4vQ^,pN"3 FtLn‰;Kj3q!c`#V'/// @uӵk@KsA"XoooYj.]-@ci;^kE^(w2ị1в侮s);h,˯e@cBm4[ZZZppi~Nz7ݽ"##>|(339999::ݻjY!ݺuٳj'u=Z777''' \*\\\&L#<ĉ!!!bxȐ!gΜ145NgDNm~1cƨ.a+g,/߿>իW_xmVb3fLLLrwtyJJʟ{l<<<8[^|y„ ,()) 4hP[xGYp rL&[bŕ+W:B kչ75f]ID"4w$TUUĸDGGә5qj6S-n: Zz뭽{rYTsgKJILLܹss֬Ycccӳg}R666'N|qN0!,,[x3f߿gΜrٲeׯuppXhQxxurʝ;w6ھ7nl0x#5} z4}5t4k/mVZT*WZ5h <<<|ԩEEEk׮eߺua\VK*.ZHPTWW3 3k֬Ȳ8a"##'MTZZŋ7or6S!Hjkki02LZjP[Yʕ+Jڵk۷ofzt^z_a3gtܹm۶֭sssfΜɨ{G}4l0sV7S*m۶MNN?SWW1]v)ʜ Beee<%˗t-啝]VV񢢢lRYYɆ-ryyyI8b jvBƎ{_oझ9s߿auuu%%%ǙΏoZXXضm[BHNNNff+;?,I_(rŋ+W >C;;\\.KKK4KWr6S*22O>uVXXkQ2umڴDGU*cǎ6vvv޼yMuXQQqɣGzyyyyy䓕+WSw;v};Eծ]lmm#UK.EEEZ“X&6h͚5駟Fも+Vm۶A}LL͛ !TRRgϞݮ];:l׮ݜ9sӶ*rrrT ֭% :[lqqq駟^#!C=z/H$nnn۶m;t>~#NNJ~_T3W p႟_mcǎ>}Ç?iӦ;ܡ57q\旞ު'!k׮7n(((={^M<7B)ʣG6Xʣȑ#'N8|0^NwyСCuuu)))ƍSkP^^~HՅQQQ.\^qqǏ,T˹fkX-e$YUvvv> =z>x`vv6-LbŊSΚ5aO8񫯾WVV8qٳgtՕ+WFDD?+--~RRҋ/MsΉ'Zߟ;H+YVUU9;;Pٷ2_pATWVVOXΝΝ;w({{{[]OObUUU|&kص@U wZhΩAu:t;$$l9LD"HNh$\/JAM؂l˼+oseq'ĉkBsos@%NK¸Xb,aI@=+d9Wk8YָӢRf j,+wR5D5;-j-ƝRr^@e=+diNM1̫NZK!iN2N`iWk)$-Pcg,j-'_A'5[`i-N$-Pcq: Ɲ<b!i3NkZKa jv*I 44wTk ܁!sJt4B7w,96lq `zY̙3[ __UVB7lK/_턳=QfgZv?k׮{R裏ݫgϞ nӦMHHHFFƭ[^}6m7==)pxc4 ]pt?̙3ϟ??|/_0̒%K\\\9ٳ7o~7mry6m;Fwiݺu{Ќ [[0swwwmoow^`_￿k{4h6446''ch=ٚTnҭXQ{M6/_f|b?۷o3*aq6W^xٺ{P%9)))MHH`,YK.{z9Ä/o|~mmtà 1 /~ך#Gjjj_ŋ!C}iiD"Qm9cƌ &d277A-6Ç9yR erttK uuunnn35$PNև}} }D[{HrĈG>zw={0 ݷlllt; IDAT0o0}bN>&ѣG@6sww;wO{MSL9p@v EDD=uLnlmm\ҩS']ta-鳩r'ʉDe˖-Z~СJ255ѣGW_M(0~1cϘ1c͟|㝝ܢ7nܘ5kֵk9qqq^t[^Ν;m۶m۶51O;ʚ5k|||6o{u}Μ9suu]tinn_5;((}>[TSYYT*ueD{uq˖-&<8$s#` y14$OL:-`Sssϝ 'ƝZqONxI[:L;1+ਯ yhjmڴ1c7ntqqqww7c MdN|'N7oA+6҂[NEEʕ+SRRK0NXnnn %%wަ3fi{s?Y">6OrK@kq>}BRSSUsgYYW,ۄ;wvЁN󛕕Ey7kkk={9bbbjjnN:Hݾ}3!vsttڴiӧ~;k1"!!Ajl%%%b}ѢE4%KѣG;99;99g]рnwƍ=z]2eJ#~c̄%CMqt!ںuX,bF,w֍422rҤI/^y&0.\(..V(3gΤ322MKR___z֬YeeeaaaqqqjjnN h"BQ]]]\\oݺ0\.OKK{X,f@(rf :ujeeeQQQppڵk >}zUUT*  j;fW4UV)UV 4eTO0Nh!t!ٳg~~ &O.999kmۖi(|7 TUUoҥ6A)))۴i ƃ :z(0[l lnn177.?{l```EE r'g]рIKKsqqipY)l1 X"D"=zԵkѣG>}Z"ܼy"Jy<* "hȐ! n`[TTŋ_~Y"H$ÇߛŅvrr:yCCBB_Ny>L9|iӴ5Sݢ7}۱cBTjccӮ];W-89Zx 6'~u01%{k׮?a=z5X'-]__BdR m۶7;; rT{6b/h"(%%E"p6c)//wӅz;9R 8##qg })++` ˆŋ)[n):WWWByfEPaWёd:˻t꺚SAM~~3gjjjb1 NGӧOښQNNNcǎ]|yuuT*]z)SB1c/_^SS#6lؠ]89j/zf^!Ƃ[ `9S5w*55>~PPڏϟƍ7Ņxxx?~:Ǯݒ]v-]߿{Æ S]Wms!!!:RWW~ɓ'uo~Jw3j޽111^^^SL#ٳwqwwYpajjjVVVpp0L89nįZ55nv~R,0w^pA56C˸qrrrllLJRR|wՂ`w"q7۷o>}zclllu떛zI&U+$uT@73^//A&;w1̞=M6QQQ~"l ϝxJUUU5gff6֩N\0Z3[AM܉¸0ȝ1&w-fw܉u@+glœ|f alL X)c-X,wwwת  lܹ3[ϙ}PN|` `(N;q¸0ȝ*dff:99Ycmڴ1V1 FM4ݻwXCv9rdff~ܹCz{{VTTyfffPPPMMMʀyp0P󨮮^h޽{Ν{k>޽;!~1k^z%Lf(1 \N*־꫄:Cx3f߿gΜɮURR)-ZT*ƍsrr LNNֶQw١CP8`,:|۷{zzvƍ6my&G]dzwi&%-޽W$͟?_TP84˲ȝµkN"|W ׫w9tP]]]nnnJJʸqEGGo7nذa]#Rk8mŋP( ̙Y^^?we˖ussJ׿9BdcǎUUU>\s ŵkӳ޽s١qбkօX|;爽HK/嚭Z -飭ٳg.\{^{I9dȐK޿?//o…JEEEeeX,~왷7!$))iѢE򈈈{Զ: 55uԨQ#""Tﹲ{"ѣGAAA=4hL&D999ڵ#\pa„ ;vń%sssilΝ[xS4rvko^S=0oȑgΜqtt4iꀏ2s߿_T*x/>!cǎ97mH4dȐJmu@ D{{{GGGGGGveccC'!חprr:yCCBB_D[xll:t Cvͺ w@k̙.HJJ}PB{}}}^^}ӶmB<<<agggsnsu\o߾ҟ٧><<gϞBwwDDDB֯_{oVs ЩS $-!al̮Y¸$P3*33>ԼASRR|{TO0FjE.]ZC|MnrssW^=i$sG2ʝt4)+&WRR2{삂6mDEE}推e¸]wNh1td) LVPP0{lv9=KWBΟ??~k񉊊:~xNN X\ɓTvZmfffVVVBBBTTɓ' !D&]z5<<\M(ʣG+-qSk5o޼*ݽB>ãfp#0Lī`cJ:̙3__7n0 !O322!eee ä sssi_~YsEPal>ϾDnnnmVVVtttN!{NKK3haUU]^^]tіݻS5j+ҷb5;;[.k;nJKKWZJeذacŋuuujB`l0P9r^hNͫٙ@kDҕ谩V.ɡҟvi݄%KnaQQы/^~e0 ɓ''&&;611&sE@ 'Mt+VSDlv> &رC[W "6666Vp3 B0 :pW*گT*e{V]ǏݿMvvvr\.ivyO޺u+,,L)gg͛7oڴs ]0={5˫:jr'pwYɉMܶmmP( u?䓕+Wz3K.o"+&&f<OsP(ΝܱcG:w^YYI˝҅|>?hMPKwrD09l߉ҕF5[hZINhȝQϝjON(] :p%X V s# FRȝfd`YXYlz~- Lyy{{ ¡C.,omm'͛gڞ9E:uw\.޽ٳ<:V|wss))){g^zI&5Y]cظsҥvvv111 4k.???GGG//M6eW5K7)00099S­wӧ!$55UwܱcGϞ= ?~Ftehֹ5hulsk.l9gh9y5Qe2YllcǪӇN],#Rk8vOm۶I$N";w7޽;g_~={.]DKttUsk^栭>>>~6mڴIHHtjS+**|>[rٳD_ٳg~~ &O-f͚~}VtUmYUϽֶ Pr2mƔZEQ= Juu.]khF |AAA6mVvUtT*xlَ;n-** ڵkuuD"IJJR XTnٲeE_Y 6~q=Ղ5be `B]ef}_`#F$''L4i֬Y]`-9M_Ӄ\./ry``'Orf={… /_lA :g.4zA=@3Sc~aeeW_}`w6l@  ðeW?sXs aaa˗/Xn\RSSGUSSSVV-GFEE>}[V.{=l0n9w\+'wSVVVpppqqkՅ2lgbɉV%ʢEJխ_i~-1ݻKJJ<<<HkSzڧOޣ=x@#@iֹ5^kqCΝ;9}P}MG%hmI|fDOXTnh`>[q'٘p4'NKõYwEh:ƍUBm̠tbN?6f̘+WOjՎލgiB} akfBW\޽X, իWusNqq Hӑ0 <?N8, rgΜyС"0Fߪl̺,^kmш҄zt ٵk .x{{+ʭ[N::ٳgʔ)CEE!$33W^#G,[l O/^5j`ĈZ`AS ՁH:s1y& lcǎ]v]p3H9umm50`I)'n.]tOJJ2d}-JGMRdzDʔ:Jc6hʕ;w6lϷ}76nܨ{Ф$В4UlW҄ TOh {ɓ'{.++ӧŋuϟ?oܤRieeeDD,66ɓ'666ӦM[v烂TGz*..~믿nZiiin $Œf;W^yܹs<طoߑ#GT]ӗ.]By"ЇaSNr\&͜93..nZ|BHeeӧsrrVX1aBHuui)+VL:u֬YIUUgo߾NΥm`iB 43۪Uh#ꪫ !RƦ]vG[R"H$Ç7&z)mNNNJJJb`iB͊cJe}}=!D*վ9ѵD"i߾}zz:!ã}ˆ2ѧC?nZ{="XZ^I[iB";wJAB-kP(mƮZrٳgYrɓ'޽*W\y뭷XKV$T3W_!!!l{m51 gឝ;wnܸX(N8/ :޹sg7o$;W^Yp!rB\t?joo .Xoxiii:^ !ҥKmmm{dIt]tw (AFoO~AATO0rƌtR>jM7'O4=̝&;9CK4ȝФxV/233y*7ʘ Ä޾} fff9s;w4w8V&333((Ƞ_@2{Ġ J҈Mcƌ1bEz ӘZ cƝ &$Tω(ryΙq7 aCcǎ={;tXBj~I$*t\}v__3fhnW^ ,eee3fpqqofj׿ݻ}}}E"GR3O?wa[1"!!AΝ;;t   Ŷod`)J7ng5r׮]~~~^^^6m"\'=۶nw nIIɸqhdOm=hEn9s><٩yy뭷cO9-K3~8BY%%%b}ѢEVBUDW ^u3h O< EfffVVuV\\Cj'OHRZQu蚚lL`4W-6Bqڵw~.x{{{yy͛7J#i~z _ĉ5jj*lYv=N>}׮]@Gb>-aryZZ0f͊,++ xVR*V4h]=""bڴiUUUEEE  t-ZP(ٺuX,bF,w͈Q?--M"e2ڡ4iRii/n޼[Z=}T,]+(( r\jSN,** ^v-0aaaӧOJ!v@4.\(..V(3g7nf X?>VA3s͚5+))Q]thygddBWݨ7|0LUU]^^]~.][QQsrri!mRR/0Lii鯿Z__7lذy5x$9efРAGef˖-w?%%m۶:'aŋuuu ,//oӦMBB\.K2a\\\;{,=uT}}}Ϟ=/\0ydc4ι޽{:uaQF1{Bhںeuj6c|xҥ<==UcP=zJ8 l7Zri<4HlVU.V;vlvBCC 666&ЩQxʕ+'*B!krssUԨjJe^^C33Ӓw3ZBHddѣG)cbb.]4pwӞ70~gQFyyy߿ˋV4bĈ䒒I&͚5Z'ˣo }zhm#Ë<}ӧOoݺVhQ<77]^k nҥKg!g3v }Ӷmj+c'}JKKgk R`RSu:zzj>}BaDDŋʔJ[z_5</..Z&;?i*--]f=sFKH$Ç>}zxx80BsuuU(7o2 wv)''޽{;}@ wK/8??̙3555bamXP( [|yuuT*]n\tmLx;v֭ۜ9s|MH9#\g!g3iر[z)SPձ]=OtU(lN:h^^Ԟݵk-9tGEoooc4WG ԩSPPвe! bܹ;vtvvtTY3Z~ԩS9g\\\HHH׮]{;0K^Oj6xw a***xxx899lݺUmѣG €;wuׯ߳gn޼9zh FOj%˧M&%Ɍ3uy$u0 !ښ#JE"=Y 0o=۷o RvcccE"X,ffŊBcǎt+aW<=Ù;u?ڣ?5ow̌=ܝ;wڵkWWWg@LFk`*˸qrrr )zpTkiT=ƈ~'4YfyzzFk|;To>}$N, -L& ߹sg}7꛶LjO@ 1bġCL3kЪ$%% 2q%Q9۬=zd*:jrnj֭]jjE1uwy4,Kۇ&%% h隺~'N=ˢBr[2,66رcUUUÇW]]K:wV=r!$::.??~qilU!**NM{zjxxjh9d(r< ť6k׮MLLtiԩ[eZrgZZZnnݻw>@GR>@>nt@`ggRXܣGv]}N~/pttXf D0lggv PssܼyP(\bѣGzԩ2dj MD"mHH>пggg:<BJ-[}0 wD ׮]O?ɓ:⺺j6!!! @$ 2`CCBB_N[ysV$Ijn)Hhlz; !'O֌ZZ hyyX,g:p˗/%; !& -;EeI$J?rV<9qV vQSGQ+Jhp:ʀܩgYTȑ#_|ҏ:*P.JqVLS4Z"g1[ͣ`Q\֕+W6f -wѻ=zBD2eʔ?^a۷oך9 Fփ<{lv~WCjU*9kyRFe(ihNbhpVh}Ŝ̂~,g0 ִ;njtRNƍZNKQ=P9S >ABk' h0hVs!X1Nf4ml333jjj+7S:C/0wĵk>{L,o۶mZWӄ}D"DӦMj^xQu"T7}=z5j,YΠ J3miiN81~x7q/2F~gttT*`VVV>yfڴiePPPEEZ׃KKKܒϚ5-YWWx{{{Z%%%l dgg;::hj*fff!/O_WTTѷϟΪ*;;;v۷tmN޽EQe." Zj$fwYv23C܊ ]zߴ3rڙk3wzyyݻWcB*++xaaH]DMM{aa!wAr'F}vڨ(| ___cOĸR̂qL&D7n^vO?ͭh4nnn]vol5J6 Dbbڼy e˖nݺ .XsҤIY} Vʹ(V{8waPQYO6^!R­i'~Jjii)))oݻwj p;E58Q &Zt:V8q"gLJJ֭[븸3gח9Wh/"= [TTwUTTDފ]v .x5j3o>鹒,YgJOO?~XXH$eobgaD/DoVl'N:.##EĜO(5R"K;vs222-[vڵ]3ANdVdЩ w]YTTmܸqoF'-  wB`VAVYY' 0x^{:pVw8ǠSqw0 *:m m `U3uՙ!wXK%-OlYYY/¥Kl5>|w߽|X,6loѷo_V^^^xxT*miiܽ{7ŶlHX>[!**_~-:.$$DxN9{U\>bĈ͛7Xx 6p˗?m{L<#GL8b⡙_Ͱdɒ!C\z__fw}N Hjjjjjj&N8w\~;&?rׯ_~*Jp3g<3 .,..>|СCSތ駟.ZhӦMZbʕgϞ`>1:|Ϡӥ+DST?WTT$&&E566vr*C 4x)_/thx"]`DsqK+W]RJ޽;[k>H$gΜnS1}ZVVV@@w 7-^x޼yg~WLLLW^l22vM6㊉ٹs'_7oy衇9"1 l~ҧK%%%_}U:HIIRյ'NܴiӪU'MĭX^^^XX8hР{ӦMW6lرch .ܲe޽{W\]hSSӁ}Q͟~u:݋/o̙3x7|$33^~4߿tѣGIIIsYt`xnz'MGk`FE?_8]mIf&++ߟh <1 sرFܡ?ɠ`A~iBs +'Yr1RZQpeUUU \~]$t|j !jZgR4;;;(( # ˹&FNw)6Ço7nܸ`\bؠƍ~~~+((`d2 ӭ[7:"gL`wXO"H|}} !zY40$$NгgR"T0((Ց#GOvV<0/MhN!B~Dcs\$F![YD" !>>>>>>N#hZww)SDm۶ֲaK$V{ď>hʕvU裏~iXL4iG}o֬Y|իW/ 2 Ju.]B Z4sYBvET?ܹCW{eccٳgG-! 49,HV4&xyy455}焐&$$p'ݺu-[uXSSsС:t/7ɓ322$¿QQQ6~&𼽽 bP2QXe?NW;g˞􋏏ONN+++Yf #T[%7n[J|!С9 *'9%XZ6 ŋׯ_0ѣG|.]_^RKuuu0rw}Wp0 jZ]\\ܵkO>N\aŋ_nӧ766mݺ5((ݻc ꫯ8 3w9[ {;wnppX,:ujjj**w-;8zh_p V:4x"r鹸 K+WMv!CƎ7֭[qʕΝϛ7d2?k׮l9s>{Ly{{vm #G/WZ5{lX<|1444//O0<77#F8p`bGٿ%b8~ : gkV8EDDy>+ݫjMd??06l3WaC8pam۶%$$NfCQQm?vXDDmwssc#9q> dffv҅|`;#;w!?rJ0۷b1w.)]6m0Fڷo90 SZZP(d2X,V(RTP\pyFFƓO>}9s 4b&==駟f&&&/X 7nlz}}}}}}e2?~Nbg`!wxxxL NrRʜYXiiiWfeeeohhؼys޽q b:~nT r<33ϯAp2ﻹwjwcc?bٳg[ZZ233ys7}A f%J.]ZUUE)..>}4m} 0@0xlT$2c18_5..ͭc)fdd,[ڵkқi';ر#99ڵkt[TTf͚ISEEEhhhDDUee?_RR啔kuH,8gKp q[8g `N<\e:ĉϞ=k(BKq$X v<ٟ[/6cάY_YY!!\gm̝8mkB͟6l0a޽>H;yJ$1c߿C8w⋰C#F$Ԇd!/mߵkWhh\.?>2v&%g**,,… ]-iQ Çgddf8gY ]6~xh{ݛRQQ`=`V{BFn:Bȉ'$ چ^駟rrr\[oLPPPPQQpBVoܸqW^_QQQRRϿdbu,!"""++˜ap޵Elٲ%114wqww,bPӊ[–xᇹ3 0WTWW3 ߠ]0xas ˘07n5>_vrVO*zBL&;tCBBbbbΟ?_VVz $ !!!u=j5]F#ufҳgOZC"Bi.<A&X 9=rg(..zj7 u=''9f̘SNUVV&&&Ξ=[TzxxiZV[UUUVVFx7j&yzz655B4 wbݻwiM颢"ETܹsK.m Ncyf- >F<0 ܸ/bر>>>N9nܸ3gKbح[7:x.-HZ___QQnݺiӦq4V|dbu,ٳcǎ(H{b'øSak~gJJʧ~J,)i֣?^x!<<<&&OO޽{?bCkgdi> 2:Š222 t˞9t r;M8q="yyykhhAzz۷|M[^X8N;+NC9[˴kI5- qؿɝ N|GnΨ}ԩSwӷ~qqq2,""ԩS&ʯI5̈́ h/?*b 'lKN =Y!!!ollM?m;sΕ槟~裏L,W.&m h4ΝO 8WLuT1͡vͭo߾&lsN«aɯvd1bv777vq'NJ(g*isal1lii{u:]||ܹsMLjj.Fqssڵ+m b [a|͛IIIb8))V 3m;Ҙl˂cSRZZZJJJh{NS, :^!zT*\_]aCk;:~Im 8.;lN)#̀A'¸2;10W:Ɲ܉'NNOp&; N`z܉Nzb _0p&V}'8+N|iXo܉G%k>|L>kX5wb {;S͸p)t8kNDuw)f;1e܉ 0pbw!pnطC 81 :r'+pz3 l;mfq'ng=E-8 :s'4p}$8s {/K.^r':pK$8s {, b R+w-IpRew3pe;q0G}5c$8s ?Jpqv;YH`oONK=U`?p=N+.ήs'O' N'@`9@ąO9\.ȝ,)$N0''&w>p9RąO2$NH(Vh`N `?LpI>!qi;YH8U;qt$N0N LsIp_;w7𹓅 m q܉ mRΐ; 'n6pI>rH6Γ; 'X̩r'q̃ lW+$Nh''̝CsI>A't͝,O88%ќ|܉_'t8'ϝӵ!q@gpI>]'tȝ q@qI>] 't*ʝ5 q@gsߨ±Yq?߫qq'ѧS~% 0ǝFΤ7iW+\*WwR}: 頓Ƹn$HO$!qBgLsI qd 0s''1a VI>!ippAȝ==4scp;{& `ӐVpl;CbWp BfCό5a (_ T !k S!w¦O.ulRZYlZ=]aoRa |ȝD2q] t_}ռy,Tݶy[ԬZ*33ֱr!)V5Țv8ju``D"8p`v~ȑ'vlMMM f|A[`Ӑn׎pW7\2h B˗zƌ b鄐;wC*Bz)N'd2ݻwnܹJ?%%E_:HݱcGhh3!iiiaaa>>>[lٸq̙3ٹƌw^d*++LP(JŋiJh4&Ld2`wE޾}J pB~~~*O:c`ӵvύi"۷+ DP( Edd$}wʔ)UUU?30'O,//f͊c&77W"[F gϞ=eʔꚚTy+/^/^0VʺsBgD*jZd܅&$$>>99N >\*`hoFSSo1tV7 N և~ }64UKK#bĈV-++kll|F]UUŝRpq;%?}-:BO'B>iӦĐgϞ=KKK5[׮]ichhAZSS8n'//_~ \; = ;Swڵr=z7.///<<<**_~tNgiBp ;.?т愝y p [_ŋٳ_<{,NOOׯۗ_TN )=C֩ _5k;Wee)S R\xqSS'"""N:elܹGR4666??;>yyyر#((gϞ.\زeKPPPhh?̮ h2oٲE*]]BCCr󛚚nݺߡ `mˠkΜL?}pVVů,XLsss%ɭ[vTXXR_.J =\mmmYYYttuhɓMVWWWVV+JiW ɓz~֬Yqqq>[-77W$Ziݺuݻw_v-}=l0:W|||rrr]]F>|8ŋ hڬ,~`tɵfȐ!6l\wmO+sO8u)A.KsJO?vآErssCCC8㏳)G|W/ZާS[[P(޽BXx͛7'O wǏ/))xk9r$<3555555*KHHP(~ *B\TTD8~%K>̿ b5&vpx2gɮ;MgdVֳmƍ 0`@bb%K.\5k֬>ի| ۨhD"=BzYZZ*.8cݻ7ߤ)=|ڧ$\.'xzz:F'!$44dڼy e˖X~`b GjZp \szzuƚ:3H$3g{M_¸dSNѰ&MZbEzzzMM͚5kNJJlY-gz~֭&4iRtĉ+VHKKݴimWW\5jD"Q( [*RSSwYWWnݺiӦ .aVS: aB&&NTs{`zĉ̟ Lާhry@@z=m///0aT*ݻΝ;B޽{\R* IDAT747~nץcǎر{DEE]p"*]bzzz}}}ΝkVp&9N{9Bў222-[vڵ6BwXW^8]M)**ZfMbb#=N0}€k:"9[`}`'̝`_N8g `}'$uo` `Zm@0o?|סZ\Y;裏4hMMM/ /k\m+Il4&i_qM63fBΝT*SRR䫫g̘P(Onl2vׯ={6cٳGp.~ wt۷oOݽKp2每8pÇIOO?~ n^۳Mw}X,fq㆟9d(Jx'}||ϝ;'0+MglMܹCQI.T*Mf?iӦ1 3jԨ}K0*۳M@@^LSDi~J&l$3ԩS!}~|@kצkGQQVjUUUeee4/̠)S|7wܹxb||s[`Na+Pk4+Pu4***;FZ}цOOOA !tq 5%%%-]YT*N} 0]glll޽x~8cbb1= >^VsdãG2D"|,---6mz衇<<} ì^:<<ѣ;qD=VXAg9y$!pBvvc=Oз.\tႂtzSјa~Z͆tRO?ݻ?~H͛T*낂]vyzzٳ[tto޼8pСÇƖ'\@-p9B繍AgΜa[ۧP(ZZZ?ɓ'[wsstZÃMo ,]Ns:/ b핕bx޽p?~'B;OwwwKaZ:觞zjĈO<}=r? ƍBhKdd$}rơC>w!aTTAlׯ_oll1bA{vvvSS TWWC[G_T*?sBX,>~˗Ϝ9sܹ[> , |ݻwNLI2cV;(r6 2O0iA 4hɒ%9s;#H c>"##=<<~x={߿;|AvX|YvAgΜի;K!wZѣuVQQqx 88W_]xqKKȑ#._f]+?q}B7!D. fϞO?)ʗ_~W^J%%%7nܘ1cJJ pw}w*;-P(Ν;}vF#ˇ!֮]ۭ[[K}3gNmݺsƌ #GܼyY[wX[[Dy/_^TT/imK/s۶m)))E\x ; pD/ NZ0 r'e;, `N wX2ȝl.N|LɃoIENDB`source/free_support.rst0000664000175000017500000000551213223143030014301 0ustar rgerrgerFree Services for Rsyslog ========================= *A personal word from Rainer, the lead developer of rsyslog:* **The rsyslog community provides ample free support resources. Please see our** `troubleshooting guide `_ **to get started.** Every now and then I receive private mail with support questions. I appreciate any feedback, but I must limit my resources so that I can help drive a great logging system forward. To do so, I have decided not to reply to unsolicited support emails, at least not with a solution (but rather a link to this page ;)). I hope this does not offend you. The reason is quite simple: If I do personal support, you gain some advantage without contributing something back. Think about it: if you ask your question on the public forum or mailing list, others with the same problem can help you and, most importantly, even years later find your post (and the answer) and get the problem solved. So by solving your issue in public, you help create a great community resource and also help your fellow users find solutions quicker. In the long term, this also contributes to improved code because the more questions users can find solutions to themselves, the fewer I need to look at. But it becomes even better: the rsyslog community is much broader than Rainer ;) - there are other helpful members hanging around the public places. They often answer questions, so that I do not need to look at them (btw, once again a big "thank you", folks!). And, more important, those folks have a different background than me. So they often either know better how to solve your problem (e.g. because it is distro-specific) or they know how to better phrase it (after all, I like abstract terms and concepts ;)). So you do yourself a favor if you use the public places. An excellent place to go to is the `rsyslog forum `_ inside the knowledge base (which in itself is a great place to visit!). For those used to mailing lists, the `rsyslog mailing list `_ also offers excellent advise. **Don't like to post your question in a public place?** Well, then you should consider purchasing `rsyslog professional support `_. The fees are very low and help fund the project. If you use rsyslog seriously inside a corporate environment, there is no excuse for not getting one of the support packages ;) Of course, things are different when I ask you to mail me privately. I'll usually do that when I think it makes sense, for example when we exchange debug logs. I hope you now understand the free support options and the reasoning for them. I hope I haven't offended you with my words - this is not my intention. I just needed to make clear why there are some limits on my responsiveness. Happy logging! source/dataflow.png0000664000175000017500000006003112704114446013352 0ustar rgerrgerPNG  IHDR1sBITO pHYs IDATxy~B&mll444TUUǎ+)))..>dȐ:Nrss߽{~lذaՒ~ 'AK,y!@\\fx/_ vqKKKNE  /;wnժU555"""}nݻhYjUttvB|&3t:}III $&&6"͛7P(ӧOYAӧo߾ۻwʕ+m`ٲe‘^^^. cǎ!yiN ٳ/]$$$ĉ 񇘘M6!o>AAAv`3fdZnkkc0XQƒ "xuZTT4j(?jVOO=v}O_GiFGG ;vёk]fee͚5+;;֭[222X5.,,L$j s--- MxXjUbb3g,XLMM_|9}۷o3ݻIS ++[QQw݌ A\{{CbbKPrrrz捑۷oq & ZZZ9sFRR͛fff83|;w}` .xQii۷x$%%w%((XUUu)Á8 &iw ; Cssvl L ĻF-((cǎuu|ٳg֢`&]iii_bEGGcxܹsmmm}01@Ovڐ!C?nggO>>nJNNŪΝ;wnٲ]KKԩS'NĪ'!!(آ Ξ=֭[jjj)))o϶D"7""wa9ydǯY.lǛdr_41L ̙Kׯ[XXmdÇvJNNnii;q̙31,**}fb|= )**gK222W^ݲepVV֜9s(JHHȳgج]YYy!SSq%$$X<iii666ͻr pRccÇSB}}}}}}" ᡦ'@ >|={JJJ""""""444TUUǎ+))I& Ltz]]]^^^QQѧO"$$7a?S.\޾n:[[uٳG[[ s{⼼bbb>}֛ 6l8|&od2yӦM֭LOOOOOӣG=z7Y[[[YY 6;VUUUnnҥK^///8˗/ӦM+qС`L 4 Μ9s̙qqqUUUEEE555d2L&KHHQ(eeeޟvm۶999.^(//ٳS2 47t:5jTNNzƀK k`bfĈ4FΜ9>655]vmllDRTT.**rqqQVV޳gNǶ#II{]t)$$---544{UVV dV-뫧g``~AXv-:goo1cc~-//P(+VJNرCIIi֭m0&&H$>~DZ=AakkW ... CTTt˖-,kjjm6vXOO>`WAA#}}}_VIzQLL&O>r޼y ,Xhݲe\"%%ƺ0%%&{LMMefgϢT*@CCk@BqvvP(Z= #bo{ՙ͘1&MUT۶m̝;FꢥF5l02,((o"hoo xqb=z4F>}znn. ***'2P(1114׷oLJHȸ:~TjקQ]]TVVǏ&&&D@oUTTD| Vnnnr劭mII@PPPHIIa0.[,...55]@ $&&R(B122z葻;;GkkkNHfA Jpvv޲em?>]c`>ecTn:::twccc5gʕl(&&V__/!!hll쾰O[2색Ro۶MDDD߿oiiɲ?@X`mTTTÉ*I'O9r Ǝ",,ܫ,Y}v@TTH$%ӫtzyy9`С}01@å*Q/EEElh&XRU8:&& &;88zTg֯_秧G$:::?nTPPгg}O &cbĈUV )~lnnZ@,ck $$$ 2XA L a`˖-y `gW2"A(+UX3x|+W677#pTiii;v0.\ǩ|߾}C/@?+"ssW |kFEEihh|ݽ4==-8vYOC +xL į8qqq6l;({3%%%EGG777;::ZXXt}T>)))Ԍ Y/M*¨qŮc/h;XQ({N0ahhԤeaa|TL=T`b ~܌V[WLc{uVow|{zztDrssZ[[WZXx1̙397o;8Y^z(Jz׮]Η/_S_K%Nt{]^ϟ?x(~y%A ĩ_WWyqt{,c/ kp` L į8sss===kkkXkv{х6yѣL 4hiieggSxG m: AOxbbbxGA4x L:#//OSS( 0m4|z ( ;H;wA AL Ay  01@*//ݸqZ[[^UkX5a&E3f̸{իWa޼y=>|%KӔ@*0;|D"H$8Pmmmϟ'/^9s&^"''G^^'N+;gQBBBgΜYbNt.aTTT7.33f&]$ȑ#ׯoiiYhӧǏ Tjffرc  wvGGÇsׯ_{nڴiݓZ`b ^ٙ~PQQ:t@ yClذ5k͛7e&!s#zG={u1xꕎNll]n޼),,y/x‹/,--i4Ǐn'Ǐg>stt鮮/$AMˉ'>~LJH_C>|`oo?eʔ^VPPEBBĉO<===sssLҟ!k׮UUU=}4qCwK.}⅞ޗ/_֬Y^.**Uqqqcƌ166̔xÇ{aĀ |466>/&)(( 2dŋ)$LEN}… 9tP?*o`I ׯ_KJJ^~}/%$$xxxƍϟ*Do\@@`̙666...0?W''''''G  3%(-ZhѢ7n}N755CKJJRԹs|u׋ >f͚> 777@TT۷oߏn5 _+}  A\\\׭[L&RRRGۇY^PTBPSSCS(ggg rn ɓ'KKKYK\\܍7FD ddd6nG D &MBDVVӧOT*.++[VVGnw}oM?x!hx򥈈@tsc]]Ý z}iСn! e:طoAo >booҲjժs2KHH4hz=t:H$/_TWW;!LsFA|߿@EE%::%OOO\9 .IIII͞=;((ᡫʜ)cbbbiiyԩ_g0MMM x͛7℄N:%&&򪐐..AܨTjaaaCA'M87nܳgOۄ UUU۷(___Ánb۲e`llG8۷o3f; & L'Ng0+VWޠСC.]>~8d^ R_ ;^IIɦM=z4@+^L BBBIII999xAXjkkojjrqqYh@Px11NٹbŊVÁ ̄7.66X g<aaa^ںu+ޱ@6ݻw  2p gDDD;F"ɉ`& :::\\\-ã000X Wx:1'L۷ ]rr%%%O<ɬ3AѣGD;^xw8߿_~=cǎ; ^O CCõk׶Xp w:::-[foow8{|۷oWVV۹s'ޱ@Pggg+(( !~A\\ȑ#!<<իWxAzmH$ɓ'%%%`lljժ+V,qM}}cgg@&1v9v؜K@,--ֆU OaȐ!&aaa%%%xAr̙2"((w8 nnn--- p g?~\f &&fxAgk.yyGdo\|ymm+@P_bݲe H<~aøu}}__\\͛)aȐ!ZZZSN2e 7ÃC999}õN"""TUU{Czzzr-T_/_ιo>غu;{^tښL&|RQQӁAo9rDCC#;;[XXDFF;w-#""ࠪJR%%%%$$;ׯ_tٳgh4N  xwN1cFFF@;Fӿ^YYQFȌ9r.\}Bh_mmm D"mڴȨWê.]jii,]pz6x˿+##8x ޱ𙖖7o)** @ 666IIIx΋|^Q8p*))B4UUUi[@@0v`'Ŀ;1  GcO RRRgΜ}3 ))3up8{%K$%% n=<<?ܺu6{ܹ 6|MHHhAAA"""o6##ݽD"Y&""s_ߒMGxJYY1lŋgԩS\^W:nggw5QQѿkΜ9A$1.\fiiyʕKKKك ȁ8VM׮]01|ӧ'$$`w.++{Akkk gBC}}='{򥺺:!;;{Μ9555sZjd0֭JIIŰ*+++  ^ O IDATX7iiiǻn155EpHfX %]v PZZȑ#(ZPP```:^ .sz[,9CId2`kkڊUlHGb/_=### ?83GllƍMMMeee'L0aݻwwvvZ[[ş9Jʊ =x`II\ b@t钝]KKKbb".رcD``[CC9ի6|wwwޙ csX[[#ѡ}==˗/s&55=$$$&&ߙ瞞III~~~8Fq@K rrr{[.(($77wڴi?VTT|{ϟ )&&`9rx666m G;Tbhmm-,,9r$Bf4í[ >LrrrDDDɓ;wXXX[)BeeQYYΞ=0 nPWWdMMaÆYYY,$9P=zUPPpÇ;2yd͛7 (p\Ἢjƌ>Dס%dLLfmm/vg yݻ0^|˲޽{MLLг@lg̱ٵ h`?; Ā2M6XH.^h``PVVB}#&&vUKK3f ѣg .HݻwѢLۇy Gh}Xc>}: ++ }߆p&C޳f͢ƪ*ȑ#>aݺu\#&&n޼ܹsWzNN΢Ettt8dFFի߽{'))y &II{͜9} K''H#GL8?<<ۧNRRR¼jww4@@@wjChii655iiiQ({xxs;w5557o;7544\~===ʕ+/>󠴴4+Wږ'O/[,...55uʕHP ѣGׯS̟?ǎtͦӧG%1SW2 [JJJ7nܸroݺE$eddF_2߿~krrr^^^+𿺄`b`K]]1 h")))6W^mذݧ-666--M[[;** p&(( s z̙TڵkcccH$'&&&-H$:}[^]FY.W b!A B(eeׯX*G1Kj?~sH0??s01r%A;`b` HSEE^]xDjjjTT#Gp\h Ad㣃xG|s `Mt޽{?~CW\ ;{w ؃w}}ժUdځ@ .Z͛7ゥj[ KKk׮)**YÇx fffϸqBCCyL KFFfذah #˜ T'7_!!!t-:۰aFy&:&"m۶N8˗K^^XSSΝ;at:=<<\YYyϞ=---8ƃ!>N ;??#Gfdd̙3GMMѣ7@P,--ǍrginyUVVh9-<<<++|ڴiiii锛 ZOаzw ^t)$$%K ;HljaaaW^;6<<|,>[l?~u8˗/JJJ^^^_x1wf{M2ٳ N<ԩS\kBիFFFFFFW^k%+VXZZa]O]]].\з`0|}} |}}oW;81+))͘1CMM9d+WvPիW2:-V/@UTTYJ700^nӧkjj8[2'zAEE%11o :::U7K-###HpW<8}4*I=dF(**zݧO***jjjY\\]]Y a+&&H$wF \vN=^^^_qOOOOЏ۪NNNu"[Fի5/^n޼yG~YvGhmOOO۷ݻ7!!!99ٳ.]}vDDDNOOYweqN˗wGillDmm7QE7pB+++333ccc}}SNtΪSWW>|Q~$ӧOѲοwڴiuuuㆆ1G~ 111v!۷S=a߾}^q@c8}t@={˗;;; ++[VVGtQTT4cƌ'O 3k֬5΄&xڴi eر#FXПkk뢢"J jjj.]p¹sN>}ĉcǎ>|8>>>66600guF}Z6CrrCbbbЕ銋 ~#L4Aʕ+Tjllb&>(>>>4$|Դ#K T*u„ Æ 2dP>zNbR]22X|;z1K#1W%K3/p!r͛7o*))^zŊL&chu_.k"H[n D"Q__Ν[ikkk.jjjߛ'}6o޼>200055b/FM .\ sAAAfyKhhѣO1y!CdffR[[[[[[kkkCCAj񾾾˗/?{,=ףGBUWR;lO"1y<&;m4>-[ =]:^^^`3}8zyysp3((@\\\LL Z[[QQQOe_9YϞ=}ԩ>>>666AAA c$i޼y=iooOLLvDD)Fm/& ,uT))),o GKagTj*I&B2|Yaʔ)~~~666dɒ۷БHuuu_,N,{>e^$*ZXX}!$ o߾3g444..[555,oonnYSMMMGGǩ Sٳ}uΉ:]ݻ%+ڵ2Ϛ5 M ]d/^ow'O]sss___#!!=+mݺښY:66fff۷o¶Q__ϲ(Y\~Hcޔᡫ~3۳|;ɲs/Ba:P%++ӧFXV#\w7Lqwcǎ믿~_c|Ex񹦦ռѣG'%%\AAػ2|>#|9 eeeQ3]BBBNNN/_[߮1(ˏ]ph^|+:~SN@ٹ`hhgw_zghhn3gNJJ zAWWݡ_ϰs}}=HWWݻ=և55)D󳳳{܍}S_1{b;…V*:t/t4}||~3Çћ qF115% ݡW._JHH\ˋy&XwMzZ1cBBB) NHH4iRDDD~Tee޽{7oތ207L##^u>0@Xx]g>k}} 5KtL]] lFZr%׎fo1mEj1 ƶ %'';88 3cbb\]]1N|;aPv%uvv&$$0jhh(Ϟ=;eʔHLFK}}:MMMG ݡ=zcooϹ{kvv2m<ׯ_/..y ox=zмܓH$<==Ybr˗?~>|xxx@:Z111qpp5{n@nngmma@Y&~C/tJY>2\[H?ԯw/`5N8P`,Գ~իW矿ȧw`KKK+;;- &⬀7{@ @())qssCײNII)++:wTiii;v0.\ @ $&&R(  ^b~4 sxgk"[vmסt fcǎ1Κ5>΍0} ..R,胮Û,#c8 ^e_RRRtttssEק=N8߉a̘1h@+rˬ=CCæ&--- ---' ߉CA 뒒田ܺu;.66͍D")**8qe/77uժUŋ3Μ9L =)BPSTTMq/__ }<5]``b4***-[?'B{v/AĀM [tiEEށpչslmmydD^^.̡$@׺33)St?c`؁ Fdddhh(:_6{sIKKOLL011 e}.R(ԴӧOK,aهe_ߦ A@+X]]mee4"33SVVΝ;:::xEqF޹s~>zF3W ŀ:cζށCGGӧ왞ީS,--mll>|(..~ xGA<A6hjԨQK.޵k7{~𡂂Çy0+@ĎpPWW:E@ ;IDEEO:ERCBB6oޜsq111N{vCCÿ{ȑqKLL400`W /6!!!lsI /!S__߷72$55H$v633}Tmm-F HR+ߏvppWLIIիѩ|}}=MSS311qv5 CǏ/**¶~twh#}^z]OXB/_pCCCCCĻwfdddggׯ?~GIIIHKKȌ?RNN qBLcǎɡh۷o߸q#1;GMMͨQ}joo[11{\f!~Xf^zE$EDD~w,0k0kiNNNhgk0pO>nݺ8c0^v;577tttsoܸqڵÇYf޽p:Pқ7o(w{ kЃccc.۞={: ***T*URRL& 666ս~ʕ+hiz!!!{{{??'r-r tĉUVk|&L ׯjkk>i&Á;v;88KJJ!88 /|ܸqǏ;G} @PΝ;ږ.] #nj{nc>3/_7PEEp ddd N4 p a׮]---0+@CC 6;;;jjjAP?={LOOALx 2@HKK;_]]M`VԩS#""\\\?.&&wD3H$8hiixبXUU1sL\ƒkkk~ņ ݋w83+)!!f %'' effCss3IHHޱ@Pihh3+V466Ç+**tttfϞw,)SX ZZZ{4` &'' ߽{p 'G~UKKkΜ9xAQSS Cյp ?x:1ܹB ܔ ___mm2^x!ACRRRyyy0& ,""x֭/UVVzxx0 b9M 푑.@jxx8 nnnuuu߾}16h0pĉ2*k՜ C7n///߸q#ȑ#R\C/M ;v<$DJJJKJJz*D=uUTTlmm8k„ ۶m\ܹs 01@x;tvv ]h0X~}ZZZffʕ+>놆:Nڤd"b/&gϾyfK.;˗.BKl&A>}񋝉Dɓi4/~@_  $HxAc0۷ou&C}QFFf ߿}/_}vl>4DL2hSRRjoo;"⠯_bD"޶rrr^^^ VSScg|D_\b7n 11p 򌍍޾}-O}hF`۷RUU}9V-C|~WUU]r%JE:99fdd ]Ҁ: 'Nh]{ iii VUUvZB+WHHH?48/z3J-,,{ɰattt Ǐggw444om&LxZ" bk׮٥nܸAkk#G >Cl޼y^zHk.N4CNzu@PЧ  ǏGhhh ]&O%=y򄽔A͛7WXuV@Nׯ_888p@>;n8?>_<&tzyy9`С"HꪫtĊ=5LMMo߾* p˗s_ss[n͛7/%%N c @ؼy3bСCxG &III={l߾}]]]4OLLL,---[foo h0`0W>|ӧ.\i4ZFFŋΝ&..mD"?|0+͑B0Z[[۲ebbb7n+YYYAMM V͢CI$ 9`%u[ZZZ-ZtiIIɛ7oΞ=HTjffرc>|8cƌ*"wAM\] AAkJ)"OZ@ /_{ǎ\.W Ab@Mmڴ)--MSSDI vރn @ d2VrD H$?z(a'NعsR{Oן;w({uK.UTTddd1((޽{ #99yƍJ}SWWw!$݂ JJJ***wܩ/^ܴi744LKK[`bfff*+x5}vib[0''''''ggj66k֬'ORMhPM%ɸ|3®njjj#/_,**:uꔗ{(:u;HS>ŋ+W8pdgKKK 㥥8bE"<#SIpZZl/\Q\\\\\Ld2'Md2uuuۅB!ooo'?aؼy󼽽###544(rimm-++[z5B!4f9s搷R'L`ddR/& 1@Wy{{{{{\v555/^ kkk̙3fŊ {GI.]n:PbbիW>|hgg'H܀K344,-- F@bƎO >/BaOOq&NHmÓE^p֭[y<^ppiZZ&!BBB0 c0)))TN[!DbeeEu$ Ba)2ٍ7BtxQ2 uCUUqϜ9̌@OSRөpgϞmnnuYfQ"ilc^vvvEEExx~Hu,*bBBBx<^vveFSznt钉IhhhMMR222rss),,T@oH$zŊ#P"ڵy׮]ĚȕxH Ԍ---.]z]%5~w߿<9oRX,rBe0<$=,] !x^^]fffoo2322!6qFooa(q@0=deeݻxgϞ .GK ll6q$Y/D0`@a?nooO.7+++ سgODDDppq8VeeBڵÃK"""n߾=!"##l̙g@{DXL+1mbbb ð{xx XN+Vhkk5XBB–-[B6lPYQ;;իWgddHlll<|pHHȶmۦN:Q:::pC[XX~0x<ޕ+W;6$Ill$Cnnnrr$rH$֖id |-Z"*Qb p?zhWWWWWH$"}(xGGw}4H{ !YHFDDDDDH r233KKK ۽{sJ~{QбcVZEg0B}PԄ0aBhx2~Y]ٳIII\.ŋ88;;83$KKJGGGGGG''* P+++7XDuՑ0eʔDHn#*sXYY@}ⲲփO pwpS1݀)Բ2ir$64FI%j Î92tD36l8|0Œgz#GSL6m%/^^^^111PSI{{{M d}@g%jgxfϞ} (i,uPWWw;viD}ƍjcc耀'F}}}Q*(( ^ٳʊxի*6P723ÅBAwwMB+W$=<b$G2(\UUUHHQ xO'HO(Oss3]& 1@?۶mrrr谱aaasΝ0atCi̙3TG!/ccc osss+**w[|!~z/_yo83 ޑ$fffO<: 4fkk믿RmF 1x$o 7:$I`` Q J(R 1jU2*){D+[P/D͛7߾}Ȉp@ @l0 THWd2P+ 駟&&&URR2u۷oϜ9`gԋ;w\\\͛G2---%%%fffŐP;ǏyE?VZZ͛WQQaiiY\\S`v/aܹ֭D!!!uvuuܹӳѣG$hCOOٳ۷oojj^o|>ȑ#ӦM3fLLḼ[ 3#J~|~TTTJJ cƌqww]d[?֖sMH244ɱU~ 1@W555.\ +ikkϙ3g֬YzzzL&d;]( gϞ=p8}͟?o$譽=///''Ν;mmmomd2}}}L@b`hii~qggP( ===L&sܸql60#j?wwZNIENDB`source/rainerscript/0000775000175000017500000000000013223143453013545 5ustar rgerrgersource/rainerscript/control_structures.rst0000664000175000017500000000624513223143030020260 0ustar rgerrgerControl Structures ================== Control structures in RainerScript are similar in semantics to a lot of other mainstream languages such as C, Java, Javascript, Ruby, Bash etc. So this section assumes the reader is familiar with semantics of such structures, and goes about describing RainerScript implementation in usage-example form rather than by formal-definition and detailed semantics documentation. RainerScript supports following control structures: if ------- :: if ($msg contains "important") then { if ( $.foo != "" ) then set $.foo = $.bar & $.baz; action(type="omfile" file="/var/log/important.log" template="outfmt") } if/else-if/else -------------------- :: if ($msg contains "important") then { set $.foo = $.bar & $.baz; action(type="omfile" file="/var/log/important.log" template="outfmt") } else if ($msg startswith "slow-query:") then { action(type="omfile" file="/var/log/slow_log.log" template="outfmt") } else { set $.foo = $.quux; action(type="omfile" file="/var/log/general.log" template="outfmt") } foreach ----------- Foreach can iterate both arrays and objects. As opposed to array-iteration (which is ordered), object-iteration accesses key-values in arbitrary order (is unordered). For the foreach invocation below: :: foreach ($.i in $.collection) do { ... } Say ``$.collection`` holds an array ``[1, "2", {"a": "b"}, 4]``, value of ``$.i`` across invocations would be ``1``, ``"2"``, ``{"a" : "b"}`` and ``4``. When ``$.collection`` holds an object ``{"a": "b", "c" : [1, 2, 3], "d" : {"foo": "bar"}}``, value of ``$.i`` across invocations would be ``{"key" : "a", "value" : "b"}``, ``{"key" : "c", "value" : [1, 2, 3]}`` and ``{"key" : "d", "value" : {"foo" : "bar"}}`` (not necessarily in the that order). In this case key and value will need to be accessed as ``$.i!key`` and ``$.i!value`` respectively. Here is an example of a nested foreach statement: :: foreach ($.quux in $!foo) do { action(type="omfile" file="./rsyslog.out.log" template="quux") foreach ($.corge in $.quux!bar) do { reset $.grault = $.corge; action(type="omfile" file="./rsyslog.out.log" template="grault") if ($.garply != "") then set $.garply = $.garply & ", "; reset $.garply = $.garply & $.grault!baz; } } Please note that asynchronous-action calls in foreach-statement body should almost always set ``action.copyMsg`` to ``on``. This is because action calls within foreach usually want to work with the variable loop populates(in the above example, ``$.quux`` and ``$.corge``) which causes message-mutation and async-action must see message as it was in a certain invocation of loop-body, so they must make a copy to keep it safe from further modification as iteration continues. For instance, an async-action invocation with linked-list based queue would look like: :: foreach ($.quux in $!foo) do { action(type="omfile" file="./rsyslog.out.log" template="quux" queue.type="linkedlist" action.copyMsg="on") } call -------- Details here: :doc:`rainerscript_call` continue ------------ a NOP, useful e.g. inside the then part of an if source/rainerscript/rainerscript_call.rst0000664000175000017500000000343013223143453017777 0ustar rgerrgerThe rsyslog "call" statement ============================ The rsyslog "call" statement is used to tie rulesets together. It is modelled after the usual programming language "call" statement. Think of a ruleset as a subroutine (what it really is!) and you get the picture. The "call" statement can be used to call into any type of rulesets. If a rule set has a queue assigned, the message will be posted to that queue and processed asynchronously. Otherwise, the ruleset will be executed synchronously and control returns to right after the call when the rule set has finished execution. Note that there is an important difference between asynchronous and synchronous execution in regard to the "stop" statement. It will not affect processing of the original message when run asynchronously. The "call" statement replaces the deprecated omruleset module. It offers all capabilities omruleset has, but works in a much more efficient way. Note that omruleset was a hack that made calling rulesets possible within the constraints of the pre-v7 engine. "call" is the clean solution for the new engine. Especially for rulesets without associated queues (synchronous operation), it has zero overhead (really!). omruleset always needs to duplicate messages, which usually means at least ~250 bytes of memory writes, some allocs and frees - and even more performance-intense operations. syntax ------ ``call rulesetname`` Where "rulesetname" is the name of a ruleset that is defined elsewhere inside the configration. If the call is synchronous or asynchronous depends on the ruleset parameters. This cannot be overriden by the "call" statement. related links ------------- - `Blog posting announcing "call" statement (with sample) `_ source/rainerscript/configuration_objects.rst0000664000175000017500000000152613223143453020663 0ustar rgerrgerconfiguration objects ===================== Note: configuration object parameters are case-insensitive. action() -------- The :doc:`action <../configuration/actions>` object is the primary means of describing actions to be carried out. global() -------- This is used to set global configuration parameters. For details, please see the `rsyslog global configuration object `_. input() ------- The :doc:`input <../configuration/input>` object is the primary means of describing inputs, which are used to gather messages for rsyslog processing. module() -------- The module object is used to load plugins. parser() -------- The :doc:`parser <../configuration/parser>` object is used to define custom parser objects. timezone() ---------- The :doc:`timezone <../configuration/timezone>` object is used to define timezone settings. source/rainerscript/queue_parameters.rst0000664000175000017500000002167013223143453017654 0ustar rgerrgerGeneral Queue Parameters ------------------------ Queue parameters can be used together with the following statements: - :doc:`action() <../configuration/actions>` - ruleset() - main\_queue() Queues need to be configured in the action or ruleset it should affect. If nothing is configured, default values will be used. Thus, the default ruleset has only the default main queue. Specific Action queues are not set up by default. To fully understand queue parameters and how they interact, be sure to read the :doc:`queues <../concepts/queues>` documentation. Note: As with other configuration objects, parameters for this object are case-insensitive. - **queue.filename** name File name to be used for the queue files. Please note that this is actually just the file name. A directory can NOT be specified in this parameter. If the files shall be created in a specific directory, specify queue.spoolDirectory for this. The filename is used to build to complete path for queue files. - **queue.spoolDirectory** name This is the directory into which queue files will be stored. Note that the directory must exist, it is NOT automatically created by rsyslog. If no spoolDirectory is specified, the work directory is used. - **queue.size** number This is the maximum size of the queue in number of messages. Note that setting the queue size to very small values (roughly below 100 messages) is not supported and can lead to unpredictable results. For more information on the current status of this restriction see the `rsyslog FAQ: "lower bound for queue sizes" `_. The default depends on queue type and rsyslog version, if you need a specific value, please specify it. Otherwise rsyslog selects what it consideres appropriate for the version in question. In rsyslog rsyslog 8.30.0, for example, ruleset queues have a default size of 50000 and action queues which are configured to be non-direct have a size of 1000. - **queue.dequeuebatchsize** number default 128 - **queue.maxdiskspace** number The maximum size that all queue files together will use on disk. Note that the actual size may be slightly larger than the configured max, as rsyslog never writes partial queue records. - **queue.highwatermark** number This applies to disk-assisted queues, only. When the queue fills up to this number of messages, the queue begins to spool messages to disk. Please note that this should not happen as part of usual processing, because disk queue mode is very considerably slower than in-memory queue mode. Going to disk should be reserved for cases where an output action destination is offline for some period. default 90% of queue size - **queue.lowwatermark** number default 70% of queue size - **queue.fulldelaymark** number Number of messages when the queue should block delayable messages. Messages are NO LONGER PROCESSED until the queue has sufficient space again. If a message is delayable depends on the input. For example, messages received via imtcp are delayable (because TCP can push back), but those received via imudp are not (as UDP does not permit a push back). The intent behind this setting is to leave some space in an almost-full queue for non-delayable messages, which would be lost if the queue runs out of space. Please note that if you use a DA queue, setting the fulldelaymark BELOW the highwatermark makes the queue never activate disk mode for delayable inputs. So this is probably not what you want. default 97% of queue size - **queue.lightdelaymark** number default 70% of queue size - **queue.discardmark** number default 80% of queue size - **queue.discardseverity** number \*numerical\* severity! default 8 (nothing discarded) - **queue.checkpointinterval** number Disk queues by default do not update housekeeping structures every time the queue writes to disk. This is for performance reasons. In the event of failure, data will still be lost (except when data is mangled via the file structures). However, disk queues can be set to write bookkeeping information on checkpoints (every n records), so that this can be made ultra-reliable, too. If the checkpoint interval is set to one, no data can be lost, but the queue is exceptionally slow. - **queue.syncqueuefiles** on/off (default "off") Disk-based queues can be made very reliable by issuing a (f)sync after each write operation. This happens when you set the parameter to "on". Activating this option has a performance penalty, so it should not be turned on without a good reason. Note that the penalty also depends on *queue.checkpointInterval* frequency. - **queue.samplinginterval** number This option allows queues to be populated by events produced at a specific interval. It provides a way to sample data each N events, instead of processing all, in order to reduce resources usage (disk, bandwidth...) This feature is available for version 8.23 and above. - **queue.type** [FixedArray/LinkedList/**Direct**/Disk] - **queue.workerthreads** number number of worker threads, default 1, recommended 1 - **queue.timeoutshutdown** number number is timeout in ms (1000ms is 1sec!), default 0 (indefinite) - **queue.timeoutactioncompletion** number number is timeout in ms (1000ms is 1sec!), default 1000, 0 means immediate! - **queue.timeoutenqueue** number number is timeout in ms (1000ms is 1sec!), default 2000, 0 means discard immediate. This timeout value is used when the queue is full. If rsyslog cannot enqueue a message within the timeout period, the message is discarded. Note that this is setting of last resort (assuming defaults are used for the queue settings or proper parameters are set): all delayable inputs (like imtcp or imfile) have already been pushed back at this stage. Also, discarding of lower priority messages (if configured) has already happened. So we run into one of these situations if we do not timeout quickly enough: * if using imuxsock and no systemd journal is involved, the system would become unresponsive and most probably a hard reset would be required. * if using imuxsock with imjournal forwarding is active, messages are lost because the journal discards them (more agressive than rsyslog does) * if using imjournal, the journal will buffer messages. If journal runs out of configured space, messages will be discarded. So in this mode discarding is moved to a bit later place. * other non-delayable sources like imudp will also loose messages So this setting is provided in order to guard against problematic situations, which always will result either in message loss or system hang. For action queues, one may debate if it would be better to overflow rapidly to the main queue. If so desired, this is easy to acomplish by setting a very large timeout value. The same, of course, is true for the main queue, but you have been warned if you do so! In some other words, you can consider this scenario, using default values. With all progress blocked (unable to deliver a message): * all delayable inputs (tcp, relp, imfile, imjournal, etc) will block indefinantly (assuming queue.lightdelaymark and queue.fulldelaymark are set sensible, which they are by default). * imudp will be loosing messages because the OS will be dropping them * messages arriving via UDP or imuxsock that do make it to rsyslog, and that are a severity high enough to not be filtered by discardseverity, will block for 2 seconds trying to put the message in the queue (in the hope that something happens to make space in the queue) and then be dropped to avoid blocking the machine permanently. Then the next message to be processed will also be tried for 2 seconds, etc. * If this is going into an action queue, the log message will remain in the main queue during these 2 seconds, and additional logs that arrive will accumulate behind this in the main queue. - **queue.timeoutworkerthreadshutdown** number number is timeout in ms (1000ms is 1sec!), default 60000 (1 minute) - **queue.workerthreadminimummessages** number default queue size/number of workers - **queue.maxfilesize** size\_nbr default 1m - **queue.saveonshutdown** on/\ **off** - **queue.dequeueslowdown** number number is timeout in microseconds (1000000us is 1sec!), default 0 (no delay). Simple rate-limiting! - **queue.dequeuetimebegin** number - **queue.dequeuetimeend** number - **queue.samplinginterval** number Sampling interval for action queue. This parameter specifies how many line of logs will be dropped before one enqueued. default 0. **Sample:** The following is a sample of a TCP forwarding action with its own queue. :: action(type="omfwd" target="192.168.2.11" port="10514" protocol="tcp" queue.filename="forwarding" queue.size="1000000" queue.type="LinkedList" ) source/rainerscript/expressions.rst0000664000175000017500000000213212704114446016662 0ustar rgerrgerExpressions =========== The language supports arbitrary complex expressions. All usual operators are supported. The precedence of operations is as follows (with operations being higher in the list being carried out before those lower in the list, e.g. multiplications are done before additions. - expressions in parenthesis - not, unary minus - \*, /, % (modulus, as in C) - +, -, & (string concatenation) - ==, !=, <>, <, >, <=, >=, contains (strings!), startswith (strings!) - and - or For example, "not a == b" probably returns not what you intended. The script processor will first evaluate "not a" and then compare the resulting boolean to the value of b. What you probably intended to do is "not (a == b)". And if you just want to test for inequality, we highly suggest to use "!=" or "<>". Both are exactly the same and are provided so that you can pick whichever you like best. So inquality of a and b should be tested as "a <> b". The "not" operator should be reserved to cases where it actually is needed to form a complex boolean expression. In those cases, parenthesis are highly recommended.source/rainerscript/constant_strings.rst0000664000175000017500000000076613223143010017677 0ustar rgerrgerConstant Strings ================ String constants are necessary in many places: comparisons, configuration parameter values and function arguments, to name a few important ones. In constant strings, special characters are escape by prepending a backslash in front of them -- just in the same way this is done in the C programming language or PHP. If in doubt how to properly escape, use the `RainerScript String Escape Online Tool `_. source/rainerscript/lookup_tables.rst0000664000175000017500000000037613223143030017137 0ustar rgerrgerLookup Tables ============= :doc:`Lookup tables <../configuration/lookup_tables>` are a powerful construct to obtain "class" information based on message content (e.g. to build log file names for different server types, departments or remote offices). source/rainerscript/rainerscript_call_indirect.rst0000664000175000017500000000430413223143030021650 0ustar rgerrgerThe rsyslog "call_indirect" statement ===================================== The rsyslog "call_indirect" statement is equivalent to :doc:`"call" statement ` except that the name of the to be called ruleset is not constant but an expression and so can be computed at runtime. If the ruleset name cannot be found when call_indirect is used, an error message as emitted and the call_indirect statement is ignored. Execution continues with the next statement. syntax ------ ``call_indirect expression;`` Where "expression" is any valid expression. See :doc:`expressions ` for more information. Note that the trailing semicolon is needed to indicate the end of expression. If it is not given, config load will fail with a syntax error message. examples -------- The potentially most useful use-case for "call_indirect" is calling a ruleset based on a message variable. Let us assume that you have named your rulesets according to syslog tags expected. Then you can use ``call_indirect $syslogtag;`` To call these rulesets. Note, however, that this may be misused by a malicious attacker, who injects invalid syslog tags. This could especially be used to redirect message flow to known standard rulesets. To somewhat mitigate against this, the ruleset name can be slightly mangled by creating a **unique** prefix (do **not** use the one from this sample). Let us assume the prefix "changeme-" is used, then all your rulesets should start with that string. Then, the following call can be used: ``call_indirect "changeme-" & $syslogtag;`` While it is possible to call a ruleset via a constant name: ``call_indirect "my_ruleset";`` It is advised to use the "call" statement for this, as it offers superior performance in this case. additional information ---------------------- We need to have two different statements, "call" and "call_indirect" because "call" already existed at the time "call_indirect" was added. We could not extend "call" to support expressions, as that would have broken existing configs. In that case ``call ruleset`` would have become invalid and ``call "ruleset"`` would have to be used instead. Thus we decided to add the additional "call_indirect" statement for this use case. source/rainerscript/index.rst0000664000175000017500000000144313223143030015377 0ustar rgerrgerRainerScript ============ **RainerScript is a scripting language specifically designed and well-suited for processing network events and configuring event processors.** It is the prime configuration language used for rsyslog. Please note that RainerScript may not be abreviated as rscript, because that's somebody else's trademark. Some limited RainerScript support is available since rsyslog 3.12.0 (for expression support). In v5, "if .. then" statements are supported. The first full implementation is available since rsyslog v6. .. toctree:: :maxdepth: 2 data_types expressions functions control_structures configuration_objects constant_strings variable_property_types lookup_tables queue_parameters rainerscript_call rainerscript_call_indirect global source/rainerscript/variable_property_types.rst0000664000175000017500000000727313223143030021254 0ustar rgerrgerVariable (Property) types ========================= All rsyslog properties (see the :doc:`properties <../configuration/properties>` page for a list) can be used in RainerScript by prefixing them with "$", for example : :: set $.x!host = $hostname; In addition, it also supports local variables. Local variables are local to the current message, but are NOT message properties (e.g. the "$!" all JSON property does not contain them). Only message json (CEE/Lumberjack) properties can be modified by the **set**, **unset** and **reset** statements, not any other message property. Obviously, local variables are also modifiable. Message JSON property names start with "$!" where the bang character represents the root. Local variables names start with "$.", where the dot denotes the root. Both JSON properties as well as local variables may contain an arbitrary deep path before the final element. The bang character is always used as path separator, no matter if it is a message property or a local variable. For example "$!path1!path2!varname" is a three-level deep message property where as the very similar looking "$.path1!path2!varname" specifies a three-level deep local variable. The bang or dot character immediately following the dollar sign is used by rsyslog to separate the different types. Note that the trailing semicolon is needed to indicate the end of expression. If it is not given, config load will fail with a syntax error message. Check the following usage examples to understand how these statements behave: **set** ------- sets the value of a local-variable or json property, but if the addressed variable already contains a value its behaviour differs as follows: **merges** the value if both existing and new value are objects, but merges the new value to *root* rather than with value of the given key. Eg. :: set $.x!one = "val_1"; # results in $. = { "x": { "one": "val_1" } } set $.y!two = "val_2"; # results in $. = { "x": { "one": "val_1" }, "y": { "two": "val_2" } } set $.z!var = $.x; # results in $. = { "x": { "one": "val_1" }, "y": { "two": "val_2" }, "z": { "var": { "one": "val_1" } } } set $.z!var = $.y; # results in $. = { "x": { "one": "val_1" }, "y": { "two": "val_2" }, "z": { "var": { "one": "val_1" } }, "two": "val_2" } # note that the key *two* is at root level and not under *$.z!var*. **ignores** the new value if old value was an object, but new value is a not an object (Eg. string, number etc). Eg: :: set $.x!one = "val_1"; set $.x = "quux"; # results in $. = { "x": { "one": "val_1" } } # note that "quux" was ignored **resets** variable, if old value was not an object. :: set $.x!val = "val_1"; set $.x!val = "quux"; # results in $. = { "x": { "val": "quux" } } **unset** --------- removes the key. Eg: :: set $.x!val = "val_1"; unset $.x!val; # results in $. = { "x": { } } **reset** --------- force sets the new value regardless of what the variable originally contained or if it was even set. Eg. :: # to contrast with the set example above, here is how results would look with reset set $.x!one = "val_1"; set $.y!two = "val_2"; set $.z!var = $.x; # results in $. = { "x": { "one": "val_1" }, "y": { "two": "val_2" }, "z": { "var": { "one": "val_1" } } } # 'set' or 'reset' can be used interchangeably above(3 lines), they both have the same behaviour, as variable doesn't have an existing value reset $.z!var = $.y; # results in $. = { "x": { "one": "val_1" }, "y": { "two": "val_2" }, "z": { "var": { "two": "val_2" } } } # note how the value of $.z!var was replaced reset $.x = "quux"; # results in $. = { "x": "quux", "y": { "two": "val_2" }, "z": { "var": { "two": "val_2" } } } source/rainerscript/functions.rst0000664000175000017500000002730613223143453016317 0ustar rgerrgerFunctions ========= RainerScript supports a currently quite limited set of functions: getenv(str) ----------- like the OS call, returns the value of the environment variable, if it exists. Returns an empty string if it does not exist. The following example can be used to build a dynamic filter based on some environment variable: :: if $msg contains getenv('TRIGGERVAR') then /path/to/errfile strlen(str) ----------- returns the length of the provided string tolower(str) ------------ converts the provided string into lowercase cstr(expr) ---------- converts expr to a string value cnum(expr) ---------- converts expr to a number (integer) Note: if the expression does not contain a numerical value, behaviour is undefined. wrap(str, wrapper_str) ---------------------- returns the str wrapped with wrapper_str. Eg. :: wrap("foo bar", "##") produces :: "##foo bar##" wrap(str, wrapper_str, escaper_str) ----------------------------------- returns the str wrapped with wrapper_str. But additionally, any instances of wrapper_str appearing in str would be replaced by the escaper_str. Eg. :: wrap("foo'bar", "'", "_") produces :: "'foo_bar'" replace(str, substr_to_replace, replace_with) --------------------------------------------- returns new string with all instances of substr_to_replace replaced by replace_with. Eg. :: replace("foo bar baz", " b", ", B") produces :: "foo, Bar, Baz". re\_match(expr, re) ------------------- returns 1, if expr matches re, 0 otherwise. Uses POSIX ERE. re\_extract(expr, re, match, submatch, no-found) ------------------------------------------------ extracts data from a string (property) via a regular expression match. POSIX ERE regular expressions are used. The variable "match" contains the number of the match to use. This permits to pick up more than the first expression match. Submatch is the submatch to match (max 50 supported). The "no-found" parameter specifies which string is to be returned in case when the regular expression is not found. Note that match and submatch start with zero. It currently is not possible to extract more than one submatch with a single call. field(str, delim, matchnbr) --------------------------- returns a field-based substring. str is the string to search, delim is the delimiter and matchnbr is the match to search for (the first match starts at 1). This works similar as the field based property-replacer option. Versions prior to 7.3.7 only support a single character as delimiter character. Starting with version 7.3.7, a full string can be used as delimiter. If a single character is being used as delimiter, delim is the numerical ascii value of the field delimiter character (so that non-printable characters can by specified). If a string is used as delimiter, a multi-character string (e.g. "#011") is to be specified. Note that when a single character is specified as string ``field($msg, ",", 3)`` a string-based extraction is done, which is more performance intensive than the equivalent single-character ``field($msg, 44 ,3)`` extraction. Eg. :: set $!usr!field = field($msg, 32, 3); -- the third field, delimited by space set $!usr!field = field($msg, "#011", 2); -- the second field, delimited by "#011" exec\_template -------------- Sets a variable through the execution of a template. Basically this permits to easily extract some part of a property and use it later as any other variable. :: template(name="extract" type="string" string="%msg:F:5%") set $!xyz = exec_template("extract"); the variable xyz can now be used to apply some filtering : :: if $!xyz contains 'abc' then {action()} or to build dynamically a file path : :: template(name="DynaFile" type="string" string="/var/log/%$!xyz%-data/%timereported%-%$!xyz%.log") **Read more about it here :** ``_ prifilt(constant) ----------------- mimics a traditional PRI-based filter (like "\*.\*" or "mail.info"). The traditional filter string must be given as a **constant string**. Dynamic string evaluation is not permitted (for performance reasons). dyn_inc(bucket_name_literal_string, str) ----------------------------------------- Increments counter identified by ``str`` in dyn-stats bucket identified by ``bucket_name_literal_string``. Returns 0 when increment is successful, any other return value indicates increment failed. Counters updated here are reported by **impstats**. Except for special circumstances (such as memory allocation failing etc), increment may fail due to metric-name cardinality being under-estimated. Bucket is configured to support a maximum cardinality (to prevent abuse) and it rejects increment-operation if it encounters a new(previously unseen) metric-name(``str``) when full. **Read more about it here** :doc:`Dynamic Stats<../configuration/dyn_stats>` lookup(table_name_literal_string, key) --------------------------------------- Lookup tables are a powerful construct to obtain *class* information based on message content. It works on top of a data-file which maps key (to be looked up) to value (the result of lookup). The idea is to use a message properties (or derivatives of it) as an index into a table which then returns another value. For example, $fromhost-ip could be used as an index, with the table value representing the type of server or the department or remote office it is located in. **Read more about it here** :doc:`Lookup Tables<../configuration/lookup_tables>` num2ipv4 -------- Converts an integer into an IPv4-address and returns the address as string. Input is an integer with a value between 0 and 4294967295. The output format is '>decimal<.>decimal<.>decimal<.>decimal<' and '-1' if the integer input is invalid or if the function encounters a problem. ipv42num -------- Converts an IPv4-address into an integer and returns the integer. Input is a string; the expected address format may include spaces in the beginning and end, but must not contain any other characters in between (except dots). If the format does include these, the function results in an error and returns -1. ltrim ----- Removes any spaces at the start of a given string. Input is a string, output is the same string starting with the first non-space character. rtrim ----- Removes any spaces at the end of a given string. Input is a string, output is the same string ending with the last non-space character. substring(str, start, subStringLength) -------------------------------------- Creates a substring from str. The substring begins at start and is at most subStringLength characters long. int2hex(num) ------------ returns a hexadecimal number string of a given positive integer num. script_error ------------ Returns the error state of functions that support it. C-Developers note that this is similar to ``errno`` under Linux. The error state corresponds to the function immediatly called before. The next function call overrides it. Right now, the value 0 means that that the previous functions succeeded, any other value that it failed. In the future, we may have more fine-grain error codes. Function descriptions mention if a function supports error state information. If not, the function call will always set ``script_error()`` to 0. previous_action_suspended ------------------------- This boolenan function returns 1 (true) if the previous action is suspended, 0 (false) otherwise. It can be used to initiate action that shall happen if a function failed. Please note that an action failure may not be immediately detected, so the function return value is a bit fuzzy. It is guaranteed, however that a suspension will be detected with the next batch of messages that is being processed. Use ... If, for example, you want to execute a rule set in case of failure of an action, do this:: ruleset(name="output_writer") { action(type="omfile" file="rsyslog.log") } action(type="omfwd" protocol="tcp" target="10.1.1.1") if previous_action_suspended() then call output_writer format_time(unix_timestamp, format_str) --------------------------------------- **NOTE: this is EXPERIMENTAL code** - it may be removed or altered in later versions than 8.30.0. Please watch the ChangeLog closely for updates. Converts a UNIX timestamp to a formatted RFC 3164 or RFC 3339 date/time string. The first parameter is expected to be an integer value representing the number of seconds since 1970-01-01T00:00:0Z (UNIX epoch). The second parameter can be one of ``"date-rfc3164"`` or ``"date-rfc3339"``. The output is a string containing the formatted date/time. Date/time strings are expressed in **UTC** (no time zone conversion is provided). * **Note**: If the input to the function is NOT a proper UNIX timestamp, a string containing the *original value of the parameter* will be returned instead of a formatted date/time string. :: format_time(1507165811, "date-rfc3164") produces :: Oct 5 01:10:11 and :: format_time(1507165811, "date-rfc3339") produces :: 2017-10-05T01:10:11Z In the case of an invalid UNIX timestamp: :: format_time("foo", "date-rfc3339") it produces the original value: :: foo parse_json(string, container) ----------------------------- Parses the json string ``string`` and places the resulting json object into ``container`` where container can be any valid rsyslog variable. Returns 0 on success and something otherwise if ``string`` does **not** contain valid json. parse_time(timestamp) --------------------------------------- Converts an RFC 3164 or RFC 3339 formatted date/time string to a UNIX timestamp (an integer value representing the number of seconds since the UNIX epoch: 1970-01-01T00:00:0Z). If the input to the function is not a properly formatted RFC 3164 or RFC 3339 date/time string, or cannot be parsed, ``0`` is returned and ``script_error()`` will be set to error state. * **Note**: This function does not support unusual RFC 3164 dates/times that contain year or time zone information. * **Note**: Fractional seconds (if present) in RFC 3339 date/time strings will be discarded. :: parse_time("Oct 5 01:10:11") # Assumes the current year (2017, in this example) produces :: 1507165811 and :: parse_time("2017-10-05T01:10:11+04:00") produces :: 1507151411 is_time(timestamp, format_str) --------------------------------------- Checks the given timestamp to see if it is a valid date/time string (RFC 3164, or RFC 3339), or a UNIX timestamp. This function returns ``1`` for valid date/time strings and UNIX timestamps, ``0`` otherwise. Additionally, if the input cannot be parsed, or there is an error, ``script_error()`` will be set to error state. The ``format_str`` parameter is optional, and can be one of ``"date-rfc3164"``, ``"date-rfc3339"`` or ``"date-unix"``. If this parameter is specified, the function will only succeed if the input matches that format. If omitted, the function will compare the input to all of the known formats (indicated above) to see if one of them matches. * **Note**: This function does not support unusual RFC 3164 dates/times that contain year or time zone information. :: is_time("Oct 5 01:10:11") is_time("2017-10-05T01:10:11+04:00") is_time(1507165811) all produce :: 1 and :: is_time("2017-10-05T01:10:11+04:00", "date-rfc3339") produces :: 1 and :: is_time("2017-10-05T01:10:11+04:00", "date-unix") produces :: 0 source/rainerscript/data_types.rst0000664000175000017500000000060312704114446016436 0ustar rgerrgerData Types ========== RainerScript is a typeless language. That doesn't imply you don't need to care about types. Of course, expressions like "A" + "B" will not return a valid result, as you can't really add two letters (to concatenate them, use the concatenation operator &).  However, all type conversions are automatically done by the script interpreter when there is need to do so.source/rainerscript/global.rst0000664000175000017500000003466713223143453015557 0ustar rgerrgerglobal() configuration object ============================= The global configuration object permits to set global parameters. Note that each parameter can only be set once and cannot be re-set thereafter. If a parameter is set multiple times, the behaviour is unpredictable. As with other configuration objects, parameters for this object are case-insensitive. The following parameters can be set: - **action.reportSuspension** - binary, default "on", v7.5.8+ If enabled ("on") action will log message under *syslog.\** when an action suspends or resumes itself. This usually happens when there are problems connecting to backend systems. If disabled ("off"), these messages are not generated. These messages can be useful in detecting problems with backend systems. Most importantly, frequent suspension and resumption points to a problem area. - **action.reportSuspensionContinuation** - binary, default "off", v7.6.1+, v8.2.0+ If enabled ("on") the action will not only report the first suspension but each time the suspension is prolonged. Otherwise, the follow-up messages are not logged. If this setting is set to "on", action.reportSuspension is also automaticaly turned "on". - **workDirectory** - **dropMsgsWithMaliciousDNSPtrRecords** - **localHostname** - **preserveFQDN** - **defaultNetstreamDriverCAFile** For `TLS syslog `_, the CA certificate that can verify the machine keys and certs (see below) - **defaultNetstreamDriverKeyFile** Machine private key - **defaultNetstreamDriverCertFile** Machine public key (certificate) - **debug.gnutls** (0-10; default:0) Any other parameter than 0 enables the debug messages of GnuTLS. the amount of messages given depends on the height of the parameter, 0 being nothing and 10 being very much. Caution! higher parameters may give out way more information than needed. We advise you to first use small parameters to prevent that from happening. **This parameter only has an effect if general debugging is enabled.** - **processInternalMessages** binary (on/off) This tells rsyslog if it shall process internal messages itself. The default mode of operations ("off") makes rsyslog send messages to the system log sink (and if it is the only instance, receive them back from there). This also works with systemd journal and will make rsyslog messages show up in the systemd status control information. If this (instance) of rsyslog is not the main instance and there is another main logging system, rsyslog internal messages will be inserted into the main instance's syslog stream. In this case, setting to ("on") will let you receive the internal messages in the instance they originate from. Note that earlier versions of rsyslog worked the opposite way. More information about the change can be found in `rsyslog-error-reporting-improved `_. - **stdlog.channelspec** Permits to set the liblogging-stdlog channel specifier string. This in turn permits to send rsyslog log messages to a destination different from the system default. Note that this parameter has only effect if *processInternalMessages* is set to "off". Otherwise it is silently ignored. - **defaultNetstreamDriver** Set it to "gtls" to enable TLS for `TLS syslog `_ - **maxMessageSize** Configures the maximum message size allowed for all inputs. Default is 8K. Anything above the maximum size will be truncated. Note: some modules provide separate parameters that allow overriding this setting (e.g., :doc:`imrelp's MaxDataSize parameter <../../configuration/modules/imrelp>`). .. _global_janitorInterval: - **janitor.interval** [minutes], available since 8.3.3 Sets the interval at which the :doc:`janitor process <../concepts/janitor>` runs. - **debug.onShutdown** available in 7.5.8+ If enabled ("on"), rsyslog will log debug messages when a system shutdown is requested. This can be used to track issues that happen only during shutdown. During normal operations, system performance is NOT affected. Note that for this option to be useful, the debug.logFile parameter must also be set (or the respective environment variable). - **debug.logFile** available in 7.5.8+ This is used to specify the debug log file name. It is used for all debug output. Please note that the RSYSLOG\_DEBUGLOG environment variable always **overrides** the value of debug.logFile. - **net.ipprotocol** available in 8.6.0+ This permits to instruct rsyslog to use IPv4 or IPv6 only. Possible values are "unspecified", in which case both protocols are used, "ipv4-only", and "ipv6-only", which restrict usage to the specified protocol. The default is "unspecified". Note: this replaces the former *-4* and *-6* rsyslogd command line options. - **net.aclAddHostnameOnFail** available in 8.6.0+ If "on", during ACL processing, hostnames are resolved to IP addresses for performance reasons. If DNS fails during that process, the hostname is added as wildcard text, which results in proper, but somewhat slower operation once DNS is up again. The default is "off". - **net.aclResolveHostname** available in 8.6.0+ If "off", do not resolve hostnames to IP addresses during ACL processing. The default is "on". - **net.enableDNS** [on/off] available in 8.6.0+ **Default:** on Can be used to turn DNS name resolution on or off. - **net.permitACLWarning** [on/off] available in 8.6.0+ **Default:** on If "off", suppress warnings issued when messages are received from non-authorized machines (those, that are in no AllowedSender list). - **parser.parseHostnameAndTag** [on/off] available in 8.6.0+ **Default:** on This controls wheter the parsers try to parse HOSTNAME and TAG fields from messages. The default is "on", in which case parsing occurs. If set to "off", the fields are not parsed. Note that this usually is **not** what you want to have. It is highly suggested to change this setting to "off" only if you know exactly why you are doing this. - **parser.permitSlashInHostname** [on/off] available in 8.25.0+ **Default:** off This controls whether slashes in the "programname" property are permitted or not. This property bases on a BSD concept, and by BSD syslogd sources, slashes are NOT permitted inside the program name. However, some Linux tools (including most importantly the journal) store slashes as part of the program name inside the syslogtag. In those cases, the programname is truncated at the first slash. If this setting is changed to "on", slashes are permitted and will not terminate programname parsing. - **parser.permitSlashInProgramName** [on/off] available in 8.25.0+ **Default:** off This controls whether slashes in the static part of the tag are permitted or not. If this setting is off, a value of "app/foo[1234]" in the tag will result in a programname of "app". If an application stores an absolute path name like "/app/foo[1234]", the programname property will become empty (""). If you need to actually store slashes as part of the programname, this setting should be changed to "on" to permit this. Then, a syslogtag of "/app/foo[1234]" will result in programname being "/app/foo". - **senders.keepTrack** [on/off] available 8.17.0+ **Default:** off If turned on, rsyslog keeps track of known senders and also reports statistical data for them via the impstats mechanism. A list of active senders is kept. When a new sender is detected, an informational message is emitted. Senders are purged from the list only after a timeout (see *senders.timoutAfter* parameter). Note that we do not intentionally remove a sender when a connection is closed. The whole point of this sender-tracking is to have the ability to provide longer-duration data. As such, we would not like to drop information just because the sender has disconnected for a short period of time (e.g. for a reboot). Senders are tracked by their hostname (taken at connection establishment). Note: currently only imptcp and imtcp support sender tracking. - **senders.timeoutAfter** [seconds] available 8.17.0+ **Default:** 12 hours (12*60*60 seconds) Specifies after which period a sender is considered to "have gone away". For each sender, rsyslog keeps track of the time it least received messages from it. When it has not received a message during that interval, rsyslog considers the sender to be no longer present. It will then a) emit a warning message (if configured) and b) purge it from the active senders list. As such, the sender will no longer be reported in impstats data once it has timed out. - **senders.reportGoneAway** [on/off] available 8.17.0+ **Default:** off Emit a warning message when now data has been received from a sender within the *senders.timeoutAfter* interval. - **senders.reportNew** [on/off] available 8.17.0+ **Default:** off If sender tracking is active, report a sender that is not yet inside the cache. Note that this means that senders which have been timed out due to prolonged inactivity are also reported once they connect again. - **debug.unloadModules** [on/off] available 8.17.0+ **Default:** on This is primarily a debug setting. If set to "off", rsyslog will never unload any modules (including plugins). This usually causes no operational problems, but may in extreme cases. The core benefit of this setting is that it makes valgrind stack traces readable. In previous versions, the same functionality was only available via a special build option. - **debug.files** [ARRAY of filenames] available 8.29.0+ **Default:** none This can be used to configure rsyslog to only show debug-output generated in certain files. If the option is set, but no filename is given, the debug-output will behave as if the option is turned off. Do note however that due to the way the configuration works, this might not effect the first few debug-outputs, while rsyslog is reading in the configuration. For optimal results we recommend to put this parameter at the very start of your configuration to minmize unwanted output. See debug.whitelist for more information. - **debug.whitelist** [on/off] available 8.29.0+ **Default:** on This parameter is an assisting parameter of debug.files. If debug.files is used in the configuration, debug.whitelist is a switch for the files named to be either white- or blacklisted from displaying debug-output. If it is set to on, the listed files will generate debug-output, but no other files will. The reverse principle applies if the parameter is set to off. See debug.files for more information. - **environment** [ARRAY of environment variable=value strings] available 8.23.0+ **Default:** none This permits to set environment variables via rsyslog.conf. The prime motivation for having this is that for many libraries, defaults can be set via environment variables, **but** setting them via operating system service startup files is cumbersome and different on different platforms. So the *environment* parameter provides a handy way to set those variables. A common example is to set the *http_proxy* variable, e.g. for use with KSI signing or ElasticSearch. This can be done as follows:: global(environment="http_proxy=http://myproxy.example.net") Note that an environment variable set this way must contain an equal sign, and the variable name must not be longer than 127 characters. It is possible to set multiple environment variables in a single global statement. This is done in regular array syntax as follows:: global(environment=["http_proxy=http://myproxy.example.net", "another_one=this string is=ok!" ) As usual, whitespace is irrelevant in regard to parameter placing. So the above sample could also have been written on a single line. - **internalmsg.ratelimit.interval** [positive integer] available 8.29.0+ **Default:** 5 Specifies the interval in seconds onto which rate-limiting is to be applied to internal messgaes generated by rsyslog(i.e. error messages). If more than internalmsg.ratelimit.burst messages are read during that interval, further messages up to the end of the interval are discarded. - **internalmsg.ratelimit.burst** [positive integer] available 8.29.0+ **Default:** 500 Specifies the maximum number of internal messages that can be emitted within the ratelimit.interval interval. For futher information, see description there. **Caution:** Environment variables are set immediately when the corresponding statement is encountered. Likewise, modules are loaded when the module load statement is encountered. This may create **sequence dependencies** inside rsyslog.conf. To avoid this, it is highly suggested that environment variables are set **right at the top of rsyslog.conf**. Also, rsyslog-related environment variables may not apply even when set right at the top. It is safest to still set them in operating system start files. Note that rsyslog environment variables are usually intended only for developers so there should hardly be a need to set them for a regular user. Also, many settings (e.g. debug) are also available as configuration objects. - **errorMessagesToStderr.maxNumber** [positive integer] available 8.30.0+ **Default:** unlimited This permits to put a hard limit on the number of messages that can go to stderr. If for nothing else, this capability is helpful for the testbench. It permits to reduce spamming the test log while still providing the ability to see initial error messages. Might also be useful for some practical deployments. - **variables.caseSensitve** [boolean (on/off)] available 8.30.0+ **Default:** off This permits to make variables case-sensitive, what might be required for some exotic input data where case is the only difference in field names. Note that in rsyslog versions prior to 8.30, the default was "on", which very often led to user confusion. There normally should be no need to switch it back to "on", except for the case to be mentioned. This is also the reason why we switched the default. - **dynafile.donotsuspend** [boolean (on/off)] available 8.32.0+ **Default:** on This permits SUSPENDing dynafile actions. Traditionally, SUSPEND mode was never entered for dynafiles as it would have blocked overall processing flow. Default is not to suspend (and thus block). source/whitepapers/0000775000175000017500000000000013223143453013373 5ustar rgerrgersource/whitepapers/preserve_in_nat.rst0000664000175000017500000000442412704114446017317 0ustar rgerrgerPreserving syslog sender over NAT ================================= Question: I have a number of syslog clients behind a NAT device. The receiver receives syslog messages that travelled over the NAT device. This leads the receiver to believe that all messages originated from the same IP address. With stock syslogd, I can not differentiate between the senders. Is there any way to record the correct sender of the message with rsyslog? Answer: OK, I’ve now had some real lab time. The good news in short: if you use rsyslog both on the senders as well as on the receiver, you do NOT have any problems with NAT. To double-check (and out of curiosity), I also tried with stock syslogd. I used the ones that came with RedHat and FreeBSD. Neither of them reports the sending machine correctly, they all report the NAT address. Obviously, this is what made this thread appear, but it is a good verification for the correctness of my lab. Next, I tried rsyslogd on the sender and stock syslogd on the receiver (just RedHat this time). The machine was still incorrectly displayed as the NAT address. However, now the real machine name immediately followed the NAT address, so you could differentiate the different machines – but in a inconsistent way. Finally, I tried to run the stock syslogds against rsyslogd. Again, the host was not properly displayed. Actually, this time the host was not displayed at all (with the default rsyslogd template). Instead, the tag showed up in the host field. So this configuration is basically unusable. The root cause of the NAT issue with stock syslogd obviously is that it does NOT include the HOST header that should be sent as of RFC 3164. This requires the receiver to take the host from the socket, which – in a NATed environment – can only hold the mangled NAT address. Rsyslog instead includes the HOST header, so the actual host name can be taken from that (this is the way rsyslog works with the default templates). I barely remember seeing this in code when I initially forked rsyslog from sysklogd. I have not verified it once again. I have also not tested with syslog-ng, simply because that is not my prime focus and a lab would have required too much time. To make a long story short: If you use rsyslog on both the senders and receivers, NAT is no issue for you.source/whitepapers/direct_queue_rsyslog.png0000664000175000017500000002434112704114446020350 0ustar rgerrgerPNG  IHDRsBITO pHYse IDATxytڇl E¾H"•^P<^EE# ") *"v D uaI2Cfg99_[ݿj7!@ +(`wCdBJ+k"ٍ5:z(ݾ}{T(fw~nfrk֬yǖ裏tlW(Wɾ+w:WW|Տ~EPw(\ mLNB!3F P8?,X7i'86HP2`o28ǵ%L#JPǠp Sz[nEݘFqyWV\3BOzVLkT=ovsw@sM+䌠w& 7[_-oH RƠ<#& HM%#ȠlY>MG9J!KH&y{J٦b;Pz `:N^{sKI"~o)N;ְ!'Nܾ8wywӖ9UT+ңAQ!+"#ٳÇFZ4lHp0 L:T@r_|3y>{xWf1ۡP(J2'NgZw 8ΝUq=[\rNCuABp \!ظU[`Fd@^Tqr69vP(22(4!Che&0y@R(w2_4XʗgxƏB5) YPbdg3u*fK/1q"+IPȅz8x!CkW/n]) Q Ѫ̟Ν EQ81ix/_gϞm۶eff6n8<<x |۷ػwon"##SSS{b `ܸq&M-[EFF>)))aaa=0}ŋׯ:u*pӧ'&&̚5~ӂ|w]>sɓk֬zjjjcbbY JX͚q,cP@nn"///999338w灘(mIDDQ814o޼E@57nSN___!`Xrss˗/ׯ_͍JLL"##W_5pe˖%%%-ZH;/]tݺu͛{=?޽TSOٳ+W\v X,%^a 2eʹs璓_~m۶&LN+̙ӯ_?`ӦM:t8vXlllfʹ͛:4h9sxyy9rСCUVVkܸ+;֮]zA(|bX222׮]B$$$!bbbnܸ}K. !O:%8y} ;wLKKKMMݺu3g#1'Go/@ .rsSa(ǎf̘!Zj޽B̟?8tPtttڵWX! 4ibԩ{5R:?ùsiӦ !֭۳gO!ĨQk׮ >xٳg[jj*!ēO>9e!|/ !v1rĉ'/B3f|B͛7k?6LӦX,=J*z0< y‰qc5x-:ƱbiC21Z<|Ö-cNr2X/42 #̲`I&`_U$ 0;ũ? 4~/֯_~[~VV… Yz+VXB[X~{Y8WnS7o*$^gY߶)6$''fbccm*b6Ӳq'ؤ_ѴiSXlMiEnB2߿ߚ"hZ\5j6?qMT֭Mm7N:Dw/WBmSѦwyǦ6ſrM񁘘cwwj6|'ERJfx~ִ.1~zzzzzCʶb\p QF ]rŚصsl-(~2~vvvyJ(77{.\ɱa*UY~zz-t3g1TQ׮]ǧ{;ї˻C^K^M'U9996AAA<*XTCcEUZRJOOOiiN/p=r=>{=>}://"_?99ҥKŬpKEյ%Z5:O{@1~DAH ҥ fEq|wOTe*og{-Dž8y{c6Gk\K&OJDGs*3[ڟըA-Dž1/{h9@QI䗡f6r" S 3?<^t&^@-lQCQG^cx'yA4ZhÐyh"I ?Pw~m#/!ؾ{{h9fBRcH'=DםzBB֡3d5dr=•N%u;ە+؊'QD}gFk4GlГILǾiLLgxSXfǚdlly ˬHg џ5GCg1tv '~՝oZ\l';_yގa}}IHn]}4;G%fQQe%3b˗s<hGC:Q H"18ryPFRKV+꫌K-A 1Nx':)W+|\Ag0זԬɨQ׮ԭN{0Z'+0U,(Sdžedn8?SDdg!++F q9~zS a~w5mhoZhn@]Gҙ\=nt3Z`1N덷JL6\W+t&(_|uf7-Xh!΃ư01x+7(21Zk?ᦌ<*QV.VQ=•81QDTF q 1gWV2̇2" hA ,G9.#A 'y@ fEWLD y%99xz:rqٳgPtرOdK z*n' ʊ4h%p|߲«E^жv̙enٲ߿>ȃ}[--ZɩRJ1弼uG}Vc8tMr`d wWc7qر[!xeff_ hժ#+zJ*/nٲ~[↧⋯>B/۶m+}B) E}ݧ,ڵk'N(&------99cxi[".s3^^^eM~1cn]AA2z4[c 20`~ς\~ؾ}{.:'.$d$|r3w_NNg`WZJ%x'OΝ;?Ks.G<3<}N>}ɢuK!nΞ=[l5pIKSO=bŊGsO<VcV_g8VeKZ>F M;P|*UVTxyyݲ*W 6THvkIZׯߨQJ:i˔)d\fKDDݻb *lEQo Yd]r7oޭ[o^ŠWe8E*=K9|(o#orkܞt?Y$իbR 9+}c~/aC܎Ã>2e1hK,7o]*cCslR GC,g_p01:0h-kӷo1o\rvǠ1HByi)c;ygA:H@Q>!=Za10$!PÌ-mSHqnP&o;AAtﮛ6 <eA\4))`w 3\ÞTR$(Lo ر4j`0z>5A=GT,)rѤ\*aưO E … pcPanϑ/@&EfR4cPaUC&ucta|| +5A=Ge)2ݹ f О߬sc'!rk z ̈́EB .%}וICj?;y *2I:jZAaG 34}WkQAy8\T#k&E3c;]JjI˖t»=˅8ʯ;F$Tc'~ӒHETco`p~':D2aW~10$x'y2O<'u^oJ"s[IB!w *5=,s\OI^R==yߍl %;o$#g0#C"Y;)zǠ¸2b7W'xZ6QU) Ku6x`+rtPjә>qe.Ob?;Qg]zǠ¸\ #9CZ)Na.v d`gXd]Z؝;^J:ԾeͰ0dG%ftS\ /*ٳg?3; |1B11׹:צSUK.DPJBuQA l#owܳJ'5^kF37hǀ0AYW F 77>=ϭyLe E,ij x1!ƪrbP HƴL2#ư8=CMj[u<1B1w5^+1hFSXU+D{×Vaqz c,cJ QPh׎SQmg}T91x/`-o(~ & 3O<Yy.uwS(DC/Kم,ԎSuߩwGUM/z_ņǰ(l0cu$(yLe 7o~/z?0ۭlUe^7<10K Iؗ7 :aqz 61BLn1GFLrkVzcXe a H\(*G0|k`'FtB!R&W7̑c<_vn1H)"eruCɩJ2h Ά20BLnș#9U)̈20BLnY;z*L20BLnإϟ`;)3?~|VaL` wJGC QPX|+rfime׮]R;}&''[,jժ+ d۶,;}7%%q{^ꆜ5 V\J/

Hs'Nh T!DDDD6mW rtHo߾k֬qȋn|GVZ5m4[lٹs]viKڅڵkw^q.T-#hݿn+WrC 6mɓ5j ҥ… G,Y""##ׯwԖΆ F9uT ##SNݻv X,~n!((n߾}^maQ=ggg{{{+VLMMuԖ8:F1rȺuܶm[bb"pҥիW8q- wd &&cǎ@HHș3grssn:v&t~+o=֬YӡC.]hh!Ę1cz:tGѺ:Eu>N:o߾u۷oaRqF INvFI pDOPݻnZohh!C/^_zCXXXLLL.]>?&MZϣ^zΝ+\ʗ_~tR37|꼙2AP(7P( M(cP( M(cP( M(cP( M(cP( M(cP( M?^yV4IENDB`source/whitepapers/dataflow.png0000664000175000017500000006003112704114446015705 0ustar rgerrgerPNG  IHDR1sBITO pHYs IDATxy~B&mll444TUUǎ+)))..>dȐ:Nrss߽{~lذaՒ~ 'AK,y!@\\fx/_ vqKKKNE  /;wnժU555"""}nݻhYjUttvB|&3t:}III $&&6"͛7P(ӧOYAӧo߾ۻwʕ+m`ٲe‘^^^. cǎ!yiN ٳ/]$$$ĉ 񇘘M6!o>AAAv`3fdZnkkc0XQƒ "xuZTT4j(?jVOO=v}O_GiFGG ;vёk]fee͚5+;;֭[222X5.,,L$j s--- MxXjUbb3g,XLMM_|9}۷o3ݻIS ++[QQw݌ A\{{CbbKPrrrz捑۷oq & ZZZ9sFRR͛fff83|;w}` .xQii۷x$%%w%((XUUu)Á8 &iw ; Cssvl L ĻF-((cǎuu|ٳg֢`&]iii_bEGGcxܹsmmm}01@Ovڐ!C?nggO>>nJNNŪΝ;wnٲ]KKԩS'NĪ'!!(آ Ξ=֭[jjj)))o϶D"7""wa9ydǯY.lǛdr_41L ̙Kׯ[XXmdÇvJNNnii;q̙31,**}fb|= )**gK222W^ݲepVV֜9s(JHHȳgج]YYy!SSq%$$X<iii666ͻr pRccÇSB}}}}}}" ᡦ'@ >|={JJJ""""""444TUUǎ+))I& Ltz]]]^^^QQѧO"$$7a?S.\޾n:[[uٳG[[ s{⼼bbb>}֛ 6l8|&od2yӦM֭LOOOOOӣG=z7Y[[[YY 6;VUUUnnҥK^///8˗/ӦM+qС`L 4 Μ9s̙qqqUUUEEE555d2L&KHHQ(eeeޟvm۶999.^(//ٳS2 47t:5jTNNzƀK k`bfĈ4FΜ9>655]vmllDRTT.**rqqQVV޳gNǶ#II{]t)$$---544{UVV dV-뫧g``~AXv-:goo1cc~-//P(+VJNرCIIi֭m0&&H$>~DZ=AakkW ... CTTt˖-,kjjm6vXOO>`WAA#}}}_VIzQLL&O>r޼y ,Xhݲe\"%%ƺ0%%&{LMMefgϢT*@CCk@BqvvP(Z= #bo{ՙ͘1&MUT۶m̝;FꢥF5l02,((o"hoo xqb=z4F>}znn. ***'2P(1114׷oLJHȸ:~TjקQ]]TVVǏ&&&D@oUTTD| Vnnnr劭mII@PPPHIIa0.[,...55]@ $&&R(B122z葻;;GkkkNHfA Jpvv޲em?>]c`>ecTn:::twccc5gʕl(&&V__/!!hll쾰O[2색Ro۶MDDD߿oiiɲ?@X`mTTTÉ*I'O9r Ǝ",,ܫ,Y}v@TTH$%ӫtzyy9`С}01@å*Q/EEElh&XRU8:&& &;88zTg֯_秧G$:::?nTPPгg}O &cbĈUV )~lnnZ@,ck $$$ 2XA L a`˖-y `gW2"A(+UX3x|+W677#pTiii;v0.\ǩ|߾}C/@?+"ssW |kFEEihh|ݽ4==-8vYOC +xL į8qqq6l;({3%%%EGG777;::ZXXt}T>)))Ԍ Y/M*¨qŮc/h;XQ({N0ahhԤeaa|TL=T`b ~܌V[WLc{uVow|{zztDrssZ[[WZXx1̙397o;8Y^z(Jz׮]Η/_S_K%Nt{]^ϟ?x(~y%A ĩ_WWyqt{,c/ kp` L į8sss===kkkXkv{х6yѣL 4hiieggSxG m: AOxbbbxGA4x L:#//OSS( 0m4|z ( ;H;wA AL Ay  01@*//ݸqZ[[^UkX5a&E3f̸{իWa޼y=>|%KӔ@*0;|D"H$8Pmmmϟ'/^9s&^"''G^^'N+;gQBBBgΜYbNt.aTTT7.33f&]$ȑ#ׯoiiYhӧǏ Tjffرc  wvGGÇsׯ_{nڴiݓZ`b ^ٙ~PQQ:t@ yClذ5k͛7e&!s#zG={u1xꕎNll]n޼),,y/x‹/,--i4Ǐn'Ǐg>stt鮮/$AMˉ'>~LJH_C>|`oo?eʔ^VPPEBBĉO<===sssLҟ!k׮UUU=}4qCwK.}⅞ޗ/_֬Y^.**Uqqqcƌ166̔xÇ{aĀ |466>/&)(( 2dŋ)$LEN}… 9tP?*o`I ׯ_KJJ^~}/%$$xxxƍϟ*Do\@@`̙666...0?W''''''G  3%(-ZhѢ7n}N755CKJJRԹs|u׋ >f͚> 777@TT۷oߏn5 _+}  A\\\׭[L&RRRGۇY^PTBPSSCS(ggg rn ɓ'KKKYK\\܍7FD ddd6nG D &MBDVVӧOT*.++[VVGnw}oM?x!hx򥈈@tsc]]Ý z}iСn! e:طoAo >booҲjժs2KHH4hz=t:H$/_TWW;!LsFA|߿@EE%::%OOO\9 .IIII͞=;((ᡫʜ)cbbbiiyԩ_g0MMM x͛7℄N:%&&򪐐..AܨTjaaaCA'M87nܳgOۄ UUU۷(___Ánb۲e`llG8۷o3f; & L'Ng0+VWޠСC.]>~8d^ R_ ;^IIɦM=z4@+^L BBBIII999xAXjkkojjrqqYh@Px11NٹbŊVÁ ̄7.66X g<aaa^ںu+ޱ@6ݻw  2p gDDD;F"ɉ`& :::\\\-ã000X Wx:1'L۷ ]rr%%%O<ɬ3AѣGD;^xw8߿_~=cǎ; ^O CCõk׶Xp w:::-[foow8{|۷oWVV۹s'ޱ@Pggg+(( !~A\\ȑ#!<<իWxAzmH$ɓ'%%%`lljժ+V,qM}}cgg@&1v9v؜K@,--ֆU OaȐ!&aaa%%%xAr̙2"((w8 nnn--- p g?~\f &&fxAgk.yyGdo\|ymm+@P_bݲe H<~aøu}}__\\͛)aȐ!ZZZSN2e 7ÃC999}õN"""TUU{Czzzr-T_/_ιo>غu;{^tښL&|RQQӁAo9rDCC#;;[XXDFF;w-#""ࠪJR%%%%$$;ׯ_tٳgh4N  xwN1cFFF@;Fӿ^YYQFȌ9r.\}Bh_mmm D"mڴȨWê.]jii,]pz6x˿+##8x ޱ𙖖7o)** @ 666IIIx΋|^Q8p*))B4UUUi[@@0v`'Ŀ;1  GcO RRRgΜ}3 ))3up8{%K$%% n=<<?ܺu6{ܹ 6|MHHhAAA"""o6##ݽD"Y&""s_ߒMGxJYY1lŋgԩS\^W:nggw5QQѿkΜ9A$1.\fiiyʕKKKك ȁ8VM׮]01|ӧ'$$`w.++{Akkk gBC}}='{򥺺:!;;{Μ9555sZjd0֭JIIŰ*+++  ^ O IDATX7iiiǻn155EpHfX %]v PZZȑ#(ZPP```:^ .sz[,9CId2`kkڊUlHGb/_=### ?83GllƍMMMeee'L0aݻwwvvZ[[ş9Jʊ =x`II\ b@t钝]KKKbb".رcD``[CC9ի6|wwwޙ csX[[#ѡ}==˗/s&55=$$$&&ߙ瞞III~~~8Fq@K rrr{[.(($77wڴi?VTT|{ϟ )&&`9rx666m G;Tbhmm-,,9r$Bf4í[ >LrrrDDDɓ;wXXX[)BeeQYYΞ=0 nPWWdMMaÆYYY,$9P=zUPPpÇ;2yd͛7 (p\Ἢjƌ>Dס%dLLfmm/vg yݻ0^|˲޽{MLLг@lg̱ٵ h`?; Ā2M6XH.^h``PVVB}#&&vUKK3f ѣg .HݻwѢLۇy Gh}Xc>}: ++ }߆p&C޳f͢ƪ*ȑ#>aݺu\#&&n޼ܹsWzNN΢Ettt8dFFի߽{'))y &II{͜9} K''H#GL8?<<ۧNRRR¼jww4@@@wjChii655iiiQ({xxs;w5557o;7544\~===ʕ+/>󠴴4+Wږ'O/[,...55uʕHP ѣGׯS̟?ǎtͦӧG%1SW2 [JJJ7nܸroݺE$eddF_2߿~krrr^^^+𿺄`b`K]]1 h")))6W^mذݧ-666--M[[;** p&(( s z̙TڵkcccH$'&&&-H$:}[^]FY.W b!A B(eeׯX*G1Kj?~sH0??s01r%A;`b` HSEE^]xDjjjTT#Gp\h Ad㣃xG|s `Mt޽{?~CW\ ;{w ؃w}}ժUdځ@ .Z͛7ゥj[ KKk׮)**YÇx fffϸqBCCyL KFFfذah #˜ T'7_!!!t-:۰aFy&:&"m۶N8˗K^^XSSΝ;at:=<<\YYyϞ=---8ƃ!>N ;??#Gfdd̙3GMMѣ7@P,--ǍrginyUVVh9-<<<++|ڴiiii锛 ZOаzw ^t)$$%K ;HljaaaW^;6<<|,>[l?~u8˗/JJJ^^^_x1wf{M2ٳ N<ԩS\kBիFFFFFFW^k%+VXZZa]O]]].\з`0|}} |}}oW;81+))͘1CMM9d+WvPիW2:-V/@UTTYJ700^nӧkjj8[2'zAEE%11o :::U7K-###HpW<8}4*I=dF(**zݧO***jjjY\\]]Y a+&&H$wF \vN=^^^_qOOOOЏ۪NNNu"[Fի5/^n޼yG~YvGhmOOO۷ݻ7!!!99ٳ.]}vDDDNOOYweqN˗wGillDmm7QE7pB+++333ccc}}SNtΪSWW>|Q~$ӧOѲοwڴiuuuㆆ1G~ 111v!۷S=a߾}^q@c8}t@={˗;;; ++[VVGtQTT4cƌ'O 3k֬5΄&xڴi eر#FXПkk뢢"J jjj.]p¹sN>}ĉcǎ>|8>>>66600guF}Z6CrrCbbbЕ銋 ~#L4Aʕ+Tjllb&>(>>>4$|Դ#K T*u„ Æ 2dP>zNbR]22X|;z1K#1W%K3/p!r͛7o*))^zŊL&chu_.k"H[n D"Q__Ν[ikkk.jjjߛ'}6o޼>200055b/FM .\ sAAAfyKhhѣO1y!CdffR[[[[[[kkkCCAj񾾾˗/?{,=ףGBUWR;lO"1y<&;m4>-[ =]:^^^`3}8zyysp3((@\\\LL Z[[QQQOe_9YϞ=}ԩ>>>666AAA c$i޼y=iooOLLvDD)Fm/& ,uT))),o GKagTj*I&B2|Yaʔ)~~~666dɒ۷БHuuu_,N,{>e^$*ZXX}!$ o߾3g444..[555,oonnYSMMMGGǩ Sٳ}uΉ:]ݻ%+ڵ2Ϛ5 M ]d/^ow'O]sss___#!!=+mݺښY:66fff۷o¶Q__ϲ(Y\~Hcޔᡫ~3۳|;ɲs/Ba:P%++ӧFXV#\w7Lqwcǎ믿~_c|Ex񹦦ռѣG'%%\AAػ2|>#|9 eeeQ3]BBBNNN/_[߮1(ˏ]ph^|+:~SN@ٹ`hhgw_zghhn3gNJJ zAWWݡ_ϰs}}=HWWݻ=և55)D󳳳{܍}S_1{b;…V*:t/t4}||~3Çћ qF115% ݡW._JHH\ˋy&XwMzZ1cBBB) NHH4iRDDD~Tee޽{7oތ207L##^u>0@Xx]g>k}} 5KtL]] lFZr%׎fo1mEj1 ƶ %'';88 3cbb\]]1N|;aPv%uvv&$$0jhh(Ϟ=;eʔHLFK}}:MMMG ݡ=zcooϹ{kvv2m<ׯ_/..y ox=zмܓH$<==Ybr˗?~>|xxx@:Z111qpp5{n@nngmma@Y&~C/tJY>2\[H?ԯw/`5N8P`,Գ~իW矿ȧw`KKK+;;- &⬀7{@ @())qssCײNII)++:wTiii;v0.\ @ $&&R(  ^b~4 sxgk"[vmסt fcǎ1Κ5>΍0} ..R,胮Û,#c8 ^e_RRRtttssEק=N8߉a̘1h@+rˬ=CCæ&--- ---' ߉CA 뒒田ܺu;.66͍D")**8qe/77uժUŋ3Μ9L =)BPSTTMq/__ }<5]``b4***-[?'B{v/AĀM [tiEEށpչslmmydD^^.̡$@׺33)St?c`؁ Fdddhh(:_6{sIKKOLL011 e}.R(ԴӧOK,aهe_ߦ A@+X]]mee4"33SVVΝ;:::xEqF޹s~>zF3W ŀ:cζށCGGӧ왞ީS,--mll>|(..~ xGA<A6hjԨQK.޵k7{~𡂂Çy0+@ĎpPWW:E@ ;IDEEO:ERCBB6oޜsq111N{vCCÿ{ȑqKLL400`W /6!!!lsI /!S__߷72$55H$v633}Tmm-F HR+ߏvppWLIIիѩ|}}=MSS311qv5 CǏ/**¶~twh#}^z]OXB/_pCCCCCĻwfdddggׯ?~GIIIHKKȌ?RNN qBLcǎɡh۷o߸q#1;GMMͨQ}joo[11{\f!~Xf^zE$EDD~w,0k0kiNNNhgk0pO>nݺ8c0^v;577tttsoܸqڵÇYf޽p:Pқ7o(w{ kЃccc.۞={: ***T*URRL& 666ս~ʕ+hiz!!!{{{??'r-r tĉUVk|&L ׯjkk>i&Á;v;88KJJ!88 /|ܸqǏ;G} @PΝ;ږ.] #nj{nc>3/_7PEEp ddd N4 p a׮]---0+@CC 6;;;jjjAP?={LOOALx 2@HKK;_]]M`VԩS#""\\\?.&&wD3H$8hiixبXUU1sL\ƒkkk~ņ ݋w83+)!!f %'' effCss3IHHޱ@Pihh3+V466Ç+**tttfϞw,)SX ZZZ{4` &'' ߽{p 'G~UKKkΜ9xAQSS Cյp ?x:1ܹB ܔ ___mm2^x!ACRRRyyy0& ,""x֭/UVVzxx0 b9M 푑.@jxx8 nnnuuu߾}16h0pĉ2*k՜ C7n///߸q#ȑ#R\C/M ;v<$DJJJKJJz*D=uUTTlmm8k„ ۶m\ܹs 01@x;tvv ]h0X~}ZZZffʕ+>놆:Nڤd"b/&gϾyfK.;˗.BKl&A>}񋝉Dɓi4/~@_  $HxAc0۷ou&C}QFFf ߿}/_}vl>4DL2hSRRjoo;"⠯_bD"޶rrr^^^ VSScg|D_\b7n 11p 򌍍޾}-O}hF`۷RUU}9V-C|~WUU]r%JE:99fdd ]Ҁ: 'Nh]{ iii VUUvZB+WHHH?48/z3J-,,{ɰattt Ǐggw444om&LxZ" bk׮٥nܸAkk#G >Cl޼y^zHk.N4CNzu@PЧ  ǏGhhh ]&O%=y򄽔A͛7WXuV@Nׯ_888p@>;n8?>_<&tzyy9`С"HꪫtĊ=5LMMo߾* p˗s_ss[n͛7/%%N c @ؼy3bСCxG &III={l߾}]]]4OLLL,---[foo h0`0W>|ӧ.\i4ZFFŋΝ&..mD"?|0+͑B0Z[[۲ebbb7n+YYYAMM V͢CI$ 9`%u[ZZZ-ZtiIIɛ7oΞ=HTjffرc>|8cƌ*"wAM\] AAkJ)"OZ@ /_{ǎ\.W Ab@Mmڴ)--MSSDI vރn @ d2VrD H$?z(a'NعsR{Oן;w({uK.UTTddd1((޽{ #99yƍJ}SWWw!$݂ JJJ***wܩ/^ܴi744LKK[`bfff*+x5}vib[0''''''ggj66k֬'ORMhPM%ɸ|3®njjj#/_,**:uꔗ{(:u;HS>ŋ+W8pdgKKK 㥥8bE"<#SIpZZl/\Q\\\\\Ld2'Md2uuuۅB!ooo'?aؼy󼽽###544(rimm-++[z5B!4f9s搷R'L`ddR/& 1@Wy{{{{{\v555/^ kkk̙3fŊ {GI.]n:PbbիW>|hgg'H܀K344,-- F@bƎO >/BaOOq&NHmÓE^p֭[y<^ppiZZ&!BBB0 c0)))TN[!DbeeEu$ Ba)2ٍ7BtxQ2 uCUUqϜ9̌@OSRөpgϞmnnuYfQ"ilc^vvvEEExx~Hu,*bBBBx<^vveFSznt钉IhhhMMR222rss),,T@oH$zŊ#P"ڵy׮]ĚȕxH Ԍ---.]z]%5~w߿<9oRX,rBe0<$=,] !x^^]fffoo2322!6qFooa(q@0=deeݻxgϞ .GK ll6q$Y/D0`@a?nooO.7+++ سgODDDppq8VeeBڵÃK"""n߾=!"##l̙g@{DXL+1mbbb ð{xx XN+Vhkk5XBB–-[B6lPYQ;;իWgddHlll<|pHHȶmۦN:Q:::pC[XX~0x<ޕ+W;6$Ill$Cnnnrr$rH$֖id |-Z"*Qb p?zhWWWWWH$"}(xGGw}4H{ !YHFDDDDDH r233KKK ۽{sJ~{QбcVZEg0B}PԄ0aBhx2~Y]ٳIII\.ŋ88;;83$KKJGGGGGG''* P+++7XDuՑ0eʔDHn#*sXYY@}ⲲփO pwpS1݀)Բ2ir$64FI%j Î92tD36l8|0Œgz#GSL6m%/^^^^111PSI{{{M d}@g%jgxfϞ} (i,uPWWw;viD}ƍjcc耀'F}}}Q*(( ^ٳʊxի*6P723ÅBAwwMB+W$=<b$G2(\UUUHHQ xO'HO(Oss3]& 1@?۶mrrr谱aaasΝ0atCi̙3TG!/ccc osss+**w[|!~z/_yo83 ޑ$fffO<: 4fkk믿RmF 1x$o 7:$I`` Q J(R 1jU2*){D+[P/D͛7߾}Ȉp@ @l0 THWd2P+ 駟&&&URR2u۷oϜ9`gԋ;w\\\͛G2---%%%fffŐP;ǏyE?VZZ͛WQQaiiY\\S`v/aܹ֭D!!!uvuuܹӳѣG$hCOOٳ۷oojj^o|>ȑ#ӦM3fLLḼ[ 3#J~|~TTTJJ cƌqww]d[?֖sMH244ɱU~ 1@W555.\ +ikkϙ3g֬YzzzL&d;]( gϞ=p8}͟?o$譽=///''Ν;mmmomd2}}}L@b`hii~qggP( ===L&sܸql60#j?wwZNIENDB`source/whitepapers/syslog_parsing.rst0000664000175000017500000003244712704114446017205 0ustar rgerrgersyslog parsing in rsyslog ========================= *Written by* `Rainer Gerhards `_ *(2008-09-23)* **We regularly receive messages asking why** `rsyslog `_ **parses this or that message incorrectly.** Of course, it turns out that rsyslog does the right thing, but the message sender does not. And also of course, this is not even of the slightest help to the end user experiencing the problem ;). So I thought I write this paper. It describes the problem source and shows potential solutions (aha!). Syslog Standardization ---------------------- The syslog protocol has not been standardized until relatively recently.The first document "smelling" a bit like a standard is :rfc:`3164`, which dates back to August 2001. The problem is that this document is no real standard. It has assigned "informational" status by the `IETF `_ which means it provides some hopefully useful information but does not demand anything. It is impossible to "comply" to an informational document. This, of course, doesn't stop marketing guys from telling they comply to RFC3164 and it also does not stop some techs to tell you "this and that does not comply to RFC3164, so it is 's fault". Then, there is :rfc:`3195`, which is a real standard. In it's section 3 it makes (a somewhat questionable) reference to (informational) RFC 3164 which may be interpreted in a way that RFC3195 standardizes the format layed out in RFC 3164 by virtue of referencing them. So RFC3195 seems to extend its standardization domain to the concepts layed out in RFC 3164 (which is why I tend to find that refrence questionable). In that sense, RFC3195 standardizes the format informationally described in RFC3164, Section 4. But it demands it only for the scope of RFC3195, which is syslog over BEEP - and NOT syslog over UDP. So one may argue whether or not the RFC3164 format could be considered a standard for any non-BEEP (including UDP) syslog, too. In the strict view I tend to have, it does not. Refering to the RFC3195 context usually does not help, because there are virtually no RFC3195 implementations available (at this time, I would consider this RFC a failure). Now let's for a short moment assume that RFC3195 would somehow be able to demand RFC3164 format for non-BEEP syslog. So we could use RFC3164 format as a standard. But does that really help? Let's cite RFC 3164, right at the begining of section 4 (actually, this is the first sentence): :: The payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message. Think a bit about it: this means that whatever is send to port 514 must be considered a valid syslog message. No format at all is demanded. So if "this is junk" is sent to UDP port 514 - voila, we have a valid message (interestingly, it is no longer a syslog message if it is sent to port 515 ;)). You may now argue that I am overdoing. So let's cite RFC 3164, Section 5.4, Example 2: Example 2 Use the BFG! While this is a valid message, it has extraordinarily little useful information. As you can see, RFC3164 explicitely states that no format at all is required. Now a side-note is due: all of this does not mean that the RFC3164 authors did not know what they were doing. No, right the contrary is true: RFC3164 mission is to describe what has been seen in practice as syslog messages and the conclusion is quite right that there is no common understanding on the message format. This is also the reason why RFC3164 is an informational document: it provides useful information, but does not precisely specify anything. After all of this bashing, I now have to admit that RFC3164 has some format recommendations layed out in section 4. The format described has quite some value in it and implementors recently try to follow it. This format is usually meant when someone tells you that a software is "RFC3164 compliant" or expects "RFC3164 compliant messages". I also have to admit that rsyslog also uses this format and, in the sense outlined here, expects messages received to be "RFC3164 compliant" (knowingly that such a beast does not exist - I am simply lying here ;)). Please note that there is some relief of the situation in reach. There is a new normative syslog RFC series upcoming, and it specifies a standard message format. At the time of this writing, the main documents are sitting in the RFC editor queue waiting for a transport mapping to be completed. I personally expect them to be assigned RFC numbers in 2009. Update: the numbers are now assigned and the base RFC is :rfc:`5424`. Practical Format Requirements ----------------------------- From a practical point of view, the message format expected (and generated by default in legacy mode) is: :: TIMESTAMP SP HOST SP TAG MSG(Freetext) SP is the ASCII "space" character and the definition of the rest of the fields can be taken from RFC3164. Please note that there also is a lot of confusion on what syntax and semantics the TAG actually has. This format is called "legacy syslog" because it is not well specified (as you know by now) and has been "inherited from the real world". Rsyslog offers two parsers: one for the upcoming RFC series and one for legacy format. We concentrate on the later. That parser applies some logic to detect missing hostnames, is able to handle various ways the TIMESTAMP is typically malformed. In short it applies a lot of guesswork in trying to figure out what a message really means. I am sure the guessing algorithm can be improved, and I am always trying that when I see new malformed messages (and there is an ample set of them...). However, this finds its limits where it is not possible to differentiate between two entities which could be either. For example, look at this message: :: <144>Tue Sep 23 11:40:01 taghost sample message Does it contain a hostname? Mabye. The value "taghost" is a valid hostname. Of course, it is also a valid tag. If it is a hostname, the tag's value is "sample" and the msg value is "message". Or is the hostname missing, the tag is "taghost" and msg is "sample message"? As a human, I tend to say the later interpretation is correct. But that's hard to tell the message parser (and, no, I do not intend to apply artificial intelligence just to guess what the hostname value is...). One approach is to configure the parser so that it never expects hostnames. This becomes problematic if you receive messages from multiple devices. Over time, I may implement parser conditionals, but this is not yet available and I am not really sure if it is needed comlexity... Things like this, happen. Even more scary formats happen in practice. Even from mainstream vendors. For example, I was just asked about this message (which, btw, finally made me write this article here): :: "<130> [ERROR] iapp_socket_task.c 399: iappSocketTask: iappRecvPkt returned error" If you compare it with the format RFC3164 "suggests", you'll quickly notice that the message is "a bit" malformed. Actually, even my human intelligence is not sufficient to guess if there is a TAG or not (is "[ERROR]" a tag or part of the message). I may not be the smartest guy, but don't expect me to program a parser that is smarter than me. To the best of my konwledge, these vendor's device's syslog format can be configured, so it would proabably be a good idea to include a (sufficiently well-formed) timestamp, the sending hostname and (maybe?) a tag to make this message well parseable. I will also once again take this sample and see if we can apply some guesswork. For example, "[" can not be part of a well-formed TIMESTAMP, so logic can conclude there is not TIMESTAMP. Also, "[" can not be used inside a valid hostname, so logic can conclude that the message contains no hostname. Even if I implement this logic (which I will probably do), this is a partial solution: it is impossible to guess if there is a tag or not (honestly!). And, even worse, it is a solution only for those set of messages that can be handled by the logic described. Now consider this hypothetical message: :: "<130> [ERROR] host.example.net 2008-09-23 11-40-22 PST iapp_socket_task.c 399: iappSocketTask: iappRecvPkt returned error" Obviously, it requires additional guesswork. If we iterate over all the cases, we can very quickly see that it is impossible to guess everything correct. In the example above we can not even surely tell if PST should be a timezone or some other message property. A potential solution is to generate a parser-table based parser, but this requires considerable effort and also has quite some runtime overhead. I try to avoid this for now (but I may do it, especially if someone sponsors this work ;)). Side-note: if you want to be a bit scared about potential formats, you may want to have a look at my paper "`On the Nature of Syslog Data `_\ ". Work-Around ----------- **The number one work-around is to configure your devices so that they emit (sufficiently) well-formed messages.** You should by now know what these look like. If that cure is not available, there are some things you can do in rsyslog to handle the situation. First of all, be sure to read about :doc:`rsyslog.conf format <../configuration/basic_structure>` and the :doc:`property replacer <../configuration/property_replacer>` specifically. You need to understand that everything is configured in rsyslog. And that the message is parsed into properties. There are also properties available which do not stem back directly to parsing. Most importantly, %fromhost% property holds the name of the system rsyslog received the message from. In non-relay cases, this can be used instead of hostname. In relay cases, there is no cure other than to either fix the orginal sender or at least one of the relays in front of the rsyslog instance in question. Similarly, you can use %timegenerated% instead of %timereported%. Timegenerated is the time the message hit rsyslog for the first time. For non-relayed, locally connected peers, Timegenerated should be a very close approximation of the actual time a message was formed at the sender (depending, of course, on potential internal queueing inside the sender). Also, you may use the %rawmsg% property together with the several extraction modes the property replacer supports. Rawmsg contains the message as it is received from the remote peer. In a sense, you can implement a post-parser with this method. To use these properties, you need to define your own templates and assign them. Details can be found in the above-quoted documentation. Just let's do a quick example. Let's say you have the horrible message shown above and can not fix the sending device for some good reason. In rsyslog.conf, you used to say: :: *.* /var/log/somefile Of course, things do not work out well with that ill-formed message. So you decide to dump the rawmsg to the file and pull the remote host and time of message generation from rsyslog's internal properties (which, btw, is clever, because otherwise there is no indication of these two properties...). So you need to define a template for that and make sure the template is used with your file logging action. This is how it may look: :: $template, MalfromedMsgFormater,"%timegenerated% %fromhost% %rawmsg:::drop-last-lf%\n" *.* /var/log/somefile;MalformedMsgFormatter This will make your log much nicer, but not look perfect. Experiment a bit with the available properties and replacer extraction options to fine-tune it to your needs. The Ultimate Solution... ------------------------ Is available with rsyslog 5.3.4 and above. Here, we can define so-called custom parsers. These are plugin modules, written in C and adapted to a specific message format need. The big plus of custom parsers is that they offer excellent performance and unlimited possibilities - far better than any work-around could do. Custom parsers can be `bound to specific rule sets `_ (and thus listening) ports with relative ease. The only con is that they must be written. However, if you are lucky, a parser for your device may already exist. If not, you can opt to write it yourself, what is not too hard if you know some C. Alternatively, Adiscon can program one for you as part of the `rsyslog professional services offering `_. In any case, you should seriously consider custom parsers as an alternative if you can not reconfigure your device to send decent message format. Wrap-Up ------- Syslog message format is not sufficiently standardized. There exists a weak "standard" format, which is used by a good number of implementations. However, there exist many others, including mainstream vendor implementations, which have a (sometimes horribly) different format. Rsyslog tries to deal with anomalies but can not guess right in all instances. If possible, the sender should be configured to submit well-formed messages. If that is not possible, you can work around these issues with rsyslog's property replacer and template system. Or you can use a suitable message parser or write one for your needs. I hope this is a useful guide. You may also have a look at the `rsyslog troubleshooting guide `_ for further help and places where to ask questions. source/whitepapers/direct_queue_directq.png0000664000175000017500000002353312704114446020303 0ustar rgerrgerPNG  IHDRVsBITO pHYs IDATxwxTU?N @ @D HQ.bE몈(K}AIOwEt $HH!qycL=33wrs>O<3wN͝9s="pwwͭRۑŨ. U8 !BBQH\?Ԏ;X,Zׄ@wT9~g-,q!)R*~CҎo^;!B69V2:7 @Qb47:Wģ$`0ߐeEitb3'3y;ہ,vGs.`xwoP(D{k K~_{GkMi:F;`֋Eg_s*N]Q&VaV|ItB"BFGdĦ.KL[, (/ŗNZ!CY(-?bALAS4W+Z'; oNWùy{Nr2`8G9ꍷ&'C7$- IO\՞/J_65;!5$ƯїMhz2]RU~3y/`(6e4i!9IH %O/yzҴ)IH燿?YkΣ@g:;-}fQ. ⭒>y0hGԫ(toC" ,, iXОАpΥK,]…'.&M$4bJʅvc^xIpHq`& ЄlЪ%qI\ &TU!%jEjZїydcp 6owȑ~mڴǏ߸qaRRRzq{ܹs1117n|g/_ܩS7iiiڵ۴iӤI222ڴiyӧggg7oӧ{k׮z뭻K{kjJK /qcq?_:J&NځWQ.6aaaO<ĠAFٿz=} [kԨQV{7$$Fݺu]vPPPttt=֭[jը*Ul2666,,ãQFݺu B6h֭[k޽{Æ 322wqժU;8w\\\ddS,KϞ=###;۫Wgff722r׮]ׯ_0`@ddmۮ\2x;!'jg"^ns jCR P<K˒%-nde?DTG@'t)$$0p;1ѩD P<4Yýjb W+]E隨2&;hC+\#^ִnLIL&;7 tĦx>y;Vƶ& MHZ\r#Ů,PBo#-XjQGHr=< gI_O~3xpa \’ PQ2#'[ͯp~n͞| $2ȸOhM/ˆ3T={2wG XJP+"#$xըH\ZArod_օ.թ}7Qz@$BГma@q X֍n3і@g:OfM:gJڌb1Hېje֡N[juLf&#FZIbyh"Ϳl |">%j'w$$!Zy {NhJdIqb:-4$#E|kF}';s~9ˁY$bZB`ƍ̚7]ra_ӢSHR 391s \jW:dU<s*Zq4ӧe&O'Ml# *$,. iL(5^LhMntSfNkW&LIxa~ ,B6{iww~ $3]ba5@6јc_{Ԥ|}믓 /ȷ&51̊>qXd 1 iLO4:HT۔u7.R\e^Sǜ. 䱌L~k#2 BbkL+\Y*cSE1.@o߾ez{{m־P_g > ɯ7BrS>2MNNoU^u-ZhaMJJ_lջlٲw[Sm?j]YkmC-|=Dj__߉'fϝ;ʟ؂O4isWoRRg}VfFҷoÇW… WZU𸸸gywOk.`~(S%NwuWYOʋ sW~իLӳp![Q%: 3X͛$$N^:څ.c&6xucf=5JVnw87EǎԨc^e#<ta}׸VuZ/F㒴Jlo/ѶcDGS "+e(tD{[jKZ$Fg̘?#}p]^S*i9_rp:ժQ iix@F%.U%ӧ$+(7 bcϸ#mfsLbѱTxBOݶ"y4SR )- c١wTfR::S֮MrrOsn m[|mY %13Ҳƌ3&Z},E)oJa;s(W ̬̎u@镑{yU7FVY HO- ,TRZwo Xps_ѧn!_B|KLYf!%tV@hVSB`/|[3y2OOz4nꓨc\plMi-wsF}eK.9S13?fe˖b˖L5d%Ϗm.]Gsj%r=0*7or^^6J[Цu# 7+SifLĐ!6*{*EWx%0:ıcX4i#W`+[uMx13t퟊"Xt zSu 9}~}I8|YF d۪s) jiE s+5e.'4lNr2zNѨECpZa@ Vz>֙Q8wE]0W &[\lΟ(0e K@(`tmkrlS&J ǥV+]dgc^1h5` .v#FR)u //{KL0pkBQ:.nChR8|lZ\Z@8EBInG~'|*SNpp nP` +{{S8gt 8r,%.vjP`8+d7QTb22ZqQ $3n~AO~zݺukk- Q#9afݼYժ+7o\b^1TB:u=-_|s ߿ɒI%d?oΟ?…#G,wŰaÆ~)((ݽffyrK׮] Qm|yK96JNN~G2o޼?IGۣKO֌fy䥐"Yju*ĸq㒋.JxxxKPf_ N޷==";\<<8{_fbn޼FDDHmW6ٹzH{M4ԩdEA?.`ԨQN?\K',|, 0^z2-A֑/ƍSO͞=k5kұ#OԪ/99p!Sp:u0ęwڵ$;l%J*@\\,_X<2|'Tֽ{la6S!>s2%;ZWL0!A68՚[O?ͼy '2e w{yiƌ, `u̢UaqʃShL5tfh j}t{D '/%ر`YcDPI8U4*yw{$KV Oi-kWFL{~&$".,g-X|S]I RPj/=TY;KpQp'wv˒%k 9*f)eRq6GFr=g,_aC( ux!Svyy7/|pܸ2ׯ:sի價,8ũ,ϥ$@G p2J@/Y%KN>ݭ[rW2==?ah|u >$S2qю@:6\Zu8VsHTу!T{$d~ӜM %$@G\#IfU['` -B=hs{O?$_I !'N`mRքn;!]-x"?CJt]@ i]SL`CyE7vXTR '2* WtVkD.9$Fn >57\r3k\{̮$@G\tUSaS˹Q媕첉/8Nj}C>,* Wt~@S`G"^M'XP%:.:opc CjU G` аhJ7|sCf4&B}ӥ$@Gw:]&iW ];MiL"XoHC`Np>GL2 Qƻ+~ jAMj֡6]gz˙~t|09G82kK/s@ NT1~p6>9 Ԥf]^D&|Jh?93ڂh%w~8On/=i 8P)*  \pC<)ncG|4Y6xwc~p,cڄ9$0BpkJӒ Q#NmT% Z|GiK@$Hbxa,9$@æX@Q;YÁmh%B@m#z0 (J.tÁLejeB`(XU\PjE7Iw;60ZGp Jtą\0Q(9ē<)0(. Y*8iR0h>;#`,vcXAei p'Nn[(`,4^I)jժYYY匰$!v`kG@aYR.X\թM#oOt)YZW ,:G@0~paL{_ T莀}gIc1`vW 9iIKɒVbQ[`EA'%Fa=2._5Hb #~0=8h+M H8p8z sIf*P1 phTt p@*"HQ9]@'?)@ VD `k#:0hȷ[@ED)!o=BTD `+(`,.:A&؄upTG(TG@Q0h PcQÁRCEAEQp[Q.2 %6!rl pww]vjlG K&TNԩSF }-9$U={֨TGX5kv},9$@qÁ:b'` pEAP.XpE Cl [ \( $:j8X05 C\#:Jt @ō(Gw 00wQP 5(9$@qSC L r08zv}(`,Hao((rRTNfV jUGX . *\[Q+jjfW@cQ5;Zy dS#Ha pفP#j8P sH\/gG/"$@G0x={8t0sH@gq1p0A,is_#ʟ#*1 pf[[v~F}ȇZ6eT#Ha /! KK\(=$x Q@* 0hr,X169+Ǿ4lͫ$@G `w,qMvc8/b>_?$@G P_2O<1m cl VC9㿊U-iiG!JtD)$v! Y |1%-V2o:7/%:\搀ߏ~;ٔG9CP`G"6SjLHGP#Hao[9˝ܹ}SW|Յ.59kY[“\Ū)LN{w s11 N@x7}ʧYNcR MvAEO'yr cB)Jt W %t*S'3k1uӚDwk,tkJt w :sH#wm(CL'݊Պ@uNCI( 9$ qL`$@GEA)!=|rRC4LrrRC*z( 08nW^uh-Jt W.][r>fI&۷CAA؁1üW^y%%%%>>^I@8!~(%:b>6Ж$a@%((J*qj7!ITG@Q0(q.( \H$¡\ 1 X,J\% yyyY$@uE.9c POV rT[Q.@Q\(Ha pJ*Ha& PEA :TU؊C[Έ#ׯ*P+NM߆o8n0 sH3f@I8[,K^^B/ ୷ҥRx75jJ޽۵kgt eiiiJɿl^^^nݲZҫP(dp 8qbE p P(.;#IENDB`source/whitepapers/queues_analogy.rst0000664000175000017500000004612613223143453017157 0ustar rgerrgerTurning Lanes and Rsyslog Queues ================================ If there is a single object absolutely vital to understanding the way rsyslog works, this object is queues. Queues offer a variety of services, including support for multithreading. While there is elaborate in-depth documentation on the ins and outs of :doc:`rsyslog queues <../concepts/queues>`, some of the concepts are hard to grasp even for experienced people. I think this is because rsyslog uses a very high layer of abstraction which includes things that look quite unnatural, like queues that do **not** actually queue... With this document, I take a different approach: I will not describe every specific detail of queue operation but hope to be able to provide the core idea of how queues are used in rsyslog by using an analogy. I will compare the rsyslog data flow with real-life traffic flowing at an intersection. But first let's set the stage for the rsyslog part. The graphic below describes the data flow inside rsyslog: .. figure:: dataflow.png :align: center :alt: rsyslog data flow rsyslog data flow Note that there is a `video tutorial `_ available on the data flow. It is not perfect, but may aid in understanding this picture. For our needs, the important fact to know is that messages enter rsyslog on "the left side" (for example, via UDP), are preprocessed, put into the so-called main queue, taken off that queue, filtered and are placed into one or several action queues (depending on filter results). They leave rsyslog on "the right side" where output modules (like the file or database writer) consume them. So there are always **two** stages where a message (conceptually) is queued - first in the main queue and later on in *n* action specific queues (with *n* being the number of actions that the message in question needs to be processed by, what is being decided by the "Filter Engine"). As such, a message will be in at least two queues during its lifetime (with the exception of messages being discarded by the queue itself, but for the purpose of this document, we will ignore that possibility). Also, it is vitally important to understand that **each** action has a queue sitting in front of it. If you have dug into the details of rsyslog configuration, you have probably seen that a queue mode can be set for each action. And the default queue mode is the so-called "direct mode", in which "the queue does not actually enqueue data". That sounds silly, but is not. It is an important abstraction that helps keep the code clean. To understand this, we first need to look at who is the active component. In our data flow, the active part always sits to the left of the object. For example, the "Preprocessor" is being called by the inputs and calls itself into the main message queue. That is, the queue receiver is called, it is passive. One might think that the "Parser & Filter Engine" is an active component that actively pulls messages from the queue. This is wrong! Actually, it is the queue that has a pool of worker threads, and these workers pull data from the queue and then call the passively waiting Parser and Filter Engine with those messages. So the main message queue is the active part, the Parser and Filter Engine is passive. Let's now try an analogy analogy for this part: Think about a TV show. The show is produced in some TV studio, from there sent (actively) to a radio tower. The radio tower passively receives from the studio and then actively sends out a signal, which is passively received by your TV set. In our simplified view, we have the following picture: .. figure:: queue_analogy_tv.png :align: center :alt: rsyslog queues and TV analogy rsyslog queues and TV analogy The lower part of the picture lists the equivalent rsyslog entities, in an abstracted way. Every queue has a producer (in the above sample the input) and a consumer (in the above sample the Parser and Filter Engine). Their active and passive functions are equivalent to the TV entities that are listed on top of the rsyslog entity. For example, a rsyslog consumer can never actively initiate reception of a message in the same way a TV set cannot actively "initiate" a TV show - both can only "handle" (display or process) what is sent to them. Now let's look at the action queues: here, the active part, the producer, is the Parser and Filter Engine. The passive part is the Action Processor. The latter does any processing that is necessary to call the output plugin, in particular it processes the template to create the plugin calling parameters (either a string or vector of arguments). From the action queue's point of view, Action Processor and Output form a single entity. Again, the TV set analogy holds. The Output **does not** actively ask the queue for data, but rather passively waits until the queue itself pushes some data to it. Armed with this knowledge, we can now look at the way action queue modes work. My analogy here is a junction, as shown below (note that the colors in the pictures below are **not** related to the colors in the pictures above!): .. figure:: direct_queue0.png :align: center :alt: This is a very simple real-life traffic case: one road joins another. We look at traffic on the straight road, here shown by blue and green arrows. Traffic in the opposing direction is shown in blue. Traffic flows without any delays as long as nobody takes turns. To be more precise, if the opposing traffic takes a (right) turn, traffic still continues to flow without delay. However, if a car in the red traffic flow intends to do a (left, then) turn, the situation changes: .. figure:: direct_queue1.png :align: center :alt: The turning car is represented by the green arrow. It cannot turn unless there is a gap in the "blue traffic stream". And as this car blocks the roadway, the remaining traffic (now shown in red, which should indicate the block condition), must wait until the "green" car has made its turn. So a queue will build up on that lane, waiting for the turn to be completed. Note that in the examples below I do not care that much about the properties of the opposing traffic. That is, because its structure is not really important for what I intend to show. Think about the blue arrow as being a traffic stream that most of the time blocks left-turners, but from time to time has a gap that is sufficiently large for a left-turn to complete. Our road network designers know that this may be unfortunate, and for more important roads and junctions, they came up with the concept of turning lanes: .. figure:: direct_queue2.png :align: center :alt: Now, the car taking the turn can wait in a special area, the turning lane. As such, the "straight" traffic is no longer blocked and can flow in parallel to the turning lane (indicated by a now-green-again arrow). However, the turning lane offers only finite space. So if too many cars intend to take a left turn, and there is no gap in the "blue" traffic, we end up with this well-known situation: .. figure:: direct_queue3.png :align: center :alt: The turning lane is now filled up, resulting in a tailback of cars intending to left turn on the main driving lane. The end result is that "straight" traffic is again being blocked, just as in our initial problem case without the turning lane. In essence, the turning lane has provided some relief, but only for a limited amount of cars. Street system designers now try to weight cost vs. benefit and create (costly) turning lanes that are sufficiently large to prevent traffic jams in most, but not all cases. **Now let's dig a bit into the mathematical properties of turning lanes.** We assume that cars all have the same length. So, units of cars, the length is always one (which is nice, as we don't need to care about that factor any longer ;)). A turning lane has finite capacity of *n* cars. As long as the number of cars wanting to take a turn is less than or equal to *n*, "straight traffic" is not blocked (or the other way round, traffic is blocked if at least *n + 1* cars want to take a turn!). We can now find an optimal value for *n*: it is a function of the probability that a car wants to turn and the cost of the turning lane (as well as the probability there is a gap in the "blue" traffic, but we ignore this in our simple sample). If we start from some finite upper bound of *n*, we can decrease *n* to a point where it reaches zero. But let's first look at *n = 1*, in which case exactly one car can wait on the turning lane. More than one car, and the rest of the traffic is blocked. Our everyday logic indicates that this is actually the lowest boundary for *n*. In an abstract view, however, *n* can be zero and that works nicely. There still can be *n* cars at any given time on the turning lane, it just happens that this means there can be no car at all on it. And, as usual, if we have at least *n + 1* cars wanting to turn, the main traffic flow is blocked. True, but *n + 1 = 0 + 1 = 1* so as soon as there is any car wanting to take a turn, the main traffic flow is blocked (remember, in all cases, I assume no sufficiently large gaps in the opposing traffic). This is the situation our everyday perception calls "road without turning lane". In my math model, it is a "road with turning lane of size 0". The subtle difference is important: my math model guarantees that, in an abstract sense, there always is a turning lane, it may just be too short. But it exists, even though we don't see it. And now I can claim that even in my small home village, all roads have turning lanes, which is rather impressive, isn't it? ;) **And now we finally have arrived at rsyslog's queues!** Rsyslog action queues exists for all actions just like all roads in my village have turning lanes! And as in this real-life sample, it may be hard to see the action queues for that reason. In rsyslog, the "direct" queue mode is the equivalent to the 0-sized turning lane. And actions queues are the equivalent to turning lanes in general, with our real-life *n* being the maximum queue size. The main traffic line (which sometimes is blocked) is the equivalent to the main message queue. And the periods without gaps in the opposing traffic are equivalent to execution time of an action. In a rough sketch, the rsyslog main and action queues look like in the following picture. .. figure:: direct_queue_rsyslog.png :align: center :alt: We need to read this picture from right to left (otherwise I would need to redo all the graphics ;)). In action 3, you see a 0-sized turning lane, aka an action queue in "direct" mode. All other queues are run in non-direct modes, but with different sizes greater than 0. Let us first use our car analogy: Assume we are in a car on the main lane that wants to take turn into the "action 4" road. We pass action 1, where a number of cars wait in the turning lane and we pass action 2, which has a slightly smaller, but still not filled up turning lane. So we pass that without delay, too. Then we come to "action 3", which has no turning lane. Unfortunately, the car in front of us wants to turn left into that road, so it blocks the main lane. So, this time we need to wait. An observer standing on the sidewalk may see that while we need to wait, there are still some cars in the "action 4" turning lane. As such, even though no new cars can arrive on the main lane, cars still turn into the "action 4" lane. In other words, an observer standing in "action 4" road is unable to see that traffic on the main lane is blocked. Now on to rsyslog: Other than in the real-world traffic example, messages in rsyslog can - at more or less the same time - "take turns" into several roads at once. This is done by duplicating the message if the road has a non-zero-sized "turning lane" - or in rsyslog terms a queue that is running in any non-direct mode. If so, a deep copy of the message object is made, that placed into the action queue and then the initial message proceeds on the "main lane". The action queue then pushes the duplicates through action processing. This is also the reason why a discard action inside a non-direct queue does not seem to have an effect. Actually, it discards the copy that was just created, but the original message object continues to flow. In action 1, we have some entries in the action queue, as we have in action 2 (where the queue is slightly shorter). As we have seen, new messages pass action one and two almost instantaneously. However, when a messages reaches action 3, its flow is blocked. Now, message processing must wait for the action to complete. Processing flow in a direct mode queue is something like a U-turn: .. figure:: direct_queue_directq.png :align: center :alt: message processing in an rsyslog action queue in direct mode message processing in an rsyslog action queue in direct mode The message starts to execute the action and once this is done, processing flow continues. In a real-life analogy, this may be the route of a delivery man who needs to drop a parcel in a side street before he continues driving on the main route. As a side-note, think of what happens with the rest of the delivery route, at least for today, if the delivery truck has a serious accident in the side street. The rest of the parcels won't be delivered today, will they? This is exactly how the discard action works. It drops the message object inside the action and thus the message will no longer be available for further delivery - but as I said, only if the discard is done in a direct mode queue (I am stressing this example because it often causes a lot of confusion). Back to the overall scenario. We have seen that messages need to wait for action 3 to complete. Does this necessarily mean that at the same time no messages can be processed in action 4? Well, it depends. As in the real-life scenario, action 4 will continue to receive traffic as long as its action queue ("turn lane") is not drained. In our drawing, it is not. So action 4 will be executed while messages still wait for action 3 to be completed. Now look at the overall picture from a slightly different angle: .. figure:: direct_queue_rsyslog2.png :align: center :alt: message processing in an rsyslog action queue in direct mode message processing in an rsyslog action queue in direct mode The number of all connected green and red arrows is four - one each for action 1, 2 and 4 (this one is dotted as action 4 was a special case) and one for the "main lane" as well as action 3 (this one contains the sole red arrow). **This number is the lower bound for the number of threads in rsyslog's output system ("right-hand part" of the main message queue)!** Each of the connected arrows is a continuous thread and each "turn lane" is a place where processing is forked onto a new thread. Also, note that in action 3 the processing is carried out on the main thread, but not in the non-direct queue modes. I have said this is "the lower bound for the number of threads...". This is with good reason: the main queue may have more than one worker thread (individual action queues currently do not support this, but could do in the future - there are good reasons for that, too but exploring why would finally take us away from what we intend to see). Note that you configure an upper bound for the number of main message queue worker threads. The actual number varies depending on a lot of operational variables, most importantly the number of messages inside the queue. The number *t\_m* of actually running threads is within the integer-interval [0,confLimit] (with confLimit being the operator configured limit, which defaults to 5). Output plugins may have more than one thread created by themselves. It is quite unusual for an output plugin to create such threads and so I assume we do not have any of these. Then, the overall number of threads in rsyslog's filtering and output system is *t\_total = t\_m + number of actions in non-direct modes*. Add the number of inputs configured to that and you have the total number of threads running in rsyslog at a given time (assuming again that inputs utilize only one thread per plugin, a not-so-safe assumption). A quick side-note: I gave the lower bound for *t\_m* as zero, which is somewhat in contrast to what I wrote at the beginning of the last paragraph. Zero is actually correct, because rsyslog stops all worker threads when there is no work to do. This is also true for the action queues. So the ultimate lower bound for a rsyslog output system without any work to carry out actually is zero. But this bound will never be reached when there is continuous flow of activity. And, if you are curious: if the number of workers is zero, the worker wakeup process is actually handled within the threading context of the "left-hand-side" (or producer) of the queue. After being started, the worker begins to play the active queue component again. All of this, of course, can be overridden with configuration directives. When looking at the threading model, one can simply add n lanes to the main lane but otherwise retain the traffic analogy. This is a very good description of the actual process (think what this means to the "turning lanes"; hint: there still is only one per action!). **Let's try to do a warp-up:** I have hopefully been able to show that in rsyslog, an action queue "sits in front of" each output plugin. Messages are received and flow, from input to output, over various stages and two level of queues to the outputs. Actions queues are always present, but may not easily be visible when in direct mode (where no actual queuing takes place). The "road junction with turning lane" analogy well describes the way - and intent - of the various queue levels in rsyslog. On the output side, the queue is the active component, **not** the consumer. As such, the consumer cannot ask the queue for anything (like n number of messages) but rather is activated by the queue itself. As such, a queue somewhat resembles a "living thing" whereas the outputs are just tools that this "living thing" uses. **Note that I left out a couple of subtleties**, especially when it comes to error handling and terminating a queue (you hopefully have now at least a rough idea why I say "terminating **a queue**" and not "terminating an action" - *who is the "living thing"?*). An action returns a status to the queue, but it is the queue that ultimately decides which messages can finally be considered processed and which not. Please note that the queue may even cancel an output right in the middle of its action. This happens, if configured, if an output needs more than a configured maximum processing time and is a guard condition to prevent slow outputs from deferring a rsyslog restart for too long. Especially in this case re-queuing and cleanup is not trivial. Also, note that I did not discuss disk-assisted queue modes. The basic rules apply, but there are some additional constraints, especially in regard to the threading model. Transitioning between actual disk-assisted mode and pure-in-memory-mode (which is done automatically when needed) is also far from trivial and a real joy for an implementer to work on ;). If you have not done so before, it may be worth reading :doc:`Understanding rsyslog Queues <../concepts/queues>`, which most importantly lists all the knobs you can turn to tweak queue operation. source/whitepapers/index.rst0000664000175000017500000000067713223143010015233 0ustar rgerrgerRsyslog Whitepapers =================== These are a collection of white papers written by Rainer Gerhards. They detail logging comparisons and realities based on his experience. They also cover observations regarding the development of rsyslog and the community around syslog messaging White Papers ------------ .. toctree:: :maxdepth: 1 syslog_parsing syslog_protocol queues_analogy preserve_in_nat reliable_logging.rst source/whitepapers/direct_queue0.png0000664000175000017500000000400012704114446016634 0ustar rgerrgerPNG  IHDRݾhsBITO pHYseIDATxAhSw{FfbG"+WTW$Rp ] &SeHP=zf(hbN&҂$VmI_CH__b$c…+DJKKB4}է*ܰS    6kH;uI.H^Hػm?ϿoMҔ+M:dVTKla/ H6<\lƋrqHFD\q{5A>NnWܬd:/H~ꃆ5ΰ7AMϔJiTʫV}*.%=AGD?OD__ j?GM3ZWUtL37"#OӤLN=.ɥ* w1XiTLn,ypXI|RdO|!9.iIJgYm !9.cg|OITdV؋`{z         x[n?~+ϟh?~l8k׮UVwuu]pppxll"rcǎݽ{px۶mׯ7rӧ KJJc8,"9 bK9sˆUUUCCCG5={vKKᰈխ]p8H;wpxʕ 9߿pĉ[l1w^[[W.Y$>|h8yf`][[kd2i~"l^˗kY&l<,*RV&O޽ a,^,|##"26&sֳg}{II$$yqu%h+#/<?OF6+"8S)_<,_w)(o>u ,*|$""Ѩ=_B3܏?J2ia|aH\T820 y5x(5555555~h<?u뺎㸮;u&әoyO"v]{4Ǥo?;XeWN\O{^@M&]bE2<{lw@v3Mi6<]{Fx֭S%/_|O;ɷ۸qcss40_K8wxܹ?-rn$k`QAJREEEG {؉`!HRt:"+ ͛7{ٲea/;,)lذ!-`-K@ @ @ @ @ @ @ @ @ @ @ @ @ MLLbD""BtkkիW^v"X X X X X X X X X X X X X XҜ9s^vRXX              Ad27n {؉`!H'O {؉`P`P`P`P`P`P`P`P`P`P`P`P`P`P'4Y:`VJUY8i ~կe*y N!XkN!!욢)uTӃ vÂ- j(W9+;yR/;=D$,زC;?'{պxQ"`}w%1))V^lq TNI_/ճc ;,X]Љ 矗aHٳSZZ:úxQO=aRg2Uq;,֦RW.| dձ1MFhיG+FOHa( ^lnVmΟv8ks5D%wzz+`^zI ֲuQiӃZsRS$I=zDOxQXVu2Y(LUe]UP uzXknֿET]wމZ,˺4ӧu옒#b,TZ;,OHOwzT%܀`B} Tz&"`Bj^%,d%;= ,XjUkwuwz @"XԦ6U}[dtMMM7o=vXfͺ|1M8+++???ׂ5ièѣ&WJLL|ׯ_y/v*gW'5jV!͛7N\ÒE,`C簚{]XXёB1evhefssskkkDB"X]LW",Ҧ6IyZb5S?\`!^e8NH ^-jqz@"X$ X@ ܃`{,XHR%,$*VZ阃 , ج~2?է#4"E)EW#4b֦*@u 눎Lٚ=A hYeެ eAY=↉eeeÆ I[aҕ^dE0e2Fj}/ 'O0;7 m"X8mqqpBΡ'M;Zj!6  7WKM!DPݦr9^RS9D &F}#VH DEFD}#%8!/P1/_KJp4ΤM!DQ]XBBPL/S@ NtW%1M}pBPUIL߽Kz%8]$xI !DG4TB(RˣqcJpBA@M @55Ty=o38WkRToDQMp !D4sFlqgb(R&x2 &O\ݟ]_9>vHRck[fWYy=ӏWnN;Cvf8e|m5ϏGF5Tטlc ͱoR7Qfo/>44ygZau/,,sIf&,-K44y<{d1_'9}8pZj*!!'Xey(BƦ͚=|~֭ʕ 3ZHv+P7\山ٳ yUj*{J%8={[ ?jcm5]9 ?jsy1grlق7F i^ijru0B6;v 2={XLI/Āt14I5Ea`31Ϝ?~ c&D$j9e4/ [رen^\S+TGP>j_EF}lֳVSZT[Z='=,ؘzjY (;ocuu C6C3m7TZsyTѼҴU#ݝGq|xx'v|A_"5y*j]j8!)j,\\;5iQ[]V:Z4mUJ `9kN٭RRRz}ԩ*ծʺ<zHmu)u\PPPaasy!VLxX%!MK6z}'.]Wbt1cs$%aTtP&ISYWߜSv뗠Ν;seLcc> ? s<= {nj^aÆF0hn8e>Rt*q_ 8L++|5ݱu+d2LXMzH%z믿[.;;[ͩk86woUPmM0K+WF+V`%gU=8Lܾ}1&ɢܹ(߽{1&JьbE(***&&FQwcP+((P󣢢31D(FEE%$$(<`䨕>|V=z('&&2ƞ?VNJJbeff*b8**NJ'OcjO2D",4~z?0Xv6糜^r2 f/ow?3[WOiOgmmsndnnYPW5yk|:?fޅ*G1c-5i&nNQ 1ׯ%c,33-cL$ppp`={ @-cO>ЪU+XRRÇ3߿ˋ1v=ڵcݽ{/c֭[:u~:.]0"##tޝ1q;<@ؿ _~3g0`c0h ؉' <1 bo;r#G2~'cƌaƏ;pI&1`ʔ)oc_5ٳg3ƾ+sefXhclɕ:vx믕g??!:ej{(+ R i zdiib:FQ,`KA}'LN|䗯Gx̄/'U˾ ;tHc߿]vjem055X`ffVR===Bessswwwlii(]\\6mڨmllڪ[jNQW+;99deܹ>))Mo[kW>X~GC4 Q׮]rʌ 5.#>A1Oa=^˫WAuV'E6AHeeeY[[ȹ޽1VvH|^u\PA.g66:qqիWOP(\tizz:k4}p|RS~\|Aپ5,-+צN*[>\u qqq3f066\U5#KJJ0Ɗyyyyyy\9++|d"H,J)))RRR%$$_._ ))ߥK<|p.\gn.66믿}s}vXXٳgܸqc]dddhhӧ~)w-VΝ;tҿS/^_8qsGN>ɓ~ɓ's7+ݻwԨQ\yo6WޱcСC|嗃 [l߿?׆rm ѣ?駟H$M6~GbWGܗ%GOK5y[H^߭p7bkrzi1fN{s-RSSMMM۴i{)wvvfe/lpZ QQQ݅W_}U[oƶm۠g}࣏>bmڴ ecׯrJؚ5k^1ݏfتU_1l27nd}Gl[x10؂ 3Ν `ǎٳgصkclƌ[ԩSݻ16i$g?C222x/m۟z 01G!c;8 ;CWX@Pab&ɦ=yH4gc6u EeŊ'O66.bxmW v-77Ԕ_x|>MMM|>\(044ʎ[jŅ755lݺ533vqBaǎ=<<XXXtڕaiiٳgOu`` waή;v0h ͛7:th׮]lrݺuкuQFٓn7.pss+m:t;v\xq>}tyҥݻZ+O?+r߿-[477ʃ޽;zuFŽw}Ϗ=0a„nݺqwʔ):u0śrΝ[oq.\8zh{GM4ȴrYfq>`wwP<~;waavaPW냫zi*zw>ppnUwYSa|Ijj~~>cL.IRn>i pss۳gѨ5W>NMıc6mڤﮈ]ؽEE59͛>t5WR"n֬glllhXf%D>W7N2EG5Ye_hRv7)&MzIv<RR0ke&aV% .])DEFFΝk׮ӧiaW5EEA8)D3uy|}q0:uBr2- BCQӧ'N@ ϔRD"iժՎ;߿?k֬t/Gm|(n]LxIDBVI4P ^0jFĉ ťKX7c<,XPf/pBC Fp0llEJqzh̄b_ 1cvU~!P7@9u, 3rȷad yNR0d bz>嗰T֜0 ŋE5zGsxy5{!:,++ݻz=]h:qُ<9B|ყOx̤%p[l2܆k[;5Sp z PygglۆGdI5i{comsxS,bc4x>b v&r۷j-k*uylm5wuñcu vvʍV!!桙>RiɯC! _'@YnWx B%&8I=zd;Uj!4n`T?%%kt5LPv%xP 7sRQPՑ ۉ'ޫ{? +PX:%'?tLFF=9n=Z]@sx^Ouvpx01)_?ޯk|̜#/Ϭm bvq>=mߪ}qq1[ѭ[]RH ZdBbclݻV Sг~wc:m:w)I혙[~\V$+$%3yU+ c5n* :چ+ddM &(`};wbHJP84ڄ uͯFF%&ە9iS}DmAQv767c|֮Ř15OB܉HzH-^lxq(l˖ yMQTW@iR˳};ڵCBƎE׮jv#={XRRi#oݺW\ӧ<:Sa>d Jw7Zjsyؿ!!qoW_ņ 3.O&X@.XokKeL\?4E3ޮ][ 5ܩnō䡡kR@4z+ ./]pQv7r2c⫯sг'|#$qqС֬o(>S^?+4-;tWox 6K=X?y=`Æj5}:7@*k ة=XxMlI=B2KJed=2<X t}lIx.O|}kL>γgl\fl֬kRKvgV!Q=˙3nѮSbSv7-ٌ/ V>TV9!XRɉ*Y~]sݺ}莗'89nNR_vyY[+ZWa]={ RVF ned ͛UXbj^~=00L(;vL)AZT=+IpkeΚUսV{2ZTZ~:uR|)]\\9T*m޼_]\\,ɮ\U9xU/9Uq N  }W \.g66ʽjddlnnYtt4  UwIJJ244dj˛9sԩS \]]*]/Ԩ&3z`fN9㞙d.]9y36sKkDssK[<_=քBa:}yСQF}ӻ￧)ϛ7/???11ɓ'b8$$D"lY4qs*+&TG66|8vJ;V6ndrٳkv?]]]cR.""^gx{766D\Hwwwm&.b_hCMcl^erwxl`vKvzgf2'ܿ}&|JR/?~M6J?O>,_ӭ8&Jw-[Ɩ.e_;{lrfaQZ_?;_z"!h ϙ3gر˗/nݺecc#HLLLCs 9N,`)ڈPvRlj͂{'5Xyŋc&oΟpFCIc_rV*H~G1ƲfϞ3&N8k֬,Xrr3gbAZZZ-Y :z2$TO'zҥ(E,F||-!ԧ ѣs&1ۇ1r$_ɑsri0w.ѮG|VchYQKvcR}y\ڷzHSBpذa^ P69y<II1chFC@OWWWƘT*(Wbbٳ=<Xɓ޵ywVv{-b~~50/SQ㣡d={*9ƌaBNegea jQPѣ] Ѽ&L駟;v '###44411@vvΝ;tbmm]PP_'''@osAPPВ%K D"ѺuԎ, 2v:w*clwAb,cZSM*1h_pu-gwqرef(ѩ֭wvʿjbbr>}D{̙3*%%燇O6˫W^}w-Ǐ_}]NNO@@+ݑ8s,] //8~=cZhQ`8_=.ny=0i|}ΧOeKqſٛo2>ܜ}))s Oҗ<=;0@)zq7̙nR?hV=jsy퍏>Rs|}q8._ƉBPrs'm(.ׯc@ Wݻ#G3o:wat)7@ i+4FsyLM5t޽.p*o%dhiӰz5*[Xwjx).Gh5uyxشJ yH}2xWС¦M(K 'zԵǏկX2g8p2Y5el`tܲ~}{112+WB"Qk(I]k/#(H}=L//څjw*qF[#<6ȄJpRw#* >K/@^^}5 ]q!OO|-0ȄJpRo!&S>PxY}"0'O?B?{0mZO\!DPzCBSfd+85$A4>حí[;VoB%8iض ay);6 jY&áCvM~p\[oѭߤ' 6!) !!)R~>n;f@BBV\o&L(CE;W CY[O-[мypq?s&<(F8~*$Q9D g6oְ%aðb.Tq \AXD"FF7˖ǧޛMn':@*šCظqq^Rޯbnަ2Kť^I':C./`DEUuf.!%81?X[c|ֶZFΡ'9_3gԷ;:b"~$Q'_ZGat OT#ϧ'}E3z!D_QB'}E N!JBB fff]vyf >l| BP(3rjpBJpR[@"H$CΚ5V&w[n)()xq Wn1ʳ^ÝA޽b8((H(z{{>}/z⊽bȑ#----Z$tm{qJ`͚5߿ ??֬YvvvӦM+,,T@h%82Ý:uRlZhq̙"… (iӦ\tiÆ Tcqㆣ ?>00y}?}y&OOO/..𰲲0`@vv6333KK:nҐ(I077߲eKXXYYYg޷o_vvvDDc T*M,}Ruy슋U+(⾼J*FDDܼyK.žvvv&&&Ϟ=_A NLǎ;vuËKJJlllnUAAAK,)((D֭S;P(2dBHHرc+:]%g##W^ye׮]z200G^hk&%%ٳ AP4w;vrKvWQa">00pw8::XUTߟ1֧OR+صkSgoG&$}E}pBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+JpBW( !D_QB'}E N!B%8!+Cm7))Az:22 A$*-]iA v[ iPD'=xӧTu/ݻo_ =g >cLm ػW*7ppPvE")j&`kA NtC^BCoo_ op""߈-ؾ^^rBh\rehka 6LLjuثWw/~04 m4 fnvhV4y/bB\z!, ݺb`.d'adT Zu$nv#Ç`MIv-JNfc0ٙ\lРҟ3;wNDڎ-11  G4mi/L X~3z<]v/'>qq~PҽXQۍh(W @ۿG`6Z#+L"iг-[ֻ7{AN[m=ӜLҀRR0`BCa`qxC10y8;E㯿)JpPN?""䄳gtf70d220dVLR; $!=MjIlbj$DgP[SxX'N^ xXgϢeKDDhMT%8. <=ac-HHvkD%>;EEn GKDEC 'bSS|zxEq1,QƨQK!F(ICy=<=q:tQpcv>LS{' S'\V9kעCd$pmRw(Iòؾ&&Xnn0Ȍo`hbp\]⼄Jp s%iǏ1nAdd=N, ۶QXY iDK:wÇػ-Z%ɓ\gJ//l!) YJp=x=ܿ+`bѦ Nōup,}{,XL [m-@JpmB!֯ǽ{5 r9E. |gQ\\C1wcƍ-/F|GppA4Fظ>JQ!(AA ɓ2mG2r[OHá'M(D۶hKkR]$}E N9r\M&/^Sm74Ns vCt]󼼼0""bذaӧOOKK ;}t]U=j>nj}p''Yf#GZZZ-ZH&AAAB[S팫'Mdmmmee5qDnc~~Y쬭MVXXvRpwwEj]Ox<?m˖-5%Kl޼y}+EٵiSd׮]fff͛7 _\a֭W^/_U.e(U|_5OpL?(ڔsiӦ\tiÆ fΜimm-.\ҿ_fΜ)J?~1͛XvR3˗/722_~|݆FV|dWW͛7K$j*77ի#G,ư*((NKK2eҥKbxk~~~ll*:]AAANNNjjy睼3f,[1P4c0`XZZZZZΝ;Fiii\'Oz{{K$>(jY"**s󍍍E"eddyn0 3NMM-**beeeDbXNNNffT*Z-ɸH$XaaaAAW......1LUn:O^3eff*>ƆsRo_n)#**놫߸qcnn.clto8&&&k +.Ucw޵^155=xD"h/ݣUecc*2V6E+w(؈1Vq𬬬 .tA@FF7⒖&+9H$244TT椧{xxXYYYYY 0 ;;[յi͛;wѣ#"" > biiyE Ajfͮ^ wׯ_Э[7CCÛ7oԩv޽{LLL߿Ç\<)) @o֖h߾H$-Zx9WnժUNNvڵiӆc]vnnnhڵJ\LJa]v۷ }}}dN:u @QQQ.] W_ Hz+gnnnK.ZV;hР7nXd믿`}6~ݽ{9s^y啘3gӧ78u^zq?I&#!!رcuGյkW=|Ν;?yСC;vx ___Gko>==+Ҷm[X W^ ӓtݝoյ37ڪUZjٲ%X-HRVZ(,,kݺ5<ggg999VVVmڴs wFFP(tuujff 99Ǐ===<|{yy>رƮH$Zlˆ җmllsssնk +ffffffLLLCG{ʕNXPEEE8P49vvv%))^*n*s`}:d2EeaMLL={֬Y3F?Fۘ͘h1 [[[.BW633377LMM̸CCCCCC{@IIIɋĤR3crssrvvvff&Wܯn\ٳgϟ?999\9)))??+?|" \ r[LMM7Lv5 |kkk&yyy۶m344\ſzꨨ(CCþ}nٲn$$s~ƍgΜpKɨsnݺu%.1oݺe۷_Υ;w)ܹ%itt{rLLNllOH\\\bb"WӧO_ Ϟ=~]>ʉ\NJӧOdoMϞ=S܂}yDE|׷o?uX,f)1vsq#"""߯\s/4}˗мsNddk׮qSoܸ{ cor!..ݻcbbMHH<~?b##㤤$G#99999<{ٳg\9---==+D" b1Mϟ? r<;;{r\"poV.soP.roJ.sgd2 U*Eqrrھ};( c;|pQQQII'N4ƱXJJʉ'w_Z.ehHu^<==}666>;wTﭭnݪcr&M6͛7A(zyym۶M_***|VeaarJ}J< oQ2gΜO^^̙3mmmNeD*k@:wQtl2<<\Xg]xqk׮dªғ'Ozennnff֥K/2MU/e+vReiis}2*Npp7Yѧʔ)&L6lҥKYU4Vր\ܺuK޲e˭[\o4TMHj(44+[YY-X`:Hff 7Z[^AAC{oW\9v؍7־25k֬ahѢҥKgΜYGǍ %8={<~z…V5ZI ''G5+M}3xjU&:Ν;k͗,Y2{lP(**ڵkך5kkv7'" êOxREUݻwoٲeܭx"lBRbիqm⛳iӦe˖=z`֭?òe˜oVTTUG^hw?_JJٳgT2}[n]x1KQhٲe]Hѣ[nqÃ燇O6˫W^v222277W 5ժLt7T݋B[g߹sz Ш2^E_tDtɓO>U#Tdҽ{ݻkB'}E N!B%8!+JpBW( !D_QB'}E N!4?DqɓxQۍ &(I3л7=vkTc"   (I2.׮sgHJ+/adp͵&B4Νq:F@VFEZQt+W 06CHMQbi_~֭02—_WfHXÆ!3ÆuhCr=4h MXp0zĘ1r;#43fEń ~FFظkSy3v#JF\FOM?+=ir2V` [QtZg$ }ܿFh{6hGs47[Ѵ=%K6lGݟSS,^!6$$ 5Uۍ;;vKHVT/Dh(rr`d G3_~Ap0RSaHl 98!:耴4\{!AA9|m8ᅦH] , udBt%8O㏱?r06F>^^prak빹))8{Wmmd >XF{\U4ʅB %4մh{t i(éS8s))^X O9Kcyst놾}FҠ(^a4%l-^rBtS#VIENDB`source/whitepapers/direct_queue2.png0000664000175000017500000001002512704114446016642 0ustar rgerrgerPNG  IHDR sBITO pHYseIDATxkPT.F4uKA/RcdLh:$kD/QP1k2D#Nh AƢD;˲fRd}&,_o=.g""ѷo_C]V~uBNmw(!$#y,,DԒ ,A:'"d$Ptb&#"rAR387l*U?ui3s\1&*y+N=At:^ :\` m,qo5;7+mtGw-vXj{A^ie6ɸzGBzw` >لMjFDVvfm\^(|/=$.Ba1uۉjED}o$+GqK|i+"WZ$  R{"z kED q+R˾}>3aaa;駟۴is/$%%Yԭ[666޸qcǎwٻwoEEEaaKJJJKK˿뒒o+**jhh8qĽ{N>]XXh \p~!%%nݺu= JJJܿ@YYYYYG`2X, j677Z= L2E?^G 2DrJooo!ի=<<!!!,*<<"##}7ccc={@bbK 4111YYY.."eZ-d2 !m6l6Vd2677L"R__]\__c2oݺU[[k2nܸQUUp5h6KKK-KRRRqqqsssBBB~~̙3999BSNݺuKa0_.8ydjjĉ/^Bŝ?~ɓ Ǐ9|ZۉB>}z۶mBgnܸQvZ߯^l6'%%^reʕ=zjPPPIIIZZŋ쀀1//oEEEsνpB;[6ikEDZ6xrXr?/xe!KTyrm%X+TF/\HBM||0 ѨxI RgxQA_pi1},Ǝɘ/g$WZYaFb.S1jOGZS4amw>6Qx܊:؍!AͫxO+`#e#C|i ~ߩ=u|u ld Lu,aD1c0=uAOeڿk~BCCkkk.^dɸq.6 *\l4`RhݻwW8""ݻ ӧOW~8rŃ.=ߟ77~䧂 =zU_{y)\W_)\elٲ~%.\pqBBɓ'.3fҥK.k뽽.TxΜ9gVZ>}ZwA1bÇ.}7. /.7oޡC.˛4izpٳ/_pmۖ/_pqttoɓ'(\ gϞO;r//pnnߺX|?˖-R8((hǎ '''Ϛ5K=zF*\|Ao߾n:g͚ph6lrss_~e ֭[f|=zqfbPV i1aVىs1WYH |$H".?χqXYH &_Z`IG xAqH|v(:;?*Wfp֊.#|͆ҧPvBCڣ8kEoVy#`x܊!c1/Q{j]y9`,] .qC`5Pc|NF#1|xgooЀ7 4g%١cH `au}V*4 7cjy.fݚ^õq+R} PO>NݱbV7oH2oL3xzvNٱVlPzRKx8ZH D2qojj0q",jފG*WTL(>#ưVXJPWp}&=3\SX+r,1jBRcȱtx7|ZcȘjOAc#"ձV@! H!ٱV@%*d󭢢zN/t[׿NSg? @\Viii|O9cFN/sVNaٞO~ ~IIC_yǏ=V}ѷS28qDddSh˶/$$Yc\%K,YS~":LH033IIISN}#)uWJ~wVMy8* ŋ+U*[/g.]twoɈ *P|cUSS{ngLb?"xYV@*B466:cJr9PJW8hJz9ЮGNZI"Q oX+V<Фk%=֊fX+V'<JZI"Z+`>$Z|$H.""Z-VhD*Vcldq+weqxGUc$ZQK0.0,qH030=7 X+RDG/|7`Fl h ڸbϞ=GtKNVފZ1Vb%\! tЍm\}ƌCuTX+j](Bz X*ZIFn=Gb$Z3ُ XUkEϤn ` BVrc->Y^ū>QwJr9 `X+V@ك=kE R{ fVcH3X+ɱVX+ Jrik%9֊:lNHHpƍVc#566ڵڵkθq{HZiVcH3X+ɱVX+ Jrik%9֊4kEZI"`$ZfVcH3X+ɱVX+ Jrik%9֊:Rn'Ng$׼g$ǽik%9֊4kEZI"`$ZfVcH3X+ɱVX+ JriNcZV2cHKX+V%X+Jfu$zr'>k%3֊:R]]ρtX+Jfi k%3֊kEZZɌ"-adZV2cHKX+V%X+Jfi k%3֊kEZZɌ"-adZV2^^999SL؛Zz4I7N.""mbR5k,IENDB`source/whitepapers/syslog_protocol.rst0000664000175000017500000002747413223143030017373 0ustar rgerrgersyslog-protocol support in rsyslog ================================== `rsyslog `_ **provides a trial implementation of the proposed** `syslog-protocol `_ **standard.** The intention of this implementation is to find out what inside syslog-protocol is causing problems during implementation. As syslog-protocol is a standard under development, its support in rsyslog is highly volatile. It may change from release to release. So while it provides some advantages in the real world, users are cautioned against using it right now. If you do, be prepared that you will probably need to update all of your rsyslogds with each new release. If you try it anyhow, please provide feedback as that would be most beneficial for us. Currently supported message format ---------------------------------- Due to recent discussion on syslog-protocol, we do not follow any specific revision of the draft but rather the candidate ideas. The format supported currently is: **``VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG``** Field syntax and semantics are as defined in IETF I-D syslog-protocol-15. Capabilities Implemented ------------------------ - receiving message in the supported format (see above) - sending messages in the supported format - relaying messages - receiving messages in either legacy or -protocol format and transforming them into the other one - virtual availability of TAG, PROCID, APP-NAME, MSGID, SD-ID no matter if the message was received via legacy format, API or syslog-protocol format (non-present fields are being emulated with great success) - maximum message size is set via preprocessor #define - syslog-protocol messages can be transmitted both over UDP and plain TCP with some restrictions on compliance in the case of TCP Findings -------- This lists what has been found during implementation: - The same receiver must be able to support both legacy and syslog-protocol syslog messages. Anything else would be a big inconvenience to users and would make deployment much harder. The detection must be done automatically (see below on how easy that is). - **NUL characters inside MSG** cause the message to be truncated at that point. This is probably a major point for many C-based implementations. No measures have yet been taken against this. Modifying the code to "cleanly" support NUL characters is non-trivial, even though rsyslogd already has some byte-counted string library (but this is new and not yet available everywhere). - **character encoding in MSG**: is is problematic to do the right UTF-8 encoding. The reason is that we pick up the MSG from the local domain socket (which got it from the syslog(3) API). The text obtained does not include any encoding information, but it does include non US-ASCII characters. It may also include any other encoding. Other than by guessing based on the provided text, I have no way to find out what it is. In order to make the syslogd do anything useful, I have now simply taken the message as is and stuffed it into the MSG part. Please note that I think this will be a route that other implementors would take, too. - A minimal parser is easy to implement. It took me roughly 2 hours to add it to rsyslogd. This includes the time for restructuring the code to be able to parse both legacy syslog as well as syslog-protocol. The parser has some restrictions, though - STRUCTURED-DATA field is extracted, but not validated. Structured data "[test ]]" is not caught as an error. Nor are any other errors caught. For my needs with this syslogd, that level of structured data processing is probably sufficient. I do not want to parse/validate it in all cases. This is also a performance issue. I think other implementors could have the same view. As such, we should not make validation a requirement. - MSG is not further processed (e.g. Unicode not being validated) - the other header fields are also extracted, but no validation is performed right now. At least some validation should be easy to add (not done this because it is a proof-of-concept and scheduled to change). - Universal access to all syslog fields (missing ones being emulated) was also quite easy. It took me around another 2 hours to integrate emulation of non-present fields into the code base. - The version at the start of the message makes it easy to detect if we have legacy syslog or syslog-protocol. Do NOT move it to somewhere inside the middle of the message, that would complicate things. It might not be totally fail-safe to just rely on "1 " as the "cookie" for a syslog-protocol. Eventually, it would be good to add some more uniqueness, e.g. "@#1 ". - I have no (easy) way to detect truncation if that happens on the UDP stack. All I see is that I receive e.g. a 4K message. If the message was e.g. 6K, I received two chunks. The first chunk (4K) is correctly detected as a syslog-protocol message, the second (2K) as legacy syslog. I do not see what we could do against this. This questions the usefulness of the TRUNCATE bit. Eventually, I could look at the UDP headers and see that it is a fragment. I have looked at a network sniffer log of the conversation. This looks like two totally-independent messages were sent by the sender stack. - The maximum message size is currently being configured via a preprocessor #define. It can easily be set to 2K or 4K, but more than 4K is not possible because of UDP stack limitations. Eventually, this can be worked around, but I have not done this yet. - rsyslogd can accept syslog-protocol formatted messages but is able to relay them in legacy format. I find this a must in real-life deployments. For this, I needed to do some field mapping so that APP-NAME/PROCID are mapped into a TAG. - rsyslogd can also accept legacy syslog message and relay them in syslog-protocol format. For this, I needed to apply some sub-parsing of the TAG, which on most occasions provides correct results. There might be some misinterpretations but I consider these to be mostly non-intrusive. - Messages received from the syslog API (the normal case under \*nix) also do not have APP-NAME and PROCID and I must parse them out of TAG as described directly above. As such, this algorithm is absolutely vital to make things work on \*nix. - I have an issue with messages received via the syslog(3) API (or, to be more precise, via the local domain socket this API writes to): These messages contain a timestamp, but that timestamp does neither have the year nor the high-resolution time. The year is no real issue, I just take the year of the reception of that message. There is a very small window of exposure for messages read from the log immediately after midnight Jan 1st. The message in the domain socket might have been written immediately before midnight in the old year. I think this is acceptable. However, I can not assign a high-precision timestamp, at least it is somewhat off if I take the timestamp from message reception on the local socket. An alternative might be to ignore the timestamp present and instead use that one when the message is pulled from the local socket (I am talking about IPC, not the network - just a reminder...). This is doable, but eventually not advisable. It looks like this needs to be resolved via a configuration option. - rsyslogd already advertised its origin information on application startup (in a syslog-protocol-14 compatible format). It is fairly easy to include that with any message if desired (not currently done). - A big problem I noticed are malformed messages. In -syslog-protocol, we recommend/require to discard malformed messages. However, in practice users would like to see everything that the syslogd receives, even if it is in error. For the first version, I have not included any error handling at all. However, I think I would deliberately ignore any "discard" requirement. My current point of view is that in my code I would eventually flag a message as being invalid and allow the user to filter on this invalidness. So these invalid messages could be redirected into special bins. - The error logging recommendations (those I insisted on;)) are not really practical. My application has its own error logging philosophy and I will not change this to follow a draft. - Relevance of support for leap seconds and senders without knowledge of time is questionable. I have not made any specific provisions in the code nor would I know how to handle that differently. I could, however, pull the local reception timestamp in this case, so it might be useful to have this feature. I do not think any more about this for the initial proof-of-concept. Note it as a potential problem area, especially when logging to databases. - The HOSTNAME field for internally generated messages currently contains the hostname part only, not the FQDN. This can be changed inside the code base, but it requires some thinking so that thinks are kept compatible with legacy syslog. I have not done this for the proof-of-concept, but I think it is not really bad. Maybe an hour or half a day of thinking. - It is possible that I did not receive a TAG with legacy syslog or via the syslog API. In this case, I can not generate the APP-NAME. For consistency, I have used "-" in such cases (just like in PROCID, MSGID and STRUCTURED-DATA). - As an architectural side-effect, syslog-protocol formatted messages can also be transmitted over non-standard syslog/raw tcp. This implementation uses the industry-standard LF termination of tcp syslog records. As such, syslog-protocol messages containing a LF will be broken invalidly. There is nothing that can be done against this without specifying a TCP transport. This issue might be more important than one thinks on first thought. The reason is the wide deployment of syslog/tcp via industry standard. **Some notes on syslog-transport-udp-06** - I did not make any low-level modifications to the UDP code and think I am still basically covered with this I-D. - I deliberately violate section 3.3 insofar as that I do not necessarily accept messages destined to port 514. This feature is user-required and a must. The same applies to the destination port. I am not sure if the "MUST" in section 3.3 was meant that this MUST be an option, but not necessarily be active. The wording should be clarified. - section 3.6: I do not check checksums. See the issue with discarding messages above. The same solution will probably be applied in my code.   Conlusions/Suggestions ---------------------- These are my personal conclusions and suggestions. Obviously, they must be discussed ;) - NUL should be disallowed in MSG - As it is not possible to definitely know the character encoding of the application-provided message, MSG should **not** be specified to use UTF-8 exclusively. Instead, it is suggested that any encoding may be used but UTF-8 is preferred. To detect UTF-8, the MSG should start with the UTF-8 byte order mask of "EF BB BF" if it is UTF-8 encoded (see section 155.9 of `http://www.unicode.org/versions/Unicode4.0.0/ch15.pdf `_) - Requirements to drop messages should be reconsidered. I guess I would not be the only implementor ignoring them. - Logging requirements should be reconsidered and probably be removed. - It would be advisable to specify "-" for APP-NAME is the name is not known to the sender. - The implications of the current syslog/tcp industry standard on syslog-protocol should be further evaluated and be fully understood   source/whitepapers/direct_queue_rsyslog2.png0000664000175000017500000003007612704114446020434 0ustar rgerrgerPNG  IHDRsBITO pHYse IDATxy|M7Nľ+JJQ.TQR>AՏ6EjKRtص>%Uj_b$Dw~su̜:3g;Bd}IUBJvQ׉d?裧ON<ٶm[U* 1L[sk;l{[r凶7gyIwO. *BQ0L_P(qw'99Ie?Iw|w{F 3}3ZB ; Nw4 ձ-8),fq=mg{1-dUh:FkQ(ya”lx$']5)sC9_F3n SkC0ZB 7}Ýl`CQA MncB&mHs3u0´-l$B/,\GxDu,!=+\H%ՄI L•7PU1o`d& .f&L-i-M8"߃[rhUbUyTp614j"ٛ?. Y<#9`I6Qg:Wb*T³<+ AB»R'345KJ2G"8`{GpDSX5UJ t0x?9̉'^QA,-hL30c8rdOm/#gfr׮qׯ߇wIJ"9n) rL2.0eo-h*`au>nCIڃ .p;≟9I&YK-jmnGyK,Pj:} `598\Jb2Ox{_x{s<_uCN`~TQT(g%?!mǼy[,79KX5~xƴ(L3>>DR};.ˋiܘƍJPS>pƒ ^ʬ]D+\]T("@*TE=r) \.A3i¼[%z!Ĵb]6iioEϞEѰ 6 l. wyDS(.ƠCQF l8C@]l#Y}\hРaÆ={6..nѿ 0mڴ%Kׯ#8yaaaBDFFڵ+!!!>>~֭/_GbF4(ĊX}*̙3̙3˗{B̟?8vɓ'V\) BL^{MsÇGDDDEE?B̜9~Bl޼YS֮]`n9ddA7fGxhM [Ϟ=+XbvNYfĉ۷ot_ZĢ?M&4iHçy! Z (Kٺ|q7c=EE.d\jVGJ"g?_-g9ai={2mY LƵwBX’Ůf4 !d xKQʮqτ ;I'q~/81d囼yIdPG ,ײvۑr_*VE Қmi[uSU9έbjVڂOc<֔ i0 NdLfrAuۅ.fWj,̝KD+V @ozW2y_M p:)Ro7ɗYg|g:6bS[-bBd":ZfDffiE B=k0fa^+%?UT#ho^4xOѢd!CdL?yk6rݖѮujoQg{O m'_5lذGn߾tRƍbdڵ*~ҡCmc 9?ЯZP>>>#Gr:4EIVcK/թS-O_f޽{[>%%e…y$x^{ҥK7Q_rM@jլ+Z͛cELyE\ɷ0ekaYέ[z?.]*~YMnIJext(U5j/_nU|myZi޼jDZRDPj*[V?wUxԩU񃃃a-Y$\Y)VjuO-G[~rNjU]ZV.^o؜=m^ qqqPUn޼9$)Sf̏hI/HLLLLL|hUl|ea6_lTT͊o߶d5%hnjjG ;pzt+(TZ5K"gq4+.W\< 11rBxzzZx9˗*~~~^^+$s:Ӈ'r=>>>V]TYu9Ԯ]Ŋ0rk-˗)SV>uwiNw˗|Y 222,Ϣjժ>>>uVLLL rT%WnyL sFzU /A2Ů.t1Z?NӦ˜9V"Ady}Rv;h9Exs3>{J i_ڙd*WȕUFwMiN/I[ڇ>)Wp$k[f6+Wyc$l>w܍#1[P>hMkaʯ=Y{[F)B,ϖ܂Fq1$&5+bxsx%-MqHwQDٛ('*Wp$ԃxcrǐHbQEw#ٲ ҔO}e v%Ý]쪈up|<^Fq2d1\;G85_Ezltiڶ-د[b* < :h-E?,ױ䓓 A zӻ23Ȱ*4K x2VQfvg:ȇFk)Z|׻&obazuO'!A!102Ej-rii* W{#.W,aք&x*c?Ac\ֳT 0Qwe){ʕ1ΝaڴBhr=6}ÏZ!CXx x~(iCe򔯢(r>XFpIư/NYDGS&&BP4[oQt4÷~hZ7]Z}seoh .n/%!oJwJ6++벓opۆˣJZ::Yf6}M$:߶k}>}Cr3.۪%.ݕaߺ ɪfߘْ.lvuWWUp7ޞvYCNHU`|ߍw=U=t7tcHN&=ءFM ~޾2.Ky|AsF%_;-e"A0 ȃgyv/{/pr&5jJdXy|Wv10|m)D-[j.hkZFaY"W\G0h!E\! +f%;c %hH1+) uf+Y0Ub¤A/I^Ǻx5RX*3 k.7oh&q*\\I8UDZ2Zp ..XtCij<壈Eb+[SIuZR7|Shg\fÃyy+!1tc3CIUưsNq̙AD mINN~w|}}[haӊ#^\%K}V\i{4;K/ !rKŊpPRJ _||Y3\\\%K+W9:59+尢@|I"Ik/#l4箮k[:4K%Xvرw^]׷Lȩ=6R|C5k֬SN6lKXު {&0?gHƏg(Օ?g nq[2ϖTn:J$(A ˃$%%{PPFg}VNAqv + CqVcpw磏x5ϩWQ#nՋFǽt{ygjUAÃutXi Rd+%X|䆳0x0jq81h_}Ւ%KTU(c 2H* 3k\pbcps#(-B`2ѣMmb3$RAQ q zHVw 36#o\z'6`9(4 sPv#Vϓ%hV1apOs+AAYIy9umZ3h-TH;e:Җ$ EERbE0r%^:a; 6_? &ٞOtL )zgqr]hcI!;^KU`': x#?vkg:ȋ>/Lga<(p7͡>3ǔ f\d&c^ )zL&*W{1eR19O%LLQϑV<e V6|DDP2ɡ9,c2?cк Ll-7!{էcІF+RXUwy6/墕z {y cbsCI:`%9C>IM<%vvB' X})â Ì,xW=}1XE:*F,Sթޙ2*<˳/b`CsXVa1OlfI@nXh ` ѳ<ۛbZUCa)i % T@ZG!p/5!jwm AtK ̟?:)gh2vضmipcݻԩyg}QCIK Xbʕ:)gh geeݶBGߡ[n *LUYmƠ/<%yiI=zŝ=[1X% V8 N0/hx7 T$29K@pE'_$aI>`̘1&K#-TP!RVÐo gAA:U؄&&L8fI_5...d9-B\!g ߶΂1HG KQOLױAKK[Cm+e a> #W~+>ĒVÐo gAtXp c<!DK\|򫴕0,۶YP (^–?u"oI]ro r% V8 BAyݛ-MbR8! r% V8 B5UQDKY;^+ZaHY rV!V8 *dG\ Zaތy)KS} kF1W~ŷ r% V8 g(>iDILZǺ ]ҴZ"?%r.vVeo: i8ydNɋѮټo g(`w}D~ʧv wOzg~ )+aYzQABUٱE? XDQX"v'۝-m: 9K@m Cɦ.r^PlQF5mP+Vz<7x^h@{c7C?,Yr?1ƍ5\rٵk1c$&&0ѣE)4%t۷ҥK.Ξ=K41-]t֭r'O2eJDDZ싽z ӡC:W_w^ Э[7%iTAP(,"&&&&&~Fk/ BqzMP(N2BP܇2BP܇2BP܇10mڴ˧`Μ9ڇ_~`Y BQ1~l޼9YưnݺďݿR Ob{iӦM7o?\eĮUsĉze˖v*Jٿoq…^xA־}:DGG !,XѾ} & !N<٦M6m>}ZSJѣG?cs͑Ÿq<Ѽyzkݺu%eSSS5j(p]͛Bڵk8N!`ԩʕj}ӧOϝ;nݺ>>>W(0^P!DΝ;tsNLC!}h۶*۵k}Ut˗/שS'{K._vʉyd ))}<޽{~il6k哃ڵkk۶jժmmTOOOtړBF1|ի{vINN޶m[TTjժseeᡅ \x񩧞._mY&NΤN::t(]tYzuv:vFҥKppvsر'xBJGSH1V݋I-cYؿqqZ"{XP 2c;aѝ@Fwpsj5**0aBjn{"ۜ@YYYzz:C-,,jKJJUUUؽ{l۶ի>C^wޱZV^-򊍍B!ǏB=Bӧϙ3GOؾgyfB{nB_~yȐ!B˗!x OOO!D\\ 6xxx%$$xyy]r%))Vƴ*V;hРܠǏ8qbȑcǎή8qbFF]7A(~Ĩs\/="eXf`0!:::Z[[Vdt`0\|`0444f^Yɤkjj ^hoo7 OvhbTpWC}׋ ޹PA_+їp^@ a_wnaQoKIHJCڷ;ܧcL0n xKI,r ,Hމ(1E8§a<䞎"0¸7`E\|ϏOa@JcXflG|{g= jTWP4ۿ¯䞈ӝz6l CX5wa7-,&>-~/k(=MwtڱcCk׶K\=hڣGJ\%qN{w%.nݺ~pY}ٙ3gJ\|ɽ{J\)qq||/q #qq]]ɓ%.+o$.޸qk&qqrr)S?~\b>>>wϲ/L&1Bx.tvcǎI\lYRR1116mhܹ{{{t:J\{?5kH\ó1[q1,zHX"Y4V;,zHp>= (@l^E)H{r! u0a.CY{r!(u93ƿY+gS[.p$,nda6#'ˇZ lmuBAky:˫;VP`ֆFaTƯPu4$iB+Z96y/8E ݗ^~q,/T[նKh512`<$5P; E 6na";[=E I{^KH `E`E`E`E`E=d28,b'utt|GNrĕۂE"1X 1X 1X 1X 1X 1X 1X 1X 1X 1X 1X 1X 1Xԓ<==BBBq Ys'yyy%%%9,)E )E )E )E )E )E )E )E )Jb\EJ`8rq ) ,R1Xԓ,U]?,Iׯ_ ݹsrq ) ,R1X$ cHI,`0X."%a\EJ`8rq ) ,R1X$ cHI,`0X."%a\o~USS2uԞZŢVmp㺺t,"RM#HIENDB`source/whitepapers/reliable_logging.rst0000664000175000017500000001014613223143010017401 0ustar rgerrgerHow reliable should reliable logging be? ======================================== With any logging, you need to decide what you want to do if the log cannot be written * do you want the application to stop because it can't write a log message or * do you want the application to continue, but not write the log message Note that this decision is still there even if you are not logging remotely, your local disk partition where you are writing logs can fill up, become read-only, or have other problems. The RFC for syslog (dating back a couple of decades, well before rsyslog started) specify that the application writing the log message should block and wait for the log message to be processed. Rsyslog (like every other modern syslog daemon) fudges this a bit and buffers the log data in RAM rather than following the original behavior of writing the data to disk and doing a fsync before acknowledging the log message. If you have a problem with your output from rsyslog, your application will keep running until rsyslog fills it's queues, and then it will stop. When you configure rsyslog to send the logs to another machine (either to rsyslog on another machine or to some sort of database), you introduce a significant new set of failure modes for the output from rsyslog. You can configure the size of the rsyslog memory queues (I had one machine dedicated to running rsyslog where I created queues large enough to use >100G of ram for logs) You can configure rsyslog to spill from it's memory queues to disk queues (disk assisted queue mode) when it fills it's memory queues. You can create a separate set of queues for the action that has a high probability of failing (sending to a remote machine via TCP in this case), but this doesn't buy you more time, it just means that other logs can continue to be written when the remote system is down. You can configure rsyslog to have high/low watermark levels, when the queue fills past the high watermark, rsyslog will start discarding logs below a specified severity, and stop doing so when it drops below the low watermark level For rsyslog -> \*syslog, you can use UDP for your transport so that the logs will get dropped at the network layer if the remote system is unresponsive. You have lots of options. If you are really concerned with reliability, I should point out that using TCP does not eliminate the possibility of loosing logs when a remote system goes down. When you send a message via TCP, the sender considers it sent when it's handed to the OS to send it. The OS has a window of how much data it allows to be outstanding (sent without acknowledgement from the remote system), and when the TCP connection fails (due to a firewall or a remote machine going down), the sending OS has no way to tell the application what data what data is outstanding, so the outstanding data will be lost. This is a smaller window of loss than UDP, which will happily keep sending your data forever, but it's still a potential for loss. Rsyslog offers the RELP (Reliable Event Logging Protocol), which addresses this problem by using application level acknowledgements so no messages can get lost due to network issues. That just leaves memory buffering (both in rsyslog and in the OS after rsyslog tells the OS to write the logs) as potential data loss points. Those failures will only trigger if the system crashes or rsyslog is shutdown (and yes, there are ways to address these as well) The reason why nothing today operates without the possibility of loosing log messages is that making the logs completely reliable absolutely kills performance. With buffering, rsyslog can handle 400,000 logs/sec on a low-mid range machine. With utterly reliable logs and spinning disks, this rate drops to <100 logs/sec. With a $5K PCI SSD card, you can get up to ~4,000 logs/sec (in both cases, at the cost of not being able to use the disk for anything else on the system (so if you do use the disk for anything else, performance drops from there, and pretty rapidly). This is why traditional syslog had a reputation for being very slow. See Also -------- * http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html source/compatibility/0000775000175000017500000000000013223143453013711 5ustar rgerrgersource/compatibility/v8compatibility.rst0000664000175000017500000001731313223143030017566 0ustar rgerrgerCompatibility Notes for rsyslog v8 ================================== This document describes things to keep in mind when moving from v7 to v8. It does not list enhancements nor does it talk about compatibility concerns introduced by earlier versions (for this, see their respective compatibility documents). Its focus is primarily on what you need to know if you used v7 and want to use v8 without hassle. Version 8 offers a completely rewritten core rsyslog engine. This resulted in a number of changes that are visible to users and (plugin) developers. Most importantly, pre-v8 plugins **do not longer work** and need to be updated to support the new calling interfaces. If you developed a plugin, be sure to review the developer section below. Mark Messages ------------- In previous versions, mark messages were by default only processed if an action was not executed for some time. The default has now changed, and mark messages are now always processed. Note that this enables faster processing inside rsyslog. To change to previous behaviour, you need to add action.writeAllMarkMessages="off" to the actions in question. Untested Modules ---------------- The following modules have been updated and successfully build, but no "real" test were conducted. Users of these modules should use extra care. - mmsequence - plugins/omgssapi - omsnmp - mmfields - mmpstrucdata - plugins/mmaudit - ommongodb - larger changes still outstanding - ompgsql - plugins/omrabbitmq - not project supported - plugins/omzmq3 - not project supported - plugins/omhdfs (transaction support should be improved, requires sponsor) - omuxsock In addition to bug reports, success reports are also appreciated for these modules (this may save us testing). What Developers need to Know ---------------------------- output plugin interface ~~~~~~~~~~~~~~~~~~~~~~~ To support the new core engine, the output interface has been considerably changed. It is suggested to review some of the project-provided plugins for full details. In this doc, we describe the most important changes from a high level perspective. **Multi-thread awareness required** The new engine activates one **worker**\ instance of output actions on each worker thread. This means an action has now three types of data: - global - action-instance - previously known pData, one for each action inside the config - worker-action-instance - one for each worker thread (called pWrkrData), note that this is specific to exactly one pData The plugin **must** now by multi-threading aware. It may be called by multiple threads concurrently, but it is guaranteed that each call is for a unique pWrkrData structure. This still permits to write plugins easily, but enables the engine to work with much higher performance. Note that plugin developers should assume it is the norm that multiple concurrent worker action instances are active a the some time. **New required entry points** In order to support the new threading model, new entry points are required. Most importantly, only the plugin knows which data must be present in pData and pWrkrData, so it must created and destroy these data structures on request of the engine. Note that pWrkrData may be destroyed at any time and new ones re-created later. Depending on workload structure and configuration, this can happen frequently. New entry points are: - createWrkrInstance - freeWrkrInstance The calling interface for these entry points has changed. Basically, they now receive a pWrkrData object instead pData. It is assumed that createWrkrInstance populates pWrkrData->pData appropriately. - beginTransaction - doAction - endTransaction **Changed entry points** Some of the existing entry points have been changed. The **doAction** entry point formerly got a variable ``iMsgOpts`` which is no longer provided. This variable was introduced in early days and exposed some internal message state information to the output module. Review of all known existing plugins showed that none except omfile ever used that variable. And omfile only did so to do some no longer required legacy handling. In essence, it is highly unlikely that you ever accessed this variable. So we expect that nobody actually notices that the variable has gone away. Removal of the variable provides a slight performance gain, as we do no longer need to maintain it inside the output system (which leads to less CPU instructions and better cache hits). **RS\_RET\_SUSPENDED is no longer supported when creating an action instance** This means a plugin must not try to establish any connections or the like before any of its processing entry points (like beginTransaction or doAction) is called. This was generally also the case with v7, but was not enforced in all cases. In v8, creating action fails if anything but RS\_RET\_OK is returned. string generator interface ~~~~~~~~~~~~~~~~~~~~~~~~~~ Bottom line: string generators need to be changed or will abort. The BEGINstrgen() entry point has greatly changed. Instead of two parameters for the output buffers, they now receive a single ``iparam`` pointer, which contains all data items needed. Also, the message pointer is now const to "prevent" (accidential) changes to the message via the strgen interface. Note that strgen modules must now maintain the iparam->lenStr field, which must hold the length of the generated string on exit. This is necessary as we cache the string sizes in order to reduced strlen() calls. Also, the numerical parameters are now unsigned and no longer size\_t. This permits us to store them directly into optimized heap structures. Specifics for Version 8.3 and 8.4 --------------------------------- Unsupported Command Line Options Removed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The command line options a, h, m, o, p, g, r, t and c were not supported since many versions. However, they spit out an error message that they were unsupported. This error message now no longer appears, instead the regular usage() display happens. This should not have any effect to users. Specifics for Version 8.5 and 8.6 --------------------------------- imfile changes ~~~~~~~~~~~~~~ Starting with 8.5.0, imfile supports wildcards in file names, but does do so only in inotify mode. In order to support wildcards, the handling of statefile needed to be changed. Most importantly, the *statefile* input parameter has been deprecated. See :doc:`imfile module documentation <../../configuration/modules/imfile>` for more details. Command Line Options ~~~~~~~~~~~~~~~~~~~~ There is a small set of configuration command line options available dating back to the dark ages of syslog technology. Setting command-line options is distro specific and a hassle for most users. As such, we are phasing out these options, and will do so rather quickly. Some of them (most notably -l, -s) will completely be removed, as feedback so far indicated they are no longer in use. Others will be replaced by proper configuration objects. **Expect future rsyslog versions to no longer accept those configuration command line options.** Please see this table to see what to use as a replacement for the current options: ========== =========================================================================== **Option** **replacement** -4 global(net.ipprotocol="ipv4-only") -6 global(net.ipprotocol="ipv6-only") -A omfwd input parameter "udp.sendToAll" -l dropped, currently no replacement -q global(net.aclAddHostnameOnFail="on") -Q global(net.aclResolveHostname="off") -s dropped, currently no replacement -S omrelp action parameter "localclientip" -w global(net.permitACLWarning="off") -x global(net.enableDNS="off") ========== =========================================================================== source/compatibility/v6compatibility.rst0000664000175000017500000002643613223143453017603 0ustar rgerrgerCompatibility Notes for rsyslog v6 ================================== This document describes things to keep in mind when moving from v5 to v6. It does not list enhancements nor does it talk about compatibility concerns introduced by earlier versions (for this, see their respective compatibility documents). Its focus is primarily on what you need to know if you used a previous version and want to use the current one without hassle. Version 6 offers a better config language and some other improvements. As the config system has many ties into the rsyslog engine AND all plugins, the changes are somewhat intrusive. Note, however, that core processing has not been changed much in v6 and will not. So once the configuration is loaded, the stability of v6 is quite comparable to v5. Property "pri-text" ------------------- Traditionally, this property did not only return the textual form of the pri ("local0.err"), but also appended the numerical value to it ("local0.err<133>"). This sounds odd and was left unnoticed for some years. In October 2011, this odd behaviour was brought up on the rsyslog mailing list by Gregory K. Ruiz-Ade. Code review showed that the behaviour was intentional, but no trace of what the intention was when it was introduced could be found. The documentation was also unclear, it said no numerical value was present, but the samples had it. We agreed that the additional numerical value is of disadvantage. We also guessed that this property is very rarely being used, otherwise the problem should have been raised much earlier. However, we didn't want to change behaviour in older builds. So v6 was set to clean up the situation. In v6, text-pri will always return the textual part only ("local0.err") and the numerical value will not be contained any longer inside the string. If you actually need that value, it can fairly easily be added via the template system. **If you have used this property previously and relied on the numerical part, you need to update your rsyslog configuration files.** Plugin ABI ---------- The plugin interface has considerably been changed to support the new config language. All plugins need to be upgraded. This usually does not require much coding. However, if the new config language shall be supported, more changes must be made to plugin code. All project-supported plugins have been upgraded, so this compatibility issue is only of interest for you if you have custom plugins or use some user-contributed plugins from the rsyslog project that are not maintained by the project itself (omoracle is an example). Please expect some further plugin instability during the initial v6 releases. RainerScript based rsyslog.conf ------------------------------- A better config format was the main release target for rsyslog v6. It comes in the flavor of so-called RainerScript `(why the name RainerScript?) `_ RainerScript supports legacy syslog.conf format, much as you know it from other syslogds (like sysklogd or the BSD syslogd) as well as previous versions of rsyslog. Initial work on RainerScript began in v4, and the if-construct was already supported in v4 and v5. Version 6 has now taken this further. After long discussions we decided to use the legacy format as a basis, and lightly extend it by native RainerScript constructs. The main goal was to make sure that previous knowledge and config systems could still be used while offering a much more intuitive and powerful way of configuring rsyslog. RainerScript has been implemented from scratch and with new tools (flex/bison, for those in the know). Starting with 6.3.3, this new config file processor replaces the legacy one. Note that the new processor handles all formats, extended RainerScript as well as legacy syslog.conf format. There are some legacy construct that were especially hard to translate. You'll read about them in other parts of this document (especially outchannels, which require a format change). In v6, all legacy formats are supported. In the long term, we may remove some of the ugly rsyslog-specific constructs. Good candidates are all configuration commands starting with a dollar sign, like "$ActionFileDefaultTemplate"). However, this will not be the case before rsyslog v7 or (much more likely) v8/9. Right now, you also need to use these commands, because not all have already been converted to the new RainerScript format. In 6.3.3, the new parser is used, but almost none of the extended RainerScript capabilities are available. They will incrementally be introduced with the following releases. Note that for some features (most importantly if-then-else nested blocks), the v6 core engine is not capable enough. It is our aim to provide a much better config language to as many rsyslog users as quickly as possible. As such, we refrain from doing big engine changes in v6. This in turn means we cannot introduce some features into RainerScript that we really want to see. These features will come up with rsyslog v7, which will have even better flow control capabilities inside the core engine. Note that v7 will fully support v6 RainerScript. Let us also say that the v6 version is not a low-end quick hack: it offers full-fledged syslog message processing control, capable of doing the best you can find inside the industry. We just say that v7 will come up with even more advanced capabilities. Please note that we tried hard to make the RainerScript parser compatible with all legacy config files. However, we may have failed in one case or another. So if you experience problems during config processing, chances are there may be a problem on the rsyslog side. In that case, please let us know. Please see the `blog post about rsyslog 6.3.3 config format `_ for details of what is currently supported. compatibility mode ------------------ Compatibility mode (specified via -c option) has been removed. This was a migration aid from sysklogd and very early versions of rsyslog. As all major distros now have rsyslog as their default, and thus ship rsyslog-compliant config files, there is no longer a need for compatibility mode. Removing it provides easier to maintain code. Also, practice has shown that many users were confused by compatibility mode (and even some package maintainers got it wrong). So this not only cleans up the code but rather removes a frequent source of error. It must be noted, though, that this means rsyslog is no longer a 100% drop-in replacement for sysklogd. If you convert an extremely old system, you need to checks its config and probably need to apply some very mild changes to the config file. abort on config errors ---------------------- Previous versions accepted some malformedness inside the config file without aborting. This could lead to some uncertainty about which configuration was actually running. In v6 there are some situations where config file errors can not be ignored. In these cases rsyslog emits error messages to stderr, and then exists with a non-zero exit code. It is important to check for those cases as this means log data is potentially lost. Please note that the root problem is the same for earlier versions as well. With them, it was just harder to spot why things went wrong (and if at all). Default Batch Sizes ------------------- Due to their positive effect on performance and comparatively low overhead, default batch sizes have been increased. Starting with 6.3.4, the action queues have a default batch size of 128 messages. Default action queue enqueue timeout ------------------------------------ This timeout previously was 2 seconds, and has been reduced to 50ms (starting with 6.5.0). This change was made as a long timeout will caused delays in the associated main queue, something that was quite unexpected to users. Now, this can still happen, but the effect is much less harsh (but still considerable on a busy system). Also, 50ms should be fairly enough for most output sources, except when they are really broken (like network disconnect). If they are really broken, even a 2second timeout does not help, so we hopefully get the best of both worlds with the new timeout. A specific timeout can of course still be configured, it is just the timeout that changed. outchannels ----------- Outchannels are a to-be-removed feature of rsyslog, at least as far as the config syntax is concerned. Nevertheless, v6 still supports it, but a new syntax is required for the action. Let's assume your outchannel is named "channel". The previous syntax was :: *.* $channel This was deprecated in v5 and no longer works in v6. Instead, you need to specify :: *.* :omfile:$channel Note that this syntax is available starting with rsyslog v4. It is important to keep on your mind that future versions of rsyslog will require different syntax and/or drop outchannel support completely. So if at all possible, avoid using this feature. If you must use it, be prepared for future changes and watch announcements very carefully. ompipe default template ----------------------- Starting with 6.5.0, ompipe does no longer use the omfile default template. Instead, the default template must be set via the module load statement. An example is :: module(load="builtin:ompipe" template="myDefaultTemplate") For obvious reasons, the default template must be defined somewhere in the config file, otherwise errors will happen during the config load phase. omusrmsg -------- The omusrmsg module is used to send messages to users. In legacy-legacy config format (that is the very old sysklogd style), it was sufficient to use just the user name to call this action, like in this example: :: *.* rgerhards This format is very ambiguous and causes headache (see `blog post on omusrmsg `_ for details). Thus the format has been superseded by this syntax (which is legacy format ;-)): :: *.* :omusrmsg:rgerhards That syntax is supported since later subversions of version 4. Rsyslog v6 still supports the legacy-legacy format, but in a very strict sense. For example, if multiple users or templates are given, no spaces must be included in the action line. For example, this works up to v5, but no longer in v6: :: *.* rgerhards, bgerhards To fix it in a way that is compatible with pre-v4, use (note the removed space!): :: *.* rgerhards,bgerhards Of course, it probably is better to understand in native v6 format: :: *.* action(type="omusrmsg" users="rgerhards, bgerhards") As you see, here you may include spaces between user names. In the long term, legacy-legacy format will most probably totally disappear, so it is a wise decision to change config files at least to the legacy format (with ":omusrmsg:" in front of the name). Escape Sequences in Script-Based Filters ---------------------------------------- In v5, escape sequences were very simplistic. Inside a string, "\x" meant "x" with x being any character. This has been changed so that the usual set of escapes is supported, must importantly "\n", "\t", "\xhh" (with hh being hex digits) and "\ooo" with (o being octal digits). So if one of these sequences was used previously, results are obviously different. However, that should not create any real problems, because it is hard to envision why someone should have done that (why write "\n" when you can also write "n"?). source/compatibility/v5compatibility.rst0000664000175000017500000000417413223143030017564 0ustar rgerrgerCompatibility Notes for rsyslog v5 ================================== *Written by* `Rainer Gerhards `_ *(2009-07-15)* The changes introduced in rsyslog v5 are numerous, but not very intrusive. This document describes things to keep in mind when moving from v4 to v5. It does not list enhancements nor does it talk about compatibility concerns introduced by earlier versions (for this, see their respective compatibility documents). HUP processing -------------- The $HUPisRestart directive is supported by some early v5 versions, but has been removed in 5.1.3 and above. That means that restart-type HUP processing is no longer available. This processing was redundant and had a lot a drawbacks. For details, please see the `rsyslog v4 compatibility notes `_ which elaborate on the reasons and the (few) things you may need to change. Please note that starting with 5.8.11 HUP will also requery the local hostname. Queue on-disk format -------------------- The queue information file format has been changed. When upgrading from v4 to v5, make sure that the queue is emptied and no on-disk structure present. We did not go great length in understanding the old format, as there was too little demand for that (and it being quite some effort if done right). Queue Worker Thread Shutdown ---------------------------- Previous rsyslog versions had the capability to "run" on zero queue worker if no work was required. This was done to save a very limited number of resources. However, it came at the price of great complexity. In v5, we have decided to let a minimum of one worker run all the time. The additional resource consumption is probably not noticeable at all, however, this enabled us to do some important code cleanups, resulting in faster and more reliable code (complex code is hard to maintain and error-prone). From the regular user's point of view, this change should be barely noticeable. I am including the note for expert users, who will notice it in rsyslog debug output and other analysis tools. So it is no error if each queue in non-direct mode now always runs at least one worker thread. source/compatibility/v7compatibility.rst0000664000175000017500000001711613223143030017566 0ustar rgerrgerCompatibility Notes for rsyslog v7 ================================== This document describes things to keep in mind when moving from v6 to v7. It does not list enhancements nor does it talk about compatibility concerns introduced by earlier versions (for this, see their respective compatibility documents). Its focus is primarily on what you need to know if you used v6 and want to use v7 without hassle. Version 7 builds on the new config language introduced in v6 and extends it. Other than v6, it not just only extends the config language, but provides considerable changes to core elements as well. The result is much more power and ease of use as well (this time that is not contradictionary). BSD-Style blocks ---------------- BSD style blocks are no longer supported (for good reason). See the `rsyslog BSD blocks info page `_ for more information and how to upgrade your config. CEE-Properties -------------- In rsyslog v6, CEE properties could not be used across disk-based queues. If this was done, their content was reset. This was a missing feature in v6. In v7, this feature has been implemented. Consequently, situations where the previous behaviour were desired need now to be solved differently. We do not think that this will cause any problems to anyone, especially as in v6 this was announced as a missing feature. omusrmsg: using just a username or "*" is deprecated ---------------------------------------------------- In legacy config format, the asterisk denotes writing the message to all users. This is usually used for emergency messages and configured like this: :: *.emerg * Unfortunately, the use of this single character conflicts with other uses, for example with the multiplication operator. While rsyslog up to versions v7.4 preserves the meaning of asterisk as an action, it is deprecated and will probably be removed in future versions. Consequently, a warning message is emitted. To make this warning go away, the action must be explicitly given, as follows: :: *.emerg :omusrmsg:* The same holds true for user names. For example :: *.emerg john at a minimum should be rewritten as :: *.emerg :omusrmsg:john Of course, for even more clarity the new RainerScript style of action can also be used: :: *.emerg action(type="omusrmsg" users="john") In Rainer's blog, there is more `background information on why omusrmsg needed to be changed `_ available. omruleset and discard (~) action are deprecated ----------------------------------------------- Both continue to work, but have been replaced by better alternatives. The discard action (tilde character) has been replaced by the "stop" RainerScript directive. It is considered more intuitive and offers slightly better performance. The omruleset module has been replaced by the "call" RainerScript directive. Call permits to execute a ruleset like a subroutine, and does so with much higher performance than omruleset did. Note that omruleset could be run off an async queue. This was more a side than a desired effect and is not supported by the call statement. If that effect was needed, it can simply be simulated by running the called rulesets actions asynchronously (what in any case is the right way to handle this). Note that the deprecated modules emit warning messages when being used. They tell that the construct is deprecated and which statement is to be used as replacement. This does **not** affect operations: both modules are still fully operational and will not be removed in the v7 timeframe. Retries of output plugins that do not do proper replies ------------------------------------------------------- Some output plugins may not be able to detect if their target is capable of accepting data again after an error (technically, they always return OK when TryResume is called). Previously, the rsyslog core engine suspended such an action after 1000 successive failures. This lead to potentially a large amount of errors and error messages. Starting with 7.2.1, this has been reduced to 10 successive failures. This still gives the plugin a chance to recover. In extreme cases, a plugin may now enter suspend mode where it previously did not do so. In practice, we do NOT expect that. omfile: file creation time -------------------------- Originally, omfile created files immediately during startup, no matter if they were written to or not. In v7, this has changed. Files are only created when they are needed for the first time. Also, in pre-v7 files were created *before* privileges were dropped. This meant that files could be written to locations where the actual desired rsyslog user was *not* permitted to. In v7, this has been fixed. This is fix also the prime reason that files are now created on demand (which is later in the process and after the privilege drop). Notes for the 7.3/7.4 branch ---------------------------- "last message repeated n times" Processing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This processing has been optimized and moved to the input side. This results in usually far better performance and also de-couples different sources from the same processing. It is now also integrated in to the more generic rate-limiting processing. User-Noticable Changes ...................... The code works almost as before, with two exceptions: * The suppression amount can be different, as the new algorithm precisely check's a single source, and while that source is being read. The previous algorithm worked on a set of mixed messages from multiple sources. * The previous algorithm wrote a "last message repeated n times" message at least every 60 seconds. For performance reasons, we do no longer do this but write this message only when a new message arrives or rsyslog is shut down. Note that the new algorithms needs support from input modules. If old modules which do not have the necessary support are used, duplicate messages will most probably not be detected. Upgrading the module code is simple, and all rsyslog-provided plugins support the new method, so this should not be a real problem (crafting a solution would result in rather complex code - for a case that most probably would never happen). Performance Implications ........................ In general, the new method enables far faster output processing. However, it needs to be noted that the "last message repeated n" processing needs parsed messages in order to detect duplicated. Consequently, if it is enabled the parser step cannot be deferred to the main queue processing thread and thus must be done during input processing. The changes workload distribution and may have (good or bad) effect on the overall performance. If you have a very high performance installation, it is suggested to check the performance profile before deploying the new version. **Note:** for high-performance environments it is highly recommended NOT to use "last message repeated n times" processing but rather the other (more efficient) rate-limiting methods. These also do NOT require the parsing step to be done during input processing. Stricter string-template Processing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Previously, no error message for invalid string template parameters was generated. Rather a malformed template was generated, and error information emitted at runtime. However, this could be quite confusing. Note that the new code changes user experience: formerly, rsyslog and the affected actions properly started up, but the actions did not produce proper data. Now, there are startup error messages and the actions are NOT executed (due to missing template due to template error). source/compatibility/index.rst0000664000175000017500000000024713223143030015544 0ustar rgerrgerCompatibility ============= .. toctree:: :glob: v8compatibility v7compatibility v6compatibility v5compatibility v4compatibility v3compatibility source/compatibility/v3compatibility.rst0000664000175000017500000002527013223143030017562 0ustar rgerrgerCompatibility Notes for rsyslog v3 ================================== *Written by* `Rainer Gerhards `_ *(2008-03-28)* Rsyslog aims to be a drop-in replacement for sysklogd. However, version 3 has some considerable enhancements, which lead to some backward compatibility issues both in regard to sysklogd and rsyslog v1 and v2. Most of these issues are avoided by default by not specifying the -c option on the rsyslog command line. That will enable backwards-compatibility mode. However, please note that things may be suboptimal in backward compatibility mode, so the advise is to work through this document, update your rsyslog.conf, remove the no longer supported startup options and then add -c3 as the first option to the rsyslog command line. That will enable native mode. Please note that rsyslogd helps you during that process by logging appropriate messages about compatibility mode and backwards-compatibility statements automatically generated. You may want your syslogd log for those. They immediately follow rsyslogd's startup message. Inputs ------ With v2 and below, inputs were automatically started together with rsyslog. In v3, inputs are optional! They come in the form of plug-in modules. **At least one input module must be loaded to make rsyslog do any useful work.** The config file directives doc briefly lists which config statements are available by which modules. It is suggested that input modules be loaded in the top part of the config file. Here is an example, also highlighting the most important modules: :: $ModLoad immark # provides --MARK-- message capability $ModLoad imudp # provides UDP syslog reception $ModLoad imtcp # provides TCP syslog reception $ModLoad imgssapi # provides GSSAPI syslog reception $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) Command Line Options -------------------- A number of command line options have been removed. New config file directives have been added for them. The -h and -e option have been removed even in compatibility mode. They are ignored but an informative message is logged. Please note that -h was never supported in v2, but was silently ignored. It disappeared some time ago in the final v1 builds. It can be replaced by applying proper filtering inside syslog.conf. -c option / Compatibility Mode ------------------------------ The -c option is new and tells rsyslogd about the desired backward compatibility mode. It must always be the first option on the command line, as it influences processing of the other options. To use the rsyslog v3 native interface, specify -c3. To use compatibility mode , either do not use -c at all or use -c where vers is the rsyslog version that it shall be compatible to. Use -c0 to be command-line compatible to sysklogd. Please note that rsyslogd issues warning messages if the -c3 command line option is not given. This is to alert you that your are running in compatibility mode. Compatibility mode interferes with your rsyslog.conf commands and may cause some undesired side-effects. It is meant to be used with a plain old rsyslog.conf - if you use new features, things become messy. So the best advise is to work through this document, convert your options and config file and then use rsyslog in native mode. In order to aid you in this process, rsyslog logs every compatibility-mode config file directive it has generated. So you can simply copy them from your logfile and paste them to the config. -e Option --------- This option is no longer supported, as the "last message repeated n times" feature is now turned off by default. We changed this default because this feature is causing a lot of trouble and we need to make it either go away or change the way it works. For more information, please see our dedicated `forum thread on "last message repeated n times" `_. This thread also contains information on how to configure rsyslogd so that it continues to support this feature (as long as it is not totally removed). -m Option --------- The -m command line option is emulated in compatibility mode. To replace it, use the following config directives (compatibility mode auto-generates them): :: $ModLoad immark $MarkMessagePeriod 1800 # 30 minutes -r Option --------- Is no longer available in native mode. However, it is understood in compatibility mode (if no -c option is given). Use the ``$UDPSeverRun `` config file directives. You can now also set the local address the server should listen to via ``$UDPServerAddress `` config directive. The following example configures an UDP syslog server at the local address 192.0.2.1 on port 514: :: $ModLoad imudp $UDPServerAddress 192.0.2.1 # this MUST be before the $UDPServerRun directive! $UDPServerRun 514 ``$UDPServerAddress \*`` means listen on all local interfaces. This is the default if no directive is specified. Please note that now multiple listeners are supported. For example, you can do the following: :: $ModLoad imudp $UDPServerAddress 192.0.2.1 # this MUST be before the $UDPServerRun directive! $UDPServerRun 514 $UDPServerAddress \* # all local interfaces $UDPServerRun 1514 These config file settings run two listeners: one at 192.0.2.1:514 and one on port 1514, which listens on all local interfaces. Default port for UDP (and TCP) Servers -------------------------------------- Please note that with pre-v3 rsyslogd, a service database lookup was made when a UDP server was started and no port was configured. Only if that failed, the IANA default of 514 was used. For TCP servers, this lookup was never done and 514 always used if no specific port was configured. For consistency, both TCP and UDP now use port 514 as default. If a lookup is desired, you need to specify it in the "Run" directive, e.g. "*$UDPServerRun syslog*\ ". klogd ----- klogd has (finally) been replaced by a loadable input module. To enable klogd functionality, do :: $ModLoad imklog Note that this can not be handled by the compatibility layer, as klogd was a separate binary. A limited set of klogd command line settings is now supported via rsyslog.conf. That set of configuration directives is to be expanded.  Output File Syncing ------------------- Rsyslogd tries to keep as compatible to stock syslogd as possible. As such, it retained stock syslogd's default of syncing every file write if not specified otherwise (by placing a dash in front of the output file name). While this was a useful feature in past days where hardware was much less reliable and UPS seldom, this no longer is useful in today's world. Instead, the syncing is a high performance hit. With it, rsyslogd writes files around 50 **times** slower than without it. It also affects overall system performance due to the high IO activity. In rsyslog v3, syncing has been turned off by default. This is done via a specific configuration directive :: $ActionFileEnableSync on/off which is off by default. So even if rsyslogd finds sync selector lines, it ignores them by default. In order to enable file syncing, the administrator must specify ``$ActionFileEnableSync on`` at the top of rsyslog.conf. This ensures that syncing only happens in some installations where the administrator actually wanted that (performance-intense) feature. In the fast majority of cases (if not all), this dramatically increases rsyslogd performance without any negative effects. Output File Format ------------------ Rsyslog supports high precision RFC 3339 timestamps and puts these into local log files by default. This is a departure from previous syslogd behaviour. We decided to sacrifice some backward-compatibility in an effort to provide a better logging solution. Rsyslog has been supporting the high-precision timestamps for over three years as of this writing, but nobody used them because they were not default (one may also assume that most people didn't even know about them). Now, we are writing the great high-precision time stamps, which greatly aid in getting the right sequence of logging events. If you do not like that, you can easily turn them off by placing :: $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat right at the start of your rsyslog.conf. This will use the previous format. Please note that the name is case-sensitive and must be specified exactly as shown above. Please also note that you can of course use any other format of your liking. To do so, simply specify the template to use or set a new default template via the $ActionFileDefaultTemplate directive. Keep in mind, though, that templates must be defined before they are used. Keep in mind that when receiving messages from remote hosts, the timestamp is just as precise as the remote host provided it. In most cases, this means you will only a receive a standard timestamp with second precision. If rsyslog is running at the remote end, you can configure it to provide high-precision timestamps (see below). Forwarding Format ----------------- When forwarding messages to remote syslog servers, rsyslogd by default uses the plain old syslog format with second-level resolution inside the timestamps. We could have made it emit high precision timestamps. However, that would have broken almost all receivers, including earlier versions of rsyslog. To avoid this hassle, high-precision timestamps need to be explicitly enabled. To make this as painless as possible, rsyslog comes with a canned template that contains everything necessary.  To enable high-precision timestamps, just use: :: $ActionForwardDefaultTemplate RSYSLOG_ForwardFormat # for plain TCP and UDP $ActionGSSForwardDefaultTemplate RSYSLOG_ForwardFormat # for GSS-API And, of course, you can always set different forwarding formats by just specifying the right template. If you are running in a system with only rsyslog 3.12.5 and above in the receiver roles, it is suggested to add one (or both) of the above statements to the top of your rsyslog.conf (but after the $ModLoad's!) - that will enable you to use the best in timestamp support available. Please note that when you use this format with other receivers, they will probably become pretty confused and not detect the timestamp at all. In earlier rsyslog versions, for example, that leads to duplication of timestamp and hostname fields and disables the detection of the original hostname in a relayed/NATed environment. So use the new format with care. Queue Modes for the Main Message Queue -------------------------------------- Either "FixedArray" or "LinkedList" is recommended. "Direct" is available, but should not be used except for a very good reason ("Direct" disables queueing and will potentially lead to message loss on the input side). source/compatibility/v4compatibility.rst0000664000175000017500000001371213223143030017561 0ustar rgerrgerCompatibility Notes for rsyslog v4 ================================== *Written by* `Rainer Gerhards `_ *(2009-07-15)* The changes introduced in rsyslog v4 are numerous, but not very intrusive. This document describes things to keep in mind when moving from v3 to v4. It does not list enhancements nor does it talk about compatibility concerns introduced by v3 (for this, see the `rsyslog v3 compatibility notes `_). HUP processing -------------- With v3 and below, rsyslog used the traditional HUP behaviour. That meant that all output files are closed and the configuration file is re-read and the new configuration applied. With a program as simple and static as sysklogd, this was not much of an issue. The most important config settings (like udp reception) of a traditional syslogd can not be modified via the configuration file. So a config file reload only meant setting up a new set of filters. It also didn't account as problem that while doing so messages may be lost - without any threading and queuing model, a traditional syslogd will potentially always loose messages, so it is irrelevant if this happens, too, during the short config re-read phase. In rsyslog, things are quite different: the program is more or less a framework into which loadable modules are loaded as needed for a particular configuration. The software that will actually be running is tailored via the config file. Thus, a re-read of the config file requires a full, very heavy restart, because the software actually running with the new config can be totally different from what ran with the old config. Consequently, the traditional HUP is a very heavy operation and may even cause some data loss because queues must be shut down, listeners stopped and so on. Some of these operations (depending on their configuration) involve intentional message loss. The operation also takes up a lot of system resources and needs quite some time (maybe seconds) to be completed. During this restart period, the syslog subsystem is not fully available. From the software developer's point of view, the full restart done by a HUP is rather complex, especially if user-timeout limits set on action completion are taken into consideration (for those in the know: at the extreme ends this means we need to cancel threads as a last resort, but than we need to make sure that such cancellation does not happen at points where it would be fatal for a restart). A regular restart, where the process is actually terminated, is much less complex, because the operating system does a full cleanup after process termination, so rsyslogd does not need to take care for exotic cleanup cases and leave that to the OS. In the end result, restart-type HUPs clutter the code, increase complexity (read: add bugs) and cost performance. On the contrary, a HUP is typically needed for log rotation, and the real desire is to close files. This is a non-disruptive and very lightweight operation. Many people have said that they are used to HUP the syslogd to apply configuration changes. This is true, but it is questionable if that really justifies all the cost that comes with it. After all, it is the difference between typing :: $ kill -HUP `cat /var/run/rsyslogd.pid` versus :: $ /etc/init.d/rsyslog restart Semantically, both is mostly the same thing. The only difference is that with the restart command rsyslogd can spit config error message to stderr, so that the user is able to see any problems and fix them. With a HUP, we do not have access to stderr and thus can log error messages only to their configured destinations; experience tells that most users will never find them there. What, by the way, is another strong argument against restarting rsyslogd by HUPing it. So a restart via HUP is not strictly necessary and most other daemons require that a restart command is typed in if a restart is required. Rsyslog will follow this paradigm in the next versions, resulting in many benefits. In v4, we provide some support for the old-style semantics. We introduced a setting $HUPisRestart which may be set to "on" (traditional, heavy operation) or "off" (new, lightweight "file close only" operation). The initial versions had the default set to traditional behavior, but starting with 4.5.1 we are now using the new behavior as the default. Most importantly, **this may break some scripts**, but my sincere belief is that there are very few scripts that automatically **change** rsyslog's config and then do a HUP to reload it. Anyhow, if you have some of these, it may be a good idea to change them now instead of turning restart-type HUPs on. Other than that, one mainly needs to change the habit of how to restart rsyslog after a configuration change. **Please note that restart-type HUP is deprecated and will go away in rsyslog v5.** So it is a good idea to become ready for the new version now and also enjoy some of the benefits of the "real restart", like the better error-reporting capability. Note that code complexity reduction (and thus performance improvement) needs the restart-type HUP code to be removed, so these changes can (and will) only happen in version 5. outchannels ----------- Note: as always documented, outchannels are an experimental feature that may be removed and/or changed in the future. There is one concrete change done starting with 4.6.7: let's assume an outchannel "mychannel" was defined. Then, this channel could be used inside an \*.\* $mychannel This is still supported and will remain to be supported in v4. However, there is a new variant which explicitly tells this is to be handled by omfile. This new syntax is as follows: \*.\* :omfile:$mychannel Note that future versions, specifically starting with v6, the older syntax is no longer supported. So users are strongly advised to switch to the new syntax. As an aid to the conversion process, rsyslog 4.7.4 and above issue a warning message if the old-style directive is seen -- but still accept the old syntax without any problems. source/direct_queue_directq.png0000664000175000017500000002353312704114446015750 0ustar rgerrgerPNG  IHDRVsBITO pHYs IDATxwxTU?N @ @D HQ.bE몈(K}AIOwEt $HH!qycL=33wrs>O<3wN͝9s="pwwͭRۑŨ. U8 !BBQH\?Ԏ;X,Zׄ@wT9~g-,q!)R*~CҎo^;!B69V2:7 @Qb47:Wģ$`0ߐeEitb3'3y;ہ,vGs.`xwoP(D{k K~_{GkMi:F;`֋Eg_s*N]Q&VaV|ItB"BFGdĦ.KL[, (/ŗNZ!CY(-?bALAS4W+Z'; oNWùy{Nr2`8G9ꍷ&'C7$- IO\՞/J_65;!5$ƯїMhz2]RU~3y/`(6e4i!9IH %O/yzҴ)IH燿?YkΣ@g:;-}fQ. ⭒>y0hGԫ(toC" ,, iXОАpΥK,]…'.&M$4bJʅvc^xIpHq`& ЄlЪ%qI\ &TU!%jEjZїydcp 6owȑ~mڴǏ߸qaRRRzq{ܹs1117n|g/_ܩS7iiiڵ۴iӤI222ڴiyӧggg7oӧ{k׮z뭻K{kjJK /qcq?_:J&NځWQ.6aaaO<ĠAFٿz=} [kԨQV{7$$Fݺu]vPPPttt=֭[jը*Ul2666,,ãQFݺu B6h֭[k޽{Æ 322wqժU;8w\\\ddS,KϞ=###;۫Wgff722r׮]ׯ_0`@ddmۮ\2x;!'jg"^ns jCR P<K˒%-nde?DTG@'t)$$0p;1ѩD P<4Yýjb W+]E隨2&;hC+\#^ִnLIL&;7 tĦx>y;Vƶ& MHZ\r#Ů,PBo#-XjQGHr=< gI_O~3xpa \’ PQ2#'[ͯp~n͞| $2ȸOhM/ˆ3T={2wG XJP+"#$xըH\ZArod_օ.թ}7Qz@$BГma@q X֍n3і@g:OfM:gJڌb1Hېje֡N[juLf&#FZIbyh"Ϳl |">%j'w$$!Zy {NhJdIqb:-4$#E|kF}';s~9ˁY$bZB`ƍ̚7]ra_ӢSHR 391s \jW:dU<s*Zq4ӧe&O'Ml# *$,. iL(5^LhMntSfNkW&LIxa~ ,B6{iww~ $3]ba5@6јc_{Ԥ|}믓 /ȷ&51̊>qXd 1 iLO4:HT۔u7.R\e^Sǜ. 䱌L~k#2 BbkL+\Y*cSE1.@o߾ez{{m־P_g > ɯ7BrS>2MNNoU^u-ZhaMJJ_lջlٲw[Sm?j]YkmC-|=Dj__߉'fϝ;ʟ؂O4isWoRRg}VfFҷoÇW… WZU𸸸gywOk.`~(S%NwuWYOʋ sW~իLӳp![Q%: 3X͛$$N^:څ.c&6xucf=5JVnw87EǎԨc^e#<ta}׸VuZ/F㒴Jlo/ѶcDGS "+e(tD{[jKZ$Fg̘?#}p]^S*i9_rp:ժQ iix@F%.U%ӧ$+(7 bcϸ#mfsLbѱTxBOݶ"y4SR )- c١wTfR::S֮MrrOsn m[|mY %13Ҳƌ3&Z},E)oJa;s(W ̬̎u@镑{yU7FVY HO- ,TRZwo Xps_ѧn!_B|KLYf!%tV@hVSB`/|[3y2OOz4nꓨc\plMi-wsF}eK.9S13?fe˖b˖L5d%Ϗm.]Gsj%r=0*7or^^6J[Цu# 7+SifLĐ!6*{*EWx%0:ıcX4i#W`+[uMx13t퟊"Xt zSu 9}~}I8|YF d۪s) jiE s+5e.'4lNr2zNѨECpZa@ Vz>֙Q8wE]0W &[\lΟ(0e K@(`tmkrlS&J ǥV+]dgc^1h5` .v#FR)u //{KL0pkBQ:.nChR8|lZ\Z@8EBInG~'|*SNpp nP` +{{S8gt 8r,%.vjP`8+d7QTb22ZqQ $3n~AO~zݺukk- Q#9afݼYժ+7o\b^1TB:u=-_|s ߿ɒI%d?oΟ?…#G,wŰaÆ~)((ݽffyrK׮] Qm|yK96JNN~G2o޼?IGۣKO֌fy䥐"Yju*ĸq㒋.JxxxKPf_ N޷==";\<<8{_fbn޼FDDHmW6ٹzH{M4ԩdEA?.`ԨQN?\K',|, 0^z2-A֑/ƍSO͞=k5kұ#OԪ/99p!Sp:u0ęwڵ$;l%J*@\\,_X<2|'Tֽ{la6S!>s2%;ZWL0!A68՚[O?ͼy '2e w{yiƌ, `u̢UaqʃShL5tfh j}t{D '/%ر`YcDPI8U4*yw{$KV Oi-kWFL{~&$".,g-X|S]I RPj/=TY;KpQp'wv˒%k 9*f)eRq6GFr=g,_aC( ux!Svyy7/|pܸ2ׯ:sի價,8ũ,ϥ$@G p2J@/Y%KN>ݭ[rW2==?ah|u >$S2qю@:6\Zu8VsHTу!T{$d~ӜM %$@G\#IfU['` -B=hs{O?$_I !'N`mRքn;!]-x"?CJt]@ i]SL`CyE7vXTR '2* WtVkD.9$Fn >57\r3k\{̮$@G\tUSaS˹Q媕첉/8Nj}C>,* Wt~@S`G"^M'XP%:.:opc CjU G` аhJ7|sCf4&B}ӥ$@Gw:]&iW ];MiL"XoHC`Np>GL2 Qƻ+~ jAMj֡6]gz˙~t|09G82kK/s@ NT1~p6>9 Ԥf]^D&|Jh?93ڂh%w~8On/=i 8P)*  \pC<)ncG|4Y6xwc~p,cڄ9$0BpkJӒ Q#NmT% Z|GiK@$Hbxa,9$@æX@Q;YÁmh%B@m#z0 (J.tÁLejeB`(XU\PjE7Iw;60ZGp Jtą\0Q(9ē<)0(. Y*8iR0h>;#`,vcXAei p'Nn[(`,4^I)jժYYY匰$!v`kG@aYR.X\թM#oOt)YZW ,:G@0~paL{_ T莀}gIc1`vW 9iIKɒVbQ[`EA'%Fa=2._5Hb #~0=8h+M H8p8z sIf*P1 phTt p@*"HQ9]@'?)@ VD `k#:0hȷ[@ED)!o=BTD `+(`,.:A&؄upTG(TG@Q0h PcQÁRCEAEQp[Q.2 %6!rl pww]vjlG K&TNԩSF }-9$U={֨TGX5kv},9$@qÁ:b'` pEAP.XpE Cl [ \( $:j8X05 C\#:Jt @ō(Gw 00wQP 5(9$@qSC L r08zv}(`,Hao((rRTNfV jUGX . *\[Q+jjfW@cQ5;Zy dS#Ha pفP#j8P sH\/gG/"$@G0x={8t0sH@gq1p0A,is_#ʟ#*1 pf[[v~F}ȇZ6eT#Ha /! KK\(=$x Q@* 0hr,X169+Ǿ4lͫ$@G `w,qMvc8/b>_?$@G P_2O<1m cl VC9㿊U-iiG!JtD)$v! Y |1%-V2o:7/%:\搀ߏ~;ٔG9CP`G"6SjLHGP#Hao[9˝ܹ}SW|Յ.59kY[“\Ū)LN{w s11 N@x7}ʧYNcR MvAEO'yr cB)Jt W %t*S'3k1uӚDwk,tkJt w :sH#wm(CL'݊Պ@uNCI( 9$ qL`$@GEA)!=|rRC4LrrRC*z( 08nW^uh-Jt W.][r>fI&۷CAA؁1üW^y%%%%>>^I@8!~(%:b>6Ж$a@%((J*qj7!ITG@Q0(q.( \H$¡\ 1 X,J\% yyyY$@uE.9c POV rT[Q.@Q\(Ha pJ*Ha& PEA :TU؊C[Έ#ׯ*P+NM߆o8n0 sH3f@I8[,K^^B/ ୷ҥRx75jJ޽۵kgt eiiiJɿl^^^nݲZҫP(dp 8qbE p P(.;#IENDB`source/module_workflow.png0000664000175000017500000003463512704114446015003 0ustar rgerrgerPNG  IHDR^NAsBITO pHYs IDATxi\S׺3D@@TuUWmjjUbέQPElUy C¾99)섀MK*kk0 +- , , , , , u^ڳgϮ]u]xX^$IXXXXXXMMM͛w^N M nݺovĉ.]zٙ3g6mڤ{?͛7\5wwwX|Ç˾tɓ'͙3'** A ::D2lذ[n};wlA$ܼ#P DCGgkk+X8;;?~ʕ+#Fh@S\z011 ?PGG'77=K͆huuuM/^A={_~!Xh8DCGgmm=vEvyffff.]۹6`ݻ0**СC^MNN0a!WK 7AepB=l۶mٲegg]tyYf䓘sssν{n3dȐ &~ hV\~##ӧOWɭ~L!$44T%;|2?oQᝂhn߾mbbBUx>Oپ} w DXN `AnH)X:*XhRKTK Qr锪` /R,} h)U,hDC{cZtJU hho[:*XJB4Y:*X@4?mNt VVVVyy9@+-))iܸq\WA!>ttt 7A4 P D@4 D@4 D@4 D@4 D@4 D@4 DC{HIIxTTTx<P~jkkݻG֭(hh?눈@W+**-,,̂hΝ;wnhhhmmuVysqqfffӧO/**=sssgcŋ/2 ͛k<}H$bߟv̘13gά,,,6ltD FC}}CCC-[Fiׯ_xOoS0 SPP_~-k+Wa !ݞ:u(o8)DC{FÑ#G>|( >$}ԩSG6222d)6:ujȐ!:u211166{~!n%(B4i4TWWIi"WPP o555֭bmǏr ݳYC4d?ÇX.]իWdBHVVVbbbmm gm@OO/'''44>XzuUUUQQі-[ hhoիWH@ЧO@0rHz,P__7XXXGEE9rn˖-wڴi-..9swȉ'.]J/p(Y{G!YYYׯ"P WZZmdd4`q]Pظp] h,Ǎwq]h2D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 aZ6 jbŊÆ cM+Vgdda j@WWѣ7ouTooQFp]ZJMMMHH7\uy۶m\mشi!k׮?c}}=K. 2)++"heUWWϞ= P=P(E"|W\\WĽ GYYYݻw֖@p_R.]zH\zy#GN4@ ۿΝ;OrA1mm0BȆ F3` D"...DNNN\n޼9x`kY\[qqq޽ J!$$$p]A.O\] )))<O,pP/_RQQallҥ\t?A)SD@4CBȑ#./jkkݻG֭1b=eu- rBvLgԩS]I#""G}T[[Ke6bffflltHuDDD~~~&&&/^J?~˵kdmTC***-,,̂ bH7 :2D\4lll$&&~{u߾}?isҞ={\OO>:9s;vL,geeD"//FҮ_.+00Ĥ… R' .))|˗/W\?}[˵]۔)S\\\btbO`үsrrK7nӓD"~ĉnݺ5VmvƏl2 пƢ5մׯ_xO֊4??qݾ}[q7lH~.](8Pvvv {{,,((("""55566^Nlooh,_&;aX=޽{}] ~p@! Ce4h!~__ .ȶ=geeIǢhl y5D7o(>@ZuA.Dڵk!={ԩSxxD"yiΝ;B222M__nnii9vUVUVVұ ھfZ͛iy5HYXX.]>2???99YAabP[[[:{hwބׯƍܣG}Btuu8`bbGўݺu[pA̚K 8W^MۣbM>} n:YRRbiiIOU*AVdd@ ӧ@ 9r7olhhprrVWRR!o5ϗ_~IYlׅ ` רQLMMSSSOkQDF rL8gkQ.]z䉹q] V^*r}}O*y[仉aCaaajEf̘Q]]-=N:|\YC3>}"H&Ou9QNNG^^? {{850{lb dUWWO:5//oȑ\*YC3gÇ޽+H$qqq9`<>{W^ϕzzzř$$$ 4 A)^^^Fڳg;>ߜ]fggwҥ>}p][Xd7>>8#___ l\WmZ,!!atP(1c}uؓ'O9sa}} 6,YDK Ö́hhq҅vvv666VVV-}kǤJuuu,XzjczIII Xu7dȐ7oү Ǝ;eooo»Ѡ"(;;;//Mzɓ'?u6ښUކm:t(=gΜ9sDEEq] h,C`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`vrՃr]fϞ=fez"]! G7n\= '--rs]Krttܽ{w;jԨy|jaٲe>>>qqqͦAB򸮥 nb߮]>Yt@4+kkCq]E ʹ|rKKݻw7ue``:vIi6pBaѢE>>>III e.j6 (hPuuu;v`}ٳmt4t@4b}}%K<s̡ڿ0/ՀEΝ\"޽{KJJx<ɓ*HVVqO?4::̙3GF4 \v믿&9ޞ@mۯZJA@P^^hP_j8׏6J ܖjĉ;L6~s j#,,rڵ2ڂ)Dژ?0ϟ'cʠ*:::֭#[NGGmv 5mi! 8^"2g!Ϟ=vgNII-i ! 8B0ePΝ;gddK["##BP(tss;ӧg̘A_ڱcիjB]$B'NؿܺuKVSN۷ѣGt8H! ,XN!?Jߍ5rݻw !TnO n^BB_||m͕H$ dddٳatQ90̑#G?}40= ʛ>}͛H$M ڴxo%-I[[[[DSN6aDr]K$***;oڍ7FM2 lٲ}=ydСF aLMM]Nކeee-M ` iI|>_^_/gT(--MvzzzVUUB.\sx<!aW f}lZ2Gh)DC+DGGZYY=zF-//6lX gnn.mlllmmuT5ҭ[7ozA>lťСCߗabccg̘@;v߾}_|08p ^^^?ݻ7-bffomm-pC%2 ۡ`vMֆ5iv-D.]+VHKKk7_=k֬JBȼy&N8e===ݻ^}DFF._<,,uǴꢤdĈNNN&M⺖Ta0JL>B֨Qm&|||wpkΝ;u{T ѠHmm]}[n)`=zDGG_tr:#Fܾ}_~ϟ?0a›7oT Ak׮#{]~W^O< H$\WԱ_E[tJ nܸ</**o߾\Abb寿fXZ N)B"| k֬aoonJ2}}͛7ݛSקK<<<شO5Q uuuՊEPʯR ?"""!=zwCBf͚=-O߳g0t UuJK&NG5QJ.P]o˫7O\ע^xa``߿ߺ=p UUUoS]:ejjG5QJ.j2W)r/^; ZRn.\m۶={s]N hkkHe.bkn c-]6pBH``fצfϞMIHH`6|N{"0Lll,!$66Vvl5Qzzzk!]Ew.})V]3gΔ6ŏh_~"&gllllllff흙پ5K[***[et?v-P(v˗kGxxxrrr߾}L={V(nٲ~}>۶m5jGIIŋ<|piȦرcB0))I:{C ]7c 77W!4IDAT7333iKzzzmqĢh~+x^__0̫WΝ̞fmi z{.m'[[f;BBB!7nlŶ\khe?..v.{0@Ν:uZp!]o>@`ff6}"QQQ;wvz֭t?fffAAAUUU6(}0dDDDB??? ŋ\v66țM) 7B%%%s/Úmll\RR{nd[[OѿԹsRRR^x>,**J$yyy%%%ʕ+nt9s;vL,geeM*qҮ_@ .:tEo:annnRt.\ %>Q__ȑ \zl_>VLWW?~X(ѓ?H$211!Xbܹ۷oomSgΜIII R\\nddddd_/Ydƍʼn"pŊҏ*j:arrr+NIȁCvttl|^qqqnڴ)==]"444TTTH_>V;vX|y~6n陓0;0L}}}mYEDDnEiKiooO[LYlJ[[&///55UQ@4EMMͳgsWXX8}#Gx{{]zuȑ=}}}}}}kkk7m4ŝ.]x8ggg;99/h쉊 z޻X-$//oС{mEb;B@OO/'''44[VVVzzQtuuMLLwҥ;w477رcW__M8,--ǎjժȪ0zm_f́*++7oLٳSN+Vc] :Y^A<<&&*:7o6 .]DcKKKccc'' R+yyy>>><$$;ٙ^OٳǁXgSz󫯾RЧы,<6EyyX,.((ܹ3娱C޼y3..>>\Y KK/'/%gΜYVV\Pwv_} |}}/1e˖%%%Y[[@E8]]TUUIkеkcǎ544p]\Aߖ?33@pRYUތ&NڣGy#0 dee=}4666&&ݶCBBn`&:::***11Q]KKk„ m`$;;D?ްaH(,,޽|=`|TC4@yyyiii/|||ψ|>А>xʓ <@&$\`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h| h?۷o .ꆆ4Çߺu*8vx YtUpŋ۷oONN2eJhP?w%999q]KڵKTϿoݧZsιs^zL: OMM !ZڜX,ѣG7uս{w9PrrrFuwʤA]=zp]EL:wMՍ: QRwt@4?߹sMš5PTTdmmcǎаdwwm۶qRX\ȦSN'NҥKrrɓqR XZZeggGߗ})44RKKk޼y\BGG'//_~:H$-- .\v Ѡv5eʔTىCCC֭[ !U?>11B]x{{A}Q:eطowfB4]vBRSSh n:BȺuy**hP([^Ӗf)_AmH'.\ ~SU~!ٳgٳgȖ״E NJJJ!o޼!2NΝ322dHP( Ο?3fЗvرzjyZ`P(twwD' $S\\aZ@0ԴLit8@ -+xhK5C8dgg,jK[ťСC3gΔabcc ! Æ #;80}~ŋBe7ltCҒbccQ\Za?#...;;;/////^6^jmmݞikkwsoy#۶mۨQ,,,Wf̘qu333y[7jkk>|>o޼H$S8uhkkWX Xz!Clmmoܸt;vyxx4( /_tZ{ݻ-<נ<8\C <o9|pCC!sγgvqqylmm-,,Zw,v***rssbbb*..w}7zhklC%%%#Fprr4i׵ CCkhhXl!DGG'44455:ݻwKgӧOP;AIg 8 )WUU̙3n񂂂222֬Y`;`…999aaaǏwww)u 8;;?~޽;EuP+W'O  =C /++w7oޜ0a{{ׯWVVN<# [___KT "$$ƍvvvW^ݻ7 ##Ǐ~LJh mtJsA##xKKKQ3</::Y(y`ǡyf777:%}}}tÃlڧњC º:(}(k+A)K5>!ڱZXXB;u-j^HNNnN ߳g0t UuJK&NG5QJ.P]o ˫$wB<<<ZNJmuJKLMMY(&JEP6Tf}[B4(**200x7oWUUյkWBȉ'ZF&&&BF k/2 SYY)7uCfÇ#G\z5ݴرcՓ&MRIIs}}}B4˗/ !}Qgk׮5k744\lٔ)S֮]KIIIxbҩqtt4mppp}Qmm7-)00022~VB??? ŋ\vMvF54"88,((HA>Dp8zΝ>(DÿBlllueO$o===bٴܹsiiiϞ=KIIo[9s;vL,geeD":}hiiiׯ_hbbRXXx…C+UpppIIIff/^|I5ckkKނz~M;XYY 544444믗,YBoh[[[WW3gΤ=)..NJJJOO722222cmܸ811Q$VX1m4%+--E" !dŊsݾ}9T2OFl>h333#KPv faa!moxB}BPPPDDDjjjlll}}޾X5(?VNN0[1 #;<0ʏ_譩^_|cǎ%~8ZEE$Ql'''E.]Zy#!!!={tqqIII=geeՋEvhy5ҥ D W !/^TS9:urV3W={B,Xϯjbbr[?{aN:mذA,xbDO<{W*++ ܖ/_d)޹sQJرc+**X+VϜ9@RPCSN ;y$!W^fِA8qbLLڵk|#]ֳgOBnTTaz[n .4h wvv&7ٹ?44TX ⨨O>FGGg̙_ !!!!\|y>}mllBBB載}?{xxxг$XΝyϥl_***j=))) o3ՙ˗FWvԩΞ=u-իWׯ_?~<׵@!ۛu!"66V,{zzbp@$%%O~Kuuush1vѢE Vo߾ ֛8ì/.\ٟԦ*** bcc}||.ZSiӦeddp]Z \P_54oZK͟?ݻw?蝗0khLKK+**_~iiicƌ"Q__`!f Oww[[ۓ'Oi*..6m˗utt_v|AnnW_}bG"8pݺuqrApڥo]jjj.GR4hPQQEjyw]rebb"! 4ťG666ԇߕ=ԩSΝstt\~3YEjѠOnܸ1**JD͍~եOx2eʗ_~B[@4L]]ݹs޽{'8j<===mm]yzzr]@ .UIENDB`source/concepts/0000775000175000017500000000000013223143453012656 5ustar rgerrgersource/concepts/queues.rst0000664000175000017500000006506613223143030014723 0ustar rgerrgerUnderstanding rsyslog Queues ============================ Rsyslog uses queues whenever two activities need to be loosely coupled. With a queue, one part of the system "produces" something while another part "consumes" this something. The "something" is most often syslog messages, but queues may also be used for other purposes. This document provides a good insight into technical details, operation modes and implications. In addition to it, an :doc:`rsyslog queue concepts overview <../whitepapers/queues_analogy>` document exists which tries to explain queues with the help of some analogies. This may probably be a better place to start reading about queues. I assume that once you have understood that document, the material here will be much easier to grasp and look much more natural. The most prominent example is the main message queue. Whenever rsyslog receives a message (e.g. locally, via UDP, TCP or in whatever else way), it places these messages into the main message queue. Later, it is dequeued by the rule processor, which then evaluates which actions are to be carried out. In front of each action, there is also a queue, which potentially de-couples the filter processing from the actual action (e.g. writing to file, database or forwarding to another host). Where are Queues Used? ---------------------- Currently, queues are used for the main message queue and for the actions. There is a single main message queue inside rsyslog. Each input module delivers messages to it. The main message queue worker filters messages based on rules specified in rsyslog.conf and dispatches them to the individual action queues. Once a message is in an action queue, it is deleted from the main message queue. There are multiple action queues, one for each configured action. By default, these queues operate in direct (non-queueing) mode. Action queues are fully configurable and thus can be changed to whatever is best for the given use case. Future versions of rsyslog will most probably utilize queues at other places, too. Wherever "**\ "  is used in the config file statements, substitute "**\ " with either "MainMsg" or "Action". The former will set main message queue parameters, the later parameters for the next action that will be created. Action queue parameters can not be modified once the action has been specified. For example, to tell the main message queue to save its content on shutdown, use *$MainMsgQueueSaveOnShutdown on*". If the same parameter is specified multiple times before a queue is created, the last one specified takes precedence. The main message queue is created after parsing the config file and all of its potential includes. An action queue is created each time an action selector is specified. Action queue parameters are reset to default after an action queue has been created (to provide a clean environment for the next action). Not all queues necessarily support the full set of queue configuration parameters, because not all are applicable. For example, in current output module design, actions do not support multi-threading. Consequently, the number of worker threads is fixed to one for action queues and can not be changed. Queue Modes ----------- Rsyslog supports different queue modes, some with submodes. Each of them has specific advantages and disadvantages. Selecting the right queue mode is quite important when tuning rsyslogd. The queue mode (aka "type") is set via the "*$QueueType*\ " config directive. Direct Queues ~~~~~~~~~~~~~ Direct queues are **non**-queuing queues. A queue in direct mode does neither queue nor buffer any of the queue elements but rather passes the element directly (and immediately) from the producer to the consumer. This sounds strange, but there is a good reason for this queue type. Direct mode queues allow to use queues generically, even in places where queuing is not always desired. A good example is the queue in front of output actions. While it makes perfect sense to buffer forwarding actions or database writes, it makes only limited sense to build up a queue in front of simple local file writes. Yet, rsyslog still has a queue in front of every action. So for file writes, the queue mode can simply be set to "direct", in which case no queuing happens. Please note that a direct queue also is the only queue type that passes back the execution return code (success/failure) from the consumer to the producer. This, for example, is needed for the backup action logic. Consequently, backup actions require the to-be-checked action to use a "direct" mode queue. To create a direct queue, use the "*$QueueType Direct*\ " config directive. Disk Queues ~~~~~~~~~~~ Disk queues use disk drives for buffering. The important fact is that they always use the disk and do not buffer anything in memory. Thus, the queue is ultra-reliable, but by far the slowest mode. For regular use cases, this queue mode is not recommended. It is useful if log data is so important that it must not be lost, even in extreme cases. When a disk queue is written, it is done in chunks. Each chunk receives its individual file. Files are named with a prefix (set via the "*$QueueFilename*\ " config directive) and followed by a 7-digit number (starting at one and incremented for each file). Chunks are 10mb by default, a different size can be set via the"*$QueueMaxFileSize*\ " config directive. Note that the size limit is not a sharp one: rsyslog always writes one complete queue entry, even if it violates the size limit. So chunks are actually a little bit (usually less than 1k) larger then the configured size. Each chunk also has a different size for the same reason. If you observe different chunk sizes, you can relax: this is not a problem. Writing in chunks is used so that processed data can quickly be deleted and is free for other uses - while at the same time keeping no artificial upper limit on disk space used. If a disk quota is set (instructions further below), be sure that the quota/chunk size allows at least two chunks to be written. Rsyslog currently does not check that and will fail miserably if a single chunk is over the quota. Creating new chunks costs performance but provides quicker ability to free disk space. The 10mb default is considered a good compromise between these two. However, it may make sense to adapt these settings to local policies. For example, if a disk queue is written on a dedicated 200gb disk, it may make sense to use a 2gb (or even larger) chunk size. Please note, however, that the disk queue by default does not update its housekeeping structures every time it writes to disk. This is for performance reasons. In the event of failure, data will still be lost (except when manually is mangled with the file structures). However, disk queues can be set to write bookkeeping information on checkpoints (every n records), so that this can be made ultra-reliable, too. If the checkpoint interval is set to one, no data can be lost, but the queue is exceptionally slow. Each queue can be placed on a different disk for best performance and/or isolation. This is currently selected by specifying different *$WorkDirectory* config directives before the queue creation statement. To create a disk queue, use the "*$QueueType Disk*\ " config directive. Checkpoint intervals can be specified via "*$QueueCheckpointInterval*\ ", with 0 meaning no checkpoints. Note that disk-based queues can be made very reliable by issuing a (f)sync after each write operation. Starting with version 4.3.2, this can be requested via "*QueueSyncQueueFiles on/off* with the default being off. Activating this option has a performance penalty, so it should not be turned on without reason. If you happen to lose or otherwise need the housekeeping structures and have all yours queue chunks you can use perl script included in rsyslog package to generate it. Usage: recover_qi.pl -w *$WorkDirectory* -f QueueFileName -d 8 > QueueFileName.qi In-Memory Queues ~~~~~~~~~~~~~~~~ In-memory queue mode is what most people have on their mind when they think about computing queues. Here, the enqueued data elements are held in memory. Consequently, in-memory queues are very fast. But of course, they do not survive any program or operating system abort (what usually is tolerable and unlikely). Be sure to use an UPS if you use in-memory mode and your log data is important to you. Note that even in-memory queues may hold data for an infinite amount of time when e.g. an output destination system is down and there is no reason to move the data out of memory (lying around in memory for an extended period of time is NOT a reason). Pure in-memory queues can't even store queue elements anywhere else than in core memory. There exist two different in-memory queue modes: LinkedList and FixedArray. Both are quite similar from the user's point of view, but utilize different algorithms. A FixedArray queue uses a fixed, pre-allocated array that holds pointers to queue elements. The majority of space is taken up by the actual user data elements, to which the pointers in the array point. The pointer array itself is comparatively small. However, it has a certain memory footprint even if the queue is empty. As there is no need to dynamically allocate any housekeeping structures, FixedArray offers the best run time performance (uses the least CPU cycle). FixedArray is best if there is a relatively low number of queue elements expected and performance is desired. It is the default mode for the main message queue (with a limit of 10,000 elements). A LinkedList queue is quite the opposite. All housekeeping structures are dynamically allocated (in a linked list, as its name implies). This requires somewhat more runtime processing overhead, but ensures that memory is only allocated in cases where it is needed. LinkedList queues are especially well-suited for queues where only occasionally a than-high number of elements need to be queued. A use case may be occasional message burst. Memory permitting, it could be limited to e.g. 200,000 elements which would take up only memory if in use. A FixedArray queue may have a too large static memory footprint in such cases. **In general, it is advised to use LinkedList mode if in doubt**. The processing overhead compared to FixedArray is low and may be outweighed by the reduction in memory use. Paging in most-often-unused pointer array pages can be much slower than dynamically allocating them. To create an in-memory queue, use the "*$QueueType LinkedList*\ " or  "*$QueueType FixedArray*\ " config directive. Disk-Assisted Memory Queues ^^^^^^^^^^^^^^^^^^^^^^^^^^^ If a disk queue name is defined for in-memory queues (via *$QueueFileName*), they automatically become "disk-assisted" (DA). In that mode, data is written to disk (and read back) on an as-needed basis. Actually, the regular memory queue (called the "primary queue") and a disk queue (called the "DA queue") work in tandem in this mode. Most importantly, the disk queue is activated if the primary queue is full or needs to be persisted on shutdown. Disk-assisted queues combine the advantages of pure memory queues with those of  pure disk queues. Under normal operations, they are very fast and messages will never touch the disk. But if there is need to, an unlimited amount of messages can be buffered (actually limited by free disk space only) and data can be persisted between rsyslogd runs. With a DA-queue, both disk-specific and in-memory specific configuration parameters can be set. From the user's point of view, think of a DA queue like a "super-queue" which does all within a single queue [from the code perspective, there is some specific handling for this case, so it is actually much like a single object]. DA queues are typically used to de-couple potentially long-running and unreliable actions (to make them reliable). For example, it is recommended to use a disk-assisted linked list in-memory queue in front of each database and "send via tcp" action. Doing so makes these actions reliable and de-couples their potential low execution speed from the rest of your rules (e.g. the local file writes). There is a howto on `massive database inserts `_ which nicely describes this use case. It may even be a good read if you do not intend to use databases. With DA queues, we do not simply write out everything to disk and then run as a disk queue once the in-memory queue is full. A much smarter algorithm is used, which involves a "high watermark" and a "low watermark". Both specify numbers of queued items. If the queue size reaches high watermark elements, the queue begins to write data elements to disk. It does so until it reaches the low water mark elements. At this point, it stops writing until either high water mark is reached again or the on-disk queue becomes empty, in which case the queue reverts back to in-memory mode, only. While holding at the low watermark, new elements are actually enqueued in memory. They are eventually written to disk, but only if the high water mark is ever reached again. If it isn't, these items never touch the disk. So even when a queue runs disk-assisted, there is in-memory data present (this is a big difference to pure disk queues!). This algorithm prevents unnecessary disk writes, but also leaves some additional buffer space for message bursts. Remember that creating disk files and writing to them is a lengthy operation. It is too lengthy to e.g. block receiving UDP messages. Doing so would result in message loss. Thus, the queue initiates DA mode, but still is able to receive messages and enqueue them - as long as the maximum queue size is not reached. The number of elements between the high water mark and the maximum queue size serves as this "emergency buffer". Size it according to your needs, if traffic is very bursty you will probably need a large buffer here. Keep in mind, though, that under normal operations these queue elements will probably never be used. Setting the high water mark too low will cause disk-assistance to be turned on more often than actually needed. The water marks can be set via the "*$QueueHighWatermark*\ " and  "*$QueueLowWatermark*\ " configuration file directives. Note that these are actual numbers, not percentages. Be sure they make sense (also in respect to "*$QueueSize*\ "). Rsyslodg does perform some checks on the numbers provided, and issues warning when numbers are "suspicious". Limiting the Queue Size ----------------------- All queues, including disk queues, have a limit of the number of elements they can enqueue. This is set via the "*$QueueSize*\ " config parameter. Note that the size is specified in number of enqueued elements, not their actual memory size. Memory size limits can not be set. A conservative assumption is that a single syslog messages takes up 512 bytes on average (in-memory, NOT on the wire, this \*is\* a difference). Disk assisted queues are special in that they do **not** have any size limit. The enqueue an unlimited amount of elements. To prevent running out of space, disk and disk-assisted queues can be size-limited via the "*$QueueMaxDiskSpace*\ " configuration parameter. If it is not set, the limit is only available free space (and reaching this limit is currently not very gracefully handled, so avoid running into it!). If a limit is set, the queue can not grow larger than it. Note, however, that the limit is approximate. The engine always writes complete records. As such, it is possible that slightly more than the set limit is used (usually less than 1k, given the average message size). Keeping strictly on the limit would be a performance hurt, and thus the design decision was to favour performance. If you don't like that policy, simply specify a slightly lower limit (e.g. 999,999K instead of 1G). In general, it is a good idea to limit the physical disk space even if you dedicate a whole disk to rsyslog. That way, you prevent it from running out of space (future version will have an auto-size-limit logic, that then kicks in in such situations). Worker Thread Pools ------------------- Each queue (except in "direct" mode) has an associated pool of worker threads. Worker threads carry out the action to be performed on the data elements enqueued. As an actual sample, the main message queue's worker task is to apply filter logic to each incoming message and enqueue them to the relevant output queues (actions). Worker threads are started and stopped on an as-needed basis. On a system without activity, there may be no worker at all running. One is automatically started when a message comes in. Similarly, additional workers are started if the queue grows above a specific size. The "*$QueueWorkerThreadMinimumMessages*\ "  config parameter controls worker startup. If it is set to the minimum number of elements that must be enqueued in order to justify a new worker startup. For example, let's assume it is set to 100. As long as no more than 100 messages are in the queue, a single worker will be used. When more than 100 messages arrive, a new worker thread is automatically started. Similarly, a third worker will be started when there are at least 300 messages, a forth when reaching 400 and so on. It, however, does not make sense to have too many worker threads running in parallel. Thus, the upper limit can be set via "*$QueueWorkerThreads*\ ". If it, for example, is set to four, no more than four workers will ever be started, no matter how many elements are enqueued. Worker threads that have been started are kept running until an inactivity timeout happens. The timeout can be set via "*$QueueWorkerTimeoutThreadShutdown*\ " and is specified in milliseconds. If you do not like to keep the workers running, simply set it to 0, which means immediate timeout and thus immediate shutdown. But consider that creating threads involves some overhead, and this is why we keep them running. If you would like to never shutdown any worker threads, specify -1 for this parameter. Discarding Messages ~~~~~~~~~~~~~~~~~~~ If the queue reaches the so called "discard watermark" (a number of queued elements), less important messages can automatically be discarded. This is in an effort to save queue space for more important messages, which you even less like to lose. Please note that whenever there are more than "discard watermark" messages, both newly incoming as well as already enqueued low-priority messages are discarded. The algorithm discards messages newly coming in and those at the front of the queue. The discard watermark is a last resort setting. It should be set sufficiently high, but low enough to allow for large message burst. Please note that it take effect immediately and thus shows effect promptly - but that doesn't help if the burst mainly consist of high-priority messages... The discard watermark is set via the "*$QueueDiscardMark*\ " directive. The priority of messages to be discarded is set via "*$QueueDiscardSeverity*\ ". This directive accepts both the usual textual severity as well as a numerical one. To understand it, you must be aware of the numerical severity values. They are defined in RFC 3164: ==== ======== Code Severity ==== ======== 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages ==== ======== Anything of the specified severity and (numerically) above it is discarded. To turn message discarding off, simply specify the discard watermark to be higher than the queue size. An alternative is to specify the numerical value 8 as DiscardSeverity. This is also the default setting to prevent unintentional message loss. So if you would like to use message discarding, you need to set" *$QueueDiscardSeverity*" to an actual value. An interesting application is with disk-assisted queues: if the discard watermark is set lower than the high watermark, message discarding will start before the queue becomes disk-assisted. This may be a good thing if you would like to switch to disk-assisted mode only in cases where it is absolutely unavoidable and you prefer to discard less important messages first. Filled-Up Queues ---------------- If the queue has either reached its configured maximum number of entries or disk space, it is finally full. If so, rsyslogd throttles the data element submitter. If that, for example, is a reliable input (TCP, local log socket), that will slow down the message originator which is a good resolution for this scenario. During throttling, a disk-assisted queue continues to write to disk and messages are also discarded based on severity as well as regular dequeuing and processing continues. So chances are good the situation will be resolved by simply throttling. Note, though, that throttling is highly undesirable for unreliable sources, like UDP message reception. So it is not a good thing to run into throttling mode at all. We can not hold processing infinitely, not even when throttling. For example, throttling the local log socket too long would cause the system at whole come to a standstill. To prevent this, rsyslogd times out after a configured period ("*$QueueTimeoutEnqueue*\ ", specified in milliseconds) if no space becomes available. As a last resort, it then discards the newly arrived message. If you do not like throttling, set the timeout to 0 - the message will then immediately be discarded. If you use a high timeout, be sure you know what you do. If a high main message queue enqueue timeout is set, it can lead to something like a complete hang of the system. The same problem does not apply to action queues. Rate Limiting ~~~~~~~~~~~~~ Rate limiting provides a way to prevent rsyslogd from processing things too fast. It can, for example, prevent overrunning a receiver system. Currently, there are only limited rate-limiting features available. The "*$QueueDequeueSlowdown*\ "  directive allows to specify how long (in microseconds) dequeueing should be delayed. While simple, it still is powerful. For example, using a DequeueSlowdown delay of 1,000 microseconds on a UDP send action ensures that no more than 1,000 messages can be sent within a second (actually less, as there is also some time needed for the processing itself). Processing Timeframes ~~~~~~~~~~~~~~~~~~~~~ Queues can be set to dequeue (process) messages only during certain timeframes. This is useful if you, for example, would like to transfer the bulk of messages only during off-peak hours, e.g. when you have only limited bandwidth on the network path to the central server. Currently, only a single timeframe is supported and, even worse, it can only be specified by the hour. It is not hard to extend rsyslog's capabilities in this regard - it was just not requested so far. So if you need more fine-grained control, let us know and we'll probably implement it. There are two configuration directives, both should be used together or results are unpredictable:" *$QueueDequeueTimeBegin *" and "*$QueueDequeueTimeEnd *\ ". The hour parameter must be specified in 24-hour format (so 10pm is 22). A use case for this parameter can be found in the `rsyslog wiki `_. Performance ~~~~~~~~~~~ The locking involved with maintaining the queue has a potentially large performance impact. How large this is, and if it exists at all, depends much on the configuration and actual use case. However, the queue is able to work on so-called "batches" when dequeueing data elements. With batches, multiple data elements are dequeued at once (with a single locking call). The queue dequeues all available elements up to a configured upper limit (*DequeueBatchSize *). It is important to note that the actual upper limit is dictated by availability. The queue engine will never wait for a batch to fill. So even if a high upper limit is configured, batches may consist of fewer elements, even just one, if there are no more elements waiting in the queue. Batching can improve performance considerably. Note, however, that it affects the order in which messages are passed to the queue worker threads, as each worker now receive as batch of messages. Also, the larger the batch size and the higher the maximum number of permitted worker threads, the more main memory is needed. For a busy server, large batch sizes (around 1,000 or even more elements) may be useful. Please note that with batching, the main memory must hold BatchSize \* NumOfWorkers objects in memory (worst-case scenario), even if running in disk-only mode. So if you use the default 5 workers at the main message queue and set the batch size to 1,000, you need to be prepared that the main message queue holds up to 5,000 messages in main memory **in addition** to the configured queue size limits! The queue object's default maximum batch size is eight, but there exists different defaults for the actual parts of rsyslog processing that utilize queues. So you need to check these object's defaults. Terminating Queues ~~~~~~~~~~~~~~~~~~ Terminating a process sounds easy, but can be complex. Terminating a running queue is in fact the most complex operation a queue object can perform. You don't see that from a user's point of view, but its quite hard work for the developer to do everything in the right order. The complexity arises when the queue has still data enqueued when it finishes. Rsyslog tries to preserve as much of it as possible. As a first measure, there is a regular queue time out ("*$QueueTimeoutShutdown*\ ", specified in milliseconds): the queue workers are given that time period to finish processing the queue. If after that period there is still data in the queue, workers are instructed to finish the current data element and then terminate. This essentially means any other data is lost. There is another timeout ("*$QueueTimeoutActionCompletion*\ ", also specified in milliseconds) that specifies how long the workers have to finish the current element. If that timeout expires, any remaining workers are cancelled and the queue is brought down. If you do not like to lose data on shutdown, the "*$QueueSaveOnShutdown*\ " parameter can be set to "on". This requires either a disk or disk-assisted queue. If set, rsyslogd ensures that any queue elements are saved to disk before it terminates. This includes data elements there were begun being processed by workers that needed to be cancelled due to too-long processing. For a large queue, this operation may be lengthy. No timeout applies to a required shutdown save. source/concepts/rfc5424layers.png0000664000175000017500000002455512704114446015713 0ustar rgerrgerPNG  IHDRozesBITO pHYs IDATxy\T_&".]S,IiJjvQ~eeYfYvnbW\R43,Y-eMQg9|3sx?1ss>9'xꩧ@!SVZh\dp FhGJ:LZ;,!AHVZ`#n#o#܃8~٨j %YAX"A4nS+|UPPxP#}j] BBz# OAta_  PZGYV%+HF2ۺHü#\:cs%Js,@B ơ8{e⇮ÁP脊#"4ILO6 87ZT)j ߫qlPs?b_TYĢUZoUQ\ݍ *3 a- N]{t*V6_ )wF^n<7 qḢ9/ ؅Q5F%wkߙ9` pqS D~ gCp.,n޷ k>e$"q U1 yca$M_`Dtǰ,$\Du|EQʲ,{wӸqA۠`+:= gO"\sVJ0ڌpmexH=uTZ}aM$\@Ha 6!?bU {t;lE1݃H{!2H:}>lmQxC{prAPgkΛ'ctSGD3z.^/iǒV1>y d >ƛ(ށdVV+e("_Ƚj سa }AgrӦfW8t|NѣEM%2(hZ (#اىuH"PfKv&YnSb6+ށgV`[?=@3@lڐN Q{o ,?p dX2t UȘU1:7mA@.`rmAƁ U: U: U: U: U: U: U: k~~>VK[Ba=C,XT*d&aAX"4_ v8 Oe8A%nvѣ@lm"&58{カ JD[*A*A*A*A*A*A*A*A*A*A*A*A*#?sФunѢ hPs|Zp8:&7*b^ۼNЖYP#BP)WB9Z670@K}jʰ! ϴGjχ^ZV%b7^#@/cCߌݐ⋭3cmGYMl;"@uX _?g+ ލ,s9>]Ƈk*3ὛXr=Fi(8= LL>Sײp[|kturP~7."?_1֙(#<τ@NzPUwW%&PUN %Rox ~5e0\v ƈ40zAHE>x vnTXvv!sq7V?#j p`W8_waۈGb89b9pK쪽K*mY8ooJDS#4MS6?&> ^ &G,; фAdJ <==8gZr@eneڇoG*n*N?b{n{TOƷ> NN($iD'JŲ#U:9RqY<ᤷ>ݯw b% ]P5eػo0ñ{1j,wbhPI _zZG )ޥH =UEPzy#z@_eG*GgQPkP2} w?/#-9fn's 7c2*OlŖd!_ء &d@>C͏*8 K׍o3}#vaI4С fnC~#D`xkLya=gG 6̝;CahyNxK$X3;x;_R 4Uv0a|۶m鵍ql#|=~QT\7/϶|oxwOENm6Ob#n|DKA-պs䚳#wa +A*AU:2{!5H]Xe }ː䟵<6Ktvmk~ryi?cev{a cw]zMQobUs_K{î TQUzoٖVMy0td^b^LPy?u,T5:X3PODaAqW< `9 }wu!Fh:Yz3`R3<¯ 5gkGY+Vȼ&ѼHo^2Ɍ,>X7ǵB|"+ۂn݋@iNpRn6bS`޼]g'Ԍ<f |L^'hkRk!Ƙ:~7<~4+6Fl`iN,KApJZعBzFb]c1 {[9G;skRk!b^V):ɂYp_O]Ac+6Fl`iN,KApJZ9R3bo :2'Zh@M@ܼoɡsq/\|ZНӼ6s5 m~TOvt5}؈Og>NNXr! Q%d M,KlßRSe I!%ZޤƦd2'K!{>yMyS;ƎqKt1ѽ qw)mq!r:'hGV!y3~=hȼ&Ѽ&`q6{v0N0Mo,V0tbq:& m$nMSjҸ*nC',<WwrbT<{N2ӑyEG$CR۷ēBSkt2:jh^kR#7cZ[IaSkuRȼFXIȥґyGm +>)G t!҉c?^06'Z++Ңr=3ip[/>҉:^0wˉ ~ţa,ĞzF U[ݎ~AUm҉`L'}siRPVQށ Ed k՗&*@vR U:.v n{ &Q8`„^,U*]8 AT"YG,]-1u_%f3C ֟_ozHJV0TS$jn^O_,c%dy3j3[Hǰ bsdkQ"$,ħ֔!׋wS+c3sH bLjX:AĒ5`| 3 &oDHA/rȠdgD#6Xq٣K\n)W`i+V(ˑ qF9\:OtlL29:d7OGp֍ɞh5k[+cgE"iS9òKZr~tջukS6%fqiMD֕lӜ#Ҧ[Y۬;.-/A- U: U: U: U: U: ϭLnH d_cql"hlAD 3sLF))I^ojRv윟/#AT*JG!!!!!!!!!!!!!!!F Wն ̇* ӹsmK3_. "i$̆*acl]@(T}Q###>7n;v{QWWoOEEٳ E^-Z+ŏ>hlb>~bcckӎ;O?6lXttB={vYYn7dȐѣG_pA,#_|q=DGG3֏wZ} BNnٳO>ܖW_}uݺu.]:za;w ;;;77wĉG3G5[pi2222ٮ]抅͏1TOPPЇ~o'NO2믿Vջv튊ٳXKR݈3&7,,ީS'n7G bڴiJRP`` wۛ@ʈSYXCM0jԨ*33ss64~ؾ}cEx IDAT=h@i088ۮ#9s̝;7###''?6/#a!P??c}}Szʔ)˗/~衇-taС˖-Xn[``WXR*++7l! @^^`uuujݽxʕfgrJJU^^n:.)MptZ|޽{GEEܹ=4iҤxϏݒcڵ qqqC ۷?m_fMIII^ƎbcXXXrr!O+Am tAt!oXIT%&U htD[:ЖJׂp۶m0`ɓ'7o׷o_~E׌f1r|ĥr]߿oS*={T(>Jg-NmmE5lذӧO  CAvV*]餤y敖>}zɯCƷ1l11lb@ 瞫9qĩSJJJz-~餦۷/77w˖- ˜V !{A kAy']\\FYRR2{l6wECƷr|v6|+ٳh"___yqOZTUU}wK.Iݺu330G"61,x.(atDӡCnnn?B_ҥKMMMMMM7n=ķqj7 .8p ct WRRhFk#?Wj4nݺIWJ` ML'8&9yd)DxCpSVSȶfҼGnWӳ %K:A^ ? yB~: T?T?TתSp78YȈ#.]ZQQ,*****JP$''_r1P-"##u;FEEX1a„ȘĽ{Z;uQJGX .dffY,11Q'/Nqɀ~O-8`cJ5uѣGdeetm)RG}{ [l15"KllU KNN̴| )SѥtGT.%%%88;v`_f&M_!{ڵ͛7Zt588x{"*̑"8~xZZg``yCPPPeen^ EBBB]]~mpp믿ޯ_q]xZ] &sH8ERXXwSN>h4ݖ&n 團-thnݸɥ-׿o߾p8TNiԊv0'HnK^^Q;w2Č&$$dΜ9III9(aЧW#E*8x+VT 6 6l؛oɝ>rʕk>͚rrrN8!/ #[}}}-juQQц TUUm۶O>fwN tGL*`͚5%%%zJJJ;v >ׯOHH4iu6=z?:w #[TTԝXtivΞ=;f̘xR~zvى&]OgϞŋsIhQ#&WS# 77QP̘1#>>^4#B&NꔔR77QF+AzOG`_. **Available since:** 3.19.0 (suggested minimum 3.19.8 and above) Supported Driver Modes - 0 - unencrypted trasmission (just like `ptcp `_ driver) - 1 - TLS-protected operation Note: mode 0 does not provide any benefit over the ptcp driver. This mode exists for technical reasons, but should not be used. It may be removed in the future. Supported Authentication Modes - anon - anonymous authentication as described in IETF's draft-ietf-syslog-transport-tls-12 Internet draft - x509/fingerprint - certificate fingerprint authentication as described in IETF's draft-ietf-syslog-transport-tls-12 Internet draft - x509/certvalid - certificate validation only - x509/name - certificate validation and subject name authentication as described in IETF's draft-ietf-syslog-transport-tls-12 Internet draft Note: "anon" does not permit to authenticate the remote peer. As such, this mode is vulnerable to man in the middle attacks as well as unauthorized access. It is recommended NOT to use this mode. x509/certvalid is a nonstandard mode. It validates the remote peers certificate, but does not check the subject name. This is weak authentication that may be useful in scenarios where multiple devices are deployed and it is sufficient proof of authenticity when their certificates are signed by the CA the server trusts. This is better than anon authentication, but still not recommended. **Known Problems** Even in x509/fingerprint mode, both the client and server certificate currently must be signed by the same root CA. This is an artifact of the underlying GnuTLS library and the way we use it. It is expected that we can resolve this issue in the future. source/concepts/netstrm_drvr.rst0000664000175000017500000000111612704114446016143 0ustar rgerrgerNetStream Drivers ================= Network stream drivers are a layer between various parts of rsyslogd (e.g. the imtcp module) and the transport layer. They provide sequenced delivery, authentication and confidentiality to the upper layers. Drivers implement different capabilities. Users need to know about netstream drivers because they need to configure the proper driver, and proper driver properties, to achieve desired results (e.g. a :doc:`../tutorials/tls`). Current Network Stream Drivers ------------------------------ .. toctree:: :maxdepth: 2 ns_ptcp ns_gtls source/concepts/ns_ptcp.rst0000664000175000017500000000040512704114446015060 0ustar rgerrgerptcp Network Stream Driver ========================== This network stream driver implement a plain tcp transport without security properties. Supported Driver Modes - 0 - unencrypted trasmission Supported Authentication Modes - "anon" - no authenticationsource/concepts/index.rst0000664000175000017500000000043613223143030014511 0ustar rgerrgerConcepts ======== This chapter describes important rsyslog concepts and objects. Where appropriate, it also refers to configurations settings to affect the respective objects. .. toctree:: :maxdepth: 2 queues janitor messageparser multi_ruleset netstrm_drvr source/concepts/multi_ruleset.rst0000664000175000017500000003133213223143453016307 0ustar rgerrgerMultiple Rulesets in rsyslog ============================ Starting with version 4.5.0 and 5.1.1, `rsyslog `_ supports multiple rulesets within a single configuration. This is especially useful for routing the reception of remote messages to a set of specific rules. Note that the input module must support binding to non-standard rulesets, so the functionality may not be available with all inputs. In this document, I am using :doc:`imtcp <../configuration/modules/imtcp>`, an input module that supports binding to non-standard rulesets since rsyslog started to support them. What is a Ruleset? ------------------ If you have worked with (r)syslog.conf, you know that it is made up of what I call rules (others tend to call them selectors, a sysklogd term). Each rule consist of a filter and one or more actions to be carried out when the filter evaluates to true. A filter may be as simple as a traditional syslog priority based filter (like "\*.\*" or "mail.info" or a as complex as a script-like expression. Details on that are covered in the config file documentation. After the filter come action specifiers, and an action is something that does something to a message, e.g. write it to a file or forward it to a remote logging server. A traditional configuration file is made up of one or more of these rules. When a new message arrives, its processing starts with the first rule (in order of appearance in rsyslog.conf) and continues for each rule until either all rules have been processed or a so-called "discard" action happens, in which case processing stops and the message is thrown away (what also happens after the last rule has been processed). The **multi-ruleset** support now permits to specify more than one such rule sequence. You can think of a traditional config file just as a single default rule set, which is automatically bound to each of the inputs. This is even what actually happens. When rsyslog.conf is processed, the config file parser looks for the directive :: ruleset(name="rulesetname"); Where name is any name the user likes (but must not start with "RSYSLOG\_", which is the name space reserved for rsyslog use). If it finds this directive, it begins a new rule set (if the name was not yet know) or switches to an already-existing one (if the name was known). All rules defined between this $RuleSet directive and the next one are appended to the named ruleset. Note that the reserved name "RSYSLOG\_DefaultRuleset" is used to specify rsyslogd's default ruleset. You can use that name wherever you can use a ruleset name, including when binding an input to it. Inside a ruleset, messages are processed as described above: they start with the first rule and rules are processed in the order of appearance of the configuration file until either there are no more rules or the discard action is executed. Note that with multiple rulesets no longer **all** rsyslog.conf rules are executed but **only** those that are contained within the specific ruleset. Inputs must explicitly bind to rulesets. If they don't, the default ruleset is bound. This brings up the next question: What does "To bind to a Ruleset" mean? -------------------------------------- This term is used in the same sense as "to bind an IP address to an interface": it means that a specific input, or part of an input (like a tcp listener) will use a specific ruleset to "pass its messages to". So when a new message arrives, it will be processed via the bound ruleset. Rules from all other rulesets are irrelevant and will never be processed. This makes multiple rulesets very handy to process local and remote message via separate means: bind the respective receivers to different rule sets, and you do not need to separate the messages by any other method. Binding to rulesets is input-specific. For imtcp, this is done via the :: input(type="imptcp" port="514" ruleset="rulesetname"); directive. Note that "rulesetname" must be the name of a ruleset that is already defined at the time the bind directive is given. There are many ways to make sure this happens, but I personally think that it is best to define all rule sets at the top of rsyslog.conf and define the inputs at the bottom. This kind of reverses the traditional recommended ordering, but seems to be a really useful and straightforward way of doing things. Why are rulesets important for different parser configurations? --------------------------------------------------------------- Custom message parsers, used to handle different (and potentially otherwise-invalid) message formats, can be bound to rulesets. So multiple rulesets can be a very useful way to handle devices sending messages in different malformed formats in a consistent way. Unfortunately, this is not uncommon in the syslog world. An in-depth explanation with configuration sample can be found at the :doc:`$RulesetParser <../configuration/ruleset/rsconf1_rulesetparser>` configuration directive. Can I use a different Ruleset as the default? --------------------------------------------- This is possible by using the :: $DefaultRuleset Directive. Please note, however, that this directive is actually global: that is, it does not modify the ruleset to which the next input is bound but rather provides a system-wide default rule set for those inputs that did not explicitly bind to one. As such, the directive can not be used as a work-around to bind inputs to non-default rulesets that do not support ruleset binding. Rulesets and Queues ------------------- By default, rulesets do not have their own queue. It must be activated via the $RulesetCreateMainQueue directive, or if using rainerscript format, by specifying queue parameters on the ruleset directive, e.g. :: ruleset(name="whatever" queue.type="fixedArray" queue. ...) See :doc:`http://www.ryslog.com/doc/master/rainerscript/queue\_parameters.html <../rainerscript/queue_parameters>` for more details. Please note that when a ruleset uses its own queue, processing of the ruleset happens **asynchronously** to the rest of processing. As such, any modifications made to the message object (e.g. message or local variables that are set) or discarding of the message object **have no effect outside that ruleset**. So if you want to modify the message object inside the ruleset, you **cannot** define a queue for it. Most importantly, you cannot call it and expect the modified properties to be present when the call returns. Even more so, the call will most probably return before the message is even begun to be processed by the ruleset in question. Note that in RainerScript format specifying any "queue.\*" can cause the creation of a dedicated queue and as such asynchronous processing. This is because queue parameters cannot be specified without a queue. Note, though, that the actual creation is **guaranteed** only if "queue.type" is specified as above. So if you intentionally want to assign a separate queue to the ruleset, do so as shown above. Examples -------- Split local and remote logging ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let's say you have a pretty standard system that logs its local messages to the usual bunch of files that are specified in the default rsyslog.conf. As an example, your rsyslog.conf might look like this: :: # ... module loading ... # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... Now, you want to add receive messages from a remote system and log these to a special file, but you do not want to have these messages written to the files specified above. The traditional approach is to add a rule in front of all others that filters on the message, processes it and then discards it: :: # ... module loading ... # process remote messages if $fromhost-ip == '192.0.2.1' then { action(type="omfile" file="/var/log/remotefile02") stop } # only messages not from 192.0.2.1 make it past this point # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... Note that "stop" is the discard action!. Also note that we assume that 192.0.2.1 is the sole remote sender (to keep it simple). With multiple rulesets, we can simply define a dedicated ruleset for the remote reception case and bind it to the receiver. This may be written as follows: :: # ... module loading ... # process remote messages # define new ruleset and add rules to it: ruleset(name="remote"){ action(type="omfile" file="/var/log/remotefile") } # only messages not from 192.0.21 make it past this point # bind ruleset to tcp listener and activate it: input(type="imptcp" port="10514" ruleset="remote") Split local and remote logging for three different ports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example is almost like the first one, but it extends it a little bit. While it is very similar, I hope it is different enough to provide a useful example why you may want to have more than two rulesets. Again, we would like to use the "regular" log files for local logging, only. But this time we set up three syslog/tcp listeners, each one listening to a different port (in this example 10514, 10515, and 10516). Logs received from these receivers shall go into different files. Also, logs received from 10516 (and only from that port!) with "mail.\*" priority, shall be written into a specific file and **not** be written to 10516's general log file. This is the config: :: # ... module loading ... # process remote messages ruleset(name="remote10514"){ action(type="omfile" file="/var/log/remote10514") } ruleset(name="remote10515"){ action(type="omfile" file="/var/log/remote10515") } ruleset(name="remote10516"){ if prifilt("mail.*") then { /var/log/mail10516 stop # note that the stop-command will prevent this message from # being written to the remote10516 file - as usual... } /var/log/remote10516 } # and now define listeners bound to the relevant ruleset input(type="imptcp" port="10514" ruleset="remote10514") input(type="imptcp" port="10515" ruleset="remote10515") input(type="imptcp" port="10516" ruleset="remote10516") Performance ----------- Fewer Filters ~~~~~~~~~~~~~ No rule processing can be faster than not processing a rule at all. As such, it is useful for a high performance system to identify disjunct actions and try to split these off to different rule sets. In the example section, we had a case where three different tcp listeners need to write to three different files. This is a perfect example of where multiple rule sets are easier to use and offer more performance. The performance is better simply because there is no need to check the reception service - instead messages are automatically pushed to the right rule set and can be processed by very simple rules (maybe even with "\*.\*"-filters, the fastest ones available). Partitioning of Input Data ~~~~~~~~~~~~~~~~~~~~~~~~~~ Starting with rsyslog 5.3.4, rulesets permit higher concurrency. They offer the ability to run on their own "main" queue. What that means is that a own queue is associated with a specific rule set. That means that inputs bound to that ruleset do no longer need to compete with each other when they enqueue a data element into the queue. Instead, enqueue operations can be completed in parallel. An example: let us assume we have three TCP listeners. Without rulesets, each of them needs to insert messages into the main message queue. So if each of them wants to submit a newly arrived message into the queue at the same time, only one can do so while the others need to wait. With multiple rulesets, its own queue can be created for each ruleset. If now each listener is bound to its own ruleset, concurrent message submission is possible. On a machine with a sufficiently large number of cores, this can result in dramatic performance improvement. It is highly advised that high-performance systems define a dedicated ruleset, with a dedicated queue for each of the inputs. By default, rulesets do **not** have their own queue. It must be activated via the :doc:`$RulesetCreateMainQueue <../configuration/ruleset/rsconf1_rulesetcreatemainqueue>` directive. See Also -------- .. toctree:: :maxdepth: 1 ../historical/multi_ruleset_legacy_format_samples source/concepts/messageparser.rst0000664000175000017500000003700013223143030016240 0ustar rgerrgerMessage parsers in rsyslog ========================== Written by `Rainer Gerhards `_ (2009-11-06) Intro ----- Message parsers are a feature of rsyslog 5.3.4 and above. In this article, I describe what message parsers are, what they can do and how they relate to the relevant standards. I will also describe what you can not do with time. Finally, I give some advice on implementing your own custom parser. What are message parsers? ------------------------- Well, the quick answer is that message parsers are the component of rsyslog that parses the syslog message after it is being received. Prior to rsyslog 5.3.4, message parsers where built in into the rsyslog core itself and could not be modified (other than by modifying the rsyslog code). In 5.3.4, we changed that: message parsers are now loadable modules (just like input and output modules). That means that new message parsers can be added without modifying the rsyslog core, even without contributing something back to the project. But that doesn't answer what a message parser really is. What does it mean to "parse a message" and, maybe more importantly, what is a message? To answer these questions correctly, we need to dig down into the relevant standards. `RFC5424 `_ specifies a layered architecture for the syslog protocol: .. figure:: rfc5424layers.png :align: center :alt: RFC5424 syslog protocol layers RFC5424 syslog protocol layers For us important is the distinction between the syslog transport and the upper layers. The transport layer specifies how a stream of messages is assembled at the sender side and how this stream of messages is disassembled into the individual messages at the receiver side. In networking terminology, this is called "framing". The core idea is that each message is put into a so-called "frame", which then is transmitted over the communications link. The framing used is depending on the protocol. For example, in UDP the "frame"-equivalent is a packet that is being sent (this also means that no two messages can travel within a single UDP packet). In "plain tcp syslog", the industry standard, LF is used as a frame delimiter (which also means that no multi-line message can properly be transmitted, a "design" flaw in plain tcp syslog). In `RFC5425 `_ there is a header in front of each frame that contains the size of the message. With this framing, any message content can properly be transferred. And now comes the important part: **message parsers do NOT operate at the transport layer**, they operate, as their name implies, on messages. So we can not use message parsers to change the underlying framing. For example, if a sender splits (for whatever reason) a single message into two and encapsulates these into two frames, there is no way a message parser could undo that. A typical example may be a multi-line message: let's assume some originator has generated a message for the format "A\\nB" (where \\n means LF). If that message is being transmitted via plain tcp syslog, the frame delimiter is LF. So the sender will delimit the frame with LF, but otherwise send the message unmodified onto the wire (because that is how things are -unfortunately- done in plain tcp syslog...). So wire will see "A\\nB\\n". When this arrives at the receiver, the transport layer will undo the framing. When it sees the LF after A, it thinks it finds a valid frame delimiter (in fact, this is the correct view!). So the receive will extract one complete message A and one complete message B, not knowing that they once were both part of a large multi-line message. These two messages are then passed to the upper layers, where the message parsers receive them and extract information. However, the message parsers never know (or even have a chance to see) that A and B belonged together. Even further, in rsyslog there is no guarantee that A will be parsed before B - concurrent operations may cause the reverse order (and do so very validly). The important lesson is: **message parsers can not be used to fix a broken framing**. You need a full protocol implementation to do that, what is the domain of input and output modules. I have now told you what you can not do with message parsers. But what they are good for? Thankfully, broken framing is not the primary problem of the syslog world. A wealth of different formats is. Unfortunately, many real-world implementations violate the relevant standards in one way or another. That makes it often very hard to extract meaningful information from a message or to process messages from different sources by the same rules. In my article `syslog parsing in rsyslog `_ I have elaborated on all the real-world evil that you can usually see. So I won't repeat that here. But in short, the real problem is not the framing, but how to make malformed messages well-looking. **This is what message parsers permit you to do: take a (well-known) malformed message, parse it according to its semantics and generate perfectly valid internal message representations from it.** So as long as messages are consistently in the same wrong format (and they usually are!), a message parser can look at that format, parse it, and make the message processable just like it were well formed in the first place. Plus, one can abuse the interface to do some other "interesting" tricks, but that would take us to far. While this functionality may not sound exciting, it actually solves a very big issue (that you only really understand if you have managed a system with various different syslog sources). Note that we were often able to process malformed messages in the past with the help of the property replacer and regular expressions. While this is nice, it has a performance hit. A message parser is a C code, compiled to native language, and thus typically much faster than any regular expression based method (depending, of course, on the quality of the implementation...). How are message parsers used? ----------------------------- In a simplified view, rsyslog #. first receives messages (via the input module), #. *then parses them (at the message level!)* and #. then processes them (operating on the internal message representation). Message parsers are utilized in the second step (written in italics). Thus, they take the raw message (NOT frame!) received from the remote system and create the internal structure out of it that the other parts of rsyslog need in order to perform their processing. Parsing is vital, because an unparsed message can not be processed in the third stage, the actual application-level processing (like forwarding or writing to files). Parser Chains and how they Operate ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rsyslog chains parsers together to provide flexibility. A **parser chain** contains all parsers that can potentially be used to parse a message. It is assumed that there is some way a parser can detect if the message it is being presented is supported by it. If so, the parser will tell the rsyslog engine and parse the message. The rsyslog engine now calls each parser inside the chain (in sequence!) until the first parser is able to parse the message. After one parser has been found, the message is considered parsed and no others parsers are called on that message. Side-note: this method implies there are some "not-so-dirty" tricks available to modify the message by a parser module that declares itself as "unable to parse" but still does some message modification. This was not a primary design goal, but may be utilized, and the interface probably extended, to support generic filter modules. These would need to go to the root of the parser chain. As mentioned, the current system already supports this. The position inside the parser chain can be thought of as a priority: parser sitting earlier in the chain take precedence over those sitting later in it. So more specific parser should go earlier in the chain. A good example of how this works is the default parser set provided by rsyslog: rsyslog.rfc5424 and rsyslog.rfc3164, each one parses according to the rfc that has named it. RFC5424 was designed to be distinguishable from RFC3164 message by the sequence "1 " immediately after the so-called PRI-part (don't worry about these words, it is sufficient if you understand there is a well-defined sequence used to identify RFC5424 messages). In contrary, RFC3164 actually permits everything as a valid message. Thus the RFC3164 parser will always parse a message, sometimes with quite unexpected outcome (there is a lot of guesswork involved in that parser, which unfortunately is unavoidable due to existing technology limits). So the default parser chain is to try the RFC5424 parser first and after it the RFC3164 parser. If we have a 5424-formatted message, that parser will identify and parse it and the rsyslog engine will stop processing. But if we receive a legacy syslog message, the RFC5424 will detect that it can not parse it, return this status to the engine which then calls the next parser inside the chain. That usually happens to be the RFC3164 parser, which will always process the message. But there could also be any other parser inside the chain, and then each one would be called unless one that is able to parse can be found. If we reversed the parser order, RFC5424 messages would incorrectly parsed. Why? Because the RFC3164 parser will always parse every message, so if it were asked first, it would parse (and misinterpret) the 5424-formatted message, return it did so and the rsyslog engine would never call the 5424 parser. So order of sequence is very important. What happens if no parser in the chain could parse a message? Well, then we could not obtain the in-memory representation that is needed to further process the message. In that case, rsyslog has no other choice than to discard the message. If it does so, it will emit a warning message, but only in the first 1,000 incidents. This limit is a safety measure against message-loops, which otherwise could quickly result from a parser chain misconfiguration. **If you do not tolerate loss of unparsable messages, you must ensure that each message can be parsed.** You can easily achieve this by always using the "rsyslog-rfc3164" parser as the *last* parser inside parser chains. That may result in invalid parsing, but you will have a chance to see the invalid message (in debug mode, a warning message will be written to the debug log each time a message is dropped due to inability to parse it). Where are parser chains used? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We now know what parser chains are and how they operate. The question is now how many parser chains can be active and how it is decided which parser chain is used on which message. This is controlled via :doc:`rsyslog's rulesets `. In short, multiple rulesets can be defined and there always exist at least one ruleset. A parser chain is bound to a specific ruleset. This is done by virtue of defining parsers via the :doc:`$RulesetParser <../configuration/ruleset/rsconf1_rulesetparser>` configuration directive (for specifics, see there). If no such directive is specified, the default parser chain is used. As of this writing, the default parser chain always consists of "rsyslog.rfc5424", "rsyslog.rfc3164", in that order. As soon as a parser is configured, the default list is cleared and the new parser is added to the end of the (initially empty) ruleset's parser chain. The important point to know is that parser chains are defined on a per-ruleset basis. Can I use different parser chains for different devices? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The correct answer is: generally yes, but it depends. First of all, remember that input modules (and specific listeners) may be bound to specific rulesets. As parser chains "reside" in rulesets, binding to a ruleset also binds to the parser chain that is bound to that ruleset. As a number one prerequisite, the input module must support binding to different rulesets. Not all do, but their number is growing. For example, the important `imudp `_ and `imtcp `_ input modules support that functionality. Those that do not (for example `im3195 `_) can only utilize the default ruleset and thus the parser chain defined in that ruleset. If you do not know if the input module in question supports ruleset binding, check its documentation page. Those that support it have the required directives. Note that it is currently under evaluation if rsyslog will support binding parser chains to specific inputs directly, without depending on the ruleset. There are some concerns that this may not be necessary but adds considerable complexity to the configuration. So this may or may not be possible in the future. In any case, if we decide to add it, input modules need to support it, so this functionality would require some time to implement. The cookbook recipe for using different parsers for different devices is given as an actual in-depth example in the `$RulesetParser` configuration directive doc page. In short, it is accomplished by defining specific rulesets for the required parser chains, defining different listener ports for each of the devices with different format and binding these listeners to the correct ruleset (and thus parser chains). Using that approach, a variety of different message formats can be supported via a single rsyslog instance. Which message parsers are available ----------------------------------- As of this writing, there exist only two message parsers, one for RFC5424 format and one for legacy syslog (loosely described in `RFC3164 `_). These parsers are built-in and must not be explicitly loaded. However, message parsers can be added with relative ease by anyone knowing to code in C. Then, they can be loaded via $ModLoad just like any other loadable module. It is expected that the rsyslog project will be contributed additional message parsers over time, so that at some point there hopefully is a rich choice of them (I intend to add a browsable repository as soon as new parsers pop up). How to write a message parser? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As a prerequisite, you need to know the exact format that the device is sending. Then, you need moderate C coding skills, and a little bit of rsyslog internals. I guess the rsyslog specific part should not be that hard, as almost all information can be gained from the existing parsers. They are rather simple in structure and can be found under the "./tools" directory. They are named pmrfc3164.c and pmrfc5424.c. You need to follow the usual loadable module guidelines. It is my expectation that writing a parser should typically not take longer than a single day, with maybe a day more to get acquainted with rsyslog. Of course, I am not sure if the number is actually right. If you can not program or have no time to do it, Adiscon can also write a message parser for you as part of the `rsyslog professional services offering `_. Conclusion ---------- Malformed syslog messages are a pain and unfortunately often seen in practice. Message parsers provide a fast and efficient solution for this problem. Different parsers can be defined for different devices, and they all convert message information into rsyslog's well-defined internal format. Message parsers were first introduced in rsyslog 5.3.4 and also offer some interesting ideas that may be explored in the future - up to full message normalization capabilities. It is strongly recommended that anyone with a heterogeneous environment take a look at message parser capabilities. source/concepts/janitor.rst0000664000175000017500000000410713223143453015060 0ustar rgerrgerThe Janitor Process =================== The janitor process carries out periodic cleanup tasks. For example, it is used by :doc:`omfile <../configuration/modules/omfile>` to close files after a timeout has expired. The janitor runs periodically. As such, all tasks carried out via the janitor will be activated based on the interval at which it runs. This means that all janitor-related times set are approximate and should be considered as "no earlier than" (NET). If, for example, you set a timeout to 5 minutes and the janitor is run in 10-minute intervals, the timeout may actually happen after 5 minutes, but it may also take up to 20 minutes for it to be detected. In general (see note about HUP below), janitor based activities scheduled to occur after *n* minutes will occur after *n* and *(n + 2\*janitorInterval)* minutes. To reduce the potential delay caused by janitor invocation, :ref:`the interval at which the janitor runs can be be adjusted `\ . If high precision is required, it should be set to one minute. Janitor-based activities will still be NET times, but the time frame will be much smaller. In the example with the file timeout, it would be between 5 and 6 minutes if the janitor is run at a one-minute interval. Note that the more frequent the janitor is run, the more frequent the system needs to wakeup from potential low power state. This is no issue for data center machines (which usually always run at full speed), but it may be an issue for power-constrained environments like notebooks. For such systems, a higher janitor interval may make sense. As a special case, sending a HUP signal to rsyslog also activate the janitor process. This can lead to too-frequent wakeups of janitor-related services. However, we don't expect this to cause any issues. If it does, it could be solved by creating a separate thread for the janitor. But as this takes up some system resources and is not not considered useful, we have not implemented it that way. If the HUP/janitor interaction causes problems, let the rsyslog team know and we can change the implementation. source/rsyslog_confgraph_complex.png0000664000175000017500000042754412704114446017051 0ustar rgerrgerPNG  IHDRPmbKGD pHYsHHFk> vpAgP XUIDATxw\?v#U(6cwa%MLb4-cbGbWPQ"* ݹr9$ꪼx2goJ'BQb @!o!3g~`~Fjjj |[lAVfEEE tu\qPubՉU'깡 Q)!ě=9{rd8PCavu֕ZW@rWdiF4CL1 bJĔ)_|}}1c-J:)BNg3љaW]A}=hjj A ^#FxC\p ]`v0#aF ;^}k`d&C%!īWԅf1bA`ց&Ǟ?:ܿs0C!eqp1bdȘ1+cWWW P:(`z]hf̬]vPԽ{QwPpBlnnӂ&Mv`Ȁ! _WL3CoxIB2YͲe5}M7N,>b;s+er(^4h:~orYl#UUUxS ޛ7yo}BoJSCox_IBeEnEnEn21dbDck=""";v unԹQTA ^{ %%@߫} ߪ?z+{{JB+[;o 0H=H=H ^yY |9=sz{:h&U*sR/!kfeF/^ 6Om@oަMLי3]aaajN+{)R.rRIvٍ/ryPA333(((CcK?h#TʪU) l.\ 9s Ce=T?tyYf``߁}r.sss޺zjppp+ 3@}\}\}г URQzaO=TVN[A'> 898989@}}=wv\׻w]C̆ 1*UdrU\aÖÖ[o)SZ@@@P"%гPBBBZ:k57o\Xj`)hꦫAVVbbb hTШQp2 A,Yn#G2>>> |uYd@MK  = {E&M`{`jj z2 xPAp{m2Ayd摠=== q}1lp3ɹ3tt J,5LP)E^;w& \pڻk#`piPsU:6Hx#teK(6.6.6~wB'4zFmǾ}BеkAzQGMЧC}b1$ @):EQˢE-@xyݡߴ7`x&H'l7nֿZj}hC2ze i$ n{ppgBa?r_W.Mr6{o111m[m v?d 93888;8wp.TRJ*;;;WG]uula [F7n& n,hhhzVF %Xܔ)saϻ~3\8z腣ТA-V߭[}_'>aouց ]*t6l T*S ѣ/R% \T.*|lǠo!!!Cʫ ;wzË/־X ;w hy籰mo ttt3grd(5R!353534>Hc8\|p1xYxk-puu5!J8W\su`흷w>N}C >U;W(J7vv Uͫ  Fvvvv]cw (W\ra!W\o{!eX˰:`uJJJ 'X2Cφx4_!^O?Y*׬\rMgPA}h\Ѹq;jVg;vL1ƤBBBFFF wG!|b0:`t9ԞSuoކLkk^׼ggg_ |v{ ZVUCW:TS}4lb2b2b2 |`/_C+8444 *-*-* Zj9,P憞 (A455xB&0.^xEztѭGai㧍VoX4& <⣊49hrdx 3h0555־CVUe?-iYKa[muՅ{94bV+V<ڥKkX~o@AA2&m5jS d DIDIrqVLVLV qV z|q86؄cL[xf9rb 左5z뭯=`7 m6SB5׼͌53A)Rn1J/x Co0! \~g֝Ywfށ{wM5}L1Ƅi.CYi=CCCnwxf㙍 U8 MM*yʠRໂ @au~a/^Atqtqt1(oYx{{k^z뵇*U :xHBVz= ;C)lyAPԷoQ_COB{{;/op`(7 P|%г#URWH!v[mmDω= :)jyst_}aaaP\\ /ӏ׏׏Gtx ݵ \zplz۾].N6ACC ,<T!or+++tpi;Wi\q`W<V[ &L s\Kt- llF)nE"5O?3<2#1.c\8X7jݨu`ѷG߆ )R6@G~ݟ?nݬ|#0f6lTSN;wNyx!gggIn'neRߗR1bJE???<y:4ȼy#o[߶ 3Kg!<κu; {.]:t<}=zupo½DO=C(V֭ԩ]vlJ)ͦzo߆aV<}<}<}{㞡gWO ⭡I$jALL ԱXu,TY,0+Roԃq3f wYePG#h `jj fffÓO:@q|q|q>>`U*ԥեեAOO-0Z2o=zڴjӪ m?l??$x&x&xzR!۲eotH-orvE:u CU@Y,SA~!l|mطaB) R ʹʹYgՇ 7(V4hɯ_LT&*RNL9 'xr YYYA{Mc㏍?OzV"@!-h[N; m4#jͨ5 ,oY޲џ~xۍm7݀ *p :n8ZkGztW\qnmMmj.s1__Km&s@;\\\x٦g J֕+ON:k>r_!ğRg3z2dIHx1k}[`kGUW\l;v 73g,X n=4 o0ЩĻF!PN+@#ꋫ/<{6l sΝ:w*J:t( ~!<+_۷7770000th|pEWO]kPײe]˗W7Q7Q7%T UOHB`t9ou<lȳ!`ܦMs0+aV/pO}wAHH[S6( ޣ{"""l8膣%K@]r]r]r!uN9p011S9͒ D ___/7>I<'?]bnn7oZ*lUK.m-xn]]vuU!⇈" al؄wOzZzZzld"`ʹʹ̈́ESM]4|}}AJJ  8*;,X&Y&Y&OOO+U*JP(S)@6dz2t!b: 8x`Ⴥ>G=7o _X~[ڃ! j;0aztмммMћ7AБ#AGQG57{yOi?Ka\a\a\jqť̶3΀m&M`PĠAP3fN B "6"6"mmm!-#-#-Yh>q_s/XxEM)RqÏ~T}U}UoSś%@$J+xkbr˽5i Zky`7nPȫW-wdޑy> 6ېnPz嫃nnn\i|ư[ʃ2 >dPwXaug jG;ATJQ <<͉}=(mڶiۦ`RդIUH% lwL2hwt`hh999p$Hȑ8`Znja(R(A }+uԽRp*T)H24e(wZlNЎ׎׎}yzn9:< z4i Vb@fpÕW#;<jש]v7o vpo*jjԪKKK Ǟ{~,4_|eNNN_%J~8ʼn/N|{Gwt,pBS9r ;;;7^Lr0h젱B+֯Fj2C IA&pnƹf;;+W8&M@nպU,g9-[r7n~ƃ@{L{L{ V{Zi5Z6h-ktѽFnvҷK_m^~~~~~>q~kͮ5@s΅ju|< u4R)@C͇q]uA[Pu:?LCq?@*mӦ5k6[%wR]VpVpV0߷}p uTQ0jl+(r.r.rb AAAο 7rrrA5  1ǪǪ`1Ưr4!"! ;!%! B@RBH BQIB!J )B!D $@!(!%! B@RBH BQIB!J )B!D $@!(!%!D  FÒ x u:H\>q=xaKYyYyYy1ecFH8&q kx3T?:B*wM5~CFJ QNFOӧj,Y`ee+mWڮF:z+x#.x︪\U*(g^μ9M7|_d}kZk5oUwBwlllk'N`? N*'x3Ֆ\4tixƳ߽nkk :duu5u5u5C͐#B_x|555|ڻkzC͒ xo@.]AZZT*S)Տ~5k:o!{{&1c$hj#t=L3N'a5B7000n=SHNNU*MP /SUU CUVZŵkׂ 8UTSe@SS5lINrLZ6i 7hޠ9g0)B7&@tҝKwB{5ռ@"$'~S /_"5ք[@/^b-ڨڨaaa0ְ[n&&/ɍ]֊Y+`N9III>|nJҫ\r}nnnC>MLLL(^޽;({=ʞװZhA3g; {7v(Q3gN7t: xeBrBrBr ^B =.`To.k L3N;u씡S!ߖ0kaBq#Xc}XѱcEC{fȥ#\2 e:x_IBmǦ~l:5k4jw!Cz4mh*i*i*i`Kw,ԨU/Kx"iqő0耣|...~^~^~^I'߻ot}#@{#N{:生S~4ݸvچsuu3g[iq⦆N'Rȟ" .\/@NU:{ ,z/c)\bp}!@_+._\˿Hz =n{6tO鑥G >w|܁w 1rkΕ#-o ]=pcǷS:tЭC7PTT̈́78zЩĻN ?y l}={Dp q q 1tW((( 22KPZ)VNJ+E ++ĻJ ?:yœAw;CvZhTޝ~w_|Jo4pVYP~PAGiT]%@^H} p>on`ݢEwC{/p_c7fXeYeYe:KNNN0ZkAHnHnH.D}M7N'5F x{黧PƸqchr&ԧWKץá:Z>h%TNZ9NF: n*7 LMM7y t\qA9s|xႇ 䑓GN}>JoPt){>8yɓ'SNp竂2X kccc_~ѥK׿_zW 4 lޖ-涘bn P_P_P- GgЋCM5hl46~$H Wh\W.^ Grd x{{CQEaCƆ /חu"D vځjQqFŰfњEkcFJo.]@Mٛ<C -.gޞy{&컻opu+]zOǾ}BhHhH{tMx!Eom ?hT^yo>i5jt~bbb 9׃+ή8^x1(SxTJV) >s3(\`3dɜ9g3-fZ###0l4h0L4h2{4 'O8cǜAIv)R:uuAӃM\\\7G[!ڶkۮmVXz RH)((@4Dn *l\TT 6l,+-WZí: n|F(jTԨ>U}УGorSL1K,[Ђ0SŝwZ p2d@)B?m۷mtV:+p2ŀWi4555333qkkkbXnu?Bڜ9k|3gB]Nw9 fZ`V-t(k5???:{wVz+y}f,xbh}' l3EcjP|}>zW_S_S_}>K b(((Le*Ca:u@LL TZVuOuOuOPf(3 8I$ ''';;;Le*SQ+VTY, 7}#G%O/y@垕{Vi**R(6xj)x݃|[4o2eR_N8/_d~SfN7o4r߀ONQEo8twAw{&5 p%@a}`pm!@\s *@ջWWҹt* 4doM J-Qy2ʘ1+ctm!G(*.bhMkZ[FmE& <1cccH)RзззHyW+@t:P|_"=OwCwCw- t;݁ԥ. uBP(w;)iJuɺdP*W{|(((nr'꾫cB]?~_xh'CBNg埕_[om ,*XXc'aOž54j(:׉NAƃN~w;8x] /\_Zj}54lXap=kؼo $3$3$L|2DpNtNtNcϏ=?*P|Z %K^{8{rɹ'Ǯz@CsJ[*mTMUMUo{D=`ǣv<~4`_þ}?x!-[ڷ'zyv0a٣Gez}kkkϺ?fA!TS`헶_Bx~SO-?v3fBYY;~Gkp6m. :갫ٞg{Aܽ{q@NNyxsss]qW!Ot>8!qBO~~ns;TGT?مم5kPWhܣ;;;ŻI _5jk&LL#w9n%0*kT֨,v>LMMALL ԏԏԏ@JJ TUURHPGQ?1bD/b$,MX}{kBY_d}iii`ΨQ;PPPxOcX/á> #GvԥKSBN29oWf_ ^{qŻM.BYYY. x2ɀ'fޚykAs͝%%%ՏDP)re.sOs^x宸 =Qg`3fpոj\5`҂I &A5Zh 555`dmdmdjѢ TTT@LL lܵ l@AeWaGsQE=AQ^߸ GPߨQ}#4ҴJ`׮]vz}yTQw- aaaMզjhTѨQ,V[X YgdN&M̛ gTTTSTNByR^5ske+V^l}Vȶ˶˶GA^~ytҽJ+惮TTySMPcTQ5F*U^߼;xృٮٮvaO_"@!KKKk  11W -Z:|u9r 뛯o~8ې:ub{1(cP H0N0N0BP,9sPGQW&9,rX0r˟w)v)v)TTT>!gz@*:Tt 87pjcVPh]h]h .V.V.Vxk_|%^Ix~'_tӡO⢊*.zΒ !Z; o%|Yh 4838.>>>nY1`^1ycFh@S):xW)!ԫC:@MM \l{哖OZBVBVBVދz7ӛ =+o^ȱc!$"$"$k!#;@;t[cnMٛ7q9s\?O`W_:::CʛK%amc&tj Vqjt]% /'?Imh:u6qG~6!!!ư>|}pXkQE11ܱ$ B,[Xl~'NCЧ/_b?C{¶ok tkӭ!׍n5ŸŸ{ s鉧'nnntas͆N%R3 'VZ=hetᄂI?K/ݿ4XjcB /_5j<4? [(X_koTG{.]~_}%h~F os~t ->w\;ʄ_""D(EEE/.c>r}zw;vzPr\%Q;v@⇉&~9s&L{lA7 F}gX.\hdɢ={{Pҕt%%KܮsD'F'F'Kݗ/!Yg AdxRI'e ** XRzoMь֌֌uf֙,Gvq$l)Z j,:Yt7v_Ͽc8k^ڷ0tCw@u.ֹqdɾ1C 888 f9f~x妗^n:I$PTRQ%q9r),SXK.;8q0 ;຃PC:R7K,}Yg9k꯰|˗ F V'NX^x 4hzF PVVU }J.]ÅM6]7_|qT?TPCpʑ+G++uuuOnÎQ;FuC3cccT\r`>|8W^z!FJ5kAHHpG h_Zi%=[lٳ`V`V`V>Y໧=)PZԂ,3Yf*p?L3`kk =z0k׬zzzxУGdE@/_VPP}}}}}}<ϡ ̃̓̓_^mWC"$7GM4(mJorٟ*T<)(DDD{58j0lꆪb‹ /&KKK0Y#0LzS=XN`9TTT &@QrhѢQrvw;P\\\ЎЎЎ&M|{z.]ArPW"AuBuBuw (tjjj/$&1 0;NP(C!/WcooUW\e0?>]tS5k駁jjj*9M (1Fe#p܅ H>8}0$vJ >J(#km?o9oȾ!b>}}ӧΟ5.k\8x>C槛nI˓)S c]ƺuÚk*<'<:u: 7ݬvAYg9rt]UwUU7 nI{$888cH6%m ws(* D!^6.ڸ$]IW_=~5999i@3P3P3jz EEE.j]:(ࣂ)))*̯0|PmQmQmًg/k¯#z8{8{8C]]Č3>p066vz x*6|j)D4h 媗^O> Gr?ϐcw_u|S2z/7E ذz !uYe0#zFhC0("@AA%! B@RBH BQIB!J )B!D $@Qr-L01t! K ⽣ +WfD(]0`6|UUWPIʃiEӊ:o<Xyxፇ7`搙Cf].FmcƶEeee F3liNsCo!{ZVH^:y5W|^1W\Źs? B^r @qssNQ:Eg9? m m -T0`RA %!{ݶvm\\[㟍6ҢK 0ZnhS f)!{N:uԅŵkINrwWW=5HkfBYr@޲ʳʳʃC:7'M> +:oBZjq!(沛!uqcccbU)x!^RIJ;? &7ly`;TQR.?,ۏA Phkk$I@VFRu:,_X|ppW8P8%QVV97rn@kk+Ly8ᔇ4iH MhE@!޾z*|vO=i|.\FFe[Tn*7xyM!..j5h^ U5T5T5@kp)R`p)l7vfGmvHB}89vkwW"ssЧE}Z#G )Oy }l2 )~c/^np0qGiƧ TY,C @񗝉?&~924eh tqgǝ:ֱ)ezBk+.2~QEǺukPg3R$G5D1QLXcp݇[7tǝwy;,ﰼt^{lM&)ŻJ ?RF(#v$Hڑ'O&MB:+Md6$cIƒ h~G,YECO)s\ytѝGan0zSAMv7yWtUT=S |29́U!BVϷm(X0`SwBA!(*(*( d> SO=<0xyyʽ I'$rIHcG=bbb R!QѣG)gSΦ'x̚{ WΟ;/WGBei177*ԯRljԶ w߹>___TlY+q8(((}/}/}/ <@IQRP|G=>Z}>T }>@e #:PV(+___ƿnѫD+J4GGG~~~rNR&)@9PNrE\RS P@***(wr7r P|݋wsSN9Q_E}0aJ,=Hp2eV[n0c#Usss֜[sn"""h}}u\q]G-[: 1xy77ӿC7o k&J2˔/S zwhC#@QC~I%dx|Ǘ`Zi-֋s\(uROS>xQEŧZ|7mo޴JC* 4LϚ5= /TP$I8pҾI&0drwekjN9D]ϻ\ta҅IC/HHHS2Oecޏ444Ngeee-<;UW_;wllPcŎ;B5:=hii55kj4 5 5 &[MlvFہ",`/ "J)BB %ڛ7kof*UN8:t5t5t5^ rZ9 &LΙssshPA堍_6~/߯٥٥zKwA `/S9VEt۴nӺ ܩ} c2v \hvمfC~W;/o3`1 /+%X VA S”K_;Xb%Nos솋K/.wd~mUmUm7C!c^o;̰a;&-MZ={!K,f6 U@+3WfNf5kv^;;;,,,!9 9 9^NTRJ666 \+ZkkQdEtֹ[nn]wtnݐJT% sj̩9sxPAe!##r,YEZ5GrVL[:t:o7|Χph̡1O; uԽRS Ck(*<#~?OaUUWՇy:_/n_> |G;tI<'Y~B#G.Ǿ}DDDXδi9)ş)[ط/F4L1r#jV0tJ X`郥O,>n&z6 R&S~NCDZDZDt0*ͫ4<|SM7ŠQGn3f lφNYr<,*좲ma9_=r@?+h_о=ln޼yM:u+T P))]Iw$݁%Kҗͯ6 GN9y$j\qWfQIBe %@ Pb.Va3fAՇWn#|>^rzipqwqwq j8jq⨡S!V|T)vn۹mW_^3fx"E U.*x8qL;v2tJ xeawvwv0SN^; hͣ5fK-iu FYLt5j}%@)M&J8r lߘ1ԏVX}b (J7(\rAV (}>78^ϪU?CNٜ9ekn~P>C}@[E[E[ ̋(Ѥ!^Bi!!!BhРy9ԞjO'\|9r>}RۥK]K]K]70!e)KY777!Cʇ@kmFZC"@Qbl,XRzN 388㠡S ar!DVV+p 7t! K BQIB!J )B!D $@!(!%! B@RBH BQIB!J )B!D $@!(!%!xC}}}沛n.K+/tY,]0 &J(J  }!@!ސܐܐ\صx]!vtpӛ|%@Zi!j0¤ *!<b )BC BjBӅ aԁSN;w@uz kׂ*߫|333 66SSS!IX&T22t!xS333V[o i.;Nȍˍˍfj ,Xlp-[ȋɋɋ\@5׼(u:㦤BA=Q=Q=>}` &eLʘUgUgUgwwwY GGG88>o-L91Ĕ+ǟzl>;!rjȩx<-[s3f̀9s"ï~+MMM7!DQJTq~W+Pu[á> ?l>\b:.bhk_[ kUUz>lå: NNNۗn_Bʼn'V;&MjXc O>0Lo?~@I$zgM УGdEpCd xottt@kڼ|0a 볬ϲ>/_JO/څtI $w33qWvq hE+ZAq5}@5Z5Z5+++X"zgMB]h &@YRwb)ЈF4kkk0mv6?Np x/999aPzߊ .)Mi@:b?s>E5j\M2e!44_ `u:B^ d̘1 - QQQP%JfLpýH#5Ԁͻ6\[sm5֏~Ζ;[,xyyOf? yf͂G6lـ=z'7F!rFK7j/L4J`R[!%%%%%www_~WU|!isPUUݬYwttt`C7/,,II&S-[ڷe Aƌ3a`dndndf|-Xݱcű͋͋!qG`ii N7n8݀-[ҷ@[xH`ʦM+ۓ'od 5={J 3^o!DaՆUVAag<6t*! C.BSBHB!J")B!D $@!(!%! B@R//@ygϦP6F!?ڗ׾%l> گ*4l ̵ZsC\IIIp7n1ws!5=5=56h`#h2e>h"5HCo)B`\]>|s8s8)SΧtv,Zlk)S0e< [7lݰuxFQ~DyijԦӊ!J[2o: '̇3'f,Y RUcƏuy_Ìy3y N) M D W>|^yXUpU!_oa9r^9p !WB l`p{p oooe (~g~_w |]2~1G8\s z^y{ysq8etнKզW^ l^_lf͔)0wd_x;~{w~w•W_)&{][ l˅ eWG]uuԫKŗ/~붗WL3tiK'ohd,YVv] ˝;/wQY(mQ 7x`pZi!ޠ|^ @+﯄000hG>UXWVTDEmb5׈_!mTڨW V3P3P3j(QJ%NK@# zP/rIj?ujԩQJ?-W?UfWgϞ={Z o5phYزe!TW^zPaBOK}ZSLLLov[[[_}3gFygHڜ9i3\tNo\v D pdGC6 4h厖;Z__Q>F}@y@x2eO a6@֦MYԾSNRKA䘓cN&M›@G888oοquF:#WWW喗[^n __\seΕ)[SIIIʯ_ av:4thP8pm }ty -- bbbn/_D9yJJJPPPٙ3g'\H~!M= уE96sl@tZZjy%-8[p5}[K ԛ7SovoMG7t+Xq.??qqq8hI$Xcz5yn繝/l_ؾ0؞={{6|lǰh#t{MqucԎQ;F666rMyz0_a|39fr f{Yg!&&_x~y(=)XcU*kA{A{A{ALR&?8uXH ߍJ*ޠޠ:ۍm7B5oԼ6>6>6>`P}N/_b̽ͽͽڢj-v9r@LXLXL3fUͪ Iۓ'm_T~Qtuu6mCM5=m/^ӧNQ5]5]5c{ ^&@f!BYgiiiw-[6cǐ4i|=đgS)۔mE`C Vr^xx(5R!q`ϴi?1y 7#@٪lUn5I~ 4TN*'cP%P T?ml­C:ƴnL;piȥ(Ί J=R_r].Li8؏n-.[\M>mrPuTuTuAAW_;A 1{c{c{cPn+ېv4hQZgj+ | T7=pTYg+n6m rh ,LYsss!88'>O|$'!"5"5"I$5[[[,؎k;ڦkHܞ=q;ծW^ M 4~:ryȯ_% <|yhhh&`W8%*-[><q6?.~\ ;w[Kn-bn܊v-Z5uPA]G* U@eG &4hXZZTEz lllfOxNB7RnHMMMz;mӠқKo +lK[BS nNݜ۩۩ l.֛7CE} f']]]`0 `ժUWH[8m1EQPʣG) _Kw)ݥtHߜ9}3vc>㢸fwM *XP,(VD51Fb,1jw{ް A"{]6w߹r_I٨~/vS)U~Sv n7@@@+616161jjj /^^l{y#FiuYb?rrrY-Z`nnB+TSiN9LQ(S@RT*mcƶ YYYBƍ7@QiiiX?~f py_?+Jeog}; Z5kլU3حc}JiR t}t}t}`Ó O6wRcԀlll8Nqcq8Gřřř1-cZ4H($M RVJkkkVk[-ԟUVYP^{}s`Tm#+kXְ!`FpjCc!'5'5'mb&ŷZ| U|T```[o[o[)mM6l0 ,E?E?E?V ,, f6AW_W_WtuuA;O;O;uuuLY,SB__]2e 6lܩSsBŅA(zV<7yn\;慨,YǯI$PH$]t@t@t0 7@ӰaM@}Z}Z}Ǘ/bbbT@eee= U#FTjՊvvv/ ;NrF6W+a0D0A.T-߂bbb)B _P~Aqqqyfphڡ5dG`8pT@D_zғ;wt@"6I'yeCnMӦi@m6RUqXH@@۠b_].F2q A,T*\!W)d YũC_41ibn}DHD"N(P8nu@/VZNh9%(&*&*&;wݝvw8iXmإ٥٥;DHkH$VUkհu֙[gA&M`tF7{sx_}AjQ~N%5R H6^vzD^{ц6|L?6c}{ur[j`+y0!$JlJ$?G H^#GaiևOzS)'v`y}Qj0yTgomH Deddo[;w-[@^pJ8;wpppxɦ'N"c@"i...m׶]vs?~W^uz>3>wׯz]w-[Áq@QQQ$TH$?¢ .,b> aaaN5^!A,Y3}HoR H}a{Z k1899_ftqpV[ALV&/+MD_w;v|88ܚskJ"R H~#Gtbϋ=/@Icc'O@9N DW??????p0apI$)?lÕFW]i%%%/"@suGGiܦq}j)I>|&Yߩr)'@e_~p+VXx8qKoH&d(G9 1q PBο@";&QM@ ]7t74#O?Y‘#EG@aK-}uA+a/Dm6Q QQQ!BzQ{F7߀K/==L{t/oҿXxRSS::,!>*>*> =wQy3SO<feʂ"fN*$ɯBlClClk?~PE[ d$#zI%?8qhHOOOOO\4ui ֞Z{*XԶmQj̩1H6J6J6ŧtT:*Δ;SL<<ͼ~|4iUN9(k_׾=7n<۫۫ \r Zgk#Gp`p r r v5jځ8&:&:&Bظqa@ZZb=qK-h} HOYYYYYnuVvځk!;;zXob=GW]n׿]v}0c6lhGhGhG;60l`׵׵A-D "3e֗'O"G=Oҟ?Ij0-3-3-UUUUUUgYpLvLvL^vx j |/^ iKӖ-ף4hnoooQ(U l/^ + nnn!{r.\ȹ&MƛU ~m-[ӣO>= ~b h7i7i7Co444 ʎ/;|w|҆І6x$H;w$<d쓱ئMc$! -a ~ >6c}*T)d<a퉵'֞Ck;̆UUU h|4L(e2mmm >^zp ߗC!󀜌 ([0`.$$$Aʕ+)W`Ye=‹ /7h 6m.b\wyzR>J(#~W]3g?ޯ~g#FptљGgdlll}ްi'0p1p1pSO>uvzwk(T2d|R B"B"B" TStV:+awW܅;w  b-("ՓՓKKK0C!>4>4>MozAB*d mpAAAMMM'?>~p᠋`ͩ5֜'=G V/X`5ĝ;w➒PPP8{0`._?G: H23d&4 l0̿7{iA`>|ɫTSMppQGK.=!!!`.7a0T*". c1g?|+V-hkּ9æ:lw?3 Z|A9 4q.-\Zf'N. wp}Â; ,]kwݵ6ƫ̰lԦMSүJ*E[F kn ]>Ay[вVZ-kA%[`3a8puu*t n:8pd2[-0LׂM)GB展V UnWQkG`æM8_B땭W^ {EF8~xU*]$uI///}kHg$wXY!>>ZmѶEۗ`@08!---y<@J/^!L@"sT|w'jРAdA vhт^\/ӜPZZ [>}@|@|@|rcˍ J+ BdtY:2LMMM`9rdg3=V-Z<ރz= 68!Wر?KYҊ1ncÔÔ@e`/ {!{!{ $$F//wO'Q9r@89ኗG͇-:8yA7H7H7b?/O >5M7^QrʻB*$wXCC5k^j̨1ƌX}C }PܠAqPTT'X\,.\h6(C hK[c=IOSL:ttMhB>˙ojSڠ|q8,"zꥪ`>0SOzMF#F_Tn*7<y80-6(lPvݹw^WۯԫW^z~AɆ'ln ĚŚŚU E_t"GECOj|RhђFKģN1SM8 @Éa]Ww]>0o@ٴigASAlتUOO!6)6)6 B%+OQ$Hؑ >*#>}>Ql>}(?q\-Zr5Q,..E555QLT)(&&$&$&b1cDQ]_]_]__}+|<Ţo)ttt_\|qQ{)?   Q|6gCEŇ/>|(uY=+{V&)7SnElllQ|]E1{v٢.GǏ#Gb{D1ӘOc>Ŝ$QV[bE1==]KRTŔ)S⳼gyDԫԫԫ"omm(f|eƗۮۮ{HD ) ) )ŏe>oߗ>}R{Ql"E( S~CׇyݚwK5cqkǭ'}}(?H߽H$wУ:<Kj.߾nݲ0x5׀hFAw[w[w[߽x{ҳK.=zux8XT﻾:%uJEwWJ@A$˵/" mi&///w:Ζ;[V_( G}3;$qǠ2OMMMUqV*[z pV=:ܣ3Ͻ?^ߩ$o H!Wkւ;6W%KvӦ6|mY۲]-ZtM<4DؿzAFFF_Avp7QQQ}@"yD>}½½zԣ?#FB\ոqU0ְa["""ϻGGqth{j{j{kT_ :'@{{;܍sU& 0!/@{=:J*$w@Az /ssnκκW=z\uȘ1'c,=Xz dDDD1{b쁲ef>;w@vKvKv m6a}[mѷ}-Z5cPڿiz;4t|bbA?OMTek֖sϹ>Yw#h0ԵkQ,,,tӍO7fA}ozqτ5kU9rHա?JW뫷T_^}y!zGФZjM3n"=xcuyyyI_&}!CJV%˂/ ;ؿccc[z=b҄4! ( 6ڐkC`nnF^ ڳڳڳ/`nnnnn㧏>~:yɚ0SBĦM@Ɂr(P!8z詣̅3\RRR{=]`ށ~2+dVȬ׿]H0Ub} 7MI#F`gFPB %/7  PTT)'SNŎ;^{JG+tŒŒ|%-ۥۥI%6ژ_(PpA \E"T 747474p3nn4i7 nR;?'l6 AgBkM6/yU*nad`nN6n75 ^EEEp?- Z(M?7ul ,@l(6Dl"6ņF7/ TjXJ)R{b(a0  c14inڷok-,[XQGu |R ŲgOϞ1cǰ>vvv$oMޚ2?8cH2K2K2[-V0x=wH] uA"1驐JQ g| ;wS`4+lVج=~]hrɡ&jzKKKދ#[3g,X•W_9]?yPYYYmP/^zt(t,t,t[InU,XDN@^Q^Q^4 iR R R P, E].III*_|2hii{6ټjR awL P"y 6vqrIXmˡZZZ C>8:uF>F>F{;w>|9s/_lvďŏŏɴ'ӞLi-ZBmUUŹŹP͸q5ce]˺5eee?(Y, 員a`I% Mox\q1OOOuuu1+ 0\bpG%[_N";_i B+;R:tP 7o=`ۃv۽5$C P"y%|uwoK_o'}LAmm-9s %ɛA*$*^ M&CUTmSSI^7+WgY|ǟ~SI@"y AA͂5>>>Uߩ$aaa:fߛpĹN@NNNNNIm@"y e=tFFz7!~C666ΤI;THB   `9r\ܬrJO105050}Ō3 㓌O2>w:ɿTH$o )R6C{Ah} j0 pvvSCO =5Tߩ$R 2b2b2b]ޞd`e`e`߿?\2)eR$}TH$oM&[ O3f>Mn3gWN|}_WRRRWo@SSSߩ%4D)Ur,YxZSIMNN9s -h)b/쾰-[v.̽0\D%*;䵑 -RҿIru`c}蛺qZ OO?=4߼Pn^n^nnN)#RF@J"^H$HQxQxQ8~vvvN%ї+fr C† SN;(?PjAuuK^7 Dɉ͉͉N&L:SI888\>t}b7 xCy DDDc}n-4iSt% |fgVPkQE;uކCƒ  99n'N )S*TIIIאא-]]](xxxEC AQc%JEs`s0jjԨ)d0T U@5Q @;wP~CɃ%888J\+W7rfffP`Z`Z` պպՠP)T 8p8nr79x5]]]<<<f 3ڿTH$otttwk殙`ᜅs;UijjBRpRpR0<h>.|\8H~/Ȓeɲdp9ɩOA`gg-7r#4m4l l l @^]^]^Nu7{O<Ϯ r/^ν a7n݀k̯޶޶޶УA=FADDD߽Hg$7H-[l`3\sε; JC,,,C,hՂVAE/^<#GnPw`݁uBnA݂КCk] w;KU*TBL3`F^{}c  j4@ߩ_TH$o999r_w~uA|,>â?N]8u#qGA&1MbSRRN%J',OXByuՙ 7Jn*^X/wwX#p}KtNW^{ f.;'n%B޸qy~Nݝ;z MכJ_,~2DȘ1%c 9Mj4$wZLjc1aaa6ymӻwM$&1 ꖪ[fH@jr^lz+**BLJv|(}Ӟ={ .x!M1b6]oW!C~/7Y,l>+}V ëoL1ՋTH$o*5ԬRMo7tMMMxafnp;#&&VŬY>W|\O~2P]v;囧(((@iU/"EV` ʷo+_X6pe!crN*$7X{m?0;`6T_P}ANށ]vt׬^zMx_}%}b'?ikͿ6ڲj*(SZΫ=f5j3gτ?Di~7ro={|!{e-[roھi&;tw(D>|>n1~#晛gn !] E E E tvAgn5j eNz}UR jݷv_}~k>}xp0kf̬S߉YYY0ۑߎ < < }@]S]S]l'<*xDEDEDENkK !}D>>~ N%''S7O<<1 t6@S`ii a3f̈́ot&.++ G 1x#^*H`&ṀQMFMW6]w#FNi4ApnܹqAqQ]˖-/Cby/潘 ?g%JA1סrQŬY- gtܽr`QdQdQ̯_{2d‹ /.WW^]y>} ƳgςuG`tvx"Erx7oyNININIо^z끋'lj{*quuug՟UV.paz~k{SѧOECvnvnv?s\M3>:(H $ N)~aK-={0[-4gIII"~gwK~@~@~ttt@SݧGȑxH<$q-6Z ֵk[׆|[lg`.vaRfa~P= (C;Zh;K9#?#?vvvPA !(-(-( sEK-Ep\yD':lׂS+h3 1H!@ Bg A|A5oSL1a0U &&&0*ë(((ڀ`(hB % uwv ]G|G@ jP0s033 .@Cя~`ְaۗe-Z\\\ꔪSN6 S@"'eEASVܭ[qWWWw ށ:fuc ;wJ+VcnrP١5zY`llN,'XN=f{̆;K7no7wix!yyyy{!pf.]d;u u ucBQFQFQɩS/$_Hy $$$GHNN0H.S]R+VJ-`tU*={:4? &L,Gsx\0<<r{K.ףG]"1Wsy癐{8paxۀe,cd8q4W4W4W %(%(%/g_ξ̯SZob5Hk'Fqb 3]~&;[lz.\ꁃߒH^d$(Qp;Gw !'BN6 };vơCBM5]}skBׄ]wu_]|uU0I1I1yd$SfO໔RKAX.c|{ׇ'~@wLwLw > > P-ZB5(^ܽ;6m,--éqo“'O u@-[HHHWP*Be~H&j !! F5`(++Ó:O<RyzuVV?`%0kC߇}TH$ Ox4iS⫋aØ1 |%|%| "D4*UHϑ#x5 1:.t\sUuW022 ;vYkg-Wg^y*uԽRw}.ϋ?[^O㯌2 k'UI$?A-wCk;Np-'(Wدxxxuc֍Y^z w-^> 2+e@uԅiCӆ²ei`ʇS>!X'Y'Y';R0`hPXpu AkZAC ,a0K)DSL1 94?;l0<9tb [@ɠA'_uMc) {=&M> ,,,a'ӟL2ğğğV-a K .7.7.k{кiݴn0y䉓'eM˚5.H$vvv+$''ÕW^\yw~;B7;0zwPjA_ЍC7®ջVZ -N\\f_S>|J gKKKKv.òeKi9rJ~Oҽ{ DŽc.h]к.d0M4M4Mw?N y'½{y/$$$/p3s3s3VU]ϻw=xdP)~~~ /A(v߀vF+V%CKO3f>`W]wՇ;o켱zG -hE/1cNR+˕pG{G{G G+>+&zM-Z޻wpAKK㼭įůůhf̢mmm 7pcD1 [5j K.Š_x[HVUUB^_8RWN] o\1tlױ]vP`̓5 /C31bc,k`f;*R~ $.K\ BBB iP~Np=zQoDPy5r.d)Xjo-..dddKk(V>VBg{h817qoݩO*$o_V_o|gƟFhuTQXcMǛ7&&&%,ٵdג]`6l[pR?N,; gφʑ#+Cd ZFj ''j9֮][{{{eee]6lvL L L @){z޿J7O7O7J_/w,X-(ZYg xxx3x!Ҿ[hn!SO>{S͟jޫ# `9s.B[tK888t)R-<3g>OyRnӎҎҎbMX7$ncBBqBqB1XbPZPZPZbMXkkkjbPsΕ;UV v4 &LnCP`0`,qM&TkTkTk@i4UBiӠD[-BGG;w -h/k/k/WU0`2d899[[[0[o;PV[oe?~@BBſI(%P/b ?.n,2b7n {44hhLMMow'G,bKR8Q;"&&VXaԧ>?OMnrʋˋˋxTQPԺuQk( Q'NFȨQ?>*}GQԂZPkA%?`F;FwkMe*SH# $LgaEW]f\!C^^*85Wc8|{H)Y)Y)Ypֱ[nJw*ݩ'՞T{|EYYY 律 +ŠeT2D8K`+عb"$zЃ+ߤ@Z'7?!xzzN? ȥ}cN:ZֲVߡ$* ǃR)uޞ cӘiiipzaAȊ!+{G־[.ȍrc} J*WWWFl#w(ɻ ɻ4#rkւN:y.t pmܵ9L7{ާO{wPevvv'ЉNtf0'yXܶmqRLI4#?888.TPB%8p*T§?=A={:4iP8;O<O4w\n.YYYYYY}B*$˷---xhࡁ [ [ [#"GDfכ]ov ;v4版/)yyy:(/*/*/4bI~%h&fv'N05^#{`jbjbjt#2/wc %yW為hghghg6}B*$SOpͽ7\ ?+e2kc=2 < A,2} 40hۺۺ۠iiiTM*QJǕsC 97?Xq:|J/r_DWM&h|TP;]cg9hninin; wDl"6G)R]Ż~Y0i8'hrɑ&G@.O; Մj@;=qSIU] vZЂ=== |G|t_@zeTY*Xv]umae핵Wk| &|k5ռ . Al+;](V+ABB*J+בe $IؓՖV[Zm)̍77e,cSK^pD8"m=m=m=*bbb[-\\\w*&o'yq'aǥv\V[Cn mצ0aPA j;"/ @/ƃ[' #DFGRJI~!R7V7V7 /þFk>>>N ;}}}*P*Twj"L& AqӸ2d򨒿&H"AtD7DAD 3GW8H$M&YTbPP1/ +J)rZ%JjXc;#0fܘqc䝓wN eeeH_Y@V2i4qS q\z+:Ó3O<9SRŇA9C9C9!00P߽8ڏk?wߧjjjϭ[=CR{p3mɘ1%c %$%$%ttt*^8ḇ`*U.pmoӞממUW=_fyxa0cZ0k,hyAEEEߩ%4 L444꟣٨٨b$}nNݜ~~߫=G#"kE֊,M M MeXY /j=lk/\YY 2q{hhh tV:+Tn*7:b눭#`aq8Qp #ˏ@ҥKxH!w_puu67mn~KTs`57܄;ޯ~k)Scۏmŕ!dBC!Zh- tݨ4Кִ" XR[˅ArĮbW+;⎗>*>>>c>~iMB A<%O8G#)\Rq $T|nj /M4|ɗINr&׬#YG@?=fÔSLYMn5TY[em`W`W`WpU* ;v,[m}d5 _xP<"q_uQld#C 1p3\Go)T B .e]e]eݿqadq8O 'H$D`"@LL D,hGhhh(((D4M&DAT,Dq}||sϭ>f.B¹s!11<'zN5Z?^&$9<~d6>`+`/''' rZoTX*,ARy⹋. 111|y(]Yt% m0XXX֟[n=_o`|)%K$?|Ðr#F P?V?V? &B㳍6> k=*KJprre2HC͆ 5- 9rtWtWtWjdȮ ߵwfݚuk(1*1*1]Mv5tgugugAQ(T#a `gegeg;Gs$ִִ@S,;Pv^}{ՐP?~B}8}"D4ѶѶo[| `<tOuOuO!,, 6~C{7.xiqE:MO6=$p=zE\ kE׊].T Ʒn<WWWO7n>ݠ}Rx%KJxv״״b݋u/օؘؘXh7awwoMa}CэF7 ԡu\)Rv {w]7oԟ[nή:GGGt2dɤ"X|,>=z-ǶЇG'N]QV]iti׷3zjjj {O=,kѲFvwmwÌof|3pIC[{F1Q`nenen...PSSC[m9%d2U*؛7{o6V\[}:RRRrʥ+ 8"8"8'On t?444?(Vz/_2fH۔)mAyy9>SdzMC@ǀaݲu-3#Gďs9rA M&4={>J#*4w 5oԼDDD.@ a0ES LjԪVM4`(W)W)Wk{潚j M\7qD}>0vaBFJx'`c===`nnʡʡʡnxaKw/n36z=Hscύ=7 <*<*< D;NK/}뺯>0fvٲg˞t|@&t;$&'&'&Cɺu%4A MxyyG{ѻGAVVZ6lh Nv;~I*$#:#:#-)[R78~8|E0`рE=FҌnBCC)y ȳl0kx.XDYDYDA㵎:}#FyGyGyG0?c~ xyyAkׯ >*U8}etL]&"TVmZi`kkkkkj̨Q3PWWOL?1urrr|4hR"E@RD f tldzv@oo/Cnnn{JFscǮarPգGU~{ᷡܦsQ  ZV_'g}rOOO%%%V Vͭ[5u:B F+V 356k ;w ^^L501888!C \{9̒̒***܌܌܌~?|EEE ;,;,; FFFXXX Lۙ)=r}  B{>#PqI"dr\&ȑMvO*ާ2s̜_OUz9y^~!Gr@+羴<*e?Os`Pv]]]9e ƉqbC!MMMO>u{38***)Nq&`¯ar׾*tޱ{pkշVCȜ9!s__b߬+QJ/ô +@m< x'pMMMo:t _zkc} {=` ~i{/cxPrT%Kp_8ǩ8^E%g* @ %5(P]B7 7hobWŮ-<|=$ycLsG7x455CeJB>tSM;M%L @HRԊ˿/{ȟ??><-|Z=i\\\u:N-[hw~ iSӦMQ :xxxvvvRI')S~'xz_|FvAa,,,72nd -:ԢSlll(S)^sI>K>K> @e d1m? [fnP5j@Հ>VVVe2MuPPP(__|=b P|kV~\]] ׃J*ͪ4 \ v hTQFu / NNN(2"GYRYRYlx?[o 6nݨ;'''z{ur999H$ڷnߺ}k///wZɛN4:xⱋǠئئzJ***`̦M3迷{!>->-> Ʈj8E^-ZP ,! nO=tH,H,H,=z@ Lr=.O<T6* ؅؅؅@[3gXπj[mnv~1(((]JW{-XXXG>|fߙ}g B<lxL1lf̶ kf_C_C_CJWW^ ///SΧO>DZRT˩S!) ) )^z;³grsCPn)o)o)!-- ʋʋʋ@/Clnlnl.T[nP׽{]w`! Y!!!!!!`spݭhP*B;wﰿޞv#mp+Vx3#fQQQAM6i ,Kc A0aCN PL3@9s@|$>WWW TqPJKKʡm:ϫ֪j-,}(r:U)))D1ia¤N'y[Xc鏢8)uRTQ?D_rKo<'ωբZ;Qg?ϧ% b(:N)bg9,l2Quv]_zxAt`8R)KKK([-EQ^^^y([ŭVQOŧ/}>ULSEQNNN{)9|(迣,kYֲ?0b)8q8N璅(f/:qN`1X Eq8@ fqܿKR]TŋEK"(ϢN/mxI$&q\Re ' 9b(h+buX]8d1Ybq(bҸ-KDQLDQK\(+6SPP E׋]L1Y[$Hlrfb(Q(Qc1FR(1J)qK^3ᗿ+'r" .,Y4hKW~Õ%.+YWoyiY}aiԥPsU:a=|e˗A65lS!`き6U*C&M4iSq[?!jv?\s C WtI&m:u( z4x\<.e>A涛 ~~~O?QQQ߿}QQQH,峔@w@w@w:/u^ F{#y_}zzzm\۸EGEGEWn^m arɹNe8e8e8AAf'E*$].U ;wyÎ;~ITJp}K_|ϡ=4 h՛H]"vE@zrzrz2|.wyv%i&?H3T3T3Kݗ I'u/nt3D_ZҒW+A]K]K]՛H^rAc1ј$z%=_Ty<ض|muF0kݳvC7ߓ[sq8Eh>|Lߡ$:"""wSQQGmxntF'PGQ]1R#!eRʤIpqšB~sR;˔˔`̍37΄K/uZN)Zagop^^^ V%o 6a-7<@ :u7ݿMw(ѕJt˾k{i{i{O,>wIRQQ߹| f [3fnXS 3gB/jQ }ʛ˸̸̸ _ k\/A8#@ = RKps?***!x{pŮʢE+%Kp={077Cm>3_'C-;\p8i4rɝ;vرcȼe2o(苢/`~7n]g_}}ߤ~M;wBuG*QGn݆ u/^\\\ //E߃6l؀e&AW_W_WN;i$0{n9잴{I^7nz]os>deeJh%3 gJG* yyy0ٴfӚm=R"cty:h|y,[l L3 @]v fffPlaBWmö 6;9wr! V+ rkέ pH8p L3y9`qiI'ףWfXӰaMMMM xèQ%JZZjiPkջ‹e/XDE"q)gSΦNS`o=5kl>%UK@qIqIq nSM~۽E8bOŞħ8qFckJ)@PPm=Vp8q BNrԎS;N#8> `-f``jgb}kݺvd?T:j먭={O'|:{߻ :N+N+N+ ` 42bkq8L?f^|g a =3zf6Sm@UjWɟc`e`e`/_ a0}>aK?o+B%J,Y`Y XbA^^t& a b!33RVLY Gݎu)SCq>}= o>í[ BP*U?6uuSW(P:t΂ BP,#V+mr[4ӰNX±c e"3(gABBP+JF #}9rek81K9r  <2:etbmX L`@*T6l>T'U'U'A__bĬY^ݽ{<%/Zb!hkhkhkNO;=pl䱑FB%+J*tl"l"l"Ld"ЍntTPy U*P7%nJpszt鯼D/ry9hviviv;+0s~/즐BK?e_Ve_V[k@Tndidid иZj'>6<#xF*}7M_,Z ‡?a{A)fOx"@{ソ~8 o;a0u݄nB7z ^ `t=0r7r7rcA㍍76A)_MjW f0#_/bbb }վjߗEЛ2eˠFkԆn,.Y\=?QϏ@HH4-4-4-'Nj 6wОҞҞ]w5bZƴi }nI%o8sssPTTwμy;vp%Jxf5@KA}V}V}  4QQQ#GtHPQQQqXf¡|i(Q#P|^=0a6Cߣ2 N,; f7nϮ]=9u7n---鹧瞞Beϡxg❰yAuu5x}w`QɢE%` jGd!Y^WzhN}-lH!͆@QQz?3.sg KTX#F{=kb/%KF=E,XT^Cs9'e3߹fa;s L˙3-PE_@n@n@nWWWASr(Q@ccދiiiPx|y(++HP$(PxhQ033^^^yǡȿȿ.n6H8p,̿rrryW82#Cb03jf(p2eCJ$ǭv Zc>WXѱcŲ?w??r#tҕJW222\s;>#kkk%xX 구ײ^K1cCOOXll,{[ʸq):t̆ 1]˻wn6 69mrVQVQVQMצkK/XXXZkZ1cfUC_u_u_55kv?`ppB=wwCwCwC0[o#G{"D 044<<<'ezT[nźPYY 666{:`K>XŇIvjjj 7ro< = = AT.{D$Iޓ<( * * r.\ʹ{5jkoe.\8\ \ \ V-u[deeszCu1dPɠ!=S}HތY6g du}1cvL1c +W7TTTW!Wm^yU!vFکx {F퍂G]Uutɛamm ))`ߛQ(w-{ B#4Bw#F 0nTݨ:,Y xCU]3agNf7ӿ= BKK bRcRcR^tyEx1Ťm>`]ǺuTX*,xh@v[v[&zkd/'w/^]wu6\paCp9r尾I$oWܐ!qC{y xa0{ӟZ֨5` )R% 04>7,y;{݋v/ڽzM5dp2oڙD*8vq^ /›7 o۽\SK/?WN/y~fgP3fR$oAgYmWH! 7rO޼utt`O=P޷oy_h6لfN"/ΦM;C-Ff[_o}ukmڮ?Dg4i(<<<~*Ϫ< /y뇮M"6*cX$wC&^M7---e  ?(?(K/ / / {orRI-'9s+[{{{j]LnmbO5~vjK$}POQOQOp[v܀ҀҀ(xPw)RJJJSIN٣٣... kkkPZZ "D>=W+A5jZZZ U*u5 :c^J/Pw#I6(U8p-.Z\J\)%KtRRRc-EK"""um`?~txht 5[@FFTTTp4i`l`l`l+ W.qKn/q}1܌w3.pBP4R4R4w:Ոꢺźb]r!!!6mr[H K K a҇Af~f~f>'y:SLT:_| /}>|%n[@8ShP6d5IM)Oy ڲڲ`~yimڦ5k555\\\;```K G?(X2d \/^plCԕ+!mvِ*Uf+Pa3 >O<~_|000Rk)R NX:Ar#s2 d ;###qqqru.{9r.w]7MVCX UFV|||/»CmavWaZiT"yQDeeeccc-<icƤaeʆvBۅpQk`888|6Q'N`U*SSSA9W9W9 'N(EW]r 5,Hm$⢸Xm6JJJӠ䓒OJ>j%JA# $$}Y_x6}lXH#I?~&ЮЮRRR;;;<x4h-[>pAW["EL^!lYزeiiiP6ڠj...}9DUQUT>} @bz֊[+ngn}2b3b3b S+Lfkvjo60mjԴս@[W[W[[0o<9wsK͗/!V[r}PWW_S]S]Svo _|_| 8e2}}Cvt\g΂AÃANM:5#F0 7nK'N.@9J9J9J߭-[_1b'|z2,/X^ީ{hƋ}J`x }Or6m=\8uԅSp彖Z .kۯ:uăjjjOk5?j~|8䶓#G&PiM5@-ͷ4UݪUu@@@h)..Ė-[+W Zk hIA&`3fD}z#:3ά;.xzzmW(U* qu@A5/4_h!BZ PiSP FL`gf;sEs+ϭ v[mZj ,,,aܘqcƍou t }c7PkZiwA} <x.ɓ'Cr{UW[go|||5-[?dp>}lHܐ!? |da|>|X͍77CCCȨQ5*UVb\1|9GGGÖ[ovvvH6#m|~ӎ և>}@f:uAYYY:u+~t0hk[El[ b6'lN],v.]f o.rd921c/W\r0.l\ظ0\&p >2}d?lCXaEߞ~{n_Caʇ)¶۞o{;=v]SB-6&&&oC΀#83gπui[~ 1`X};|0`؀a6m΅ |T"}m!FK.]o?v؅c &xM1vcXyy啗?tmӦ#RGB-S2!o\qF!,YS#GC!b^ļy!]>q!ֻw_^N+ĪUɫ"BDN&ĵA]Tד nvf 4?h~|! 8x㝄iO~*DG~$Dkk_~wxwwzg{BF~; :t*Hn5X>|Ç iƦfM 7[o]u"xI%BtٽfBj!n0a.D]v*Dfvfvf_:~tө)))B>TSB֝֝ nnn*Dㅈvvv"]vv.BȾ}#[a\ | s!RRRi"M++BĮ]Z>3}f1}$w! Z!/ӾLR9[W_]; 3PIII}QYNYNYNBl9J?_3Ϝ?s^ we.s!..Ȣ>/LJg?VX?~d_vPRR~6tf:3$Jn MMM/KKK*Jl-Ȑ!~_/cj2Hߜ9}3DDD@RpRpR0u[?"D(7ܜrs@LL ###e`iiY6FDH ]]]PɩS%'ꆪ VЭ[P_~Aʑ#A@@f`1X ޿2 3<@8Fc@"w@VaVaV!$VHX<0Hٕ+ge X:ցKŗ/t8q`kk[5k_GC3Hh:u( /6sm{K .5jfXͰCI"/`Ye3+f”SO=-{Z|H.ac5jʖ*[@·9|t[m ''߁UmTg_<@__ wC `-#w#w#wp8q>tig0~Yg{lVuX2@ Z7GkH!h۬m 4"4"4?2eV((Q#>/eȾ}E-j+YJ~%/QC5fsj©t9 &MhG~4X8nqVUlҔ9K VJ[[3ߝ VVVAz E݅ wCQ.E]l5L$D())1JaIÒ;vmеӵӵ/EQEQEQ 5 |I%poBK%j(**T,KxJ)PVV/>d 6<(L}0pç3ϜF ;;;;_;YXX+b$&A\j\j\* ^2eh-[ڷ/*R֥KVVVT7n|||L3p$HP߲~-RiJQj%}QGp:tp6lT(t.t.tw`ddnSܦMvFh&f41ibDxŢ E^-Zz5Ș1?c>$?J~&M[Y2//T-U-U-!vVpz-xX<<<9|&Λp×_ .ݻtᅩ?~`ޤyMWD{m3g$IZy}ZZZVO[=mq>qv?K>>>-[dHݯ;e ѧ㗂+.c]`v@Ue=L3qDؑ#wk\,-HRfkmC#4:M7m4Ⱦ}%|/>^|nYe|{vmgeˮ]ALL n6fsXeᖅ[ kZִi?0l͟Tm^y0xc8zţSo[{U߫= {k%-i &&&0|Ds׫/())Y(((l7[o]5Xnk'OzQTWm^y`4hp"Wko$SSS1)cRx=d>}3Ϩ>:ܯ&jjj;VVVeˎAWCWCWjqX([([(mKmKmKba=zT' ?in>***=#s5j`xqՄqcƁqqqhNhNhNc} LoGoGoGXdO@A頄g4_~9P|0g朙sfsss/%Bg>C W^a8P Tcꏩ?{#F 77O} ;]w!B&Lu߿1e?~.5ˣ<<<(?!`VY!!!$~І6F-Z41k!bhЈPsϥ?UUU:ThZi͙; j2uoԽQo^Lf&D':;Ld"26 e_ 'Є&#TPU>|Vyt#F7~ Ď3J> NL91˃:::*055}Bv |/BWw\  T[QnE㇎:~ d+d+d+ ~Clilil)X(, 0;kv,ܚ{k`aa¯_ҒҒ0e~V0Ԏ;ڃ^H^H^{{{£?:]wqx}} ܻws'O|O+? ^^^ J+IK K',x=8w8p &L. nǻa[öm'OnQQQ`q/^><(~J?p+V}ۧ ## @` ]v}STmgζT\UqUUe{N?~L3To|?_pơn7iӴ'8;;ǃM6r=+r=,N(O(O(mG&m lلu9_@oW YYY뺃5k/rHR-<--\P2u|?׷YMYMYM(ܶr۠ `u%i6lVk-Ž ;*#c#c#cعc玝; QڣG **ZwB:t } j/ии88b+|xq%`v"w{_[OykNk@ R;bwe/TϩS=ygv}k-LI0%,--boq@SOi?=?~x{8'Jߘ1}#ƛƛƃ-n<bbbHf$3L.`˲e/PuVuVuY,W j T*?pS2$8qIrJ+Fi v& n22l)OM?5*\ppKqKqKɷoͅ~/^ƽ GzT d Ye W0_._|5X\dq 0 {${${ͨU*BOgx&ررlkֲZpkgZ״i]P,Q,Q,WRrP!(j]Ժ5Xtj5Vݭ[uZkA_?U@xً^|r7nHHH{ i{`ĸqgYϲ.].lmme`gg9S֌piĥFA v>}`t5Ypf_6y y y x`d6lͿ[{߯WЗ߶`ī捻455$$$x(LMMz-[(_M qFgg<(3L-Z5h:h:h:,\. :::~5ȑ(G?/}G]RC AV_V_Vr,s,s,PCՆ xaB illl<4(iPr:t7<~8hzizizAalZsЕ7>U(A (㒏?U.} mmmmq333ve ]c){^~ ^ac}#v;b&1u:H#O,YYY(ypsWAśoV G܏Ѕ.D(PܡCq0 1 1 O>.ox.{.{~~~ No]Ya n`1`sss!r^y`͢E7޵z{Qq@IQIQId,X \wt ;?tNx\q!)S\-B8[ȣȣ0 pjW-EKaq' KⒸ8%N<(xQt:O'b ^ N/ ebXƯ`P1T m6O:PN:;_5h#ڈ6e^@2n[eee"Y$"tN:'TjTQFPt[6ҭK.@Y,P}KWlEEE*zUz UmUmUmiq}}}nnnk-4?4?4uxt< +V4SA*((%%%ᰊUɽÜ>wsp#Co W\q}V^z w*LU*S{zGX?~`}8p&Ld,W[\ M 6.m7*oTbbbƱj#v=?n8pR٥24Zi&M}>e2_#G$\\\S t!WՀlllʆ-5 j@0k|.FhYYYpkȭ!__@bnbnb.N 8 Z}V&M.\}RP#FvlսVZAVOVO B|\\pq~Z&Lj74hlp/'pI^'n޲e [oi]Ӻ¨ V[i,TTRJoyyy X=zbxr xxهg000cccٞg{<<<_"~|PB ]w)߁|” S.L/b(.]dDY"dTɨQ@q[q[q?Yg***ړkOAxnp/^PY&LfAL˘1-OG>b/뫯{Y'?*tСB~Ƈ337~]okw 1~G;+wV,}O}u_]b켱QGB/DDž3|BkkkW/^^=!t:Cv0m6LܪUs 7 o@!tStStSJoNԬYQ6m z'ӭЭЭXcB̹sSܑ#sG Z}Mȹs)5k"73737SEE Q4hX0!WWWȏ͏͏HV$+ Rg(UpZ/K!r=c1!['D)Sۓ'o;Jw({]λwYm6[_nnBשש QܰaqC!JKKuuu+&"wTQBϯ__]{]{]{!41M9wsBPPP !5#_n\s}1AߌBay 1c܌q3 qjũV~5TMy1y1y1B 3D!D;Nf E )DӅȳʳʳĸĸX >>>'D™3Wo}!ԱXuT~\e?_УGA!ԏՏՏȋʋʋBVg Q^^.D%555PU*T !9֚֚BvIɹs' QQQ!Da\a\aB +V0LՅ W PG#(W8pb. QA!(܏(V:t_^s2dntBgo&hU8pT2eL>iiiB 7ސ{B/|BrQBjتaBL2y!B\x㕎eș3)G 櫛 8pq@!oZi&!j|5Bٺg랭B,ZKHOW?]]qPjo1D -nvӢEO"c@ƀ'ybcc]ytѕ8WJv" 1lT7\ArB|!BLVt[MoK-Vb:$uH!UVeX!I$O[etjL1(].JyJ V鋧/.^{MU/ O|>G'!>SO ?%CI?P[-!r t7"00PЁC ˫W//!===ZoNAA_W兘VeZiUHLLzowqq\^{Bh=B;XEt]RQ*JENǝbЅA].?w]'y:k!- Z$Ĭ泚j.DV\V\VӕykEX^ejKZLLLC>}^(^_x_8FaQ@1 4_r;aO"""Hv#$^HxBN9n6ByP4?h~wc9F%F%F%0fXpvqvqv^Pv bX+;<<gs8;-Gie/[ & LoF3Ѱ/|_p-w}i;xxs?::::5tj(XUdUUNFFF```AAAv:}2,F6\6\6_{H:t" F  s.Ϲ<2Yyg坕SO?F7#@{^0J2J2Jiݦu 4~IcX0dC`%PGWGWGVVVPí[ 70gvt+Vح,?}7֛gaacy0r:t _]wnnnZpT8*ߧa)_j_7.M؛7`L1 AdH%JCeSSSa77߄&M"v C}t;eOϞ== gzv(8hKKK ZcVi[?P$J8p |^{QQQ촲@&MΛ lS6$$$CQ\Q\Q={5kO>]t)9pTSN (z*z*zB镦WNQNQNQHP$(,X\hy> 5kr={{ +3~gSmN`]ɺ;Y]"E^ ;bT1())AJ+UyUYkf-X|eW _-_-_z.rPhGȪU/ZZZ@dxdxd8D_}һwIR6sc)uԝ~ Be>/ܲs-M7yC"c^α4iVS87sCaeV׎];}}}$5hk\]]]]] k;v ]W-v[춀(++bbb(F(F(FwÝp"L*E000444M&EE]ugGyv%K>)Q)Q)Q1cbGH]2ue K;zwս{U(((SOA+S(% $$յ444AAA*OXcy4i|pϥ8s\2>J;ϔϔ@QllleyLf2΀fff7h4Y>2/f^̼I'=)S:CW!Q£GPpti0fpTUUAg՞U{|>{/{/{/PF)Qo ;#3jk+Xu+60m`@"1ְ)|Sp\ɹ3 \>p]]]R[h].Zəəə|mϷzzz h?~<<<4:} sss0lV٬2Ep} nnnXXXNcŭ[ÿfJ+FYd]:(\8ppYԒ %J&A>}_'O^@vvnݠZZZϥ1՘jL!sm̵/CiI'eiҖAfsI`7߀I&'ĸĸ 7n0NNN`jj FFF`0`HPE"THS)Ҡmqe@[[[@!a܇PdXdXdE_}Q)S8 s s sA)˔e:uf~Hlllx 8p<l>} fͮ]{Tz+,,,aFgt?,dVɬY5kPW8,:|)S$$$b2L-TɩSrLrLrL EދPжmA[].w;ẘ̊@gCww7Ⱦ}-T U(R 1:`ln0ad 7lo޴ &-MZ6M* 9E?X#d,Xr 9n9n9n^^^ WWWy#F捄«W !Db>t*J`ggM.]r4ieØG[ -[> }7߇ m5jŏ?>vI"2gNϜm;;;cVXZB*qԦ6&4 eD6]hyΌ?3xX hA(#}zk3TlP:?t~ هew*_~O,골Ϣ888 4^xAw)8 }K~P+xWǍ;~$@u׺I'aI̒%1h Œ~3N9wZoRJ}6(}/^O?a?j9Ns;>>>N+H$o;S5pkV93$}iҧN%+[`/li喖+{Wl!LBLBLBV"H޼wpϽx^yo ުTDDDOX0a><{d歘b hԹ3Uru`&H$\nvڟiVZk!Iғ''yFoԆw`OJA*;D"R~T>SC?1c c*twMɠA%h磝vc㎍;6mkݶ6(JR}H${B)eJů>}r]}+2K2K2K`eʜ9p_tFӍC;T>%߽w^_W ǖ[vlL,?bX)%oT2a݅u]rjB+pPӡJ$ɻ락I$s.]»ÝwY N'y[tuuY.E,=Cqww~D"%wwwhѸEaoP\\t75d[cf ?r0[xV"H>GCzpWÅ^X mYfI^de2Y o&:::¼k +FWwJD"x222zyI8pŮ^w:ɫ O O Os#FB9ra/H$߮xCCzQ؟?w.mlw:U\\ ?DC4޾z9sdH1cX\kVi%- 5X -[.p;ʁV[,1SL3h }(:Rt}hpz齧 A)RM3f6TX*,V"Q-ZF5???˷/߾|.6bS0[hl!XD[D[D8ywK'U'U'UptGbvˡӽ2f8 ߸}vI&NH >>>N)Hބifx!J\*PP^A="狜/%%%tuuajԐ!ЧJ*},9ޛGՏ~l#xQ޾zjLLLwOѫa^yu (}K$ec c c }7R|H{ wZDukխUT[?_WnRnRn#GyyySK~}9tաW^↊*B={ݗKK.-[no>BM7-d>wZDOnܪU3h+;?{; ɐe2d0_4,iX/lll}|tttg>;<>}bD1cAPE;D"yN~v?Agg'lqy0,lXذ0}ۭ [a+`χO?Y9r>g7T)SvO=}t|5j00vȩS#' "V"g*\^p9djDFZ~GGGP:? R?H 8Ċ!00 2}4hys0J5J5JF2L'{cF4Qⶊ*´jO ZWk]ӽ9R+Vo 1a#ƏJc*$ͤ(a6m.`Xi@4D3}_>###!q;wRokү%䓯пQԅ>%}J}}} _7u`5j }|uRoUWu_U ̈́/ >r#}{ H ~p:u>|k0#e V")S |0ᄇBi?AӹAT{*UN@HHСF-##)Rō7ZVXy`j~S#}TQGAɔ)'arr ,.Y\w?ODBpn`諒^.]rBΡCAUAUAUAi%EGGLƘ1_aS}Kup_}TD*"V=Z3 RMTMTMѡCG7Z. j(\^h^h^(l:䦓p!?hbce-H$ŦŦ0I?Nyؾ}APP?N__t}& On? ;<3OZ?d2rJ$D?]hv!LNNBa||pΐ:+uV,g:t)DUU˄؎c;.\W^{.U]Ts [onݪD"7qUUUp^}^}^ ;vY f3K,9+qDG^g9Y'bO 4,<xp$HȑXs;ý:܃qu,Bw$$Dn:IUVWY]e5߯0b#@UUGE}QT e;?jܪqA4D $/HuÃr=(&GM:]t$D ?)VjZOOO ɺd]tttʶ1P̡C10V[f9wsfX~! ڠCB‹/澘 [3fn̈́ *L0A߭$H$wҔӔӔ.[]|s(_zn/EO?W#6Mbᇇ~yyy F>`$ܯxn%D"]H<<<o,`ʂ)Pv۵nNe?]7nt]q"G\Wٯ>CJm7HZ8i[K"˴6 l-Z^x~ m$G:BccSq8+Bϱ? [&oM5kb;ݻC*(?&M[eZ6 [Pn[C"WWWCFqFqF1}>jeɲdY pdddڲkˮ-ATEFg(ˢ/M[`f&~]D'3(3(3e>5550a\0b 93g8XXX@>}1lٴ3e߼@d#d#d#@UU%\`"'=iBM7YdAmm-|sCj5j(dee~K/=S=ӡwr9oFGBgg'hiib49́)LaƻC*2]]]=? k;-[2d}+W`/x^y "UH̻w{=z S$L_)m/:"8ԳSϠpzPſ0w7w7wǺz ’’’TS-N#n9^}E_0CQG҃K.A͌7!7?7?7< xGGG\>|r7o u:8xࡃ |I%.R ccƌ[R2dHHII^zm ~O~Z*8zaWӯ_M0b2dvJ L.6] KO?-D(0ws*U.ҵJ*]9sW+ uuu"^ x\|]|]|!ezPSSGJƪƪ*0.5.5.ғ'KOB`=_3Ϝ.p*lff}3ՙLaꆩnHHHЭҭҭddd}_="1'1'1G `BI:P!vZ!Z"K6l ʽ+ܫ4dddo!>Q 1mcF}z}GoIL^1JiREVo[-ɨQ'wqGІiôaN/H$T%?p0TJR)A@[=oѷoG߆An;D"H7R/Z_G?PߡC{c.\Aօ aP,VK=6$DH7of_PKե}ھiBATATA9rBg#H$ 9n31c6k8pbzн{A8pנm`aa-e-H$HEލy<<Zĉ8'ںj몭146464/3dgNx|ﳔH$ߕT!"Ev *O|}}惚j> O'>[D"H}ސ 3fi[oidzm赡;s̹3!"$"$"jS>iDfHObbbbb"^{{IդjRM E||<~3W}NPjQ"042424K$7SENp[0w$e0&=1=@d]*wM>A>Pkw^xAݥ ܌܌PAF¬f4'h¥ n'K3ϼ]ӺuM]ZwiE߭ H$'D˩SL1wCIUlݕW^.kO@BTh-Z ''@cX^k3/g^<ȼy1"xUU.vX˭r޶{mdP?~fLj=zG"{d2Ȑkwokkj]uXb ߻/(SR',&8&8&/|`bbAAA@DUК$f>p+gTרQ]E/}3Vg΀&FM[[[[E"H$k3gFM|7 T+-8u0`fh֑H$ɻF*^ ^|J4ҨJb\*3EUwz[G"e$f$<{ v$ $).).) չũԩԩT477V{[mEQEQEQn%Dt?~ a"hR5QnFy=z㎎;:LLLKoD"}s `}gHzC£V>Z >}.\w(mۺ7tB px}AМ9@DV9t P[U[ ;";LxE2eԃl޸zD͌733S3S3S8|"TyK$?TDDD0c0`8:;:;:;Uî] B~/_I'N;D"HE*^QL1;\ef̖;}'e*p˃%z^N'HoR%@޴ia3I/**v?~TYf՚ %%{ yyyǥ D! raȅN'Ho7"o|7;;$ `i҂z8pa9sSo444`k N'HO,;;D*OsX%VUP1bxp}^Ȱΰΰw{C !q%\}H^>z,@,;b̍ jlllꏳ.]$?xjZ[,/',kY2$듬O<{555 /XBCC!g-˖e@GGRM R/^%DQ" c@@@ߙ$R;<<<<<<@'N5Mo4LMM!$$Dߩހ4Hþj ||' t=J{mRk˯-sv{Zi >:с\s?rH?;~v UVXeSuiߧ}B %0%,/۽\{8`+sR={0^zM5 on˷|QSFMC:t pg@n_|Hwx|;w !!!={ /b*K .9p?O?8$Hֱu@>#-^WDΒeT999pW}jM5tꪫ?7LΘ19H%7.jKԖ-<8xp` PDZcGhɳ&Řc^OO<= 88!V[zֳsssjXհa:vujHߒ%}  8 ۾o>9sGGG64d@1mc4x2ɬ'a!4i@S___!!!9!L3pj멭b֋!++ 2FeD@JJ dRY)m|ưҪK.Ao[~[`Aqb=*AUm0iXӰ&7o֮[nmsssyU- d}K%_Oğ? ФK.friRI?;fw)  쭄o|sݺqƭ`f̂^{])S@XX64zhH+L+L+~s7o ʅʅʅ=w{v;v.T_W}]uPηo9_011K/]tlNٜ9wݭvx\Vl[mEwͿk y;,vX <{y뷯]]]~Ӟ K%T?RH#s9蠱wc3gL000+t`]0`- cPB `2d4h@MM EtGvOAή]9V[]nuߎ};;ZZZ7F}8ߝ+W.^ %I"gϸ'UTqU|}z}*L0dh̽;ٛ7,Yhxmo蕣W^@G(iVҬ}0!{Bl`q4٨f \sa8VqX9s '>1ȵr\ ΠܠܠM>+WA:ui姕VF+VQQQ.w6l8@ ύ>76J M2d6l3 O>>> fb6hJ4%S7S7S7<@__rBrBrB{Q/ ԋzQ/!hNhNh~~~~7| }>GzkFW+FQ 3f>F0PMYMYM 6|`4^xm\{K"]p8RNJ>:01L 3(H R+EEE q6ܩ|-η8<(w(w(wGxj<5z[׽aYtE?<ưƦjn OT>vYBKK nݐ*l6H8.qhkkÙg枙 px :?t2dIh"EXoM;5F@lw9\\\NNN"E^ Uի*]~wPPFA p !gzУe=Z•W^ bOŞQQQmHِ!N49DHV-Xi5}}} kjԬ@': r4i3kgqX\lP")Dɯ?|Q5=kz(;_On?wnsddd  n7}EѨ5jZQQ4d1D Ec;c;c;Q4n7n7n7ωd2LhҘ4&(`QWբh:n:n:.Xq8V O(%d Y{x὇)S CT| 111P>|hPhڴiӦM}mڷFmh=B;QQQ +nܓܓAׇl`0ȱc#!lpኇ+{oH$Z|țɛ;D*~O{? VZ*Lb7wJh]кu(itXx,<aGSsE%E%E%pѭ#xM&p2e* G/`!XOi~Aє)GpqVk:?$.ddd{tetp-Z kMMso*R z=cbXJ(УG0aЀ@yS*ZU^ ^ ^ Pkz鵦CpApAps7H$L cBƄ w%sqt>tv۰枛{nB@Y4w_fz Jɕ+L+V0t{6;mvS)grB,G#m6IF@SUSUSTͩS   i2ep=sDRHEË ~s߭ۚo3fo~sseﺽ8pحcAӈM#ܼrxxxТB --mh @ARARAN;`J0%UVrC -7囗o^ ܞs{+q$><p48KeLi5'꣨>?PbjTwYxg(?_$NIbTq¥ (3G%ߨhLi:댯C`oooT!C܇5kCA ^/;D"st[m)3IŀuO=YxmN@Q$ iPҠA`ddnsֱuNռM6ixZC^y@2$+r][0"jD]I[EEEs^jz) lijN'H^ 6\4`3͝I"?xO 5k!TB͝쨽롆vUgW0Ltq8l;^^^oߩ<| pJ##=p/@gp˔KKKK>hA̝ #8x[mH<#u{m-)S<ZZZg0a/H^(nV `ҲI"s"s(B Bw "ޞ4C_̏7#nF sH$/WK]K [ݳж^z֓';sSؒ%c عععoؿaTe;w=iVo V9)GrwwwA0jaB /_i4@5,M&Kd1KpX8 O>G#555Y,_r' ^ /m6r+Jf`![""",>n 7 TK^^^^q/...)S~;>'.^.^.^gN5(J%PLTLTLr>J$0 0 }/@Tj?sߜ\W^uE{J?r(@ +xVSvX&,Et}?K͗LT&4yyw*JRʠ2 m.s2Yb$$$AWWdn,1KTM&UeeePiS(SRjB  (].JyyyPWWr-+ 111Fڍ qqq`QۢEmP+36t:[-8r:t dMdMdM@^S^S^Odzы^`d&(G9+`F-LN&'0\1\1\c#c#c#055C! %K'O @XY,VBG!y|P\\\uuu%J`/ RT͡C79s"x[n#u6Y/^T"}J:O?Y΃w\Pz/޲вaʯ-@ۗG]vPC%7oBohe K\^`v~&6ﳜ} ?`o Gҗ>U} (B˅lzse\\ݹ3?ݻ-lJWEr .hcL!]'r#yl|EY78{,责ӎN0΃m $ 6m5W\YOݞ=u///8t+,Y>p0^cT~~~ ,OY={z}7$LX^B/8^xtW]Mw}AYEYEYܝzeޞzCTObleOi(yqe8;; N,8掝;vXPZ(-&IS$N333rUV[A$A-ZVeS˦տWb3f BosEMMM(Q2d4wiRpiXTlQK_144ŏ~!6*6*6 aP;wpoPWWP*]r{M"y9YCYCYC?n8ԧ>sϭ?*UΫ QUDUSN !C:t:O< *eWʮ t;ݻRu|t|ƥNNCsssgOev`eŠG~k?J+Κ;kƒ>> `'xfff[nɻmmm NL^]^]^݃݃a쌱3΀ə3'gBbdbdb$L1}pG#[Mɽ{`¥ {+?.999uuu.qqq! n7/ˠd:hI$ 0K;333`p08xģWWuL]&pƱn`k}7}7}7S1zO'heZV qJW]]PvUv^O2888FgXͰa%8EqK-N;)龜999( sԹ玞;*7DQvW;ӎӎӎŽ[^sNQ̜9!sӕˊˊ 7@W8pZ$sι:(^W~GXu:Vt|(n҆K.~q_ť喖[ZNN(:!4448hx"QW333w]Q4 v~9sGDqC+=S_~uUQm4(q8ҀK.blNlNlΫԟ?EQTR}27` 5BAZZU;}7\zժ0}ӧBˢE-@Uץܩrxk[c,gY΂3f ಺b)f•W^ v?lS2/- 5j&݀W_EgJn*xW}QT_R}I%ʆ+ ̶߰?tڽj0:pt@%%% ß];z@v9r)E N>ե 䃐 Wh^lll gxM&^w ޅ;;;:K~֎":4thP͓͓{{k]oC.]¡rʝ*wNC; 4oz'NP_U_U_}K׎,귨! /=Ve&@SgSgSgЖӖӖ6m~lj yrp߉~'#?C?=)4۰núPYevvv1XZZBIV[}n:gu8=sz 8Uqȧ1˧.| K{-X `5k;v +V˟_^+Vz-(P.\ӢN:```TTT*< 4n۸m㶐q%Jֻ[_>xh=3\ ̄r˵..ֿXb}2 j=3z}aަym_h~wWv_}? Յjj.ԨRJ*pω>'fff{{{Az`z`z TQ)TTT ""h (׸\r~} @BYXqqq\j}҆ K-;[vr(rOAqѸł '3'3'7o>|\v}iׯQ40h`@~hG)))P(P(dp28.?S4{A!&&zpjکo/0q|:8 4O4O4O_5_!arɐ>IO @Mo mLژ1BBBX1gŜs@#GPdQdQduWЌՌՌNmt9U.s~~~CPi[ӶohըqvWҔJS*M64nEMI&'MӇO>}ΩΩΩ {bPlB}U.3]f̄6O3}f>O}§?x)bSX[[C빭綞 ^zi+\m~PˣG-vGghSЦM,lԲQ0ɼ&ZgY̋ .ˡdu2etK櫛!PB 3gπ\'ߏ(d@;;Pǩq`YͲϖUU(B! nA_S_S_k;<ȱϱϱoRI&BޭzKž{VY B>zM5G.BqNŝ};vWFI `IXOm_aP>qffZʹ tS)tn?SzQ&L嵟SN8%<곫)|Spذkî ޸{I~\{8W B zzz1mcF8r x=z^m{+WgvO[;^w^EO+3ٙLFotӯ.g:Ԯ c1GO{'N2@VRVRV]w }A&V75\YLg'8ɛ ꥛W:P@PqDG@O>hG󡕱KHHdӆL2mtVuVuVW'_ \2棛uAĕ+W xQE׏_`[#D$E$E$:O+]WS_S_S:NJ*@jՒO>41-ƴ*+++++Jb%gCct<1yV?~c ׅ T Lڙ3uN/_={:SkSkSkS3f\QsEBNu;}w %|>>>p} ׃zzz 0ѼҫWI)))Pgfufv_=z7 fͬWSE-j8ZTj1c ].])))@9Xl,6qC}hLc.OpB757575/} 'ZhAl$6n`#bGgsXXX!d<0?|~p>K_12w?=㽟=C I[oTH^!z 1 p?ay(?jڷ_qK:t(uuu`vm^8ܖs[`6m>{﹂"G9mv;v YlgA7+YMbŮM7$WL\LMM!{\|%Jx0sAqFqFq+GW 6` {߃O_?}TSO5ol`yw!>C|89JJJV盞o w Cy>^·7׆ ]BfKo`nvwq:ꘫcwIob&k&MSL{.f3`X?h ..|||}mggg sVk AAAP0`fLpLpLp/K?T?T?/G_ ,Y􃘃1cBV}Zi;쨳j᪆3*gT(6,mXx1^_8_|5!ncƸkkk~~?JSTvQȣ#<ʫ* N SxuW{\ҡߪMI6妖ZBa heʠR[.E,,-u^]!Cf̆;ԾS6^xaHv! =t:pujN N Nm=_GSSSN; \s ϕs!hѸ8qL8O} 9sTTTPVV̆; 5 5 5 sr`S)2f^ͼ &k,4CE000&LO?t:(++CT.Q]uTש`1b't)6xb X^nygFhQEookH K څk];wÒ%aK@aPXRK5xkVc;=y >2|Dq8,,,@O'p_/EXQ %KƗIɶɶ`TY$$$tq8]X7nbݤEփUVW ީީY:Vd+AV]V]VG] :tADgG%z^PTSNAGV C h_ѾbF?1nкAk|wJZe `/ڋ"q8VVVŃrrrX}`Px_>ЍӍӍv,ځuEA=F=F=tf| )x=Y)kxxxGYӲeMM7&nAHnHnH.X]fu tV:+888fff."@ Մj6}mt000x ~n?c3 MlN<,YDV;w/լGΓ'9O^5(kP X5tUCAt:$OaZ߆aaa'BT!033-*DIWūAMզ 7tttrk9;;;AwYVfR\)EYgdi4(YT&XYYx].^CSCSCS].`t6:E `śoXhe fͰ>_O >#G‹W@jZbYŲ y<>},VaM?M?M?PTTQwmm,u\pfљEgO~{==ٽn `徕V ^:Ay@<_|||@MѦәϟ9sv[oy_y_K^d{M@WW\e.addd_OJJ RWH]EQEQEQ  ~r_DN;{=kݠkkk]uy<{F5k,nnn1ML~P %pA \N+V8oLo;PJ+ޟp^y>LW3)MJ@x7Qe8r#F 0kDx"9U_R}{w ~rPCu:@w}[En < OͽW^?]t}~i5j:6$ٙV[n033˩S-BG5|.]@LŘ1!?q.CO=vۭ,{0Rڿ gTFF*sg:--!\\G}\/x_`u?>LO2=_xH\ .@[aw5v׀ чCжQFmAP&AMEc0QDw}SMI.,Yس0h8q8tʷ.ߺ|kJb'W92a)(22ZVr͝T+v^yi%Hl6-|͟lmxxx5zY#8ԖS[ԻSNq\A M/4^;x{{ǃlllDzzzAvypuLLLo4~z?~}iU?z_ NEܭ^L$-ϠňN=8`h\[C̬Y3a|2Cn~$듬OFp=zpppٞ=gC.57TsV[n`gmgmgm*)s6PhiRHNN͆w-ZBّ!^Nz M*4ФUW]/9ܝyeM̚^^pQ;[YTp?o|PuQE**ە`oM&JZ:5z|l6CF.] Vĭ[p_+WH~j)l5 jAՃo,,߱|J*vvv %<%<%|'_ÓOj< `ddnnnP{DG@]vuuPס {8WXc(QU>򩹳EG3f\x»'$s7K+VVVO,>ר%]=zvuHHHW_b'N9r\$$$(ߤ|M ી+N8o({6l7@S!bŌQ7nF]HpKpKpx>k52e |PsW]5ww~΂,c?xx .s4۴my1<Xwb>^L9s8r`o{Š+Wl;2W,t?C\:oPQG9A_ [+Vl-x^yudTɨQhhhT:Quk~'k]׺`sl;vri ++ aw?XD>H\-WA=G=G=TTTy瑐x6lYHMMo?ې}y߃8O'={ggg,P{mԩRJ %Xs :~6芣+F,_#S <pF'9ll2W̭2*(hQ"٥geBQj%>T}R4JiIIIѐ >Y}Mݛ7Af-Y.*bھ}kpssO\?q>wspwwIN&]w.X]2L+ӂO'+H)eJ Å  ABЉNk4KXŇ`c0Ly`J5Ro7Ń>V}5kσz Aނ{ rss!D։PҹsIg0: gi'xxxoC߆ s6mXeYeYeQ:Eo䃒$.=\zl*/s1/;xx@^ümn#I/0@"Ly\lr @fN,:Xܰ񲗥%%xn !JZ*3SfffzzzqjRt.4E6`Ā+!Dl(lPؠ)>S|f*Y1Y1Y1Z/^j=7PTT/w/w/whPAmRϔ)?.]`V eKF4L0$yݼXQWmoL4&Oog/uѺ@= yymԲ4$%<| P'N&˶Q x~|79@<9@΅ } PKP攙CKCKCK?mNv8$?nwX}**3Lh1z@S6Mm̝N, uXw.Zh"PUU-]H%v%d Y?k?%V]#]w*}%1YLAx,<||| 0L5w:+ÉGkPPP///(˔Ӂt0wx*xrd?oo4w&*111`aa2&7I$CNcܙ$eO'œ , @DDܩ$q2ƁW]^u͝F"H^e#iii-;ϢѹѹPu[;D">L`hhb@6G6G6ܩ$XR{IH$f*i"M$)3T|*>ELddd̝Jg=:{4mlF،H$黤;? t$M=nve)000y]y]y]B ͝Neμy GXhZֲ$ x@T(`sg+L Ƌb<C!Iuc%Lh~-2w*RQAٹ0[- B+ qhc4_L~y7򖦺H$Pv t1]L/] (J^3ِ5k~W1cSI$L 2 ,̝Fg)PdU*k('/'/'7w*ttȽ{Lb8XcCI^/V5S8(˽{/sHʺooX 1w&I)(1JE_E_E_ d%oSM:;uv 6Jܩ$γg3W^3w&I)x3Ⱦ}%ܡ:CWH_k˨Q+; up-de͝IRv Qtح:WD_B %sjq9rxXܶmqLߚ5} 5kڠ6e2D/0右ررTsTsTs---D"yſwMwv ; 4w?/;/;/; [.l|}}kLгjϪ=BȫWaO=P9r|xHMM: $ ^ox"xE H؝;a7\|ɌOf|2o>he/| ,*YTsÈ3#Ό8gF1-bZEO=Y.^.^.^ _,_,_ 9-rZ䴀Q=zB!CSGOk+6M4eD!].a^Mz;~=PWWԇ?D-O/?SSSax9Uׯ~r,Y!Y!Y!YP{ok=dcf9p@PkX[LlFGH%TstIYzF<mn8Y]eKe-…E]X/_j> 4 Bddd8uԍS>|RƥKO'!sb̉0CEE,bq=z)?i5j$4i0_`N'?y TRJ+hhh͊5+&&&AH^!k*gU΂g͞5{ N}pSh#ڈ6@ $8H$HHH(r!ehЖPa~g ?[Btyp0(zPhx|'߆/xg;kY ux*txj<5 o(o(o??,[l(*Hz@t͝IRv B0F#ˣG/Xr+aᑇG}Ck)>)>)>ХSN]:6{ozjzjz 6m4rz#`&~=]$l6Yr~/K`]ٺue,,,kq8M+G9q׸e.s)!0€nG<$$^LxnlF(,,!L@S 4 m۷mǛ7oS7nN~Ǜ DDDq'5,Pybr\L \ WA*l{!0(0(06 4d~+,^,76]wPW+7avK~ w%+YIj=IO& `dd m6Oٟ?2d@ozѡCa0'ja5Ѓ`Y2DbL2a0C;j8 v ={&L-xKsC цlnFl~Iwoyf9$/o ?X’?М(3O>}* Bޢ 컳\qq )) UrT)))Zܵk1\Hr!Ɵ? A>}2$d>} c c cR3R3R3 C Y1bfE1ctG88܃s /zwݭw>r#{7.(Q|mmm~CS}J&.`xM7!N؝;8qHkxsycl...ީީ UV][u- >*;;;jcQ_rԗ`3f >};L3 `@߁q-Z5(*)*)*3Vg΀Vk}&\ dž n鞦{CI ?*?*?fffs9j3Gz_"H'A ?)cꎩ;`pP3fth*WR|=߆zh36Sͽ^)}Sg?h#hW<(H 9696 ;[Uf.kZ0|M`R`#66*XU`i 5JJJs{e 5l9vvvkqMv޵l0Ss@^,/餹SA̠A3a]v!Eӽ}w`=ztsH$JdH. 47w&k6|S)LHS$^fZh-ZӚK?IIISP\W\W\7w*D(G?sg`0^ 0T{xUl`^!ܯrbbbsH$2SȲdY,EɢdQ`z}skSM6ԽԽԽ``_m:(Srly͖՟.K *={b\#OG+Wү@ `jj > } gcƜ[;F23efLp~-...ܩ$Yk. ALd3IN/Ńh)Z٦٦f<2 |}}w yyyA}@Ǯv Jb%;4,xaӇM\p[na{y 2@h,Y(wީzPpC/mSڦM~ : N]Dg>t}-Nr'sga0U N7K. K5ykVؕ+}W:8t0no&3g?#q8G=7zn &ܚp vow?84h>,g?F_4 &Ibڱ{n7mmmu]Rw l~p%8N{: R+B: ??|EITF*_Ev-[t3D"fefG?֫}}}Ԥ&5%gKΖԤԤTHSu|ց??&&&T"kkk_5_5wvX6FM4X pA 8p>|7/H)9@BVM7 +'+gleW+6pgPŪbU0^{;:~,X8\8z腣0ydeexpu%MMZLjhh`leWٻcc Nz H(J(J(o[!%;j}@#1w&Iٻ 3f5͝JkmNۜW{>7o!! @pͮvVvVv ӆi@D?s/ŷo߂̭[3B@7D"\`}A0  k̝Jd,XǍǍǡ¢ *MD"(sW_Y~]K];IKKC퇂]vcDƒϫ<1J-/^fW ```W}͝J5kx7nV:+ܩ$ɯsAn `8f8fL2WX`=FXWFM-M-M-/+~T^QyE+H~V' @vPvܙ$e1@Vw]wSSSs¦M!p1-bZĴFnTAYY% %KDΊZZ + gΟ9 :>>*W ׭oGS:EOUUU!y]S|OUϫWϑ#=Gnݶ4? "wX~gE/>'>'`eU ~-Z^PH!P;v 7|ok9 iا-x>Z `g].w xxf}+s-B er+++;՟Os\(Z\*dȨQNF: !!!.]j;ЯүүUUUp2eAՆV N69m'''pNvNvN```mU۪6].Bv @?HE*U*txH<yyy`gogog&&& n7AWOWOW7(nyyyPмyAs7 o<{< b6[Ztj,Yroߔ O֬ZjMq333 :u BOܟD{EӆN}?/x;Z''^:@|(>0T0ThTŌ~JC* 9?@HC1Q1g%OC-ËŅIor3 ١flڔ¿̍hJ^`1bD>vPWPPPj=D" x͓o|C!<[ڢj-JA*ޟrrrX9X9X9pG#1w';q8OrrrPbWbWbb*Bؘ1c!Ft2[ l R6Hp ` X`^Jʞ9| \ {yEyErTTaWPB%|m(^>zew} O>?$3>ܩ~;S?S?S?\p-_P)~P}EW@á 6 ~|  cM7@щ!"'"'"ތz3M^^^ު{ 5jUTYPeȯɯɯ7gNޏ|?BAsg{ߊ `n N~@9Y9}lpo1ƈ#`ffvYMYMYMseццգVZ};?v>TVuXaвz-C5\6m۴dޭ{F?~ _a<c=u zK!C,t % ͝V_ŧOkڿ#`nOFg Mew{Waì 6̂yO=͸*Ua]u(vQ"viإaXO'Rh)4^OKX`nn< = = NpMp&G!M//xr @i< &f^ Ek `c1ؘ/Oa/7œsΩ [oQtL L L @;A;A;ċEoW8Az>{;Ȫʪʪ l!!!{K˿@Msg0aE"H+ț˛2@ Ge CCC999ڃm;v`⬉&'Oܟv###!:(:(:պW^-0|Magg'Dj 455!MOõ6_ NݢEw!NT:}}~X1쪼ʰ- < .]TrVͭ ߽w!}W]>K}.aٱgǞ/K Zjkkk[W@܌UgUgUgDh"42eBW2mHڐ!S['l~n=__B:66Z>|jʸ'41>c|xXw5{aןa2j=Z֨5BģG+%WJD_{Eq3nMϦJB U^A ""EH* !"Uz/$@lʶzQ{9x69sf~wgRbbb+`}|@C!9ֲpwX2xe0 I$](tL?&?4~$}> t_|۝;o7 \ ^_!Zĵkg poȽX:X:X:<ܟ5k}]}]}]011b!;1o<ã:< |pp" I`^o>{qt6jZ Ʒoccc0l4l4l^U^VVV077kZ`z(-Ƿr< ,;ۡCo _˼˼ EX=oκκZi5՘g%x$GQrc}c}c}077JҫTh*4>x?#0o,ԪZj0`Lp6m '''DG744|JlDUJ(isOLO|QS<͞P WNr'':Nt9sL~333"Dވy)xY5jfՄ÷:j(۶l۲mZrj0~l{}D{/{0j¨ &}SM_r6riPij)eJP8pBصo׾] _ R5AsSsSsVFZ 'ʝ(wm޷yP:/h]к5\]]ARIaO=Qge^Zj!ُ4@ k5vlرa$WJ\ \c.2LF4?8l#&GL8TS |NIbee:~8\n~ۯCM!ghМEkϿ9|h0Á8:|3|e InS4JiKG,tD6l###ƿnƿH#TaCÆ3"!*"*"*Le*CjԾ}ah{?Xcjbbb%|`-[ae3̈́OZةSc DA:#΀fff/`lglglF7 cccɑ1lS)22vQ@~J~J~ T%U +WMsMsM"ELv+V>79_:l߼}͐SO?AvAvAvhWiWiWAĕ+W ̷2߂Co}S3'hhh<nMݚB1lj"AM{4_.r!;;fo7obJ\/Jz*<펿=.{њGkxu ^]TSti4ȨQ#GGGڛ޼&l 1 u^JW`_]*y}#s9>\7\7\7 ۤpi8T]1wh`yy8 p': IcƂ,[-ˆ! CBOOfffmiK[XS)x 4h$֬ZjMrrrc 9s@ās͡K?~.ps͵7…  C6ˏ.?((( zb0baB~7n8k56HGd* k뿶 ԼSNM9e䔑SxxxYwgݝqUoW@yTj\2]2]27 ; v\/SIARBY{ ɐY,[-HI$tU ѲѲ {SM~ru @Z!V4E"MY,CYtdkdkdk.#k(k(kR d!YHdpK/ K.."4NC:Q(kȇɇɇ4L& yyy3 Hi4$w]r0JIRi݃O>M9VX9AAAJz.n~--- -, ˻lEY07575,M]^tG K%<|곪ςyCVYA~F~F~Ji%NNN^j/% I@ u:<#FB .&U*I@~@~@~a]]] 5HM@j.5?wwwqv888 &NM s?aN9?"""555xM&m{ޯ" R%en|pLLL.{]@vvvvv6dϞ=C8SL]yyDGABBqi3)S84@81vҥKK~@y@ 1aFTE"UyTN*'_ HCeX-V PP*=MiʣQ???(ۣlKKKdMlZj 8#KQ~8r.+]VBXnaݠUvV0#jFԌ(p6:*U sz=`X ӏяXrh!Ēħr vaÿ_,Y8xE<8h43>3NnŊNunƿ{Pjx~܎,v ]&,e) Ԧ6پ1i 7i@Pղ}.(9s#KRK,(=׺dо}CUëDEE #rFx*kXMV၇$SӦ Ю^z>}M}E*ÃaQvC떯 Fo̽3\h4`|-(VThkhkhkh 5BЎӎӎ@@@(ɋ`_ξ}9H04w;q`nnW?+++lb'''nj78rOOݼyZN WG_; 77wiz'kcƮͳo㢍6.v b,1 |U*_[¬Κ e>33D%*ٺJAK^#Fztn'նmIc>cw+&&&Y1L:~8ù΁6tq@7]ә`TU.Ixvu(*S2J}pwwiiiЩt*4iTkPA qK-0gᜅsB|kQ 'r-*/]t 9[- o֣&U}Tg},7Lnn{3e$7Hn:x/8"D<8p:tevpN=zںzœ?'OwPcŎ4JSoOh6X["7>U>ǛCCCgꝭwYsssCAP{@:ԪSkN?o?o?opss~G~u ||營~~8q^7nz]=;[o}P{5;#߯~Kv[4: b秿 mT(D9B ==Z^^uR?f}6Y@ׁo/s8K% 3/̄?RK:.K)R.*Vr ោ WJ_/^"{P8 =/SZb-X0~j)d4h$NI7\xs!$z(\t2,Yj{ծV.]deeb^:| `ӂM  __lk k T}G~y@,K>3{c\ f<{"⻽n/h&j&j&¨3Ό:c몞```Z>k=O2rH!ϝ;y}O+V o)o)oO;!ϊ;3xM{`?/ػ7@A5a `:h: X1 ]Lm8?/JPB )hS@}=@%.1Km[m[%k|M&_uAY,P&M..&Rs5CS!ha 1cUUU"GMrr1Z^NJ6@iV ,  hG{\p+9Pxw‚ QQw '~!$?@H~] >C_L_r^ V(X...W벢&If/8NƝ; ~Y(T/o!ǐcckckck0 E/_n? օ [Cq~@@@Jn*`G !!ve%e%e%puu={;x,,, E"a'<\>8=m}0y\ #m7 `J0%߳7ٛ8 sPݢEx;{; /la ˼;q {_}7,悚͞o|?*~Tn=VX rA$ n?}#F EAR?Zɵk===o몞SSSjv˷[o?D>} ϊpoڽ5C 1'ϓ~=4'sϹ>כ^U ϊPlSlSlG***r]`Yg͇=#zF@fjԦ6m]  UUUprrM&Mf몞GnqfH :tЩKk. ,fٺJAyNlv6;A'Oꟻ;`3>9f˛iI%,T*+ϻ GCynm&%%{n֚ZktJ:e*A[7|.]3g6zӛ޶+W><̰a75 jsJ+ٺJAD ?$NN^OE͇Y/zyq*zf虡gAL$ BpuuC5C5C50Ocgf3ϛ:΢ .RAo#o8`ee{{{LMMa{yx>|'Ou +o^sz LɦdS2...xغ8zzzV_C\J\J\ Ll7vgX[A"}nALWC>K_eCCC 6!6!6~ )`}!PTzA4ilp2e4<0<0<0@QDٰ}bbb}P^]^]^ OH={.췳~vu~2ce 20e` hZi%AE%x RRRVd+Ͽ+W /nһ 4 l0֣# Dx uk7akV~;Ae>,a!onܼOg#w=ӦM6m4o8:]te[ F>}A ((SPoσj=Px#7bA^W^W^֣! 1v9rPr/?gv0ƔSj@ţV< _-ث~Au!m4r\#2hnns_u /_rE9E9E941 TUU7an܆0Y?Y?Y|7n>}QhAA_ܺ~gž {&%Ka_}UK-K-K-(t-t-tJR+¦M!J@*jϪ=;N8 ӋM/7MSOm>9^VzF *ʢzAB<CRS:O oX `xt ,>;sKZ. ?98Û{97~A6=xE9Eo,}mNV'~á)pݺݺ:Xz~mWgWgWg[ZA(D|||Ntj8)x5dgg?HF2`䀑Fld'`ɵZrm{A7*0(8fcAvxn|[ aV?~<uuE/zAފy+ -- ,--mkA1zD M4d9s8%%%pl嶗^np \Ǹqo{`W{/2]`wֽAJqcxFgv?(++Q? (,,fGm= "_$5HMļļ^ͽ w]uq\uxδ9L(2L_Oѧ+)WRtӅ>q}zfyuuuUoVYRM K2d,(((Fj# I7ou{ 7h H*髤mz1矞z>\\\рXl,{Ye N Ä>5b QA0dQ(Y밮únBv`e&GmrԾ}S +]Vtvvv(Vʿ뗭_~zS&44oS---?:4l)R>la' ?YBzVXZZq}NP[[ a^y=Z2je%%%%Xcnnn1>1>1>зRJ}+_%J[;Aw7uuu (S~pu8Ww^4*hTQF})ĵk222`GwV Z5h:DuHE[o߭[*20d`@ N5j:APvPvP68f8f8fuuu6j3gi* ȂaCՌU3QPPJAáTz;ށ;wF_ ~-w߁A-ZACEEE[5AqDxRf̘=z*VᏥFR#XNZNZN>SτbmX Nݝ;uf!R^J`mkmkm!ֲֲ'|?y-Z@rTrTr,[<7xP!BA ''~~~PѡCEVJ+>X KOJ +ְ摟{H RCpDy} *R p6m>T*x`|`|`DDDP;NT1bREpo "!"!"e<(UJR|;v%%%+!CPFWFWFg% 9Ws|YgYZյkU[W' OF\xR,Xl]  3" B)$  B" B)$  B" B)$  B"ER{$d@PU #U@Zk=5QGxmfo vkحmZizl뱭6uoAᏉN9}$:$:$:Zk-tս*T \:y[y[y[hxنg b~C>Z>Z>:pp~}}員QFuյu ׈ ڻwm ߮~]^d)YAL||UUW犗/)^v"E7~A"cReThZך^2/#UqzC-bjAɈ'Ω;ХB ]hrɍ&CзA}k*AɈ~lyyyYvmhֺYfZĵkЬQF#Gϲϲ$w]rI-%5J(  3l 6H "&iIP[[  +WEF(%(YRd l}`9_eU /Wd_}}} (f+f+fjjj8[-P Vݭ[u\s 8}GP2֣+  ̰̰ ?}xA- X±cAAA $L2(S~?sPUTUTU <KKK48UqT;w(]]] /Kc1@VxVxV8 0XbCPtPtF Оўў͹s7~~~4kkkaaa2(**G:uipKzw0Hȳl[-AEa`kk puw=zvvvg~AЦMA s@ ѠQ(}@aQXPTT@@@S7Hp4i >fWͮ A ezudJí֥֥֥6mZX(c$K*T.H2-eHURU_4|)ToSM6md[pssuA[yfXXXnn613fߛ}oC u:X#TWUWUWAա~-@MjRTBQrQrQ2l{ͶpAvAvA^zi(XG[G[GC *Ԫ7>N8dI$Y;# #3^Cهm] ws4wd8qտWUUU8V2dD{_}aͻk].ҷҷCsu?*{ OO@[oLk3 8ugLLLu7^<湐 vvvPa]uC[W QD܊}+f9h =ڃ_r~ Ƀl] W=k /x8T*JD}Aԓgɜ9/~ב1ck[mE:u6ڸ o&? ³pdGCahszR_Q_Q_ 5j•cW]9:b?~PvRvRvfffp0a:۰oþ `mm wm{-<փZ<ٻf7oѫG ˔e2^;}}}tR:)`}SM%Kƥ e&C; {읳wKi鏓 l.EEEΑ;G ^3fw?w?0qlllϵk?2f\ k\q999Sc1W_~e8WWWjު Wf_}e6@[oA#FxخmNAXXaz9}uAβe9 f@̀|0`AKKK?ntF8ܺs֫^*>>s'N[n 5RRR Wz^pnj]KKK`EEEp-Z̵vnnn@ RK].uZRkЋ^3r\qPy՛1c) <; oƿ&BMP#Sl{{(++ȬȬHX*aUlpLwLwL'O!!!8QDU` w;XcuW_)} ,jQZEEEhFjFjFoGfGE|d 6}wcn}py v!}AHRgφVTXQ K.;2SeO=Uzzz6tsMH4?i>X?tXW_~Eߝ;7C9+Oa>}צ^ y***] v5Aw]`6e>e}BQbQbQ"VVVtN:'p‰UX7[7[739r*W lg;A#7M A?b)F1;bv<$X[Z[Z[>|jZմi@_vfg:렯xUUǴǴ x7S s'Ns=ҏ_ڤ0)L Y,U OA]OOOWr^y̳ͳͳή /x/܍Fw#L+V2 /Y_(Q @3f V G^_BG=K}K}KG%`H+Gߍnt01<"w0 h1B{uչhG` мG"ՖjKAZ/?|s=>N; _;|ճVZ=fjXXX_\/(**K+V. A^U y$}$$$1c Fh|4(iP [|||8886 lsgΆC2eA)t LLL044ބԥKSBO|R0X 555===ATT\\\ yJ)={d@ R_PBAH I I vCXrXrX21d~u4`iR2 ̃2<ֲ`Z`Z`ZI'aaaj_վ*K%KKKa.\=q={>|4.^xE e+*hZi@=P=P=֝A~::: rɭcǜn<ǥK0! <8qqq~:tiq3f\s΅:)SJ'(TdCs!bq7olڳÙ;h}y鿃Ny:Aκu9 M&OCO ?% ̼̼Lpvvvvvÿjׯ]v}(7rCgm 5H y ‹f:әΠWUz@É!iB҄ po꽩Bɂ'd{|YPWWWWW^սhs!Rgm,T* A\\?R#d'e'e'A:/΃eee X/[/[/!@Rb8i4N}*T)U*rj+ddd@NpNpN0_ӿ {:#tGs s sm"Aez v Ѕ.> g>>C+C+C+(** C*UViZAog o4w5w5wZѵk`hlhlh UUU ##BRH &II`aaڕڕڕk&]]]666...Ǖ+Wsss 1cw>h 4 9/s^`7nxgm}0AՋ!k'k'k'0L4L4LS9S9S9022i[ עE]u]_w_bŮAVAVAV߰ PtPtPtPVVDDD Xbm= BiUuתÒo|§>NA/jL2|EA#AE#  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$oeM6Fi_¤0) *T^ $zm AA$/l]bbb;w/dh3Z~;H=z"Mh7PQQ?T-EK&&&ٺ7 D c?c?c???>++ ;&;&;[n9% k;  go(++CK]K]K8;;hE+`.s t jPՠplñ ںzAAkDxhhhOj,㷫qƝwrbʉZA#`n܀B /vUWZ_XQ(uՂ ׈ŊŊħOPQQyxh03l]  <D 4hC#F }z 7< Bu dl]2/S:6ul   *U~|PWWηu d{kkkC1ŘbLKexòòàv'N؝[o--^xbJV*ٺ߳W^z NA>;hz7޶z`;[ ( HIIQG,7us>wA_[_[_t8@7 ipuE ܿayTUuW]0dҐIC&yw-ZSTJҢ.[WxEYEYEYpꕫW5ݚnMԨ@EZZZD`';iAO B)$  B" B)$  B" B)$  B/lZS8sqbuȟ?t t t fӛMo6jjj[W4K/}1b4I?~U /60QQc}p\pÅ>+}V,7vyc!gLΘ1.KXRoA δδbbbQqԀM 4 >vcYo?0AgЁ{=zWZZcccnt7OÖÖ`3444eeeC͡PK`+444oT `~ [AEhz]زy-!qruRޜ9{3H_J_J_BbNbNb|=9_ρ!Czzz,\Y@}B}B}zUW033u6XxL1ZkaAy=`}חԦMSB/x nuïBk_}nM6f͈gLgLgLػwcq;vYGCAxѽ0>qpcB5ה^Swލ{7~~~NNNPPPor?~ Á!nG܎>_mVooo 67.L0$z}}}m۲ _|e1#a+>^1BK)/&g Z,mRH65m*̏7?Z*nU Rh)A^t/Lz}###f. ZJ-<_$ dxY̝6wiPC:; c&<<<(]R#uzKwށkړkO xU*'zO,e)Ker7NA bE,zdqD%*h /&T-ZT4:NK.UT ppp w+ k666(Zܵ+vڑk sAh$I6^sz LMMˡѵF]1ƌ3 11333!󿆼!yC@A}X}X})c )S 2 e $IHpW:\ιstMuMuMAwNwNwGCAxѽ07)SRK'p| .\&jt-P,V,V,ɧOC[ a.headerlink, h2:hover > a.headerlink, h3:hover > a.headerlink, h4:hover > a.headerlink, h5:hover > a.headerlink, h6:hover > a.headerlink, dt:hover > a.headerlink { visibility: visible; } div.body p.caption { text-align: inherit; } div.body td { text-align: left; } .field-list ul { padding-left: 1em; } .first { margin-top: 0 !important; } p.rubric { margin-top: 30px; font-weight: bold; } img.align-left, .figure.align-left, object.align-left { clear: left; float: left; margin-right: 1em; } img.align-right, .figure.align-right, object.align-right { clear: right; float: right; margin-left: 1em; } img.align-center, .figure.align-center, object.align-center { display: block; margin-left: auto; margin-right: auto; } .align-left { text-align: left; } .align-center { text-align: center; } .align-right { text-align: right; } /* -- sidebars -------------------------------------------------------------- */ div.sidebar { margin: 0 0 0.5em 1em; border: 1px solid #ddb; padding: 7px 7px 0 7px; background-color: #ffe; width: 40%; float: right; } p.sidebar-title { font-weight: bold; } /* -- topics ---------------------------------------------------------------- */ div.topic { border: 1px solid #ccc; padding: 7px 7px 0 7px; margin: 10px 0 10px 0; } p.topic-title { font-size: 1.1em; font-weight: bold; margin-top: 10px; } /* -- admonitions ----------------------------------------------------------- */ div.admonition { margin-top: 10px; margin-bottom: 10px; padding: 7px; } div.admonition dt { font-weight: bold; } div.admonition dl { margin-bottom: 0; } p.admonition-title { margin: 0px 10px 5px 0px; font-weight: bold; } div.body p.centered { text-align: center; margin-top: 25px; } /* -- tables ---------------------------------------------------------------- */ table.docutils { border: 0; border-collapse: collapse; } table.docutils td, table.docutils th { padding: 1px 8px 1px 5px; border-top: 0; border-left: 0; border-right: 0; border-bottom: 1px solid #aaa; } table.field-list td, table.field-list th { border: 0 !important; } table.footnote td, table.footnote th { border: 0 !important; } th { text-align: left; padding-right: 5px; } table.citation { border-left: solid 1px gray; margin-left: 1px; } table.citation td { border-bottom: none; } /* -- other body styles ----------------------------------------------------- */ ol.arabic { list-style: decimal; } ol.loweralpha { list-style: lower-alpha; } ol.upperalpha { list-style: upper-alpha; } ol.lowerroman { list-style: lower-roman; } ol.upperroman { list-style: upper-roman; } dl { margin-bottom: 15px; } dd p { margin-top: 0px; } dd ul, dd table { margin-bottom: 10px; } dd { margin-top: 3px; margin-bottom: 10px; margin-left: 30px; } dt:target, .highlighted { background-color: #fbe54e; } dl.glossary dt { font-weight: bold; font-size: 1.1em; } .field-list ul { margin: 0; padding-left: 1em; } .field-list p { margin: 0; } .optional { font-size: 1.3em; } .versionmodified { font-style: italic; } .system-message { background-color: #fda; padding: 5px; border: 3px solid red; } .footnote:target { background-color: #ffa; } .line-block { display: block; margin-top: 1em; margin-bottom: 1em; } .line-block .line-block { margin-top: 0; margin-bottom: 0; margin-left: 1.5em; } .guilabel, .menuselection { font-family: sans-serif; } .accelerator { text-decoration: underline; } .classifier { font-style: oblique; } abbr, acronym { border-bottom: dotted 1px; cursor: help; } /* -- code displays --------------------------------------------------------- */ pre { overflow: auto; overflow-y: hidden; /* fixes display issues on Chrome browsers */ } td.linenos pre { padding: 5px 0px; border: 0; background-color: transparent; color: #aaa; } table.highlighttable { margin-left: 0.5em; } table.highlighttable td { padding: 0 0.5em 0 0.5em; } tt.descname { background-color: transparent; font-weight: bold; font-size: 1.2em; } tt.descclassname { background-color: transparent; } tt.xref, a tt { background-color: transparent; font-weight: bold; } h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt { background-color: transparent; } .viewcode-link { float: right; } .viewcode-back { float: right; font-family: sans-serif; } div.viewcode-block:target { margin: -1px -10px; padding: 0 10px; } /* -- math display ---------------------------------------------------------- */ img.math { vertical-align: middle; } div.body div.math p { text-align: center; } span.eqno { float: right; } /* -- printout stylesheet --------------------------------------------------- */ @media print { div.document, div.documentwrapper, div.bodywrapper { margin: 0 !important; width: 100%; } div.sphinxsidebar, div.related, div.footer, #top-link { display: none; } } source/rsyslog_confgraph_std.png0000664000175000017500000050751412704114446016170 0ustar rgerrgerPNG  IHDRM`TRMbKGD pHYsHHFk> vpAgMaIDATxe|Tgי8  )A*hq+EZ(RJ $!O  N]'39m$ t>2rpΜsIAwAA+ fh3}$HHHHh D;0k:t.T;VXc`>||}AtH!;w@OORRRuK-AYFYFY&h}0666g6h0a(HGQ}Ax}t{`r/Å 2?'S'S'S?jʯ*T_`U[Ғ};vm8r6l lhņPW[W[W -=[z+^x]A>>zuuu@ؓ'uO*zzz >7ememem:u6,BT!(Qx#PnUnUn 5k ftѰ7aoxI']}z=:u] 魁%|M7oooa0u:tvB{ 5Vk@~:82IL7ߓ{= Zk(x:u UVZ%ЮҮҮ{M5@)t ǫ4ѸG4T* ] ‡XUUw{p|BEU_^ x5_~q4>tgНAFՇ*W  R,% $i7Nj'8s!-- n7lQۣ6ԳgSZk {q/}P}xՇW2^eS*]rW k`Z7 ͼ7L{1nnnWM^5I@&XXXoν9%%%z<6ylU:W\LϘ1=)))PdXdXdXb% !!{zrTU &~&~&~p"""`.] | ZOk=  aQ¢EaUªUc;<z}^߀zV] B)s @{z齧ztѭG7B֒%YKp 7 S/L0kt9s7SnN9V{#.'O8Zk000 2=@2 G(FQo ;0ʆ ) K.t?0xk׾/A M M BaO=C"D fA͂Ao= XKK wr}pi';#333t[~Q\$p XT`Q_:~ ՕJuI'}r~AڣGiGx㏎?,@y{zA'A؂c+ί(((_s>'q'N`t^H[4m)hy偖pѵGA!-2L*3 333 /܇Ç:|v;v ^sx́jӫM6]߳"VTTw; Mٛ O>'}NBÔ) S@%xE`nggg#G~6`\ʸq)H^8y1EEE 7+ܬƷnv>v>vmNPTWTWTg?=O¯_ _;6 <Ю[nIII$O^>|wYpgN;ɣG' s'|x;7^U{ctqD`ȼy#Hߗ/}zp5jh޸ya`ȁPҿ Ώy /w9rP-ZNυ969696p4hH8[lz-!L2 J%sչ\ӵGXXX)Sާt,,,==[[[ !!!o27>J~𳆟ҼҼ D}mԷtnҹ xxxBڄ i<S/Bfjy' |4ѮGӓNO:-*{)S6lM7T_} .[}l444_<,u^<~p{Y^$cI,qxAq,.9]rr`d`d`,0l° m淙frԐ!QC޾^=U=U=Usssd+ 2)\rA,,,eYUUdgRYYYA~w*R)pj©'''aYePvo[o ... C'N{#F]4vEؿc033w:]tow57jn7xB]Ot==#zFVZjU fͪ'Ɲwb,߶|m0g4jШA*o!C,D~"?w oKS7F3k0b1ݮE!͐f; Byf) clek ǢZZZ@5QJsMsMsWWWZ}A{VVVBŋ/V...Rgޅ{]g5|Vž= {/Fb$i4EȎȎȆ{ O8=LFKp5yg杙w 9'9'9fb XtbDXEXEXyWzAo};bVŬY?O=a#&1ccB `ү~+>3gXOH3'̙3`kí 6y"7( ]AOϧ$;g:t ].lll *_|ev A\jqՠO+; zvٵgWhyݖwHБ#AP|σ HI#is-ZS)}P>|bDݾvKs㣏Bj5g-?ktZkܭܭܭA|2 QA@AQ(m19y\DP^"/Ʋe-Z=({P Хti 9INogX2 ;7X*, 8w܉saw888}O §k`:t@-v$<i@ZdM6-la DeavJv ;:NrrrIcX+] 4y< tx]q`ҵK./1g՞U{VAڗi_}IA|2 L@@^5}US,,,!sCBg|O⾋2eT˨]]] nnnpt1G@X:au`<ֽ{D3pBq 55555*=cUxV!vxN];uԵy/| ͞6{)Xj`)H @jSM6Aŵ^ ֮֮֮Ut+ӭL70?e~N\:*W`GYtdc3f_,b9TTuPARF)ۣ(,MY,--azi^~귡[̇2e˔-Sz{ C$ i4\^*xURJ]*uIߓ+yEhLcI$TA .0\. \,xQb;oTMhBf7*J fƛwk߭}F2\4JT;e?ьfKX;9|w?/ ?GWRRE5j껬S-U-U-tttpYe $/L^PJ=ȇa}A(>%L$2+mVڬ47 6gl؜c&3.L3ʌ*3 q:*~Yˊ(%8|3\wߥ~PeW]Uv}^j/SN-Ӈ,)KʂP(t/t/tPPPXg]u}`o07en趶nk{n`Yʲe)}UiUZ___֩֩$InܠY|f&MFPPPw vy[Õ;TP)S?[l3x9ԗSc 0uYSgfMhW^u{2.p-;wk}?іF[m+WXCK-!k~w18>>uW:. (w =0|L>/_BBB r*aJ^%CAaqW۞n{^:{%y_a? y>PzU{:>^9?:=k~81(5R%KPcu:={{N9nKݖ  O>_7n|%6Jl7o߄{aA'NlʪU)Ut5k|~GKۥлwCp>}(2 xUWa=5:jthף/tvLZ2i_~qpʥ*@罞z^6ymюvA~("Z&k ȯG~w>=mSUsTQۢۢ[>l%vy&{ Zye2G*yQQQQQQ۾nO?]k>teXaPR2e<zx+\̻w1\kr5jPA岗^uCuCuC})R4UTٟ?>>>Pc@5Tz*= ؿ ^}=Xxo㽍kfgh}BGώ=|(QG~<ꁫMBK.eZ)S š^ lǖ-[W&^MO5j> J}=}/|px"8L3m&M0h蠡B +Tpm˵-׶@ u>ud$$$xq %: 4Zjm`kkYARQlQlQ,_Kx-Q8q?nM&ˡ\hcFY5FseE,f,e3FOx<)˪ o<6ylXYGegOz=칰ž un׹8=vzKfdAyg=!QޣGprAtXtXt}Nq:ŁY*fU Zzj3hgN)xӪO>J.}mPUU݅s 87 =4Pppp>}zC՟\g `=9 {7mmm+W'۞l{ zaFvm$\jp G=x \r!njlPA͠ܗ,%j Z|7KKK B#<}O/HݥRwPPZku~?{_b~ %K`v{N;k ]]]xyy~wjjj4x{{Ckͮ5m l bo`lup'w~_} :NS^ƻx&M$7^%J|}]Γ;Of/^?u:c?o*T}c|eW Gˣ'ϟ<=v{@:]#<Z[lm [ n㿏+W 'O;<z.]VVV.^XWy6RFQ-+++6XЕҕҕ_C Wc_ uuu!C 3l2dI |x KQQQGGGW_!<}f e̗['Nn\$0C}O뿩+v(n0a`P۠Ami.Mޛ7|'Cύ=7=.A{WT?~sss:8TPCi9*UF2RF?/&͔fJ3Avewޮ W[3#ym浅a'Ni>}gu? 9Hϯ~3$4Jh o"W UCVGzU߯aaa*/ױG#oL1j.044, |:>\9xp#_V^9{l0l8p wd_@dKRDX! LA$& |DA>I $AOh` 'I40A$ I LA$& |DA>I $AOh` 'I40A$ I LA$dddcC ;N\\\:ґPԨQQ#U+h 5C(T4hh3L9y*Aw;$/N^6_|yepppVb[vڽj36cHWU߳=ݵv]w gq9rӛOo>3l;`;;ۭ[mBy^A=h}ux`N:k묭nRIm}Ago:=(Pơÿy ^:꼪*cjS  ڞj{-[$.]Jgc?X}A~?es\:>$IjTiXӰ o`iMkZUWHR ퟶ)XzcF)A||g!Fdw j. T: q-Y4h5ZhQddd@C!JJ*S9^򒗠 :[*J 'k`)Rʼn'BEQu@8c%)AJ̯2 G4 횷k4i8J$30BBBO5,kXt> |R>v\YgagLNNN;ľ}RT)ԯ^z ߔo7KpxE< },X F7`4Zzk%! |:> +/n~q iٛ D&|r.\ʹ|T>*E"J&`s]t-ӵ .uRpg(F}  QXXgφ՛VoZ\6vmH/ҋظaaa 6ڐjpuW^Gc9sHgxs7W_ 0x?ښښhhЬ4 ha0m Xss3AzOOO|\pv@[xg!l^ؼy'zk`ʝ+whhh@Wî]Ņ¿SE^@Q]Guk=XXX; |:$uH8w4h ?`Pʴi)S}Oǫ{N9?8p`x;PC CY|uW{>~,Y8=o`777:u@kp~ Դi]Zz 5 /8"\u֥[ |*J 2^y0`@r%w}kQעuv }}}N'PJ+XWkͻ6>s7iU  <7<^x>9|rd}A(y%.VXb5P=T=T=.lQ8vp:ԧS[oA@@@AJN7S7~ <3 XgO}=jղꗫ_T %є)GSAYrRI-'̿?kWkWkW7~@TÙ3; B+Ww_}u7 Y>d`dndnd2OL@L@L\d}4[Sڷok_***㳎:>KߩA{70m6O X'N+~ q q qp3f4PVVwL3;t!O/G_t {?鍧7ހqK&`Rr>rdffBQŢEA"]@Q~EԽսսAw@w@w:u :t½{ B}}=5r ***RfJk RLJ1`W_A2UH2@;K;K; OOO5k mH[Juss˃Z7kݬu S6L0ep( %/*JtnٹePѤIl\ѝННj7#nF\>s30⌊3*?}?AW]sν:*/s2o n*lOޞ=j[+Xfo wTQpoScO=OW<]t˘1/_{|q8쾳`jé 6 '|Osss`A=$ÃCv'm,xQG.HY,4440115P6 liҞ= 3gK],u\ʹs)_Pi>|_Iے%mN5j8AnRnRn[[[iii(EEE5>k,,,nD߈7оl¾ j'A(.uؒ%c <|0쀳΂kV-#tۇATTł&C]]]]]]H<;y6thСAp(PH}" u:C:թb@j#)Miv{ gBBB=?J+<<< xN9#v1a;vyAzSLAZ)V9昃$IAmƒ.?gͨQV[uׁ׾_R?O# ҪJ*AU]U]U֭_~z ӟ簹psB|F͇/ 4P70o t}Xan > ^{ _MֻZjz;BԒ%QK`pE]^1c<*XW` E6mǍc/^@BB2>{8롓OO?y$jSZc?~ *jU ,.[\ e~,cA}e_x1ŔSֲ[n-8 :wrgpvLo޲/azpɡ'N8 VQVQVQ%}A_7016cl@?~< sPΐU%JV t*T)e˲29dr8iN(@%Ւj{ы^>>> QQQpvgCA`^ϼy=n ՐjH5~?Bz!\\\so߿*3 gܼXcevC字^^A()mF: N9QD jͷ6BΚ59k@3R3R3R_;/,&JXt3v7n ,;Yvfn$9INU گ_iCθLe` [gA➊{>p-ϗP|)R2L93̔3`T֨Qْۮ BI2Lt&:`g~:ĪbUڢv-juM5a냭>+W@Ae{ZXj!o/|{[7pzȈΈΈ)Sccc.'''W{_}i }I_yrмм@ѡCE;6vl  4_v4 `aaV[m.롯 PZjQGA ¥⛧ua_XUjW]mGA_޻&116Yda2-dZԉ]' ȍ̍̍#FXXXзCn"?iii0N;AI&՛>O}<}A>Ŷsss m7gPy%ɳg'Cߘ1}cwgN'P}5-K,<*{T ﲿ d:uP}q|`KhvJT:K0kRפ.f.'bŘpȹ#كg F-w:ASb t$I08ip$8}7!B ?:y;w444=J` 7} d9z/֧&ov쾰?^'-NZ333hݲvJA>xMNAyGyGyNkNkNk=8888`ȥ!\LLL}A50HHHd7n'rI{Z>/x t% ԘScN9`i ; 魁g=*{h QDcƏ^{y=P6P6P6w:A{3d0` v𷃿o?< yt:^}W1lcU.TPE\.Oŭz\q|vgî]ˬ/nnn Bf6_/,RUu[[[p읳w;\G}w:AOFR,NY g/x6d.\-5Z QFQFQF,,,s89]N >œA, m m muA5kp`3i̤1RL2e喕[V )hş- :w :DumH[СwAaTS!00VZM7d0ٻٻ; }t{`列#^9+rVϾ}3(2Cн{ai햶sOsOsO}AgL 2*zV +];tttXcN%}+^x:ܝwмr+E"uwgii î:*:u2 ^}e[}AП+ Hے%m ԙZgjN5Hn jVY-it)hkk; ‡ѝN?plƱ T\!Xߩ>g Nw}A>=EۋCh@h@h4 h$O,bbll އ{?7oߨt G\\\ UHU@-4ڢTg[myj쩱qwA7N'P>5QvFNPF+;wPn 1LAJGdgYv{-74nh e2C>>TSa PPPޞ{{ N'Pr> eA)ϭ[?Wߩ>~gvy&C@r@N$}A(~]{4јGc*T?ddkdkd òeˆ6mCCC {セPϤI=0,oXްS}:\\\ SN:U]avAeN|4 ,UvVbˋ-/@ 6(TUV[ ӻOw*A4سgcςHW+N;v;էbjG 1cb; hؽ{Akζm;;է鑦G:SL3sfw7xxx#xG ALLLA(Nzo`l%[W_=~swtX: ^?z#<tӱp&7;&kɰ?d"7Dn[[[p\ѹ"x7lq RRRI֓'Y|M7Ayy@> zo` .$\_I}]z_;ߏ / 5kAr@a0V~߭aiii0.#UUUHM&P( PcŎ;!2/2/2 6+lO?=0ȭVr+}ϊ {TG#`eee]XvS}uyr`9r`8ЪCoWI^;IwM7$HHH888?~><6m}z]k7m)'8gϢ!44R.L]nnn`+0\`pzr=8{$H.K[. ^yUlw7n<~砞{$c7ok׮#G􇼩yS C?hɃ&fK̖-w/&Mjð+~XÊyQEjjߊ„ .Lڎk;-YYYÁ|~sl|`VVfCujש g4x+}oRFJ{sau0^n#mL;M;M; ^}9Xpm#MVZMj5-Z[һJ* }ʗ*_ J+u=h4}(DvQ~GyH M M .]z4T* ϊ?L*P~=zz ,,,/ʿtﱝn;v:xn !%!%!/ B ri9?PZZ xy<v[ ru\|1AۿP)JQ K%ۿ֏~i@Zכf3co}5ppp5>k||m8PoZjUGVYuŀ]q5i ՠAW`oހТN:-@ǗI]$u(XW`;wF7nIIIAԦMQ ! ! !2r2r2r×_>gxv2keʬo6f#صki.F]'{uw`vn5w]s|7(((/[)d5jL|3ķy`FgԆ'W\yrEA|Cc/Aa=€f4A7n1c Chdhdh$7roO B!`ҠAK(ӼL2͡& 7 Lo1lllE"E.CY>fLD:!N@R!B@gYjjj5X&X&X&6mV`jV`ʺu+`~8Y9Y9YqsSS0_bbb888̶m5 1scLpaۼR*TH>~p*Wo |$>SSSa΅9\f vڟG0뮯7X~̷o7{1ŀ`DW_Ag+aP>!ĸ~qAUUr4Aw >X{b퉵}3ZgV[Coo/pwU |=0888' :'T =!{Bolk/68s4NA_^U6ڴj]4id-o; >X}81$''kiҮ](z(z(zC9>_|-}k-q1A5e˂vvv9[~l._ gϞ={@٬YgNE%=Oz5 :P[7uyw2d L;2<뻯B*J? vث:꼪`jbjbj 7VX=bh"E2T+[lſ8Xe hhhl*ʦ)~S&[oAU5Kk :w111Ou<X6lnB#B#B# cl؎`n.h>#Sç4[OS-T ZEuɫ{ͺ7YfM5=W\sF.]3o̾1(]6l4\rp%oʾ)mK‹ /`:u;iwn(ZTh>?ɗ/CCag΂Pz}CA֓[On --ZZ'$OH.[x_* v jcv/g|! +̮08q*VVVPj_U w^h~GAoޠءءeˤI9s 7o|Pʱc)G7z222tk?{A2>{ȿ'TȩSᯬ.|ʔ+SL93 g@CcJ` y hQ~PY,*SN;oMkZCΜ99s )) -9qqqu[mo`q8m]5 eI&Y ťW_7CAalؤIhFS q8y=jw$H2 t#Ar$7%uɠzkyusdo[Jo*LMMW]Y]%'aOj;v(4iSe x Akkk $IړN o4ww?[o吹4siR_ ~ZZZa6Lu +dץ p[܂ 6p|yY.r/r/r9GsrB e9->->-^d9o]޺u,!r,g'e'e'rqd900PUTT=ɂ Ȳ,ZLy<Y|d?ϸ>52m3m3maf^1bz@wtߡt !Ă .gN ˇw‡bnndddɮɮ,TAA50Te666.WZ4liNk8K|V>+%Ax%fffHS)o-V aeʆs:!tB_~NOY5riʁqjL.WЗ*5ԨRriسp= _ Y} %Ƶk V:+W6_r}=SAVg)Sob %R"R"R"vBۅ.SXXԱcQ5o tKt |JJe}mַ`gg2M=45[l]5wkkku5_kaaa}cRb ,;/;/;,{[2^i /@DN iӐN;7+YJ8wܝswZI50llcǺ>VU\Vq4ݴw0C!ϐoᄑmVYnxǛ?x#}cP,Y8jʫvvv.SdϬY9;3wf̄;[lt>:GltuuALLLUOMMM l.]2cw= k,cbb 73737,REW~QuYuYuXy,Lcz}uK-]Nf9gdd@^A70<<uF | HR JRԾߓtG#݁nt`9r\:دc!yH1 c@s%抾S 1(= u:fJ343hfLe Z.k ٶfڷk߮}>֛Zoj.]KwZA5DP^T^T^>5u}a홵g֞p;pS}S}S 9g[BBao`z?~[QӢEME&ML迶k#X|c7PاOaVqeƕ}>x+(//WC^ y5n*o*o* U9rVP\rAWˮ]-999,]-]-]AyRyRy/NuJ +@yHyHy,ppxw[;N:ȵrmPTT888x}''s;w@}ipVۭ6^d{ zI\N +&!!FVRacƨQP^{0;﬿.:"貸.!VdZ}4i !GQλ N;y/ k6 A<${Kn}K9r:4\~upm@ռyWu90u WpvvP~Bl)AJSL1Qj@VV[ :EuGCݱΚ;k뎯;bnQnQnQYj|Vj1xPNPNPNwтa@]]]{`6lٜǟz )lv8 }վj_c;>>>+1x9TUU!؟b۫n N;tPd+,~Y28upsPSNe:Awo 5,װʹin\ږw5Ir9sPj*:u+|".տTR}w C*T 7m~0h0`U CWۧN;[\#\#\#@'A{ 5GrɅFzQ}!~;{ĝwN܁N^:y K;v. ㎌;2ԛ_o~S)gxxZk/9{`hY|%GhF3(ߠ| `؆ammB ,賠+:Vt)P}쟇.1y%-IY`ިQ{l7n2Ϸo?7foDU 0TXR!)ۦl@QDG:%Nv_,g{)R`aa6Wl\"""055Nx{@$DPi4SoSoSo055WV^#G|!{a셠ъъGAAA+ pppsϓ^fϝ=w\NH'julfim AɃԲRJ-+ &xds;a۩m70y(g044wjAx?žfhZЖ֖֖11bI&&8t9-?>Py_,"o7ob!Ї>sQEFW1c6:uA_r r,'37xPz(=*QJ9]ȸq!]vi%o侑`䂑 F.RJ*wWԻwQoHNNɆCJdh郦`OKX?r#!Xa5Ax? w2ٺٺ٠Ujw~mBe{дѴѴƑ#I{&|\qPM(ttuu8*hhh뀮qt~EaEaEa===P\\ pE"eˮlll6Y6Y6YسgcO8q tPwPwPZn-uvvvۜ'OJ*ABvBvB1.]x;c_}=`_6kSyR^ p @hZ2k+T8p\r˅.0>a|xHNLNLNC;t-~b 6w|ySOy7ݜgz rL˙gʞ){,\[rmɵ%w|wş܁r9999*sEEEkXÚ߮ |:v2B]ZK;7n@)r.\ʹSNSƧOرcc,,, UU=5{jTH><}8dڕ W2\͢E1G|2%(++ӫO> &&&`զMW;6v,ܫp½ `w}Mj7L3o ro :u[o}1켸΋HHHG#G@dFdFdۼyyypwCY璓 뷯O?Ok=>{* 0\=bbb_r{AQ~MYMYMYx6ٜgs GJp;J+aN))) Yw籡Pjp֧ZC͐!7;̾ ?_EcpO@dȺu^&b?hüy0yh!٥٥ٽ}W_k7ݸjvٱfG @ĝ]n- ::}[j߾yʚ5+ \:trqQEEu QG!kN֜9`n444IY&]*r$I=0{`S C5.ָ]+Vtnݒ%Cʑ#b8qW'N^(ߥ|]tKR.IcL1= yyy\r> f9rt TiQEPj嫾]-wqvk֌[aCw Nu;TFڍis.\́'|~??<<<(Wگ<lW{` L.M-BRaRaR_,E(OyʿƪT'I% ʁr 3/g^m3\rA^!W}^ziDZ,f1gq3GQ$FiGZ -a cHf011Ɂ~EAѡCE`ӷOז-_[/RRR-7 d;a &|˿4E"M؂؂X GADDDDD(q8йtn@R +mU4hVfʛLd"!@Vh}H>.}\"WաhBф ug,XE{E{E{ ,ӻhтTG#i4D O(SٟR;wqJc<^TiPZN8f6:tm\4h~?o?E"io?'IaR(f*f*fB-_|{0Zk`jj /4I$MUqRZ){o•9eXZZBs5;g&l3f6665<[ ZeVAKy6I'#G$1wsM 6k~d PjaB#XrKogs::8:8:O?1c?6~ ;>#$H óg}CN!jՔaaa)Q)Q)Qfff >>>-  lٌV.Z]֓'"~z555z _Pb{`l]2v\ן\r ky彖ЩSQ"011uuu}9km rM\r(&i :ЯC?v+V:::qus2dE5E5E57/_2~%Po]uցooo&txYgw%Jgϼ91mc~1G;w&4?Xc Az3>w3fPE"Waz饧;w @֥KYq>ԵkSW[gn2v-ۥۥe8.~@n_|i%z$$$3:g4Ow>wAȨQ% Ww^M7ߤKMj?PKUKUKщщщ.]j;h `lR٤ T[qoŽ)ﯤNozꥫdyɇ'eJҼi'ߟ|/V|\QQ!OOOZidХХE5j~*r&3ο֜eȲ,ʲ,nrweY=T=T=T///dV)Y _.|-K~^ey{5הeTkt‡8qY2˰/dE^w*AkJlq ;"wD )SRR ǰ~ùv m -[ ?F ?? on"KAXXvW]uwUXeM5]`ӵO>e_}YW*x"ٱfǚ~j{t0Y*ό*U6 C =7ܩrʝ*pl۱mǶ %u=^ׇCWۮ]mڥj]w:AkJY8Y8Y8bbbM/^/ӠL2 ^z5k:|!055Zkݯu&ԜPsBMc;v (PJ*I% miҴҶJ*Aa͆5 6X7nl޼~k.oЯ{C6~mg=~E2lyW_i?L9焞pt9G'~O@PPP)~ @X&/t-NCW_ut~J'''Vf[!99Ź4S)@qIqIq AΕs\0nt:;|y-Z5?4ǓGˣ`1bgYϲ%|ߟs9QQQ4$VMXbƜ9 ~ZССZ*.E/`g[7nݸu^{yo;*vS -Mw9BޥK{ ; k`&wL܁ +<^}=wDj"5&.\R6lJn(Z7nƛ^ln0ws_':W8CakG &#\r˵]wi8q\v-k%꽪 IEؽ{i9͡oA@n@n@.dFeFeF;7w 3g87zC=ƃrrrS B(-+X~c Q|۔)oϫW455!9<9<9TUUӡye`}uPTFIӤi EP0``@_,~is͙6fff :T;~7UTqvvv\ǹs㫎xxXL}Eq.mAQbW+c=5hD{/" ]tv7y\既fEu gsf3sXcaTQUGU b=z5?$ΧO;O̠)RХ xxxq`M5=jq _~a{UͫS § X*NU qL1PXX{6 U*Cڹڹ[/oPp3gEKPSYSYS b&MnC*|W;>}ʯ |=Ph Yg}SŧOCMM )~Sӟ%o!o!oԺR O8?L3tmwL>?QgFxz齧JQ*w$,3ytx㽎Mg46n ގގްvb[7o&m3fMG!tOtu:] I$ gp2S\R> *ÓO> 111PV[nASC/^`oo4rs ΁3g@ !((b~5WPY,T5keu0DG#O^޽0r飦e^˼A{>X3 R.O]??<^U}UUn&MP۪Vg, l -[z@6P6PVcccՆ#G@AADh"E8ٛ7go9s,@unݠ曚ojeˆB/_O^qz!%(%(%&͙4gMHRjܫq,9`mgmgmFYj$ĭ[b7+,W@2eU_`V٬Ye055 f*aaa h'j'j'EQ ** c@VSVSVipE=Wiiii5={@{{;[[[A|a|a|!dffBшE#4ih]냙##ön; KF-F j888 .\J쫳4hߠ}lﳽς#G M֛7<\Ԯ]Q|QPSS ]I30]RW FIFIFI`|U(5ԬR캲ʮ 56k| %%ۿVޤISO '*8`Mw2fͨ ;od 7jި9ȜdN2.ɩI$PVVBYPd d-Z rwyjՆDž CE.])H @V6N;:uFKN ;V[A~eʠ'I ; /,?|據O#GP԰aQCMwWڨڨk' X/ў=G3l. '{j[@mmm5K)mAڂl+W c֌Y3f ~Zi Y,>| _9ls\s7hvA#?:8\5sUkkk .0:u%¿_/`lh͆wz]fwtw 'N#<:|||EMJtZAfz{ZjUmkmkmk42hjjjm,3>s&ޜxsM}7Aw N+Y#/;0oƼfn-Z4=_GO=yvvv0lFVitQrIDATJAaA*CAi:՗K[շï:[߷oIb&0Y9Y9Y) ?0m-BM6 7000MrLO2/_#NG &<zݻwo;Zw }i5VҽK.݃w&C}S_J еkC:::5Vn[]XvaYNNNtXAO#w,6Yln0;w(&Mʛt%GuH#TWWWh2ɘ&c`J)ݧtK)`jѪE*_|S}rrr?y'68mp>@^AIIE(,?&Met),yᒇ`UӪUMM|}:^|{m[naڈi#K/g;{'*,*,* v}nw!뇬jlتNy[me`ǭv܂[È #6uSle2[MA>YZlݳuOah,(ԂR```锟Nyy9Z[Anc;a2 _bŬ&&&‘#Gҁ8tGVVa}̣3< =z:tZA/!ЍC7OOO0L}0P)Rp`Mr{=zk+6|`shf̺5h: 數 ~7 ::GΏ t.AnҺI&A3ajj \Zpi锂 s y=tO= }sNЕt?~ )tttyݛwO.A?Sb ={`NpSvSvS[n}Dߊ} 4pϬȧȧ?8XkYeg۟{L&L02AT-`8wvͼͼ`[m}$$$?8QD| Q>ŽSH!x[fdu _7Y:f6M4atmԵQF?&w}6oۼmɞɞm?nq\o{ǫz*G R׆/ `Xa`4htټfo k\A-yC>5Aď)YX&cޏpl걩Ǧ«i~Yg˻/ᄐ)GaRI&i ?瞞{(((aYgMKc)#̘̘Xh`5lj ~5xZW^z5p‰m~Z`GWGPSS샱6 " " "g|V[mo@Z5[ _;YuR.K]`gΰa:u\IϤg\Gw <~ axM7S2N20a6 fΝ `y?&*bbbv v vj8o iiiﷷns::hu ܼܼ~nTŨQOn>pWw_qE_azA/sL1E1E1tӥNX_ e/Zo]]]Hj(ufי]PWWgXp• !mpǎ;Ё {){){ i>i>i>peW=X-PR|1#?7߾= |Y׳j^RJ*wn޹yFUUaTttt}Z={Ȋ#+VZ=k -p\Ź 4i^M —)`J+կT{neWˮW~ɯ_k"Ek:V׭nnnJQg!S/_f?PE"UG<UV[UXXXEFi2 CG!b]fff`hhZwh݁f7֚N- ^B̘11c" ^2x%&Mvb]ź5( FotN- Վg*f^?<^xcx⭊gHv=zuMAj X4DFZ2e8'Owz׃ Z6h|=aN -`'?p2TPaB tR:)(mԷQFТ\r-ʁb>!44TG!f!Up5r+tUe+WP C aI%T)=*xAM %H Rكg +wbމ&MdHuuu'OkA_]3b'7ozX?/$${;vֵ[n]^zjx"{"{"Q |"E pG@XX#y<=ֶ[ntqKAA4} _/,_X"NE8ZUjUՇ+G#gxЮ_~/? k=4 |z_M=;ddd@Y&eM>^гJ*=@{- ,xM —)`GcMB*#ӕtۑnG.9]r:,+{{Cj X!!! >555k*U.\Jӽ"Pr}5,R+R+R \.q]WvHvHv:w=L{0UWÝw#2A/`w2dށĨĨ(p_}ҾK.w]u}kYzx롦{K XRNRNRHk5i3fCmO= v6 7\-la{OOOOO׃Q:Fu*TLd&2 >x=6zl]ŻwAc`A||GCGCGC_S^ -A+Jh(r(r(rnN9 z$Hkh }&L<EQEQEQ`߾gx4B ?"?"?1CJ*,ANp兖Zlll iOӞ=nHݐ!pJ+Akk+&&&={ҦMI` ]Xx`ZkvڽjA eLΛ79Yg"""pW@qVqVqr\.x/^ =moN7n:=w參+wlJٔ)[_n}5XTnQ g**U4^{tG 7W\}Ϣ |XL1k`lmlmlT\֯ cƦM!C'@Z*-j:рG ((kYײ;w +:%tJ.*ĝ;w!oHސ!C'~_yFb ?UTS`mm ,YT_}k l `X(gQ]1m۔zzzp% ̰a=aUUMV50{k-Ol?z(Q yyyǭ[MMMۗ7K"$x)))G2jRI&0܄s~mk;8|'A+ݕj:o$H"H;Ҏ?9sNiiikY,dPY(ȶȶȶ-hA_]t}?BNJ'  po,[`v KK%+++tttpo4x3ܠܠ ȫW'/2_dHө>=g=dɞ=aiҴijjj Lf7@WWϧW۫!-- 6uiS'PWW3;8\re(P8pD]uT)RO(IC\q 6PTUU,}X0I*(SP$4NiX/$^H IYg-)/S^JRYY$7oL2]2]2]$)<<\%xuՒ%I '47JR~F~F~$%mHڐA/&_L(IEuՕ$Fz#Ioyo$)VvZ Mh~,vvvp?e,XY>|f@̺u1`WolllMAs_Lz,dffBo|SFL?CZZZ03Cޔ){r?d9V)ASMVQQc_ʪU:0}Cqq1-[;wHLVVN; &Lt*A 9 *{lr'Nhݯu@^iҚNSRRO{O{O{ jV%J60l`@i߻uօ[`J 9ks欅$u:I YMd57foޘAqq1pyV:tZi7Ō@GGkkk41gRϤp?\M͛"E !NܝhM={³&? puo4*iT\~pJ?p¡ ^^^K:,u1c@~aUW뽮 Ύ8;X`cfffi7vہjզA NUr58kpYg N&;MEgYtb`$Im9rШJ*~nAUU^zu 5,jFFF`j:K11bbD\0p!cjҳgKO8}75HkLk UUU*GqNU7o Ft[=zl /"""5YQ. ~RHZ'NlٺAwTݩ -- 27"d666;\]zuեP|aBО=Y{AB%y7deeځyyyC}ytuu[o}Yg;v&)Qu:^Ti4B -͖͖q7]wϝp e.ZktҵJׂW^z&XO` k;34?h~PsGF%)SzefNt/mڷaв~-ÒK,Y?<|8qP[[ zEWrrr?%ʟ? NJ'III L?iPI'qQQQN)܁sx5FP W^{U+V/ǻ~[)A&JR 7o 6l4بTǢCN99$z|4ki,;9u'u'u'5f+khAJlSUUυy'N>}4JpE8x>}M7dXmݶu FTg3ؐcC G,B-.%UxQ"())zk:ȧɧɧAk#Gͦ6 ZȽ#܃gQϢg+VJ+=EyEyEyM Czzz0PjwT'׏~zK-j묮DFFžGHHHKMc*#0III(..Y5Y5Y5M>5eee8wL+PPTPTP< Oo$HLf2SG#‡(#woSLlt(S? \__CbĶm]tj_ #;FvQ12=LFmM>5} } } XtzEЫny5j~zZ ?jv׼[ EEE頪 yyyśo^@ϱ? /8D,Yօ [Ϯ< D]u^jzo߆3CA@A@ABqfqfq&PTt ľ2b܋0ЌC3Aߎ};j_ C}111v)o@VtVtV4re2(++",;b<};餓裏>ȋblll0kh/6m:]]] ?2-[638 Nh§Qb|||9Ȼɻɻi(`_êU B v7 ۯZJk/^hЂv<==A+`=zls2RK.`tF0zi% 1b0 @YQYQYA#vvvHCPUP|L(,_X5k2N;M=AgJ::f\qeS5<\'pggg@YY'?ww}|6志寡ععHa0#enC>(qyƁ rK-xM7= `r>еѵѵRH!EUUU K^.8qncH28e0<7yn^Exep{`rv[5j.PPP@neZhQ [b!zzm"XdՓUOcxPjT|bŋ/V5kx!N`:puWgȴi# 87878~ìvWn|i ypmеA͏7? h?J* \s(;씲SytttF [-[-ۿ{7,oXްk;k;k;k_ zzzU+044ߗPG!O'ϓ+WƯ!GJ)yJ%nrmA)A)A)pFAYYTUVZ0ƈ#jFA/P/P/Ov#GaQWFheeepnƹ 83&M`@H}4)-wrpҵJ*xGZjաC];t&NM||\A*hH-`Rh)EQ.x\q|iϧ6m۠PU*TA}y}y}9/(^Pn܈vvvΐ_5j~Upuu,,,oHKK[l?% K0 z+H~*y,zR %%%J+ .\.-\Z@7C-Z YUYUYU`ؠoc%K,-¤I x!{!{!ߝw0o $I(~-k_j⫠]Nv9@tri4A 4SgSgSg(#/#/#kkkXxUtұJG8W\so.:\p ̬̬̬ mh7ox QFAUiLp gmyr>.] Xc <4BZZ).S\ܻwsa[m巕Cws\\ir _;---yzAnhnhn!2dvXր9BŇATTh/(F<9HQҨ8w8{z쫲‰'柘fUͪUTnPY,Rd)Beg9* {PVPVPVmDEI$\G]{uuuu߯~X[[ Y,R k׎E1bŀ^f/]wY4VREz!Q^FЌf4:ґ8!qB0iӼ'888-! Wտ-oy' (P/yKޯ(L0@i4N'˅ /o>>>:t<}m޷90y?̃V:XNm 7of/uw]P`QG ss7S{O=c:v(nVzkI_԰԰0xH6XXXk.Da⡉&Vέ[•+ !}~5KS AAAd9e9e98.q\8ؽe[%K0v[ʂ܂܂\( !v]unnn q.]7tbҐ:5ujTx*U לUۣn㱏> =t[>|n UT9S >|:w!ͯH ޚ{k_r=v;jPhPhPhQ:Euz7웰o¾kC?K©S `^0hكfCӵO>PE#FAkf ;;;|'1(1(16\cs HR5*<|4_~z333 l6lo_3gX?ȏʏʏXFcC\ 7o| +'+'+&&&Pfniz~z~z~ o(o(o.?tm봭Ӷכ7̜͜͜az齦y;Hf$3A'NnܠaKÖ`kko,ΒMv2 e(C")=X_ְZj W_jmڤ '''Lڙ3i0`瀝vz},{fG͎ x=eO=][o =bd1o߶?;;;lllo~2zzz0$xH`X{7GK-?a pǓ'O4TSS~$5:db/Fk:+QGݵ}wM^xŊoM#FJR/"I!Bƅ)SKR+$)QHF!}CIJz#$HR;$)-&-&-Fﺿ.IPf(32S$Η;_Se|xIz { { nRIR%a݇u֕'|zR$);;;;;ϏBq o侑FJR*6(Iwݟ$)mlش;HRiiϏm36gϪ?l>$уFIR֏Y?f~~~_HtG#x _ y37gn\l$RU*.]fXPjZө\aaa`bbeeedT?~P)R:tAuCs0U6U6UA5jՀ?>9|r85 jr fN9i&9v؝c ?.?.? B߇~/;3AFǣ?(ywݝp!O111DDD'Xk]u@-Huu5{ !emڔ>M}4[+˕B~5`UW뽮 Ύ8;X`cfff}髲*;!n݈1bŏB%AN9߿ݽ+++yzNJj<9_4h~ccc?BÓ$0ad4иB 0vA5k痞_F7n6؍c7 7n2Pz}׃@TT0` [c{O{O{Op p p =CUeW]]Iv%aUêH&M+6ش"xyyAȖ-![@)ՔjBee%T/^Pu\չ TR A N3BgbU؏ W 9H(M&J0Zjh)4Ki (F8Q1FyNoo\rlB nio'P(@zo}!,//ä6LjϹ>>> Aj&5x_!E@AAǀvҫK. dړ? b|_?|d %%o1 ,;_w ? :$vHeĕ㏫Af̶mAMM ̧O5 %%%|2+!;+;+; >wC@vOvOv222 bf̊ן_~72^P:@7 dMdMdMZԢЉNtJSwhq@q@qAPkGqB dGdGdG#03lmڰ50 PxkVPd*2?Eҥt)d'd'd'xwq0!nG80Xk`-n^yueו]WBev t3I_yLϘ1=FFF(|JLn=z`jj o6f+W6l`O6(mP7o G#G"D;|nnnŏeJ;TwP=z>kooz]uo. 7l0prsrsr&Û o2\ov ^{/u{]SSS )Sf̆GD>|? 3*fTkׂE UWp2d,d,X&M /ڧڧÛWo^yɐ5kZW=4{(XZZBR)R[BLIÍ;"v@ħO!QRFUFW;xuՍW7 YƳg7joӮO> ^^^oooBstU]G)|JL!S20n6l84Ji_qu8e2N ^kxll?^uzubkܯqƁ z; Z?hNt?Dw4J3hJW*]tYgaߓ'.]N̜̜888~ë)&&&cccVVV7Aow;6m&L64m6klج.e]ʺ=_0`~|[m* TUUA%o^z{AׅA'F'F'描%ӆk8ܗ/w_ֶֶ֠ S6O|_m<,5_j[oo=>}*ܸy捛 {${${ /r+\|qPpcFx4ݰv y4xA5V5V5|||@tR:Q)R@wdݏpoEa^;|wnlH!͠၆\n—)`V?Yd^+U__7o@@@??<|0pa@xd!\ɼy%7_XXX{={j:v:t Jm68?s~ ʌ,3Hh;춳>p|+5kFLfUUm컸⾋p&@f]umunֹY&h:W?m%$$t'0!`Tl]ZPjA)(}}txK0e2Y vvvnnnxʩʩW G=z.J\opu؛7coVҭ[ 8q/|9>c`3xW_\g<2eK. K`|3o̼19s[+Vl-(S.\ 4N;_G~M?RX)ኆ+M6.Klﳽ#ry"tbӅ> <<<Y1"]w {20A5A5Aإإإ拙ޠA{ʼn'^gΟ!!,fAEy })**ھ)S4r[-ȖʖʖH~Rpy8GyPXX Y,i^U4hJPg3ՙ1h=z ^jlsY=zf^7nxr].ӧOnC &4o]]]???Q| l)I[&m3gwi o:B뫭 b*Tx-a_\v?~l )|kFFFN'S &L}_}n0acCdž<(;ԲS{++˯,; v zkyiyiyiM'0̆gBz!ADlƳfӆO>m?g3FFFC6ui}jKR@HH \B|+PԢEQ ;w,T7t:JI߼xՖW[b.VeUXV:Lu F6mV;vCCC 85vj]`|=0hoޠ=hMך5]>9́|e2_ Y#Fd 27@z*U ~v.j]:777|0að8>v|eh떯[./_7775} III.XWb]jGՎ- ؗJ^/^8{qbx4GSsB {z齧CfzŅ^\mۢy!g`P0`bD`2 K .ddP L3{=RO ej}?N;Y;Y; ȬȬ ?-~ g syAnanan!d;}233!fͬ8qb222RtK899À5S P*Tr\(E)Ji, ?0ZCń }оSN;9qM>T`ƒpBϐ!=CݫvڽZڃ]]]T"ΉժU*m\\\wj6-$E'E'EC)S L֙3 ɇ%SOJd2{i{]uP.T.T.6mۀ1}clllcǠRIП?Kk7['~as\M5A{`:V*ZUddd׸Jޱc{æcm:o&M#uG0aÀ]B̊/7{ǥK7ncccЀ|  iulߦMV׭ zL179orQ+,%]Rq_}_ө*g\θq[k[n }߷>)S87K;{A 4WX_RRRJ!jC|cAHH~2'sp)t)t)2N+&}#wܻww ;v;\өwUUUҕKW.]y[m`so |8Ç> w3f̈́r5Hk}}uuu`.]mශ`-kR 4V?{F)S*O?=T_x≇_~qf=rH^6z-̽7{d|MƋ%ŸjF`l٪U%KӔӔӔ k'k'kt_QWV^Yye% 7奔/_6t5jUiA(I;mi֦D}}~*@ N:: +)OA=B=B=mRyTJ;XsA=^zU''|ŋ=A(=)%%dɞ~ʼnQ FgK- ]>w]Fw>}u^ݽ{u갫îw|k5jjjjMANnjJO 7No88e|1/_\¡TRJw.\ʹs.e]ʺHZ+[&M֛dffppp5:u0 ,j"ePA]+lZ6j+{W t+Vto |:b7 > )'n./Yr$'[o pD5j.xbrW3f^Zn 7VkXaķo_{̷e--()) T_ -?yuyuyupqq+m+m+mH(P6,a{rDN iBu<ց 7@;Q;Q;7;xK^j(A4GOLRyAˤI/{',O3f̘555v]A>_}b={ A5PwPAuA,G#tZACeee Aχ(`X!r0hŃ~&כ\or*[oy1`!Ќf4 |FDĒ`@ar ZG4h2?oߚPi44Oi4}t #dB 666`eeHF2n{ C 3rۿ܆/־XhA4GOپg;;;555z0ˆ c׎];vEEE1kQ(`HެYy+WP)RNА+Bo}N;w.ԸPB 74}Ԃ qIP%Tm߂cN?nt4ְ[n!{ClP_V_V_[䒫^AtDD^y0`\0^aPPP 2=L6pw]PTTF% 'OjΫA^)Rqrȡ<@a럯9(^QkjAG_U_T}QZl9L` vXTV[ w;NY:o+jv٩&Bd!M ‡8>)S2@ZVZVZs2Za~6z}pG[[VM ‡#+j999vvXUؚck'8v8dy%3ՙLM ?' G2e=n{83JsyW7n +N8"79nr'P;N5AO,^Խ{йsCY,dNUNW9]4L?N[ ;v"L(P0Aӽ!Q>Ȇ #mmm!(C!kkk3č1pkÎ ;6Ezt?ۣoBCQGUUؐؐXwwwbbb}k,<7|n=7znI%;3g@XXUaaaq^Ž s\1ƐCm۠zzz [.[.[III(iQҢ$xې!oCM6}!sC JC!RK>|..H]@gOQ>e2F N999Nk _mSM6T*gSu9rɹs|eΗ "Eڋu_K,9&LM܇Gtnt'O=P*3gtOx}җ/ )Cʐ`up^{ّgG mj=I{~X®] e= z@X"pE }ޚ>{=(zW|||Mp嚕kV= [o}1ګګk:YYY恱%x8q8sLȎ̎̎W_ ,sMl1b0 =`xM5׀A@zkCUPEZ4lJ+}94H"'9Nۚ5mkB 7\R/K/ݾ=c*ڲj˪pnɹ%疀={((()))*V ui~2'h.5K>{RcScScmޖ'NOh:qvywݙwQѣGEq)@k47B $@VJ+ [/[/[z y/~wsf6:xu:S)l3f J*]t-z땮W` ְk;^{A<$}+Vo+L sB,G#^*0}-[RcA?O?O?Oө>;?;?;?f/|#ٿf t&LЁ1:urty"D Xap!?VYtJAJ21RVLYgͤIG?,dʒ)8+qV,M$JJJ}S}S}S0H0H0HtϏza c'<<r|xP)ynR;HX*a{C>MPؤIa044tOJJ z豢 }CPHPH߯nzp:u28 s0 }Cֻw[k?~,`V-'ZNeeeHKKσ1Wc@TUVDDDZ/k%QwP٩TvbM>Z>Z>hw 9sUWÍ7x \`ȑ$@O>asE.XV,+7odV2xL1wvg\7nxmZ(ԮR4w~s%MARmq`t9`4t_YCYCYChnnGGGpcÍ 7 j|K-ͷ'̳HHlllHHHipJS@E*RMMMРР7 PZj z]u{^Z+xyxyxyȂoJSTJg*0>>NhУ(g(g(g믮urցz >~`y:gt蜁VsZi5/Cxxx+jih^y Jg`ee,;XvCѥKE@/X/X/t[m ߴCѨQGa FN 3t'hՊVP^qb0Ag&MN)§ &qMYR%B 5F<at<7xn\xg㝍w tJA>QD0n8p8::¬K.ͺQE +WCwwS 17eu5[M v/` >4miRX:!㗌_2~tJA>Q9 r;w4F# 0=~zxH].ⲋ›o濙锂 |Q9s @9s+WN% vk kמ [n񺅦S OByeʚN%U- [n&KKK0o8lj: (`QP]bbbAS ^^^|37];XyI%^{B _ إإkҕXZZZTSNA>]t}.kf̮9yM" _ZZZ lY,4JPЩ~ȡC#aSMp2d%o/EKR4-(ZPc>㢸v,#UQ,Ш޻Kر5*+.bX/^\͢.ggǙ=sF߽]ĥ u/u/u/yɼd^ K%JHHH@CP O O OX=kճ ]λweXa],W+˅AAz:u`Ȼ!h;mememe'lO;He mmmPM&Lf;S?3`l?N8N2;e"їM,`qsd&2dJy|fdȜ 4~ M6l6۫A ylHe'qQrBO777 `бtK9sV`gߝ}w3^.{ܻx⽋p&LHK_|eoՐ I.&]2eˀ9())AAXXAYYt+t+t+@6N6N6dQ(YH $0i4h$>M1b6 Nw:V]1(q80\`p01(& V`%@7 hmm:::%xxx!DT>!O yTpÃZj=׊׊_uW555 LLL;wo!p93rf@EEܚvkڭix)Amk߯}FM5iv;v؍7g`&`].E>5~YsYsYsٿgA1M1M1~˓/O< zzzH#@aޅa䎑;FTTT(T"DBK , b7%wYLf7A-͖f9;aEoZi5{l|)ϧ@垖{ Ì 3G&&&YrV߽$L2c9PT*ܺrk1ǬɏO~|#rnʹ)p/mX۰!lgtW@DA5 jccc-SN=:G /S/S/SIII???({ղW!22A!XMe6䃒JC[nmNrEM[6m-?HXXs\0""ݢ=v͕6W@ge}FUUaf79'rN@ئMay} W¯_ a0I\'lO؞۞=o \w94iS,,,vحح V6[m'''!t`Ё65h(G(G(GK/mk,Xc㏍?6444Eެެ 9s.\rrO7n03Cii)L}8ԇ0cBfDT7Pyl展 3`gg\ 0€  pk0g̜1scv SS)$** atctct)E!sds B:` & < ~cJ(D@ 4 n ; iO z􆘍1c6jnỮu+3(gP%Xd!{ғ JBwqxt!M4uA)ΐ;wjosXof FyrIh$I0,kŲ/oh)b---As9Fjl˙(8 Q5jD Bq%@VV4D#UUUAOOtH]Ӗ֖֖mEmEmE)jGYY444@{J{J{ t'u'u'AI$ dffBAFjtG:p6*lTB]PtCuCuCA;A;A;(g1c`~&۽vk-?J/!!!pavC!e,c?f~2+C!j~"Eh 8|8p0d-Zcum6j¥O]6?曛onQErȖdK%U5jTU8dw2cPǠt^ym?6FliҎ/bLt3c 9-sZ\r@r@rr\ɹRK3Fg!CbAHT$6-[gY;v||| D׊]׹/]5552e`333-[@!CC.`6IDATc'nTYf`פI_;xགྷkf{i>|sx92so?j 5v*[H#֩֩Aέ[iҠ000=!>!>!> }ۧ.hkkC]?s+-[,ٺg랭ޓH|$>~Ye헁guءcB~_7ƾƾƾ3}g΢ mB[P[-aPAAYfRG:B,]t҅5}I&UT Xրtt7;w23&gL% uJ]\2~?r!$i4Ile@G: z2~:u(v...}} @qGqGq: ?l?؜9ks]]]ē6m @fffff&vr;nmں5HKKq303030oooXXXf"EC ?e4iNuuu?& ut(벯ARFx_} De"hjjI3o,w0a$B5ל_t?ae. III`jejej&M000赢׊^+@HQ7d;*V*T>?34ӴO>PֻwYo~~z~z~:0 ,jG!y@!!::F.d~}}}7 '~[m%?Ze2tE\r^iJSZߩ@hG;\\\kkE3 ;Nlll...2 eʀ<Є&4趇 0˥_咬@x <Ҏ.EKZN\\\q [vl]]] \>py~S) h@ѥddd={b~1G?|8`p%N'ʿ gKїE<[>pG]JWx:lΖ?0\'(?3kkk`9r8HZ5G/}aY-Zox666r$H@7~.~~~@}S? )vW\qll_$neemBڄ v߶ݷd Es >`3~i0& L)4N;0:rtHXbb\7np_3~*Us!*V'999A7@3V3V (Qh#y~P(P(gdededeaՕUWV]|GGZH-PxUÓQOF=:s﷯(((y5jՀ'러N\=qU(7ZjuAAAxpݽw݃cyAF!$$rvx,X1uuuddd'g+x^ryىىِ+˕΃ZkA!y#Gf_/^~fejrG-wggg rJESߤI}ǒ%r~$.I\ N%sC݄ wrU+W/_# pà^^^ e^)xS:VX?OE6K}.Z׵k O#>ܞs{w9c LKIUIU8033'矜ra0zZi qJ\}4>'''8y.\&]pv':Ntuqq444ȪU5*Xݵku:t yGS#S#S#(X>| xt@] TrPA4i0l٠3t+V \Kp-5 k03g ΀QGF'Pq%Q6G;\5k-T*̈2#ʌ7[7[7[0(cPƠ̯7;$wS ›koϊʊʊgǟVZ6nٸecAۋar6lYA8";";"ǃ B*U*joC 7Tɿ M6Y:2(Ar r rS?L̙3p'‰'v! %h9Ydɓ%a0V+BԧOJOyUW=aXa퇵'۞l{MߩDx O2 0 0 FMBՌW?^FFFFFF`~1022[k[k[kЩt* əjgTUU!E1(cP X4}i:888CRrRrR2H_"_Qf=hϸq?+\WpUW;Sy7kaU/W&,j|tOM,`Bal 6m7r2r2r'O}itJw݆ wC+m[Tn8u8"""~ᒔ$2uLHRd6?l~|} xzzBEԋQPB U/@٦em ,Y޳LLL#} Z0\xm<汾ӊ*p^8444ނ{ A ]Zvi?σX$E~~~4i߹o2K+A q\X[{mpÁssK%nNr\yyyJH>2}$ w8m;6ԂtE"]Z_j}5 {2 Zgl MoS͂͂͂atqPa`쓳O> OٟB]P'gLș3vXakTkTkT)SZ4iӲ%r}S"]ÕW&_  s9>OSuD'1Ƅ zFP7n@](Rp <NYRϔϔ#G2he 8q#\uו^PAKC. y嚗-J(MUǜ888gY~&잺{ Fwm4TUUԁA6m^T0`F iz)(Qf`ږi[m>'}N>ObJV+Yd5HKHKHKe}e}e}]5њh ULVX|c W^a8={" 22޲h·o߾}ŝ;ٱٱٱ՛VoZ wwH%oh޵y]giҞкc뎭;RKm/eSxyyAwV uuOh_%H}!CEϓ:u֪[cRh۰mö ~6m">!;3;3;~iӖ-AWWo_}}hnn.ZT&y?CA>7y`KMMMO%-JZtPeU`hh6'lN؜***PPPttto B@P( 0n~:@ ?l ..U?W\uQF%AqHqHqꬨ ]vڥd2K_XN=\=\="##!KH.pYg#4ߤP?~Db5jӋE'C2kȬ!7o h߬}NWGGGãGяZkeopá*.p5s5s5XXX3G#oOߞGF OK>-$<ː-[n7R{PK-@W,UMKӢE,`nnn9n 2h }},8#qF x4G^x PURURU+ﯼJ,UTMsPӡCIC`̠A30,n=Pؼyas'={ޭye۷߾ܒܒ@XXJ+>w~`غuc($ XaF$w>7 9sV1c;K|pg###^zqkpK%9sx{鷧!d`PPP`>|\(R¥ ]fw XVVV`جYcPLQLQLL$IF  <1x2 4 MhohohoW#PQQy{B*W2@FvFvF6C3g t^PxB0aômq⩊*ǚ5k`& ++E$3-oZO5j ^{w:Ǣ.P 37܄CU>T7ovy.l6lxCB~=!]Jv>>}|xHY.eDhN"G9 sB{{;hkkSo(@ OxT2"Y>t ,2 ʥr)(f(f(fyyy/6_l7o`S)&&&ݷ_HO ߵլ*DW :vM\D 6 <2<2<x 5^s;_QN괠;;;]4J+\\\M&555 ddd@~N~N~3.aaa ϓ@z@z@zAzCzCzUEbH,`#G,s̅rw:ѡCGN.;]^zlllV$wWH9Us %< ;R%TIp;KJ.) C4 {&G,\"Qq"NH~tG`kkk H 'RaUffu⯟L3? vZ viۥmg0`Ml7YiE" OĸqgM7 ^@VF;ݗ#''.] \pLr4 m][ɭVN+>&;O,^nz0[SoAvy򠩼\>CuCxPAUacƸqիWWqPAXaE"ѧ$}bqRVPFPFP(((;CVV.ܻpBX*xU0k:g\pD&b V/ rO'\tӥNNU%&&⚋k. O^?y$LN>9:p=kFiE"?I v4n_}vxRI'a}wJ*y***;wN)I,`X8qą;w2:׹z8.ԋԋTĩSpx݇wCۨQm; ;H$*K0Xn =zݣ76mxyY}e(QVy\ 'ǜsr 86.躠pD_ xUo\qygS>ppp<3xf0ʙ3 窡Zjݪu~G~wZHTL:Xc-́m9Fߩ>>]]]8w܅s`||~Z?-L39Ws"s 0=3cǬ׿^zpvٽg³Z?kt_ΐ!9C`À 6 { [l [o59jrTiE"DQipKqKqK;8 XXXFOoS% Yf͚5 |-|-| F =;H$g`LEuZ6`#&;L@RRR~S)섻vfff fJ&.H1j\ո* ]=tೃC'zzz"2=dzV]wu_㓎O`؁as{s{s{}]H%.Jxxxϯ><۟N: t~;fw юvc+{TTTvY9Y9Y9%~Kx%| Lz>PٲeeK`5Y)HXSQQi㦍6Nl m m AZ_Z_Zw}k_[ !H;sa6mq8j~֛Zoj c돭/rNd}-Ho"Sk2d5;\oߚ醿Κ;k_38;揙?fx*U8ɜdN2[oaӎM;6Z!Bj@>}AQUQUQUGM$z *T~бcC/\ Tm6 U6TPnչUVi4y}|*l&>};4^xYe ** H$qG1UUW^AGG;TS`_o5knWj0s2iˤ- {;wM&Y 5_|Q(D3>τ>:rȡ#K[/ʿ(`/w8YpdXֳgYŚĚĚ@n= @@OaGÎ?T2Li< 0Q$3τ٧goվUVAO>!!!O<tQVVuo׽]nȹ W=QsJϕccc ʡʡʡ>*"L<e~ = ..bp^_{u'N֝ uB0F;F;F[t?BgR5K,UjUUV%h:霦se^ʽ{)0kXװ{/9w.\ i5ՐV&Ml0?n~86m:T*444׀T7nRJ4,ѰDCK%H$8 csz*AYd5,kXְ-tܲܲܲ@PPG,\"8>u||<`vۡ*.%\JlllSD"џ'^BBMQNQNQ›5oּY 7,(oۻ.;H$q%/LV^V^VdeeeӗM_UҪUIİİDXigDψ zI H$01bŌ666'~SO>:\r*{jNSH$yr: V[-[l]n/O]ѻwEFQiTH$>}!jB5ڇڇC*}U+\\\ygzgzgԖS[Nm 9^s}tmtmtm;H$5}!r9-$nLܘ-w?~eSgL`Y v2e H$'q|!"*GT 2_*"@,`P!TM`s͟}Wyyy̭3 O?Yd9lږkPXrae}H% g.88SSSq?~OO+<lݔ)TKUKUwd"L)7*7*7 <`pwjjjJ}.C١e  3ppp}=H%>S'nnnp=z޵|3O<5D1=Ydȟ?-SD/X>Sů5fkրHU%VX'LOfQ͢ZZZ9={@)?vvv ?w*!^BLmiٖfcVY=foSI3'l  ͜͜`ԸQF }ԟ1cCЈCkү O>z wY'57kn,X<εk9ׂ;oLG2_|m 0 |/DOI<».^zS8q3^x1$L<VkWkWk!fnܚN? q q qp+Vڭ4(,,3Fd,Yn-ZAJɕ~UW7z3 XE,WWWžu{YpRH=/_;ɏϏϏ#>lڳiOp,XƱL]L]L]_6pyxT}SM7`TǨQ1^J[F[F[6mHgggZVdή]n̻ ... vvvP1bHVj" U{W]5سs=;逦(ըTRd㒍K6cccxq!yx_XcŎ;***cccB )lޚ5{+Ȼɻɻni1i1i1mmm 0e2 ddd QޣG m (>wg&> > >mNԘ1Sc tvҰvJ[Ve\\\arU'WԀԀT8^x`^yuӑ#OCУGA`L=gs5j9s @ѿqIUvP;m)SjԆ;4b%VKX}/kY^/i'wߍQRGgaނv.۹ 64`CHNN)SrO? VgUUyVX^c bn艾bD]u[ͷߙw666N   FeW]Q2gf,ޛ_1b~̞=3{ =z,~CAuO!C<@nfnfn&nѺEдuM[www(DPUU\!W7o@p|SO>ԐRCJ ;6Zڴii})~0!TvRd@YS}XI'tԥԥԥ`پeu;opW4)]!|B8BBB%$H|B)A2 OOOnnA|M?);Rv@[ٷ mp[F%J9s I^&%K^}d㯃*T `X&c tNҌҌҌ #1#1# b b b@zIzIz n\quоооG=p̽2@t@t@t({+{+{CިQy kP֠A G`5^k/?^" gBi4P*V.]l;էgͼy7;s̱3!!!n_}v&oOX.,Caa!W\ _}eCy BePBm!nnnHF20ht#rt9WU*T 3F9vX0I2I2IA9rD~㑎G:R2J7tTwTwTi `L`h*/ 3h (,,DH]'}N#m>GjTjTj$$$A<[-̔̔L=<@$7 g"VUq[mapWUfCKK D\q+|ÌF3h>:"ѿx 3ìf0 jh>}S555{ջWCHlHlH,L6k]˻w-}DxVB?sOߩhhh轪ޫ὆ރ'N>.(b+2L!SFFFp'2hk֠-t=Z hV.Zh%sYgyyyP\R\R\wOkХC]:@9]t+ ܩvڝjNkkk!,(,(,TcUcUcJ$*^ @effQIF%Dߩ>ccc.]P 0,iXҰ$Y&~wNqSN ng΂͹s7#lV#FZM M M 0b8]pt,JX(qqqi(Z"D(dn"{G uuuP_ ̖-5[!6 KMM8880n\ݸS}~Y㯅Y f0&&&5\pz8;,ۮrI/'Az띯wIÓ'뗮_ΰ⃋¡r*}w8}8p4xxx5׬^׻]vzv١QQQtH ?$8u:>:>n;6ڒkKлл|$O$O$O="X KaX3=gzN}Ʒo Kl.g֣[n fs昉g"?JXLa¨Q 0bXŰS{9993VXư⊋+BFFFFFSD.b+r7n } } }T";;;v)kA$ A t=zu}VLʝ; @zGzGzGߩDYUbU&:Ntvvv6m@[{+( ʙ35g*())䆾SRӥKaLȘ1!PV[o|h|5A,G#&IM$Q( #GvJW_EA0b#C`f`f`&}{ѷd:ӊD э֍֍mmm0\ap0Yw:_%C̿1X"gEd^z1 0o8pCDśxVhM&ZЖՖՖ;;;}}lG}˧/n9@g)yʢu{u{u{qǹ^D%bF[_[_[G#[[[;S)SL29?anb+C݌w䔓SNNO>;"~AAAߕߕw*ѧu1kƬPS)6C iO~SƗ_n?et3ѿX1ۯۯ JOyRpppX&iMdIYwv5oׄu=_[wx&7v B$%%J B'vbLWOWOWpZj%d(2 }B$gѠAmmm@/zKߡDnnn'(Q,XXkUUVɯɯ %bF*\,Y@ K%;S}/^=tۭodddK/t8RRR||)---`g˝-wAAASI$mT ^̽{ >Mo4:^u]w[yn幕p.\ڹ4\r˥pE".7%%%1bVŬlu:[ Fk;&\rA\\Xb;"-- n7n݀1cǸCe]uYgYrf +~/:a>}6W>_AdPdPdՏW2L9i B B BH$i40la°4i8AQQ L1lf3AG͏ 4 A䀪!TV*+``yyy"XYY2em`ɾ}'p(P¡Xg$Q(IGM/b+n$HyRHCE3Q3Q3Ld&2TUV[9}`gg]uץpXF4 d$#)%-x b:tw=z'3q_}A4yyy迉PfRHRR_o={lw};XUlU^6m=W{m)m)m)Xox1\9=Z8G~?5eee4Xױc]T*S),GҫҫҫqsF4 #G.g]κ_|n5p(Pء0B m!bp-Z5w-$MhE-Zg}z6-[ӍەoW] "E΋͎6; Fw X/nl̬̬̬wNw-[ᾆN 8AVZuky?a;k}732ddd@Qz;6Km]tҽJE3fpvvv9X̶m1Wɯvkح!x\ ̫W7??efp%8Z(;`w僁~CW+ƂKӗ/\RW)8,vX.z]fnfnfn;whnb;X~c`;vTvvvQGMAj ,> 8t#ְnq:7un*ď%~Eg]t((H1l|24~YgŠ +-[`,Yp[NiE---vvvPyTى;G~Gm6)))g֘o7A 'pap9yâsN˝쳋Y.fn {2⿋.X5j3ДҔҔ 1aV?^{ {r 7 0.m`=Y%bF" "VܺusƆЈF4Җ86qlXjզ+6-mZ@x~%L2k\>>/7=(h}sH'tF Pxrf=p{% =I{DtKtKtKjAՂ!˒%/u'u'u_WYYY''NN,I6%m * B֢EY!A IBƮ]!AVP;vBmAȺu? L(P0A!}I% k!;););IGď!)))P`V`V`&3gV  y B{AEE寏k!},m6YۻZk}UVZ@A(|S  N䂠~~~'].AAPG,8 ΂'oAPWWI ' BJ~YoAX.x] )S0GT.* $N<[ APPP4F# GaUǏÕ+aWBR"R"R"AMMM!ZkEbTQ-azzG #PاOaA(|] τg³>^iii ’K&.({t{t{t]џ#b`V& LPB(!(N;$uO=Y D9Bߩ\YYYق0jѨE ?\ 6 6 6_I [l  [!zZ;vhmARyH!]2eAgp}nv SCN 9%w}w- ;v0YGf T˩S-W\3;OZ?~j-Cg 1t Hr#E~Dˉ-ao~?Vn.jjjK: BnV);.︼ ZjիU0>Om|2gϬ>3bʶmwcrw/ (Ux}` Ѝntm6J `t"fu E;#ETpO3KT2E2E20cfw;!**A?/^ˬWI/I/I/0nl;]YYH!:թcf $$릘bZddd7o:5tj5h^9p[ lll?lTZ֪AUKUKU L7?I<+;%?K~䂢L?x8\s-@__t ~JJJ#FFFW_~9v(Pdwewew!~^y`%]i_i_i_ )SCOOTv*;ſ \9tЕCs:tiH҅t - - -KA._44%%r.]^^^2geJ0iӰ'$s[/^l=066U*KY,U C~~mqP( 9r<EYEYEY?$B¡CDAs&LpJvJvJ'O\@A`A`A ^~z`&_| ֽ[nĿիVZޮV[A&qAܜ9qs ~C i#Gv}mW(++\\\p^ٽ2CS666hG;ځ68Lq0rx& dnd9Y(=J011m-m-m-%3Jf@|J|J| @yI_Z|ttt888^kwjgΪ(**Bfnfnf.X޲ey yU>+}VG{A-[N@ZZQajPwtu?Oo͡ %cY0ky]viۥݤZjM.U\T1l:mh>ųg;wܱs}0?ޱc{ +,r=*CDw~jSä*LnʹwbqK.PG%z@\ݸqu~o~3|sz);'";Gv lزa t|mǷbqG1WqƥCͱRaJ\u[puuru* *\pP/T/T/VխCg N:y$|znL"K/86mu3f-+ ѭG݂mj&PNVNVN͏6?,!Kؚnj=ڳ`Ata=3/-t_nu@vM5m5b+!TNR6mGh(5J,ZR<+mmP,YuYuYuyŞɌ&3̀[N<9@P]½{ BPzA`ѕEW]ÛCmݷuXi4ViVϲe? ݴݴ m~`G,+ ^>fpl^y JBݜnnnxzz]w-/_qƵ n5Vc;;(]л7lVv[ ú:+ȼe2o}JIII:ЮCaظaㆍ1'bN*Ϋ:3%Z߄Da" 揘?b:t<8PPPAwe wjX9kkk,Eihh`뷛nvXoZh=pIrIrIu7u7jwjwjw,D]u `χ2x{נԍR7J(((ѭFݠ;&]tm$[%[%[=*a-kY :TsEaAt5TXS"DԉBG}~a?|:Vr_Ͽ?>8tnZi&jWC N/zOQIIIA)I)I) }eІ6cq⎁/}HHH@%8>|L>]}Cͯ(xG3aϰa?V!B<hi͞1VG 999ۇ>\j<]w B =^;x -[8 A'Ɓ0~aLLLdd`cc _(_(_$H"GGGnnn +y:[i Șڛڛڃkkk.}   B *t+W8: iiiCU~U`ЙCg;K,Si$ G>}l iYiYiYNJMMυV Z1}kï ߜ7ghN#Q/#Wuk0v4v4vkAׂ:gdaJYgCڛ7ioo ԫWS풉no! G(((voڽiw8l͡xN|Bu^Wү_I6ژjc`vv/,B]O(`t =ZhS}z2:dt+쾲;|p0#Ï@MM 1c8Fi& '#pN9 9'r@=\=\=\>~aeʄfԚQ &Mj ~UUu-ZA wuZA<i\>$tI?H]N)R8N7:t#;'wN.ȪU# /|rpttuZA<>Qzy'[|o}2r2r2r`ӰM6 g 2dub։L_&VG`fvAvbvbv"\\\:Շ+W[׷o]H4 i̞;{( |H'© .6l؀*UHtGAA][Bn  "D@o{~[0`t肮 K'uvSNNxNxN8laɰeĖ[FJ (?(\1'C>qУs=:W_ u4u4u4PQ^E=]EGEGEGA~ ɮɮɺN)!N!~fylOz<| ohhh]HRiۋao׿۪o {10s1s1suZA q 3өqƝq?~]ש>U*vLٙW;v.ݻtW^exQS >SwB_[llŠĪ~ϡ1~#봮ӺN,iY2qmĵנ|M71iN+A}*YTd\ڹs־Z &Lt_={`fǙgv7 nߛ~o /\2p 'H\{m-]tRP]Q]Q]).竜r"kWNN69l3g4ڤk0؆c t= )DDDDc_;;;n68/q^"EEE; p豣ǎB-TNH'ÓOB҉AEIqRV!Crhhh%,mYR׳&.BBB5kzW_ACC{G5j3gH?_А!CaXaЮVZjѓ!df̐Ϋ:GYeaRI`aaYADikkJ>+}`nܨQ;wwo_hYhYh ]wt}F`x_ٜ9gao E"HQ:Gu 7BdNm!CڇgM3w]uhwݙvgkӮM6͗zO d&3ajj ޿z' O0VZjE+h,YtI%Q.A~N0*߫|VyZˏ/?8*U> H Gďwߙgn?84848.q] fϷh zꉪC$ _LLL//a} }&IIIhs9Z<3A ӄY&BS xuտ޿T Hp.\̹8z:tgELEPJTV[ul1]?~6,*䢒p3fLxzǡD J4ӯL2 ݷvZx2 E/^m-~Cu]5_gC^C:R<Ӛ0}mӷA1_| PwU{CPfPfPf"WuN9Y$4d`PTY__G+‡L0/o7nLI<Ǒab0xc(;f  k/k/kQ1D^o.px3K×/g7nP7n|x tZOCKZUmUUU\rʕJ|*e— _&o9 ΩΩκN+§D0/ю׎׎7jިy90XZii {M5;wujA> .ϻ<ZVjZjtP:(al،E_l-vǜ&)ɚɚJ+AU^Wy KlvG ~}zQGyx7.=h{ >)|Q 1LSҧOOYYYPM6erB -'{ gz*2Yeew 1LS"E,}~%JWJU%Zbk9ns ~\ 2Q?鸧㞎RJ* Lw6q^y=̬3:`ˮ]/ya慙Yg垕hA&18/_ڿ={fMO2=GYM&BN \s yJП ?Q?$qXa*W\׾tjzvYfGm`{UUU]φ $VwzwGf.37xlnϖ>[ a0a`oo$?$dtR٥Ke055w}.Y˳-֌[S׳#¿I0wkb‹ /&@-T `;) -~Yv )TکS6m~[piSq/_oC 6Ox>s8qn d&:'tӰqKKK~_PdPdP$l9ؖcp^W{O?Y[n YÍ=760o$VL(~LM3g anSykx὆saͥ5\ĵkB @o%N{/e_ʾy*ĵk2f| O}*@YeYeY%ub׉]`jhjhj=lгDDD999hUUV`\̸q1r\mVYf5^V{YefjWծS/J0.a`9`?~`tHE*kz)l4hn^yfplڱwkdҏtD0HۥvmovTQitytѺNyi9,Һޭ[{\rp%y6wܵs̜93s`˹/a,2e Zkv.\9lkֲ-GGGBVͬY5!fW~_(SL2Qg.ڟ?(|`IDATk?<˃L^3(}!PCkkkvvvN:W^=xu:u1cTGHT5*2.e\ ;7vn Sևą kE׊1#zzz;@NNN0᷈&U ck=6xt 'N:,sss0cc={\gxf ,_8v߱~puu _#KΔ);!\sP®] ;]9uhzjkpttYgCغua?{: RRRN+'q_-[6 l4W:@a0P@=+WnVABل e}7z'N: |\)D$M8pl5[ ȿ!yw]hQEa||z:o8<_ȿ/"(`Hi4b2KpYeS}B1iP}_} '''CQQO9r^a7uououoH4L4L4)QJuJ܈&SHHȿޮJ*u)m5jnj7? `ȃN 'ν:\e\>|ryH<+yHߑ5Nk iii:qujPũTqWWWމމޠQŨb׋_R:tLZgO0y{Jd`j]Yk5.e]ʺ[Vx||u"pYO~;v={,X=C w~g8+ܻr08fpc}5TʩS V~ە.] `kրpKW/z6]L ''4k5k5kEˋN0q2q2q?Zk[k[kaW\K/m:\FJt+ ڔkS ת_~Pw~:\vsavv$IX]v.(j+j+j 5jNJ'\3fr lmm{a>CP rF4 =(zD^rKx_Կc1阮+ Ŀ,<,<,>>`ll4U\s̻3μ 1110/}^tH I I XXX@GGww7oB_H;v$d}uנz߃Cvɘ'cW%^xUrn8:::g{;fw?WE ')SܡO/_CCCuJYfd0+bVĬȮ]1"}딂˝;+wOCCC LY?e\׹s]yd摙G N)(`yփ~~~7ho^שX&ca#4ld/___|}S # g.#5#5#5 XE"Vש:cPAMoZ~]_w}]8v0`hkk: 2g.CF`fofofhy|Q:Q>s+++`pj]>4VY 'Xr7777~qc2#dr2f1n8)G!|Z,d!9PRm趡]>Tххpb艡' F' @āpYvYvY{Ao=t^Ԉ#ϔ+JP`APRRu*C );Sv•W^)[]vfvfv&A173%ՖjKAm6QB+ħArrr7npi{^IW?>heʠVz+(O'sL0 U*H@6S6S6Sס] )-)-) L:t0T U~}U`kekyFף>}~zԻ#8*TtJЕ+WV[\m Ǧzl*Ll9Ėő/|qKKK\6lp–- [ ~|g!ohмu$HȬY1"dxexexA&E{)RAڃi ##2wd999999P +@)͔xq# SӧOoe˼ڣk ]^wyu=z^ vG펂F7^o yPA Wү_l6-dggC^y!d~~~ Pu: ARKjI  +<dI&p"$ @pV8a`R`8pt016161f _ `wύvp Px(<ԥC0ALf2hhh@s!9 9 9lSlSlSTTT ( ( (f͚FW]i4(++Tif +3g~WFVFC&x@だlll ,,,PUUY,CZZZPXJa~Nt+V 7o AAA Aȟ?;6BɬY'!mDۈ AV=>{<łBO"""0ed8=vzG8pw:.U]C?~AI **?Sm6f{nUѫ"f[mNss ́ppp{0bŤ XXZsÐ}#F x7ݸw 33B-ocƾ0hhР!mO]Jvz'>}h,,, {&{&{I r!TSUSUS!si̥u#F 58k0O6{m3S)"K knܬ\\\aaa٭[g(W\rq`kgkgkrgYד3]]] 3]ft-^[@m9/^=8stF`[Ͷm_ߑ#Gq+>:,tXKS.f盝ov[:o0hɠ%aaagásR΁g6nyLLLbŮ wuJ-[(5ԸRqS)@n![8WIklll OxDDD@'!$$/_ v'N؝J*UT <==999]]]fG׉S)|||\9h5mmm ##˲˲@5 000N~Cz ͞7{9eee*hL4&PʕrN?}q'O(xxx,T* 'IϓD)N:kڻk⻋.㗃eee$TNX9Zj1((1ļ| _O~_ {i2wl(o jP`)rss!Or>{cX˓.O< U7UTSex.][vo kWzk^bbb)|3Qa=ܠܠ П?M(D(ӣL2= tJҐ,Y30g|hohohoEEEx6lk֯ e,c ' }\>3|fLx7w#!uP~%*Uv&4Yiggg!uF"cEƊ (Xα#|}__fgBʈ+!cs9VW^ x5ӻR)E6?;wvop5u5u5;;ٻol.\B2C2C2O.a]ºi6y]Pŷo_(^xAII A7d2_/b)`:t頢uZm}QHY eJ{* nQF X~qExVYgXa0 3]׉;***(_`/l" ޥ{] p}}gMM45bŜ9hhh=/L0ꔮSNi0v ca G'4EΥ ideeeeeA!-- rnȹ7pcٗ/{vY]]]AAAޚ5{+ 4l6l!!!p횷kg]~*'UNmM6 Fy~yz}Iܓ'qt-O[:nu UlVG=C >>> /ݿtM?~4֔ZSjMu&֙X?FןF& l;v[l&yMS&OW<_|E8#QTFQвl˲-˂7XQ(`E(  P=S=S=P:Eɬe2kp}p===&L6Kьf;L6L6 -SL]a~lYe͖RRR%;\3HU*R -Z H>SlL1`nbš K0i '111{.Bkxl8';';'CL~1˴˴@TB1cD&)Oy 꼪l-[4&jrVڭ[ f6utf XPTڜnsih|7I'p8pXʳ+˯˯ɉ&'.] z0}L#M#M#!mv춿a>'I=мy 5kfW*JAi4VHeXXX h@_ciğ 8)FFFPǻwo&&&[nU dؓA3f̈́UTPݝݝu[hnܢ9d576dJ)RlF ((4kG5ЉNt*?WtDՓY,@<ҒmmmSE~ *H)R HݥRwuuuV[Am`@r+@Aгг|FaT'pÐv0E΋*jUԪ(hti>0ِfC}O=O<$ĂL1b2tmN7>uSϜs!88455ݾ/DTQ*86ؠc#G^ŨQ#H5+d̨Q,}{K ˛.v5jUR KK^6[Hm<9,Ґq"D ?~ uNB #ĠtttӢ列69mr+x" ::<<^{Cn=!vJ)6mB[HR'Ei} >|rR9+|V,0119s;A:$A} /3/3/cqQ;?=gL0?UOOOlx݆w9ss/3,YTXo~...`hhXݒ'K,yϦ=l Z.   t=OO?o7v0ߏ/?߮;t1bzF >|TEMEMEM033׃i#F)S={fff`ff)!)!)!`0`|̳̳̃Z[ |iOi;v-,۶l۲mСA@5N8 kצo 5 1hӳgO]=k5Ӛi$$$ǯ===i}k¸ sdɢ?L`U۪Um]8w1h4f3777b! /<?AM&8PPPwwwdd]({d:u *T6 VFYy%y%y%k0!dxgxgx&$D%D%DA VvY fff0ܼrAW *wܩ?{".̙B'~AE?ϟ?'X b1 (/'^ s΍;7wz:sY粠u0l43XmhC!g{`e畝WvRc `5ր;CH!O\b‹SSS(lh435353}7YgힵzO=t?~>b|9s.OZ?iSO|ye~(CC/^Jj%drTΩS9xzݧwijPXXZj]5x] q O f$Il0hdcѸnvȈ̈̈7O;; ,hŔ5\ka]ںui`jj VfVfVfpwCwA};<\э^x}5~r\w-fffc>s,vY*:333u؏+Ⱦ}% dKeKeKzYdUrYe!zTQS@,K%s`5jsss;JWqO=g\ϸq|||viG /^m6PHSfff{_#o;%(T2}WT3fRMl;v2())d.KﵣDddd_emSa \r>RkW u8/ӾL2Pʭ[)7жҶҶ:ґ?OӒaf7aՏW?Qef@^(/)Mi~~ďxۇlll{ߡ/7^n 6|pr˹/˳/Ͼ3μ: ʾ.k;O<G0FO=a4}ۈk"E&M:::&q;vyYga]SwMĴĴ4777OHHˀ؀؀XXvye)>>>ە!C5k::EuZ?{yCv!Btrɐhhh!=CzדCuu5dffB2$i+V.I]@2E,!?:?:?V[X*Tb)Hޒ%y J $IxlyR=S=S=!R}YAuu5/_<j 5%%%\\\č7|\9[slq6mV۬ =(=(=f;v v.]zAۙ!dɔP{=nH1M1M1SYNA{{;XXXEEoOߞBCCa}!!!(1Ĥ***e͗5_VPm(((3o&_<|[mp%_S?~ (N+N+N';0(Zv@zQأGa __חCCXEf2<+xi4菝Y&MxÆo8 SSS`Q#N}'}'}'~\q!دcw>|@W]͡Ftѐs=zuq AlZȪ#̡C3B m m -xxx@i <j5T4hRfΰa q:u)SQϣGrmi@Z#-GZ7|||> 0*,XI&==\O ZRuI%`lblbl_ 2/2/2Z,j"s΁: dXɰ0ঃ yyyСb*III"dnܖ :0èz:pY;FwS;w& hhh@ڽ{i@-EúFk/4R?JTTO۟ r6&nr_EA#GHҐGC y$IW2d^x6$;3̸3ԪI&Hҝwߙ/I gnqF;'IGv$%Uɪ|5_H000$ihhHҋI/&$IFuh$/~⒔<}Z5:X#I:ؖc[$).2.2.R{$-6[lL&YLd!I Z'u:C7ho I>}$ejZ&IcǦ^r9/[x$:W5kɹ%=JzT*J%1;bvLMM *Jϭ[C&W^=z(lm&?oWidH:;u6Κ5; Nj'...@jHjHj L6.J] NNNKR.I0]0o`? тc:u`Ygg.{ Tm VsL15ǀE预5֬Z mIے۵n׺4kܬqƿ$$$#XvfٙegZk rpz?^QL^7^t#k\׸_JG84fӛK~H\#k׺Ns ?>xLLLF,vWd^QQQR)RJ%+8VZyz띯!""zi=y͛7컳BfLfLf o 90^{}AVVVVVZtmѵEWp+Vڭ4ԦSNufW(ӧL2}jl Y*EgEgEg=Cpvsw݅vsVkNk:e2XQ Ki'N@XzXzX:\/~W/_$I֓u3fPovfyyyG|8qb[bl%ߠ~ 53jfv5U4U4U nԻyyy -[e[e[e[HuHuHuCzwЇ>`jj zj=y)R LU* l5 ǬY+ZN__R˦M- 7̮]7G_)Sn܆A 㷏>[o+W,@e>}Š +*E\aDn{OUMhBPQQs s s'''U3&({*{*{_$ ]w%mKڂ[m F-]0ۏ}O=oxaxxx'v/< y0"G,r~pa#QzDPv`فe~v`cc23Lף@r!qkĭ6m\x*U(c1rP Q Q 6C妕Vn UnWt-ZRRRt=(`/d~98q<潙f0t5t5tu:GQQQ}>|y o^yZDj!!!2VAZZ5(k.\4K\,qlll@ QPQ(y7y7y7ԇN"(//ԇ .[շo!jRAtv vQE;+vV,HOOԇ5WjwhhhL2M4,S)lD~Q1_| 36sv\\\>SjCQQ|TQM z#FWWW0dxdxdx@ww7}A___&sM+7+7+7lnܲ962md 3\; wPPP0jհ+?={ 2L+ӂ)ȿ# O,< ڶڶڶٯٯ .###777jjj'dddCCCJ=z2g<*;uՉD?\8XXX5kCߥK(ѳD=\e2Wqqq z랸CEN6;mpppxẇ~ǚ'N3L3L3 `НCwsi<zٮg;035353w W!H֑#iiii9i9i9+WB/P=R=R=lPnP`\`\` ~[-Z@JZI W?k']  31c84?*zUV&Y9rf+W`jj fififi`dɦVF77x]8~Ӯr*6j̪7ެzN%Jδi;aVNOC[lԳyyyGОXz m6$T KR:0a W|PB 2 IaR+k#k#k`;@vSvSvd2W+d29e +%+%+x&#aGŽ­ . {]qysx|Ƿᇖ?%X߱c}d %Pb q QM...`aa'O:O~<9z}pkh{퉶']vڵ#g#g#ޟ  ɨQy3/g^Gr\-$)֯Zú몮  >)))r(s%I'0u4Wrq/B 5*u:R Upjǩv懚j s6̅ŻZ zw _8~UU9W\|κN%Y'9s0㣏0Q(`"Expx#DGDGDU?xpdGƃooo{TQGooo5Rse2w]&N! TY,UF r&aH^N'_o*2lRVNY .x>|uVq&!ggg9sztx ubro0!{x{ (Wb ^^^PCee82>Q8s.\ :u`;( dZgZgZ:ݧu_Wٛfo ._4h >; =4Z. EƼyaVY=g +p~˾_:+On>pJ}J}J ǚkz)5kZ޻{o(((uZAw#0oa4h;菉bŴiEk LЃosp%Jpķ'=`D>oLG읰w p#FtϯXֵkYW>ڶk۠嚖kZaڇ tV>l kϯ=6m#GN*;K9d&^{[/n"5]kק_uZAS¿ꯂ Mū^ i}u_SS8VYg .ZP.A+++LX0`4A -[tIvp7[ny/^8J(]ttV> LW#O< qjՆCv 1]]]tKJIJIJ2X>e} t`[Mn% Sl_پ~C*ͳg5ς36éb*52bżyy544]m7(}} (7Lq2E׳+6}]>oe$I!r_ ܇#<8ھk.XUlUUŠϻ?NΝ;i4E())|ZRki;;섯2%5KjʭʭʭUA/ 5IL/|v 5tPxtG7iӂE_~vgǻ^IW;Oæ[nmp=kXmh[nͺ56mn\zz驧R3K M0A&6LlS\Lqn: Moz$c~9HX"r\-{ݾwzwݩw'[-={ڙ3ig5A@0A,Y4hSM7e(QУ,[4hI$m?&w?ץ[X ^y`mm ;w8, KDtJP* h A X>6uaSh:鄦E{'攛Sn~LI2-r[$8aq׷WTTM7].&_LYᗈ&|PW4^ ;%wJ]vu U:VX#N8/T_r% VD\ Ùd&xxxAEUZMMM u=+ qQ&II%|KfÛ of͒%2@ @@@s'r|!`ll PXcAr5/U:UTT|PA`ĠA]^_" QҶԶԶfTSaN@)m6m)SF gSϦ W&9Lr[[p +A|||2hjj&ui4Jc]>v9 1Ɛ-n! |w`ǩh޹޹޹`ccmmmPΰa9C(YdtV(`G|,|,|,`ӵO>mYg8v]uiլujAQ{s7W%*SSSbbbbm(VtUp>u^B0wW?:TU GGG6k4ѸF@)EԍSAj%ZAcf̀}c%!N! y;v@dȊº **LcӠ h ,X86n;v1b0LA#Q10b (lQ5.k`VY f7 !RH&4A%q&|- [.\2w1b{\jTF *C [VB 5/jSں E ?PPPAyS d YIYIYIXklHRTZ6k٬%p3Ax(`G%}fnԺe,{QEqsִYfMJ[М4 L$)I PSSE΋ c1ԳgQdeea]ujrelؖ su=yL<_|u vgZҒ7ހ^Oz=azz4]4]4]͂6 ,$$$]ϊ |D>*OB> U*sZ'N* +*ZSkkk=E\(|rMsMsMM*7/^^kRI&wk]c8[÷TAYϋ(`G!olؾ***J2sԸSN;0&kL֘,8TPC5ZZZ]ϖ |D> b + + +0h>|T X-ƿf8vcW@ ^H/t=kiL(Hz" JW(]tPf*3N_aʉ+'N_;} xN)&Qޛ{v=]J*=&dMȚgz]w54_j| CRfRfR&={Hש]Le7nR|S|S|uxN*ܭp]\irɕb.SwN9MMbEF -/[^Zmkjj‰'N:4ܞ~{poŽV@Xza k|pY{w@wLEZr\.SJL)1Eשrm,rn9Zk}a[mŷU^{.Nr; " " "~}i#F,e%Zʉ+'ޯ gs?~ 3C!$Kޗ-[,=: H9r6,4n<dddt)nSܦ8T8\pðuNWH>|0 TQ9llluihh@ʚ5)k '8'8'fz FQRT*rouuuP{=`oonTQۘۘۀFn#y㷼-DVYvn۹m6hֿYf7JƮ]C&jƏ?!GCBg#Fd˒-Keee.8E;E;EP)))!sCP|Z5PhдӴӴ9/r^^kz!QGP[[  ^#0λw9*c~f;v-ܹsΝ;{o(;säjMp:G_'N~ TĩSpGA';O<4oqʇ%QK_^ma6m$$$/n㻍!fx -Z.|kqB &81S^{<*yT(83/aUW݆mFki%^ٓ'gÜsN9[o:W \VXZab6lt&|Nj'fPֳgYO]\NqӃOO?6TPeC(**uʟ3lv2Cy%畜Ci}Rש9ŷR| ;s̱o_ʨQ+ //(dR&Aljljl*)qĝ,Yl3hɃ& iKҖ-y;vmH2(e7Q FAY!U«Wa&dBb`b`b db^gggt-Z5H["m$uIR)%ŧŧC~t~t~4///7߼M&ꍮ7h*T& DGGCN9!wTQ10c`@HHHBBBttt+Wfcw1 ;w" 3@/\/\/\שyG8iobbb`K/`KŐaaa)))0`Cmemem%+WL?xcM@Sz7n݄d$`dZfiYWM&UaF~7;0J0J0JY ӡN:444W,Yֳ,tRwRwRIE&a ޠ\\\.÷@S!BDGGCɋ!w}auVCGu}ѪѪѠwW]V{OԧM&HA}K/YzZiT ,hf;v1ƔSG6>"}D:5rk>xc]ϒG`hт&M|(=ҟZm'N맮T7U7U7!`RIz*TKoA?A?A?2L'''zϕ(`%Zjj;0w`@(Q£SfVaRI Np.]h ˒%/ls2,޻x0EEEgG\S%B ᗈ&|P-[6n6n6n`4h'x$$$F5g(ݯt`ws=N) QJoo/8UrT U:ՇϨQ5j0T9T9T _ban~(P!]u1cJǔX)V_h(`ALL RSSa@NQ.V.V.0ccc`n_WNY$_j~PPP7p|v۱x㝏w›7o!qh Cxo-hii*ԫRp/C̸q1RHl(`A "E knܮS}SSS4kڬix2' òeC !*!*! }=q_v\reXcUSCBnbm0LrϽ{n/g䋒/J‚! ,y8¿L0აy'NF|:2,,,˯Krߗp;._1l_پK'OQpSN=; 2gn999=={zt)Sn`|ipPݡ:T_y|`97&V>ˇ׷^z} N:axt{ @`z[;o}}}~cV"E-&B΅ 9b:u\:սW^݃dhl9TOWv_ S{O=7TTTf˛-o9!9!9!N)|DtJP{]4`zXe:6pi!qVY0/`^< uJs# S8u: K*,FFFN%:ôO;_ys͙7tR\&:Xlll0niX\222I'tL?l{  @ Bp-RšݵC!h,$Jvw~nox|[.-gNә9sƪЪ ΦN) Ĥ ՅB5yyySI~+֫WØ c.K6yyAdzdzHO"0I+WƯ@uNuNuԩ$bχ>sX۱#,踠ゎO^:F*`1ELS@LU:R)y/o~yƵk-|ܬvjN)T&_AfffN%P222PCmmm,lp r.] 9xa0hfkk@ N$&>>>ˠlllbT?PK%ԂfunFr  C=8oC__vvvzo$ILkkk@MMԩ$:ꔫS&/l28܋s/`jj c񇩾S}«SN:eT$&UpfMPPPcccS*mv)gp{EAw[lNٜ_?;P;0N/XHLbRc4|||Lixex{{3ujB*`ҟ֟֟Up\MFWIZ! 3<N?=_>RAǁ缩BbjRkQ+jEH*$Y, 84ph}V_Dh8l8l8 ?ʦ I1c M+0 !CB8z艣'lG<7:=^^^KO,=c&8f"p{ зַַCz% 3)3)3 <<<ܬ8M& sߣߣ ((UŪbXb=,eoޖ /g΂F6A1D1D1{{{ L`GCzL"Bf!K/yF}6QA7Y7Y7sϙ>m¶ &Ĥ9f07cn\i5Od$e$e$ATQ-s/Zh@յUV] kܮ1ut\nu ...5kVVV Äa   |yHMM BWq_}I& >>>0k>|.ՕՕAT:}/*f1f1f1vؙzT|RԱǚkC</!bw׋ +&+&+XbMڛ7in/Au׭_9~Be0fY`===!="="=;wU;T;;;@%喔[UUU޻?t QbRfW̮]!!?pJH+ 6p|ddd2a˄-gn6æƛoj mj٦&8ʆ+BҀK ]bm?[z~⚋k.^{} )^S{ TU> PT* .vBiLcSG(T*j ,׾}]B-jQ7'N3!)4)4)nnnDO#:2 n~ahnhnhnmzw4zIYljtuu^{ElL٘͂͂NjPSG===.ֻX.]Wî] Cn% MH;N?ϥ '<3Ƚ{#emuuuӞp~GbNMSMSMS?+~lr&pr}'AG!IK#G]p2W@'O%K>o'g3!dbĐ0-jZԴ(84CS!PT)Skr /7\*\4PF(%J.~]. _,bL>ip畞Wzⷓ Ĥ,C-C-Cp@PpU᪢WWWabbſVϬY=VV[Y ^}[xxᭇ`mڜ9>-}Z4H4z]/Xm|9\-ZpZVۙ3mg'8p>|[5jG9͑oG} 4 o"o"oUͫ w]|7d*U_~иi4n +_000 6PnC9r+!_J~?m~8_|!z޸={of.ԘWc^y(tQPhwݩv{ Xtf _i|wy{o=۸o㾍j2+Hڜ9iwREEEv*T >˽{-G+Voooٝgw'pJؖ-a w߱>ԯYfiuuuFh\GGGvSnVSϧO==c{ 4if O?",}!B899Yvg /+w5xWB /TPoZipI$v'B5u5u55tmVY]ϻw=m6l4|B?yɽ{ n,[÷o雧ozyImۮ$ž(rl.\ZZZ0Y΅ _0+0IVVV"9r Ox4>VRR111 K fB$! 2a@DC1o@m dXdXdXKA UثWW-Z\ ^ /ߋAA/_48%K< Xpb pǹ6یnUޫW?OF1Q 30c:iD BGEj 5x\q!bċ>> < O7<y.#F9b$Xϰa=㿷cggoy!: >SdZVs0.]0 ͅp;&4vXȏȏ3ڟ$NM8ַYf}HR-lٞ&VXybe_~ 4Yd}Hٛ7e^}=X h4l (.(.(.nxaaaPXDa X2u%Sp |WPNh;Xٱ#z064646DĄmmmDqx-gv})횴kҮ(Xx`၅:'uNQTOSOSOE,imڦŤI{(VVVbKK(&6IlD6m,b"klilil)?a~Q̹s?(bRfRfR(D1uע0yaBQL L L Em6R)iń bcDQwVwVwV&-LZ(Im$ŜM9r6WbOEѸڸڸZ+++D1sa̅~~~%Ij&8i'Q ՄjB5>\s(ۺn뺢+uW.QԽֽֽEcccQ4*JR c c cEјhL4&aaa(I-(n(jjjbʸq)DpXa _~(՞՞Պ/_|KQ\}EQ3[3[3[Zw(J2KuFEBBBQԫ*Ju t t DbaŠ(n[qʫ+DE[%/kkkEG~.+ W(|q(.REB߃>N}ZGd!w=|ׇ$& V+A]] >58k07333+@s\p;E/z~(Q=pV8+}ok1d5j0IL*][tm }| )NMzVzx݇wP>|~|@ oW8"@:]}BԻw[OPVZ5jvkۭm z3 ؼyc]>vX+làɃ& 5׸_>6`ľNwEX__>}rccc5kj 1z/^*t-Qza j, =(⛋p鷧Bzի'oy2RK.?^LL e.ÙgJ) &aSM sv>~^ӽ{MMћ7aaaHLbR?[qRۥ6$4Nh@n ^e{U'5Nj4E" F. -[%\f3P+ 5xXyXyXv!lG؎ ?&?&?V2e96 ˒eɲ@ rAdM6FS):(((|||dq8--- dBePPTT>}@!55oݿuVo_џ +V* d2L&f;ՕՕJh(^{H*T,ĝ;w?@SSdggăM((ͨ5EME*`S}N!sz{%UWLLL ...> [V kU֪UB?-ٝtC! E,1;`O?wWO<)z͊%J& I] UJP]~tIu BovXE].@*5IMkk +&SON&a 7śoR oVZQjE)p\q[v~ ))3=0GS_E Gcc`?y<?='s ##ZՊV[osV*Ux-m6@۪۪ۿ]Y_Y_Y_044`xUUWAu:A W_9|0c܏!f"lu:[ttt@[-\\\w[0o!h{k{k{Cܕ+Y/^}ûFkfk![B~AAA @S:PǫW+ö>㐯W+@NT'B/Ey>>> yv*ZjMSBSBSh%)S@ɧ%| ]]];wT0a>|())aPB ?Pfśo,^/7/) / @y> ,PTT :"t-~0渚jBIyIyI9m6r_)D_}]wuU07h94uhE^ {RK/Uk|VJ R?;~vlHؐ!atxYge:nݢ.^<<}mnݦ ׵k_ׄ)(&K|OVX}`uQ_'׾(зoC_Q|(}JEAރyhΣ9bfFfFfFQ{׺\r( 4Kwe%9999998qlQ|鑓(OL>[[[ Q|(NݝԣQ+~o|{FLJW9s=fכ]pRwK/j 7ݑݑ1|8;w@SN;%@ @ WN''h%=R{B_ѾѾѾp]8x4h V#+?r5,W>)p w w IIIe@*P;GK%777#G2@t- rt& iJӔ 7 r-[>}~_AoSyep?t&( 3洚jN+n^yMryH>niiiѰΪ:V @LW+!;<;<;T^*/8vs Fg#x1 O:t> V3fZ+K+K+K(vةb@ Tʨ24W+A(w;lll4m n7(]تUa+йu5jZ#OOOB~>} <</N_ ov?$Nޝ2:.amܴnZ7-TJX){Z%j:pW| kp_eeeŋE6`ohF^ {-5,j:J([wVVVbbb-X j=6pd YJK444VVVppp S0Ŷ%K´sM;iii0ܺsB 68+.K*`kJ•+ N2b pʧ+7s}:[,Lj?tGSSILz-Ë^|+7uOGa퓵O>GðE [}yطž5uZ?4Ceeen^9\ztѥGЇ>1ua˯/6660wܡs[[G?t&[V[ounM5DȪU#K111Y2ԴiSb pILK:-UϪU= ڗ/ v^ya't+]Mo,]Vvcʎ); ^l財ˠ^Bz < LV$K)))qL1__JoI$6|mZ63lf&&&Üsv Y BICK$T$k5֨[.VqZ~:ϰааaff޿z͌of|iiiN+2I֔.㻌V.[oM㓓Zmh_ |nm6cǪGGG:DI$UW*쯲ccc`\qƵpB8aꔦ k]ֺu~~~dΓ9OTXRaN)o$( /Fh袡???B (kQۣGAzw`ށ`ӪUOSH~I>;3z+o2&`KS *T0<@OVZkeU_r4 j4d>}fɇIZluI + p@A_kͯ5pps͍77!<btm}fqfpx*i0xiLV"sHL{гC=akͭ5քSכ:NWUWUW;@?Xzկs{0%vKLV"sI$¼¼.O(|v^yqEQؤbMDK]w߉.IKjcZQDQk}ޫޫ+{$I޽{[/nVQ4 :GK"Hg`OAc4pyEY;g?ퟯz*xM7]~G?l4h ޯ™gU2dVe6lzSOi?=4l` Sʔ2Dq *~U*X`ႅ j]vc1ǘc41 x/Bޅ y]]])uSԅi-F6pdCr\!f]~vyإb`J$I>)%{Y',,\Xn?EK-nnnܸp h}{?q;v퀅UV]X%K~^ /!밯þ~ &M.L}$I>)2jkka77߄E3X4ʩʩʩ~%KtQ(w ko/fff놛(I$ '| ^/(޻x⽋z](ZDXDXDbp\p\pܯs){Qt\Ϲ^d_Fn#-[bTQM}4$u* E"6 luvzWkX__g&QߣGA~E~E~deeaETTTOOOm~|iM.5 8pj-RpzD !Pc1;6lzݬw333p|Ĝ9sϫ><YRfIPE^E^Ev_}m5(**z/%' L"dddrJ)---'$O(Nh$4֍[7nm{{{ bL7?4C" ]ssߧO}BN ho7".O$07}n9tyko.Ojւ+AWqqqSK$lRH~:ԡK-Z 3l0ؾwϾ>'m6uxI& Eطlcddd/Ml4,j`ll *۫,ȣhSD I$﮿#J.պToWzkMW]w[o徕`eee꽑H&!!!ãGa~ǯoO>y:\f}^{ye0111^I$oRH<- [*09&M W:_u={2dwR"{ DYYYCIǡr*xk50䮓\{m! ɆdSD"0?OOO!!!p}o /)ln { CCCSD 0?^5*ME6?]rI+ v^ {&MH~xN<'W^zu|=B.qx:uzkXea]@4Es跬߲~@1N1N1GE"Hg`/( 'O>>>^0崗^ƒj? vo۽m7)SXGE"HL";wDq8Z ;Xomm-L)>cWRuK-UAZZH &ȶm#B U>]Kgz>+|V7Go]G]G]GS%Ĵ&#JN;Ax&<9< L7n>"""aô 6L<<|||S3J(11_;wjH|=:FFF@aJ jPԠA:-tZ40L3L3L3IL"yO܈sԡRJDDDSu.'\N-%6JlkVYfř:$NM87Yd}Hٛ7eooGl555T~*?\p!>n066[]ou&M4yd777MAAA>[),daѥ;hhhННН_btC!`H4$dӒMK6gJl/_78@7W7W7߆  )))Ȼw#h׮]v`FQiqMZ{kϻ5L6L6LxxxT2 r yyy08 N {=A<"1kH#ԃבVH[ynA7oW_5uL6ڔkؒcKw+߭|=Y"e7nf?V+AEEtɺd]2/lWڮ] o߿}?u~^x9(m^ڼ9ԋ[/<==!a{7oZߟ+< jvEٺf뚭*UC%!tv٠{=zԣ֢h >Z(8TtPUnVYeӻ'lq,&XLC;.s>}l VVVO@+M4^zUAmm-?DL-Z,[  VXaePL\K-},vٷ˾cmvM-///#x{{{{{í[2ָָ/vqppp///())jjjGᗖ+MiJ"ReTPQQ7 U~J~J~ doeoeo'N8@&d$nnnbbb/_$HE{E{E{!OSC,M&eeepttmۼP\(.2 P(G9ʙz:D}cq-F[7SO&x d2,^xV-ZZ5S|9r Մrꎂrrr0}wDI{툈+x5b%/l~%XJTB K]__RF)!CPiJS+MZVo 8ǁB )|/G3 (1J2&me+[!6/6/6<{oP۽{mn㻍* /_$?0uJ}FT`}zHtNtNtݞv{ M[[[k!o^޼V&_2%hiiAޠAy4_},XY454545 tNw2dI4:r]B/_VVVϖϖφ7޼z /ϳSGNkH`W_AAnAnA.888K*snҹI&Ιz:R|!Wj^cT>000VVVNk¢΋:/ I7n&4aa cK}.8[l (ܦrKŗ/mmm6:(ϙ3@1P 888W?0fff{EE$''C-ZAgYCRIA}D}D}wAxM7@q8B@N BV oaBss3D*#J6m]jwpqwīWE-i[Ҷ6`~X޶my[ /&b )dޛl=4`ҀI5kN)))7VXEw'NRcJ)5˳ƚk³7<{럭Yl?30'.X|b E"D}J,,[Tn=6)S ``v:$''Cf5 /4Q|l&%,NX:sԩLǼySu} }Uj_ N.8 uFW Q Q ѧG}Vy\ 93ё|lKOދ{/DMƷf|Sx+lW4xOc%%% &T>SMR 䓶$vIXp3ϠWx^NWWW]¥Ǘ_z PI[I[IkꔒOt QI)=Rz@7ޔzcT/E"T =< k* ;,vXOn?#zZi 䓤Q}@]]?7nr[-tԭSNN?vXVbY {M?(FAiA\\ԡ$T$$bbbj}`gcgcgcTmpڧOm :]nFSnݒv/ Ob>3g@i!002d86m[0l0l0li;vB#G111iӞCIA Մ(sHk!J>I!!! / y@>>>VZ]huTUUa㺍6444hf+|1 B_{e?8uSG---BBBazz>?σs!G\`^`^`^SŔ/fIW_ gJ)}4<΃;`b2PRRނ|,,-,->·]Hg`OR v9`}}SBԦMSahА!;6ۜnƝƝƝ{&p r r Vl 11괨ӢN 7o<Pf@9sFgm۲7_3g}vZTiQE8q#\ν{9"~1GSߟt&$^n/6 N`QE 9)XS455ݡ㚎k:((٨0 o.v 'x0nl;k5e{e{e{ W^{cN :PRR1cÍ7^x^zex0V5V5Vҕ/ LIx<9899|Bo_ŏ'Ϟ<{,<`y ?~0lԨQSjnc/@~Ӫ-iIKs9`wA{;Ommm*3I>I2e\;v:?_تUca 'lf.;X:oTTT@6\6\6nVOHHHiyAJFJFJF\WUm)R^/{i7n݀T0?b~Ziox킷 /$/$/oԣ'0'XXX 222eN={ L4eӔMpgÆcm8o4hwhʡLn3TN*'uFQ#>;XUfU{z5լABF k/nve4:|}}mۤIAan|0i%'%^Nz0nܸqc= _UI`I%TK ,1Ft N)XIg`OJ~R`o7؃_pJ/r_S/M4d|}dڒiKAYMR 䓢NV'AaU؂SI\vv SN98 b m,Ni::c#0'E]L]L] Ai4S:'v _Oz`w9;k tӦN)XH$<'{O÷,K$P].Mi6Axb`ܙqgƝ=<{:T30'ER*0bVŬ :SSSI' 58R,4_h^.yST$̴̴4zi%(&+&+&:QRRaщE't)%5I>)Ye{6l0F#1u*opR8){5ׄX__/׿\)%I>)#G-v: pp avpsρJ,ҳONST`;v0S|K\4! -V[Y+g9uō/nrrrCK(g<eeeP-Q-QI7qV 9Ls7NH:ox7w#I%<)ȎˎˎCI*=Z{rM,7v;`78/ M#F4CCC666=\sڵlײ]Kp>|O N'FQhh4 h#?qqq1XW+^AAAUUU,,,TUUABBe*>>I> 餓$80Џ~3u8ɟM1_1_1*S@%c%c%#~mp䑓GN7|aaa~C?h;!Z|j)Sl'HY{Gq:Vu x 4Jm(h ̠̠ ?~0 N :0K/ARR k%N~bbb̐2C u,Axu{!!!PnꂪE"_m6D߅* U@ڬYi666jmVPSS444PQQO_Icۏm?=徇6im@\n\n\.F!FF|=zuefeŲbYpz vQƣG\nr?q}Zzh顥ֳ[n___.5]jԄ5;\Zvoٽew8w>|l龥pնWB nZ 0! $$$555GE*aU [=z ,Yֳ{}'wZZZ]wDJTYf͎",'vYbg Hz0!xn>B666Bes\[ԍ; 㔨K%`iإ lγNVW?!Յ.t.]\yc捙篝vvwt}GC&6ȿ_k&XNj9d>ϟӠAa8|K/A-{3_K,A8*L_7+ Ќf4_n@!PhG;nJ(5owM(үW77on޼^; a0$v Zʵk^{~lcBeZ{8SwO=._=c{w`|.sce=Vnnn [n? =K,ݳ4hhhVhm6ZRRR$$$6m`Rۥ`]p]u--m[TTTtuJׁC&<ATT,Zl eXuYeNn;򺧺ԈS#ҫJs<Y7nd],L& `0WJ ͅBsyft  X[[ðö`zb} ݕ rmrmrmS[Om6 l3kk{+VZ>l3УB =n~`Ko3f4|Y˒_ewewewp:iP{z鵧CKK ԬPB Pipî]QZWk]*o Xc ՗V_Z})<xF 5d(쓲O%%%^{]o}ov5kׄO>]vu066{yCUWU^["DlZjÀ3} ՅB5<x:&]qGPxⵊC-)Svp/^ܽ8|;9wrE?wjܩ9 {* =z|$L2( .* ,'YNuWg\rKWx,Y0ьW^zU ;܇6۸ v,Pf(3|ǷoBCCXv`فa0dJĕ+0T8$Aa*Un`[: ҾK. bvWRJe*-2W?%D'ŦM PTTf6j=hMmjLcL+')')' ..\ 666@zK@@콠lf̲Wʯ_)xAAiSځPB(!dȐyyys9œ0?Ip~+ `ooϙQG2RV[U*s0;cv 8%9%9%wC h rw.ibĦ TpT8* ..*\2g3™FpN8wf߅_htFAeAeeee)K>Y,N*:Tdd_8#$kkk(! r|r|r|LӥllldI& Gq@iYrG#>@a0Ap7|_gr?{n02 :Xݱcw͇5kr׀ėK%b?{000 @W_~YUfU[n*zU.***sI>)VNYH(P:a7 }6X8[l@x޸޸_} lmm!>>h '@/ǃ.VSBx=Π: ---)S*TQ3`5{000B{`ooz^W  <*x9Ws\f2`6AUUz_/ʀaaa2ws_}0Y3Y3Y~t BPcscscs'=F`cc|aas\Xmb5x~Peɗ%_Bf ]wߵ?8_t|Ç/os͐/_j?tttv%D'E+ p6:PP'M7}}ﻂvAqո9gfgfgfͅ +0f嘕cV_*IFFjݩuw4h d2o9c?l -Ң \qƕ ߈o[=znвI&-} - ?Lapd`w߁"YHa'Nbbb=$$$BHV!,,,O?P|_ MtMtMt,,,Y^en/^-.[ TܩS<(yP pRť M2xxx"JG( λw9+aW®f!ېm6Y5jfѨG]yv;fw 77F6tdS8[l!??ʽ-[hpE:㠽yw(z]>}^4 QI#tG(dlƼf̛?v.R˥K-c {;뗮_~)u} ΞΞΞg0kl/J+PaQE뷮ߺ~ QQQ_όY,cSrx5ռWS;5,jy2_~(ߢ|-Re]S5E hСA`珆/x c c cLV? CZLz^¼y \:tri:u+8NޜT$$#VGzV!`P@}žb_\"""`]uՃ#: BCCAp7'yb899s!cDƈ0u0W8sA_W_W_2,2,2,RХKA*U+ ˻w-zT/t_c}u w $.8+`Fތy~9vfڙigxu?YO*1/c^-[ h=z7W5ָ[N 4\t[t[t[Yg=vS"E (R,X<ʓ0uxWJ+&Mܛ@ -+ދRT7lllsb>3}f̄}6lJL+7n9-sZ@q%ƕ.9L6_G~4;680փ[CuByw ]ֻwYvډk'ܸܸdoeoepO,oMޚ5VVV+W׶m_BaU+^x"/ lllA"n@ttttt4ğ?ry[n5|xp~"k٭egYϲ)SP'QnGw>sIA^^ԣfv cFgK-}z8SO>;??mS())fz/9DG􁴐{E> -|!|g_~%XudՉ~Q(EFF’%KRaecvv ~?d˸q 1cjjj`,o,o,{{{@,,, /)/)/ M2PQQm6v2'N8aJX  =]oX߰$/Tz{=ar8?999\NsnnܺPcK-5@ɻ% ދT|*>lll_x Capapa0h5tpXa1>v}-[^*zUkלmmm 3*gT$HCWd&poֽYf^S{M382w_nP7b鋥/{VY+;0O9$O fZʹq4hQ5*kd6lRnN ^.{ +Wʯ JJJj}Z50jUjT0Gi `|Zuuu_ٱcgh3f"9fs rrrfU*k }v<)0!mWmWmW0l° àV[MAǃ:`뽭ރ;wܽuqN;4ZZZ@:t耮t+e2j`-kY Pu:ːg=(ݕJw`;mrWWyGI +:밮<1}bB#C#C%$I|G.\ φ<l 0t kkk?2.d&!~^z}^{^xE^YaĖ-[ fuO=aiO=ߑ#}G"8?(ʘ1+W7]tukC-r7goΆCCԞ=S!(=(=(k4i�!~3Ϭ>{ < NKRǤIatFpA^Pab㉍'6-[Hq 5׸ܳgytLAd0z‰'VX &L*dddrj˩-g_Ǥ̢H7T^a{P:txp8v,XS{^Ny9XobrQ={fL6tZ]BSO9†oXjDal1MIaI%͗49'rN ^Ǽy4$#0!~G -6ZlgO=yЩ>߃'O}*:(B}W;#G1t7O}>VÅ_&M2$$$jJ)KBO0Zhh!Zk]u0INR|M7ԥC~[-lnv?CEv:؁t Vm <x ;w0~?PtҕJ[8xqaՑUGVs 㪎 5W(am%O<lVجY#NGuOO- ףGWگ_i!::{zoyᚇě!&<<<nm61cN:ݟ-j aϳ=L5Z˧.:={NwXWg]uu'?9 7x}pF gqg]%#0!^6o3zW ..M̛7r555˝L0m!x8qGUUYpgǪU+U?:99婪}}}>}4oʧ+T?L^pmZUnr{x᪺jja }Ԅ}ro@Fg1c*FY9s@SOl'd0S&NM`d k笝v\|0jcA2. }Ԅ}R`BF{nﹽ69:no_N QC9s:4bgmC?Di7nkK/rJ9S-ZBҹev}Qg`BFMݛ7jռy^/;SL3o걫Ǯy9C樐={Zwh⢉%|eWPQF( H U\qǰҚJk*snnn@_TMN}"@dv{=S V}U߀zR=4ϑ/2 a@/.lݐ!h[޸z# |s+@fj\kpPZ===f;?zaA-[?eOy)0!ccc8{a/'S K-Z.%*\syة۩۩7?7?7?ܳr=ԖS[N???j֫-SN:s.Q QI Q<γнyݛC~v~v~6mBlBlBlqXaPŦMtttq{#! QAuwqlDZ02d|[nͺ5eEˊHqwEP 6h `mfmfm~uN3;4^e ar Q"n 6/}G0l۰möAM6y,E#GTbRPrH!%:EL%%DQDI=؃P}>4t(! !(BKR`B!%)0!ŒBbI L!D$&XBQ,I !(BKR`B!%)0!Œ5+<?}>FcT]'&/}RXqƕaeʠAp49hJZkݯ%"KDCx[I Qb)ЃRQ6 HJJ~M5tuu!:2:2:do̫WUvVիW^ z^Ayy9)jb+;)0!05D QC 00Ҵi4-ӵO>] $m6WR{/?%deep*P6nsHv3&XoZtk C$I N6SkNK/- ~IE^45CP3 /$/$/?]Sv?CN9#;w2@eeJh)D6P VdrгC=aݓwON[:mnn8CWO_^ν{Ï~#-[T:c_~$KX|J8t6ltV&xtQ4OáI\&q,f1 , , ,G?=wfޙytMCI5`;W Ϸ>|+2jeLʛ7)kL1m>q&LA?m?m?xGL"x`Z`Z`ZVVY.ͻ4gTϨ!_`~?!E@!a֥KY=*z@#T>-J(ݢ4={:.シ^>{WOO{{{(dw ;}g,,,gKi2Sl5oD':Lg‹ /BNlNlN,< ~,u:gݫ4)ӤLؿ` @ ӆ &VB )u[ %/_{{N8uǫǟC>} Vĭ[p톷F} jƂ !!!J.ymC%a(R`Ba⮸I$<~-X20Yfdf @[^6yem۲7hzhzhzH`%,S)ˀ e(EhF3~\ W |g<P9s[[[:tЦTRmJ dI')^x$ wBcMcMc ;ޯ{}Yg5hFkFkFÐCV YW^uz<:ȣ#1cjTV/`]˻u4`>V۟8iq$W{\q;|u:p93L1u:K 999222jsQ(} N^:r>K8|``wYP@%pyE L4h@aWV_> 300f>\OoooU{W]pm:^x5|W'N+;)0V*SЧD#zؽ~a6мE[fffӾЅ.pΥ:v-jUUW 3hϠ=`Ҷ!/ՊbM LUҞ=M{ +転/<`FTQuDUV%JS{zRI)Xx!G0"`D(VέSFno Ir!o\޸q0S+KqS.O˜/s={<@؂a tyD&2iEq!&0Dߊ} b /aB %&iӜ峭"êU 0zAaQE6md[6661tZQ%DQ4/h^"##!((u-ƴb h*i*i*:"""`iV 7f vvvN))0Q,΋:hJ#x?~"L<2(U*S*yg䝰ࢃB~a䁑Fm<:(*D :-tLLL9^ScN95VUXUaU5+r ,-- 8Փx3_j~ QIQIQIQGAAC;M&L6:x&Q$Bxeayeߗ}_€.IKSCFDFDFH"=wO!RFJ!11y6йtn`=.Vi`w5[Kd.mG]UB]]/Xt҅K!#$#$#?^hv'N;eS{OB@e@3B3B3_AXAXA,2_df}4Yꮺ=3g|ag#G2!C.\txuoŒ 3*@ٜ9g}fᙅg~~~-t/^ 5CE" TSbbbZ?hXaE*Rﯾ~dʓ)O /S)eRew0 nS*O yv킰ZajAUUs1۱Xmb5q2fN $@_;|w1|vSM> }B?666C\N\N\xx၇>XXg?7~ˍ_ ? ? ?Ztm 666v'''sss[an}nnnE/|*ݭt]pJ) OzR=GQ4ȿUěa &pb艡'SO>7os;O2?ijg¦3l:R;vol K*,\r? apO9 |0$u:8H#ma>(w]PRRs +rWM;;vxxx8xmKr.ɰ7jo(l`XXX@JӔ)M}>98r8q:tݳvZH;v80( JC_|>>>,Z[h ^zڪڪZpx2쾷{]]]ӻOB7oY}7NN;|lP6lBhdȺ5SO?U50kƱƱ0. djm 'Ǟ{r,ly)7~ )'0gle,O;qǍo!,I^$\\D&&^|&溛n„ !o`hb@<sss84}Ygccc>p,0Ya!eXlo-7ZJO,M,M,MhJ*J,N:FQjyyyƀ.]^=ҨQo`dF0e?~;VԧOSBNٜ9e!TtRpT{T{T q=`źu`8$:$:$B?8 L/Bӄ O!6?6?6|u3_꣪%N8Y*XT`=7{nK.q4-5-5-AMPԿ Ը^z0x4c83̟ hoNVR`⵪rʍ*7Ζ;[l9ȍʍʍzAtЁzS^򒗠)aJEQWϭMmjzN8V@)jʯ^;ԅ 2@lNlNlXXXõq]iѢ5FQc@Quuu1lPC-1[lڮڮڮuz;w4(~jo=V7V7.] :Au; ƯH!&^7l|Ƅ q8Mfu`x,YϿuKuKuKbaŠ78np`sϡrʽ+mEmEmE>}2$hMZSПџџK Tm6tx]<''';w@ITDH/H/H//_Ba%@OOtuu_nnn-|[mŵk=>{|6A}6UUUG~0`aBRKTRKvGGG;{s傕 V.#ZèQBO~2mŞx#*WSO=?HN*T8^kQZk RcK-5Xc]CCj"vۭ;bk֎ jY&DDD\o...pc׍]7vYf]p޽zAfi#GsΡ;B|  pf晙gf8)Еԕԕ~+&W@:ݕ+w%K2@;w@3D3D3nM5քWy{{C~k[-TY_e}ݬvW뺴ҮKⶊ*nUWu_O8>գ+L}?&3gCB a) ꟪ Ƽ3fL )[6mٴenп^zA-涘7~Fv[===M&E={ZӚ֠P[-pK- ՄjBooA ZN-NS@YTV RZ)F.Ba*Ud$hhhZ^-'xrH9rGS)Qm6sO'Э֭֭6͠kA3O3O30 3PSSIqR/jZJDiNWooom6NJ? B444,,,NRK8iq$s|TJU mh|b0Zj᪅&?6컲J0?i~\G#n{AxXxXxtqH!ٿg0m|ӊM.! *B_ L?qpWׁ_~6rn>}(XbŊ%zKh3"fD t5^]##0Q$]Hv.] yyy0g财o : ,N~N~N~0ΰ;TS 퓓 >ӇNN: ,d! VWR`❐+bVK7M7M7&כ\F 55e?Be옫\*M6ن%D &XBQ,I !(BKR`B!%)0!ŒBbI L!D$&XBQ,I !(BKR`B!%)0!ŒBbI L!D$&XBQ,I QP@'*U@+pssPPPJ J JXXXCo!Q.pa҅I&ۏoc@S:jn spΆ !,(DdlMBi]i]iZUjdLLL΁;b& ^7K L"777jtѹ<==#GN-aH QXYYA'@ZZߗkթUVeHN-ag`BAsH$DM,Y|x0if̤ a29s&42idweC°(,[AAA`1bXhQEe%N)a%DN}rBe@TU:ݿS/ x8011G֫[n Nְ5`thYe}&M'R`hݣuA 0#0#0Lt&:;AqPc'NYYY NթE14e2 vqrI(IIJnp!& fff;/:o ,e) ;w)&SLYq6tawӻ Fm(yf:E!XBQ,I !(BKR`B!%)0!ŒF/ğ2eK{RK]J+y$*#`9r-ZU ;v ={@l`l`l Ll3 2wmͷ5: 4hݸu֍<<< ?7| σnGvG <6yl999[oO>M4^]z7~ ȷ˷˷%yK@gi}Z ;~E{{PL2ˀ:K4ho QTLߑ\mz `e21jz'< }GFN9i$t]?O/O/O/p-Z؜9as\*s%P)yκu;khl46`ddWï_ g]zv e>:Ksss%?.1TWi\q^{v3ͷ۫0005YMV䥡ϊ &P•p%x#꿃`3$REk}w}w}wp=z m:ܦp&LHgwq`fmfmf vP;@tS &I3'͜4&MJi#H,H!`/{ c?PZZ-`FTS)Հ缡ϊ ex26el@ј1G!nZݴ A-[6,h;h;h;@5k wO=pu_8 \cy,ԙZgj7on_3/f J22grg΂I΃[[[v+VQ(}dffBn\n\nd=X*V]vו5jxᩆ(}Q"Ⱦ}92yj /_j4YUܫWcCdž;!wBDDD( NB:PSN:CCCrxI'a՝Ww^6Z?-1aƄf@&nMܠ݀v 0t*BbI L!D$&XBQ,I !(BKR`B!%)0!Œx76A}>U")d \2 Fmd2_N0lR٤2LJ2 E/:I>&} -4̇K/UT7n dPm#& 7sBAƏ?fJd:GVUkh*U̬Y3ЩFBBQ,ɧB!;ue+.zTXtcreate-datex3205054 142226020B# c}.zTXtmodify-datex3205054 1425266020AIENDB`source/tls_cert.jpg0000664000175000017500000000101512704114446013361 0ustar rgerrger--2014-01-22 12:49:25-- http://www.rsyslog.com/doc/tls_cert.jpg Resolving www.rsyslog.com (www.rsyslog.com)... 176.9.39.152 Connecting to www.rsyslog.com (www.rsyslog.com)|176.9.39.152|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/jpg] Saving to: ‘tls_cert.jpg’ 0K .......... .......... .......... .......... .......... 141K 50K .......... ...... 146K=0.5s 2014-01-22 12:49:26 (143 KB/s) - ‘tls_cert.jpg’ saved [68335] source/historical/0000775000175000017500000000000013223143453013201 5ustar rgerrgersource/historical/php_syslog_ng.rst0000664000175000017500000001715613223143453016620 0ustar rgerrgerUsing php-syslog-ng with rsyslog ================================ *Written by* `Rainer Gerhards `_ *(2005-08-04)* Note: it has been reported that this guide is somewhat outdated. Most importantly, this guide is for the **original** php-syslog-ng and **cannot** be used for it successor logzilla. Please use the guide with care. Also, please note that **rsyslog's "native" web frontend is** `Adiscon LogAnalyzer `_, which provides best integration and a lot of extra functionality. Abstract -------- **In this paper, I describe how to use** `php-syslog-ng `_ **with** `rsyslogd `_. Php-syslog-ng is a popular web interface to syslog data. Its name stem from the fact that it usually picks up its data from a database created by `syslog-ng `_ and some helper scripts. However, there is nothing syslog-ng specific in the database. With rsyslogd's high customizability, it is easy to write to a syslog-ng like schema. I will tell you how to do this, enabling you to use php-syslog-ng as a front-end for rsyslogd - or save the hassle with syslog-ng database configuration and simply go ahead and use rsyslogd instead.* Overall System Setup -------------------- The setup is pretty straightforward. Basically, php-syslog-ng's interface to the syslogd is the database. We use the schema that php-syslog-ng expects and make rsyslogd write to it in its format. Because of this, php-syslog-ng does not even know there is no syslog-ng present. Setting up the system --------------------- For php-syslog-ng, you can follow its usual setup instructions. Just skip any steps refering to configure syslog-ng. Make sure you create the database schema in `MySQL `_. As of this writing, the expected schema can be created via this script: :: CREATE DATABASE syslog USE syslog CREATE TABLE logs(host varchar(32) default NULL, facility varchar(10) default NULL, priority varchar(10) default NULL, level varchar(10) default NULL, tag varchar(10) default NULL, date date default NULL, time time default NULL, program varchar(15) default NULL, msg text, seq int(10) unsigned NOT NULL auto_increment, PRIMARY KEY (seq), KEY host (host), KEY seq (seq), KEY program (program), KEY time (time), KEY date (date), KEY priority (priority), KEY facility (facility ) TYPE=MyISAM;`` Please note that at the time you are reading this paper, the schema might have changed. Check for any differences. As we customize rsyslogd to the schema, it is vital to have the correct one. If this paper is outdated, `let me know `_ so that I can fix it. Once this schema is created, we simply instruct rsyslogd to store received data in it. I wont go into too much detail here. If you are interested in some more details, you might find my paper "`Writing syslog messages to MySQL `_\ " worth reading. For this article, we simply modify `rsyslog.conf `_\ so that it writes to the database. That is easy. Just these two lines are needed: :: $template syslog-ng,"insert into logs(host, facility, priority, tag, date, time, msg) values ('%HOSTNAME%', %syslogfacility%, %syslogpriority%, '%syslogtag%', '%timereported:::date-mysql%', '%timereported:::date-mysql%', '%msg%')", SQL *.*,           mysql-server,syslog,user,pass;syslog-ng These are just **two** lines. I have color-coded them so that you see what belongs together (the colors have no other meaning). The green line is the actual SQL statement being used to take care of the syslog-ng schema. Rsyslogd allows you to fully control the statement sent to the database. This allows you to write to any database format, including your homegrown one (if you so desire). Please note that there is a small inefficiency in our current usage: the ``'%timereported:::date-mysql%'`` property is used for both the time and the date (if you wonder about what all these funny characters mean, see the `rsyslogd property replacer manual `_) . We could have extracted just the date and time parts of the respective properties. However, this is more complicated and also adds processing time to rsyslogd's processing (substrings must be extracted). So we take a full mysql-formatted timestamp and supply it to MySQL. The sql engine in turn discards the unneeded part. It works pretty well. As of my understanding, the inefficiency of discarding the unneeded part in MySQL is lower than the effciency gain from using the full timestamp in rsyslogd. So it is most probably the best solution. Please note that rsyslogd knows two different timestamp properties: one is timereported, used here. It is the timestamp from the message itself. Sometimes that is a good choice, in other cases not. It depends on your environment. The other one is the timegenerated property. This is the time when rsyslogd received the message. For obvious reasons, that timestamp is consistent, even when your devices are in multiple time zones or their clocks are off. However, it is not "the real thing". It's your choice which one you prefer. If you prefer timegenerated ... simply use it ;) The line in red tells rsyslogd which messages to log and where to store it. The "\*.\*" selects all messages. You can use standard syslog selector line filters here if you do not like to see everything in your database. The ">" tells rsyslogd that a MySQL connection must be established. Then, "mysql-server" is the name or IP address of the server machine, "syslog" is the database name (default from the schema) and "user" and "pass" are the logon credentials. Use a user with low privileges, insert into the logs table is sufficient. "syslog-ng" is the template name and tells rsyslogd to use the SQL statement shown above. Once you have made the changes, all you need to do is restart rsyslogd. Then, you should see syslog messages flow into your database - and show up in php-syslog-ng. Conclusion ---------- With minumal effort, you can use php-syslog-ng together with rsyslogd. For those unfamiliar with syslog-ng, this configuration is probably easier to set up then switching to syslog-ng. For existing rsyslogd users, php-syslog-ng might be a nice add-on to their logging infrastructure. Please note that the `MonitorWare family `_ (to which rsyslog belongs) also offers a web-interface: `Adiscon LogAnalyzer`_. From my point of view, obviously, **phpLogCon is the more natural choice for a web interface to be used together with rsyslog**. It also offers superb functionality and provides, for example,native display of Windows event log entries. I have set up a `demo server `_., You can have a peek at it without installing anything. Feedback Requested ------------------ I would appreciate feedback on this paper. If you have additional ideas, comments or find bugs, please `let me know `_. References and Additional Material ---------------------------------- - `php-syslog-ng `_ Revision History ---------------- - 2005-08-04 \* `Rainer Gerhards `_ \* initial version created source/historical/stunnel.rst0000664000175000017500000003222713223143453015431 0ustar rgerrgerSSL Encrypting Syslog with Stunnel ================================== *Written by* `Rainer Gerhards `_ *(2005-07-22)* **HISTORICAL DOCUMENT** **Note: this is an outdated HISTORICAL document.** A much better description on `securing syslog with TLS `_ is available. Abstract -------- **In this paper, I describe how to encrypt** `syslog `_ **messages on the network.** Encryption is vital to keep the confidiental content of syslog messages secure. I describe the overall approach and provide an HOWTO do it with the help of `rsyslogd `_ and `stunnel `_.* Please note that starting with rsyslog 3.19.0, `rsyslog provides native TLS/SSL encryption `_ without the need of stunnel. I strongly recomend to use that feature instead of stunnel. The stunnel documentation here is mostly provided for backwards compatibility. New deployments are advised to use native TLS mode.\ ** Background ---------- **Syslog is a clear-text protocol. That means anyone with a sniffer can have a peek at your data.** In some environments, this is no problem at all. In others, it is a huge setback, probably even preventing deployment of syslog solutions. Thankfully, there is an easy way to encrypt syslog communication. I will describe one approach in this paper. The most straightforward solution would be that the syslogd itself encrypts messages. Unfortuantely, encryption is only standardized in `RFC 3195 `_. But there is currently no syslogd that implements RFC 3195's encryption features, so this route leads to nothing. Another approach would be to use vendor- or project-specific syslog extensions. There are a few around, but the problem here is that they have compatibility issues. However, there is one surprisingly easy and interoperable solution: though not standardized, many vendors and projects implement plain tcp syslog. In a nutshell, plain tcp syslog is a mode where standard syslog messages are transmitted via tcp and records are separated by newline characters. This mode is supported by all major syslogd's (both on Linux/Unix and Windows) as well as log sources (for example, `EventReporter `_ for Windows Event Log forwarding). Plain tcp syslog offers reliability, but it does not offer encryption in itself. However, since it operates on a tcp stream, it is now easy to add encryption. There are various ways to do that. In this paper, I will describe how it is done with stunnel (an other alternative would be `IPSec `_, for example). Stunnel is open source and it is available both for Unix/Linux and Windows. It provides a way to use ssl communication for any non-ssl aware client and server - in this case, our syslogd. Stunnel works much like a wrapper. Both on the client and on the server machine, tunnel portals are created. The non-ssl aware client and server software is configured to not directly talk to the remote partner, but to the local (s)tunnel portal instead. Stunnel, in turn, takes the data received from the client, encrypts it via ssl, sends it to the remote tunnel portal and that remote portal sends it to the recipient process on the remote machine. The transfer to the portals is done via unencrypted communication. As such, it is vital that the portal and the respective program that is talking to it are on the same machine, otherwise data would travel partly unencrypted. Tunneling, as done by stunnel, requires connection oriented communication. This is why you need to use tcp-based syslog. As a side-note, you can also encrypt a plain-text RFC 3195 session via stunnel, though this definitely is not what the protocol designers had on their mind ;) In the rest of this document, I assume that you use rsyslog on both the client and the server. For the samples, I use `Debian `_. Interestingly, there are some annoying differences between stunnel implementations. For example, on Debian a comment line starts with a semicolon (';'). On `Red Hat `_, it starts with a hash sign ('#'). So you need to watch out for subtle issues when setting up your system. Overall System Setup -------------------- In ths paper, I assume two machines, one named "client" and the other named "server". It is obvious that, in practice, you will probably have multiple clients but only one server. Syslog traffic shall be transmitted via stunnel over the network. Port 60514 is to be used for that purpose. The machines are set up as follows: **Client** - rsyslog forwards  message to stunnel local portal at port 61514 - local stunnel forwards data via the network to port 60514 to its remote peer **Server** - stunnel listens on port 60514 to connections from its client peers - all connections are forwarded to the locally-running rsyslog listening at port 61514 Setting up the system --------------------- For Debian, you need the "stunnel4" package. The "stunnel" package is the older 3.x release, which will not support the configuration I describe below. Other distributions might have other names. For example, on Red Hat it is just "stunnel". Make sure that you install the appropriate package on both the client and the server. It is also a good idea to check if there are updates for either stunnel or openssl (which stunnel uses) - there are often security fixes available and often the latest fixes are not included in the default package. In my sample setup, I use only the bare minimum of options. For example, I do not make the server check client cerficiates. Also, I do not talk much about certificates at all. If you intend to really secure your system, you should probably learn about certificates and how to manage and deploy them. This is beyond the scope of this paper. For additional information, `http://www.stunnel.org/faq/certs.html `_ is a good starting point. You also need to install rsyslogd on both machines. Do this before starting with the configuration. You should also familarize yourself with its configuration file syntax, so that you know which actions you can trigger with it. Rsyslogd can work as a drop-in replacement for stock `sysklogd `_. So if you know the standard syslog.conf syntax, you do not need to learn any more to follow this paper. Server Setup ~~~~~~~~~~~~ At the server, you need to have a digital certificate. That certificate enables SSL operation, as it provides the necessary crypto keys being used to secure the connection. Many versions of stunnel come with a default certificate, often found in /etc/stunnel/stunnel.pem. If you have it, it is good for testing only. If you use it in production, it is very easy to break into your secure channel as everybody is able to get hold of your private key. I didn't find an stunnel.pem on my Debian machine. I guess the Debian folks removed it because of its insecurity. You can create your own certificate with a simple openssl tool - you need to do it if you have none and I highly recommend to create one in any case. To create it, cd to /etc/stunnel and type: ``openssl req -new -x509 -days 3650 -nodes -out stunnel.pem -keyout stunnel.pem`` That command will ask you a number of questions. Provide some answer for them. If you are unsure, read `http://www.stunnel.org/faq/certs.html `_. After the command has finished, you should have a usable stunnel.pem in your working directory. Next is to create a configuration file for stunnel. It will direct stunnel what to do. You can use the following basic file: :: ; Certificate/key is needed in server modecert = /etc/stunnel/stunnel.pem; Some debugging stuff useful for troubleshootingdebug = 7foreground=yes [ssyslog] accept = 60514 connect = 61514 Save this file to e.g. /etc/stunnel/syslog-server.conf. Please note that the settings in *italics* are for debugging only. They run stunnel with a lot of debug information in the foreground. This is very valuable while you setup the system - and very useless once everything works well. So be sure to remove these lines when going to production. Finally, you need to start the stunnel daemon. Under Debian, this is done via "stunnel /etc/stunnel/syslog.server.conf". If you have enabled the debug settings, you will immediately see a lot of nice messages. Now you have stunnel running, but it obviously unable to talk to rsyslog - because it is not yet running. If not already done, configure it so that it does everything you want. If in doubt, you can simply copy /etc/syslog.conf to /etc/rsyslog.conf and you probably have what you want. The really important thing in rsyslogd configuration is that you must make it listen to tcp port 61514 (remember: this is where stunnel send the messages to). Thankfully, this is easy to achive: just add "-t 61514" to the rsyslogd startup options in your system startup script. After done so, start (or restart) rsyslogd. The server should now be fully operational. Client Setup ~~~~~~~~~~~~ The client setup is simpler. Most importantly, you do not need a certificate (of course, you can use one if you would like to authenticate the client, but this is beyond the scope of this paper). So the basic thing you need to do is create the stunnel configuration file. :: ; Some debugging stuff useful for troubleshootingdebug = 7foreground=yes client=yes [ssyslog] accept = 127.0.0.1:61514 connect = 192.0.2.1:60514 Again, the text in *italics* is for debugging purposes only. I suggest you leave it in during your initial testing and then remove it. The most important difference to the server configuration outlined above is the "client=yes" directive. It is what makes this stunnel behave like a client. The accept directive binds stunnel only to the local host, so that it is protected from receiving messages from the network (somebody might fake to be the local sender). The address "192.0.2.1" is the address of the server machine. You must change it to match your configuration. Save this file to /etc/stunnel/syslog-client.conf. Then, start stunnel via "stunnel4 /etc/stunnel/syslog-client.conf".  Now you should see some startup messages. If no errors appear, you have a running client stunnel instance. Finally, you need to tell rsyslogd to send data to the remote host. In stock syslogd, you do this via the "@host" forwarding directive. The same works with rsyslog, but it suppports extensions to use tcp. Add the following line to your /etc/rsyslog.conf: :: *.* @@127.0.0.1:61514 Please note the double at-sign (@@). This is no typo. It tells rsyslog to use tcp instead of udp delivery. In this sample, all messages are forwarded to the remote host. Obviously, you may want to limit this via the usual rsyslog.conf settings (if in doubt, use man rsyslog.con). You do not need to add any special startup settings to rsyslog on the client. Start or restart rsyslog so that the new configuration setting takes place. Done ~~~~ After following these steps, you should have a working secure syslog forwarding system. To verify, you can type "logger test" or a similar smart command on the client. It should show up in the respective server log file. If you dig out you sniffer, you should see that the traffic on the wire is actually protected. In the configuration use above, the two stunnel endpoints should be quite chatty, so that you can follow the action going on on your system. If you have only basic security needs, you can probably just remove the debug settings and take the rest of the configuration to production. If you are security-sensitve, you should have a look at the various stunnel settings that help you further secure the system. Preventing Systems from talking directly to the rsyslog Server -------------------------------------------------------------- It is possible that remote systems (or attackers) talk to the rsyslog server by directly connecting to its port 61514. Currently (July of 2005), rsyslog does not offer the ability to bind to the local host, only. This feature is planned, but as long as it is missing, rsyslog must be protected via a firewall. This can easily be done via e.g iptables. Just be sure not to forget it. Conclusion ---------- With minumal effort, you can set up a secure logging infrastructure employing ssl encrypted syslog message transmission. As a side note, you also have the benefit of reliable tcp delivery which is far less prone to message loss than udp. Feedback requested ~~~~~~~~~~~~~~~~~~ I would appreciate feedback on this tutorial. If you have additional ideas, comments or find bugs (I \*do\* bugs - no way... ;)), please `let me know `_. Revision History ---------------- - 2005-07-22 \* `Rainer Gerhards`_ \* Initial Version created - 2005-07-26 \* `Rainer Gerhards`_ \* Some text brush-up, hyperlinks added - 2005-08-03 \* `Rainer Gerhards`_ \* license added - 2008-05-05 \* `Rainer Gerhards`_ \* updated to reflect native TLS capability of rsyslog 3.19.0 and above source/historical/module_devel.rst0000664000175000017500000001222313223143453016377 0ustar rgerrgerDeveloping rsyslog modules (outdated) ===================================== *Written by `Rainer Gerhards* `_ *(2007-07-28)* **This document is outdated and primarily contains historical information. Do not trust it to build code. It currently is under review.** This document is incomplete. The module interface is also quite incomplete and under development. Do not currently use it! You may want to visit `Rainer's blog `_ to learn what's going on. Overview -------- In theory, modules provide input and output, among other functions, in rsyslog. In practice, modules are only utilized for output in the current release. The module interface is not yet completed and a moving target. We do not recommend to write a module based on the current specification. If you do, please be prepared that future released of rsyslog will probably break your module. A goal of modularization is to provide an easy to use plug-in interface. However, this goal is not yet reached and all modules must be statically linked. Module "generation" ------------------- There is a lot of plumbing that is always the same in all modules. For example, the interface definitions, answering function pointer queries and such. To get rid of these laborious things, I generate most of them automatically from a single file. This file is named module-template.h. It also contains the current best description of the interface "specification". One thing that can also be achieved with it is the capability to cope with a rapidly changing interface specification. The module interface is evolving. Currently, it is far from being finished. As I moved the monolithic code to modules, I needed (and still need) to make many "non-clean" code hacks, just to get it working. These things are now gradually being removed. However, this requires frequent changes to the interfaces, as things move in and out while working towards a clean interface. All the interim is necessary to reach the goal. This volatility of specifications is the number one reasons I currently advise against implementing your own modules (hint: if you do, be sure to use module-template.h and be prepared to fix newly appearing and disappearing data elements). Naming Conventions ------------------ Source ~~~~~~ Output modules, and only output modules, should start with a file name of "om" (e.g. "omfile.c", "omshell.c"). Similarly, input modules will use "im" and filter modules "fm". The third character shall not be a hyphen. Module Security --------------- Modules are directly loaded into rsyslog's address space. As such, any module is provided a big level of trust. Please note that further module interfaces might provide a way to load a module into an isolated address space. This, however, is far from being completed. So the number one rule about module security is to run only code that you know you can trust. To minimize the security risks associated with modules, rsyslog provides only the most minimalistic access to data structures to its modules. For that reason, the output modules do not receive any direct pointers to the selector\_t structure, the syslogd action structures and - most importantly - the msg structure itself. Access to these structures would enable modules to access data that is none of their business, creating a potential security weakness. Not having access to these structures also simplifies further queueing and error handling cases. As we do not need to provide e.g. full access to the msg object itself, we do not need to serialize and cache it. Instead, strings needed by the module are created by syslogd and then the final result is provided to the module. That, for example, means that in a queued case $NOW is the actual timestamp of when the message was processed, which may be even days before it being dequeued. Think about it: If we wouldn't cache the resulting string, $NOW would be the actual date if the action were suspended and messages queued for some time. That could potentially result in big confusion. It is thought that if an output module actually needs access to the while msg object, we will (then) introduce a way to serialize it (e.g. to XML) in the property replacer. Then, the output module can work with this serialized object. The key point is that output modules never deal directly with msg objects (and other internal structures). Besides security, this also greatly simplifies the job of the output module developer. Action Selectors ---------------- Modules (and rsyslog) need to know when they are called. For this, there must a an action identification in selector lines. There are two syntaxes: the single-character syntax, where a single characters identifies a module (e.g. "\*" for a wall message) and the modules designator syntax, where the module name is given between colons (e.g. ":ommysql:"). The single character syntax is depreciated and should not be used for new plugins. An in-depth discussion of module designation in action selectors can be found in this forum thread: `http://www.rsyslog.com/index.php?name=PNphpBB2&file=viewtopic&p=678#678 `_ source/historical/index.rst0000664000175000017500000000045713223143010015035 0ustar rgerrgerHistorical Documents -------------------- This part of the documentation set contains historical documents which are still of interest or may be useful in some more exotic environments. .. toctree:: :maxdepth: 2 php_syslog_ng stunnel multi_ruleset_legacy_format_samples module_devel source/historical/multi_ruleset_legacy_format_samples.rst0000664000175000017500000001527013223143453023255 0ustar rgerrgerLegacy Format Samples for Multiple Rulesets =========================================== This chapter complements rsyslog's documentation of :doc:`rulesets <../concepts/multi_ruleset>`. While the base document focusses on RainerScript format, it does not provide samples in legacy format. These are included in this document. **Important:** do **not** use legacy ruleset defintions for new configurations. Especially with rulesets, legacy format is extremely hard to get right. The information in this page is included in order to help you understand already existing configurations using the ruleset feature. We even recommend to convert any such configs to RainerScript format because of its increased robustness and simplicity. Legacy ruleset support was available starting with version 4.5.0 and 5.1.1. Split local and remote logging ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let's say you have a pretty standard system that logs its local messages to the usual bunch of files that are specified in the default rsyslog.conf. As an example, your rsyslog.conf might look like this: :: # ... module loading ... # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... Now, you want to add receive messages from a remote system and log these to a special file, but you do not want to have these messages written to the files specified above. The traditional approach is to add a rule in front of all others that filters on the message, processes it and then discards it: :: # ... module loading ... # process remote messages :fromhost-ip, isequal, "192.0.2.1" /var/log/remotefile & ~ # only messages not from 192.0.21 make it past this point # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... Note the tilde character, which is the discard action!. Also note that we assume that 192.0.2.1 is the sole remote sender (to keep it simple). With multiple rulesets, we can simply define a dedicated ruleset for the remote reception case and bind it to the receiver. This may be written as follows: :: # ... module loading ... # process remote messages # define new ruleset and add rules to it: $RuleSet remote *.* /var/log/remotefile # only messages not from 192.0.21 make it past this point # bind ruleset to tcp listener $InputTCPServerBindRuleset remote # and activate it: $InputTCPServerRun 10514 # switch back to the default ruleset: $RuleSet RSYSLOG_DefaultRuleset # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... Here, we need to switch back to the default ruleset after we have defined our custom one. This is why I recommend a different ordering, which I find more intuitive. The sample below has it, and it leads to the same results: :: # ... module loading ... # at first, this is a copy of the unmodified rsyslog.conf # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... # end of the "regular" rsyslog.conf. Now come the new definitions: # process remote messages # define new ruleset and add rules to it: $RuleSet remote *.* /var/log/remotefile # bind ruleset to tcp listener $InputTCPServerBindRuleset remote # and activate it: $InputTCPServerRun 10514 Here, we do not switch back to the default ruleset, because this is not needed as it is completely defined when we begin the "remote" ruleset. Now look at the examples and compare them to the single-ruleset solution. You will notice that we do **not** need a real filter in the multi-ruleset case: we can simply use "\*.\*" as all messages now means all messages that are being processed by this rule set and all of them come in via the TCP receiver! This is what makes using multiple rulesets so much easier. Split local and remote logging for three different ports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example is almost like the first one, but it extends it a little bit. While it is very similar, I hope it is different enough to provide a useful example why you may want to have more than two rulesets. Again, we would like to use the "regular" log files for local logging, only. But this time we set up three syslog/tcp listeners, each one listening to a different port (in this example 10514, 10515, and 10516). Logs received from these receivers shall go into different files. Also, logs received from 10516 (and only from that port!) with "mail.\*" priority, shall be written into a specif file and **not** be written to 10516's general log file. This is the config: :: # ... module loading ... # at first, this is a copy of the unmodified rsyslog.conf # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * ... more ... # end of the "regular" rsyslog.conf. Now come the new definitions: # process remote messages #define rulesets first $RuleSet remote10514 *.* /var/log/remote10514 $RuleSet remote10515 *.* /var/log/remote10515 $RuleSet remote10516 mail.* /var/log/mail10516 & ~ # note that the discard-action will prevent this messag from # being written to the remote10516 file - as usual... *.* /var/log/remote10516 # and now define listeners bound to the relevant ruleset $InputTCPServerBindRuleset remote10514 $InputTCPServerRun 10514 $InputTCPServerBindRuleset remote10515 $InputTCPServerRun 10515 $InputTCPServerBindRuleset remote10516 $InputTCPServerRun 10516 Note that the "mail.\*" rule inside the "remote10516" ruleset does not affect processing inside any other rule set, including the default rule set. source/conf.py0000664000175000017500000002447513224651466012364 0ustar rgerrger# -*- coding: utf-8 -*- # # Rsyslog Doc documentation build configuration file, created by # sphinx-quickstart on Sun Apr 28 07:10:10 2013. # # This file is execfile()d with the current directory set to its containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. import datetime import os import re import subprocess import sys # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. #sys.path.insert(0, os.path.abspath('.')) sys.path.insert(0, os.path.abspath('_ext')) # -- General configuration ----------------------------------------------------- # If your documentation needs a minimal Sphinx version, state it here. needs_sphinx = '1.5.1' # Add any Sphinx extension module names here, as strings. They can be extensions # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. extensions = ['edit_on_github', 'sphinx.ext.todo'] edit_on_github_project = 'rsyslog/rsyslog-doc' edit_on_github_branch = 'master' # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' # The encoding of source files. #source_encoding = 'utf-8-sig' # https://stackoverflow.com/questions/26242919/sphinx-documentation-system-multiple-substitutions-with-rst-prolog # http://www.sphinx-doc.org/en/stable/config.html#confval-rst_prolog # # This will be included at the beginning of every source file that is read. rst_prolog = """ .. |PRODUCT| replace:: ``Rsyslog`` .. |FmtBasicName| replace:: ``basic`` .. |FmtAdvancedName| replace:: ``advanced`` .. |FmtObsoleteName| replace:: ``obsolete legacy`` .. |FmtObsoleteDescription| replace:: ``Obsolete Format Equivalents`` """ # The master toctree document. master_doc = 'index' # General information about the project. project = u'rsyslog' copyright = u'2008-2017, Rainer Gerhards and Others' author = u'Rainer Gerhards and Others' # Generate the current stable version number from the latest git tag git_tag_output = subprocess.check_output(['git', 'tag', '--list', "v*"]).decode("utf-8").strip() git_tag_list = re.sub('[A-Za-z]', '', git_tag_output).split('\n') git_tag_list.sort(key=lambda s: [int(u) for u in s.split('.')]) git_tag_latest = git_tag_list[-1] # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The short X.Y version. current_version = git_tag_latest[:-2] # Break apart 'x.y' value, increment y and then concatenate into 'x.y' again version = "{}.{}".format(int(current_version[:1]), int(current_version[-2:]) + 1) DATE = datetime.date.today() TODAY = DATE.strftime('%Y%m%d') # e.g., v8.29.0-98-g07d02c6 (after decoding) # https://stackoverflow.com/questions/2502833/store-output-of-subprocess-popen-call-in-a-string git_describe_output = subprocess.check_output(['git', 'describe']).decode("utf-8") # Grab the last portion of the strings, then strip off leading 'g' commit = git_describe_output.split('-')[-1][1:] # This is displayed in multiple prominent locations in the docs # where it is useful to be able to tell at a glance when the files # were generated and from what commit. # # The full version, including alpha/beta/rc tags. release = "{}-{}-{}".format(version, TODAY, commit) # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. #language = None # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: #today = '' # Else, today_fmt is used as the format for a strftime call. #today_fmt = '%B %d, %Y' # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. exclude_patterns = [] # The reST default role (used for this markup: `text`) to use for all documents. #default_role = None # If true, '()' will be appended to :func: etc. cross-reference text. #add_function_parentheses = True # If true, the current module name will be prepended to all description # unit titles (such as .. function::). #add_module_names = True # If true, sectionauthor and moduleauthor directives will be shown in the # output. They are ignored by default. #show_authors = False # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # A list of ignored prefixes for module index sorting. #modindex_common_prefix = [] # Warn about all references where the target cannot be found. Default is False. nitpicky = True # If true, `todo` and `todoList` produce output, else they produce nothing. todo_include_todos = True # If this is True, todo emits a warning for each TODO entries. The default # is False. todo_emit_warnings = True # Supress "unknown mimetype for ..." warnings suppress_warnings = ['epub.unknown_project_files'] # -- Options for HTML output --------------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. html_theme = 'default' #html_theme = 'basic' #html_style = 'rsyslog.css' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the # documentation. #html_theme_options = {} # Add any paths that contain custom themes here, relative to this directory. #html_theme_path = [] # The name for this set of Sphinx documents. If None, it defaults to # " v documentation". #html_title = None # A shorter title for the navigation bar. Default is the same as html_title. #html_short_title = None # The name of an image file (relative to this directory) to place at the top # of the sidebar. #html_logo = None # The name of an image file (within the static path) to use as favicon of the # docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 # pixels large. #html_favicon = None # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, # using the given strftime format. #html_last_updated_fmt = '%b %d, %Y' # If true, SmartyPants will be used to convert quotes and dashes to # typographically correct entities. #html_use_smartypants = True # Custom sidebar templates, maps document names to template names. #html_sidebars = {} # Additional templates that should be rendered to pages, maps page names to # template names. #html_additional_pages = {} # If false, no module index is generated. #html_domain_indices = True # If false, no index is generated. #html_use_index = True # If true, the index is split into individual pages for each letter. #html_split_index = False # If true, links to the reST sources are added to the pages. #html_show_sourcelink = True # If true, "Created using Sphinx" is shown in the HTML footer. Default is True. html_show_sphinx = False # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. #html_show_copyright = True # If true, an OpenSearch description file will be output, and all pages will # contain a tag referring to it. The value of this option must be the # base URL from which the finished HTML is served. #html_use_opensearch = '' # This is the file name suffix for HTML files (e.g. ".xhtml"). #html_file_suffix = None # Output file base name for HTML help builder. htmlhelp_basename = 'rsyslogdoc' # -- Options for LaTeX output -------------------------------------------------- latex_elements = { # The paper size ('letterpaper' or 'a4paper'). #'papersize': 'letterpaper', # The font size ('10pt', '11pt' or '12pt'). #'pointsize': '10pt', # Additional stuff for the LaTeX preamble. #'preamble': '', } # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, author, documentclass [howto/manual]). latex_documents = [ ('index', 'RsyslogDoc.tex', u'Rsyslog Doc Documentation', u'foo bar', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of # the title page. #latex_logo = None # For "manual" documents, if this is true, then toplevel headings are parts, # not chapters. #latex_use_parts = False # If true, show page references after internal links. #latex_show_pagerefs = False # If true, show URL addresses after external links. #latex_show_urls = False # Documents to append as an appendix to all manuals. #latex_appendices = [] # If false, no module index is generated. #latex_domain_indices = True # -- Options for manual page output -------------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ ('queues', 'rsyslog-queues', u'Rsyslog Documentation: Queues', [u'Rainer Gerhards'], 1), ('configuration/actions', 'rsyslog-actions', u'Rsyslog Documentation: Actions', [u'Rainer Gerhards'], 1), ] # If true, show URL addresses after external links. #man_show_urls = False # -- Options for Texinfo output ------------------------------------------------ # Grouping the document tree into Texinfo files. List of tuples # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ ('index', 'RsyslogDoc', u'Rsyslog Doc Documentation', u'foo bar', 'RsyslogDoc', 'One line description of project.', 'Miscellaneous'), ] # Documents to append as an appendix to all manuals. #texinfo_appendices = [] # If false, no module index is generated. #texinfo_domain_indices = True # How to display URL addresses: 'footnote', 'no', or 'inline'. # texinfo_show_urls = 'footnote' # -- Options for epub output --------------------------------------------------- epub_theme = 'epub' epub_basename = 'rsyslog' epub_author = u'Rainer Gerhards and Others' epub_contributor = u'Rsyslog Community' epub_publisher = 'http://www.rsyslog.com/' epub_description = u'Documentation for the rsyslog project' source/development/0000775000175000017500000000000013223143453013362 5ustar rgerrgersource/development/dev_oplugins.rst0000664000175000017500000005022013223143453016611 0ustar rgerrgerWriting Rsyslog Output Plugins ============================== This page is the begin of some developer documentation for writing output plugins. Doing so is quite easy (and that was a design goal), but there currently is only sparse documentation on the process available. I was tempted NOT to write this guide here because I know I will most probably not be able to write a complete guide. However, I finally concluded that it may be better to have some information and pointers than to have nothing. Getting Started and Samples --------------------------- The best to get started with rsyslog plugin development is by looking at existing plugins. All that start with "om" are **o**\ utput **m**\ odules. That means they are primarily thought of being message sinks. In theory, however, output plugins may aggregate other functionality, too. Nobody has taken this route so far so if you would like to do that, it is highly suggested to post your plan on the rsyslog mailing list, first (so that we can offer advice). The rsyslog distribution tarball contains the omstdout plugin which is extremely well targeted for getting started. Just note that this plugin itself is not meant for production use. But it is very simplistic and so a really good starting point to grasp the core ideas. In any case, you should also read the comments in ./runtime/module-template.h. Output plugins are build based on a large set of code-generating macros. These macros handle most of the plumbing needed by the interface. As long as no special callback to rsyslog is needed (it typically is not), an output plugin does not really need to be aware that it is executed by rsyslog. As a plug-in programmer, you can (in most cases) "code as usual". However, all macros and entry points need to be provided and thus reading the code comments in the files mentioned is highly suggested. For testing, you need rsyslog's debugging support. Some useful information is given in "`troubleshooting rsyslog `_ from the doc set. Special Topics -------------- Threading ~~~~~~~~~ Rsyslog uses massive parallel processing and multithreading. However, a plugin's entry points are guaranteed to be never called concurrently **for the same action**. That means your plugin must be able to be called concurrently by two or more threads, but you can be sure that for the same instance no concurrent calls happen. This is guaranteed by the interface specification and the rsyslog core guards against multiple concurrent calls. An instance, in simple words, is one that shares a single instanceData structure. So as long as you do not mess around with global data, you do not need to think about multithreading (and can apply a purely sequential programming methodology). Please note that during the configuration parsing stage of execution, access to global variables for the configuration system is safe. In that stage, the core will only call sequentially into the plugin. Getting Message Data ~~~~~~~~~~~~~~~~~~~~ The doAction() entry point of your plugin is provided with messages to be processed. It will only be activated after filtering and all other conditions, so you do not need to apply any other conditional but can simply process the message. Note that you do NOT receive the full internal representation of the message object. There are various (including historical) reasons for this and, among others, this is a design decision based on security. Your plugin will only receive what the end user has configured in a $template statement. However, starting with 4.1.6, there are two ways of receiving the template content. The default mode, and in most cases sufficient and optimal, is to receive a single string with the expanded template. As I said, this is usually optimal, think about writing things to files, emailing content or forwarding it. The important philosophy is that a plugin should **never** reformat any of such strings - that would either remove the user's ability to fully control message formats or it would lead to duplicating code that is already present in the core. If you need some formatting that is not yet present in the core, suggest it to the rsyslog project, best done by sending a patch ;), and we will try hard to get it into the core (so far, we could accept all such suggestions - no promise, though). If a single string seems not suitable for your application, the plugin can also request access to the template components. The typical use case seems to be databases, where you would like to access properties via specific fields. With that mode, you receive a char \*\* array, where each array element points to one field from the template (from left to right). Fields start at array index 0 and a NULL pointer means you have reached the end of the array (the typical Unix "poor man's linked list in an array" design). Note, however, that each of the individual components is a string. It is not a date stamp, number or whatever, but a string. This is because rsyslog processes strings (from a high-level design look at it) and so this is the natural data type. Feel free to convert to whatever you need, but keep in mind that malformed packets may have lead to field contents you'd never expected... If you like to use the array-based parameter passing method, think that it is only available in rsyslog 4.1.6 and above. If you can accept that your plugin will not be working with previous versions, you do not need to handle pre 4.1.6 cases. However, it would be "nice" if you shut down yourself in these cases - otherwise the older rsyslog core engine will pass you a string where you expect the array of pointers, what most probably results in a segfault. To check whether or not the core supports the functionality, you can use this code sequence: :: BEGINmodInit() rsRetVal localRet; rsRetVal (*pomsrGetSupportedTplOpts)(unsigned long *pOpts); unsigned long opts; int bArrayPassingSupported; /* does core support template passing as an array? */ CODESTARTmodInit *ipIFVersProvided = CURR_MOD_IF_VERSION; /* we only support the current interface specification */ CODEmodInit_QueryRegCFSLineHdlr /* check if the rsyslog core supports parameter passing code */ bArrayPassingSupported = 0; localRet = pHostQueryEtryPt((uchar*)"OMSRgetSupportedTplOpts", &pomsrGetSupportedTplOpts); if(localRet == RS_RET_OK) { /* found entry point, so let's see if core supports array passing */ CHKiRet((*pomsrGetSupportedTplOpts)(&opts)); if(opts & OMSR_TPL_AS_ARRAY) bArrayPassingSupported = 1; } else if(localRet != RS_RET_ENTRY_POINT_NOT_FOUND) { ABORT_FINALIZE(localRet); /* Something else went wrong, what is not acceptable */ } DBGPRINTF("omstdout: array-passing is %ssupported by rsyslog core.\n", bArrayPassingSupported ? "" : "not "); if(!bArrayPassingSupported) { DBGPRINTF("rsyslog core too old, shutting down this plug-in\n"); ABORT_FINALIZE(RS_RET_ERR); } The code first checks if the core supports the OMSRgetSupportedTplOpts() API (which is also not present in all versions!) and, if so, queries the core if the OMSR\_TPL\_AS\_ARRAY mode is supported. If either does not exits, the core is too old for this functionality. The sample snippet above then shuts down, but a plugin may instead just do things different. In omstdout, you can see how a plugin may deal with the situation. **In any case, it is recommended that at least a graceful shutdown is made and the array-passing capability not blindly be used.** In such cases, we can not guard the plugin from segfaulting and if the plugin (as currently always) is run within rsyslog's process space, that results in a segfault for rsyslog. So do not do this. Another possible mode is OMSR\_TPL\_AS\_JSON, where instead of the template a json-c memory object tree is passed to the module. The module can extract data via json-c API calls. It MUST NOT modify the provided structure. This mode is primarily aimed at plugins that need to process tree-like data, as found for example in MongoDB or ElasticSearch. Batching of Messages ~~~~~~~~~~~~~~~~~~~~ Starting with rsyslog 4.3.x, batching of output messages is supported. Previously, only a single-message interface was supported. With the **single message** plugin interface, each message is passed via a separate call to the plugin. Most importantly, the rsyslog engine assumes that each call to the plugin is a complete transaction and as such assumes that messages be properly committed after the plugin returns to the engine. With the **batching** interface, rsyslog employs something along the line of "transactions". Obviously, the rsyslog core can not make non-transactional outputs to be fully transactional. But what it can is support that the output tells the core which messages have been committed by the output and which not yet. The core can than take care of those uncommitted messages when problems occur. For example, if a plugin has received 50 messages but not yet told the core that it committed them, and then returns an error state, the core assumes that all these 50 messages were **not** written to the output. The core then requeues all 50 messages and does the usual retry processing. Once the output plugin tells the core that it is ready again to accept messages, the rsyslog core will provide it with these 50 not yet committed messages again (actually, at this point, the rsyslog core no longer knows that it is re-submitting the messages). If, in contrary, the plugin had told rsyslog that 40 of these 50 messages were committed (before it failed), then only 10 would have been requeued and resubmitted. In order to provide an efficient implementation, there are some (mild) constraints in that transactional model: first of all, rsyslog itself specifies the ultimate transaction boundaries. That is, it tells the plugin when a transaction begins and when it must finish. The plugin is free to commit messages in between, but it **must** commit all work done when the core tells it that the transaction ends. All messages passed in between a begin and end transaction notification are called a batch of messages. They are passed in one by one, just as without transaction support. Note that batch sizes are variable within the range of 1 to a user configured maximum limit. Most importantly, that means that plugins may receive batches of single messages, so they are required to commit each message individually. If the plugin tries to be "smarter" than the rsyslog engine and does not commit messages in those cases (for example), the plugin puts message stream integrity at risk: once rsyslog has notified the plugin of transaction end, it discards all messages as it considers them committed and save. If now something goes wrong, the rsyslog core does not try to recover lost messages (and keep in mind that "goes wrong" includes such uncontrollable things like connection loss to a database server). So it is highly recommended to fully abide to the plugin interface details, even though you may think you can do it better. The second reason for that is that the core engine will have configuration settings that enable the user to tune commit rate to their use-case specific needs. And, as a relief: why would rsyslog ever decide to use batches of one? There is a trivial case and that is when we have very low activity so that no queue of messages builds up, in which case it makes sense to commit work as it arrives. (As a side-note, there are some valid cases where a timeout-based commit feature makes sense. This is also under evaluation and, once decided, the core will offer an interface plus a way to preserve message stream integrity for properly-crafted plugins). The second restriction is that if a plugin makes commits in between (what is perfectly legal) those commits must be in-order. So if a commit is made for message ten out of 50, this means that messages one to nine are also committed. It would be possible to remove this restriction, but we have decided to deliberately introduce it to simplify things. Output Plugin Transaction Interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to keep compatible with existing output plugins (and because it introduces no complexity), the transactional plugin interface is build on the traditional non-transactional one. Well... actually the traditional interface was transactional since its introduction, in the sense that each message was processed in its own transaction. So the current ``doAction() entry point can be considered to have this structure (from the transactional interface point of view):`` :: doAction() { beginTransaction() ProcessMessage() endTransaction() } For the **transactional interface**, we now move these implicit ``beginTransaction()`` and ``endTransaction(()`` call out of the message processing body, resulting is such a structure: :: beginTransaction() { /* prepare for transaction */ } doAction() { ProcessMessage() /* maybe do partial commits */ } endTransaction() { /* commit (rest of) batch */ } And this calling structure actually is the transactional interface! It is as simple as this. For the new interface, the core calls a ``beginTransaction()`` entry point inside the plugin at the start of the batch. Similarly, the core call ``endTransaction()`` at the end of the batch. The plugin must implement these entry points according to its needs. But how does the core know when to use the old or the new calling interface? This is rather easy: when loading a plugin, the core queries the plugin for the ``beginTransaction()`` and ``endTransaction()`` entry points. If the plugin supports these, the new interface is used. If the plugin does not support them, the old interface is used and rsyslog implies that a commit is done after each message. Note that there is no special "downlevel" handling necessary to support this. In the case of the non-transactional interface, rsyslog considers each completed call to ``doAction`` as partial commit up to the current message. So implementation inside the core is very straightforward. Actually, **we recommend that the transactional entry points only be defined by those plugins that actually need them**. All others should not define them in which case the default commit behaviour inside rsyslog will apply (thus removing complexity from the plugin). In order to support partial commits, special return codes must be defined for ``doAction``. All those return codes mean that processing completed successfully. But they convey additional information about the commit status as follows: +----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | *RS\_RET\_OK* | The record and all previous inside the batch has been commited. *Note:* this definition is what makes integrating plugins without the transaction being/end calls so easy - this is the traditional "success" return state and if every call returns it, there is no need for actually calling ``endTransaction()``, because there is no transaction open). | +----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | *RS\_RET\_DEFER\_COMMIT* | The record has been processed, but is not yet commited. This is the expected state for transactional-aware plugins. | +----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | *RS\_RET\_PREVIOUS\_COMMITTED* | The **previous** record inside the batch has been committed, but the current one not yet. This state is introduced to support sources that fill up buffers and commit once a buffer is completely filled. That may occur halfway in the next record, so it may be important to be able to tell the engine the everything up to the previouos record is commited | +----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Note that the typical **calling cycle** is ``beginTransaction()``, followed by *n* times ``doAction()`` followed by ``endTransaction()``. However, if either ``beginTransaction()`` or ``doAction()`` return back an error state (including RS\_RET\_SUSPENDED), then the transaction is considered aborted. In result, the remaining calls in this cycle (e.g. ``endTransaction()``) are never made and a new cycle (starting with ``beginTransaction()`` is begun when processing resumes. So an output plugin must expect and handle those partial cycles gracefully. **The question remains how can a plugin know if the core supports batching?** First of all, even if the engine would not know it, the plugin would return with RS\_RET\_DEFER\_COMMIT, what then would be treated as an error by the engine. This would effectively disable the output, but cause no further harm (but may be harm enough in itself). The real solution is to enable the plugin to query the rsyslog core if this feature is supported or not. At the time of the introduction of batching, no such query-interface exists. So we introduce it with that release. What the means is if a rsyslog core can not provide this query interface, it is a core that was build before batching support was available. So the absence of a query interface indicates that the transactional interface is not available. One might now be tempted to think there is no need to do the actual check, but is is recommended to ask the rsyslog engine explicitly if the transactional interface is present and will be honored. This enables us to create versions in the future which have, for whatever reason we do not yet know, no support for this interface. The logic to do these checks is contained in the ``INITChkCoreFeature`` macro, which can be used as follows: :: INITChkCoreFeature(bCoreSupportsBatching, CORE_FEATURE_BATCHING); Here, bCoreSupportsBatching is a plugin-defined integer which after execution is 1 if batches (and thus the transactional interface) is supported and 0 otherwise. CORE\_FEATURE\_BATCHING is the feature we are interested in. Future versions of rsyslog may contain additional feature-test-macros (you can see all of them in ./runtime/rsyslog.h). Note that the ompsql output plugin supports transactional mode in a hybrid way and thus can be considered good example code. Open Issues ----------- - Processing errors handling - reliable re-queue during error handling and queue termination Licensing ~~~~~~~~~ From the rsyslog point of view, plugins constitute separate projects. As such, we think plugins are not required to be compatible with GPLv3. However, this is no legal advise. If you intend to release something under a non-GPLV3 compatible license it is probably best to consult with your lawyer. Most importantly, and this is definite, the rsyslog team does not expect or require you to contribute your plugin to the rsyslog project (but of course we are happy if you do). source/development/queueWorkerLogic.jpg0000664000175000017500000016401512704114446017372 0ustar rgerrgerJFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (<ow:?I|<{'n?נP’yBN?I|<{'n?zнrR_?^ۏ9^Q- tRA fjx{H.e7VvVD~ȭ43*$whe4GH-Zc7 xsIgyi$侎MHbA cWA|<z 3XrsimIu&7u91JMn-x"}1^O@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPs[M$Ue)d$}אG5S~eMN9mOy8\ \^uq?'Z ^uq?'Z (((((((((((((((((((+c]^^g_J ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( s2$ $r͎` =qjJ(_}o k|/jSBL*_\dA`c1Nm/i%bK(c͒c^\|EӮKl DO3+ʥ~ry'lWz5;-"6ZD&@՛䓎I&4(((((((((((((((((((+c]^^g_J ( ( ( ( ( ( ( ( ( ( ( ( ( ^gxjR [9'z?}? ?VP¬?8(YSqWQ@ gO9a^Ey*|sU>z?}? ?VP¬?8(YSqWQ@w'Hfx^_6 FW+pv Ď'*|s½U>?}? (V¬?8+(?YSqQ @<gO9aG*|s½U>?}? (V¬?8+(?YSqV|dC\,_fzg! 0zg5p*zQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEPEPEP^Odz %cQEQEQEQEhڶ5ɣGF̆A m.sgOs&L A5[.fq%!q&wa^[ZMHZ6pF9U`2, w$Jy>K_}yv:cn:go_?oR56=xĞY\ [nwFյnMo&0:?R6d2 mu:jh|% ivr\!;01PI' - nm-FVka[l߂IbzPWl>'~W&>b!drO>(l5ofR)v+D$"`$kW]Ť(ss|j7W}՗"DI`DK]L8N ;=*M*Kh@HahFA–V9`\u8WhXp[$s"DNS M,qJ$xT3մ[m`YyK\2B@ee H#ӎO[_~mKMFͨ^Y5aHGFr9ۏxShE嬸Q~ld=9 & JNW7 009Sͦlrc8s  MGZ[ZVCMѱA:3MsGDžpUA++zxS4^63N|wup V-,/&K EwTv2iǁls'em֒"3Bpdrկy]ob>8#5(tI$LeE^8EvU/.(H/rtޡ.FpGcXW>[MWSϵg"*TmIB@r3]'4tVZ(Š((nO@?Sn((((((((((((+c]^^g_J ( ( ( ( ( ( ( ( ( ( ( ( ( %cנWS+ƻ=(((Muzs5E k4-pf+\A QSݩMC$eS"̰_#nI?DŽ|\x>W8y ~Sn]k;\P7$ t||Г*)-LRմ\ZE4@vI: e8=+SѴٴi\Oso'3X"*2g,K)+I|"LKt0"@w|'$Vd[ՠ[ak5-q$d+ i _3}G^/|q؝9`K'+mdV 81V=9Иs@&:=^D;*+.3['+@ iUyόxn}:+K4K=&[ۥH,ʪnJ.퐗,B+}ԘW&5F(aV̗L~#6!G8%{(>H5NGc'|cHn`*od]|R ;r9Ŧlk.S1,'py^~:*5oZ~ΣJbhhn|6FnpCڦ8l5 IM%Ż c\nfX<*~S#[xOLijvŇ0Q9}.Acb!.uay75F<`3c3#y9oVՅk_ ~h3Kwsd/eFw W!X | W WDžq5큻2dchܹe2@OH8ʪ+ֶz|6ptC(b2?+gz+[AekIc\*Hr_``5^)-O ZɛB0Sq ۔4놹If{!WS#x]pbqkMz $23q :O JW rz6N-tu&hc;q bD A;{ 1?cm^UtXd]>d|Npy|Z}H*!(G'͕=^VGm3ιZ.3wq8ީ[O_y{3t;H]Dln.#ne"?ü=@5]NIsvWY{f" F̄ 0 wu_jT]VT;-cvvJ*i AoYM5ӛ[yZ=XJmqd#PFpFxh֪0ߗ]bMe3_`7h yoofϻY5OEՠAp|_%$e<6vG,H.pw'ݿ6wsqkMz $23q :חD+sk?oV Ҵ$H`I J[lzU;O^4iiח]Emg$FTDfbY8c;Zږk\I Ѷ2U`@#UZ]Ֆ:\HgCɂ0H!y=sFܕ{.x]WP=>R{&TXRU 9E:Zޑ{}]>Y / ybs*[uc9bew3F$a 0x y56-;WeG S23grK4GcS5/j׳A[,AF 8ũuaՊ@# :WZzy6j3NÞg$.^WS[$ ɳ̄M33<НwH>*$Z;!>ymwvlŚT?o]Z 1l˚KRF]Ca8dx2oX 7r}Omݷw8׭[~C.S1'pyZ&ͮ^R aIu  nO(Q$kBW7 rvS(C ( ( ( ( ( ( ( ( ( ( ( :}WW,ƻ=(((((((((((((>X/YңD)eIvw(lFzWq'T]@'~C?U?0T 4?C'T]@'~C?U?0T 4?C'T]@'~C?U?0T 4?C'T]@'~C?U?0T 4?C'T]@'~C?U?0T 4?C'T]@'~C?U?0T 4?C'T]@'~C?Urzn?ZK-/_ i-fYT7ځ*H8 4?C7Zp^QHA*@8EPEPEPEPEPEPEPEPEPEPEPEP^g_J :}PQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE-N-NQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEW,ƻgο5QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQQ&kyVH㜡]U*$gF}Ep~-Nn<}ỿiiמ}Ba2#BЙ2y#T.{cĥ,mѼ؟+>yˆl\m,@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEg:9{,W#|ύv̀p$^'SMO*OX*0p<2_aq|@/uV>SagH(j }3N˵!7'ZRF7,u-VF_)[圏&5$(\K_%&z"no]'>grw1*(P? |F犮KMR7dMO&Kdm' @BHRp:uQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEW,ƻgο5QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEU=WUOS7+Q'$kߊ|iX?s`FAր=Y4iej|n GVl' Sy?5sj1\HrT/Nʅ@?Ҿk_7W9v?s%ԇ%BtZ ((o~k:trNlwqc9 'i rrZE,.?3s}_Ŀl 9?QEzc7.M7Wc:мWf-u2  6K=v@Q@o}#KkiuKϳ€Z(7#q H8{V~d|$ZkknT`5)`rdķclj/7oټ[M-u?/KқQlJ2oM ]Mssfd5ЅꄀHpAoO1~u?+o1|M5MB6cJs1>a GR< ?/KқQlJ2oM|9w60j2,g:H)x Jqu-]k_5ì!ˈ nd2k_}e}{lKԖ)i`6.r:{E]sH6Ms$+ 26:@2+6Úbj2ʍR,t1f /E_BON{Y$jm4Mݿ*~]'wc u V(O}2HpFv< m+_+gwg<Lv7L𞹥麡D7rؙ#Kx39?ݵO$Uյ-B;"- -IN!?/~sn m?1Luy5{7Ibo%_6wq-v^wYGe5ibUmݱM&)Jva„F8={vztנu/+Rck/_wveuG{-+!Rp+WoTt6=4`\l 2[rǞLaW_E:u/sYZFQ՛FI2W?xܦG$6w<|60bvy ^xUX/CXKjJpqESy?5sj1\HrT/Nʅ>0Ӽi}'<]4rʟ͎3tQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPX!1ki^ƿp!q\Ey|~ρ6)CG5i-qlT - \]*gѵ_M..w ^+k DPH[ ƺ |F犮KMR7dMO&Kdm' @BHRp:uQEQEQEQEQYι{N{^ +U3q:`(8Pg:9{,W#|ύv̀p$^'SMO*OX*0p<2|'Q:o'Fr<@~0KJP'SMO*OX*0p<2|'Q:o'Fr<@~0KJPPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP^g_J :}PQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEW7sv5:9' ;I᱇ sJ(=X\g&5쿉xs's<1Þ*{+[-5HݒM67 ڣ6Œy;O7><?`cZ.bL`:ֆK]D).v9*peB|;O7><?`cZ.bL`:ֆK]D).v9*peBנQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEr/'DS\=bmUأ[P72Wpx_~$N\mK},Ql`7s@25"Lb|[y.*WEjM-ŝ۲OPL2Ad{ mQEQEQEW7sv5:9' ;I᱇ sJ( Ӽ)xU[Kas=3]se0`HJOuO\yڀ`;R Ӹ2ho_u@(((F^Gaj /n^MoZcλF#G_CBi\+nnn7tw 򣤰\GBLRFl2;*h.OЩ&0M[\Sl !i܍+3n8<>#jچq 5 "mW-!.b01 4?C'T]@tw?Q ߃kcG SCt?Mx?M4w?Q ߃kcG SCt?Mx?M4w?Q ߃kcG SCt?Mx?M4w?Q ߃kcG SCt?Mx?M4Ş+|AIkk2nB`p< ס*A<B?  h51ס*A<B?  h51ס*A<B?  h51ס*A<B?  h>:yW*|}ǚ,sAE|pdoFRA Wi'T]G SCt?MN9kSIXsj"kVU$ Wk9q[W|6zm_BǿR02wrxx?M4 4?CMס*NC^?  h*h.a ߃kcG'~C?Ux?M4 4?C ߃kcZf~oNc%K9v5'T]\,,ϊ_- 7d0F#E Np2I?zEQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEPEPEPEPEP^+'^^+'@EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP^/+]^jfiR3#Fc. ͅ<[MTPO)8yb*y89U=+Tִ}J{KOev8`QEQEQEQEQEQEQEQEQEQEW,ƻgο5QEQEQEQEQEQEQ\>!s1ؚ|fh'r#p#G<aEy-?sΏZ!xzB :?iԅtW ?'ROQ^ O/H^9?g@Cuo-QRHPF AbLF⟆;Nq̢8&R 0>@}H^9?g\_xڥ\pF_Â$`N k܊>xnCwēϮnb}#o⻊Z!xB : +iԅt ?'(?RO O/@H^9?gG-?s΀=Z!xX<+?q5"sO8 ( ( ( ( ( ( ( ( +-O~.妹ac߱'[kHꧽ\յ/:6}\/ +y.$Xb gPQ^g_uT_,F ]CpHwFɺ +ԍt&(?R7Mo\ѬC&+p@5GjOGC.#?^#25}o<=6ķ k]o,.A*sAFݠPmmⷷ8`GjQ@TwFɺ?ԍtW&R7MQ^o.H7@Ey?|IO>/l7 t\uAHXw#z>#sQп#Za["<8P((MAiHn.t`б'91ǭy}ؚG*Q@!E@Z4;]W^VQNu KFky23I$,T纃Qmtw=.oZ+ȴEm!սƧIzWʷ_wa+~ AcY-mfnVZo˨;a߽چv%켮)5ߧ$ \ʭ;]4pA",Vr0ab0 iKnK L\6iڋ Q |X Ⳕ\di~?44[|We-WNY+jSntWȯN;{xc$qơUp+W,ƻgο5씀 ( ( ( ( ( ( _?nO@̷y.iiE}wH&#P"!5=2K@19qKsDkd#wV <{PxEԵ>gnnR1 wG&;K%/mf[s۾hZoE`tHGwMm ͭO!tP1@ g^E.Qݮ+= =q@JgGTrۨ-xFC_5yQEQEQEQEQEQEQEQEy/$:DxIu_Ht/x҉+*E5yZ襮<RA@VQ!k|8-v z=*QEQEQEQEU[F]^b]`|ǜtTנWmCۿG^@Odz %cנPEPEPEP|)a)Bkآ=?VyV)8?8!Hac5 @AT߯[ U4Kx"k0::D꼱;kOOo+͡M dLS C^E>m[_\MOFFTo85嶞U%k[6堞ImY#FgmH{dwق prx4WO\xUմ5Ʒ5ZK$X^0kQ:w"E*%>R鷺|ހf &L[#X9Xx_hV4jmܶt/qTpx=[ؕ{{ 5LV(d,^F}/1Q ;MNk/z`eMe_ ,z+hw6sol1SZCFZ O BD˰PT1zS thw-{xt}n[8dma3)3U5 ZjZ6\G068Y;AIϡXwDʝ?F HsVSN+Xc9A _cbi=nbCqwV}fPIIEʹ#$1+ ꕝ[kHy pȲ3Abd3sm?$](ow: @y?k+)̕c]^@Q@Q@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEP^O ~(m72cszwFɺ?ԍuP&R7MנQ@o.H7^Ey]n#zwFɺIOßlE$[$ax9#'ڽb_5&R7MנQ@o.H7^Ey]n#zwFɺ?ԍuP&?Q:K7U-p$o,x'95PEPEPEPEPEPEPEPEPCI]xW_)%$B(RLl'\=n<9"Ѵc@HQ@׀;1,= ZqI/2 ; D.\o!SSKcxVΑ䓰[momlG 3rǎIMVlv_v1oq:Ե[ഫˈ{uw,o[toܻXU_ t9GZUԮ.6^}I#ZG$ q99}J,ϟgwjAog6d8UXPǑ}jHuw҈+6!J#@S+ƻ_5QEQEQEQEQEQEW,ƻgο5QEQEQEQEQEQEQEQEQEQEQEJg@<{wCmQtnU0On0BѰ>'ZGe}>$Ĵr2 RUPEz%QEQEQEQEQEQEQEQEQEQEQEQEy/$:DxIu{zevv2񕥬y $ IjICuo-Ǎk4I#V ` `8tyZ襮ooH8Ղ(1R¬?8((?YSqQ @gO9aG*|s€=U>r5?C2[]#gtՈvb.ۉ\h(?YSqQ @gO9aG*|s€=U>?}? >6!J#@7;gg/]ɍϩAR8 ¬¬?8(2Wv?=zy txPw} cIRQ  ( ( ( ( ( ( :}WW,ƻ=(((((( zqj03Y.X ,@85 ߃kc\~f9ueGm ܭ "= ܨPk*h.ס*NC^?  h*h.ס*NC^?  h*h.ס*NC^?  h*h.ס*NC^?  h*h.ס*E|ea~'[hdpmboES!SOЩ&A<BE?hvZE44bL c6'Mhw?Q'T]G SCt?M?0Tw?Q'T]G SCt?M?0Tw?Q'T]G SCt?M?0Tw?Q'T]G SCt?M?0Tw?Q'T]G SCt?M?0U[qo,sA*H2AG9#]_? ~ҭ5-~!ZTH\mmⷷ8`GjQ@PQEQEQEQEQEQEQEQEQEQEQENNQEQEQEQEQEQEQEQEQEQEQE ?ud@?Y3w%zQ@Q@Q@Q@Q@Sյ(tmTY +y.$X,U$ z^oWԴ}#͋j@؁hF$BKz,|#n-/q0+%FԐvI+\xGoop8*((((k%Iڥcfu8R(j*[/mc&Ur;{ ( ( ( ( (?oj4am٢ZSƤ/8.Tvu?17/xƶz"|j]V+q*Af20>\1H/.Hr)>b:PBda@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@y|Egzy|EgzQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@y9ᵷı^(y$(I$q3[ʶGBꭎ PA#=3+^/=Ewyj6R0b) c@M>?мO#E{߱O{Gz#N ug '\tmTxpii\3_^'"_h(?K[|C @/So4%P-ƀ=D!O?)@ +E?(G"_h+:>"FifiHvW<G M %Y ,d1 9k]F>i2EInCC?'U]L~AӠ(((+̼A{voLUo8E)0^PKcv.ͼFFbl<▻v#]}wOmBu)ֵ!mmzmGIƅFcp LJxKFK}Rk!fhF; -"LM2}*[KWFqFKoi63mC岺yvX.F/=M$1>oB7>d&  n'p; u(^ub־{|y^Omݟ8BZ ;{X̌DV ֢lv_v1oq:nՅm-]v- jo{Ma$&1y ǩU_[y&_8.&ngyT![((I5YDXLaQԴQUnK!d0 }cϥZ/ylX(X oCW  ux,jWd̛U՛ p7G( ( ( ( ( ( ( ( ( ( ( ( ^p'j/ZGwpD%XY#bd1QwU5ōKM=.w-6 p )pFПaZ=3[#rꭎ@b#=3*J((((((((((+c]^^g_J-|+X}~LS&ixam,`]gXNgw$0f !W=5-kVQ⺛P-&o-8-g#Ú拧\[[ A ֨azvk;['UH0F_={U;6Eߪ8_ _4Inf~)㻑bfw>P-r t~5ŴCEd`=BOJ_/۸zVW'>u s,0Dz(t6[rnwx9RY[_Ʒ],v#-.ɭ\X<ɂ|<#Ao \jW?f -գoS g"Ey_[XD[R(\0 gP@ ;UM䶚z׆/+mZIJi# ݴ8iSxoI><nBlȿg r'#56,it=6 ZA)x#V/7d3siXIen۠@1H4+~_[+n`pBێ~_o8z_m;"g2)U [7^މ<5ye,"H|ϴt,cMp/~:{#Mw1kf`.fD,~PBr)w/R(((((((((((}gYywx4r@c ~4_\ѬC&+p@5RvGJpM$`m-cW7R=wIdկա'r+ d^BgmVV|K-۬ڎ, jZM!00 m=R5KB/JY=tmWu41> 6K=v]QEQEQEQEQEQEQEQEQEQE ?ud@?Y3w%zQ@Q@Q@Q@q5RbWgid8l8]OzҼt/h> Դ>SLKxIٖܨB  e9xW𾝡ڶ"_yN]I,q3lW ?'ROQ^ O/H^9?g@Ey-?sΙŨ`x<iaC$zHeu# ދu?RO O/@H^9?gG-?s΀=Z!xB : +iԅt ?'(?RO O/@Q\!x|i3!dAaGb ?'j0=Z!xB : }oi7yv<>vXrp\?-?sιxXt JӻKtHmپvʿ T8n|!,#7soW])+(f? \@Xu~]I )<:Պ((((((((((_r^_ik7<4\X2HXzepZZǍO $< ^w'Kޅ&VV.Pg 91Tw¯5oR 8 ``~dG'Kޅ&VV.Pg 91Tw¯5oR 8 ``~dz$CkoQH8Ppb"@TP0%P?|+xZd.xA;\a;FpFqp_> դ 4j դ 4jw_ ŽZ?5nt*(#P(((((((((}gYywx4r@c ~4b_r^_ik7<4\X2Hyܟu/?zMZZ(Bzᜀ+@aRi o ռ{OMJ<2[l&B0)p4u/?zMZZ(Bzᜀ+@aRi o ռ{OMJ<2[l&B0)p5A VG  HB(q#mmⷷ8`GjQ@TQ@Q@Q@Q@Q@!1ki^ƿp!q\g"$:4{W#V,ѨM;UGP<Jt}\d:̀l+}p+?YaA{j;&L$OUl#<< }#s`lD9aPJt}\d:̀l+}p(((((((?Y3w%z||q-.MTw0XXb>A€>dkM{'^I"Oq.mU` ac.߇0@oJ ?%q(?tyCI\ +v<$?~Wn=]?a+7G.߇0@oJ ?%q(?tyCI\쵨>ՠ6com"}7Ѣ]Nؼhoa@ٿ|fZAm>He=~~T|gsF它[j}ʶ>{<(7|f-~k>zu~Wn]?a+7X +v<$?~Wn=]?a+7G.߇0@oJ ?%q(?tyCI\5k`%ga;/4ɧx E'vj\X-hE5ŭ\elbN#"-Cig؜ys;-{co|yuG\^.Pr N׊C nT_ݷocYߙv.x*ruEzb׷I,1Zr쳲@WCN-[NX1"4S nI麲bRN4d`cy?C.W1AqhB[c%yn7?6 u'ѵTkGý 8.$۸fPHτυ~~TwLh`.[^Ui_70l[zg3[_ӵߟAu/QEŠ((((+$xXeRG"WR0AY^Y48IkFkiX!d8yRnT>ح<2m-u_sy8(dV*1#aN_$MsQgOs+aEPEPEPEPEPEPEPEP Fk/;OkÐ~O6NX5g/eͱS{IHT).O zk_t/ཱུl vêʜEhW Fk/;OkÐ~O6NX5g/eͱS{IHT).O zk_t/ཱུl vêʜEhPEPX#ҵK=14D|+%@{j~+-m. u$-#FF1JC;? 6?mn W=NtvWjڪY5Z Aam@ݳ$sX^]A z+]DgPϙ%C5o^eg]I/UInZ%8C!@^>V+z_w_Emw*fBvdqV>Zu+}H0$0``ms!ĺvaIHфuڨCrw=/mޕMx]ҴCZ:HDkXJR`a$ ;F9;HYTe9qȬ/]T4EL6iy89\gJ֠{+Q@Š(Wx2ܾ7Gi<60 R7.x$W'%_o/n}ȏ/8;XpUPYxsF8);Hy᱄Js"9."|vh~v_.D|yºO |9nKRGgR:ًd# Hr P2:ucχ<+p];<['qRCJ=h((((+c]^^g_J ( ( ( ( ( ( ((P}Am6D/R6o39Eo?yVѧ|3mjuͶ>~~TwLh`.[^Ui_70l[zg3[_ӵߟAu/QEŠ((((Wm'_620~<-:qStvc9#qErr]|E- r7ʿ\]ts =z&~uóFduZ(ßxVmm$vy5+N0 #zYEQEQEQEQEQEQEW,ƻgο5QEQEQEQEQEQEQEQ֠Vm_7l;gsFt:bOgf=5>ՠ6com"}7Ѣ]Nؼhoa@ٿ|f-~k>^+Q@Q@Q@Q@cx[_ _\C>(szf¡cr1O`I[5Saq ٮd)m<6\VdR2{&+# RXePWR2#RVW85 _[j1AMa~Vm e?{- mڟH2C,2NXrxT=k( \C%`oUFT+BUO5 ^O}\`yx̀;^+}Ѵr>?{- mڟH2C,2NXrxT=h(\C%`oUFT+B +?oxV,d$uHp##zW7_l٭}/XrPIY]\wH \;1\ I FGLn;_<%!#oZ>Wm'_620ž-htqSlr|.yhtS~eMN9mOy8\ \(((((((((?Y3w%zyk((((((((AQ|ioHٿwtl:u[Fe|# ŷ{4kP}Am6D/R6o39Eo?yVѧ|3moZN~}ԽEV ( ( ( ( (0;Oh^Z\Z?_eUY>?6s8õe\k>|Gwmo٢Ss'#nVimEiQX (((((((((((((W>ڈ-y?qi2PxrFIoN_ Gšm4D:4llm`xJ ^p'j9p6s%ܟF oLh֠Vm_7l;gsFt:bOgf= z(QEQEQEQEQEejwrZjW˩J?`I" W3p]W=pZ_traG2ae[p_%QEŠ(((((((((((((_W"3Iڽ_W"3Iڀ=(((((((((((gο5 ?ud@(((((((ڴFmmO_#f=4X>ˠcm}<(7ޙѭAQ|ioHٿwtl:u[Fe|# ŷ{5qk;_mRQX (((((BM(nCG 0%H17$qPx~e{* \FvG'25X~Ε-N_72}W[6|oC p=xFK_u7(aEPEPEPEPEPEPEPEPEPEPEPEPEP^/+^^/+@EPEPEPEPEPEPEPEPEPEPEP^g_J :}PQEQEQEQEQEQEQEGZZo?'|/ʑ,etʶ>F oLh֠Vm_7l;gsFt:bOgf= z(QEQEQEQEQEaj3 n>k0 $aoi-EYA$Cw[ך=5(QEQEQEQEQEQEQEQEqzě'Z- ^#k9a.7*9+ϧ=rB :?iԅtW ?'ROQ^ O/H^9?g@Ey-?sΏZ!xzB :?iԅtxM5? &y=.,6B0R+dJkI\@λ-2HG^4EXё^ O/<~ɥYՠ6com"}7h}@X_3,t|f]>6fʹ>ʲyflzgk<]uv0jDD1A XGɜVO[Ͽk6 ksyH$A1HTC"??*hGL/sszvPt u68k9i/?;_wT&ՠ\Y$7PK:0hXּi[jt8$Kn'y]tQV.IQ6׺WPWY揈 ,=↬%{/EyJL3j>s6a.!RX544JaERQEQEV>K[cWO.T1"U* ϣ]PM<"[Z_zu{rA_Ԯ]Unj܈Uc%Ђ0H i{wecyڕ\߬kja,<ӧ[h NXw կzKK|wq±ҭWڌ/=v%g.B1. Mhhw3j3=Sdp2 ]'ٿ=(EPEPEPEPs  !y$($s>1\]xPu#G1H$>B W'=Ba;_Zoaӡ&sUf؀ d荎s{ }3N˵!7'ZEUR.khn/*r?(g<]kd"1wt'{֠Ӽ[zg pL 7I*GjܢmC]صf;h0y{eYjViycyouj<`Ed';$k[Hyy+7o#<.sҿm2ogEI eXGr*{=BOrY4YBN33# ۜd@tEP{}3N˵J\jOoȔ3.YO]G Gݞ/Iq$7#[Ghwt38@wpUH,,m:?.$NPNhQ@Q@Q@Q@Q@yk++c]@EPEPEPEPEPEPEP,+{il@W:Ìn;aK·>f}éY8|cnVWGh.^XVdɖ+YgFy#rm=9cR (,NQ95Š((((((KѴ2>Gԣ.ve.&a Y׼,5H`i1$,Z]A#ϙr-wXu]n Vs\Wd\11+|K}}ExvC`UI JLL`|8*Khw,.s HҬsZv9f޴ZK Til*69>]>K-Owq $''ZTPEPEPEPEPEOVԡѴkRdh,丑cTR 3(<qc]?j_řLG lޑ^Fkߦu}zWo&!2)*C]g(FwsXam;X8u 2`Y?*űm=]o5մd qh7 Agvz-w_0<~[RU'Xm+˺<].B,h@PCc]ς[k=N+FGBqsvwX]jVp^\cɷuY$*ϥZ҆i1U$(bg9 AЃM=-?p )ˋeլ'7$D(bXci%hsa,7&mP |6ckuV? J\Z +'Ojk;aay6.< Wr>#<A TvӴLXKx:\b\F_#IdMmoe;ׇ#Ddp>fEnCŋ[ YDܭӱsu];G[N`K5,yXOϯ(;Z?GsHٞ񥖥^M -]tƫ@6V KM)]:WvIi@xۀ|}šybG~+r8*OJڟVmaP+BUa$~S>ֆ׵ [_Q{2n ͡꤮3It66pj㶙~2#C#<?W[]彵Ŷg<7NRHVYg!8b6Tn\A'6a%K~-N{zd>][/-#) JԚZx;MC̖v$pTgR|q5n6qЫli-fYT6*Hޙwi6XjVw5$dmRrrxu1Gj:?'Ěq3j6 n"\+F"-+8&@IS>BĚȶִyb)ۂs2=ic3^,Zƞd rہ\t5<5M*Ek;xȐq#|wIi6դV3k".BFzeq uRggid98]=zҀ ( ( ( ( ( Duk.-ʟgL*)TUPyCI\?v<$?z~Wn]?a+7^Ey.߇0oJנQ@ ?%quPyCI\?v<$?z~Wn]?a+7^Ey.߇0oJנQ@G5/ }géY7{soJI / cl?>7g[*_W ?%quV<oJ ?%q(?tyCI\ (v<$?~Wn]?a+7G.߇0@<oJ ?%q(?tyCI\ (?KqlZ$K¡"'˓uk;]SFм1,jYpx|>\g1[g;ߛnui ?%quV<oJ ?%q(?tyCI\ (v<$?~Wn]?a+7G.߇0@<oJ ?%q(?uz=uAq)Cm((;J)<:h3w]gZI$4NI>p]~d8!zDCkoQH8Ppb(m~aM"n yn~b1g5_O_E:[fd+*2qwNu/q~!ۛMEdҖ%{%cH8֭u}j-f[;u ipcPIN @m?w8&*Ih5ǖw/mwiY9N @|I8u굇tnI[[+! -Ue5O y>PL7rmI 'iu(8 m펥jwZvͥkAʱHks<zi@F7˻c=I&Sۻ?2[\X=CkӪX^G\FJR0FF҇5^_MF}L}m|9se$rڴ>c d vܹ^F5k1q&&cVˤ] #hdA߼h;j0ګ6jjN5qдQBghcp6u鐮ecQ*(@QE!yĢ|M_ .nQydTrTGW=u7f}éY8|cnVWGhEV ( ( ( ( ( ( <+iuMNK!eL]aǏ omc>}+nk\OEW8Š((((((((((5' _-F;QK`,@7׵)v˧Zim[ox/ H[h*~l+JqMf}éY8|cnV,+{il@W:Ìn;o'z_m^֊QE`0((((((=c:u/2[,^p$u%鹈!RX(Y49gIkF[$Ք!d929Rvt>٭>}ߨss*K 9#`FApAJhQEQEQEQEQEQEQEQEQEQEAwsHVO"iK{aM7]tnO` Qvi6vs=@Iq&wJʠ9$䑞ZwO:X/`8+NNݰ8 ZبQEŠ(((((((((((((((((((( ?XixVgu??wom?|͟j?Sqzܭq~K]B(QEQEQEQEQEQEST[&"i`t;- RJzfN/\x{OxeAm9 k VaoCJoh~rM?VkV+m=PEV# ( ( ( ( ( ( ( ( Ok\ /(`ʜIp vl ŚZ\i0D62H8C8 5:vnkح:¬ZF,]f%,n}+7WeVدnƮGec,#}⣦[g}OV0&C$A/H]߻ȍa<ɹ9I& _wIt6W8VK0ȉ>G<xkfЮ&ly,e>֦v}?-v~{Es SiIbv隠\c(D ;tXI(QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEaK·>f}éY8|cnV,+{il@W:Ìn;o'z_m^֊QE`0(((((((WĘ}9zNȼ>F߻ַ+ +o᱒6̓Y7yH tu]]B}ןM?NĂ(qQ@Q@Q@Q@Q@Q@Q@Q@Զiܥ h%3]Q#/Mb:!}cj̶t dy v%UP۶22ȗ0%5j\W* frT@rqҭ&+*Kq ã=\{7d2e9^Mt>ESֺ|cD'p<:YEfӿ_?G g05oiO.$",܂dat}"%lh]_Ā1`AuSl?97 JO@oͱ6ܙIb^=R(((((((((((((((((((?^6}nO7{rac[Oo3gھcw1޷+y?E_jvWP+Q@Q@Q@Q@Q@Q@Q@~+ҢbOl[]ŗ"*eM˚8 m8a<ҠZuԒH7I+vڽ+lvEV ( ( ( ( ( ( ( eɵV' {gjeiW0k>mueyfwCg,0my/У{ZSrZ/Ϣv-ieioi$$O$O5n*%'&'vQE ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (0ac[Oo3gھcw1޷+?^6}nO7{rU=/WkEu (QEQEQEQEQEQEQEV/ץKo&yas-~ϙUWgN(8kr/^mgΐE ikxC:ZHSoMsS>wd'EV ( ( ( ( ( ( (3u,{=_ۡoȑ ⣌洫*o /mAA5[j/Z(.QEŠ(((((((((((((((((((((( ?XixVgu??wom?|͟j?Sqzܭq~K]B(QEQEQEQEQEQEQEu}/X[k;"-L.|c;_4tm85X~+ҢbOl[]ŗ".j7WuQX ((((((+7XV[;]up ^q1gRXG$rX u=nӥh r%${Ul4#i1i&y~}1>ƕu~]K IvZ+6wc (Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@xÿxnGuuH5bm`'_P =F𮯪[ƭ=*Y 2=Ezs;y_]覠/_f|+j:{e ċBt @ʓSZ?}? < $_ K]y*|sU>z?}? ?VP¬?8(YSqWQ@ gO9a^Ey*|sU>z?}? ?VP¬?8(YSqWQ@ gO9a^Ey [+^3LXM_q)r*oU>zNRiE gO9a^EH _߃<]M7\njw60 Gz_Ht/x҉(YSqV_~ͣxWW-uVkM\,XRد`?SnK[|C @</So4?`NUM;;|C /So5RE?(G"_k(?K[|C @</So4%P-ƽD!O?)@ (E?(G"_k(?K[|C @8 o MK[z%P-ƏD!OנQH?K[s}3UM-^ߟ38S^^g_J?E?(G"_k(ᖭzvhiły  * O~k?Y3w%zQEQEQEQEQEQEQEQEQE_WWCI@\xW_)OY][$I\X&E'Pr :|ogrݢ#A.N %c@Et^+njn\h@sA힙oFa%[-Gu-Or]#G<z[u;5;+& 0#zיimhz۟\â\[$ztVǽ@d9Qm23MN&lEsmd$Dv)8 {oO-mv?"=qk|Q< rNҹ8V}*j62Ek*^۴wg%R&8-x yt+Mk[>wImY#Gu rif.@KLLIl^UgG㴶}wL[k+o3]RV_W:Ot,rxm$es"I27(b0Tү/moĶkkg N9κ|A-MSIoql_"1nA}i\j c28PHtxrXѼg4w6Izo )2 TFynpxi(/omCLڴtɾ;oSžrF(\QZ_:mJ=omK7Vgk~pj+sHcn[,eǗs-,OFk<,Ey.4y F*O-J^6e5{i!h8!YIUHIYu%zt:[nb3@U>lc2/#GAsVFUHa3p qF:kӭ?tMPZi]OgN4L0&Q[k6+*M`ӵk4Uԁ%< ,呌F9PFSpM s֠;y T',/I}5)$3j(((+ !пJ$@?%$B(=`_. **Please note that this document is outdated and does not longer reflect the specifics of the queue object. However, I have decided to leave it in the doc set, as the overall picture provided still is quite OK. I intend to update this document somewhat later when I have reached the "store-and-forward" milestone.** Some definitions ---------------- A queue is DA-enabled if it is configured to use disk-assisted mode when there is need to. A queue is in DA mode (or DA run mode), when it actually runs disk assisted. Implementation Details ---------------------- Disk-Assisted Mode ~~~~~~~~~~~~~~~~~~ Memory-Type queues may utilize disk-assisted (DA) mode. DA mode is enabled whenever a queue file name prefix is provided. This is called DA-enabled mode. If DA-enabled, the queue operates as a regular memory queue until a high water mark is reached. If that happens, the queue activates disk assistance (called "runs disk assisted" or "runs DA" - you can find that often in source file comments). To do so, it creates a helper queue instance (the DA queue). At that point, there are two queues running - the primary queue's consumer changes to a shuffle-to-DA-queue consumer and the original primary consumer is assigned to the DA queue. Existing and new messages are spooled to the disk queue, where the DA worker takes them from and passes them for execution to the actual consumer. In essence, the primary queue has now become a memory buffer for the DA queue. The primary queue will be drained until a low water mark is reached. At that point, processing is held. New messages enqueued to the primary queue will not be processed but kept in memory. Processing resumes when either the high water mark is reached again or the DA queue indicates it is empty. If the DA queue is empty, it is shut down and processing of the primary queue continues as a regular in-memory queue (aka "DA mode is shut down"). The whole thing iterates once the high water mark is hit again. There is one special case: if the primary queue is shut down and could not finish processing all messages within the configured timeout periods, the DA queue is instantiated to take up the remaining messages. These will be preserved and be processed during the next run. During that period, the DA queue runs in "enqueue-only" mode and does not execute any consumer. Draining the primary queue is typically very fast. If that behaviour is not desired, it can be turned of via parameters. In that case, any remaining in-memory messages are lost. Due to the fact that when running DA two queues work closely together and worker threads (including the DA worker) may shut down at any time (due to timeout), processing synchronization and startup and shutdown is somewhat complex. I'll outline the exact conditions and steps down here. I also do this so that I know clearly what to develop to, so please be patient if the information is a bit too in-depth ;) DA Run Mode Initialization ~~~~~~~~~~~~~~~~~~~~~~~~~~ Three cases: #. any time during queueEnqObj() when the high water mark is hit #. at queue startup if there is an on-disk queue present (presence of QI file indicates presence of queue data) #. at queue shutdown if remaining in-memory data needs to be persisted to disk In **case 1**, the worker pool is running. When switching to DA mode, all regular workers are sent termination commands. The DA worker is initiated. Regular workers may run in parallel to the DA worker until they terminate. Regular workers shall terminate as soon as their current consumer has completed. They shall not execute the DA consumer. In **case 2**, the worker pool is not yet running and is NOT started. The DA worker is initiated. In **case 3**, the worker pool is already shut down. The DA worker is initiated. The DA queue runs in enqueue-only mode. In all cases, the DA worker starts up and checks if DA mode is already fully initialized. If not, it initializes it, what most importantly means construction of the queue. Then, regular worker processing is carried out. That is, the queue worker will wait on empty queue and terminate after an timeout. However, If any message is received, the DA consumer is executed. That consumer checks the low water mark. If the low water mark is reached, it stops processing until either the high water mark is reached again or the DA queue indicates it is empty (there is a pthread\_cond\_t for this synchronization). In theory, a **case-2** startup could lead to the worker becoming inactive and terminating while waiting on the primary queue to fill. In practice, this is highly unlikely (but only for the main message queue) because rsyslog issues a startup message. HOWEVER, we can not rely on that, it would introduce a race. If the primary rsyslog thread (the one that issues the message) is scheduled very late and there is a low inactivity timeout for queue workers, the queue worker may terminate before the startup message is issued. And if the on-disk queue holds only a few messages, it may become empty before the DA worker is re-initiated again. So it is possible that the DA run mode termination criteria occurs while no DA worker is running on the primary queue. In cases 1 and 3, the DA worker can never become inactive without hitting the DA shutdown criteria. In **case 1**, it either shuffles messages from the primary to the DA queue or it waits because it has the hit low water mark. In **case 3**, it always shuffles messages between the queues (because, that's the sole purpose of that run). In order for this to happen, the high water mark has been set to the value of 1 when DA run mode has been initialized. This ensures that the regular logic can be applied to drain the primary queue. To prevent a hold due to reaching the low water mark, that mark must be changed to 0 before the DA worker starts. DA Run Mode Shutdown ~~~~~~~~~~~~~~~~~~~~ In essence, DA run mode is terminated when the DA queue is empty and the primary worker queue size is below the high water mark. It is also terminated when the primary queue is shut down. The decision to switch back to regular (non-DA) run mode is typically made by the DA worker. If it switches, the DA queue is destructed and the regular worker pool is restarted. In some cases, the queue shutdown process may initiate the "switch" (in this case more or less a clean shutdown of the DA queue). One might think that it would be more natural for the DA queue to detect being idle and shut down itself. However, there are some issues associated with that. Most importantly, all queue worker threads need to be shut down during queue destruction. Only after that has happened, final destruction steps can happen (else we would have a myriad of races). However, it is the DA queues worker thread that detects it is empty (empty queue detection always happens at the consumer side and must so). That would lead to the DA queue worker thread to initiate DA queue destruction which in turn would lead to that very same thread being canceled (because workers must shut down before the queue can be destructed). Obviously, this does not work out (and I didn't even mention the other issues - so let's forget about it). As such, the thread that enqueues messages must destruct the queue - and that is the primary queue's DA worker thread. There are some subtleties due to thread synchronization and the fact that the DA consumer may not be running (in a **case-2 startup**). So it is not trivial to reliably change the queue back from DA run mode to regular run mode. The priority is a clean switch. We accept the fact that there may be situations where we cleanly shut down DA run mode, just to re-enable it with the very next message being enqueued. While unlikely, this will happen from time to time and is considered perfectly legal. We can't predict the future and it would introduce too great complexity to try to do something against that (that would most probably even lead to worse performance under regular conditions). The primary queue's DA worker thread may wait at two different places: #. after reaching the low water mark and waiting for either high water or DA queue empty #. at the regular pthread\_cond\_wait() on an empty primary queue Case 2 is unlikely, but may happen (see info above on a case 2 startup). **The DA worker may also not wait at all,** because it is actively executing and shuffling messages between the queues. In that case, however, the program flow passes both of the two wait conditions but simply does not wait. **Finally, the DA worker may be inactive**\ (again, with a case-2 startup). In that case no work(er) at all is executed. Most importantly, without the DA worker being active, nobody will ever detect the need to change back to regular mode. If we have this situation, the very next message enqueued will cause the switch, because then the DA run mode shutdown criteria is met. However, it may take close to eternal for this message to arrive. During that time, disk and memory resources for the DA queue remain allocated. This also leaves processing in a sub-optimal state and it may take longer than necessary to switch back to regular queue mode when a message burst happens. In extreme cases, this could even lead to shutdown of DA run mode, which takes so long that the high water mark is passed and DA run mode is immediately re-initialized - while with an immediate switch, the message burst may have been able to be processed by the in-memory queue without DA support. So in short, it is desirable switch to regular run mode as soon as possible. To do this, we need an active DA worker. The easy solution is to initiate DA worker startup from the DA queue's worker once it detects empty condition. To do so, the DA queue's worker must call into a "*DA worker startup initiation*\ " routine inside the main queue. As a reminder, the DA worker will most probably not receive the "DA queue empty" signal in that case, because it will be long sent (in most cases) before the DA worker even waits for it. So **it is vital that DA run mode termination checks be done in the DA worker before it goes into any wait condition**. Please note that the "*DA worker startup initiation*\ " routine may be called concurrently from multiple initiators. **To prevent a race, it must be guarded by the queue mutex**\ and return without any action (and no error code!) if the DA worker is already initiated. All other cases can be handled by checking the termination criteria immediately at the start of the worker and then once again for each run. The logic follows this simplified flow diagram: .. |image0| image:: queueWorkerLogic.jpg Some of the more subtle aspects of worker processing (e.g. enqueue thread signaling and other fine things) have been left out in order to get the big picture. What is called "check DA mode switchback..." right after "worker init" is actually a check for the worker's termination criteria. Typically, **the worker termination criteria is a shutdown request**. However, **for a DA worker, termination is also requested if the queue size is below the high water mark AND the DA queue is empty**. There is also a third termination criteria and it is not even on the chart: that is the inactivity timeout, which exists in all modes. Note that while the inactivity timeout shuts down a thread, it logically does not terminate the worker pool (or DA worker): workers are restarted on an as-needed basis. However, inactivity timeouts are very important because they require us to restart workers in some situations where we may expect a running one. So always keep them on your mind. Queue Destruction ~~~~~~~~~~~~~~~~~ Now let's consider **the case of destruction of the primary queue.**\ During destruction, our focus is on loosing as few messages as possible. If the queue is not DA-enabled, there is nothing but the configured timeouts to handle that situation. However, with a DA-enabled queue there are more options. If the queue is DA-enabled, it may be *configured to persist messages to disk before it is terminated*. In that case, loss of messages never occurs (at the price of a potentially lengthy shutdown). Even if that setting is not applied, the queue should drain as many messages as possible to the disk. For that reason, it makes no sense to wait on a low water mark. Also, if the queue is already in DA run mode, it does not make any sense to switch back to regular run mode during termination and then try to process some messages via the regular consumer. It is much more appropriate the try completely drain the queue during the remaining timeout period. For the same reason, it is preferred that no new consumers be activated (via the DA queue's worker), as they only cost valuable CPU cycles and, more importantly, would potentially be long(er)-running and possibly be needed to be cancelled. To prevent all of that, **queue parameters are changed for DA-enabled queues:** the high water mark is to 1 and the low water mark to 0 on the primary queue. The DA queue is commanded to run in enqueue-only mode. If the primary queue is *configured to persist messages to disk before it is terminated*, its SHUTDOWN timeout is changed to to eternal. These parameters will cause the queue to drain as much as possible to disk (and they may cause a case 3 DA run mode initiation). Please note that once the primary queue has been drained, the DA queue's worker will automatically switch back to regular (non-DA) run mode. **It must be ensured that no worker cancellation occurs during that switchback**. Please note that the queue may not switch back to regular run mode if it is not *configured to persist messages to disk before it is terminated*. In order to apply the new parameters, **worker threads must be awakened.** Remember we may not be in DA run mode at this stage. In that case, the regular workers must be awakened, which then will switch to DA run mode. No worker may be active, in that case one must be initiated. If in DA run mode and the DA worker is inactive, the  "*DA worker startup initiation*\ " must be called to activate it. That routine ensures only one DA worker is started even with multiple concurrent callers - this may be the case here. The DA queue's worker may have requested DA worker startup in order to terminate on empty queue (which will probably not be honored as we have changed the low water mark). After all this is done, the queue destructor requests termination of the queue's worker threads. It will use the normal timeouts and potentially cancel too-long running worker threads. **The shutdown process must ensure that all workers reach running state before they are commanded to terminate**. Otherwise it may run into a race condition that could lead to a false shutdown with workers running asynchronously. As a few workers may have just been started to initialize (to apply new parameter settings), the probability for this race condition is extremely high, especially on single-CPU systems. After all workers have been shut down (or cancelled), the queue may still be in DA run mode. If so, this must be terminated, which now can simply be done by destructing the DA queue object. This is not a real switchback to regular run mode, but that doesn't matter because the queue object will soon be gone away. Finally, the queue is mostly shut down and ready to be actually destructed. As a last try, the queuePersists() entry point is called. It is used to persists a non-DA-enabled queue in whatever way is possible for that queue. There may be no implementation for the specific queue type. Please note that this is not just a theoretical construct. This is an extremely important code path when the DA queue itself is destructed. Remember that it is a queue object in its own right. The DA queue is obviously not DA-enabled, so it calls into queuePersists() during its destruction - this is what enables us to persist the disk queue! After that point, left over queue resources (mutexes, dynamic memory, ...) are freed and the queue object is actually destructed. source/development/config_data_model.rst0000664000175000017500000001554213223143453017541 0ustar rgerrgerThe rsyslog config data model ============================= This document describes the config data model on a high layer. For details, it is suggested to review the actual source code. The aim of this document is to provide general understanding for both rsyslog developers as well as developers writing config management systems. Objects ======= Most config objects live in a flat space and are global to rsyslog. However, actual rule processing is done via a script-like language. These config scripts need to be represented via a tree structure. Note that the language as currently implemented is Turing-complete if the user makes use of very tricky constructs. It was never our intention to provide a Turing-complete language and we will probably try to disable these tricks in the future. However, this is not a priority for us, as these users get what they deserve. For someone involved with the config, it probably is sufficient to know that loops are **not** supported by the config language (even though you can create loop-like structures). Thus, a tree is fully sufficient to represent any configuration. In the following sections, we'll quickly describe variables/properties, flat structure elements and the execution tree. Variables/Properties -------------------- Rsyslog supports * traditional syslog (RFC-based) message properties * structured data content, including any non-syslog properties * Variables - global - local - message-enhancing (like message properties) A description of these properties and variables is available elsewhere. As far as a config processor is concerned, the important thing to know is that they be used during template definitions and script operations. Flat Elements ------------- Global Parameters ^^^^^^^^^^^^^^^^^ This element must contain all global parameters settable by rsyslog. This includes elements from the global() as well as main_queue() config statements. As of this writing, some global parameter can only be set by legacy statements. Note that main_queue() actually is a full queue definition. Modules ^^^^^^^ This contains all loaded modules, among others: * input modules * output modules * message modification modules * message parsers Note that for historical reasons some output modules are directly linked into rsyslog and must not be specified. Each module must be given only once. The data object must contain all module-global parameters. Inputs ^^^^^^ Describes all defined inputs with their parameters. Is build from the input() statement or its legacy equivalent (ugly). Contains links to * module used for input * ruleset used for processing Rulesets ^^^^^^^^ They contain the tree-like execution structure. However, rulesets itself are flat and cannot be nested. Note that there exists statements that permit rulesets to call into each other, but all rulesets are in the same flat top-level space. Note that a ruleset has an associated queue object which (by default) operates in direct mode. As a reminder, direct queues do not queue or buffer any of the queue elements. In most cases this is sufficient, but if the ruleset is bound to an input or is used to run multiple actions independently (e.g., forwarding messages to two destinations), then you should configure the associated queue object as a real queue. See the :doc:`Understanding rsyslog Queues <../concepts/queues>` or :doc:`Turning Lanes and Rsyslog Queues <../whitepapers/queues_analogy>` docs for more information. Hierarchical Elements --------------------- These are used for rule execution. They are somewhat hard to fit into a traditional config scheme, as they provide full tree-like branching structure. Basically, a tree consists of statements and evaluations. Consider the ruleset to be the root of the execution tree. It is rather common that the tree's main level is a long linked list, with only actions being branched out. This, for example, happens with a traditional rsyslog.conf setting, which only contains files to be written based on some priority filters. However, one must not be tricked into thinking that this basic case is sufficient to support as enterprise users typically create far more complex cases. In essence, rsyslog walks the tree, and executes statements while it does so. Usually, a filter needs to be evaluated and execution branches based on the filter outcome. The tree actually **is** an AST. Execution Statements ^^^^^^^^^^^^^^^^^^^^ These are most easy to implement as they are end nodes (and as such nothing can be nested under them). They are most importantly created by the action() config object, but also with statements like "set" and "unset". Note that "call" is also considered a terminal node, even though it executes *another* ruleset. Note that actions have associated queues, so a queue object and its parameter need to be present. When building configurations interactively, it is suggested that the default is either not to configure queue parameters by default or to do this only for actions where it makes sense (e.g. connection to remote systems which may go offline). Expression Evaluation ^^^^^^^^^^^^^^^^^^^^^ A full expression evaluation engine is available who does the typical programming-language type of expression processing. The usual mathematical, boolean and string operations are supported, as well as functions. As of this writing, functions are hard-coded into rsyslog but may in the future be part of a loadable module. Evaluations can access all rsyslog properties and variables. They may be nested arbitrarily deep. Control-of-Flow Statements ^^^^^^^^^^^^^^^^^^^^^^^^^^ Remember that rsyslog does intentionally not support loop statements. So control-of-flow boils down to * conditional statements - "if ... then ... else ..." - syslog PRI-based filters - property-based filters * stop Where "stop" terminates processing of this message. The conditional statements contain subbranches, where "if" contains both "then" and "else" subbranches and the other two only the "then" subbranch (Note: inside the execution engine, the others may also have "else" branches, but these are result of the rsyslog config optimizer run and cannot configured by the user). When executing a config script, rsyslog executes the subbranch in question and then continues to evaluate the next statement in the currently executing branch that contained the conditional statement. If there is no next statement, it goes up one layer. This is continued until the last statement of the root statement list is reached. At that point execution of the message is terminated and the message object destructed. Again, think AST, as this is exactly what it is. Note on Queue Objects --------------------- Queue objects are **not** named objects inside the rsyslog configuration. So their data is always contained with the object that uses the queue (action(), ruleset(), main_queue()). From a UI perspective, this unfortunately tends to complicate a config builder a bit. source/development/dev_codestyle.rst0000664000175000017500000000116513223143030016737 0ustar rgerrgerrsylog code style ================= **Note**: code style is still under construction. This guide lists some basic style requirements. **Code that does not match the code style guide will not pass CI testing.** The following is required right now: * we use ANSCI C99 * indention is done with tabs, not spaces * trailing whitespace in lines is not permitted * lines longer than 140 characters are not permitted; also, it is advised to keep lines shorter than 120 characters unless there is a good reason. The 120 char rule is not enforced, but everything over 140 chars is rejected and must be reformatted. source/development/index.rst0000664000175000017500000000006612704114446015230 0ustar rgerrgerDevelopment =========== .. toctree:: :glob: * source/development/generic_design.rst0000664000175000017500000002072512704114446017072 0ustar rgerrgerGeneric design of a syslogd --------------------------- Written 2007-04-10 by `Rainer Gerhards `_ The text below describes a generic approach on how a syslogd can be implemented. I created this description for some other project, where it was not used. Instead of throwing it away, I thought it would be a good addition to the rsyslog documentation. While rsyslog differs in details from the description below, it is sufficiently close to it. Further development of rsyslog will probably match it even closer to the description. If you intend to read the rsyslog source code, I recommend reading this document here first. You will not find the same names and not all of the concepts inside rsyslog. However, I think your understanding will benefit from knowing the generic architecture. :: +-----------------+ | "remote" PLOrig | +-----------------+ | I +--------+-----+-----+ +-----+-------+------+-----+ P | PLOrig | GWI | ... | | GWO | Store | Disc | ... | C +--------+-----+-----+ +-----+-------+------+-----+ | | ^ v v | +--------------+ +------------+ +--------------+ | PLGenerator | | RelayEng | | CollectorEng | +--------------+ +------------+ +--------------+ | ^ ^ | | | v v | +-------------+ +------------+ +--------------+ | PLG Ext | | RelEng Ext | | CollcEng Ext | +-------------+ +------------+ +--------------+ | ^ ^ | | | v v | +--------------------------------------------------------------+ | Message Router | +--------------------------------------------------------------+ | ^ v | +--------------------------------------------------------------+ | Message CoDec (e.g. RFC 3164, RFCYYYY) | +--------------------------------------------------------------+ | ^ v | +---------------------+-----------------------+----------------+ | transport UDP | transport TLS | ... | +---------------------+-----------------------+----------------+ Generic Syslog Application Architecture - A "syslog application" is an application whose purpose is the processing of syslog messages. It may be part of a larger application with a broader purpose. An example: a database application might come with its own syslog send subsystem and not go through a central syslog application. In the sense of this document, that application is called a "syslog application" even though a casual observer might correctly call it a database application and may not even know that it supports sending of syslog messages. - Payload is the information that is to be conveyed. Payload by itself may have any format and is totally independent from to format specified in this document. The "Message CoDec" of the syslog application will bring it into the required format. - Payload Originators ("PLOrig") are the original creators of payload. Typically, these are application programs. - A "Remote PLOrig" is a payload originator residing in a different application than the syslog application itself. That application may reside on a different machine and may talk to the syslog application via RPC. - A "PLOrig" is a payload originator residing within the syslog application itself. Typically, this PLOrig emits syslog application startup, shutdown, error and status log messages. - A "GWI" is a inbound gateway. For example, a SNMP-to-syslog gateway may receive SNMP messages and translate them into syslog. - The ellipsis after "GWI" indicates that there are potentially a variety of different other ways to originally generate payload. - A "PLGenerator" is a payload generator. It takes the information from the payload-generating source and integrates it into the syslog subsystem of the application. This is a highly theoretical concept. In practice, there may not actually be any such component. Instead, the payload generators (or other parts like the GWI) may talk directly to the syslog subsystem. Conceptually, the "PLGenerator" is the first component where the information is actually syslog content. - A "PLG Ext" is a payload generator extension. It is used to modify the syslog information. An example of a "PLG Ext" might be the addition of cryptographic signatures to the syslog information. - A "Message Router" is a component that accepts in- and outbound syslog information and routes it to the proper next destination inside the syslog application. The routing information itself is expected to be learnt by operator configuration. - A "Message CoDec" is the message encoder/decoder. The encoder takes syslog information and encodes them into the required format for a syslog message. The decoder takes a syslog message and decodes it into syslog information. Codecs for multiple syslog formats may be present inside a single syslog application. - A transport (UDP, TLS, yet-to-be-defined ones) sends and receives syslog messages. Multiple transports may be used by a single syslog application at the same time. A single transport instance may be used for both sending and receiving. Alternatively, a single instance might be used for sending and receiving exclusively. Multiple instances may be used for different listener ports and receivers. - A "RelayEng" is the relaying engine. It provides functionality necessary for receiving syslog information and sending it to another syslog application. - A "RelEng Ext" is an extension that processes syslog information as it enters or exits a RelayEng. An example of such a component might be a relay cryptographically signing received syslog messages. Such a function might be useful to guarantee authenticity starting from a given point inside a relay chain. - A "CollectorEng" is a collector engine. At this component, syslog information leaves the syslog system and is translated into some other form. After the CollectorEng, the information is no longer defined to be of native syslog type. - A "CollcEng Ext" is a collector engine extension. It modifies syslog information before it is passed on to the CollectorEng. An example for this might be the verification of cryptographically signed syslog message information. Please note that another implementation approach would be to do the verification outside of the syslog application or in a stage after "CollectorEng". - A "GWO" is an outbound gateway. An example of this might be the forwarding of syslog information via SNMP or SMTP. Please note that when a GWO directly connects to a GWI on a different syslog application, no native exchange of syslog information takes place. Instead, the native protocol of these gateways (e.g. SNMP) is used. The syslog information is embedded inside that protocol. Depending on protocol and gateway implementation, some of the native syslog information might be lost. - A "Store" is any way to persistently store the extracted syslog information, e.g. to the file system or to a data base. - "Disc" means the discarding of messages. Operators often find it useful to discard noise messages and so most syslog applications contain a way to do that. - The ellipsis after "Disc" indicates that there are potentially a variety of different other ways to consume syslog information. - There may be multiple instances of each of the described components in a single syslog application. - A syslog application is made up of all or some of the above mentioned components. source/development/debugging.rst0000664000175000017500000000322213223143030016035 0ustar rgerrgerDebugging ========= **Author:** Pascal Withopf Target audience are developers and users who need to debug an error with tests. For debugging with rsyslog.conf see :doc:`troubleshooting <../troubleshooting/index>`. Debugging with tests -------------------- | When you want to solve a specific problem you will probably create a test | and want to debug with it instead of configuring rsyslog. If you want to | write a debug log you need to open the file **../rsyslog/tests/diag.sh** | and delete the **#** in front of the two lines: | **export RSYSLOG_DEBUG="debug nologfuncflow noprintmutexaction nostdout"** | **export RSYSLOG_DEBUGLOG="log"** | A debug log will be writen now, but remember to put the **#** back again | before commiting your changes. Otherwise it won't work. Memory debugging ---------------- | You can't use multiple memory debugger at the same time. This will resort | in errors. Also remember to undo all changes in diag.sh after you are done, | because it will also resort in errors if you commit them with your work. Valgrind ~~~~~~~~ | If you want to use Valgrind you need to enable it for tests. | To do that open the file **../rsyslog/tests/diag.sh** and delete the **#** | in front of the line: | **valgrind="valgrind --malloc-fill=ff --free-fill=fe --log-fd=1"** | This will enable valgrind and you will have extra debugging in your test-suite.log file. Address sanitizer ~~~~~~~~~~~~~~~~~ | If you want to use adress sanitizer you need to set your CFLAGS. Use this command: | **export CFLAGS="-g -fsanitizer=address"** | After this is done you need to configure and build rsyslog again, otherwise it won't work. source/index.rst0000664000175000017500000000366713223143453012715 0ustar rgerrgerWelcome to Rsyslog ================== `Rsyslog `_ is a **r**\ ocket-fast **sys**\ tem for **log** processing. It offers high-performance, great security features and a modular design. While it started as a regular syslogd, rsyslog has evolved into a kind of **swiss army knife of logging**, being able to - accept inputs from a wide variety of sources, - transform them, - and output the results to diverse destinations. Rsyslog has a strong enterprise focus but also scales down to small systems. It supports, among others, :doc:`MySQL `, :doc:`PostgreSQL `, :doc:`failover log destinations `, ElasticSearch, syslog/tcp transport, fine grain output format control, high precision timestamps, queued operations and the ability to filter on any message part. Manual ------ .. toctree:: :maxdepth: 2 installation/index configuration/index troubleshooting/index faq/index concepts/index examples/index tutorials/index development/index historical/index Reference --------- .. toctree:: :maxdepth: 1 history licensing how2help community features proposals/index whitepapers/index free_support compatibility/index Sponsors and Community ---------------------- Please visit the rsyslog Sponsor's Page\ [4]_ to honor the project sponsors or become one yourself! We are very grateful for any help towards the project goals. Visit the Rsyslog Status Page\ [2]_ to obtain current version information and project status. If you like rsyslog, you might want to lend us a helping hand. It doesn't require a lot of time - even a single mouse click helps. Learn :doc:`how to help the rsyslog project `. Related Links ------------- .. [2] `rsyslog Sponsor's Page `_ .. [4] `Regular expression checker/generator tool for rsyslog `_ source/proposals/0000775000175000017500000000000013223143453013062 5ustar rgerrgersource/proposals/version_naming.rst0000664000175000017500000002007013223143010016616 0ustar rgerrgerVersion Naming ============== This is the proposal on how versions should be named in the future: Rsyslog version naming has undergone a number of changes in the past. Our sincere hopes is that the scheme outlined here will serve us well for the future. In general, a three-number versioning scheme with a potential development state indication is used. It follows this pattern: major.minor.patchlevel[-devstate] where devstate has some forther structure: - All stable builds come without the devstate part. All unstable development version come with it. The major version is incremented whenever something really important happens. A single new feature, even if important, does not justify an increase in the major version. There is no hard rule when the major version needs an increment. It mostly is a soft factor, when the developers and/or the community think there has been sufficient change to justify that. Major version increments are expected to happen quite infrequently, maybe around once a year. A major version increment has important implications from the support side: without support contracts, the current major version's last stable release and the last stable release of the version immediately below it are supported (Adiscon, the rsyslog sponsor, offers `support contracts `_ covering all other versions). The minor version is incremented whenever a non-trivial new feature is planned to be added. Triviality of a feature is simply determined by time estimated to implement a feature. If that's more than a few days, it is considered a non-trivial feature. Whenever a new minor version is begun, the desired feature is identified and will be the primary focus of that major.minor version. Trivial features may justify a new minor version if they either do not look trivial from the user's point of view or change something quite considerable (so we need to alert users). A minor version increment may also be done for some other good reasons that the developers have. The patchlevel is incremented whenever there is a bugfix or very minor feature added to a (stable or development) release. The devstate is important during development of a feature. It helps the developers to release versions with new features to the general public and in the hope that this will result in some testing. To understand how it works, we need to look at the release cycle: As already said, at the start of a new minor version, a new non-trivial feature to be implemented in that version is selected. Development on this feature begins. At the current pace of development, getting initial support for such a non-trivial feature typically takes between two and four weeks. During this time, new feature requests come in. Also, we may find out that it may be just the right time to implement some not yet targeted feature requests. A reason for this is that the minor release's feature focus is easier to implement if the other feature is implemented first. This is a quite common thing to happen. So development on the primary focus may hold for a short period while we implement something else. Even unrelated, but very trivial feature requests (maybe an hour's worth of time to implement), may be done in between. Once we have implemented these things, we would like to release as quickly as possible (even more if someone has asked for the feature). So we do not like to wait for the original focus feature to be ready (what could take maybe three more weeks). As a result, we release the new features. But that version will also include partial code of the focus feature. Typically this doesn't hurt as long as noone tries to use it (what of course would miserably fail). But still, part of the new code is already in it. When we release such a "minor-feature enhanced" but "focus-feature not yet completed" version, we need a way to flag it. In current thinking, that is using a "-mf" devstate in the version number ("mf" stands for "minor feature"). Version numbers for -mf releases start at 0 for the first release and are monotonically incremented. Once the focus feature has been fully implemented, a new version now actually supporting that feature will be released. Now, the release reason is changed to the well-know "-rc" where "rc" stands for release candidate. For the first release candidate, the version starts at 0 again and is incremented monotonically for each subsequent release. Please note that a -rc0 may only have bare functionality but later -rc's have a richer one. If new minor features are implemented and released once we have reached rc stage, still a new rc version is issued. The difference between "mf" and "rc" is simply the presence of the desired feature. No support is provided for -mf versions once the first -rc version has been released. And only the most current -rc version is supported. The -rc is removed and the version declared stable when we think it has undergone sufficient testing and look sufficiently well. Then, it'll turn into a stable release. Stable minor releases never receive non-trivial new features. There may be more than one -rc releases without a stable release present at the same time. In fact, most often we will work on the next minor development version while the previous minor version is still a -rc because it is not yet considered sufficiently stable. Note: the absence of the -devstate part indicates that a release is stable. Following the same logic, any release with a -devstate part is unstable. A quick sample:  4.0.0 is the stable release. We begin to implement relp, moving to major.minor to 4.1. While we develop it, someone requests a trivial feature, which we implement. We need to release, so we will have 4.1.0-mf0. Another new feature is requested, move to 4.1.0-mf2. A first version of RELP is implemented: 4.1.0-rc0. A new trivial feature is implemented: 4.1.0-rc1. Relp is being enhanced: 4.1.0-rc2. We now feel RELP is good enough for the time being and begin to implement TLS on plain /Tcp syslog: logical increment to 4.2. Now another new feature in that tree: 4.2.0-mf0. Note that we now have 4.0.0 (stable) and 4.1.0-rc2 and 4.1.0-mf0 (both devel). We find a big bug in RELP coding. Two new releases: 4.1.0-rc3, 4.2.0-mf1 (the bug fix acts like a non-focus feature change). We release TLS: 4.2.0-rc0. Another RELP bug fix 4.1.0-rc4, 4.2.0-rc1. After a while, RELP is matured: 4.1.0 (stable). Now support for 4.0.x stable ends. It, however, is still provided for 3.x.x (in the actual case 2.x.x, because v3 was under the old naming scheme and now stable v3 was ever released). This is how it is done so far: This document briefly outlines the strategy for naming versions. It applies to versions 1.0.0 and above. Versions below that are all unstable and have a different naming schema. **Please note that version naming is currently being changed. There is a `blog post about future rsyslog versions `_.** The major version is incremented whenever a considerate, major features have been added. This is expected to happen quite infrequently. The minor version number is incremented whenever there is "sufficient need" (at the discretion of the developers). There is a notable difference between stable and unstable branches. The **stable branch** always has a minor version number in the range from 0 to 9. It is expected that the stable branch will receive bug and security fixes only. So the range of minor version numbers should be quite sufficient. For the **unstable branch**, minor version numbers always start at 10 and are incremented as needed (again, at the discretion of the developers). Here, new minor versions include both fixes as well as new features (hopefully most of the time). They are expected to be released quite often. The patch level (third number) is incremented whenever a really minor thing must be added to an existing version. This is expected to happen quite infrequently. In general, the unstable branch carries all new development. Once it concludes with a sufficiently-enhanced, quite stable version, a new major stable version is assigned. source/proposals/big_restructuring/0000775000175000017500000000000013223143453016623 5ustar rgerrgersource/proposals/big_restructuring/toc_screenshot.png0000664000175000017500000231504713223143453022367 0ustar rgerrgerPNG  IHDRoEwsRGB pHYs  YiTXtXML:com.adobe.xmp 1 L'Y@IDATx}`U:PRHHBB A@RAQ (J{$! 5y?3eϞ9׬;%`K-[l %`K-[l %@dF%`K-[l %`K-[l %`$`"%`K-[l %`K-[l  Kk7͖-[l %`K-[l %`K@D Bh+|,?ϮeCިX?Ѽ ?nO]R?[6< |v=9;O%oWޏ c_mpF.Y%`K-[l W$5k=,?_}{( b,qC!zP 2YleZy[x}k2=Rζ8Iw7c3{owg7ƶf$tr,!ٿ҃W?-;=S&dgL>Gj;Ϧ=,++˼}V٘g ؿu}5H6s$80U]qN7:wVzga~bvd檌mhglK-[l %`K2{Fʒ.Cvj_;{}Vڂߕ_G#n׽?=,yڪ6ygҟMuH*`8#6CY Ogye,X{&=y& &w A=}Ώ7gg_cIX>9wA U?%`K-[l 0p 5>_[ \q]g2tzrI:eR),92a'Fl?u˘ΘsU^G@6!;}33lZ6n0xxt|{؋qcyF_IHΖ9M=UJQ^"ݢ+i93=1 5GI>^9TTp`nA+~>q7 ,$ԎYɄd]+|s^N}{$Q_uQ+b-\?uinr ޤG]剑 ɉΉݡ"xMڦ?V=P_MT][Ǯ"ME=uGU$!3_WեrqyXrUU&Tyzz<݌-N8O'馃k%dqGR:RGVrPDu鋫jƬXOVn0ԅ[O]>i~qD]"Q/Sn%аv:/ga YX֓NeO0[}M>NUcG 8ڦ|Up-xx0wKO$ܽ/[&Ȇ[|U/S,\/$ $ %뺦+]7IGt%E]GKHɛ>|IkWo,QT2.YzdectDuHXglFVFXOTuV_yy1⒉F;}4>gAy|]>y$3~PTw#Q嫌W;%`K-[l ,TkYm֕JZ볮i5f{35Y\#[.2frk,;Yk\ZX?)U-)@,<M7*IIevMyd\W9"ZC?2s~m&{$%#S &[L~,@O\} KQ~nDPre'/kbl=N{!o'y}vPeڢ.P'JU*DY ^1 &]y{n6F {g9|!-*[zt~ d:􎞧ՕB~ax˕EILNKvItL*GHm$4Q ϵkK`*kF.Ilj´sx" 0 {A W/~B`<>RlM7nMѠz!VoمFn? tQU%?/ċ?~&`pJ":>7&۟.MGoQ>M.9 ]oܻgmI\dpWUKٝec?4,DQN_.eT7`b 1)+9 @h9 W0S\+d!uDܲeÔ7aѬa]L&M]2 6u>듍eG pA:tuCT&0 .3Yz'GmL}nn(ZдI'3<%%Xg,G@odTy97TGbf|TNࢮ'DygɜMb3%#51дa|B|:D/[`~8RF٘6TlĀͺ&߼ᅣNq6*_^UNH#grQ=Ū(yݠ\軧sQHu=F*O}h~NJ 3X 3ײ}gSQ>8#FE9߻{| y t_#klӋ?//`̻дA p:-YhU}i͋y;"S(/TXwnM`~zI>:;$d/d4fYXAyS^\yH $QƧ6>kl轨w"/9HyJb.nMJA~/zU\NC;rVt@IcdK-[l %𗗀ր"9=6Mך\}yiZkq=*I~Z] 8r{tl,[^Ō=*[^v焗\k3ݓk;,O!C\e!%;YX[ϣ|wڰ~}yT_!ԟε.)M#[L+Uu]Zx{c8}# &)%2|? ccy]_Hw-#sdCʎV_8 dk;QdYy$қ#;%w98?liZ_D;#,#/ga>[ݪX$r0õ[iۣޗV ,O%΂˷:l?zqz-byAIEvD^Ee/k7R**@qwh `ld^|b!FVΒa~#zv:3-YdLeнk Ū] u :*X6?,GWiT .[J!}4Kn#}{G7:.`1+eB:r te$ްp,>ZP,$~?*Bp\7F|2or5}:0;ι#P׷t{Νۚ2C*qGDȥ?/wSNYGX^/+Rw8M>8y:#,)?5J`C\&`BKXC zև(W2\ f(E[wbțl rP;O3TfŁB g VJ#"[>nYH g);3+`}Z,ɼ,bv+D؟U+@*.ع8,G  Xe lj֡A q}Ksn.V%:.Y,3cxyv/֦AU"IGԘ:J js,ѥJ'T+\{ XړׁRKH T)[Q88:H,ax'P) R.S,?=+ȏe|ݡ](V6Xl"(Z,*Dbo-n@rU 8{©sH7RٳflG:zZQ)ǃtJWcP>ynĖOn K 79$zYV@ sxz[O=?Y(G8QDK"N#V}r!ϕCS'lCl/8rȮ}Ȃҷ=W.֧ZQ75ǀ sDc|D!4#*.,Àt8~4sHi%&]\ yEZ wn/iq|_?^̯bh%c!˝sBn%bkQg8|^7/S?g(fuj@}W;ѩ9Fyulm+UI/>nrq!&W@Zq[FDkcFJ$^~w%S|~I^w͞?~-{fCY 7e0b 3)H!Jr޷Zߋvm2WڟG)ٓx,;,U*ʟSWWVZ@[!ЎlMvo(@_G$7qPsm spA?c>E{RaKD!&r{B?[xGUxWNy-Cal.Bx  ٣ ¼␭E=ۂŋ9:Zy[…[.Y G Y2}@G0HRK툎d[}h_cp嗰P5!9:ⷲE̫ (SA#f8nz8rȖOD*_ /{WG:=k2@BeL,$E\9(&HGUPgҬ"X~1U=W.{5fj$~OKduf &(W(SR㊍懍Pl)&+Mz38Bf X{N^N^hxKgF~9{OXkp&s-ԯUzE8: :=Bx-٪P2@69˷[~> +" 3x#2:Ѳ8e' '--@t= EQkY fv@*qkU\Iܤon~{`CXy6awЪW-yuf/ O\Xs5-T?iw얾ݺ,lbR!xq@W>.Xm{ 01dS2YOKWY˷]KY} c;ѷ7ݏaW%NP/hb$0P,ɒ%n#ʭsCs/Ў̭րcdV7&=D mJb%{cQ;I7ﰾ~ڝؕ[-F}0)Dք{!+n[[l>^!t>o^G=!sW &k-of<7CѼǬ`N|+02ؿ>Fc4Xosjkmbkh?jOzs ˪_! =?_^ЃsԙXkɅav6bn~[gîq 2>xK[;q=*ZaR[W܍:ʢaf D^?>uxfاahR:8LO`c\ ZoUE^ˉLV\i1-jV*g洭[O_mwt-[X(._ g̗RU:34B2`ۨQ-z6Û[帣y8qYnUO8[Q1/D̥d܅bl;޽ksk<_KJE%ѣ5.^\:^YyaLZӺN>Cu"sVlĺO[y|rcڭصZubӁqAm}ӷFX42"~ L#Brp~[UWlҽqM&NE`g[oJq<†hq]^`5"C幁 Fj֪Z'Fc✵0ltxru5NKL@di%h۬|ndBP-#`W1 |Dfbּ)^{9 _we'hƢ#4Tk?#55ٳgG=>z,Z9-7 Ѐ slE,u TfRﴫpF2%L×i?Dq碢Lxxy֠dRȊ7nL I<팁zӭ "UDՇV00~9Yi$PČaOۿx4ܤ99YD;n>ȕئ9%rD)<)PхDn<<¹6eF"h\ ~4 /ܽwmZ6Cy;Z5AŲeMpX~v)Ush\8[<%ЊeLM32kѤ!1ht5Q0֫.#m|&p6_EY)z?kR WZzMfA"yI$Hh2k؁hߪ LN% _PB%-`#ٖ ѵ}+3[|R2^|׬2K]ø$H3䥾͠d>IdWƒ=5m YRBkfثmiHdr!C٩Dh:~I ]cէ+M>t$r9[AѤNu͋#glڗ6`&d%5맶 n!<E@mU|Pz{s .UϿjGw SwtUƚ(7i9Eh5d]!3nW4F5 HT(IGE 5-͸VTUKa{yNmް.)ews`Ǟ}:vnlM9$F wdnݺ>sG#x_f6d{4}3Vo kd?"Ir.}ꖇyJ[6#⬃fjN sZrE|?ԏ‹^[X?2-tι;ś$ECѷxffk[O)9ߔ.Yu^XZ]C9w$1Łe1 %$ ˾ا;_ Z7od|n<YB/غ{ZPWپ7Øai 4uzsfr1kj;dLCtm駂+`л(EW=GɢK[p^֎x-a_?%(O@nhɶܸ}op~p6:ͭ6<1'Fϕ*DӃѧCm|F~k(Fn%{%dq$m/y43Z4mwsKsie9L(.4'iwoml?7Ae9^Vv%`K-[l +I@z/ꆊcHS;& ŚiWU_c9] ٭Gy;Y,^n~Ēi_dwL[wÑ|`g0[c: O'u}kx~BAI<DNԐ6XfbFÚM̺ZYڭMK$mm[ XJ}1|`*#'"6 1o^ 񣟪!#DErCN 0gjtQ<,#c m)AM3D5y6">Iv\+z07d..a3قnO5ʣT2u>Za"7۴'opOF c#hЃ9h^|G5lQ 釟B Q,nrt?c5+@)||JO(M,_ɋ4} ƌBthFaWtқXj2FZUtZ2(]#7sZbl~&>E%r]سUHEIܘIfaC<7Ğ'pP-(iykՈU3'PPA Cs~= 1M7$@2ylFOFƠQ-RqưdeΟGo1yRؽ z$[+2o&Z4g&ѱWm03]o>FpqhIsdi3 Sf }5G.MvX nQӀ2%bȨqת-S|A6ub:z2C4jXL"S )sGml]{pv39p H!)]4txuݞcQ1xXԨ`Q<{gјۥ+4+hZʣn(iD$*v]+Uʗdڎ Gso$]xh,j,<: ~d1.8z ~ʱOeE` $e1ٝ}DZ5;'VIL@b!fƍe~;s.~=P_Q'9fNM:5kAG SL^ٙd_CI#>l"F~>gA#Ώ&4\;cP@S vrbSIq6n߉_0s6/ڼ]jt ya6]:)ݺOM6K`źPC'S0_F.dRz;bjl۵րҕicǹ8`xN9oSDn8 {߷QBY#5kg ǎ-.>Qyמ'`H-LJ#lض ujT5l;m ,@6gܸ ݩ 8o~d*I1(Wc [s d>uvM?iNs?z99So"%ץ=Ym^$dE.z?-Zag-Dy6 cy G@Rҧ=&!DCڨdR8t8*wxD<<%3U7iH V"k6A6!#ʬW}TFHc;(?sFl9׊%)0~Y'~&?{wRf(t415ۿTe)v9&PNSZ|KCyW0T ЮI]ÖL;ȑhf&ԝU1wŖGI ^|iCDx¬X8 BcqX;T$Yjl |*W6QPȠ&P埻s`V?Uk9°TlYbI+R1ds>W q}1.$X~^L @0ԫhJA/`hNt΃YaNC[}t{%Sm5]4$cM5Gs0`u$ݖ!d)nztS~`hVai‘>Z ռ*> „3 A H6 Ƿt.\HZvqDDZbO0yȁdDuO2nI$>{g<;1duɣX4fThƦ$7ot3cy& UsQd '1jDBd33!fB0NajhQGB۞J7slΞg|iWcJ|IhתHqcDO` e8C?t[o^cO# QRCƽx7kV0z-,˜6IjN5均P)van64K{0bHP=Sͼ/N"HmW,qkZ3Jy dq@oqf/&+ J jT˽axfDMu[fbfp] бw:qa! [eܥīFNCPQ,"x:x .gHyEkG{orܸ͌U-ycAٌ{zNl %`K-[ 8xw 1Ax-;%i_szkߟXC=u8BK4|EyB$6^4"&b3푞_Ԯdyݺ 7 uyDbJƆytՁq\ޡdɎk$cԩ^vD]hֳ wAsx(#6(i,"V$枼Ũ$R*}]7")דMh2٦ٖGX}Q)gI?B JM<2o G`-Og/fcx%AV#d_>T շCs"S1w{́ZU+=]V% ƈl-yItwD:|7P~7@Q 2TfɄkIqG;2| kW4J cbӉbFO*(akA'd"{qɌ w -w13sJ&"usb% yxerMa;V^ș1I8;g2oӀSL0qKx6ͥd+Bdϊ/te 5/O F2K>" 6xrp P|&Je KG:yuF:թ$p^ xi4@1║] *Q~{dbpj@T2$ >SMQo.{C_DQR71O/9()&\}DxG3G/CjG6&*0kVw'²Nw% AXNz.Iɔ4Q}~>31!Q΀,9IQ4l;ȸ EqZn:Qs_KJ{:e;9mwe3轤23)1't"1Rt>~s xGa,Yt/U?0: ,> ZЄ31zRIZx5ש[dva]rG^1v.ځ>'~Mfd,lo')'U݂r}`ƊtҌsVE79p?|1^ZEz5'XLjO~LG*U0)CaQ>?.h91̸5%yyrF#b|*:ygTD 3@EmUDT#εKE.*q);$Jw84qՠ=\JW6ī}z6k\z,v߱3Qd2+ښb9hdJ"AU*4ll.:ǻ|uߎ)`iya20Yܦ]-xuҏ^(Tc S܉J_32tfq9rŇ/w$Ŕu_i?>Rn >|y_$"EXr*قcIri +~2c^a*U8/a[ -fLF܁,t-[l %`K_@fgx 譇|5yfVzR^KZN: HAzi&K6^Wi pWSծknL0jjޢY{+l1DY5%M`Ei;9պ^g@hP~ygBdɣF˗1k^d2_^w z i!Yo*J"~%F!1<0k|ozhw=4k Bϗ XC#TAřD E[2"@۪ASnUGe_ՂYi~/J|N2^ɉͤlR:s6 [IYnδuvNdGQߧ3aT]ATaG+E eP}\JB?ݵn/H:ם񪨴v2na@TPb!T"*Yijq~wZGV;XSNt9^!+S?6Jj F\f|P Ĺ PL1(OMJ.ug#=c/&@q@ %;e}ʝɓ?ep}2)  GRR2LBoI @|IL^tpd 1F-Z0H9W7?1b.iЀD/eNBp] ]*@YD•uWπ1(FZ"| ^r_dGb}-`u"]_9K [(NI hdE.kdfEb߱,+9RUtSGaow)V_I] 2F #Z(A6@IDAT55eIGR9\ųC4}+P:/ZM5zRbmF( -8jc+~h6!aE)g9^EB0 *gt$Z(/{Fg[s AzI-x-fh{J0,\齮 ':DdvʸTx< rW4w;!b_ <%‚d4PJ$+<X1Qm?=N v>|l#O3Kbh~na{PWѲa]HHbA6!e?o|l \ĸpѻeP vX19¤n򙌥6i"g{f&K8j 5sƞCwSxpHA34lu1*@!wn4{X?.@8Fs7D^6j1i[&M@[?YX3q%)eMf_DcEbJAƢ]D٣EFE%#,z4k3ě&FoX\ Z*L9xa6rQ4U0]ٌ"+3J:dKC4kXis$%㽱Í=v"|#1XauKPsk/3peA#[OAo0=3gp~^6c^YmH _ h^sk[NT~WHuO 2g?Ofh3~mΘ.^l7Ch`HI~߯K2f%|dMF%1t#!KPZԨR0Xq$@3eD0|g~B  j|X:d|;Tfv-@ri˜i?a˜]df,7L _`ŊvwFMf^4Aj :m4j6]~Osv`R@eƗO!Q D1{Q,,T,6sɐb8D鮆0f1TWa)e|OwN$LC<`wd$ +}GЉqK # Ybw( ]Լri#[0ccx&6bv5'NT𰏯GN'㇙;5!~.<.UY}  ؙ s, 'OАj( ¶$KDML)O6{IJӤ֫hdtQmblfŢ)mpSf"Kogb٢}KP0h?| v^r=t섉'^0H֡7cQC^F"jiO 8 ʃ+()˷E?:0qH& wto7J}P2(ۤ[/~\~m7j9i 1Tn$Pmr<3:@צTS~\ {0ǧ}a\xEWW Y1_O#"`v<"4'4lV6{?eځS%:g+y|aJ*PκO#Z^fJ.r22-hT*G٦ T(Vo\\|pO&4&nx'-5B "cXa4dK-[l %ה5D])Fش.>|? EqKP™0so 0f쾛)1_@SorТͻXF#;'@ٛ5kjH#M>dBxG>tH,g? da +%﹕6ՙK`U/b(=y°FsmUbי8䡽&rg~'@_AP/cur4"h=ؒ-Qz7~l)oDoA6PlqN`71mvN7]S]FnV IcCrYNEaQcmXz" /?-ex̏*ǰkqg S.['- U'Ƣ3l~D2J(iMsnY͟ݱ(Y7 m5"Cp Fc-aV|I7\rMWAr rH5}|0wbHCYD9_fb?a71 KoܔZ(ݼ*b*So@:.P% qiƜs}y5p$;O"j .$OHEՑ䝬ɋPF )B1s2Enޥ oPY7e4߽)C8Roy.{=ow_l;S*0/wo;5Q.ߧKO֣zFOc<+hΧR -9~<A 7-x"t0_l ળRy@ƢF*zŴ_>lɽ@|TϹa4q-nKcd.i9 {5ە[x<9žfh\@{=_n?b/?pm/rǕt}F{]z/ĒY*j31sŮ%l'iY@{aXk=0%a\i*&0&%50'|hP$N|?  !2!,'*nEiumVmժu/'( "{Ga&a0¼9=\Uk|ss=}y'h8S79UJoŹ,1Hb"N2=J)BMZ =c-x`Jj]nc\^L'l Çhͻy^ۮH"6PBX*`j-5SPʼu "$I~IhK)K(ێy H ̶Rcj=6϶R_?  ~Ի0_z߮32m :>2 $I6mUK>K q3'ٗ|ꁜ.NOO@qn_ UfEƦ:1^eO*X%ۆBbJEMetUxn$"vL$0Vf!tw@9d"[zBl$S1M2 KbiǍAػ+hWKô¬gtQ!nf8C $kePDjn54>$jZY<΂, O+ERK-\$9o+byL(]rhC}SUդ jUHa6Ae!_VLFP6oJZEN'e}S̢gP_euKzf+.u)/fFQdT6ZPȹEn#ܥK:h;N#>Ṗb4ԬM=)=j ۪\A}DQlo F]W{4 %kP#͎j/|*5א0jC9> uⰋu])gTTIG:Pb_{1*/X6@G#EV!O{&]L[ʲ4΁g,'Qm/n@TfyOayjCtsaZf_C<7cHlH4oXc#c<2]23\lQWo"GCk+Y(׏~̙l3ﺫ,]C!p8s}bLk̙һ<$tڽ74Oin& S3yW[SK%DġƔ>E~*8xKs2acUʶe/4i|*WR9ziiu> a~{#K-욿zz>˫UҘ9$?[95{m VJ4a/r6||4p}^uLX1 ]H2խ0r4Yy pC!p8~sOq@{]0f 8~6Ze\Zص'Z軤Iu]iM]µ*]]UE]ZKh- 0թd1̯|"wU\o+V :1X"AkqZOU}1lBX0K#5] 7[(pbvÿ]iӺ,W끓q3jQmOwj}-jp%.bcvֱٴ:BK8nˢT,>plaRR^/H"-g=K2-j .-vҺ&)-ϖrl݊קN~8|ZV. Z͆€aAAMo_nq~.2具雼[u|]>%yWm[l_NtmZ-fz'8U;[HMӢ3ò0DgH6/gX<,vg[MlZ[w&B*[&ա8]܋hwIK7BHmOJhZ=iM?)eEiMsUl^uy:l8K_g =U[k^l?Y>'lH(;n˵NV?]x݊ש%𺾪aeճݶ=^; Z= !D)ѳ~9/$yLYn-n#ܢ>1g]i.^֩޿S WEpYN?\&ʠ<oK6ƙ9UOwp[;C!p8iMe&֦|zw{~Uo'¿C+J龜R:Uo76TH[6mLI,p+.˄!" }InYa <6'Y4!1>=u\l𓹶LU"L^ҏ_z~rh`pC!p8~dmԭMd~ѻ}Vbk@h󇄱uW"-CŇ}|*78 BmȾsVttޥ3Gu!p8C!p8o@Y Ky" P,ɾc<#8" @sn~psu~pg!= b(2e'֟^Ig=%4|Kx> 3s{}c1*Ёiag!qN~8pƇN?n~pN?=N *" Ic+;Y٪?<cv8|_'N?~8p?'7??'WGڞtw7BO8x41w\ ?r߱8f,= MQ+"ğÇ=volpD$Ca6<8TMO .3؝^w){JPc!7+RIkUp\X}|'\/%m/pulWg>< ""#9I#G2ΫGilg?~YN0>;nݯg!qN~8pƇN???8j;TI=€[H-[0d҃;v\UJL@fz*gVEZH#v8TuX\e4vO|v9nR0( ]<߫>5o_Hc7?>sᣡwי/-߯ϖar(&kTo드"nZ>hȿ[ 0nLT>i$e+mQpC!p8G3!p'X#5Uy|]@zcy '*P+5Rpo/ԪeHBS(d.[^Km>{d@0i EyOFre?,c2yhmy6q^#5^.oذ7]P3\pqߦrm3IY[ыv6dt'l}iXich,W$kw1JI䧤TBӊe ߨqpg xa]xa2mV OxW0Y6?=>! N? g7?n~ k~pE K|RLtаZN_ jVD w'+qh.߃u[#ZS׻.n0tly߆:^֨Sf 3p9ѧƊVyï9Nٲl/<׻Sf{' q% =Y Y2̝5z$3-~2, // /wP1_FFaem]zmwX]pQ>b-&n|au7>4:v(7>|_\ShG;#v0m1Ň`K1^Tf}&`)6=? g t !*Oexr.0OM8%e׮Y`RC$x Cm]6}S>Y(Ĵ {ψHbu`5Ʋ==C!p8C!# @"FGCH.P~KUZ9M??Z=?h@d88*D\nؘk }Tǧ3`R7T@N) cKA!bcR)t"Rd>8pgX⿔N}o~"4D*?P 穩=ɉHd%O*zЎD-zHsW1 Dq c\=WNAjJ2HZ*HF]$\||zV^ N"ӱzf\}9"fھ*O~"HN#r[MY4DU ɝ=8?[NEv)'z튧P*(BHZ"ᵣh}̤D3?GU{oK 9H1")mߪLIr=66}+q < M[ MDQAOlww%grT0wKtcrEXmnT^#$bV/]XKV:XldOJCf~״rRƝL4x̢"\zUO==o28e[P-!5nZ3{c\㍞ 7>pC~VǟXIHMF$3rfqyI >{eu ZO"+Tks<1W={B?֓#BN8l5Y ƉXVY$ߒ am!e$+\4oہh-g~FC3ݲ9Ӝ]vD$Mč|gLߌM`3rFL]HJs֍ѯGgS;+ dB"3'Gcy[m–ѵ!DZ e%"r/;aPuZyGM)W^z-GG? ?Q5%L]WIC*I VErEj8v;CaFբ g]",+$ 3Ōh16[;]l;B-QgA0nt\{ߋw Qf!t6ʍL7n~Vm="d{70u?? N@t4KOD3Zsԕ>FN)[ډঁѼq}ӿ~"ɤJ"}mBpV8`tlCL̫aSAjxȰ@xLy-`ICcIMu??ϗiJW2!Hj~_s$Cd.] S`b[ɶTDU,;}zߒHd-("_#Qv rL[ME ],̙/:g7&!KBnE ,Şs`I&Q?Z_ӭUHzPxWeУybal-,жZ2_>nlh:jx'&aM⏟_,F`8FwXLpBvbƇV(Gb]W\wo3Ië hEф $JE6Fl˓^FUŴ\ZaVj%M;=&pyaGe]<!wБd4gn֨sAR^;V[X`X!yfK)=5v]8m$Sa|,*bٙUФV&rG~[Fk#G刀'7ЬOM:i2}fc_+!!;t'뗯1lnlo]/C|"pdy)BwcsjϕS2}cgFCHaM0 jCA!K I$[iD`sn~psz.jTKC3KpmE]SCFv*<9 X/B4>]Eqzlƙr^au -\JN%"Z<1yGW,#Mְ|8w "@Bm$']Pm)((Z -A =ЖF+%&xm|zNG5m&[ o3;1T%Zo?gk7lyMKֱFݵR5ԯnupAfި^[DK0邹Nusj"NuzDP1_N#2wj/;s3kVų#Z:RjNo"":w!у[4Sq /]ܖZ95 Vl WXƣϽEo-2pWvtЕvU0%WsCGa6-8k_J/ ;6 Cl@Brkhr;.>%u5["O]5q]УKWn8=[Lv-哖kJc fZL윢9ij5OpIVZS`:QO{$^-CL.Z5 {rJ1b2n}e$bD\Z2LZi~6DMք䐡a%.E+`>to_nKW܇ 98!䋡8r GB)=L"Ut",U>ʠG1'g(_ K䶷e~zs,cMRKYgCl&I:E`d^=_ w\w9VabK3ت_T8\VD@Zv˄ÍGcfL;vb⬅xqBn-DAhޜ-&0Y~XX_Ճ:+!;2Ā<%Vcݺwg`6 FPLXtKV!8e-XriaCq[}{$?ZpT#YS:Mgs k^Uϧ֨ @v].CfNkEmZ #&sh֨^B1=wjjHΩ{y4m*;1j\ӳ jר^Ȱ_ ﲾ;qxKV~Sqk.A:P[ <|pYo-xc@htct)Z6mv(Ӯ^H\R7UK6hP'ǜ7ɘJC:!+QYjfg­ʕlğxKz>LPcwgφxѦEccY"^mŽ7H<lG9 /}$BuS6,[gstܴ}LXq>b 7Y.J{Cw\IXmAt"Mh\2R5qKu]{2#'ТqXBj1p/y:y@H*<q=>fFbWMc]Yl_M8n|Ƈ=,n~tz~<%1\h<3/֎(4$!낛.lka$ RbVMET55$Vrұ<{[cIR,+v)mJE8Cމ7V;f^~lSb/K]IEPe``+ϝ*"zfT[DDJ%pC;7xT3iV"Y{!֗6,lsˠ5elL~şj"7) *CύRZj+2{Z2х[6X)-nc8&df,jV bFKUb"@dG5:Kݩ% ͳ. HTPUY\Sr~GvFnDcxCƽ+'Sj(V^qsב8Ak+n㐀e5Uݹ<pEmhؤa]ع s7rl53?6Ev0XKɒ_49]?g#hن|ް:KG4/*U@!U-"dj1Og=u y&E9֢Ey45/֗BOñ>&',~1]0aL+mS{q[Yѡ"tjy>Wgۉ' GJ ,ҩt+U~ZcL`!}vJ=:Ի⬜j 3׏7uSy[ } wm<㯁AMQkYfvj^ӆqDG! R"/ γa`Gĺ@]*ߐ|A'F'<4~D-rѮUs\Ժ. r~B\NQ1cô6}ch-Μ]nkۺvF9$pQ\yvnkHKʥm~<3s/o'\&X*g۫s"E+J9cIg+ŻM?)wnw 2C4n|n~냛7?) @1CrLksnXBtuB7Z`ep]PǍX1Ӹ'*sKV>?7y oJˊ 1ks!tP:i$.ԜlލKVaն7(ob,*`tnU]{RVISYu^7`=f^ЦY|=ZtG)ӖƔ;P#OlnH7yhھMˠnZ!V{ w4Obqp˥٦dl)ډB _+'I2X_^gGĈًx63XC .-vb|5LYƵgF 5[AOS4p׏EE"D֙MlXZJx[T8+ W%m,yD 0_yV;s5V:Np=;?@?,;=M1b9WXbFTv 4V﬇G?\, 6$Rѳ$PWasO' K%: G0đI =+^Dd z4#42BMpyw* { YnmU5?"_KH I'USG ɫ%[ Awӆ2|H9M,FTx PVdHb:IYF%GYF(o;BWwm6S5U ^"ZPKd_g, 69.7zqU14 K)WD0Kn&- (rЌƹ!p8C!y#Bk.4˳t„&b&$uS;mHG:9NN78U7 #-43oymƽ1m3-םks~thXc|<~2&>: 1ۂRA ]>i:.~f(6po~I£)^?vW [n2o}|`cH-Jh3/0wPgk(IK65ZSLی ic@F^YuKAGzhuتr"iMKG8FE5i)c'o)^ 6dq%.5x*jl-hh .r" MA"ddcFCP0K^ٲDi~O(}Z3zaLZgcHQY-ORx^/QERWOx|#WI 萍2xDAtKd`2WƓ>=TfY0o45ׯ5}acsG|2g,L I:v$^O^a^[$>Di[LJ2^w:=RTV_yi_sYH_,4NOvBZt:Y@0Su %b2r\)! =ro^Q8&=C!p8C!JЃ[Yy&Ғ7BZ>nI:)Yb5I;[oභx#g<}Yڮ= oa}hoiO|@ϧvH$) |nmݸOOv7n0cBxyk\Էަ52X%ʁ 5[mp;^Ivdsh6H؏$2&9{:,-Hn@7g/4s Uemp:v9 -t-_-ֻx5"VCmPg\M;ѥe-[55gтȡE aKa\4utT :SRvAUg#UD5f|QEw,<{BfW?Z|ٗn೦jݳpo/A3Ӑ7>z*/Tr|j_&fyFN:6k>_I<}*/_}T{50p/ӆ)>xۋ8|ʱpCA3N?~pƇˊ+7?x17co@z[BsbON@u,Z-KM3F~ݑ yavBFDi7i'7 JvɊL:>1U6QcBEGH/BF[Tǧ P˜-t.e.;!ڬJĔg3 6{%XBM.+c-&;\@h\|V3y=]䢬vѱ!6_'BUXIS@Uywk##ԉnl0Mn3t*9a29g[?Ɔ?쳋/Gbqau\;Bs~8pq⇎č7>.n|X](׎EjǬ|AC/ Zoj@_^k?./VtxHvoc*VvV0w3%r1[Y^ɪWLh[=W$*,G:NKY6dѮ]]A7tɊՁ3[?wHYC[:H .4g0go3[uV#w|E4:z2ԋ*JSz`"Dl:ua*Hj%Б#A:X WY\uLK|50d_gfpѲUq`MӦ. '(Y4 r˯+OZ۵jMW/C M9G jGp4yp񟒘H,޾{7$Z |eċ {V;AT&xѹӑ \|`{{|܆۷ KbU7ӝ 6nZK [H`Z]>JLVԸ;r*Wawiq;spVH(TIMjr6v{ w5Ih,9$<|e^5 oR eGɍ7>Bsnn~pCـpCppO!Ժlb&Ky~Q`Fsǧ^$J8*{`ž˛@vj%s~zjV T\ٜ=ƕT` lUsh@B\l}虱AFMNsJF>-6ӱG.B c(Cd`ߑYC$\z,VkJ5Qq[VʫbO^"(QтR 0Qv!$g{x 79u$#DRl b/(_wi5{!@"&֩21]MpV,o35<ɷG:n?_'WZY]Мrc`r#2HF@MyZN;W^p6Sr;aEvp<49 ЫiCkZĴO1ۍjVm6*F)P4?%%Xe{N&tiHё^3<6:@`H.w%@˂*|^/Ǒ,WǼ+O#eI/bXvL/{V$/üѫ~bzbm%PznNv@i5'+3!w13= 4©BOT*?[z0: 1EʭLZ:=i,)b)ӌa*- ڕte>?ugHO&Fb\^cuJw.!GhNpl@|(?1G.n}V ".si0ν)qHZ5u]LͩA˹<<1!&\T;JsD6&p12X/ ;h\ڡzMozx1h}3pkd,sQ/3k@,ivČjD"EޣX?WP\\J?c1TnGQ5i%D+B^hDͻ:Y9pN:Xz+*A^>m& ˷-SrIR9vy?n en+(RYIdpJVyn]llQ=Oț~iوY%xxk T҈|ydNJZ!CU͞fk0 D6t04^zeK^N9iɩyncʒiTC: ݺS1|4 Y&S{e  q3hP~-rhc5w}Ÿ}3_s jބdFJU+^Xٙp101Yc4 h W+R}gq1 s V bdqJuyNtdk\mخ!cimP'M+Ď:wF=3_6[Q.\f80sl_0XsIK",[ oSo(((SE!t&,SyB<4x:Sf!,<+k;ϡ!ɬ0o*Ϲ;/_ܲD3Om0zXn v$is!3Zǧ:yuiwmO\zW[LFFCI)tAy5miKsagBֻ*K?P%+hN z@/-$7ν8C!p8D+4kJC~hW5:E与 0Uт[<.js[k6#n[4O- {HNDCxY8g''i$ Bae9icR]Loğk$cbp2q6t :YULyʍw^!@]Wz7w.aSx;YXi;*TfŦo|L$& O ۸hb }c k05YWmrb,3; ik-6"q}1[дA=t״7hٜ٭PLBUP͊}Z1!F\deH3fpxYx\A':O'1aap:sC"pO9OPHYɺI1whG.Dd[h,Y=bC҈@H}OaP&{fGY$*`񏟷8ܨ4>DvvUǰywqyg\lDdsa̐t:'dyaxOm Gs8j<ی6Zob؍"Z"l\&8 &6olػ cIz5Z*-//4Ypka;S/g"Ao:$j{ Sx';d>]_|W\Ћ2T3x._Ͽ oaՏ Rvq<ݸsgf甶ebe#Q2 I?ٍ¹g>8Ynofi E|s8 y6;,f]h%7gxP*ZSx%:N“fs݃K9]$q1"71\uɹ rrOMzOhp˪{ -,*1 ]5/W"q:Fe.;s68LA[w.oCQ +6ljd>WcÌUx8w7ymfV2i>6}`R[^ k1Q}v.gN?r8pn~p<Л}v\M2_iE$ϻ3ۘEZ[]8ms.WCFډc4NzvK^.sh#ĹgpZLZYpz~ID: 1% SfKUC)f=tvF g-@e[ЍA}up-4Z^7d4 }3򴻢yzk 8;˵H9`pG&i-ѦY#XI+tB+nox䎬z_кICVG%% (ҥ-ܸjbأ!eL@cS'i!]{]cƐӱ܎ފ^0 ܞO6-XE ˳'Im'/ZZl?+iG9(T.nSz܊LIvpmt<.7/ֈ9h׶ΨIIܴX< Ųd93h[[E?(U>0ԥ1тq%o~$ECnKmv2No? \{ $exxXԪu%iU[+'VY}Ts];H ~Cخ!#VMNɧ'nG fq!yO6VH6ЖjC^0K1$lV]Lzjn>r1MKkqH(8y<8ja.0 O҃Rǔ)K[Fh<SclFM9 &5If!Hg`ZpV 6^{ ߑdLs&O@uo3·~F011ةYmm8(R\ptq-jegɑΌ .]w-A\dD@XqihVF:CA.XSaaݻQNƑ#sSD`Ӗm Zekl9@ed]y(@ #1 ) 1& &95a-ɒ̬J8[o#-eN%$neW:vUulxi?Z|20بUsֈGD½h+x7x#[6@$qu i sqf@jvBXc]ڷ…I$[U@f5R*Ezgw ^u͵4F\<`@j4 l%2c4 jg`<% *>YёOqс1>o,p]t4Q% }$IJ@D^SH`] D]y3".V5e҃ bPJu;w҃i‹:~_*4/Roٮ-"if`V`7 on n֢BzٝZk^dXv}p{dm TѺq{ic3;?{WQ9ޛv{@B/zEEE ߇OQ|ԧbW=ѤH BI%{w~/7!Tg=gwgggggΙ=;.U0 %:E'{o>In1L9w}7~"|cuI P~̟B)6~ 0C<(%#{Ε-9RXz}wLYƵ',hv9#S1{ >1JF'l]x};y( {fjYi&յMh:{2{Rzy?VcCzklVzx1luYy7ySuڷ By]s8؛5wD[/E*;ypm[tیֿ[Gi9슣oՉ6ۻ;XK]SgϷG,6v},mde+k;kcVi2}姿ȉw<==w Q37Y9_[Z=hUkm9gzy(GlubM>snƽ/\kI؟;os2&(!RDBR=9eT!]HW땠2x.Gԃ[vv='6wxh2.CkCxÏ>u;{5ֽѨ/`kV :ՁnҖUH1]6VmWqLJ[sC!j銧-ċzDRQ'߰n5Q CoTqx7Qp6hfh#xې`8=A>f =51B| mȀe5VvpG_Q0w/1,dဍ@Edyde"{G.|#~Cr ~؝Z}i{ޚ:IQ۔zSYS.&خ][;b T+_FljmӖƾ2::T`me3hIFu2$|J wTs_.pZ C,d [Z|=ZDYv6PEtz-U<{Fەe;M}u^9[U9qo 0չڱFڶ~ 3DyeujYayxm9O_5fX!80fxP21p!\N:0, ߵ/+d4R_MzԉEh`T z< /bj|90F;I<2^o}#ֿ^N`T}^#e.oDhy )d@IDATΨ7p]/(QYԽۿkG"#WWyC3.wt9_t+8z;T/R p0&2i)'w;u(x}1|N Ⱦф/H>8lw| ~+,ZT S~]4~&[  }c,θ'4V{f$ù|8VQ@?vLG>>@r:1+ ~臗 FZ8uٽ6F^²Q*ʑǚ C֟6'o?YweK=;w0Nf0H*F-| C j]s@7K*È(al1杌AKk_>r3c|̟q_y> 3Y2bZ8H4cG: Xmh@^-2rm8W _(,ɸMu_s Dx+MjOl#=ŀנE&tޠN:[`$\9uO ȇXԉqJkFEM$D5_@6Sf6 I1xm҉w=0z|=y V՗m=ܳ.ŕii#\HkQȑ˔a\J"KE/o~m{ͷMckk[m>%t@ɨv9'iX"ќsX! wadK9'OY#fĢG.eah&\>rR.|=56U%EweWՎ(0;dqFx7w (0qj;Sfd֥x4v]^x(x~}cp# y^}x쎛i6 7i's rqz˦QAEp})BQŻo]p1/'ϰxBd0 `W\t%`\rm ůq_,^ӟ1%9x)y$^nxUsE"rOZ}eP]ѝy$ĠY9zr9r9s @΁9rh0`s+Eo_Q}1ۘ XgY10 }gӲ{\lg/=;av6b@۫Wq z1ٴ}w¯`ϖ{rf;Tx=CO/ҳFȦeR4W?tDϦe~ [&{ݜM ~`ey"<2#\> \?!~F? rOh{n^*aƕz|~qWH<#hNUN:p(N?W^+ s6~2j -9s @΁9r9s @΁9vɁV˖;[D0pr'%kJ' 4x-PJ\ f$ٛF8?dQcop=˶dN/o~N-GZ8=1aL})`1[)ڥB{<9s @΁9r9s @΁/ρ::|XZ'#Y ZGԺu#59 rCFiWQEȵ~N-߶"Ku+[!SI{^y{W yo!F?ՆƭVvIŤ9oɁMZ[FTkmڍ֫cV(lt,v:? Nx(! Cz94  W qqGX*}[׎%8k9묝 ]۷qoCFF˷VБoWL᧝ofe $/AnUfXdV1s[iQ.E|oMtlk=ڴMn-Dil7BS76l 6榦7B^mq]$9r9s @΁9r9^lvD17 d76'mw>#Oֶ5'%8‹E=eÀ^7Ɬd@j@uvoϾh7aگl'"3[-:*-$:=蘳N;;ímu[ɼ7uɼ%v̅kW*ClhmR7G1 jŷ̊Nbœcӥr~6S)ࡾ"oC򶩾#N9,W[6ٹlMun]4~ZmwBe6 [٭w>oW]u 5imh~k*l]t@[-|O6`(Z74Z޽_.;9s @΁9r9s @΁odЍ [}jYk+.V[ m$߰vGٚUkO\Y>w=mmif޽Z–nֽCk[r,e"aAkCZmI,YiָiYڵx^okW(I3]+שmPlVnֺjkWXV-SuAֱsGnMhZQ IkE՛dR4T|IR<obEj(ifh?Cfo}ҽwM_Nˏ=xsLy;v ~i!}lS/ }ي%l%Dž玵auެv=ra (8|Vޓ9J̉nK=XnsϷ9.07vαeKXů-V'Cgl.Vlr{Hg^e2l.ӧhLi>h䅰Dr9s @΁9r9s @΁If@adb]!n ap]ǻk>z6;W{O؇{^|¬~6 jsیlϳv2fVax9{='a'^:.lstqn}l/ط|]#e:ؠuoep//m#[v:mF7~ơ]M|pAvϱC:ȍmMj7\{}Gى`Gm,{BqϏ:ܖ$s>g7r j[_e?}oژ Cw\k"/_n;}|~x0nnns/z e?33ml0=qdo F|76!b߻uyvio$#oɞyl}켓Gf?}?:ю<(0TހͰD[i>X),LVs @΁9r9s @΁9rs,<[:Alt^L>-eUķv__09zh{a,'Ov]ﳓ/>r뇬N!~CV'ds\?!~Csa=qd1?gǪ[|: yzġ7zRvĆ8;f|ۯN8uuD-sW[뻟aMVYgm+~)}OtF9q7xǩmsė`lśl]Fkzo[[g;aAqlAhRz\ry!Áy?/3\?f!\^V*=ѨY$ݯez:6mIׯPi!}/}v_ߗ{ژؤ3KGw3gE8ōI?ݘ[./c`UN𕝏FmmoÆJW37=uӖنU|kࡽ_~yfJ%i#.J `GzO<#wcQaC{Zݽ UWu]ڕk;CG1{d 7}ϧ/cOo5*MЎf^ {N-UZV!IFO-Y!ڕ}V,\ԖTԦ[ޫ_=:ܤ}Ck7umxඇ/q=7y[u0ٿg(u.{ZQ!d ]a9^/Llx4gI M9rGV'ds\?!~Cr \?!~C`@xC-q/6y:N6od$-mص7M'ۮ=dZosm%s's-ԞnhhJ8TSuX:]C-̚o66<9?POH;vlek'g$3/!#Q:bIgz[]M[lG89pdM:Mq<7P4loms*&Ϟ/cxP+#5[}}ddO֨[:xmA[ZN9S^gf5mT_>y^ZA2o 6lj}kaV[TաKUnNu!<UrFtuT[y=icpF>eMч-Δp'MI!@΁9r9s @΁9r9:kbmH0^Msb&Z+_a~2xaTз]3ىwnȨBF& YDF3۱[]levɶd UO,M@)tdZ( n ;=h\sJz^ʾQs=JRSGiD?Eݕ# [ue)F v^i[岼xވӜGn7M}z69 6ܿ\>0&D}QWjp e}vRY}2x_G]_Oڜדs_*>`AJe0%;CʨVORQ.xmƝMQYCf/&n=Y;}JiZ}OP~ϟ0J\ SpC3nomvWmUxIeԉP?996ekc^CPoH 4pu" ^0PIKWPdbSaZmen<T]R(NO6e_DTU堗d򴊸ѷȦnJuɖkM羊/P%ڛ7lQGB?'coy[{R~w 슆WSp }k-#jmg{+pKlwGwG{ r|򮹴lXY2jJ՞=goru4{OxU9*Qos#ﵾ׺_΁?O:cG!G_$XR>6|jy –mEa1\*/^8/x쀱okD=wEv,cn{9?7+Õeqm6WڛxWSGxxP'7Z+țhO\C-OyxB@"#?WB?'W)oAS>'vkõ-_P+C%LeY|Y{sZv_%. Kiwo)0/Y//ŽRn?:\i(҈}%.~/SL?2_J/Gk n}B +WY~oNڧ_S?JeŸR$'(@%_ϖ'|\W,x˧0 (ZgkWA -ϴ]O6lD՗uk??K+#ذR哩P.uybI>+I^?Q ;dt+}+s_A~Y3e>Tf4BP>eJ6?Ei~Q+R]_?ʓPo GmI/RS ņn勹qq%Pԥ/IE}~(ͺJ/_smyg)8b-4*|TGAB=;_}ez/w_zoו$xJi.J%l>%\A'/*f;./v.+`+<{ԿR?*M lG)QI#k,ţ;gs~Nsx=){ڤKܓJ[BUC{җ/gοk.|TCq_žť xsдyK#So}uE~T6-ӓd|;QֽW۰>y|,dqmlhL{a߫m"Y(c Pg26驅v1B&3-+6ةG ɔgovp ɳ+zIG7rp~OvƤ~f{ڱgk,]iw@dss鹫=$ 'g۔'Zo`k[:)غȩə'hqqx~n2Vthɉo>"Ez{LB|iE]&>5vهZmŏ6VFm x䃇R{_ž./A9U$*Nn͚5IcNxmZΝ㍡gi }uUce>+#UCWҺuk,=q꣰B gnMVXa;v7[x~Ke (/8noe>qpe`>UzVE~W>L!`%}˖-]ڵk~ߴiSzj2|(|6`J!&87AnW؁l>/]KG~g/vnN֮]4v%*6|AӮqҔlgq`UVXС`;'7wCU>ps%42r-<7ntxhժ)OKz"/ 'x1(5.M)߁R=G{DLsq*^ӽ?/y_*qIW(Iufmڴ١CTx^sƙ13_\_))[7"_Wz>yHR*C?9tuɽǁ'P_ Sl'ذw9NQL7ƼHYo:Ж.X;㭧c9.l;đv6سyGFb#t?x}Q6b9)eDiVvޛ>]9+ /O|٩j?яf>B'Oll:ɮ%-8?B6y)bK.ulQk `}}]{s9Dyt9di4Y؀!=w'_pF^>~Cyl+W>:uÓyY| 0lܹ┏"^LlZgs 峴1ReaMlі/gތ3|,FW *#0Qwp ,6] aٲe~>}\{-h%?ƒ>rϋ BF\~ʔ)vgO؋/ȭKv1Ǹ<<qm`!s%qei.tyٺ,y={gkj,>>}xexOWB'4ge|NB7yx)wWȏJCl^#?_`AJY# GYN<'DO۳>[ÜMoC%.9d6P6p@q̙xOQ6"=l^#l{xi3hxG+}s |W"Nh:g?Y|M_ou]yo}FmӧOo~@Guei(yV=gsմi]h|\O΁ .}k>w}ﳱbkWGjoXr0Tod=xa[N6lfK6ېд69Vݡ6~v؉~m}/Gg1n+auCF&c״/nV6mZ-dU*ϲ|U7{y[ε#_|Z]s^bl&MwZi<8Q66\k?ݩoSfl+={/[Uj< T՗fMi}sck[Nh:'L^կ—E[o4Qkx7MyA=|\lh. | \YH$x5`hOsٴ϶5_L\'M˖'#t q*g1qxDn'pP.[6o0\V`#|¬Y/̀Y Yڑ "`А-}%I ZyͧGc#?^J|%`Ay@|xHBs}?`$غ[<,=Be} KZe8"DjЇ^nA=EmȐ!|,mwt'P/i;x` ?{/~ֻwo} d6D9!|ywu&޸~8^?8pǩ/p"vF0qAkz~ߖ ?s%+<9qr kAөtu6Z񬦃<ڼ }ݰioe:b|֭Ow[pM|tv>=pk+cʥtZ7[mZ-zeЎ:xmU|cFٷuo<gOo|CGV2aTC [ڔ۽>o|KĻv:$9,9sڈXkd(lvOϴV@v]a('|ƦN mˋpx6[~=2DXA{yYVmȰXmΗ^( ݧu]^ QI&~?ލ#Z?kLt,Y6xʂ:G`N]%&x@ÝW5|]LcRK~Qwm|11eQ 0aP@G;vRghoSi; :–UOpJKQ',@:m#|@0Wxm!7r.^c+~2}#do> qĈ^'G)Z;Ag 8 x n O6;}=9el3*#s"}.з(!G>+kgC!teь.d\chF55t2F8301^,?+\Y;_<M+#_2Cơ>BguZ@IDATYB/Y~=-d >CxeA 6WqX q2GCCq ohQ7c~b1>f]1V]O'eh2 aq"6vCFOd Enip%EJċZ9Dv1WA'c~>^M[ިRE;-#m?]GӇqnb W1VG=ԇ0)d.2 YdI;[2Nx&ڍNyWpsl4G N >F"ŸY3/#C<[xѿ~hCWo|~!̥GW/4<9=W{C7E7eмTu?_|Wcsϱ2yP)bE[x˘V/_cZ&O5ֵW7;픃ZټozU']l=`dR}OV0q衶f[8{aulڹ ٜB' 7{面Oj?gdFŷZk}YKŶ-֦s}O~!OEpt7k1 ]QTFM-FuMU_V-YiCDgcǝv iu/k9(]~'9 2ÏIPm O}Sa;YEr'?OlX0`#x9LV!0 !y>ί|'<|b6"["X@v~_v# }{^?|dюgG 9tc2}W-b_|‚^GIFaD~=IGeBO?=f'7,~{x6]p`'R~0׾Vގoe+&o&@ۡpwKxcO]03>f!@3Y I'b1L'2F; dvu ydַ."b%\b\s{ a.@1< @C¤Y ?>FcHe2K>@i+޸`VO~q~^|d{{kv}3qbL Y7d3#䙶>2/#0VrJxAYCb7{\X0epя,(Yw]7_~; 7\&ɋb|EЅ =\_xsqy"*Ҿއ |!JXaܡ,j^z,c>8/E_ѿA}~ ic!|/}>omG6h+cq@VƸEgovR?xnvEBV!b݈A~39iE/st.}{=+xJ B?5ON0F=A~E`1,C|9I?!7;fQ od@#ʃ;tC' ؖNiS ^OѡF71yyƳ8Nx0bX<մv~qD[봇Vܳӫ~·_T3}`G9Cw~𣗞vviS(SeҖ'#K_7y:}^o;3'ͩzIaWwU+Қ3Uƒw_{⁴әR;.,w兪ߖ<'Ǚ=O+3~R Ͼ2L;ҳJ{3&OK w{OŇ' }㛲}kgI/7t{)1o)[J{~gZ8O)\ ?xkM/7 ߳Sd˲,h, :td80qSC/gQJޓT3 kY 4q ^ !5)U[ 5Y,h"jQq=S-~RZyy=K5/hR LFIA&ML[7SMRm{MMb :͚yoy[R?g}vAT Nqka~G(h/elL5Mo}AFbinMDS&MSM`9 }W]\ iLiůmʈQϣTT##C9> : 2xlH5MEG{ɗk!JUAW< ǵ8|ق [ןɀA.hO$y)h#m?W 2X3RdHp\>-C| ]|EEA{ǧz?'0>A|;]'(VP<&Q|loo<?J͔/Z= y"!ƴW`` ϠQT/$\0612lJ'HYp 2o4GFG|艱2yuFKTx]m^-N %yZx{F>XWZtBrAi.@^}^|-:iC2HeFAFEd!TrQbP}е_-r 2;MZ: C2(lN %=_qӴ8Uɴ烊y>cZ/n>􇶙[<|O28 yOlӇ1>L#KAAqgnw~yNY1 'z_ϱr?ҋ"P\-z!GensZ22Tx^>yyƂB*#i5RyG[M$_s_>aR^LYUA E_h aѩe8!0>d{\ ȕ[oKKԥ/v2lQtzy ;Μ9>%jހvm | 砿4\~ͥ7~2@- }ނ>zQA[T( Y]w?ߙWʠm.>>hsYpkS+͡}<^țƪ˗Hq(݇nbIy>&R KVjCATFjkN>c b/C/c 6ts=+/h΀Խn!q gnC<*}.y6j)z){NP(ni٪eҦmĆ45mg\+3hm2#/8:9` ˶ԦMy)٪fK-/K۷66Uچd ɨF%o;.00I[hm3'[$lA^pM{n^7^{_\ˣxbp ܻs;ѫC2kwM*tj/,}̝6/=g\6ν]=jjk쥩sA%Ɂw|"迟ϖ-Xf~OI>%_;>m—5}윷p}5 z|&)~*mIK崉!{OZ*4uaKldRp'K?\b0 [PNm#h x|WNP<($Ӟ/3VOӛҶvj2#>d@* Y!-y#_'9~! Zx@c 9dl,/,##ߴ">0% \d%x?/B6"5_㍂LJ % }%@k=<˔<+ y$ =%[-҈˰'͕g12Q K4</Wh~"J/yV?8QM|?O@G<7yV2/1Od8 > >B6%x%2NX/ VtGHyft8 : tӇΦsi\N yvzƨ^u rBsdi7ޗx3Ƈ`>@M^ךK$23v/yg%1 ;;Xh'o|z{A}KIМ/cs䗶_й <oG@?1w뵴йq!WGha1qiy+ITDgY>"yޞ=7{:ǿ7sl/Q[gW-]L3uևX{̙GijN~~m[•u6|Fߒ+mu\'B~B3cK2ElIM6ITE|}>}XARD BhtHul5{fn %L7̙3)B8 p`@IZ1ǟ|ƒO($--KIzd&m 8X,|C͑KUf;4x0)>N</?q9ur0v Q>t&Ҥ<ѦKX<-mve9m?]AL@?n2[~ ;E@{e}Ã010:mk;ҁp&HڤƗ|[$.r kwz0ƛz<1>3xY6k8G@<$Mڽ1L>,Y83DnҦN.% z" `$ v90O#%)S '>AcxOP'8[+)Qٮ*{ζO>iweA#U1c'lߌOݠ~Y'ʡ:`VxgQ#P'x}4~O&L^;KdRhѷaغY ~.XK2%O`}vʋ3H`;fġ'r3/rWqlJg\JAc6OU†ݖ~(àKbi퀶M"'c r"9~޽O =fQ2VؾN|L҅M`L< C؃9xm|h-ck gG8Hބ;[ObPaA$I+8mESO<U9+e^q53WH}SU{M?LqtT*A&:r=CPw]@S2ӥX&<>]gTUa;׷N_'e"`̫ڬeELL_&Tدo2sb߿ /^)[&ȱ/̕^;Dn8kj/-e7_E^RF .EzM<3a$X7|x 40) M10`00c`¤O X3Cd3p|1 # Ώ|qGo`f@m& ̐/aXOHfG&Ҵ` ,sDJa ?pg ƙP؀ K>@j5DgqF\_m/|- +J d1|A(y'yǍ!sgPN0OË%.+&7Z: gCV0g"ҥO DP~ v˷i6BV1ׁ.$?ڄdaO?\&ǏJ^Vq#e,3 #+x |lN9RI&m0<aa #/+먫!wah@F^&(-IYYə|({c'Vw$1M8ayBv# FQVRr9Y0^$3U*_ uCz閰0̐=̤oJ >D&H?  ~13~VQ.pvyAbL-qX07OJkBvV8`Di.n u~740NF^AA0ʈ2C Ù򃎰d}-Oc8ҡW^A]nxҖq=X\p2ceh2mu(OޓX0`}_i얮?G@Mr7JuVy \+BT֯Df,Z/d`Tu+?;Xr/tfTiDžcUѵ^yb<)J.E`iBrՑ-/!Zԓ/!XC)#+ %/JRN43?GV]y~tmzڍ׼XEl [,zHEq~s8wWd┅RTBY+}rLWܪɊ5[dz<䗬9`@켼Y1Ɨ7VY:(xfx0[& P1qd!6X% _{2l:aˠU4|eʄTeKK?~2521xpx`ѿfÄ"t- g 2D6<01a -#,Y H4L(CYM/[}f&6(\(AQg_Vl81Q!O6C?eńǶh0'.rb%(:CZ(@nfE'_13QcE%4ʕ:, eVS DX%r7u(lP vd_ȩ[LV(zn参ՔLlng?À6J/&-L6TFYOl)xXEG^8ꦞdu SLH^)6d60Q O(@JZ(^dĎ$PXيv$fhֆDxS6F*ʊG߈An'V()]9^H_!}misG=r#S{y0(0R.1#`EP^I<dsty|*q`E/"E0.QN&eO0/1>I1E T2O=؉qCc/`|Ӊcm+WH9EEm}2u l&ޯ( Ie.0Y^IobøEMer[YM3杄vI<%/K#ɘM~n 2?kiSwOd(qX,U[q݈FOGx{"sdCVJ)fPu,dv`|}u^&t/)|L*0GQjN+IGL|t؉⪛{("sgyw2J^y]Af>7]VJUޱ򂒲KiT!c8EA>-vU^w*^1d˖?{TcٓR@ˀ /p\в2mq :B% 3(|'/p Z&tl5b/hg@aa`aЊa"d23( & 2?VOo f x mlLďȃm{$40bՍ(t8({1$lde_'飨`ub.XgsZ&3`b#'EDaŁH|Kla 6aưb $hHa7P_DS2a+-X@\f"N8+KL 0bM]`1a \+&TL3`6|Raoʄ.&o׶@GKh)[&IV2xg=-A>+ar&` )S ~  L`()7 2S0VfsnSx@fm(r;iD'\ 4(:~ Eeֶ:x)~ķ3pc7E U<)_5|Hvi .9q>5s\ R R08U_|JC.%)@`K=Fo NzK?SX Ci' L1/xd0(#./E1ht(k&o#أX"M>>χvl;ADa.B#*!n `LF=-#cޕ?Ǡ]A_{2^X;<{n]Ґ:yIykX7#cUG}1"-^PNo>LiAhaL/ure<ўHw!KQч4L!Nx@Ga'?S]Ș~X;`4X:{8mY6C&aEY [57' u1M"O̻r/ۻ10K1$-G^Yy/ c_(MҝscÞvs4l<<]G!j~?fOzNߙNNZ1~ϴ7K_ [74nāхRUzN2AOCvWeɯF2g[x& O|P/u%cB ;?fV˓AxB̤E'v~Zƫ/p7Qt5gBncBYVD0e şFA/ Euu?ȯiCĽ8,%p ?Qub0L­LupisZA2`ȳPtӪ_3 "AL8Z'Q: IŖbM Bmp)m/ȯXq]6sM8G'gy7 -N9L:Ы2)ĘAᔕ*3( A^YepMq >ʗ݂=N_RI.Bt=[C2qr0wP&,~(g 5IQt0m{uOJ=ΰr@lAsh LXtЪu:`>ʏ\*K+tZFm--xdN8ć!_%M*C*ELjtM SL^t } LtO3/ŅpPp;^Iߔu68+pm|ɯɊܡ3i}3'J&!Pl?~Z_L(o*3BG^U^LZCCeߊ*C௘R^Ae'r'N ~MJ':P2'>eu5GA3f?(3KN@Ou;`Q&)C_C߀R|hOm^'duI; ph>GX<ŀ۶C\ X3KT8H qQ47U@w*nOF)A{UlC[B9 mP5?< #A {"\8j GIu"o% _ₛU|ZF^ п?\?uM)Nx0aFf%Ww4|ZomuҖ[! `TRlBP(ƭ(׵F͆!>AgO7}##)'ޟP%O>.>O}zڪпH^+Ly8.¡\_nEI(\N@}?WP;qӿPwh?j}hvßp:6 OQk_ oZFUVQ^? Ǫ J5[?Z(kf+ 5#EB_I 5rYeP~~/Yǎ(Sj}v>b >UᲘ_'}5ϣ}ӿ3Fop>N-%\M`<-}wd,\_B%m5o<^ox>BƬ օP~`{HajBh'} >ƿ(G'm'_|Zva 挻V%}1;(I;'? >u %7_ڟCi?wO$M"Gjsڻֽ0~"'5)u0nV!Rn~ЛT'/^?J(in 8U!)[ˉǎ /hz{G2+OIdX2$8W2]x'c؞Md4{x$eKߓ3m2$4{fK0M[\K#/6>gw&?L,an/bz1؞Kc؞M8&WR@1~3g2=w?擔ZLd&|c{2~2 w)4}q0xnI $q$&˾ʕ7#=۳/Ǥ;kaTNXʒ?(PrȞF-,glOO5Z5"(Uvܳ󭓼sO O?3)_LCa8Ә='Sm6_ $gOg,+>R>4b>nw/5}eo4Г˛ nVu`c/g^c820c?vcOb&'[\h⼚g6n ~{'l q³Y<7Zs[89$ aO-,N;)+4LR.?ogxq m,l-.t 7䍿Y1-%7K'a<-x[FabL,#)CLGz CbEB1Y)ŷ4>%y&ŷ0V`rFf%l_(Xy &V~0c%dE6BYA\, jiCI@d'D 37OYc>Ɏ;[x#7nOFM6[3ⴰᓔYzIM:fH/4(k.v7xs['8>^?WG ;tIr Xo~28< 5Fk鵗V?qd?3=X% X%K3~iRlca[Ń+??47v[\d,4f7~7’bh̏a~?L١Þ Y~,^->-l0kljnltfm~1}6{6:39g~II1m{i=fx[i!?8cca1]l7z, 3:IlnK+8--ϖ&~v9FKᆧ˗m/mx18N6, 3zg4'Kű'{b8{gqbd~p~-,%![LHZiiŴ1[xF?xΪxd{,Gv{noi--̏'0 _DݜYbc2hp~q=:92 yغ™ў,Iv7]>.ݿ^ZhYE$_$i-tF1;ᄙ0s3o~<>Z|@k1ٍ78^OxFٳF '^{'%ᇱi.x[ܘdS80xC%/ i|/bdŏżb;m/N6Mtvi-=z O D?,/N{d'tigKҵd;旌kaclF3f&1c3g7zB>8vmw߫@IDATvI-mhߞq< 8$K%I^-~6ڤn7^,,~&yYX63?ܱ?}0q\{3q?8,韍Xn[=-~/7&[8?myv WAH{gO߾ߛ|G<3&yFn%D#8#8#8#8[@R^Mh*աkU_)rT緩Yn&KUAŏyeߍ{t߆[.o+؎cᎏoq۽>!{?}Bl^ͨ+դ<]7DmOҬM-<9{VW/kjR4-* eYe˖B'qVnnjMw(_Y)6?Jyu"uNeRCISwdIdԍ<"K刮R9圶aTiLuH竍Y2Lmn"Xxծ5z7f>O:׏]Sۇ?z6GvoF+7eǏ] T/Y0*ZdM+/ҵ@ٹDTYҰ,?W:<z9_NiASYQWu#HS Uml)r*)TM se*OaP^6ClyRI 7l C&-gf/ŲcgK\GV!9nRQ]xGpGpGpG5AQ,ȡ#@νxbt)P'{^:Kn]D6EZp&dMd{tsz~YvT%]z.W,` t+[k.~r1GȪy%Wk`^*tUX,WKfpfP [;ozzŚnPZܪ Ffvf2ҩHzw&}zvNA9R844ɬ[DH<#8#8#8#8?$Q`.Kt)kmwHΝ}~$˶\( !Ncc=)֕vSU&ОSᆲJӗKJ)EuuunX CKYۦK [iȢm2aWnN毑J¼6تBQ6JeҨ u{U6*e*On%~}:eTNsQQnozNt%a{J*grdUlJ[*=*o|stYUo5ʫL[)Uxj,U*tt [v#8#8#8#8#D] R-`*pcƎ9Rp߸9\A\Xk6ê䳗] #:YqLx%?ʸGTv o[Po>{Q2aR";g% N.KV鮫 *%!u59 ~8KآO|iN3~*);Ͽ91ҵKgog̖f#%Fʼ^=d*oަ\6hiʟSk.=MxR(1U9gIW_U5N;>{?xh?ꂏ||N8=jU{F)Tі\lV?-E ~ +ڢ[]W>}A2#Kewoh9Mޫ{|7e)Ǐ-R]臿te*n|yK/W$gmWw-_Y ۤVo!ަS9ߐw 墳N o^slܼEqwɺmW)5j;?:?UkK=W]&7QO+u2|l: TwzPI+$w? =:@*toE?osXʟ؎u>Fs S@GpGpGp] @n{zHzWv-|SUpˏ# '),ߵ\*raݬ]ssrul^۱CJ_JuE]\:zt9ĭ3/:fueԦXhEKY_ n[%SmTz8O4&|BRAWwFf~ ,AћCJ(z$ fT zoXŘn rp1qޮ")&+McJ6kcidt\dEkaFB2,̞a}:8yt#8#8#8~(u+' ny(l=܉&O/Y-۷KNtZ=[׋9u\e|-W=˧?r|EJ K;xe2(_uoPeh:SS'-kzl&.Yێ1)/GK ses)6b ykdɒ{2zUlTYAN+4&{Ё"*dVy,R94 U0#? d(ؚtꆚAo;hKKt{m]*B< 6mǶk{" 6Sm7~. NANІPw4ӊA =s+8'e?qYX Tjw8#8#8#80{Wd/;قVt-_~d]WIsE0z|\oPcb ܏e:;o~'Ii}TQW-w'&Q\W?oKyxjԨZN% ϑK;#ٸYx\y\|89Աcpߟw'mMұH%1噯JED??*22(rsUFv)d=j|sÅ('=*($f\`++) GFpq:BeV"%+VEn:~ߟI WHJ~*i銽6m)+̐6E.xZY ޕ6ɠΥr禣(yw".sJM6؃ J5MIa^"vfȃ1 ?+꿎#8#8#8@Ne)Ne鄣^^>G9_뤹Xr;cIm9m4I/Y+Sϖi-[";m̴ 罾XpӿPk/z2m[-Z*?6Q>dIcUHQK̘3_&*z_'*[׬T6Ͳv,YR&>c2of锯ɆMkX+{83_]>OSa7Č}UOo۳R ͵u\{h~ Utl~NKG"]6jg_)/Ϝ7y7ǀ2 ('frt>LԷ\7Uz&GKyʱ#A @3YG Ҏ!+ھ^&k*kmRRGyUooӎ?*btnKʔrcLGpGpGpC Tʬnjj-+T4gM*tb<7@t/KU1_Jd6ݾTӭa]Sn]Uجj׈/>C*B!O,ܰUd1T y,Z*rXV,uVHY5 u& JݤT Uʤѧ2F:[]#מuleѲ2jYKJ+׎0OUI6TFxk^4]}XIϞRk(8)@Xψ|rcvS_ŠPv`J,Vg4Ihp߬xխ$SoQ_tN2HW+WwY|ME1'7\2°@K՗nX#o+~Ai0]p2sjYQ]~yu =s#e&^Sr?*zp* ˍ_VZ!uU9&ݎ#8#8#8B`[{4gA]/lv[VENLrU5klW[laEsD٬+wv*miUg)VYnQ' <\ٚ% cgoxuӚ")I~gP*GƩVcΠJM)(l[ݥV[TPªp/[UA޲b&ʍޝ ?Z4T7td;ro׿wzVZ)Eb"8/uP?0f+MyxO?ҧO+3Nɔٞh?J޲u_!c>B_,%+7~Bʿ̚/KU N<:(#@KXT w?7[o}ҵXNs81ON*_}LQÅK=fI/!n\ݦ=w?Q Ru_I*+J*Bb˷jaI<|jۇ ?>>Q*Mv M4t-`+.6k(P̡􃖛p7-Ź >V0CjU]C_vOՉj?B!2TpH>75(UuS ͪ ,V7e#KWw4* 8'F 4' L vލ,PzV85lsH!`/nT:a3g~閌l۶Mo=5wxficepr˜C۪vw =>p4j]ftԭc{ف @6F صLFb2iL-u<7c|: TK>=(YEm_or-a]O*,mua_"tYl' tǘv'@Ilw|Dl뇷O?xq۽!?UhFann{@V4c>tB3I7+KE9J4. iгEye[]T}ɰ޻ mDu$%%%^&9}GR^IR9修+?J/i +,Y!=fЕf1f^4T[v^Vn۶1(0tN_urթɷ>Aݟ.Wona~\ GpGpGpC5F䢎z̭)޹(yXVn]UU%7tyc_ *cLoq:.H[TV6J.AY Ҏ3n*_=|ҷ| ٺCo"v^.p|(:<\%7;98L<d9\W-#^>E5jT*CXݽ|erO%P~&>p1!3t|X{`vC}X^?~ۇ||uޕ~y? @c3 N\{wɳbUo/lgnN|PRwۍch8?|x ?3/ⱥwv:aLlӳ=Qʕj|B9zo7{W|aP9a! m͚nZ.=,\V/2Qo>{| 7~(oR;yuRK}'̗|r#eԹVoF٧ppBo//+.1Hii,_I|ߞp|ĘvNv^?~x?x H]9AdR݌Y)ՠI, (dR㍽neeJ7j|ƹ=B>C/Fux옶I)U[` =pQw[|Uc~YlU48coeRR\d~ UуK=mLW0nnpI@C/IiHl;Uar.7G/hFE %t(&:V=kssdWYa[deDp@& E˹'aȌS,!}d̈; j*d#"?{~AAn?V;xF?i@ƓPd_É-d4GpGpGpC7u 膆f)K4zk(JvFv( ?z\6pYg"QV yS>dㆺO oAYZBtYC6qs* eȑgRɆ%?\7>)Ε:0_Tf]UٷPZ =taɚekR_,+JYET煅x]AP*v~ڲs&V2pWzrix:xLnFi[E>y%,$t-5eaUvX(c/,%bz<{d*PM^QVߔ*7Y`?nި:5eޛ&ɀz)eJeÚMkiiNkҟ !UHƭ2c2u aUN]̂Z)UFM2R U$hL _\FV 7'kWQ{Zk;Ma~Ix$b&䘼m8?GpGpGp5oJleUݺMۥvVqX},rp݊.GWHscT]u|qʨ%5l n=N2q f(Fܪ7 ÆinjvHrϓսohG/;ny\RO-mʄ<~|o_-ʂzch*^$E%2gdìү mqCX,&nhqxlN[$?;_2i(;53=?Cӎ<{顎#8#8#87NM[F2Z.X)O>P( sod拋 kϮ#s37\ Շ 铧Kfʩ+.-_V`\ȋrܸdؑ+Nm]+3׿G(g<4qsRO>9WɤO Ғjoj zJҳ7^h:VhhQS 뇲 UFcB,76Ok^ڴʯ5uQRTR:I>cra沒 `X٧s0YQvjŎ`֬:sBYꗄ]e.naHIyK^]> aު;/ڂwۏxVo`qS1մMpvuS@ yzGIR99zS .8fܘ\ikHYVZ4/V)ՎyyRas~tԫY;LιLu9LܚV+#T:S9uŷeTE5Cu]DV/rQIScsKeV2rMx4M{MٵyBDQw5n؁Hj,F fPv)SfS^ߓzqe|B{yr^>5bp7)n[՚v|(k/-捍M_^YǤ.=O(_2qR՗@̄oskj>=|ʰp|~x_ۇ1>}POϭ.xyV`D;8J* г0U}W 70'7WoU cy~m]Vc,ҳFIENzL r =oXK RPT(_zM&N%L1rx)(ְKr9]'ɥ:]Eƞ1J:Vt1sd˦ܤdEeuң XG Bۍ&J8 _qjv|Qq,Go]3G ,?2ʳ/ϒF]¥rҘåsz[lV+O0C +Cn#Ǟ}YX'zuqǍ}z^@"Ud=gN2Ow!|0l]l3rCm:VUSe2T28n ̕k7ȩ)ExjyI/Ƽv<;u G<F  Kymٽx>}}BlzvO#c:۽~x#bH/_3lK:tlmU_a.3j/'W,IկQYrp r.Wˤw"}))и[6Ԅ~("y*O?,D9L n2녙2g&L°ZwIAU2O/Ox窒q=Ke21lfU7Gu ȣScy'宻ӧx{C~fs(g ]dȀ*devf[wYC?,oE4"6oWr焩_/8597ED]iVU?S0&ȽO*Ͻ:'-P_I>Zy߮>:断r~?toʌKV s{Xc?#8#8#8DdдSzu)6?Owi~/xBң(O˕'L p, ?Oƌ]-Ho}yjQQ:D=3PWr%)k¬ilk%k/_U~1XVX/X!J du/TKERYfJN ՗_93F/K\J\I&2M6;Y=-?hhoY/)cƌ }rg>, {465ɂ Rٹw ƦYz®H2szYi{XAW;&5 RrU(MC&UE^U7=gK#DQf~n![U٘ln ϑ~]j|o)}djtP|飫E8WW!D)VӳDkUq꿾*B{>b%`ڗ>t`X}xyWV`%quJ9#Cf]}t'+9axzFyyBʉIeN?P&q WfUe*ՄR﨡 OF n]H9rϣȒgo<\;򌉱Ựr|u";>u"{G'vOo*Cן,e[hM!g٢th!4=AQȏs7scGo.{sq2bpyWM2wCs8#8#8#8v 9 (bV6;!gΝ _XBn4h\ve!<ӳ=>Ɔ0V^zIr[|'K=:cM2a+2;gy~;'7 ܾޓ/>4E_sӾsd [z= Q)'B]aL}SPbyq=-/[EϞ'odV>EgKUb/&ɰA567 cꂹ6=cu&{*o>>?zW|?#NA 7vv#B8/_UU\s5,=]mO˻HO-ȨY k/~z~^a8/GVBZzv*}\zj&9k7˿On\rP=@%C%iOu uVUd{$Bk {/Xuuu]ݵUWw-ko T齷@-@z/;s߼܄Xp޻N93ͽs3;sNlDGHmQ G"ۋ,HksypꠞJohL,Z%ƪ:$VcëCe`#WMigEqpb<׹qsn#yn1{yns<9yn3?9yn懟~~Z s4W~-{ѿWw"H^q/z2טȵ}:85t>2ΣC<8\$'"9)`%2Űմ׷J-![x%*&/( KJ6A(vI (ß[Cܞio#16JvM䔕WQWxz\\RJ EV.6/A `0 A `0F;8PwX9BHk}~ GcU@IDAT(vyIsb._r$JwjoGq;4-Gu~%,ߴ֜\g4_2&<_^? 3?A f~pM`ޟL=*z0_qr=f & ?:h]6Sq㤜֑8Wꐼ3x^z]<?6%Yu~O& `0 A `04X.x>!$-2f0!=BySgG&G>$H.7x]ɹG8-n9w O8М̦QvI$裖۫em& A `0 0^4ϣ\!OUqrїSY_zY̺369HȕP]E:}iN(E[dr '=nO$'qtKy}rt&ty9qck<No=FRBd F]ytp-SF ^~SHu~L&zҚKJɗ#^&E,}l"\ A `0 I Vυjr=&ײ, )ͷx_l?R )Ð:B)bWmgE5K|MkYI˫HJ12q~>RdwZ9 '2/5%$ssq‚tkjuB(bJKFvz;sq v"=:f(4!mT\d^i*Ztťlzv@h5lAOgPӣžm\ uD}TDG8>j UdVyTk}KlFNU nQI{Է-"it{mىĢ]ۧ_lyʊ$ W| A `0 N9鹬z ,|| J B ?A~d|/oUu gclF2vW4u:)8WrHE|"*Iԯ2 pEbT>.<=+!]b]e\;cC?/0)S8UQrmPB3tOaYk3Ɲ&э:I? !n \;&G=< V'ZIg܃ 啞{m8\}udqMu3P[W V $l2PoK?ISr}ת\3x/-,t RKY%]ԽZmk-XrXS_w뮼l6Nn[`NMmQt'RKHq"'.q5Ztq"׈tVdw^%Ud;s.qf >p> 09'8`3?9'8˜jU V n/ "+;ɮq %Z.^skxޯ' JC aU\3X>zgwn%5=?C0}-Y */RKo/*-p%b"e( 8ycΒxx|+4Q\o{{(ȷ=TVI^Uk]uG%mBP|,okIʖcuWuˡqL-'*ȵ>qž]c>E9_Lǡv_ɮO CL^[''2di)IE"mul4N<)sȹ=s<j"v~h@<yh y?M @$Y;poVIHF+(涩0XjR<|HJ Ȓ3$\Ymp@A:imTlcBD\ GBp(mR2Oږ:J (bѮM Nmp!8.iPI"OXL9"Tų,bi0K}J*Кuٶ B)femd$TZoAE/UQ7 O96sdnNrG),yX/h}3A!r㍏ħ7 s%c`NGL fܪvIQh.ƪ]DSg.ĸpSDW4.Y]*!risfw>"pΐn99i,$*ׁ4-\w똉]ZagA1ӹ|&EJgTۆ_p&n܂,)۟F۔DnY PN:$Qb{ޟﲎ9kw--0g9Q*`*g?GHUȁ=CT=N혊CziBIqTU]K}& A `0 y+K4ނbC]6zSPQ}Z {CRm⇟R%H->_.V1a*ڂvCZJS|ߙIb1mM] P ێPIp!1J QYR_sSE7>Ek6zeŰ~=8a?ob=P#f։ai0ȕiU i5a,FJZ> qp#*2GR*MN)b2%4t+H[_w\_>nIڣ9$ 5BɉćRyii)d6RSS]JKN2;GHa[uf%asNkP`|Ѹ㪳\f[_!BI5ҒT-Z\wg Ŭk\|߸JKN¿ДGB$ &sS'X $5,ۓOV?=͵ɖVtd8n{]kzM]i݋koZmXv5)s\ 1o}웞Bᔇ\?זUYqX]S.jcY(v)غ͗u/Y))m+4.sokIԈ_H-r[k߮g'[ZISAmt<{I&6|a_}m3[f}~g|iG3?/cSLjhz[[˰@zuɟoycFdYKW[o=6na VCiuj[\?[uGojT[{eWOzu٥cONرg5wF,6;q2"{kwYnbmV>*qⅻmxVTe8l C /涻9+[o[4|҆my֥C`t@ #VietyKVקYGI3Х]G#EŘx^Šls/2i^``=i!vNƒ\7L?2^2F999ܹyźu,9<͍ DXCHmCۘ0ڷi6rj)sxwJʫ+OmלRחnI6ZRtJS/⡏97>-Ȱ` "%n4Q@sxzOM"Llyn%N<䓺2N4,Tq `AV>~iϽM"Ξ˪jO=:*L>f5}+tg[C vWkmB]4G9u-8,+; &OE9ˊ%y̝,jlKB %;[L%Ei-v~y1 w6oPOm)9P5,i΂圧{}k<|]/57?3~h@<yhh< SpߔYepr:,ewG6xZ2Yq$5g߇_dSXc<7dp'k? (((@6m<77ǗJnـn#!K3Ks^n=A٩0wv"NЋ?6ޝa%݄%Xy7zGz"d >UW%jlDsP;aj 蘮mJ>!?dR#[4zUۊ`!s+s 9\5fΠÎycdLqxP lǭBh ~d#Fh`N[8/EÅt(p33-'123^Tl? ꈤ|뜙-{{3$9߬CӗcFDOW}0A `0 A෇,:(j hb6T*UP%r)K bo%ظ-Ieߙ|Vq1w@.ȿ|WV*:W›u5n٪^W/Ax rv>n1C ]S\zh1ck\y[i+f:ϮP[T_YEfY3zuƏî}x/13GkH6rm7ǓrRDSGJJJuTH]^uz;Ì5N&$$'!g,\ypŨ~*^;!"V8<ĩx{f\=3zwlpe2vVӂԑ)_czMYqaQ"R%)<-c4d_6lۥcҹ&_N;;_l7L`BK?p܀s08=9 /yrP"N==QC!-N-dd)>`5۰6'3*U+f5_sj0 A `0~4%ݪ"j &8̐(Ws4id&42ݹ1W]i_37}֥s ⢣\##NubUVQ?g~H=mZQ-\w||lM3 u 7Y>5zpoKjB$jj VMg ܮ>_u϶>o4f.Z5gpVg|z9֎}1&+Y//RH^0v낱&CEcW&54ؐg}1f+ 3?Q f~4`zN0_)^_c{%QTsT[idZQq-2JJIF[`G$rG*:JI1ZŲ+.:v7OLZzڶk eSJ9ڂ g&oߚ'.`uz"NKDÐ3V-Q%#*Rp%~2k1s#hmjm؊@D Y,ωhV*{$s=8s0?&'8qxIKKþ}Ե !u#*$Z։Z]EX)gHځ6"mRR^4=cEmA֦vhJ'` ?1jn<6[h_e;k2cVfM;tl׆,<"||'ُOhIi$#q1Kwjҭ Exzǘp(iu^$zr*{:F ꁕY0Ӌ}VfZ~+ʫj UJtMz|uGf7=f>00σyД^ʵ>ɪJv7s-& 2IW}\$¬dzԕXVTԓ$ ۯ3S\Wq%Fza=gm\u]?5\^a \pW\\`n۝g}8ܼ^z}-c vLw\,øwQk v.zkkE#:몍{ai䋖MZxhЈV K* DF-E%eb+ nϓ沰*/md~||̱tAgGߪM\sG~aO >rw>j<Թ?yd|dLt~5TD,th:Ocѻs"$+M+\qޫ+sQm٭]1^%1:GL7Y֫WwXv0ל5JÎی]lYmS[Qí%{e96f܄&pM_GH^? 3?A f~ߧf~4~&hG}/9?6%IK±ךTI.W'Jӯނ7ģRklw{<',#睆3Nĸ՛`d[4|K\H2?r  WIvhsi^ۜ~\ GXQvV90)-%^CPw\.ٟODGْ㣷^EQyzwiרs?;K_-/bۮVRu;tUIEvXWC\6xg q5#+h+35 {wNJu$ }^ wcf㆛ ߗ2_498n?Ϥ7̑~2xQcb_3{f50&kl_ Yxrҹ odkf$͛m+Mt(2u-B.6RէϮJ|[/aHM= ,{*NhnE{!~xB:%ul;踣Fm;*<,~oxqCxw.=tZ2 񙲭9{>q _֓_#bѽs^;MGc^+ZiPg=5CJU疦m4h%Ngmtg\+"RN.L邅^,65Y)e<-G>5MnHU^Ghga}qIҲ sk JY]orJ-NSAC":3yӝҝqs]<76NL '0?f~0AغcW QRzDr6ޏw>Tpڼ{/]P^8 {,^pFN>t޶qg.rGP(jh?oڒ~i":d9G8bUa-xh,6ƪdTMG-WPvPnHs,Ta1o {51$JQłȥgǍ`u$pH/DfUqE6Àq%CubOQ)8u3ڨ nvLHQ(mt.@j.-ȍ$7;xƔDLx#tm4^8w#oC²9dMuciwx1VYHݝYy.뺹4i8V&*BUjSe0 A `0~l㮖unOMUߒWxQv!&w/]\};%>m͌:^<GHлtQ @o - ̊EzFDϏ])A>ie#WAC#gZ,?}9?ƶGn¶* aA ' pΖX߫G AH~E8Y[K}}oJx7ͥ7-Cr*H':4g[ ?Hh7-8_)BdX6ls!#9tlwk }ԒZDUfe0 A `0~RGEONa'QHpVbGO2^<)#x"GB<)'ZZGЫaeuuRO%a(uT*u܂,ځ⥗sX2q|+b#QZ^Nh%j̹8󎧑*bɈ `]Y}f_Жkb>Fϼ$]= *'I$;e f\KfU|Kd s&zҚny]\"v mrK" r|$HF/G s`+?]ZӾ^r_/WYBx||!1+w[5&Kit^ Ň#eVI jܷgG. ؏/=>*]݅hw^PswǫSz)c#G2nx/uȓ#v[\ysi7sȃa?o |x3?f~0y?o :-L>(4\_lW hI`1T/w'mecy" K,W宀dS*W×{L},2pml.T}yxBG>tRU]m-؜[Ê EZ%[)K܂/ Hюl=i+wcY }녿3]ѤĈăuI<2~48!D뭢 ~fړ`ߜū^ߞ޷+$QC9dY:8+rMw5JyM%ҝ[^lBܩT{Zc<}t"k8{>K6]">}RA_rwX_hMZ^n-qyriWƒRU{xI;'ɣ%xPZZ'nd:@O$xګi~It7s?4I1v\̸SNIdk ,"~26BE&g/Č30k,OK,"[GpLNt"$t$߯WnNm?5 &Zg{}cj<} ,2=}*K1MxUx:6~,l&4y>^"9 ~<5 gϡodv~eXs?lfv #z 2Spaݶ݊ZOj=^1 p[1< 39ۡdߩ};!).Zi7IoVǙ7F{?<73Lk(|}c.oQغk&s بP|CGzQg1A-9k5jjk7{ ~? _<:iªiY:_13h0~%v?Fj&:"qߠuIز3Ou ڭc7b$a^TcGP;ʗm9W⏉R/(D-*_EwtMy?#A@E/A `0 A ##`4ڔ#5a _*ܷoN?FwNVڀzۊ^x?&Zq#m]5uzwB0ͽ@?}yquqj-7n?7Xaz1y^T{}:{Zv1ڥp_~|z<J31I#!x[n] 6C [. =7i:mU/ilk;/fچ6W?s;)Դ;Y@˜I8[F QYW쥈ؑ{͆hq螡l!m?!\}wn-j̅00vJr)ql#ֻ)L9 A `0 !OFA Bd!$`!l B(5 $KOMpng]OnN$g#E_Rx-rSnbB"48/uvrΜxyru5ʖ߃7_kٯ N]7q GoZE<<.5-b9jh)*tmPk=%lWݑ䝏r!]ͧt/aGkyԒ A</m[TΕ>_l8-cw%_IoGo8SxYV ۩]:V$s+/RowX~ڶ\DGoןoᦷa UXK[7".Ac.` m0Va]/%]J|$k)i& A `0  td]N͹jz}7 K/Ehh(5۪Jtjimi϶t!ut*&$hqG=n/(E7:ОZI$%:KoC?j隍~$2ol65[ RdPnvcB͹ HŸKmn~&D*DC"-X>t"[Cs}lěhZ-XWv2kK5M%W 5!0n̥p~JcN(+7hW<ǭ/|ǯԖ HKN=>ѳW3-_ uQ掔d۝qvUa4E__җ;|=}R9b/#v/~[`Ltw4&Ū;d*^G[I3.:OͣKv Cu=5% ^t@_l ٨ COgu `0 A `0~4P>oJmd1'^t>li%j~("$\Z-h  sds^ZZ^|Fd9.&&Bm-D{+lmq9mh/.E(V]|3oW񽹸p!ؕqxe3C|@IDAT$F2>{[c0}6%Ecn2V݂x RN,.]V~Ȧ]Ct(}y߬7`XV78;3ku<4A `0 A ##Ue(ϑJVDz[VP‚x %=%+EU[ݤԔ $r^t W9Iɢ]tZQ'ܤ8|\m+撦@PZl̈EvF*+R]pկ#aAFWl6vr.ހ} q5a, -66Ă5 m$ҨCv$ޟ _ي: tV٩ aS^ 쒁?"z DO:>{ѧSzنRCzwVj:ƪ9|3K cp>j;nբcR(:k ޫմpj*"û$c-r3I>zX Eݒ" E3Eb`HKIRyKr=)5IC/d 1ښ1X;%sV+zVA+JF)[/[;ѣ=EWAtjrK'.:Zls7쉋 W6eU՛r8 ز F%)v/}9&z o k}n7w?3|Va|^3]aG3?,cqWsÃ&ʪjQIKCzex77V栀^bҚQn۝W-k>JSC 6@/Z7Bv,$wkZx;4٭"Х{:BÃQƅl$)MEN"Q(UHymI݊rʔa&W,RFZ _ JS39e" #+9w~/ 'ΉݤυGjZ n74igݳ3CHЎ"伐[tG<* <ǾwIډs`o, Ŕ)B^I kqx|)z&;oP啯-+st$$v7=DG3WQ8 &Hȗ2:躾ZQJpb,<|RRp`?*ZFSx)hX4 n9-ٶp;m8&ݕG4+L!;±wޓ{Z쓾n8S̿^? 3?A f~0WE1hǓ}~4e"v.lщkvH& ,4g^v0 Ud#@9D"Bi2M%h?CNZ ʎ4 0-ˆmp!Z21HLEuaƽb͋^;PQS16/ײLW2W*rOYlOai/_r/$Η.sF'!H8¢(BI>%-\҄1owYgB)u\"nRf$B[֣_&xzU~iJy'qΠy҇cdq\Lkc@Lw<2upK=x/zv5͵iy'uH2ـNozT)A,Ng;>$0q RS"Dz$" uqṮ#u+lW$D1=pR9x.e0 A `0NYbGEmgln8V߃?p{XPhNTD\zDE"'XFϗ{&W\I$\ػs/yk. hNX0c ^'@HD(k[OIxy԰6b=# ٖ*~Ѕv"i*1~t읭ɲ2g_٭eXh'Oå#c=f.E#紅6} 2 v][viKHh1]йop+_ё"| ]a\t_bioY8ƧqJAcaZ$AIeM?6MHʉ&angaInuY9Mu]ȕ4 v9ϛɵ_S5Hg5)K|̦vU IoJTZviGXyAq%פ:o;:l%1Ҙt)Ftfk;Gn? ?a"m?Cs>0?\9?mdS523bѺ}k$ID ~+o’[k*ڟAj â%p #sD rn0TUn(-,Bna}LI6a8Ո PZ޳-R6hӯnn]7sz`Y9 wG<;F.)mСW6r;(#=Da~"IՂ.o> ?;gA}N}C\d N=,i-Zud7BD-M֍ _`ƛ"/'y193EㄌIq's;wf'Jt?*~;1s5&~ދ0ih#WR/U,ێ>0 m؟{QL'&{e!o{H AS"gN<|^ڷRJLmm} {LDg"k&ُ "{9v&'B8P4"d~t9ϝ帐r,k_{.'H;1agǮ3 A `0 !?oxϻ u:g$![ғ]@ɔjAz~ CP[SF:ظ [KܾGiI Gi7_#AAJl߼ޑ~jKm m֜CX$(G  @5=c|k͛0a,V$nӫfƉyڵ%XK>ؘt ?W>-Wq`Xx'rCnϘrjQTI $}Hf+ۀSۥVWV#ځ-ZxǺG˭B[Oc׫1/1XW NA".ԑ aXܒ[Ni;ZyionNk H_u1- <#-S%9X"߆^t8 oX7&:Mzd]c"x">M?kCpSУc+Fjc+dS} U/jPkqw:OJUqG-W_jWlirt+>!!E~-/63_={A_QǝMקצ~'׌= 7H!zB,c:./†#s4NA`p"Q(jSCoŬhұxl׹-YE/' CIu;)1ʱǖ;H"!|Co*726=wE9GG e ($úRSEqHyI9|u7>?6բYƴp@Z~!N-Č8qNt,Cȯg3?G"@3&“?~~tڷuET&^j=Jյ?bUΏ$ k8&ԩ܄LI_p&|~Qj~7?D)c0 A `0( ˺zXz  􄼋 EVZ}%RDMA?\2TN@rEEGc7kqK>Z&U_ XM'}j)ص}/ ݰ c0{.d_.rn-|h/ф!MyΦ }tsn#yn1{yns<9yn懓o~a>l懯䢦3Ymw>{#2Cb\z(=㺰rj^oˆ$oMu-~sZj xlr!ؕKf.QZ8.tU';dp,Nyo H픎@So'-[`סRUءgu۰|䗢?GϾ-l^j`W`WKs%?4 FR0NBJqf|xmu[:Vm™+r!Dؙ G@7"-7!t'ӼWt>6md.*7{J;{ZQnA9Gs&[.C04yiN=;ѽpeg7?9 ǘ}T{_~\{6܃ is⪳GM:Ee'# @)j /45MD pwRUW{o,eآh4b&Xhb{oK]e{sǰ{a澻s9d)`o 'lM80q᜸}gظq#BBBB ƍ8)mG?~r#>VN _1vP'<)~7V=r3eM7b bh>(+-{e?Cw E@U$Xl|A0<d/[35:][{;)8{Xip>~]YY3WLA)c㮫Fc`iadmjdH HځS5WA `0 A `8>8f @l+k&ՍZrzJ]K ⨑ h( 2!_RE|~(/ecJ5MIt &S &K1 ?WRQ2˱zsuK9J_$1P°ǒE/+9f @ &[v[XRP*pЄ!AL0 GXX*.K.EPq`\Z)KbT"$E򸯬o9XVبpUX~ɱ(6&ڤLRW/GkkkU7WA `0 A `8N@!ጊ R]#J$Hle)qtѝմ6 (hA ;Nz*\%Sb Vr/}渰S1jh)./bQ1AG#u$˪#r7*>_+ֶ珃7%.l!aCЄ (;W>/j '|ҍhɑZylz15KYdO+㒆6?& EPhvqj2Ys/qgƊWbx-âu{pϧ(/:9U#K"7]8q__b{>l&1iG[ڀs/(|8s!IXK`0{=PFmm- tuUJsGQJ PM!,\ gL +>Yw]4ܽH*@5fY(Z@TloҾ& A `0 1rm @T|)"Kݒ#AW]V$ I~т_"R!=Z5rHg qBO%GgG+IuƓbFu|ѩG`"]|rD9^4gLDKs+܂&I  {ۨiPr@lt(ƞ9â'#aIޟGk# Atb4P[H֠᪦jBMy4@iu**C`0?1 Ghim9}6me:OZ:]w {RΣV_=7q]qьW]caAxdZ>)qg+q~fF~>h`ڢ64Xqi Ggy)I8x" hGkȦA `0 A `0;(c"c%Z @.d9?> cPDG?f7I(-L7; L2!08H]xfVn0iGGi7}]~e~6 k?.9oڔ._|J,jjd!\l ^:;/|%gAv/FZ74 3o^7e |}ѳ:lkks Pս9eh"ml/,j#vQ=+0.XuPsF HҊu˶b=HChA A@ejdLyc C /_}ҒTI## prUg#.:da;NC: e&`ʘSAH 5#=o"qŹQY]H+cp:?? ;nwA `0 A `8N8fPK| EwڋnyY 5Rp姢>JC0&9a(-1`/<U75LZMB35M`iQL1TL0jݽ;4 =QWU9ۣOD}Mp:f[Sބ25YX2?#Q'@v~r-C)èH$aˍu0%P.i;88  !)!?8^^ w>Pc'!7> IWo"=*P1b G@@kI[ΓyWx  iG^%}@fO܈1z:$j )qQT tA8khR|2I1=s;.; A `0 q1*﹢֝pSnn>\ !pt¹Rۀރz#/;L gϞl<"Ko!xEc, | j0e\/%{MOw_~Lawגy.1h$LJcbDNx C u|yֹc:!iL=s@!j++k"eݧOW ';A9N:;!Yuw v& Xtl7-ۈI3'afn#&,sZu%y3N\4֕;$ߓ$<0n9:%G#PkiAVI]y8Aע_#ɪ뚫A `0 A `03Cكf6+K*\ݪ=y6&Xx:Tb^6 8~l^+iJ6+b窕ހ%H@c;T?YkQRٴOظpEĕ)KKP^=\)D'#DjUa} qCC".VYZ$ H6S/sHjRO6B"A4XuuX`Pނ%bAJЛ[HB(G4f!4QWeA~l|}q:+kkz}RmZjڶ2ܯ0!)u5>)!hu=붎Pu[[-=LG1˧ǮqU癫A `0 A pr pږ:ܰl >~`>04h]*nP؊S`?ˉvzA5h{lE&3*> C!xC?w,]XWDёF0# J!uj{,GpAa%~e>v-)79WL6ڪ(veSݍ2yT2v5z'XR_s } Y #E#f\ȝV&AM0NnIZ'uWemFc)Tiۉ?7ݾ:'e奃^UiuU҉$dlCR۔F^rpՍ=:LRES]hy[4k A `0 ?Tp|> CZZ2>CkO—y=$.AK2i/M +I1ٵ(Mj:4;W^o҅@d{RVR.]ڨ#?0>چt&:$: nHWt~ImDp Qs `t?RI~ly&EX?N8%.rUk'ty=n]]=yƻݦYԞ2 =qrG#W-9XXoּ5/첹 2A `0 A$C @robn촑8e@eOlyxmia)}}Ub|3ሢaԂ# MԄ@~+ӝGya.⎷w|~_8u$M1BEbG^%.\731l E&ǒ#yGDc7選Uw{JeږUEC2dlK ʐ9.,4^ڨd3&"62RTWnSGٷ8vL8Л[J#݉&DvY d4M蹧Η{:[ybc`ϮuHɺ$|"ՙod|n@w T%MʌB5p𛮯e2Ƚ.AT v*/U[rױtt䪃Neu\_]sQ<%A `0 AC{HEl4-.~rkoiSZr<+v#~e$© &ٞO;}e[@W`\$ ($is>d7r+\B~>w]zR8J+3 ْV뮴 CicojC@5pia9*JkL0o^lY` G4so[s37碉}ԫ8 ٽGB~T䣼y; ܈V,b%>^pt6sǎϖquE=9) F۝`n G7r/]MIrjS-*U\ 2mꢲJ:(cnN>vW=Tm[?o-yeyҲykGk$Ί>SѩX1VjPW/Ӥvӎ՟et%' tmK=J3 ɗ-BH*>l뽽Y6#ǃF b,/%Y RW#e%y px[!l{0nhw?/gWuUOu]Uȶbݖ<{y+xO1E}p1ȨZz&vt1] q҆0VT#`)QLɂ2NDKDXw{ϲZ& `0 A `88fY.v˝A4oM;?KQZB̾G)ZJ9I$⤍$zȰl|0JH7">[H$ʱ4%A4M$+#{QbҺ`S]o,$hW(@G zRTKΔp:`ʓLN_G@M諞G"B˚?<[yO֐9br|v-(پ$ @Jol2m۵akpDU Vm؆ٹh띆;SbCqĸHcR,]1ɸLF_zSK5]sQM0 A `0N,S pip}s}"[uXѭ"۽:TI7Nl<7|RRR믿w{;sQԀ2?|!Hdʧf\<$kw8{O0W*QEơ]ㆠ7~cΜ4V^x $Ď/+gNU"JX&JAg)MjQw/~G7]JMko{B,U,Ώx^SMWv˧aPFP6ný|e܎1CPۼ)sǬ!)j\tisދoļe0댉j\*,͛A `0 A "?LoAC`޽;w[0;N<č_ $2{ >4[w*p Vo3"9\VQoO>zPookG+Ўك9y虊3'qҖ]2n"$VIFBO< P]|AL<+daoٞ u"%oGcHZ⣬}b(Gmnj` ]I2n<7(ǚ-IޅH(K'PEoE({hSIHGo5tmN4;EICBz^2kVy},5BH ==96B,Ģn].w"^Ԭ{tX'v [ߝ;iO9}#>nj{" qQϪb_]47fD!==((EhU6Ge\BOč,}đŻh+\_OtҎ`ji#aUf0 A `0Px~[/kX&Acb9KH}?w;_˴1  MFkԨQ+W^"X_e';9yձbNE,ҩ p}@AΖvp:JZ~;6*t3:=;&O':x/p˟8ptt񯏾<yAf"lLj}+o_б c{'")6UI9DKq|l3$8HtdsG`_'6:m܎zLQλ'ty\&??$L&!'9*=Ŏ|ee853AGKRQӶ# &JD_xcWxt[Օg9FQkGm/6 A5Hgxˑn'C em;}iBɇKGP疇"g.A;!ގE[mr KAfbDŽ60hJBh]H_ԪLJ;;JLg\qE p ykA!N9ڬJ%柎Y&B 3?0χY|P_C(XsAaG>9C|$Hpu=F@ToL`r2KMM@?ic˛1;W"{kΧP=$-9c&XL?ܡ]qTPsMȺ{ow8о|s>~{E-9B:^bNolnq<L:j$@JEU\0:Gq[[fPvnz,y ' |}5権W}=GiE/r|EDҢDTlkYQ.bIj+78yvK->SH#e:Z)sb|ENAC8BKuW6 ڍ(WqlO=]@^7qmBat\]f~aG'y0Cl89Gf끵 >ߢ)j5k>S|ט7o&MtP\S '#q?>)Xqe-&2W+#r<4wO!&=[>z}<"w$i;^s{8XX!$xm´E5)'_-C7hs}ߠX%\ھ,_ECFSy5u C=[^*S,ȴ^wW]8c|*|3NTc9ҵmd,g>x8* Ü<__{9h?6䠩e}{`SW?cŶ\OmCpsL幎~{Ο=:qɽCtȩiohrMvsï9܇$z~gA6Lnx+ϑhP$n%JI ~ p2cc֣`{A;8 x>XA}{ȲZo2'CHs>{TǙfƿ<v#%IP+oEΟ<2=w^IˢM.<"w ^ZxVO]Dkgў#ޢpovNC{:FLDcT,z.Ga懞 f~ì`B|C^O/myc_JRﺬ$X:[>A1+2H~`*W}Di;|ܜbWCզݵ {+>a7xzy_pJ+A6%1㜎J--7tq]q lQoLOudo~H[k7 OͿ} D3XS$~HcMI%D,J3{Vgumڅ93)̧>9,^i3}'@Em}bcu (ImH&ko1ÝCBM]c7CmHG)dEG҆bcݖع6^? V:pV9.TWmNw#ALD;NX8>&:sbGxh,xH6G"H:yQJG. 1ua}.7m%۱){^iINs9D[W 嘅=A'X.GK+1Q86'C`ԛC#:Oyd>狋Y_z\0χYh>GOP=lO gۊNFIOl4u4-H|ys#%h?#xzR;N~P'2l ~9L2 Nwvr6YW>l^pJjڻW0uX_\64UO৯}Mݮ<{E]7׳=:t_kWmƳAyzF>/ϼɢeA `0 A p yKd j:~R.KjEڣuFWRޏFM"D^=@ƨ®4SHV]RADQ'87 :"ov<Ǣ?9bO\]A `0 A p#pDPM@17&l":ICjرxţRKH b_R :y7,E?/$E͚lmсuN…fI# ~ ;>#A@@)GӶwq@&lČΗ:_וJ<]O4]NI]wJ]!^k]x$ЇGjU㐖'Mr/BFI`3~T$3MSyRG]Tk]:/<]!}JlҦcz+QH-@KbWU!~uY|ؖ5ViCݾhS'a?KiO)uY]מgg: `0 A `8>8"(~B ח_I1s2iC^ ʫmؖW^HOH@OGѻXnDސ y(W6Bzv]l@i(W8xCC>ݝnTH1[\(eڳ˪~U|4Ҩ_,]xG۔j&&YuUIy}o ~v猾O:R u^y![`hɫZq+o z*W"t3xXO!W[\~:\LIG!ë}? $EȶvAd A5&*v^R_t .?Ldž佨 QCix}ć<&mUL/#j1qɷcb7>RJp|Ya:irΞ,fKPN8{n_tu%]|4ʗ6=T<8 b]ҺlY;KRtYJzin%t1wcaO) ٬vtWo1sc{[1| >}N0|Y^K&%6QYqOJ^w)z%_t+@1G4J[&2uH a(h@IJ^<]eF")_#Y.Л?¼֦5a|Hֵpe[j۟uҾKO!>^$ڱ,~&L ,ljE  HZ-!v,p Q}ԱeS儰B(w+8@*6E@U1+&"K_d~+:tK^>.̛A GN&zВYe=漏.*wY?j?:_ǥN;ܽnO}{]{t]pW=CՕt-.#x]sp}ݎՌՎgyVJvw5;h<c0jv~L `0 A `88$(W(m<k.8[9Y7:u8~q%H5_o*56DЮ_.vk UQ lzD.}mlٙ]TT>A.WJ^qC+Uk D[/m ɴG(hI>B:nSvIEƇڎ )̖v+Ev!dwFm+1M9[UvbЛ7+"^öD%ybCQGowv,jgg!¯]RڄSAt^!$2-ieoezlYI \z~د2xqq}eX1 J*r|L$ڱ:t:moV1-YzYκ<-ϡvO_-ۑ>+m#ǻ|:>SBz> _A̯y~c~Ӭؿu}8$(u~hSi/"sljc xˑٳnϷ_ƦfױzqɰLyՅo}s3{ ٻm\IY-qsOǶ`u]oێkH4E0jn+-?9גœ>c-F04N;fe眎+Zv%ebjJd"%2[1rpaK 6fo~$cI.th7ez&Z|$x?EG'}ۻgN@lمK{ 5j.DŽ@iE\_X 1t00ک1kz=GGτ>]1ɤ#+uԣm#'–ju 3K1mp7A%u-4=Fmډ5[":ȥd֜yu֢>N9o}ie$cG'y0Cl0y`N``>Cl}h#OʊސnYnN@/iz3fWpIMD=Ou aQ!j[yNu) 90aEIi j\1XmQܔD sP@:n<2 #'&9g'V\=(ݲN{nqёnvy /Cd[H"=5I;qCwb B BFzuiHC 8?9$MR6Y&<:ujYyjr"R)K֒TlSy v#שc(aO~)Ow;V&?c{[ D' >z2v=d쒮$.A [ b/C0[:*~rA)ڇ8p ݦٞe5 ?}c=m,gbaC-O&[%rݶp RL!Smt_*hs,Z7_? \|2}s}>vMrcםؙ#HTUb5 :[AȑZu1b[I%jNrù_ܿCmeyd-y(%,^Oqڸ$}q3bf<\TTnPc"k'M >dx{˶a@ewO%3"*9_Qgj塵\y"wµɄSp5Oz*n|ذ%xgo≋ԼYl8܎Dtx(ؼsx"xh6d~ 37>,\r4:?3{cU/c{~o-+=^\u=!OheoˑaCJB,B|u>Z:`RUS5vf5HF05^JL85kAjlFcL%͊ lrjq{/9GOlƠcYy24ɷcb7|ߛa懙 {>f} {>xJ2׽Q&n;6a$'}d:oo T=ٓF#80$ͦ==#0+@m-.e:9d:>3sln ?]WOg&Zs00=cc_~80bтexwm&Lsпj\9L&G߽2v8kL洑¢RHITǡ~!Ҋ?6^|`D4W;Fɿxz̼Q*l00 %,]?T/7AHd]E<󈝪:t> .bYe`8 \DSSuLV<",,݂.iVSWkhnO ݸ.GGiflفuYy8uPQ&x q!8j:~eN>f+Y8z5l]$";q(} _=AoR +GE_ A `0 A " l! 7 %Ac!˜qO{tdccBY6$E6|bUp#Idr+ځI-(.*Aߑε"yxu*9zL#=U}%xmD%"Aw"j8z&<x[~Nq׭/#39Ke73[SR/CkO%V ~U552;=gf`LKODDXgL[~1Aelͬ%#G$)Gc30UéR|?4[9sk#&^yİaðvZ꫸ꪫTO$t;v]IȰ w"hN?wT"tH)AjMÜB̚>? LC³ #.kK7a4f?j3FCqy5.={"뗥h+A `0 A `o `mOTFZ;PVEҍAȹ3cx,*<+5=E"[%(d֏6dJȪb֛S4mC?R~hf7xM_E#F 闁o7"&CJ9kZ".>H띮^a[1Hnެ]MG2Ws:''.Xr)>mp$F+YX%Ev( I6BM` 0Cr7>CwRF{e<  *@] o\Ժ$GCzbkN9y?X/6yʗvб=^e],]~  dA5 `0 A `0~PءY|]7rrMw#]$cJ^gjc|'O\VZ4ߢAZ?΍5d q(C09лpw1h<"ˍh I^'sU缩1aش\i h,aG~gL ݣXb7"_Cb8m݃XfGՖUo0?dWYf֕#uXOхhr/>UoCi6ds5N\65WPZ7)Gψ`-qhCŵi5!Ry1t1٠ :6S x+_҆עm-&$:̣C~vOjKә51so0 A `0~0:*.EC"*soB\UbSqfa|'Lrs>\|?nJEټM@Οf;gLVeO M<-]L0N ڸ>JV#i*{,Jg\M;U]j^oَ'_\sȏ?zL ju,ZCk%$~~fe\l庵:gblI4<>JHi]Y$a(ev 1 A `0 .KDzƱ.s?ܒ@Oq]7ƋQRqJOnX_B듖;FFJ|,2zPcav똘@³~1Cd ]I54bPF/DFi(A5 s_܈Ǝc\6{‹[77y9cdF De,q% <6 c?hcEmy!98l`?UEeg>i+W>y/+J&qQJF6^) oi9ɿ}=:],TȆ}aNe ߶snr1`0鴘W_}5f͚o!@trOvz&:gLr(8 /~ mV΃ޝڊnOVm*Fή<:9JBJTn)=~x5^}gn}{*=G/Vc҈T|M:7aEOÝ虒i딘A a A `0 A{G{HՋltWDh>^-FlT$c#V3KiI('q1Q&)er|"o]1f^<HkQXT}HF2 I' z.& U1ɣ)Ͽ/_`/,ݒa)1왦HYR^D'Gij\t [i B{O:7܃mH#)_d$9ζ)k;w`dćOz*l r f|\, * Y(W>[z$>#gkwT'V#mPk&wO{\^j,vmz V&X}a"i_:! v$E۲ΜL6ݙ3:Ƚg\|4(AAAsD8 RIp ђ xsl >_5UVOVHMQHG^iO錨=?hR+zG>%xee^[&߬\u0f}5GiB|>'f~ìf} {>8GҌQ`WrSZ=qA$xLr: Yy K)|d ʩiw /[u;^Z )\ ھyM> 1(  wNF$w~a1>]-%U q/wБEԜ Se;`7S뎊r_;=1e 8Y)sDZL((W)C1uӮa% 5vͻ䧴KqS08ZH,.۔we#HڥU]\{ڂ_$!HHdwA1<$!;w^]&VHa>Q4 MjGMPըck~%YJcN[KEuVk"y&dJBmJʭoj %6 I֗ղ.@" %<,yt6/e+!Pt:ԈJO6򕡕_Ihߛh#уmcRQc>a FM~Dp/PTѾ_x !&xF"c(!Iؾ/ÐEًxXΩeri=0^v}WdL8v֓6VSVxE#\2{@@>#zc=to<?eaÕ}+6Ooo-~=uLuM `0 A `0_iޭcrTȐ _̈K…FHY:"a֎\`Bą)LR$[wjI;4.Jռtjg<&+y ̋'q=%-_BIXHc'ǒCnJROx5 RW`8 YҟIO' zt%AZ(ow2轓/i_&%cҮ @tKKdnb?EMƦMٽc!4pU쐸Mb(ɄqI ęM#kYc\5YU䳀.ڶh {rH׍HIw"uugB'Ie|ݶsuR>Sx$Dx+ ȍƧǮ5:n<5fP+q<|ysIg?='rmߘWYwL8ǒ)$n|&[V*xH5TTxz3HͪUROHF1AK/GAO?])ğݦ.cZ%Mh|rQ+biRpAM *p훼{?&q=u\:|^{\졫Y^9]ϞouˉWlzQ#coOpkEJZ.u*Wvyw]_S_Ծ.wWO|CNGTķi|>f~ӬO֪nYgֿw4G*/rdןnhc/ tUhҎ8v̡6?T?F&SB@>#zch03?ƺ߮梽.=HzmtiƪtL} "y=H9UOʨ{$AaY~?=op[~RwA=]]Mٮmg?1)PE;9sL5wA `0 wQ>T{=m%"DvnrWmhU(uGYMGS;[~2#oY*QY A `0 5^g[R|2/?گsfEyu ]3y5~&J`2|p~/Kܞf7q~hH8ݺu"etV]I&8iOB] )JjCT}U-\m奜~޿dWum4[\z}JnlqsfOUD>>Cg}Kps9juyW;=6_zkw*B"[g!mƫ\mq5fݿk(z J~K}Y_M~')r5P1aN`hYb懙9a7||+K3>9>yc"bܚhDKY r_][/ hmkeb!HMU夼Tlc]Do/K9]u!bMw}=Kk>E I;9Qٖ'n;_,bjLz\zl-u#OSȸdae*OE[>~Iƪ-\ZPޛf8lU4bnCwQZyE#6y.|Ij5F/^)M1כv8y{{lJW%~̖du?YPyīw#r*N ]{KmWR~c-vbݨofCs"MYcRqwW㗲2n%U$5~W"|\maѪM_7?wVBʷէ "-2WIכir5}N0χY`_f}0Y`_iۼHgںM 1x|xpSmk'xdéwVΓ< s5W]g]Χxqv|玑<}pU^|&D;C/Vcp 6*/cd{PS׀VGdx[}?mvR'&/j^g?E$KY*"{ Z{RUv-k]wm+ڻ TT{B賓7o^nBw*3ޝrwd3| vKoVQss]A>$^bVNw .7Z+ݴ ^tW ,uPx2ir_9sr*+,dV ~ޞx`Pt1w o콷",$X_>r SKǤu$.S2%e<|1(ݕڐ,-#'|/ ,;V,%]]S+{s'm&2(,gE63;^Qxrlu0i `惙<ų`y(Mr&b,3_e`bs(f[cjnaO86t:n >睞:2t=͸wd=yO} M#QW*^{8:Ox9z5c0sKԯ4;|nðq~,=]h\;Ab%~^X=;N`hZ="Cq |t#퉨`o8V#V8sW mU v\2YY1qd4WŅ9+A@ow7W㺭{q!\0k.TW~mڱ^[{Evt6<7}vTXsrZ>[0G 2۟V[㉉CzHƤ-WcѶx]B'jjnZ 9xg!1k \M"ֺz8nukVSc(x8_!l~]8cy1skʉ98Wg\Sr># ?+1?e˖eApyN%&ukU=Z1ԭ!M`KL] ֝OWe:^-bSQ721U•31mz!`%+'+'OX%zNIw9抆߼VUE&ZBGF!E5*ڊbHxѼz#Ϻ)ByGf'vo?,ټ >^xe;_ĉs)Nd0%So6sw kބ,LCת7ԍ q$Dk *9rr% E=hGh7|:4^}B14CINs sWmûbTW+&Ӆv4.}^~ NL~&{Lo?p⪄Ô/ Յ+io!1[6)4VwbrP9LH>/|6b0խ9y+6PsfA `0 A D؄U e/+ Yl_EZxX֢+C)!iĎsC]n8+q&JBb+HZDri[MjרSW8i]8atzC<0&A։ uNIV_q @ǖֺ!E)9䤸[&HBX7#<w7[uS풍ܶ7aPZ"̃0nDU'AC< AhpBu,_;4_[vhGZ֦I=ԉBƵ Q=:a']o~/Z[S5%6o\*ա l5o(n@'Ccah o,܂3C}9P[0x~+g@-q^$ b_4Ŗ%tq@޳r_֩)Y!ֈ ɩV>'BdE.nM@DjDlǯ|{i{=nr;&B=n10| y?P." 1wJY֢2$zfA H$3E7>]x@_23e*\7})- SW!+/a` в79@],ae&%<_j\)Siwd;ueH=='4 i: Ѻj3cMbdlE^q_{Egzazk=?v@IDAT3\d;lK_n0$aIi\ ޙbX$}[= U+zbwEUU_^Ӫ%D{0kRoݍHDX CiO >=~ַﺫd0a>|P(=tsq:& L$<$/@{ɖ$N(ARK2.D-I2>gѫC34Om1Y۵43}PXJA~b1WY %{˾npTV0QcႼ'Go Ooj bX :b.ɾЦ,dk-`"L&FJ_7\4ۇ`S>xdOI.wX]#G `0 A p!/sܾB/ŋxyUvuX& "P$VAERR$ l-W>J$)I<Œؽ$4 Έ#m(E:_l_ۊL G@n=zp^$PWVd"[D z4_/B.'к(2H"7ZA]k^BB%NT!\Zy::I.9C+hpi?!)'Gk,f_>9Z@tNbPi\tyj& ?ILwToV.ĬrYqe\ d.4՘$I/>":eح-թ0w:WeWIpZӾ#; O!? Vys1g:@OaScs6an wVsd| ̃LHz{&yh,օl`E^% ;}d_2q숋|eގ )i~9Q/A `0 U({ u%E"'ы5EB@xT kN0G-zw bŕO\o%b?&Sf jW2^'w[<1% ja$ҪE ͘7|K<ַ)"d8|b>{ jm{Ƙ}@ۊ8y7"L:=`USL9d(O_[׈(Ւ?v9۱{T !3sa59qm-p/iv؏-''U:/r䀎Q,fqH:5OmDt2L}eEIahìݍI9%:ѷMc<ww_i#diTZIPp!r",EP!|1O;Oc#cett[Ӯ1XuXةxcRD|5c=?^m.²mV}}y>N1qiE=RY@Jq`0 A `0m_\]}rs >m,KbV& pmss AlZ*yVuvYΞG"O-222l2̜9֮{TYhꠁ˲fbP΅YA/Vg j>bX8Pu,lE$ti 1ND <==yNbk3;Ԙ5R$9|j'fߋy+'6[SզlLD0Ns˳*mvHt~zXU3\ ТN ~\I㮛Řn۰1mH T V'HKX0T wK&Zfk*‰ 6~\e[Ixi@tmLP`9 `I;VH!C=3"6bW(0MExß7aw:#&uk!X \nj8NPܲ3_N{^\UʋS$hXMNSn 7`^<}Uɩc=Ee=Ę_n\@%w}HkQ(VoM.S2# g@̖ZErR(9ɹiP:rU(祥ױE}j$}G?oҭ#S'߬N>V6Ƽu1M=2Sw| A `0@*&8(J \Dk>qVzQI~j9g 0e\|Dia>|04 ,nuncHKKᅬ 駟FHHߏ~< ,RX`\ePq"?ls/ςo A?s;5;|d zeWʐKITI3]d$|X W:,sv2Va^=k ^{veAHr*,$HCgחɾ.gJBtZ[aX!|:0P\gzu~;_.-8p&ˁt')oXQj0H۴j#U#{]V_E .0q7uԀ̗A `0 A pUl\])4zXrqիW+111jߤI'D˖-QZ5E>}NR!eܢh).Ћ3~-o_+|.Hf{ev9O!oсe| )8?DzIà՗ęs\_-+9!vHZQ$ł>-%Eh=~rՔS^WSX"֫dJ畕yZ//aoqQyEi:/=ʰ.rX|kUo Qh^*B] ?܁WܲuTAU& A `0  pLuL3سg?I̙3񁛸 { {95 <;={6&N9DDdY85dtgh$mXA{k I6@F3;d\g"xXC9afL!ܫP>lTs:beK2KSec-8)#O2L6TwT=˭8prc)n2/3h4RڝCޫct5겳26tj.HZײW+Ӳj0 A `0*:| .dsz dݻsNL<ǎCRR:ЀV^^^F>}pdgeYDqk{5b__)8)-x-.s!WQe2dI@8˙p6ueub=9w1==r=e; '8YbZ^U}QgMד$u|gܡKy-chy8qtŴW롌./Qi]P#hU._KK"g^/KҧkZW݆v)2j0 A `0-k0%_ o\+^3Mˠvڡ{HOOվa TntOvws徦_kF ?ćl2 jRˑ$,RͰ\6GkPh%iO|1+3|yJӌH2†㣌R8HKKq=ռ>g\I}`qqċuiYے-.wth1JKu6N{v.c(J2ZN_Ukex}b\ŷ̉M]W׳/{=/e& A `0 ]nkٳ'Odp?8r䈊(\n"x 0mJ?"1iH eQ:UU6E׏&쵘ǠˋHbX)]3>o& ёrI-c~J1n?viYB"8_,@]TYiYOSSg-DQޮqTa;+w$0m0MKTbhyKȳCLH1%NZ&᭙ ps6h\%*OyJzXߒ}ms= C5Оѷp[N=J[Ѯ CcbҀ-ƴfnضNӽ=a]A˘s"|E!*EҦ)}>:PoZ?e,Y=2=I@OgT@͕>r ӗVW}|s=AױuJ_^#c0 A `0o:޾:xe㦵? 1-2'** /2/_ (7ߐ<#⏇oW|r}gЪU+p╼s!E`D&4ipe8!{40}FhHΕK-ۆwヿORt/[sUbĭ,ݪPng\=]+IKZKкt.݊ bЬnt-NKտ&1C<(K'fZZ.߲W._^^u[edrog^fA `0  +pf!q0&#})|m%\hsAKK@z+rrr ?ZcJUHۭrzTj'xOƄ2:ѕ,*ȫfؔ xzXZ? ":* nJ*į'EK p:1ǒ3pZZOٹ8y6QGQ9*>pwS ~bбecey܃}w[CtD(-W ItK{ĝ[,iqx9Wz'=HNMWx֏UU}◝?o/$OGXU#ÂbHCTXSr< с'n;TG!K]\NPT1qn~MO{bOh1 ,AњX{ɺ8tC|dHCCd[mJs֩ӮBR~%$D9mrba ;ii^u_e3?z.yy?߿OߟJr`uI/tO3XeSѼqSzIZϲ1\Ye/ ?_?E$r2$|T!h}-ť i{F(FCYĚ/44TBrb0㦾s]hv&eKt0c8jTAc_닶Z7ZƄPn-OVJKbBy<

,x E7?ᶁ]Q[\3a{bEfx{aBb_NMcx(~RU7ᬐ}>a~^8R悗'Ef ~ >T2D*3"˜9"yr˲* ñTO{_k \ݎ4L՚O3\.fyz'dϜ Υ;FbxvbDHCպ=^/~$΋3w Z,<>#32]Q7-G ]m;Yڢz᪷AESn!`)+e G } {ܔ[1 >"`f~a;OW%:AV N"ӕp22cwcg]<<-NeМU['$ ,X.$Ct$9u蠾+}T]n7/?M6aΜ9Zo;ʒ+uKܜDzŘݸX~;F=zuhA,Sͺ33uԉޝ0CC|a?nA{\ Plߟ ~+gq^\_&Rt-xTep +6?}&s",]~܆}U,ڪzcmZOᗐ?"_Pr6A]!˞~sE{$9]k({}&Gƨ}Mx#~-x[I UNőo#}'D V=3UR}Z!tjw{S Ϭ܃[tA 2R3s)V9/>> V֘?nw9թ5㑏qKN#(-a-^]݇o|ACNl154E.mU_J M:e̯Xa;=8 K*KfxKŻb#c<㫏/z>@ `0 A ` Xz!K .HƪX9JE"T=iʯuC d6A@=HE2N˛BO5nƯ*0e|6%*JrmŚ >]+G MN:iӦFݺu/ɓ~[[1_U{hyr k,$f!'/O rnʥ_IkT G̡`~%!Sd&;gC/WE@q.! u~P=H\[5O iRZk~* øά _lKnrāMPS5#n|qc}d-Ѧzrzi|(v=jŨI[٪2Kc;V:O-.{cjL,+V؅gV+˙VY;5X]G /X 5I<1=#01IK;jdSEa?c`vJCұ~H]T-C-";xuOWTqV~y8rӰKDErN@?_ą;5b0 A `0@K!I".J1$%3kɗŮ"5r+ʾ[d\ ntߵFk^v+ fBdpޢXi%5whg`Z4:Vn?>z۾}X"(ˠW+M-(!2$I.:.mb8?uj?gݷ* 2HƤ5/|"{=P]seڃVjٜ8u\2iOq-DPn謧ΩO/::P$TX2{:zVk\ycE~SEh>+.#]GF:Њ0U/_R@)R+U$$ǹlOP"!DEGT2;aIVr/ IrK]$8De,ҞnK2wXP@bƐ%woy@0!VNr *yw<<{G4JSvSNch;XjD?b|o,TR젞pM嶾Q x|fz^}NB=n10| y?CՁFvw\@`_!6ܑ3JhZruRO\,kFė1> 6ѿY.r%1*^LӚ%*Pʤ9gϦ.crKaݑ../܌uRVG׷+i;īOȖWiXy:i>e!93W~eXX2}r]LN(GG>hGa@fA'ނW].L 䠈9v t.DWTS݂\TWӗ&tCߧf`ò+}N'U?SC[qc ,}s"Z5l|S.O}wyMVnΦ~I)N CrBm+qe ɷDːd<`W~S<3gE6W1I57xrd2,څzU^J|5<^N!f3~0uwAm{:4 cўިz_6\vYVD#'9$1C/٪Q69]eY(dcu1}[xmD [k i)FjSr +>d\;&2So t.S*f.XJ,'/{~HLIR~b䡞3՘.aA `0 fΌ oJ${>>X82UlE,n( %$Rd./YKV½X ɗ"@H#ٓS#!{Y u5 wHTj^xz!!pgܳ:D{UoVME jF![1!^"d+$]X[EMaz5$ )]$FNOvSrn<<+׮Z1Uyjo@, 9r9oŊ0 IYZ5@{e܏E)rU7: O$.-jPU=^ڥ9dV2iyU9 A `0nP*T42 A06\ >n\9cf?ѾUsPydte^rayՁdN3ΠZWZ@{]*5tzi:۾nyqUe8L7K*Orxzto9XBk|q{}gǤ]\f[ >w^ǏIw󏮷teqoB{=ɕ/ ѵxv K~O^ sܯ1e^y춋*_iXWahNB抻` IU}Wўu9ĒZҝ _-ߊi7gT# `0 A ` A?@@/hgu7Z9Γ~uĆ=1.`“% &CWuЄ:E&4ڐuUڵ%HQcɷL>#@DwSڠNem-Va D_l}-Dnfz^2yZpbt_<8%~4dW:ycMD>-& >8Iib̙ &GMxtߊ$sQ&NãŸ|~| I@ Ъ_QpXj<8&o~3m氚fc9_،¼Ѽ||4&FlcX66\y`e%_?)~$ɢ_J2VZ]l*,Gu%ySX7l+}(naѾ+;ǢU$y9uS=rYS?۔͒eV>JJ%P9_ԑkDuzm&rXejm6R*+*BM<e6$_\*`ֱ /9'n__.nܑ֮':e+ݗmp<:,+'źrwq9Qb+4,K3WA `0 ABXی"!!h&8tUu(M0r]WM|\K~-o/W˔NyM uJ@Q>kQ^KJ`iy-[fZ;.}Zi{ Wm[IX2]nR~]I32}-+_`S^kɖ֭do0qA `0 A@ F4Qq4Ieh+K_S:v?o ꘭W,jjyL+HdʪoףjQ_l$]+m't={[<WOtYyi=Wv-jZ..s-=vYt=]26g_Đ!s5 A `0Xƺf=ɗƀ+0'lK`BèbŽ$ nESAdyʙ\lej++^Vt_nj't/]{ZFU}vbmkWgg.J_V2]מ2,W{n +ueק>^%h.۰oRҺjt<jSbkyu)gA `0 A p `^ ׁ"gDĉU}U.#l()!iN9Gf봖͓x3sH~Jx`IZF:CN2o׫h93e=2H8}.Ijd c48n^%rd'xrVy>̳u|y唥 YjAgXIӮ+ONK$Tz'6諮|=&- `0 A `~,+srZRr<+MZS4Yb~6g j .jŲd/[~+Kisi<'s!IHvGյ_HVO!]D95g"!)BbzrC˾aδC,g`(A'/Oe> iݦ>rɣnr{ RR-y/2\UT_.]_,ߒ8}5$m$N_3Bu}eGk1諎3?J3WA `0 AC\gxTO%+$SN,Ş^Ō*V".KH2uݡ:4t8LB_^r2.Y(˗_KS^> WT>d +xTT+G)\%L1!1YzeZfͤ4$eJ.%߇фLEy?˘.=> g _|J(jxH^ǑP9M_tGxHsJ4*ʗ.'9UlcCZ/cµc >{N'P)iGnuNZ^y%/u$Fe{|~Ԩlum"E2n֡uA `0 A `*ȥ,dS, % |EppTrG*E1;07WI +m2ԂJlqu`J׹Z>TbJ:net]UL*ժv/8}s$ MKucaRƉ匳P Yyģ$N}^)qᢱtlSζIz~&yZ畺NO!%&UP3y$ (%2sC2j'r$qUnr>~#磼{tb ;|d^ D+gcXU592Zm\TD:5鞃G'cŢA `0 A `J$I*cyתz,`i"%RDX\?>zp-t;$.H],ݬ&z$ 󬅎XD9Z\w :D# I$hm+ qZ%u1?O+資\i>Sϗvd? 9W&CW"lfXH%``5cǡě-z{< uiݼlb=׋zg'>LkƝX30_*d |?]( TL|q:".^(·b7ap8~k&.ذ l|pGO kTOplXKƋSkv/iəmhZz"]NhL˶ |ɳGRlhoy]sS%$\"Ng;t*ȳjwF>y/f=3 U֧=x}=&W?ߊX!Cn݋).G*^1~Uy^є,AoGjUJNBc򃇻+|U0h`d^iqh!oG=V>w;Z6/cxS>-HȸOc>AVģ_.І1xΑG;_#[^H1+@ܟg' Ff<=9.=0;|o<|#WX2w ?8Ѳ"Uz>,t]cy>AByyY7i~0?L?>ItZ-z*a䰸Xú{qqzn*+9@X| Nc{cxokW7R+ aAEPb7N΋ajAf%ˢ;X坕OT:50]K=V5Bʑ:p. 8!:Ѫ~揣yү #Kˇo" Mʲ!tOp?cUBD$ TY>5$6El ai D7" vJH_0 q-Q[j}EdT# _^H]Q܀ >"SrEցGn"H 'P)2~b!$ CT?Ӳ|SX- cZTn5#Pɇ}!B].ۇ}ۈSR~~YJ{! m$fRwФ_ x;v SN.\___u]P+Iv<+qmPsmT"-ۥ nكN̻*뮾@ώ-1zpw|&ѥue[>NYХاM\FdƑ$-֥*k9df"^,~ڰk17|[:c)[ێR=~/_'lwm{X%'pO801+hRNg?'򇓧'U$eܴ>ѡ%Vn܎ޝ^ƿG#%-]6W -y!xMǞɣPG,܇6DӺ50G;,YVsV}@?ȾԈ& 5&ޢd.>gB"n8!rѥu 7DozbX/6ui@3>xو3F7|bl8U^P[Hֿ}ifghݴ8ZSC pwR*oDnrmܠ6_&"ec7|8:0/ÆCgpKXDȞ]HQ!%V/kŊ圐Ckl\[CZ;ncȼ4{ ( F!NYIZ8u.o_4LL,.Fd^y eeIBLnJ&yXE FӢiZiHrǗ2}( ge+DZQ=&xcxg! eJ !>4B-)k`]jZaOhaj/}hK7TX.~!~ +EkY9c.i^u)1'YYY2e aܸq*T *U鮬XCDEoO\e붢e:h,ts^\>%8SG,$"NEﻧۤ ̐ХA@@[)_IՐ?r~6!E\=0O'7vS`, wJ/DcܐnzW/ܸa{yxdwKfnȆ֮#B-' o`aTPb[{6VjZvc@ b9ފ=v,$fAxϷ x|"h_#N )7D,8K !g.b8%$gIF팯FEc'nbDѤrH_Ky9}qxVe:Ҍ:~1|*$뀧=ڤܶ !l|w EztFݘ_eZ։}RPI--{y+Z bチ=: =O?@6د[G4zuU`)b-ըN- Ri^8Y{BJ*ݤB6xBx/ԗ0@K ԭ,!PkA?غ_=n-&>ԫe6lCnIU^SFTs5\2{%y5)Dz|wR@|g(wE6㋕;-F(Ğ::A.(SA!+:>B;$CУZ(Rj)#.bN2m_(<_In3xt8IO|iw8q-}-OW. l;"4X}=.bY,VPU~烯PKܩ]{XU=@PB* bW,v׶޻*vAAwwBPR!}\"访mwF߻N9sMsF; M25)61Q;I;/Pd=b" G9\Q%${cs7ᵯlxf.߂= ӟ?w~L?s|=n~p?q… c%w'IS>ĘÜ1/݃}$Js'ˊCBR$Bb\'*-D."3sb_{/VKۡwˆRnCGcFDljЭCh?sP*4o mȿUS}p)ڐd|v% _^vC/!CIES&Ȧr 4.ya,{/qo[0`+7 5$f,ƚ %-W1~{p,]5vx\c~m\NR'^ŶԿ*ىt:$^}7YOrp%A.jkƿv&_g|?aX{͂Z$sߣ5)<ʘU.xeqkմ!,=w4q1y `M\8'yxi$вI}p(h= 2^%W˱i3רu*u%MI,Ym\>mb/qywXSO죃e0yOq-*XU(wC:ŌMz dyHۜWz%n|Ԭl!݉ݏnצ,g#'q0ܳ۟;:C!p8ߊ/\hE`Z޻7mm;BgHNrZMGxerŰvWԂxwMIRL$g6n݁G_m>n,vr\w<}s-}"K" h.XM \qHZDSCZ߉(X6M?Qos12'*lCac1}BB+NK$}cI1lc*OE'IDњ$ DZ+ +ί+Дpӎu+ ۥXq!+X2%11_|C# Y:$JMsB.48c0L߾c4ts+JiaerOG(>p'E:&fܖU& UGspxoc~}K?Ҙ2oe)[0{JSo 'L`.%ϓm.Ia Ԯw^ΏJiiLpB[T\_G{ᴎVt$#pn)ЮiZ,Yt;;BAL̴Kw_3Uw?[.lփhۨ&_T0Dekl~LB<~ hjlO b^CeĄlھ` TIǝ0Ы6lA^˒,Z\1[↖hUl ,9!p8C!p6~k)nA+Ƌӂa[O3*?[Mmo,^r̂1]bI#j\q{iJKKCzz: TlT߫׸9ꕍ”.[$f4Vڇj$ښ\. h'XZH6댬^XKuzFB9+`&č)n]8OjW- 'z:Fǎ )ć?1$E?= xc,|pkZ:s-pk0?ᶞqc4Gob>a,z|Z>ob ەuXO}p3_a}Z/_/jZo ^..+A{ec.J7^e0==I !p8C!p&~ Z$ą6KkT " ~.Dx M]lgcU,G Cƺl]|UfD66 ,F"{у$(v{Ep N> zѩ0fH[i-w~$ժn\[7 /}pUکS."Ҳ`*pe;߉匙'->Ʌ=6QYbC)YhGnGn&^|/y v < NN*]$ٱ5:l-+GVV6 .Ûh%θ ;_dpU]MTdMy.j=1Myw^޸d+#B 9]Nf 6y'hs MaȬUhߪH.r~0v_;ƐrW[]QVDHf7.!HyIvEQ nZL~Br+.9Ά%Y?oN~oHwI$ɁƊmʍ>=iC_+?slީU# ?>ɘ 1Qf _lF %qol BrX20dB2&%ODr bХAKdOx^B«bynBtQ6XUH~"-gc9&[W]ylPk[ʭQ܋'Ҫ䮹h1iRf66A[|JnˌZc LF,v AKrܑx FRsnc)?2jSwf@K,朸b6c_7XlgokJ<|e'CʋM4NECnPԒqjcs:5+Yx %Rwxx_8qNG; ^8O|=7T3mKcA%wp8C!p8~@]ޢC5H^;4tdc1-Kk/pʚk->xpquq)7)Ge$oakz8#P2/_%G# n~tG#D{BAv3QxPA r;w43-ұ]ckqY,QIo:+_:{h`~hba T!c7XZ_*$-&};N[VB][G+< gⳬr ruY?ËMGwY1;C"6ըƎ I*\xM=*1vf;l_) ep`RmQ4ꔍz8]1cOBow6kq2c|qwq$jF#&+Vî#iٯI[5ZljNp A3~eIѨ Ǎ[*57MX#&xrxws<ܩxҼټwQȝ6V~{X'6Kc`l δάɾRCj@<$ЊpS YLi$ݷm>CT>*D-;e:uɴ۬&r[+[W%=ٓhײYУlɟN{? p.l=ӴߦIM1e!tMv45;_#ӶW&IyWw<{]T$OpC-TrWq;8J~$[+4+Za*/C!p8C!OB @eH@YJ0OK;FH;cqNa8#is kQK«9Q'+<e΍;'&%KyFclJ$!M%SlQB;\6-MʗƢ$=iIʋn&,v$RY ,ZX2(W$KdI24Ns$aGwmV}T_rH+G8DJ?)=^ļDs՗>ǩt8N )G$e$f-ݴ6jkFڰbPދP{I$ #I 9pe)$ ͓+ps~zhZc5?'~-ydJYߟ&KړWXױLYPw Q؋B&=ȳmϬgr +Gյd|_]j^Q9^M;ھuUrfVEekC!p8C!@W @'"n*\b\92giH Y)1,ۥH""#]:IUȚL͍U+vN &DȐJ"$sZDD'Y'O,G}IzU{ձCIddܱXmE)Ɲ>-QD՗0 0y6Invڈv뤊W.ol&ݤƟzЏo%$,T}j*Fι=)tgԥpv**IT[+W"q%'a*ZD yitp ~zL'Td,GF`qF<޹'vnj&`pTlm[HƝޙs~љ?_;z=C!p8C߃M~= ' J?g;5F6cMf+r;ŗ!x2,E9Z,[Jj <}Yb}K(eR3\Y_hY$kgd85ǰ[ E InX{˗ D3u.E=}~W Y9GkŋsbdWG^r&؟#Y=(/ w o vj:*cW*ZP.*G9ԏʭ.ZG>YpYp?q>͍Jk1c4DkYpËLn^1k@@-zC@Ioo3f57.ذ# B;Fзs-ba%I]Ѷ^cXmlLx$h'okZMd\ֹ1IXfWdd@lEĘ@Je/3al:sojרF[Ӗj%'"CKJH©@݊ep|vrvSWL`z2}=99F墑v0fH['G.=9"uϑ@Ê ָV¡#فŮăI8ffwZ]!!p@1s;4BX3jGnY[zX`;.l_ $=SCzjv_{p@RY`hk]0qצ ?Yn9rاs |9 c5Osѵ?bqGPXںQ@,|J2XO ßw^1ID m^>h. eU(뷠 _֮͐ мШv;~|x31cHu<#[}xO01~zQNXjTlT<1D(neMhmt* &Ӟ9ļ@3Y7L,|j (0ߟnG"XyP>neף-wp|9~]= ,@wtχ{> |L~n~pNp~(j$aIDgC2x_Yl y ,y I#޼]ڵ$t=~c­/~/ґȥ⏟@릍Bx<} j'F!Vr;e{Ff;u&n~S y~TXѥ}~\طy/7g\_խ.+>1齇[ S\R!%R%K▥+wpixO7zd{MϕH>2͈n 4b{8o?TSO/j6I^NNk5r.晛PlضoN6ӯPA^L\ܕ)x^d|>zir+/%}{]tnuEZB46_J%]:-*W)Th?[0T:ܙC!p8C!#Ph5++[5@i2t񍍊<;?]-v`Бh߼!jTDbj7z |uFʨ~W)3е]+OǐS;^[oDVV>n jV!#3 mEzqH:-Y6#K$5ؘhLbј4\(ڸW^1$Müh֫vO{ez5qYhwmtRU O:b$7_Gc2ulܲ)֨ekc1kݤ7ObXMDU0^7}G:ز1f$3?#vޱ J2_nI\ڭ#hIWVT3.E6iP;6=ѥmK!wbT&Ȓƥτ+O'=,A @, ¥D{bu<ǒ8g_Pơ_S٩9-r h~Y(Tڔm:'L i+t2{ ֭ۊRR!|O Xa!bB$1uz|a͟-ܵk_*8Iq$#n{YHٶ1]:Ҍ;_#ŁCF{#"<,O t5~Q%8/,s=NԓnɨJWCG0b,4DtdG8ݴ[wL|:+7lXK#=3 Rטq&%ƙ~ oIsa%6ndb%x1?-z/[ɰ x@لX#(_^ڔD6k]8{)jWM6Y )(IL˰\%sfL]'d/\LBPjq;C!p8BS_Ǣ3CnOQujra݇ {8H*"]XS޼ 5*;Ek4"hװFe.Qi͗k,6*&%Npn) ][717?FpZFW!.vUfƌ7q4lݾ#&6ݳڑĒ\M?L-;6kZ$(Z{7>~I?#\>F-pIu#.iҶI}丵!{H;A:%Bd"_23z\߷'FMa-jTO c 󵷯'rkJ='ǖW 3KlD{ߢwT)/, g>4:W$ 'Zl0SmTuɻ/~&]w/!b?f.yq8cpo`6]Ios'V |=Ɛ{O?SAjjNԺECϠ L[C!p8C߃Y]E2ðG+BǮz $A pAx| H.%RlRJ(){Sp}pefa|z~$[DVy%5ķD0o̗֭:z}4Sw8A|ѢE0m4o$Y 53~?jU6 ojrع!VKLoe9DuGkrf,XoN;s/$Ϲ׹!,|Y4×G`) DNr9?ZeW6IWqKmNT5ދzSyIFfpE5[rN&pȠ[rc)i,"45' MGU1녑^֥dKz3KۯAis]0t`_3d070ͤJ̓zO%2&1g0Cai='JQ+Vl%6l-7] w@9=8[xL~W֯GEZU͜u_C!p8C? @sI(.zoYH6oTXphZEO/\05$ voþ5(7x!KѣK{dҢˑcGGЩu  l!`L-j %(%wa{Xl"7\W95.lkct}uL/ukqfrf:͚@\ܕ[v`yFFMlu,dJR1"$g< 3!.+Z@*|7`.w5'!LJiqOa5u\H=aͦmƍVXk:]vuKق$JcYɞ1i,n"BK0̜994醥k7߽%WY|MM.n.k\+pӖm t=t[%k'Oi̙Wp, ^qd6Q.+E&q'єmKy|Z勓2]iX-3qNe4j<,ۑ /DU{0|ӵ^МL]J)?xnw5R }Dj3$ҽLQm؃&C=Έ1+頱" dÕ5.;i-IIHEkcah+Pڈ5=pM hMw!-㝯`7pەRjWT` ahaEGZ$sS  W؅!,/^Ih;6ę8ăV;713lJĦq ZK8]r8C!p8nJJ ՐQ5.09Lx\\rAZ.~-TݩzuE-d-\ fp(ER=zhz4*<xz<-y;SA& 7inbQc' je7G#)}]3)~ @/DVJx:Te)\t+^$g#Q9O|9t͓,cxn{cզ$n*R3꿍.Zgo۽z%3J Z|I7Y3Rpg C!p8C!o@15HBW6#TQe˓b2f~v(n_!Թ=EIZXDa($Ǜ|T.NR0).1VP}]zWIv%3U:*IƐ"EY\^WFyỌf (seū']pL&QY^99tx7n~UEZU2K21qrw_ 6s|Rv#i" Y"IG7Qfqժ&qpzX Y@J L_/42ܥfrjhH!@HQFM D*7eP4v$#(ەV'ViIKLngCTB_\FHy;s3>wyW^G߇Fjxw 4[!E-(TONF-0ljy-oltr]7v:lh'pScB lE[yPMh颤|Yu˗woãC~ע x~Oy-5F %F6lS_k-CpWHgSE[$1ITR6C9 7UJ$|N%?m=O|q8XWѬJZ oiVߴx]KjҚ\$AV}ۦaWߐq~wwwkl+7l;"8~rF{ٴE ;?1m] wwۯc=7Z!p8C!O"{֭dxQtgҹ,pV .B8TPzSrq )Q,.䮦sU~ Վr-)'ѺlIb5S$Ҋ-V8Z87+*.^UHF2O(R|("##=Qm&b$uScUƨ<"Y$p<OrS]OA_+W8 oH/<+Wn!NyjSz{v9!K7kٓhײOtK{dmem=jŎ+vRMH)vfȃXCji5)۠r$Ń g%ڽk_*cY?gXuKr7*&N܈+rWH;̸qfޑɵ7;D6aM6Det|9&*W\n!Ս {p{MUS+V?NLnTڸ Ga,";'BvdZy.G22M,=hr=]sr ˭5YEJ&+[ssYV ܜFL[|ԤH=~n߳hU*_+ŝ6,ZVB{ee[桟eK{5-ו%=IyR߇͓WxjH%Ol~]KMm+J9WwKߢuE bca}qwL;ɶDUenMWۿ=\َVYWSa_mqKG;.[&̬\[ϖ<{:ֳu_s)OA}^s5>})繊 ګ& ^Q兲L3gNA xFPF:W /ӵW}r7 {~n~ s7?n~ s7?>燢j[O{^xj\8<0Bp<y#pO^ Ngŧhc+ŞVo؂9WL+^,PF%tl1_zg/# ҂OuU%Sb婪 NUGEE۶0Xnm)X^ke4 J}8u4ހYK֠Ovм^C1#g>8X~ 7<9mwg@tdjTre⥒} ԒkB<[3PiOwx-[R V,g0z!&V2>vȝZWEgOܣqIX~,Xnm~m%S\TQ}ƻqN|G1U5ܿs#6z1-6^>u%B'K1*b;{d%tsGh*?)$�G9G82"ivrBld:~Kߐ3ea1eqkItmL ƨs Og y֥tsk+C!p8C!m8Z9 AA;1XRƒ&,EadȩS ~+YЮAuXe7N<w`}Sቁ} 5wj|;eq$9 U*olLӖm@S[1/t%0s!oߏ|7i6.=NԙsVGUѫk$FD8u.J() f-ZMf`FMjw(0~b\ؾLxVߌ%k7^]A_eb1fRthR$;$lޏo'E1afM=nc]6۲ӸO1q>Bc7t4L]Pc]O;pz&Bty/oS^dHqFTQnmZN^ֺ.&,l+PxY$T*{wA h%ؽ}sso LbݬKY+Fu IIZS"Xf==u+쀊IΑ,>?؄ˢQa#>&GUekR0掴 TJUE "Ybצn#9HѠj.Ǚ௟atJ绣(v~򗼏xl@oDD&aÖ(AĠQJK3 `<c,{Qz=pπ{3 g=GghWeXH?>%=W\cpxQn]t_~%ѿcE%,,6hX'Q:TL%Gdf ԧ"^*4WÐ0O~:^}i۴~M\|봴Z>eP=,-6ǎ@׿$Z7QW֍yn `~zv :Zjr-mF/m!7Юm"IIqAo4y5||zzF֗ hpӫH`:g5˲u8Vla/սG^u}p]HJ182u+nxq{?[p6 &-ݚK8UZ;68抔ճc 8k .qѴS,D# o/-%O 6˷Lަ)-j2 =QSg/2uhFǶ{۠"x͈>\@k*_$ӽUfI"9rOaסg֦ϊtvkXvϏZo^{,}8Bnk'u5*~jh~z4LFtѽfG:7B+v8]DC,,%EAi fus^Rɛ C?'j%{yb=#/@>p7?3w y}pE? `ZkN,ڵkQbE\fs>*0!!he a$?L1buʣ&7PEn&"yy$aWv.6N5. KS&,Y-"Ybv- 1uV}"r(UPT\i[D+ٽj<$hI[JAeѱ~y죛nǔ=?FKohRg?̵NU:N qsuCIZ>շXM+΍kqj( /Yqz-c e ( @sc(I@YAV+s؄ݪ.tI.m %f${c;! $B&bCеb]um.V!ņTҤZ `oesuz߻&q=Ҏg"km!ѹ_Nt0[73u\5]ԭ)ڋB;{9[6FTB9GQ Hǘ΍pv*vkҸ,^(^n~'\RH僾}De{:/H?ާޥQ db[&Фn,hx nvGGЍymwpc+>p w^p?y}>.˩yvݽWN!<ϲΝ?e !XH$~:_BcXtY٦hH,YG^"l+IbtxuP%dYL,`6۟`̓aG~oF)8g[qϥ G7QR~_X#SZ66mEVՙէ˰7-.J0?vE[heyPdP $L=^}Ke4 S"~=$8ĭ{9`נ]T|p Oyc~֛/dcx=0eQޛ":gx9}.:{W,Fdح}+|؟p=z x%X9۵Yز3ǻd/]$^wWO3$M/rޕ2 ,{Dq!KTHq=g1.ٷ24IZ>}xʑ2p4 Iޘ%F"Wwɏ_Lb+ĥ@C`.ؙ{n2Xr >KD*{:kxYG>f N|C5ǿ-{ɝFk&-dxK^ [e7'[Yǣm۶>}g„ ҥ &OLW`O||!B))4\j=#vGB<{Lߘ~MR$l+DxH-((b&~F#'րBxv{';i+C~l»P((qSg'cV}p][5EEx_z2s㊳.mgq'}EfK.W`!<[źxCl!(K!^Qf|c&VKb~fJb-ZݶָY+8 X2y̹KRͬ7 <By{/}AA~%BKFq߯4>[U.d]v͍V{ m =4f-\?dxHmKƬ̽Њ~|v紾(oށ )ҷ{Rxl:/Xgn5vrj.utӟs9}P$݅MYvY5(IL9+{ R/!δgaM~ ݥML$kkY[Wt?T#A?yFd<_hNP<@@^#""pM7nݺXbF#3Jxey*cXdyD|.]ofax˥g8W9&!pˋaMMn 1"g6X-&$KK04h߯}d铓o6AH(Ԓ2v-i~ګU: Mm%qP<)@H1o|-b1#ޕ<;9päF>-݌kbKoFyc=~ʃ4m<7o>W5 b'= CBRش~|Kmw%ڽ/8m38瘹e@B\V!{|AL}< }$zojwC|,5K,]$ "q2ѝi_g\qP\MtL5:̤KP7Qw ISN4_n>d/C=9Kg^2e"7s?\,Ti fH$_Q7ؘD"9K S}a!uݛ!#Tt>/o"("("<[t(E@ _ V9W= SS B3Y!EXXZjΝ;aÆzZY%?[kheUS7--/t!ZEÇЯk[@4@ea|*,Z/u>tmHk _.XB]8bpМKxl1}]H/gWHH7oƹmVoaL\5ͱt{7O' V9K&ǝkάcpr|8{T+Jny{0HԣC Uo8O"{ 0{;Ý!)-i 8#[YKWK6?>G%>W+6wƲ6hޚOޭqX!oi2F<|:oƟ/4d1q=?^v m<7,sWpE9.Y Qbb],4N{3_,FFp6WNkNPE@PE@PGvXE?`ֆ{uǢP\FwnOK\kRDK`Yc`9F!/nb,ѽ?"4$`e,$쨍|Y.X1R010#e$/5tHJѓx֑6K B9岖 ޒV?PG3ُ\DY7-FdX'lHsG%] Kڧeqވ+(ĝ>nͅuΤV3c=\m?p^"1ktsim@/qE Ǯcݜu:y 튏fχ>?>/&}>>' WIP#^X?E<ǰ}1VZ,1 X29N;ȗo"2YE@ư&۟t97O!w˲242ogGKj9꺣mwgk\?ulsS-@]/rdfS՝#Ga`Yuz^GuF6IILi_ڭ:*$Tv֤("("(1$1׹xW2q*hjq=K՜G.$wL>W#/u*_Z ) L,KncCۥQf5=&'y3uכVӧчny3ff12}M^fvH,rS)C7^wUguvVbf'oɫkެnV+̿RЫ-n1.(oK)e>fF9k`Jq4$M)E@PE@PE@_P =(gXÒ _4tq.>Εˏ%9ϱ&+!<;\E%}b˳X^m4eSk5Zc9( b`zwn ɱXuV֙9|?g5N# |~!xٹn:j!ȗMKrT uaVR]ȴeSrd5oӤ("("(A@ Q_ @e46YWOw?w$g’Cql`rٯjbzWae:$l?.3g/we+ϖ}lg gzۏ}m޴Q_>aN)ՐoѶs wא2G?VtAf:8x]ly؏}^6oV羺4("("( }EEKH0M/6A:,qb 7;ƒ0l!ah `[2&preeIwXg1ͳmg&ne}.,̳J"R[8}cǻp;cƲ|ĭfOl;xVVoرV6E_=Y,V_]PPE@PE@PN <)n.RĆX|l +`pw()!1Ң! Sdre4O`ɺ,pHlڶ !BA#K\K֚c5%N=>VCrCBܻ? g&G^N\ވ9tiKG 3ژƼ+딌\Y3T{5qOrs f@IDAT6 syeH_|r@PE@PE@PN*jT*/,qCBD6uc#l>"~Cy"&sa=1kfrXeʒH$]QgXr|`*zkXۏr#o1oN!sٵvZ.2_H]{ӯ-{O , U~|kqBzj ^ճR,^|KUc&f>i5hs!_صΞxMl:ߛ>Ͻi;[֫"("("(!LJV@@ɉjH,$|"cI@w5̔tr)Kq翿g/\{Zչ 8~#kRǴCQQ bcQ7!֐mT|Z`beWW>`ھk:wOÐ>]>Gy88}8(}⌬Ç>eb˵p}e&;E[Hpy `1ʥOn~E!oLD wL䮫CdT ]{L JUUzDrv`!:ZĺpG~Ɲ[ZЃ"+8 >&{n>t+x#oԩPc={oY+gڕo0+Qœdш4yar.^|„:CcC viwĔi vYCemН7>[w?yvaQnP*օL-yEҮaLntl܊j6im9N 2`x阷)[VtmqcNEfG7A|d2wgkwIl8riٱ$ťob0#SbMx|]XC8s3\>!qL-Rbqprv_-ۼ]K-L^ijdq].˳#W8oUp*ddr̕[=^4zꌙE%|ksO5'-B:~9?o~E@PE@PE@PjE@!` ={euOb„ 8q" Ddib!mC϶M GABWv-q郌5ڧϣ¸{{ės3ixuo`p\0w-Yu1CS.0 F9oywkO:B6vvu]9Iڛ_`oޞq׿m{q?Sg?b~>ӹ5Ec@h"X<0dmO;sm;/*\WҸo1ݯ0kkyES>G˥GfH A6Ҷ2e}Ѭ~&^8.\_ h{g~0Z6Brn=/D)9 ,]O\w.>f {tmi1/pkFa}Wpʣoc\tj 3qR tj62פ("("("pPQ?n:$EO\ 3a),I{$hǞ={3Gv;`ʔ)kjXr"JuU1w;]i_xq 6#{0eƷ1! ]7qqm$W^YbA8b@toE߮;-]\'rmԭciFitnC#"kU7t3 /w:g0Z4n sCc!JPOޟ`qqU`bݱ%Ow>CW!o㖛go<}xQ nqѣc+3?.7:t1ظu2\X4cw^0jX6v-BPf4@ -]mg*MPE@PE@PEg#@?[TNHB21Q:Y УGߌO#77漼 qxr S$Q+XM;(ϯ+P@tsx6]hFUJQq1Qx_({/SX#dNVsCF"Dk^X汒yjt \I|^C9۵t0vz'yM aѱRHA_32- *[<7K*Z+ciIh39]KEZ\GKb&bu us>jDfg* 8RqLD&CJc]Ǒ yHQ[.<(BQ!I?]N>Kr}/j$VmZPE@PE@PE@IIc"(5 Fƒ4m۶EÆ 裏bԩxĈ 1yΣ=yEi}:+<ۘWM]["#-ZbCX[AE-NVaCYRIHՏA !ȻN[$Dl)g{z Xyړ_'Ѷف_ir -ܖdھ _,ہ36l[0e V)䙍P̱$@$^0 vXuE\ iI-aN$"em]]Ky/X/>eHqZax|>b#}شNH@Z/LӢX؟O\FӠo"("("(ǍK븇E@0Y Ò.ˑ;M4Dݟ \0wrKx!rn\r^ rnr_DGp").Z4Ǘ9\̗(Oī#.'m%<8W)$ɛ`^ea}k(xq1~&R0e"JHnaI q@L>Uqjtlu =;Dsr ze~pcoa fB;'|Ni6a)i&kq/fI6~D".-0Ճ{uMÃ/KbS#Qڶ zT$cK$ү]`磎`4GGF`hTLr9xV"cg1[ RPWܣd+kIPE@PE@PE!ݢ7TG)'Ad\q@4LM/Z?+4c `%܌t  -!>7{7Ջ}V-km|+6l)Z ak.}H {!L C'!y~!3x9嬿x'خ1o2e1˙С#W$hI3я2y> BԠh(XkME315øFtk]ۅ9)fҢh+AAЯ3'Ԥ("("("9V*~6|:?BnڐyG]c$>Hj)[vc:[Sb_R2#UGꏉru-Kr!H aeX23>d,Za,J0s| םN !ţu72nE`XL v;t&aiO}U.Ѵ:dmvnM;zs~bAqQ vʣc;5 ڹF t.rkAE@PE@PE@P~`A"p4Ha:'ucXmMIL@l}60"1&hKs Tܽr~wD'gVI<U;WKq BK7&^G;Z^I1f2#ԓmL$!%;Y|K2)vQCC{5vcxD<>9V("("(" J <ڨ(?K^9M0l:֓\b {("=EKI@I&7c #l:gƎjC5oPw\1 )2d\vhsaI6#Ϸ)˝؏ufҡ 1XDz#c?GQ~?";|t9 $2y+W"("("(? @%*?|Ý_ղBqp8\1_5+<:Y-qs<ۄbb*5] &_G6ƘO @_v"rdDa<eƐ#%̗UQ/cݘe篕ǡr&e2$>~휓uFW[v$Wݩ0S uc֟]V`&e+;[evG |}>Q|s>A^Aפ2z1WGB>.n _,b2=6nN;{`#%Ѣ.;ǘ/kEęUbbLa?hxf}uct2ۭ\{uҼ"("("('JhwL!`ߜb8?tߒI*1y,|r"$m3 "ظ>NM:t˥ Z2paI {-\2wl%ćj^\ۙ?@qrMٱ;/;,݄Q!Yr#;4i45ut9'0=Ht.(*OO#wGSfٛoԗ@)r_{ ڥã\0{~F;3 8!JJ%s"BCh"("("('J`7LUCiGCmBu,x>PYYe,--%g`L׫(m$OblڵѧmFG2 %ʰDU,gRww*.-ÿ^ 6gEZ$lރ[^exuHNهБr{Xl1fcFر'r?p3@dpnd$zh29,溍B݌_sw&E@PE@PE@PNt<(5 c$K4lvñmwd8cp/[m Ӓ1knCe{!S!59I\` b9vKpTTmو GTեl7y RP/1ΐb_P$db$vkȴ <$ 475ĉ"Ɔ$w_gn3db3Mt4CsD~Iz NMkqXx(DL9!674n͹ w? Jugv7\Ӳ!e\\#n-DV݄83ν]{L];(Dl`mɷjnȻ Ś  uڹM[wH6#d eROP\Nɿj$cXkAPE@PE@P %O*#HpoT t.DJ8r|pn8 MbpP,6)Cz6x`tj/7P%g,,[}qr`!!9* zhس ^Ll&]==ECH&hH`rv-ݿb7l/ܲJDRzEк9ޝ 6m߃]Bb׎K#]&xϱ#w ]T6ċ3`ኵxvzdO-0Is[)*a_ƋʵqC8 W!֕ZgC֘Ǟb[ i>ק"HܞTm\B217o?u*f߁N b]ݡ1w>2}yWi_!n'WjKL}SE@PE@PEF@  %eRZLR9v؁iӦ!$$ ŨQ:ubSXHdqΪ n҇ѪY#o8W'Oo|A}sژ02sz жeS|ǣ>@Y^"\ οbǿ6 N?~m<|shM&Ӿ}{lذ$c.|VsbҸys>}vmO>Z؈OV>$h +t:I6 Bc[sbB<>W}JZӿI] c+E^LTΈrfцI׉~(: g5{Ƽ%t  ԇQ 86* b~~}~ϟyt?~P~P<!t'+ @Ơ!@NU qĴrJs1c a ?g&'9z)ާ#N? -;"}~_\{ihR,ZjHY)x/A:<V.9 \. $(#~:g|Q"<0&*¼IЋks%hI(pH2Ѳo3@Gzj2DHA!@-$ؘl}r`X9"r$ j DRG,**u@9Ų;oѩek)gUFBV!$_pcD~u}Q:"QE@PE@PEBv)*"S GyO={1+7cƾr6_Q&J0N`w)9/Z DY7BQNμ~jRkyt%8(U#9_yF (8=|n.Qbզl߶؅WWn(s`nz,b"u!ɿj\B\ tew6m`9~ć& &o a/cw)W.>BDӭ% (_:b@sl 4\!r`bg\s@"W[s[D pn,5Hb.Eν@khZC%9m oQ벲QTZ?Kp0,$I5u*Z4nhd̈[7 ߺ+O"+Oq G}!՘Z7M@'S\i)7~iߣK35Of\㠴qmhj]?-M1c3tH H-q3qUf_:S]Huo -b°l6{.$ #7Df<'0N};7I1CC&EfNvJ Gs/Etj&Iذ}rP\ڿ=$Jl$n];PfFk@)"("("p"I;s67O#X !^>ݻ-Hh#`-5g ;]vm;c݆cgrbXo\feɣʲWe]*,EXe{=϶dz.L[}uéjc_&X2uLy&1$_N/pNK 6[8m=63HL"&Ϋ{,2ʱ̓d#ǼC :|q,v y~$8^I\3y8r`uzm.(EAI)ZϮю}Lm{.۱ էkeTˬi.;bҒ$F)ϦA|p?y}>A|p?_.DV" pDi %~ږ<"=rYr\DKKFbGH<&r˳uQ:r>8փN;הv-5'ň{mm!hu۫Qqm9j񩡫ax1 L\6?>q[Ǻ+^;vw[#ndIozE@PE@PN|4ȉu" "p!p@77ۘnXy˶}0=-Zoגt߭=~2ͯS4} ymvG׶qL`IVق3%gh8u51- R>drseo@ljm_M/([Cح`1}E@PE@P(JFo( Hx%r-IC\ϒM$\je|nXy+κru?j5t>GԻ.ΰ+$ג#laُ>{: Wwwhnu9Z[wvVu  :2ܼ Nvsګ8-gni4h:*md.fGK6zgu*Mݹg_/+=ɉqa2:^twwլvߏM<;XۗegNc=_f S{,ceh?o,V8_3}~ؽG}>Q|gO~(DL"?xGq-ymwrc_C6ه#9;O>WUzSi3\D,;vˁ3#l;>G_Zfld ԣZeF6c멣_O[qQ xm*/d_MxOӃjdӭ[Ƽi7r.0GԜ(q_7i_!}+,.žIrpqƲǽVֳgut-,]V>Ɓ*V qd]c}p \O̜lz܍KVY3QKpܟ-wڿ>;#e崻urUŒW:V;}xLL唝,SG,h_=e3T 'cf;}la,>,sˍ;(>=C?g;}>j'&E@?:l{`mJD1m^8pFwc&kqw 0l l}57_qcYq(V.6 veYoEBcлSk$EuF*vbHqmQc.*ZSuE?]sjVcGaJ]|Xs D9NCu'"=XFu.BdDTvo0#A;8Ƒ [zR;|>F?O7decHv,+g_jH؞ژ> ªcnl$-gF?j:<`贳fˆ>{&{?5WHp0Iܱ9^: RԖ}ldrYfi{5IN\>z~YGGJI\+]vA;KCÒv{m5 a;ȕGbb$j,W_6])ل.m!~]?PP\"iOd;j @H)F7Vnvq=LB6͐s[qEn>]׋UѠqդ^t_\-utl.nLvm@,.Ym{(z YcUe.sEC҇8?Nk7mEv>m6As5Ȉ5SE%ew[7^eƕ] qō02`Ǯ=\4kF6o3 ~]!n6o݉yqi92ҒEt6볲Xqjuŕ54$Ĭ*Vںi:uhPc1kq.e B$ԍ/Pnފ;r.7tw52:qE˄|r3z5O3Dɏ~f.E1e7eF- q?^$93EV醸"YuÓhV$D)YZh,nz-9TvދV?J-&6r_3Zf vF {qs=ڌޟM#59ɐ?{ Wspb`TC$[bl}д!bF"g?' 埜/\keѕBt_/Ĩ] 6>B EmZm<&Dub˶l)$B8e&Vm£/Rkn-EI,/!"(/QKȤktsJ+񧷾¡)DgF7/Ei߭Ò|$A4|2k5h\B8]ޜK3gEaL#{3?l}SE@PE@P~oz"p#ݦ-['QQQ8~툏7]j'[=@d/߮y}6}j$ke /%l//ۂZH;_0D$eoC2ݛ' yE8K,mFNQh VC{C=:]q*!AEgo?煥[ q-h?1\4bb[ѱu3c~ifȰ"73 b\kzvŸ0/7S.)Sc jY\HoE9C *ntI۲Q.4ޯX/1}p1bA_!z%\ 8 ׮ڄ,!.8c0e]Eڍg?CӾ~%ҳ]$wi=;+$mJX0Ə&8w87qŨ\!2Dg_:jX!Gw " YFۘ%8chcI: ~}d ̼"to] ً[(wKWm@+K+Dk#V\gqSr#- #Ɵ.< )j* [$!ᢸU]8ҕqɨa8g'{!BfiO;Oh6c'~[K98ܾlԩ架2 g<H;׾BX?tZ}t^/Y|.KdLD{ljU^q/㬡łrڧ$ٻ#?=^veCBlWTgތbyyC=ЫpuƸƋe?a0bi٢Q ق? HKQ. xVMPE@PE@!@׫eXyjDŧ rG<6) 6>>?ľs|{[n񷳏$;~&V=D_f3F40OXթSǛZ|޳y[3㻵o=QuOi]0KPzE>w ?3{eoݎ=aޱ/MGKgwkpߠH޹+6zݏ䟩kݴgk2j+SgK{HI2bo7OָԎ=#W:^ya`VVY1f03]!o/K/zo;/6n!^&$vKEYKcbɲ# n9^._0-;N˾`$+cCȩ['[zW^?#6+Vnѥ^wf_.mcdR~D'2,*_gɎܧi{j+3mZU@IDATg Y{`qNq'$~Mѷ[{#_Νvj&jM^Nݛ7@yei֯]&wz70@V~%=4"6 ˼QtC7t#o-VxByBwyy zGOLMUV71>Ks<;vxJ۪Wگ'Ĺd4uG\uѤM=:^b }>Q3kH3W'w;o{ymwpc+>'>_zdl;o샜wp׹ ĝ?|!jsf7&!u֬Y`2ea+jHj0##[Hb L|q孛ˡČ1 E7ί8 o_ 9JH3W T.]\N\0f˹^6vDs3"+D[Deb ]8g q@X+0m"1l‹Qf"CbSf2X ٴ_28!edƽc>䠌uvǦa]pYC$n 7 !$g&NH`l)"İZܝ-Ӎ' ]^:fy>0YKԍ.fRy>#F.}&]%)4ڮ,q!'',րC#- 8?d ͒e-D<{Xe} !BI轃 D{[{kYwm[67齷{MC{{/}Ss̼㝙 $.B؆nqGAPKsA8q\Q\ =/a9 xԔ/e(D3G&F +.l;'\ϴG+Ȏ5_ $sl'[?z0>l8IlG Mp|yEػBJ;Q#y9@7qDÍyh{[:/#8m0q2nzеe[5a _Wkb??r-!A@Wcbĉ7nL(/GeyЅg -Aw4wlgZHKKw1iYblwlFIoY]urF"w#xCՑ\#-YƬvJl-m}?n#yKqm݅ ,w)lO]rBM/ڐ̄4;7GGvgQ7^v۫8&~[6NMˏCܴV T9seZX/)K#ܚ׭'sFda\7% =6#WpgIs{#W8e{,@\ RVK/OȪ3 @8@V;gӗ::1 :TT.bQۙ`Gqc;SgGlA3`+Ʀ1Qc-DLr%EwKJkQ̧& 9ڼNuAm,9CpMEsݗS|gPc,w9 ۛrS:]5=fBJrj}`e<'oxo?$햬KÌ+1yZǔC\ThJM1|jd˭] $_>rHsyeD|>a#7e)s٘)dcg?1&ɛ!zDFDu1mQ e}p83 6-$;D:O &nq$9aJ[vnGhJC5ً!`!`!A"4Se8眿ϫΟv?&mǣO>j"dʰ#KHhE)X$6X.[ b a A#.뷣Wڝ1rg:NwC Wuî8]-j^_c}CCyopIn4hTt~!)?-jWſ&ܡnC vbUo]WAۦ]D7.o<$7w3np/i_ -qtn:Q(IoAƕˆBkݤ׏NuئA[$طHxjz1f ? .e%"^<pO7#KG/Gq+e_69"8;VME>à~qPHחn'wg ƒ>HXqot%v1r6mw5;$J,^٧t9g!j$`,/[+9[M+&܃B'O]_s5ҁ BEkax|:Gv9e5F&wlIFڕ0d~H簕;oC6X3FLxUwܲ?_,Z/7hǥۀ^=ccu@tm~?t_Vd1OOӯ|~sny]\˸y 5Nr %۟>>!VۼЬÜËcn݋v k3T9b&?o~Ly!5a>>C {Co?^oL!йC/~ ;?8W.-rل;$1gVv"l&l׺q] ˆ*ntgUOt[/{#VۂurBDGkБ`)`!_Hxk7mkWdxkU[CR;0Dfrl [ YFU4U4;7VT!ttiݴc; vk\MunrM K"#Q'ϠKyF",3+5[y;ܶݩr.G~6[N^!ɑ~ w"; 9mJZN#ޠQn֕WPe4I6N"MeݸQr"xFCsv-hs9;rҩkkk  :BT9jTut#N LܬJ[ڤ'8҉3 syg*jWF+2vr6$#VmrZ6'g5A,[o=q3B>׈/+Ud {L&eNcIFkbH^|~-7@B2G}!ٞ)kg Ԓh@5%"eecl&2$^زbfAظnMWK.pM;:_:~!(`ܮ|HɤqruY<9Kr e5r#ydo/NhMgǗʭui!`!`xΌu^ `y1 %fgL<Lj8B$5Yt1q}Lxw˳ow}+CG A[?<|[:&vTޞ!`!`m>_g2 @ql(NV丄J8Ϯܮ*dڏFf.E4Mūv`PҾeG9MڣG| hYדBe/o\!Y2d+ze%eyl'm'- aRtIm(QJvR^H'x!'SתnG}]ݘ)z-[mގ<~Z1&ZƟ,c*Wܳ8bNRxkӱR?Ԇ>CZV۔:;RZVe?)Gdzl1g} -kjN-ujVs$cꨬ6>8]ӧegP^+]օKJeV`;?=0 C0 C8_uf/C a ("d@h -(#x A;NH2hrrR(Vbc"D}uuChA۵o-M뼼{,/ϻܮImq=1w VWՎe$b;=kPy>ٮ6ם_[3ed*^V|>dUY?L,kL~;"8eUԞ)ZVg*Ӯ_Lғ4y>TävO`/!`!`#$enw4oOTMR1 k T;B3Z-Zq΂"xP?n: Rv͍#(ɍ7&Sm.h?ıG,gi _lx#=JO<6] yIZke?޵ֆ*f~2ئoǟv}SsGe U_܊ _T'z[ׄd9'O8˄T?se;f]ʇU>t42 A_~[6^] Zܱn C0 C0 sFs O %"xnʦ(]W %d`kLUV i'vKGIؕ2Kar BHvIAR >nWW;IeYAE^3'}xRgF[?>Si>;—T^&mcY۵NeeϕScaO=ꐠ6؇2T4|;nޒՈ, '7tn[yW_ כ7\Jmp΀mytY{;Xxxc5]4՞Od9U~F+/^q.l؆RJezH38;]{!`!`9!qNL0  5)AA=GL_%r V߂nH%#c-/l~FLi V:Q_HrZQ/G:ttL_i(R&{A?;ï&Pf3c<ɲB#T>6 }c @;S~6z*VWyOV%ɿ=7$?]]{!;'g0?ju!oĉ=u.6J u~|&%/K x~x}J{1 C0 C0 sFs #e)Uk pP%AipFa\o-uJD֩S'U#g W }a DjD?Nn\u8q.x7&~t|~}yJPmL=Vuf$yDg?1P1;q~6[vsBxE!`Ov%2r۵W%0.k NL('~<8I>hu*A$ %슗~s^m=6|qxXd!`!`@m`t(?_fF.]n],ȵt"G,-HPs< ',Dߖɨ[DecؤܣeYDTOþixNn%kl'#b X> qDKVoDmtRS1iRWQAI8mݵW"m./|}=3![i$}&2BgeJU*#'OBG-H$%vFMؙK~ #5WRd evב-p䷘l-;jqe$Hń %ob.8%ۣKbaUp$2ò:aTpln}>z&^w(: Pm@yiYvNݳuk綝2"kjJD)%J;f؈wPZ&ȸ4J]Hqbؙ8q27Ӯ}Y<,\N.N9!jH =ٙ(-kAR""ʖŔ9KWS0uJLX7WwCNj &e˔Q!eGH4=;m\Jzk#i~skh9[ $1T?BrbH5}U26 kI ?p2 V& vG$T^>cLѸO0ddǗD_VێCvAjG7\ޗ~W7/ $N$;>}оI\H ~$"T-k6Mse Grar.`&L/^!Fw {0+Gd\##+W#x1H4]U2w1b,gn^>˧1~:D ys }]L]^|MƚW ;UWSd$atz-YcəPNr|Sr-@=c5ЭMc<7b&yS<çKc!B/2?_*tc٘ikU0e:\ڡ)*W%|ًW,cȔ'<' {cpa:soX5W~}c+:|w,\< d L˻0 C0 C0?i!p~!>I1uV4k m۶ݻѦM|'se<L(DGul.]״V,۰ Aco:7jƔ'DM57K_%tl= 9ԺYC\Խ6ل꺨BB+ " Tb;ɋqW)&Q$k/*x˕]eگ\X B5i Ixy _'Qk/~>#zgLt #d/(!7G,;ޙ6w:MD|:q{$%O)(+qEָk{ܛ)[4:r."%oKe&*ܓ^/܍˻w$m[4 Bʿk6ϣc?Em Qy_.*Dt9ѹy=ҧ 8b.O#<\yh [: u"dEa_t%v)%90]UPV"zw=[^!bɼһR?^J= [65aex~/5_pU_:pSuhߪ)"$ﱋopz'N_\]L9q}HNA܊ree0KB?,"'VvbC.MKuܶg^74SVs$xi S?G儜cw)(RK!`!`!pnxn!`Gh[K$-[;vFʹ yQ] $Hp!׬~mLYIHs:KTIujBsbl/ImGfD]޾#XS%V,i^wnIkzal3/lHQr m wvm?rmк %2GyLyBta#G̭qD NM0k*HVر;M"N!OnؑƳd 1#_y+bz݂SV }jC-w!6p.#dPvd4wi-!"oD!^;PI\ ٴ]XOp,#k;m LZ%IL$G矀\>=CoQ%O/۟9=#[WIYёee s:o?n]s?cMZLi"$?y.7CLbqiB2;s窼)H.<s}l[5mc2w=;4 Fݝ" (*NI!I5vkKQ"~w{pO',3yٮ1zk[ɚn(1 LFLOs[py T0 C0 C0F~?L0~DvJ*GYd[JȐVb;^sOQ $@.]=/>()!JT$mxE ~)rMkvNȽ<49CO̒yh Wꃹ+qmnA#/HD4*2HI~QWOwDO9Kngj;鶖FE};S!UH,JtͻܹzGrt$y81EI5"96nv[[匸kȥeѵq-T-[sQ'.c")ğruU/c#Ѥc-%e @K2$8\dNysfgzHmՍ8"CeX-/CĹ+S`!p=Q^31)KnRǪsO`/!`!`!pNxN!`O_JΐcJII ,+BA~[y*xjL\UDy[خAMUHD   J BBQU76LTaW_JzWIAB|d9w-ѻ{GrL.ƥc`?qB>EHi## B0ȯ2X]tif˭2GgsJrjMbelu\~Ҷ**}ZӰoqqrDrq<7Ȗ3𞻭덗Vؑ./+zdt b5N &BrQi,DD0OI_mb"M}Tl1hDrN,MV3AW(t-ŏ_1_203>Xf6Xtз..-$z}dql5 ;@T $F2T'H@x! awVF1w) l٣b\9,noѸًpx-e;qx -&A?t'e('b/!`!`!p93UC0~Hi 蓄SRR֬Yk:oň!SAuԼSnm&^ֈhR+Z˶rBp{0FGDU穈# 珨"qXiDb*ؓeDEv+ӱc'OcRV'6f|/Ǧ},K0v $JKiF[cթ!43k{S5Ň:] =e\4. yxE,uiybwݖ]B q&$PsoK-gXSn!,ۓjܤ^m?.9$tgȩHM$`^rb 6_Nc"!4ĕs $)},vxփgK꒪ c]{QW;ݛ%_Nν}UXQO\p,ܴEqwUTvJ~Vxm 7QMn^M#H_VRrE y{8zMOa{\qɧ96mr[BI}-)b;7coM5G.h 4 :4|`]ד~rjmWXi_}&O&0ej.݄[qK֣J$W/\DgxIĦF5V\!8/fD[݊[WcUd+n%اvl.u."ʹnmIs};`/TNvfGW*/^hDr^(z}8o<}\Q_2;U}[I$-x/qAeZro&6wa!KUT&nCnR0۔wf~ <%MRUʹ}Y^u/>wc(>*dX{NB3p%оE#vH$F֞!`!`!pnnM040|s_o42; F,Fq MC[zm;#h&s O$(*^r\D70۟L,-g֕~1.эdiDޑmbSQId$ϒZv˞r$tTEDQ$H-r;sh\rE1(:99?S*׋IĔkevc wLGr! xC2qJیV%Lyf:OslMmr 7۱' qcf`9QI lٹO˓!ù.05[pfc-{g!`!`p074qeͳ,AL .#O֦DX73.#eaYGZx-C=cu$`8i%H| >iOee,4qvi"\ N{aI큋$g:puF} gA4{c U/'c)nfSև+>m ꟭׿7~xk?=WP_2:fi:?_ޞ-wL{yJJf1v̳)[Zv-[|>g?/4|j>l}~aܾ @ߒ!`_>"+Cx/)@]y-듦Լ֩=(:F߼ &n܃Z6v6zdIMäZع6\޵ա@ R8EjQ}09Yv0|Y p}6?֫T*ڜ$Sirl]اQFj;X? ȫCx;cB}^xŏho!`!`!EgtMI:Z_[^W/m/:!6 e˚7|2:~]' O%rF㸺ICtxカijKJ/)`ҳX/E֗Թ]ǁ,֟k9MpA Nz&ǯ:Oe9> Ki.kjB}N^d_$L},YM}ڧ| /̝>~"@>BA<(ڽg$݇oyD>+>e f[?Ibg7ؿWtH;|Ԗ4kmև?BO|?>Ydu v %CxשEV>e4^63߯)BdW[M6A]m:S-kO=O^8Tq6ڦZoz> /ee)ޮZ׾IY&-^﷥z*/{u\hD NN )7EHlߞdem[2 C0 C0 v W3B@-Zm#1" мz{Km?ϐM󗵎OnxGqvUV䷧D_D۳1_eLWT=n?9S{@4}Ծ?W~}iY2۴]u)OڮuО)緯ek/'c}7}O>t-և?tM}>Zχ%ɳd#Pa˿̌\տ܊Z=(@+Xi} G,XԹ_R</12̼ί %':߇PہceoS0mmyiᾊ6}r5Zȫw&Ֆ_ Rb6Xc= OGT]>Yj=dI%O˔S:yOWJxp;E[d!`!`!` ot ?3\ɓ!¼)D=ƧkEqvT_<;qöcǎ4dOyM__O4EOdzئ?Wٳ"|Q[-Kل`²q%!( [t8=)Ur]凾1UR:~C?Sy7Ngˉ'p1Iuw`8RxԕYϾt>}){}|/y˝ձ8888VlfYэP!Oے!`!`!`gCcm@y>5i˚)+DQ>~IiBaH;pȕ/ VkY kKe9۟ŴyK ;,#NzB7b ޞqb:/uHx6<_}dȮP/-+{@W} :Lk7mǨ鋄k3yעiߞ_$r`li,g_%0. -lђ5uh8{GԲ~wA<ع'&yn 7,,Yҍy/~i?4si >4wgkpM1]2߮}lqemSֱyk7|l}x{k>>}>? @5{]eϥcCB#XVL?Q$!UՊ'Vqu8;%Nܤ6"D-&aEd@a%KWY _sn|IuS!hx֡syGQ#/"Q>2"'QL"<ۙsXBTPsXDZq<^S&1Z?'$ʱRLGSB&#v(+ʺ~؞%8pN+Q?SP?V`*K(ekF=\1F0)%a2l@IDAT7}E2`\_ SV^NDjVbQR ֩}9_\E۝qyQ49y[^I ~#9hoٮI:5Okֺbbе`|G|~&}?Z~)~?w%C࿀˂~e%=e?ʏ~ NI2!c&X'Na5/U=:9ReڙznBU{Uz8F}Au;v+D#-_j$VK@bn -WD%*LD!H:}9a6Y˅A*1w$ g֘pf&2 Q5&w邮rً_NY+Qr|EɋP(Du@Y$4:oeز; w_`seqGU=p<$} |Pе%EHHG_!cga_vU{wF]+BlڍW9l4Z.Mj+FxJfnS1}NT(S 7tk3q30AD[WuK2dȼ2B`l݃KZE1v]\M';pǞT|^~Ftj9V:{[vobx([tv0>w_uzi Cʆ= ȫ vmS~d + ]tZ2e0d2,X67 G>ÂgGqMcM_HFΧ~q2Ⱦ-{0kpߋqǵC0zzMp|Cnn." Ҧ%]/ w ~q-"ʺ歗zBFO\%Nvb>\4C (-[c[ǕwO:5 qjV:]c[V VLD"| AvMФn-BJxkpEmv߾9rŸ>.JQ$ܟ.EZHV?1mk^Om6@l5?g * vß{ ek> yv@ԬVmZ4[b_85+j7Φ br 4ȲxI"xa)iܮy)KSʮZ:}YzIً o?3'Q oen^Km5tm/=Q 'ܰnU*! vM}֫ ȭ>͑csv"؋RyݭDhVr}pVm˗un?[+啂j _k\{+n+ZOskݬΑCSf(-s'yIˬ<|<~*MrD9@zKۏ]%h/c!>1ss6{;YʯGlqۂEIW}J{1 C0 C0 C  C࿂xX~=4i;=|M#>>%$),$ÅM8 n%#* aT;s BmԃBw[]yV^0IgǽXϨ:ntI(9ߍ?LJn RN$ ek3om/dbd%d}{8q6;M`t6HuXRtRW-Ӥ^Ub+{ݪVFGbݱ}o:vM=鸪s+FlSfni>CY9Ȗ3HL~9*zAT# ϖuGTJb X#rkPR^D"T_qۃO~=ݸFMVCZlr)A^ڤQ?lw-I75̿Jc%2s*:f5Q-ދlJ(y^a!`b}R8PHHG:c*3qzmӥ$ڰC`~mAZUqEE w1ce%EرUcow\g{-[0 C0 C0~sy %;b_<;3dGfleŒć?R4*J"VkisH^xCSJΗ+yAp$s\~DDl2b@O}ӧĩ"BBP11cIqWN8bSB|3'O!!yO?9ºjv CȥFKxkd^FHEQ 5JrFh 5?ahh?lC/Ό%C//?v~~1sL+h۶-rʎh(p/Q@ 0|de##XeK,uiSvom 9Sk#(~nE?Hat&0THNƯ2z`,!?LLfXes->֢#Q?Tl;G@ԋ>XOR(o yd1n؂O:xc,pM˴Sܔ:Y=\t&j0DD]NçZ!_>l}ׂ?`COL[>_ C?B5sh'#EHMMŽދ.,'DmT-m 9HxluoS$T(?3aݖxᣯr&1vExs4LOAz1 C7Ў wq>N uw+8&*ƒ9^ȳi5 u!k"-PdؘxqRuPΎ[ "ms 郗o~:9W\íQr KV4<ܕ#A/*$az8"~l#//x^sIzLwדf'w{S/dyG `>Mn~qezxiR_]_3KErVei_~0zo#y#ʍ;0Pv8,L ba#ULa#a/eв3ßv{C@3_KF7l3H= Ct[g !sܤZ+zPf_0pKiݺuhjժ9$$!+T֟g]N^>J)DMQI.hHcqkCh٨9}tSs);_&ƭu"E#G`϶$ /v2"fB>ܗ;{E-mͥ @j #U9Yh/y bᵱs1cZlۇ=tn&^^/D!M^(.l㙄Z.=6[Fimy/۴?Splש;>v:׶0w];YG>/~[ڇֲ^fwhR6Z E'oFJ*S^=SϏߠ('([\_Q(KMhT0 C0 C0 !k7 %}5X!mH|Q[Eyn:u V{h[yQ[ irm)[ԮOeO9]>\YU+`8LmgW=};.^fթ?T}j(̄0" i~=R5|JI\Ή2޲!`!`!`A"pX0~('{ Dfo$W 䵬rZ-ѲkjyXQKpfbJqk\icO`sxkM}рT{vrLZGGZQIV]|i J"qM}??> iYjOӱh->"]LZz\l~m}>}}}s@?s@(K9 _Lj_>ƒ%C7 T9ŅO&^?>wUEmQRuhۤ.thl}3|}>nf.l{$#23rqWX=(Ug!?@rP/O=FGqu&+B̝RB(֮Q kҶѣغ)>-6n݅M; ܻ_bdY_MǢLԒTs킕4o%ޜO]eQ?#0D)yޱ'| XهsP1lTĎ9K!`!`!`^Oy?ez/_GFDDJ.n SL9H=$zmu=ok^2k:Xk? bo!NHᗫ{s;ky 7mP>*5{1_ډf\\8'-#)|yޯ:i!byK"khhWN Çև?B~P,ahh`k~?a~?0+ϒ!p/j_̓۳g{=s=hҤ FO?<#8a`ʖ> MҙQ(?6VqqXaH޼M'H! N_^Skzy)Xv3QFKM:lWg*\5 *#B=DjW?o~Ly!5a>>}>>Ba5i ҟߺu+.bmE^{8*[v/ޕBrFDީ,~g|d9\ ܱq\ 4 'x A£ u<vbk]׭qMsY#엉gblcc%C0 C0 C0 C7FF3~8Y&Hȑ#.( [|K+6:b>}rRжamD++ *,)2SB-yCoɄ"hAOvIuyY&ۇӤО=^ C0 C0 C0 p鿵>5,ևD1<:.c<%Ç~[n}jO0d 0T $@&Lycx9&\"Ko>f*u\p{୿f^HީMvckJ&_g XJ|@ȼ붸nso*^ujT=Q쩬#ǐl_z G{$%y{?k_ LuO\5a>|>rrʊA~S A²ăyחh޼ٳ'W' ,p+]Q]zO~O}ܺ&+1eq .َIU~&_IHB B E v]ۮkoVqX@ED!R^BMH B ϙ{7rF̜33ߝ;3sqɭ,GXp f.l,Fn_ [ѹ]+t ]3<ɳg.6Qh:ßֱn=QNۆo|)Pq}58cH.Ʋ1f:q1>M+w!끮`L6@6~@m:38v%Wx2G)Q4tf;rϐ5B\\ %n2 m[_h;%3q77_]:N!%= %evx#D""H&lG6#Mz8FU_lܓ"5#$`NlHɸ`d"("("("?G\&+46=durGO?yx;]O} u6^DOcGs4璜jyx۬J0 (_>ҹ{찃Ah '*c/qyw0W}nz-{]n[U{NJ̧C?)N;;gOcBϡӤǿ\g6Ϝ>|rAG}?AD}?Q~Ͽn'?9W.l:ŗB3ABڎ qVG='%I09BYHEcmB Ǥ)B &YD VP "IC'ېEY mM}+m2\$4 |A }yp]yA< gNk\P~'<7ԅ{{ѱ1yH/=%=2r;(u1S'E\Jۃ#*9!2dQq}6tȸgE@PE@PE@PU_3گ xB^BqO9Ns?LQOK9rysN]0zX?Qv)ձH">׭i$TJaT")g8pD8׵3ΫOXp8q۔zOvf @Sqa&ޖGz3Q\R7f8buW8KyUܜ%*q9yLv0c&mr4("("(@@<NE@@@%2rumDOoёPDӶ}SO P.Z%4Em]/@0y$oݙ?KGXHٹd1a6DbXx{^+,,& uY#sIi96Hš|4i-#*[,]$6}Y~ٖd qц*.-6nf\?e^yV- 2W aˮ4syD—thPE@PE@PE&_f=EqGN"v/_TXrC\Ei!byw:AnQlW39DĭM3d arjk0oc=}G C.Y&}"쇗'}' v`,zGTnt$_0mm*ޜ8 7wVom~qԷz3y6>y$F 4OG;"9lڞgmȭʨ?+01exQHFOXٱe+ŒB;c4@.mW^l|u8wg3Ͽ[ߜqmⰗFǢeZenYɋdzqUk"6Bx+К:>qsq0:! ZI o{n&>'M.܂1Q&8.^3}ۜؾ g¥h D> ,C?µ΁\u}ڷ4`!W@#"("("e,7!nOB6nFGxzz:}W0a:>;Ra!!w5TNUXώ,6lO!}y0X" 9'9GQھ5&ߊy/o,qMWRm_ߚcQŒ$eZ3\G}FVf\M܉01m<%DlM$Cf~xnDvHԣ-OY- Gud5Gǖac?_F6o\CTr]P%ƒ=*ڛ񣇱~L|e&6Mā9_'c'&}WwO9O "05|YX<۽!j~=,ЭX1=3 ߸݉J֏=_t&2 t^ӖakE2+oÐk^yM?,\^m,>4_G_|D6jYcSrt#NFE@PE@PE@8X6T"pN `ۯ}Nۃʭ#DKaa!}Qw}xq]we?^=1)6lewh Aذ7Қy7E8Yq(&]:hK[]lft.u 3KJD"oADu` y{UXa!$vӍ;keUP^G7Vs{V1Ad!|;j#p&z7mˤ`TI 1^DUeKĘ!8V/j L:B%]70Mt0䞌,OكԢyQ.2  "G--#,ˈ\>h"t`,msMO l):xѺxOY邇bfުx`@[4nn 1<[K߾썩xЂ#٧~_5Cϧ?D{\]t}&>olAP~ dOKիbCg-s8o;v[T9~8_<%+nnlٛtd!{NaE6 f-Sl(̔>2Ϗ&/ο{m8ZB1 |[%8cymb úJ>ep Զ h? G&a();NS\GA7hl9zDxYyLL{A.1W!l=sà 1Z~{_hq8rvd)^UO'ȪcJ_K O&Vk#q6qQzRQ8A MnqJ_rr`VyR{"QCSOLj6KJ#or?9}ܓ:*mϊ]뻮gBG]e.Aׇ3>(ȈjP~0 {W{Lcq^a˖-:o޼D_#W}Up#a+t_-" \sQ?j4;I@|uz<9GELTclغ#_ldPg4P_8 `խ=!eW:F?1YbH!"IHW7eRҋ`~s90)t{sPdlW@d_XHq$2whCbr|rrB,KHG:Xcb/+$Ώ0Z@ ;x1`^{PTRKzK=,y5ah)i,?'DdG.,2ZTnJvLqОg\csC>5A]t} q}8B"p'$ɓ's}]|G<@}ao-bkxAt`f?h/yFXʹ- BN1toQƲ&"LmaAft9bcovWIȅfk0:cd]ǺFcLlJA\đa\ۜ]h0m6w8Kր^d[~?|+oiDlu*=".m li0%N1Y¸$&ȳJl`VۊisҶbKVk?n*!|ݘchOiHDOҹF{~eƲ-ᩙ3.=bg?o+SHۦD!^dddS.|rqbE@PE@PE@Pp6-m62tn퓦z Y1H\Vf">11Xe![ukX[|#uĖ 3Xέ>d(88xs[%`ҟ'}DQp!޾EG3~~zq&ڑne{xf~Q{{x!А,x{`9o<>}Rh+5{3~vf|5 @Orׁh~Kx~E'} ADq[URka0ɘ86$~ t7.ޙ} 総Ǟ\Dz3+o?j04jW"{SAo2t#+{?_Ž:pcN!nb]W Àr"Gb"-yFiq⎃+|M+"("("pyWjE*S୓3}!,(tF?𿅀}pޙqk9_h߲^gKi[w"1[E,XJCц<ϲ2ڲz~߮ 2~"˵KdeaMȥmt߀nmλs(jQ3m?ZYgVUd6%8::cἣXyErB #kՂ:mVoƎ,$Y>v6HAX0f (d+ȵ-$SD'Z@xބ!HޝZӖff@adE-`6_Hu3!aܚ, 9𙅇D!y4nA}]f 'ɓs,'|y+PBWБBF4@.mmr߶LrFʐ4Z8u j]@IDAT"("("(JVHk;K 9_=>;}rOGroe2/erʲܽ {^蕫",{[Ɗ*,vL[GFPLJqvhkW{6u}u'M94u>.nZl+5͢غ;,2\ѳ-n"|;Zۮa!{'a y-7;&Q{LI}8H :?z3룮2t}QG]y5A?~-}Sk_:dC]u}u@}?A悾~SW"P;k#b/8>~ĊSLϔ" 9]PtԞr_ɡfXuM 2KzY~.cjY6ꮭoqdž5ib&_\m@9KVh0E&gfc#m.+/7[M"A, .rEiÒYXq},|+"("("p6P V%L!8_\"zjmBr\tXrJ3`R\@tp}ꥣZmR"D/`>)XIpLYGS1ηhunGo6I9Ϟ/Cz#3كKni˝rUeCR߲c]}6mQ! G5t:9Q|J=%*9q9_y ^r*k2VΑFJ:$O PE@PE@PE /M(vGH%U"4GȠYs %8Dj5ET\ȹ;Ȥs茻بF :u6v.;Ur*.r`F̓`N#}p>8-u}v\FyG~\ڰ׷89:Γ2vyeU2ro2LJr2Ef/+q.r]_xȜ q|냮>;A~I囯APjGIH1&My/L(YrKa]o!̻='푂"<֧ٸ{wnzs=Պ.bkc۷[8dK[Ϧ#eN9鐺U.ܤVe-^ՔgiߪocsW'ߺi .:OT'&[q5`l0fT8/m"("("(zVQE@IL؉Q)yVEe(*#+'F;Jr)TD-@+$9O,&؋.`Yz\I/iS״YrӮ/rhշ9.*^$-mp$wշy݆߯4q?_:C< \냮~5A~?Q֠|pTT'URH^eee(//GEEbM9//d{tnJكD}rЫckx{G 8mRť޺D"ew:?*0edOֆL|ݙlfioHqŽZID8d^b Kѫ}ZEcͦxo菄dz^ :&!80VmBGEg5qex鳅x𣅸WkCܘ(O $׾-K %%Y_²il7=j)w `hٗ{^Yk}(|t3_ot3]K&ĦͻPJD"[ڬ#hc"Ы36D*}7qH&x}%d{cM00Ss"TT06T뇊rԈ"("("(n TEL `'giӦCbb"RRRp}a?Yv. |CVe9ƪmGj .+wdXg U]Z\kKD'aW>~qTyp#h!J!o-b#p3 uO]t%qI>\rR xAe@[c᷿ĤpubkXpԭ-zwiGd( sxX9ֿ FJG|Ǜ9b#PX~%F#ȿi;; >|&_hxݯ1M"Y Us0ށT?k3#0;ÕG'W/7Ya>s(Y$^+D7u-e;8U'Ҵo0c>%D/aԖH Bbq~n>dyسB&@ϯ4q"("("(xN~@@΄.qn +V?ѣGO) _\vhmdYZWlڅ.zHq-8Hi~X0Y%$J}@bZ!IuI4"shΆc}=:$ž Idiwy rWnكgF4py]Ȃ-8_hqִ5t&ٴG",3p#t[VG!oP[}7Yv2|eP &r|i{m;nQ}GkdWLX[۴ WӠ~("("("P'C@,rG;U}Ǝ}dnݰvZm1p̙vjK*XXk?z8燌rC DLً8B}1[YŢqPL>{^r ?1ѸHtn'3i߯7y {퐲+ _IOXGgUYYo FO]_'0 V/W5?:ۏp"ɲ^6gEaWQYI\}s&_\7j4^d]}lH(!k@ކqo6>,+X-Lcg+H7n>﯂Y?NzGNJiر yɆt +N╯`Qzh{.m\Ԇ/֜p>8AQ|xpW}> sA:?9맮2t}c~WgEW ?'kFd6eNC1yPq!*s gÃDyv8dˤYvk6DAs:GMdb)h1Hdm{fAhp֭5|%|;PIĢ/Y9Js[m08A(|cynrh/ L Rr]8wNW{q}'ҫ"(EpW`ѢEX|9.\!Cxe݊OT˳h%zjJ^p8^IJ4&˲VOZT zgD8Vmj6m А< _^%k ً֔kd w+ yŞyKRp1#рÞ̹dd%Z 8af/k8ptqcDŽ_5[CD4ߗt\`d('''H& o}jp|dbvbDU!=3OV㌓v-9q #̃U86=LBf{-ݚd7v?12v"=/߇6jd YdCxS9wXr5"("("(?Z@*VE"d6Bj%''R˝R2X~͔ϭ) oĬA׶-MqkB_Q٩qKW ccGǧAp(3ơc3q(F=)ܰX轹e}Z僺WgamA3bkQr1[1q羅p?^FLX BhkadYWj)?1:mM{7_v8|WіݤFؐ&MCjd_n{&cCA"+.đҶܨ2{f5r.h'/=/B^]Z͍:#6M9b3Y﯑ln3 " {Ə$*1}щpxWr};ƚ6ܠ22=i "("("7gs~8ćOu˦<>ݻ8|Ys>-<_8F&癚THtۀ ɒhA'lw8/!8䒅ٖ{u^|Lm3Vm,㭷[vv<:cmZġyl N:2yVߜעy!ٲ-eO:2id#rx‰cg{ ۞'\l dt%6ig)[r:tq`!uA6ZR_>3˂ vPV͌n{7 a^:"ٗethdh7ϞPD5igҕc$ld+@4ۏD!;Eil͎Мc&ۓy >eҠ/k~("("(/@@ _V9w)!N Ap[c֍EP Q%iv:!iMi&r}>eg'ޮ{&%od 霈.fHf.@ դߣvN!\xa!(m5f)kN5+7+f6aSZ{c鳗qrt;G/eٛsχ>2x^냮>ʚ}?\t 0Y "_,Ҭ-򐿪3 z|Y'ESTWB&D)i&O_{Z9urb-9;ƾ5^Ŵ%޽2Cq9VEhq-NYBNn901(jU"1_{Lxr<{Zp1[|"ۇgQ[>v \,("("("SP 9gۺ⨮ Vj!yuշu%|i|6ÆUjpvvʉb؃H0o:'1gUq ۟cwõNmk3g<{\Ԗ'2*"("("sP UE7D@+;q,9.4K].| v"̞qwE+o?{zruIZ?.KFdK=r9eNKA\W}=_HH):E@PE@PE@P~ JԴ"`Cv@D>d 3,<=.٩R2?%˰%pԗZWקµ̮8-AeYڕW}].Q+jU*XVKE@PE@PE@(1@  E #disV5ԓLΒhʚLQ!(VMI)9sqV<;RPTiGmqb>ܾ-R@^M3\YV_5t~;]?tt ]t}A: k~O @{uR8}ZE$pM9`+:x/{-(*ƳolēD/O,xԦF{v],~H8Ots?v;zȒ+YeM.c=y^͘ïsx lwϾބHTgbOzVyǧcmH"("("!jj9CJU"(:BULhI-w`&R[axණ SƠPg+=Yش3 MUs~/o߯RnC{#E3"*Ur1w5 5*9[vy+qX:ƅO3!8oz!+'vg"qgףeBS4ivE2]߯N;sj?eH?\0&I(yC5("("(F@-0NP;B܉srrw^۷\򜤠cRBD%c: tcB ":!֥ⱩQ/,|ngCpa ˺æ3PIi&ɘcopck-XU8I+OWf=y6"Rxk6}!x<.q/㥏kD.c?R h1\qq Bx&kHi[G&_H1x W YG7HO Wn@{^Cx?Fe[Rq㓑w=k ῘK^& ㍲*x/rOpaG1YD_v ʗx,!\)Vr(UDOc+[("("(F@-4OPBǢ)SGll,233믷rEs?>\'n/mp^Nfk%y[bO:_Iޙ|^8"+Nd։7?^Ҧ%GYibk1ɉLu9$6Eq#"> |q׈޸ QA}(,)?o?_p~D֌{GFkVF7cu~Qxnp\:K ZIfj\?B4&\?"1Uw=՛#,%|<<>n߽c2VU ׍j!(~r -`g> 3SȂcoGvIF_\~\}@;m9pWcXwHjJ"O90!j&S?E@PE@PE@8 (x@U"_KH;jbܧ Y@vnK5n'DRm޹kƵ⌷`>npɸ~@tIGnE䔐RdEGl_]FdVd!28Gޤ -:?L5b<3.nD*J.ދpX6 @F|<:pmmBj;[kf2U4[vL#"nG (mGH V8㱩 rWvDCqJ<$@%Xx[A_} Rp?}<L7b0w3\JXi`GH/aIۈ9&S?E@PE@PE@8 YhPU*"T,mY'j mm-J_ \x^oCy*]ڵ;`4 葃U;2z슎߄%k`Ֆ=xtz dMD;PYEjdGYet`YؽL8\I9ss?uH`UW#8X@nkb i@ B=ޞA :CB:珷 n|V_)Y%1xHQJ ;cѹ|-Ma&"BN@BzçF|LNyf,{jk* b󭻯6l$U("("(YD@ >7k.! i3*H D%t|dkl 2˟-D LzC ru&5P zwN+/ YqXa٪;$yWnBV-CVLq`kC g =*+8VYd=W:mKن&ѕC 8D@8]9|_*#M|qG:Y$"볇ͩh _' ,3*c<:aha%q{b2N5x~‘cTո9L- EŸ,6tAF6A`(vl䞟k~z]t}灮>z sAgz~FT"p^6>)vu!-- K,1#F&n?&N[:?^||:8OZבWۧ'Dp446AǸ<7"Ir,zKl6XTye'ȻmwRrqy#:ƒS9a!ڂƇ_⺷7_-h YYp YՕ6Z UYP26֑f?}94){p+3`6ƺɼ#%ʜm1ϱe-;làːxp6mS||vkQqU$<<lߝNa朅srxb9.,aȄ =C}>k=ù> | @@WЪ•AznAdrR6`>O~<O^8fCVylGs،-(&+У}Ӫohnx_y,ka\D !LF쐄'lCoG/y ~y-ԇ'} 9C[E;u ome%bb~8k/m%^tF!B{3S';+/0%IȄ.I-os+p3 q(aWs$_p_`#oE[|';X4yr\1(1'wn XևrϙHeK@ "("("- g} o'n1V>τ;h0F2|yGZ0@4Ƌ1c+Jd b 3N3=3l # .x>pI "("("=alqw<"c(Tn+2M|d̂ӵRVʕI+!D\Lm{YCq!Ȳ%yidgdk6-3I) p]/A1))g J)@L=\`6ۭ$uBɷd$$k?l_3=$yOWN3ua-)y*W|d.C~뀬 ~}?A~p?(ȈhP~ {W{\‡ٿ*՞8L8u(_ ' !bXKѠi +gYG$MIhk=0qփ'q`q "eef2}ў][E{9ˁ/; qd;ވMZ-}22nW{=.ey-㊏=C}>k=냮>`_[UIc[,BpZ\FA"(>~~ܳ5EX1mY ve> ft1; e U[}-'h/[2ygo瓔e"+V\v]'Iq>~,-e=VT-rj\K?+%*?=si{t~~ σ$Wɓw*qP?:?o}|Wy~gpRGEvز)QjgA^䋑3S#BjX_;]_D5=j(C[}<}Җʉ5"K=ZiG\]˵Kgy-ޏi:3rǭSܫ: @PE@PE@Pn>jE@P~ % )"O#a' ,oebϵPnz\<+Xɗ k#=3#}vN{1cD_fV:k3єPE@PE@PEg#φL+(5p!55dٚZCw:X0ieN;O+I!,Pt>stϐRy%!ۢ\{?bϩK25u4iiE@PE@PE@PXik:E@P~w5hGՏfc?K2Lb_L`,?:" q<ҳtV|"TVVlXFeg~xP"("("(A@-\FNf8l&n兙K6!%-[Гri0a|-N:OϚeϲ=ÁN}l'yݵnKè!ӱX)0eZ\4;|L)[wK@.{9)WE@PE@PE@P@_+-_hVy'12?Ӂs.qBF`tNNuXp`m#{p0'eVwؚUp.)+G8ʪf~.+?Qa ۵Oc/ҐȿR?dyHVzͤ^!8wY9yd蒳#ذ@k2u!,-?^u(h19/s >|:3puiqAr1.2}㜧r>'q|}Mu}A]k=냮˔'<M[8ȧ!HXsX808 .8mGӊ}>Pb8b͛S 3_<"<ҮSrKVMS=D& bfu@T&of-%8Nyq.9qёؗu[42}]ͣ{c.V2䕞 #&z\;r05 a%),,ua!ADDEUG=kīH/F#"|4kfN!q0n{&Ӱ-,S2u|ϛ< AD AtAG]mĹ>[چQE@P_WDǷoߎŋcŊXhRSSM.K/gn$[r9FG>0oV"Nt"r1ve׭ 24<3ĴUUo|퓰co&\ yHھ, <%5_oXo1|ɜm( k|=l|<{{UfrjtM$7mwv-ta/}3Yʔnj<:rXL =6xٟ`i2CPE@PE@PEg!n*kaE@P`'s^uh™THA slA(& Z6F8Sի'}v"zun@4 e]W`IŭpyLޚ;8Ԑm~v]س3|ßҷvM\>;ק8a!h*S-߮EqvZm[@?lr5گmG _4l&⹿M=醈A"("("(F@ VPE!lt k׮%G2rʄ[olO@TpZ cG!F?EAqYGu2DB̙쩷$hpD9??VkRڄM} ANV :ť`>^()+Cna1hӿ&Y9\JW\|^O|jo7n:€`ts>^jo=غ;~oq!(`1("("("PgSRF,is-[aC>޽{#11))) q2vl [%!i-:h;_, <ǒD"},Kނ܆[Gۯ5m$+R$YNGx|rwd-ahƚ=A? љ]iLs |o!$ wC `ofv E@|:~k?OS?}|%\s5+sKDΫ}~p8V]&l@"||:qlrMoyf>/[h/X/}; +'P^~9G 汑X|ي͢cb/;(a`x>s4b3D{%ޜ]E?=gݑB~W>fg뿋h,G7XgE@?̶aٔGѧ{?jTЄ" /9 {o¦if4%Œc%#˶"#zA ~.qMwKMLsKlFä|O{Kt [ !k~i8onc5xp_Vm;aDzamx˅+=:A]p9&37|9s7 P_/2zq`tLPE@PE@PEn(#%R! |4-ˉ.)'y+H!#K;%elj$e-m>[xi7Y8ҎuH`g#F(Y r(*.5ۂLYfsOxr 28aG!>JE@PE@PE@PWO*E@P~*BN^ ƺD.q fԵI})fy}Bq:cgUX~!'ػ{ }Xmj_VkkKn}w$d% IwK2@IDATT3wg93ݹ%ghZϋgy2G+3 hDgWC0 C0 C0 Cɴ CPJ27o%Ԧy2>Ӽ< 9N4ޯzZG[cm5Nu}qՎ^] C0 C0 C03/X ޏ G}8텖 >V'92S&^n  B<^ U< >l}>/:~z և[| ;+Ӓ!pxp|:i1?~|Yx1,^˒pGjf0 C0 C0 Cp-! @9&:ũ)6dzs%'á];eDvm6HH20>GR̝s*^}!`!`!` # C8xWcD_ciTX\9|h!ހjtl&ж{,k:#һHKJ8q1N4C_lCQǦ>l!`!`!p`<06&1 CKE@;!E.{}e矆-7ZْCRU(-D4WTR$ mg7GvV(A{v†-뜓wRTbWq;QHILpHU`8rg"M#X.*-CJR"+y{&#'+Q"l܆ݥh춈&8x!`!`!`4BFpX0 #;x8Du*k,lzܖ>/> tJk6l폽Gwo|-}w9cyq998㤡Nꬅ'bUI%.? |l X b%wN?;W uk7Om&U7;}; $!MEyM؍ p9P]]^}?mM;{d!չaMb!`!`!`x|!`POSbժUHJJByy9!C^vaҿ?/TsFGG㬓^] gWH7VlC@$J&[ѭSpFx+pWn{\u/"NkajxءS^-8| )x"Y Ozg*XR0\n;Tw^1C-'~w0aH`1CE ab$`Z0 C0 C0 EE C裏pw=AJ|zU 7m:V6 F7bB^۷MJi ʳл['gb#Bd 1SBgWY[uzDD8U bccvV6g>3mL17 FVH/_wNǏL]=.1vT[K0w7l{v8]%OE:e0 C0 C0 Ch@/FV0 C8R4o7b|p_v| guᾆ}*tu-2>M?Mq1Q'TEwQHLs:!I۲*&yg s{.ۍZp{d/ _D$5:U<@<\vbdN6 , $F&u: >$KW և[| `{? #u0 #~2%T/< 늂 р^zix Ų$+}Iu}Ujj{COa{ᷭ7Mi]Qѩ߃5՗!`!`Q8J :z,QOuk::j?ZWǠzZ_@Ňw|ESmXnpQ,dS:Mz6ɘ6Ȗn֫e{us~l!`!`F_fkG!JʟC%?!mWbJKΆTҫL߮n9O48W@/A{ei ycRiy:$̨ Cm9\^jZ7%ף,)} յ;.ۅ'~ʆ!`!`!p `s/m&!p D^9-5{PRVA2afh<QQb;A}e\8*9`kP)~$J΢0r'65U\"}HTfo U{٪ EVڐJgr/ZH/ِZgWC0 C0 C860ظ6 C8P?FN@N] c{$Bo3D~ g]]i$-!A(L|Vц@ vm$A'.7"S]^{|^y{8R$Ŕگ/1):u@"oʆE"nHӋz ^t2 t. 501Y?&_ߔOEe~7qfm,#?{I7_b-:'~zyHIJp=Qfb"% 3y+^z$BC8YrdHu""r33y}xyWa!`!`!p"`Q{l!p!'[~8dK^vㅈAYynk8_gL8u8jj"VSdb vAB#ZFZnJ2Vwڏߚ g<;!Arf)WVU#sلN"nB$}߼n}oβm:RPu"KNLJ,^) yy(_\Z$gfa 8Gpl wc(<._%6 Itܻ3ksr?xᙙH߮ߵ;gm$gnHɽB/ѕ1pRg\Qm2Z{Ur}v8prSkћϣ sls|;և[|ޏ5|/|"SdM#:{.SdCoMt̜ ?Kxxb=mqOb{>Vn݉?Ͳ xC>^3.Ⱦy|w, QZ|{h׬݅1w)!+еu#nsj\!ڦYx) ucF}F O/k6agI9~hVV,D]Wy߲[YU\rK]ڶDvm-՛qV\.QG|dlsWm¯_ڷDNVwO&Q xo"<1s9fgپ<)8Sly$]{MRw^:i*\3~`}bҿq=/#+> -XûGk!=gP[]*!Bא!;9B[u͹ ه!`!`!`򨞆 8BxGx`u &'M?ZŽ;0a?>6Lؖ$RjTf=ϗڋʽXЫk.mڎggw]{8ޘ6F 2)gmǩ?yEn">']9x+4z`w<'8sp\{x`Z<sBL)~' ]į{ymS8q)#11KEgEM\yə}?~vR_tn.'S|CvC27ɯ[{s0eE#zUVb`%bƂuB_7scDN$H4-Y|>q=OI7NΘ/g0\Ag1rOeb+^wã㬓IJi!`!`G+$ou6nC!t=+qWrȍ,D:Q2eժU8qbpV'pB0zM+mOe'6He{0nK'ڵƤۿKo;28ں: >9g1F˟ӆK`xIOcvA!MK[a$ nxcElzD#7$ >ZȱT׆^op*&伾6|^8 me}G"2$5}w[UbFq^Ar\!QҬubʼnV,23NtmCnDO(GQm=2S,g17I"!Sd+>yx-_~-}-z5=E':o~p%n|$ d[g;s $6#[#=;ȉEpz6c:ŕ^^vW/}S hɚtmiٮ!`!`!p"@В!`D HINaÆ>C||t90h'&2c.zw6ڷHAViTXiNYVr|ce/c_6-?`,>edl T[;J#KV$ E&]^ PZ50aC% l*!ȴbF}#cKes|:ʹ5g16FJ lSl"`k:1mڣןG;(wf9(`h!je< - B -+r̡ =s9*O3ק̃(QWI:!exȶh+%>>{|'9OǜƉmSo)-ĵڶ!`!`!`x;!`%)wv#'TQQᮇ IF,G7MS>>>>5,lÍߟz t*n|B (QIfSG3`"{X2)SkKۨ(LURjZK\duBƹHy<ٰKހXf0 k'Y h,fـ d+D-0o{}08h]`W}a1yn9C{8IGD&W▝ξ#Te=7=-B2xKd 3)G΄d_D Do9{;wu+=9mpyĮ 3Z %`y{z~4k!κ̛y=^-!`!`эNqtFo|xJ6xeIXּɏm|3K/ɓ'_U_+г-!UC__ eGvH` rK %\@"~7q "Buɒm汎ҥWH0arO^EॽҊJt#2x747=~߀[w/EvA靗G}o~0o|4[|%<垎[k !EjM?7| }^tMs/y[?~lxaχ=|}'~b)40~Fe^;&cKJ3dǟ(/7ӫ_/ &W szBl źz7ou9mұmW H{>^ NY!M4D n/.wŧŨFair23'p([WO iCp 8cD|K!^+#n̼BiUu[$㫒8aTwgp^*s\?uYb$WY}mZ6k?:%hiIrR(xl `ciu\1үn7*gu8"O~s#0GqðN<0Z3~&%șpp-O.,@^Ҿ^ ;{P,ރqZ iE}`$w@~u`,ߘ-ތY-Rp'[t;3S8"8Oz! lX2y? Ο71|M>l}N`{?4~?Dd}uU}Bj>1tqV'oLjH(xMSku4OcmL~Aׂ[di]`.=l،DoXk7nqd9!6Ctv Xli㈱m;v!C;Tβ\V^r.Zu,rڶh=HJ!I`Vh)yL5a{?ZCm'wD~6K͒!4Cٴ5\/g/CF׳ >\֯'MQϪiHmu(mu,3u @:C,(^94͍}RfF`e '?Q}޸/2E{J:'4 C0 C0 (›?>5CٟY&?:qt +z-/Z~DڋZ⋮@:^9-s :Ͼ_N_7 s}34?Oq8y`?ns-(g ǍET a>`ʢ2&x|x҆>]gOm2?н p\}׿ v8I=1 FSjODy Ln!`χ~'{?N`#~ 5bol\ :hHxcILe:&7сo,GfGօ'I}ѓzwZ_gڿl?ױƁ>̭bjɥ)z"cO˴/k>puٟ(P_ᴧ~arUk~}rmϫ?r_E늏7:_h>l}C _c[ @c0 }YCJY1KEZk{p;e[j_c oTtu~ڇ~c/׼o5.K<׾PSJ~`}|l_Ss=Tχq(>XzVVo!`!`G L&yޝUL `}v\Ձ4.\&)&C_'|z7VWWWbfDEFkn{e6lmlպ#V8]ؚ+kn5DGEEt6(i_pq)|`!1چ㑟,[ 2Ά6-z 5 o/e7K_GCbԡmCjRb6W89f)wgH 6 = TEWq @XY 1nOUNǠz&֐a {>:w~#,1"__yQޖƭ;dk;.-u[;OΒrlVݥxsN<=v0b%$\Y||)R1~@H㟫KV{.@eU v{yJ1krLMlZdnSGDv֎Dt^l[EmSGGE-ⱵLsW / NlK0c*DGG0jp!梹d#DI ݸN5QQh )>[EBuB4OhD,EyKWcÖ|ٺNCrK/܃œrފ GƜ}u0 `#kC7sGf%c߳K-;E>rOGmÈFﮝ5}?5{k1_7G)wszsre`оؾm>;˶8,m"Apj!`!` -#CXAD1y{dW (x H mu1 b/(ĒmEJO5]!3}>³CtZl$|?J+ժ7q2|E>zbLOw_~UG*̙;{6َ{Ҡr##'bc]K&>ZצwLB[uۓ_G.^rouI@yK()ut]ݜ%p˓o W U F-?λe!<0w:L>ARI2lҺ|T(ދ-Sq/G=~-dor^Lhku$Jjċrۊoxyٯ+X>| F9>,u_Sf.+ļUd˳ocȸ᳅+\m.a>}!vČEkp`ON]!>ck ײlrGׄ-6^q NDlSעo<$'Oۮ%xFvpi?).q[HvVL UN6}_,$X9ZJzr_l7 ~Emc^n,YqуI„i|BF'`.[A`ombmŮb^G`C\mk>¹* Oa?n-p `@HMvAG=L6 Uْӹxelj9$vsaP 95׀$/=_ChG=GN׶ϯrx,۾_]"w!Y z'1]sզ5{C<~8oVEYSR!`!`!`G#f0No׮]:u֞={@$qy٘hx`-3i:fi nmفS{v@s! jƐ^c9CV;va2_gB 7^r/HDyB5é~>]JAxŅLD19ny?fl7w*Rk d /DvUHLn6 O鎾=f}GO$j"6"6<}ljn-nاS')#`앎z}9-/3{Xyx]nؒ_m-U5x{H,w|bxUXz#rGQ3F};pY#Gyi.vKPś pcdk9yt/FQe ] qֈ>^m$&{XG!قJP!Rs9/A/,d&#O OH&Pkn6>ux}gxùd|y%HMIBkG=M䧶uBTvHsSIzYz.~ ˺zZR̋DlɸVrBc˖Kmdg 'ĺ-VIА@\ M&Ο-%E{ * x fҥ}k '[e?YM)٧!`!`!`G_GlWj$f̘ш 'eX&Ym2ѫ}K sF~ Nl\2px#PZK1 pj*c nk% ߖd+R3 *\!$xp_7oyoM< I$0(,Wd[psmRL ^:GwIz ^>5 !`!`!`GB=BYC0wXNNϟEaXx1RRRpT`cK2Wn=[##SHt@K+,}[zf@[Uh/|'|B9ӏ8>6g XB2 HBpC I>ZD/!8{j[p,xlҧ{g|2{^oFK_'wj3u1g15c!)LGt9{bk Gꚋ?݄ޝ&^qn-_ %a]k1.x5GĻ0cw.xo"D iǤ$-[\Tzwy6y]2Oɼ\ۂ{*&3ӑiB xV!Cbo'Gxq+p1c`NBH&9[4H R^010z˨]l8?2i[x1ǣJ #&nDS$R orS횪ۯ-*ƄG5kPӫ_u/o'(k6ϫ=2L~{dY:暸52 Ȳe{D݋]Y QcێVV43t'-_Ǫe> C0 C0 C8Lэ=zhY ?:SkK!2%&%'}*)φi,l,ԠбyQ}S"TW2^z!r~?ͪ}? .xMuI{6(T>\fmj!`!`F#7 ?ȁUGZ5.I"e ٘z>xB[lu Ǽ (ЖnWۅ׫mʙTWh(k~H:n-z(r^A>y%Z0 C0 C0 #!`G $70Rrpl9F MI\&%"L ;؏<6՗}+%̟_f XQ؛5ݸMfɊ!`!`!`|-0kql!p,"I$seN*[mގ+9DF6CjuD9>o)G0}DGaHΣM#黆z`(9rRev\^f/נZKJ1OD{М[Ȟ6YTǢu(cbL ;c.s"9~ZڣKNVׇG:yy7/hnx Qa^զ] C0 C0 C*6OC0qU󜲖W¯:`Z"N9< <}>|\U5xm|lY䚽l\t~#9U/[\ G/>#cf;w->~,c0{.ʫbM㱗AZۄ~h: ?R|/3ɞ{t[[Mm"cy'C0 C0 C0"+޺5 ?I'X Y8J$:?93QSl#\TTo!%)ĸg&g1~3e!4&'4t{$".^DEF:]#YFxa/v6T/BOqNõY~]qީGnv&Ə>!WIY#Ru^L啈 A\(@YE;;6G|-|i) ,X b_L\HD&%HqoWpxUB!1>.l c0 C0 C0 >',k5w8[72Ɋ\\6&wxwp,`]`=軄K)T"#:#!6&&B~ؖɵ/*qkn'IrW>n Q>!"f-Xgߙ%{zk 3UfqYX5u%h,`dƭ;"~L<$\A'iK#*^}o:^(~FtnpnS&dzH.xsrIKlCrނEK^zg[&bH^26dFEۘ}B<$#>[1 o~0#b~t>Dg7tM1)3 {#wmK8Qʶ B̈h&,oxwʈh\yhoኵO9w7J!;|ϣ7pn|[;~Wd[>el 0d@@~W/hu6mҥKb ,Y۷o7auXj=oَU6MX~#vaלzHJL@T7 MKjÜE+0즇йm:~ux 7aڍn;kq50_G]@T3}\z6; r&#/~?8g4nL,ې;d+/2{ 1'sۧ|<$\4\5~(r2[NüRv2Hlnft4ǖIh'ً~_X%=;?Ƶ28䷏Hh&%8oƒ(,)9؇QzP,uWH~t1FFSA&; ^> C0 C0 C  z+d783#$Xce#|=zygp뭷#<~2Z?յW"b=[/'g`Y# זlvሻ}x$nrѷglQ)G^nnpA/"y&ʸelk>OO@㦧FL l}Zփ[!y!hC8_/7 @%C?A Nz<cBxfe26 ll/7O*KՅ\mmܼ%YVexFfmrbkHÚz kO/hɟql}.9+Q,:bc3cFO!TUzs\7 \^8wgGQgk.CsнKkΏ^uغC n'sVcz;2Jse"<ː?i^]=E9u69q6?dz&T.)n0#1.$ێ;wrK^> C0 C0 C0+ֽ!`ɖX͛7+Z Jڰē0)S۲kKH=_ce9>XI-$J(Hs±]:Obو%7gq?nR{›I fO{/!`!`!`|j_8C0Yɠ/x饗j4p}^l˂U/Z lO5*<%1m!#F&㣙]H{ybD;JInxfj'B,^/3c~n=rgAq˃/9mÖ| 1ـJu7؏xS":_W$*}‘lO ^lnpRV%[kХc{|Ճ/cyy~ϼv)q"7`F dnGFrkg>,8Mqg r+$pt0 C0 C0 Ck@dJMb0mTRTvm?PX㑔DwG~k_fjj0zP/ݪm^y]Ů]+n۾CGImXӧ\4T!A?e˚1LJK!fCaQQ. uVj2*y&ZYUQ'l'ra$oOUMCK! %idY~;g ;KPSS-zn)M"HN6ȶZטs%lruF=لT`n$ 24)^3WV5ܺ6l&rArq[A_(g>+jebSSƿyj q11ڴt[ٞF$2Vzs-LnpϏ>3|^4gĞ:5aÞ] ~}?}?gߏ dČ'oLjP!_:AX6 ]Ԛ _c*O{$ WRg5@:M{u$<lJ/$m@v?P]S=]87Ln=|4~{?kA `.9KA8`}bD@#ŭFFarB7?ܲESj}Sv]]Sg7d$5%6W ͵^ή߇9D_X9>mGܿi'mn!`!`!`|X~0G1ԡ>I)傅 -I4,F22 s~T#B[R&]RB,طSsqHp4u:Wzƥ M]e~#;dtu^#٦LRSʼ%C0 C0 C0.u6C0'?t u?O}"H\9Jj^`^{j5jF}H:͡t\P9|3k-u}#!`!`!`_Oz!`''% ʝ I+%v4ӾL]eM{m!`!`!`| 6|͢!pt#K ֩] #Gz5 ZZ ٦â[ o|e+Sճr0~l!`!`! @Py/ǢY1%ž|KIнɒ! NAY bPUolh-0oW뙇Hύ#u}4k Wŧ VҳOBjRbP?ڪ\e,Ӯ8+ؘRv5 C0 C0 Cb4bͬ!`E@ 3@Bs\TR0 $Z$"9>ͅj#N⯘6k3E?JuT/(g6صJqZW{ q\?WzU[z 2!`!`!`_ v9 iDy>\tPϔ[vGwlk/:YP/Z}%ehx è!SYUg:*wI !{ Ml{]oY꺖UWŵ 6DX" ׄPH%w޻ A]w-ͻSϜܹ}!ﰐ`Op 8qE#k@4imL<*4FTxgAߏ~w~pA @Y?E@%cvL6"kոe nI*j3}BډcJs??{ Ǖ@HC 7v>(qcпggn ے_!}K5O[/>k4ƍsՖ}E=tչHCTKE@PE@PE@P%kU鎀:3kgTG-nذiii@YYڴi.]ŧaL \ϧvxa4[NL1ˁe%f :4Yb%Y%AT8;g_ֻ 1kny&D1i8_ssBYNz}:7 8>{.bc0bS >zFDuKfcg`aHsg߳A(bjr/p!k3냮A @y*(oܹsSOyz|мAےZ?,&͎Cؒ-ٌQhf+GY1#mёxK0il|pʍ(ڎ6m4Wo nv}lUC\MGxFIUPE@PE@PE"P:_`8w6ЂseqibOyhLJBTTO WիW#44ԤBX;+^y+qCc Ku]9}>$X1 謽z 񯐮*v_ťX_zy(,)h{qZ ̿ oջ=ƞ=o9Ex/\GKkeᮣ%VEy9hѢ"Bt  2u_]?tA)<$:?t~C]t}}?~PAmÐiAB`N@/Tό+iO"Η/k&F/EEE !8RZZj!AF͟cfQ>)jmD$e5c:lLLᆜHDE4Ęa <)G E8y~ћ.ހK7[

n%=o[ 6nڵ3'ѯ6P|t=g:t>|"σ>٠>7Hրgp6@/g&0d"("("(|XPF - 1qDŖz?QYUes{0QyK]7ES]w } 0b1{,߲ D=|8m`ӫ! ]n{H\0j"O ǾEVg~Xm|iL^=P={WE@PE@PE@P_7zi rMJĹHmC)8?[y%gVL20AܘfNpyr3ѣn< :?Lx)9$>I{.wr" 9z;M!CXD,?0AIEedXeǔevb9~5sY`@nL7"kFD1:џDX=<M#yK3gt~냮/}?<>(sA?Ja}-@"Fӓ3.l~NJ֮/iz1w|Z9_HdX3GD]-\$Inkh܆㬏Xc L<>ǹӠ("("("#P?-S8X>q J!%8o{hns"=l|5,/fgүȖ\%'%HY4[LعK=r<$^"ۮ^eq sݯQ.9zLE@PE@PE@P~.?ms%i=E@PNEgt>̆ #F_'$zH6g+,uK)6nYƏ<ӗKܣ,߃'{őbcdwYThb2?LE.&<'yGS.}VUs1b7qM}dC]eYݧoTSǔH9ZS[Wޭч00YNliy~#Cm "Ћ@:)^՛rw0 ҳL{mܔ";nBvGǕ# AVd;V-Ř`>r'-r=8㬧f݁4''ĿgbRnO)!r? =2!8MX63>˝ѯ )balMYd4wugQ"=܃H?..127FF>U||Ǖ[I{, 85ig3.yθ+~<sC>5A]t}p θgנ(r3!M1r=)t4C E! dqZ/Gdq١llOkth->Req<qشqDkܰ>B\G=a4}hB8+;vҡSۖ 線ax=(*.Ehߺ9PAf(O sѢi!;E~U.9OR~jPtۥQJ"nw!$dMDy oNܝj۶#<z:4>Q.8=iYh @Tx(LgZVZ6mP]~DO, NDX2gMܳGѶU僆!6++ 2kekRPE@PE@P %3#E@8)`~kxfnP g/_O ])H=s0 >~ K+ވ"~fJėOނDmغ|8>|!y{)tk*r u=x!Η#5G*`6F7wL2d"~}&K+КȺ7=oM8]|\q30n3&yv=t! I"h;C}9E4>8YDzIQ;_"랝>ٻ2 `9C Ȼ'#&,[300̾P1b6EX'-vWA,ʸ 7LD/ǃ/Bhdں)BC~>n 7o"Mю>>=7\#2)Yy.N9Em*"("("@@ ?mP%Nf V>δĵGߏ3g"00V"88&MBDDǢKBOL< ^m}!owZ6+'g=<{N~yf[aGٱXέJLE]H=&S0 Gt>l2;7?_|9(Ɵ{s6 [n\>2~oxޏQ93=z#59wd%حC7)}0ٷ2} 풪jWI+3@9?}+BCἅ -n^ #%hMc7_L}G/?@Nh1 [5ƽN>W1_al-㚸̀2Krg`=c~||ВWܧ>7瞅t'l%)<}9F I@ 7dmd9OCb~ȣ{YoI7bpH$"#oO&kPZOδĹ]0a<$C^dMAG ~  xD3kg|1d< ] tJծcdHD#hliV|Ea°v=<8cdqFa!uJ-:CpdA1mm쁽ʹgvH>QŸ ǣdܺbmW}ޫ=[Mpǥ}1,S֘pV;ͩXi`tb 'n{!7a lu&ضIij7&]B6R7E>G]2aZ5kbJq&)gMJǟ'6wUM8kʼܷ %J/iO5t`=S7r+1m[󖁷ݒwh zҽaNaܰ[(-!t?Gӽyw`&VkaD =:Ið6~ÀrkVg\8q-pb+>#θ:?p θ>prJʪWE@8e3Э[7$''c6Uk)(c9ChfN~+,.ݚ#Θ_8;3ә|c;a;y|~ހ-۝{ᕊ<",9Ј޿JyZv|)"4r4oE[jKʈ,Gh(m_=|egd?g94bg,61p~>3Fʘp޲ÅǔPPR@MNMpCv(@!ؽm3o8yp3"("("(UEB8sS֭[us8C}kn6!&\)8!X&[y}~deDڠx}*xx?:O] D|kbM@>o.c-x"/j3`OL-Dr-$X8քY}p`gDeEf䃶||N;Up$˥WXr{=|dR[Qaz1Yw!; F|XWi!,MCҕf/*]c؄3V@C]t}Q ~~˾ؿ\= "|9eδĵ[#7R^xo7iy\}2jO$1fw(E8Š(3Tj:^*ϊ۞^@WSՑkm8^xa173m\u6>w>2Hrqؑg(EWzdUdApFOdm7[йM33RLXr]}< SCm;hAE۳c&D>.^M[I.滍#&hKrn)Gc:Vϼ%{NrHeufs}'kE[p3ēS>ۄ͉MyY ~pуIfD>3sv_xW+ [.6#vӶd| D6qgˍanW#(S13-q8%J\˽3\0Q|t~\C^8Ȝpu~0C>V>kEPЫ",dYo~7k ~q}ssd(qr7Cb9W1('mZ๿Nÿo +4no^7HF\ ̼BLݺt3z87=? >5`.hcko; k3ҶgmϼKAbArʲ N%݀8Km4("("(o7zoߪ_G8)ß 3|C{: < wr/voeNtkI7Z$m,3;Xu%oQ("m)ƹDmЯggsV dmI{V^]ۓ ;2ѓ!Fm8Gg}zܟAyЇ< Ӑf;c-];suCTnڞH:]ZKrK'51tnՔpb#qEPE@PE@P%صӓ%O;ub=9e\G:v9-{&=>O:1.P[W+:șw ԓ8_.Ǎ3w]&˸-g}qMyt@yywȳs!fn m cw\NyO{)xXG9N{%c\*"("("!u=+BLȏ}gZ(sA~@y'O`~4(u#`4NK[|<-mq/?9XNN$Xfm\s9.rNԖp0teͩ:b Yndpg5Ud\N"<[]&8r~}65}9i޴:K`D;Gv>:p`"7c 3'c^E3ϖmrӗIy+;+q劏 7<'8ȜrIBχ}}C]?Y3~1ӇO:ϟnK@'`5@@^<D&I<ɯ+,sEZ$S"҇2ԩ}=RY^35ݤ b0u_r-s\ϙt!q#QldܺI)vDz׮'iO} eӫ"("("('B@W~&6) drcr#wǯ2Jʜyw;RGLEqo M8f[`>Y?i_Z[\d|&$r#:8?4UsZD=Ǎ~T(+LUst9OҢc!u򤍳f9JKKZl4" &N/js[IG>?\A߿M#τ޾hPa+ ם?͛z*b% 'S#zLqhvuʡ|r;g=)e<~6H#+3U:/:cH'Yv{\s?Uu_Mtan#"q)vJdd#80Y)6}ppzu7!28-zpٗ3.e|˹L"("("(xj_""WQӵ3τ72s-ٟ_+!,_Y} ee帨_\7a4"O;?çD[5?U,,il+.)O.eݚ.):Jq'\v ,X&"r,۠ cݖDoqM|#ʹlޱ =:ţQ\uΤ'I _."js\$tn+; xcvw"'zvB?kfcܬaWTTq7("("(,JV(7LºpI&A'3OVU]Ls"mGAyy-7 Qa!<2!i&$K:b P9.2951J}w,]wN[.&F"܆9D8>xdWӏ@}2ɹ^odASA0+gby@֑6_@Gf`ǔ?HT__Lx%"0אg-kntˍeOW|mG{4_>CpԯQ>]czD\㞝at_q+\KdCgȿlU)ؼk?ͯ%qݲKʱ<13cX-b,/N_~"'_{\ԛH=inN܃{SƗqob]X> {;SP} ~w)sr!M&]K+*=zh{ݳXu7ܛ aݎT" 'f.^RL9'cYk:},mۭ]{|rBstb6q([7 H V`˟>{I9 m7ĮW֛G  sm3f ̾MpiθG<fKsm# S tܞҁ'd+ |Ѣa~ضcnT݁UA"UjD.2=~-c W5ɾatCq-|ɴչl%f/.yy/Y5yH! H?8ѽ Ugmۮr:GaC^$ž꧋T=Lm,.Y!IrE@PE@PE@8-`л-A8-q.rŇ9q"? ;~`SԎk9e:m9`O"$ĐtVBBkڵ )bs GW$CحZ5q1yN@nٳ|k|6:/3;zi\C8C3FXrz bD"&4rfR+*h*[&ZY ?~mtqLBhYsXҖ.t=R֢t6!.gd=g/ʨkX'LuR?` $\EJr<;i%sUyg[eb":/ w]0DH^F?" *RΡ*9 *e\jF[Cgv,fē̶T`@8WKɒ{AG֎LW!ms ĸVfѴQŴXk{V! ^yz=>c5Xiy&A悮~pr4_z93*{!RX X91*Lڦfmim9N ٭ Kɂq:;d@;3k&2kmlhҳ\%D[ydqǁ˹ūƁF}"Mbt&8_lH1)?BޑW.BAl"ne,]MMz4  @va 7^z.b@$ZAzo&1o/+AܺG/,6uy/s EZ쀅I=ra?ň.-{xrno͘Cn-Vb0jp[+ MKrXLh>pe:' Mo>z iUSnb7~8qsƵF3(>sN8:?t~ù&8>냮5u"U!?=ik鋏gb8"&Lw}%K`8묳ި7$"l7)lؚd'][5!9Lq~ĉ %͕ikwLX)><`:?`χ>|3w ]t}5=PPի"(Cl0}-/nݺדI;٥܍'pM2q&p0k\?s Q1𡷑[9^=+nl)"G|ƝEVd3r6B[iY:Ytk~Dћ ݺVk/܂"2ڐ+!&~ufnE1鸲GkL۔>CH8VQmRS%94>؆I! )XbnD|}c|O ݃? 0cdzjҗwܔo؍[6#ruRlcuX@?o|B ͵C1Wgrr $I\ qk_`%y&>JglT(-F6-ѥm z#O]W[.EO x=Z6Ƌi:_SGQ=[cݗ 8;8Jև-i|k6%⥏/swt.Gvy>qlnBۏw:P6m-$+BJwM߮$OdҰ)$wk D02x/Lޝxlו:n[pӨn`@irmlsL.Z"t1-prq'`] b\:X^ܼ|:#θ:?p θ>sMpWE@P~#ZOԵM\. qh/9%c4ßad{׼>ȓ+iPE@PE@PS%OS!u~0ԱI&("ǐG1m$u\R<Ӗ (898A"hfsZ4sGأ'Bq_LU͓>ZI;ֵ"ϙ̓8 :fⰵ,Bvј;/mbm&Hevʐ\4("("(&JUG(B(P)Y,gމjޏ]j#H;̓.By>+P^t]KN׬lX%}ˏg;Z("("(J>ZG+ pbjWLEv%Vk {˼$9\Odq^rrgY].Rq}qeM9 v"OJ9I!95'u2c xsSw/&kS.z<YMwGq.g›iL4ԐU֑p{;OʱqȪX("("(')i'"( nN+7|R3tmyjA@~ QLKUrPLyy~j~WϪ0_pssn^9%cE\F~)_KWouh^ۀ:ŷ@lL%"l~CJ*cEM?\͒5fT0~Fص{cYhEVs+7%cDyUdŸlnTUVWco+6 5qFe":" ےS ݰ=y/#ðqG Kg'u&Xr%@-0~X4oȰŒuHC`ЍtGN~>_=ZE+VqLz8g?,ZC9<8ڴhj-\DV/iLZ43{#=+l@H틄ɚ,;#tead½ >-,|d +*O/\6>!Ɵ]s?˫0wr? 3SڄoWnA5=wc/{}:9FpGz%xʼ_?/TNu,^C}>t}xz#PU-7p%'''@ZZ2!\dLM7WN_ଷ|Vu>23Z7>3tn Ø?D˘3LCnm_cܽ"S+\07^_,J{sq_:`MGާ3 yTxqr$zVuae5P\VA_%f}=>4ȩ6pVL[za!XS/VmEPف_ 㞝aȖDfCu߿vHl7M[.6ܓ=lDbCSvNu**~=##7[ %+zϏȿTt=rHܲ d0z Wm^С%"´/Y еM"p.«.׼|;+[Ÿ+*̟Y_-c!-?EDL^V\#v?ݳk~ޙeyiY>LrBz <~(qIssƵ;?<\qƵ\d8:?t~ɡC~OiZʪWE@P~%ӦM}݇]b۶mW_-ņlq~pkl(`I\6w]}i6OW ظ=]ڷ3L#4-ث/mSBC0o7Sذ?Kd=B,~v5)IzNtokg>YRB{[!`&? ܽ^9O^zŷCudvFDL#^f,גR~>x18f(x Tmo 7-D\tX!ً,޼RЯGG\1n(_+Akڌ'/5/lڋ&4[q*אַxCFx\ȿuyxwCřԏ}GsV x"l-G_Ͼ,38(·o H4 / dQxk3KK߱M tUL{4d<8 g-{]w nAPE@PE@PNB< o('7nr%77 D4'櫐3y؛wlO |8&p@F0i}T9Cb룴fFں;W%wbLpc2Х!F9m! ~E_Us/1=±u< ,,-لG޻!XLm۳g+v?6 #y 6Uľٻ!~sr}۠H#l21,ak|p684j;12spQ?GJb0 c;]#zӖػ 46}1ͼBBPE@PE@PYP#ߒ)YZN :㜭Ç~z3r=ak= P:k=7LL}Ԟ?e]Ɏٞ;Wt?vޝ3\ikhʡ,3qUVTƒ 32sbno{Xu+48=yvI5 GĘ/;5 [-`Yj<$ r:/~+d|l T5Œ<",@l %?(UArZĖ=~%ȣ[źF44NlNs1y[>e>|}|]GKL^M7Q=> 1~Gr\d@Wp@,uЙLq`y~|66m!χKbE͟t5`ڲRt]|c$9`yGR3r]#9Vmad1v,?w^|C Rn3\<t~8}>p g\>>\q]t}%Cm @&;hZP<~>ȏ_y!4Kд!sQ)X{X!=B aE40gG`a,(;Fkʙjj",at$;#E”gyyy Oo,nÙ MJڂ;}SջȱE);߰ŢUb.9r6b-J06cǪr.$bFIv rLQaRFN3f~սYC7!C:t4'| Kq`"+e5$܃ DfQuKlܜ5zK4Ka6_ t+j:UVZiv Ju{W0yVP@fW/-3e?nl[M p?rCآ hoH[˞iJұ,_ࡗcˬ] $4x| c:룮BG]wY?Ǚ8_%H%傎Nj9?18!B5%O;竖&Ɏ s9~5׸A|u7SIK\_k\b2bv5[\ WlpޔH\OMڵ-)u}p;JKѾus8´.л9q)s]lF}XEȱb 9Y,Bچk$ά :on;Y E{տлkQfr\g3"-+EI\g/2W.\ďQjseLI4?3i,] @.yE.-pӭꋪgcν.rJb+M wdӖMwX]wI㲫ܵhzѷZ.[zHE%y J]dg"x!6m{,1lMs%tJ+HV.vQTR"OĮsa_q',W汮Qb]o} 2m_v׮^ˤ xƵ2c8tWZ5f- _M`Lܸ2ϧ+A悤u~!s9t~Wt~C χ \Ox^c88wr4d`DS ם?=qy"g<:?N]+r}iDsfEGG#**VHHǺ1L]I';̰22,ftNkc^۵;Ľ1wrڽgr6kmֻOa׆voke>oRRYXd]wVhGbMYWZf+vJbU[t^3zcx[_.\3nnѺ}8>e⫫7[ sgپx"V2aGOޝ-">m0oV\Κj-55Ѣ3r+9y/mV#1G~ ܫENF,AuZ6keJ=ae: ,وi Z Wo73⭷mumc,jkbxq_Pwmг3 ڶq |(? Lgmޱm[}|ݯhS{!}:[a֒JNM6%Z/YJix =;[ee־]{ѹMX^0?aMnVltK3z/+F m pZ_,`mٟe}|$toaՏ w .6{īsZDX^:Fs?LK\x)>5`g\A@w,١ ]?sA}>|Xq˾֫"/9˧=A aVWB@H0&di?g.qvQA[Z)y|rv^ƒ3qPDg1lɩDHp98\Nm[!m "o74Us,vXO0:c}sg'a'Gq[Oֽ0n: ې9hc8ێJ:"93*&;^LpіSL|2 *h! )CpΙ渳O1Z 6kWmarÏ雓_UE'jHsl!iOp \@#mӚAVbضnsjoڌ7b.M9ӄSǧVm_ϗ#bA `0 dSxLq7-46'2RbG%4#o@EB>DG`P_eEW!:FzPh"&l !$Xr~~iVk'9k_QrmGcN\cZWb.i A `0 x֜JAlGG9vd;rW|/%TƿX,](GT=lOCZЍ yڣkrGn*yj ҈ۃk==}QtW#mZ272lvz޴Ӱ]߱By0_A `0 Y!ϊh:g"?LL;n2q)Jwh*9AyZOeO|=k"nT]ytZa>Сz 2w\ʴs)uʗ_fA `0 '_} 1(< >s-Axw*"DŽ֞M,GOu"u%pG:r-h7+__.׸YsӸ]ZGw}waW;2*[]הC]G}Snq w܌s}? ??ßsVAb*G9/+Pr^Ay M p̩6Ȧ sRƆmg6Zn+PltTZzG>G'd9#T/b׷?~N%8&vQ2͗A `0 A pV"`<+OA %`.Jި?]P҃7Z /;~ |d ҖԯMG9?j*9|I$ 6[̻U0a_*WGs9t}G. E:bܲUD'YwHH=v (zT_~ax –*ܾ;s[%LN$o[S+wνT8G <Qe։ 6uSKڼ'G} rĉs?+R {rN1W;p^rVf\JJ[ 8Q,w,(,<`}溝(|m^A`y~2xFQp5>_\[1A0_A `0 CRf5S `0J\?!;T$.88S J&5oT(&9y4~T+!ޚn ׍XK1Kr8@IDAT`{mNc {}VlGOЈwV;}Oe'vt(]ݫ۶eڂs럢1R:5 ֳͧS2j Mm¬4jvǭUr]sqWj)oPva fBmOOHQԚԪI}n"!ˎ?I3 8O'ݭUe=n2s<}V=r>aoś/-IsiUbWZqtu"&#?<™q8nm=Ҧ1-],DcBA=Cƴ`}S|Ãi9{lٶ.jD IiRe'P$цY4z<ڰ71.-nSL83N;=r/f[), n].u '0f@'y̤qYjٸA `0 :E߿)6ߊe*s&f @0 ?Е۲e -^VX!Ǭ,!er?2WjǙ:D<0GyG(:2ʎ{ߞA73)ԺqZv3wԽYmzu=$&d :yO8I64QL-VS>mw^NS鼿O7nr>{/L=6fϸjI k' 17 x=u܄YtՇS]ᗊG%O}$l 0;=?:7Mcn`^oɄ?Ўhk^iTZvukBG[y$Sє]Fr~;}kuKˣ4ś笤2о4IN7*#RD5H|+!8a/N'>C:5woG:9R mf1ɻ2&z<>eKw\N/zedZԢA7cDH|y4m>H/1~ N|ltn9Oص}@juQ< mb A `0 3=%!ZqV} 3 Ǐ'|;CÆ .)ԻSxzhO^ MX>JGw!J +}}Os~<]&WD#-ZQXp513EP@.Zڳ73vk/HծH2ь,[Vn[4+(!6JdD!i؀ @/ ,acҤ{E]ډ샱4hݖLbbTRz ]rj}eUEVJ`'ez\x)tij1!.^_A"!vJV/@ղn-*O[6}y3hCn׆=G+3צioٗm:Ol/Ƅp-1i/abL?D[ wRa/Ӧؓ/jixW®waFǛdة)M_I4m?oݐIsg7|=8tִ2kT︚vi#ӗ!%0 `0 A `8c軶*t?%;vp pWgh3a0~!nBV(##UkP9a b'o8;v"y]5Eo|.V?L7[ݔTӝ jy DŦL:@LRm޵7ɭB-ޙCLa2nyJu 5w)%ދ Wm칇uvQAɗ܍z><.m=ukNiBuӒE0pˇuJأYzwj4H7 WQ} 6 BKVo;e%}D<øiƵGdȋeX0.ǩeX5>Ahv27S2쬟LS.,%>O]EI>'O?+W޼\3twDТ!ՙj no[:7KZ7ᝢ#>~ o&b0 A `D{΍vΦÇS`` %%%Qhhh9]Lg3e0~k?Iï *S/PXE$U@,!x6,AU%dL zt" tMA6-!Z,L1))>F@cYU,o'g d'GSj2iL|*֟ t_ix6YӀ q/>o@ww +!Nq=|`V7qLrPޖNp?/X?<%h@J jnͪln(acB[';,z/DkS tR `0 A `ńtڵ4 oF **֭K-Z5x_\4鬜 $MNY2Jla-jxVեDZZS~A*+Z }mZ<5ILr%FRzM䛙B ŧm=A!@7ǨqZt>o?b*&VUS4tPojӴ>]iC=ԭ n%rrv ~eT?-=P){ӽ5n31B9d#@ C;r~}pC%g.s(>.FҡLῃmg+/^ޢ60ԀqLD(9FiL!lضf,^E͙b1u h69c(2 # Dke˖ѻKk׮}Jq[J[Y _Zxq&n=G.nh9GhHώR-Jз6M/SͧQ j<[dzz{wt("4X(iy%eB|!_6eңTrXo^Oa/,zt wOqd x^j߸tYj\PZ&AWboմd~03h|jO>|MS0o6W|ˡMvR&/*,oAL)O9Vvύ?Cq1-d%+*scL̗A `0 A /!s_ek4%%%B s&Cz-< .نf](o=3}AmؙT b<)wqh)a]̞zZO[$iR+&8$1Ӿau3kM_2y'=ۉG56.>b‚iKim;oRxe4cF:TPLu0{|ET3&֯-zwfP^7 z ?IּU[({!natT8uHf)KєN]ega!YVRz5(1! C$;";Kbv_*=#vhрZ&'in& ]}߻wÔeԈ=QP7?<W5GtZn;}2w%lBw]_lLKs*ט]e<A]% JզjizW#Z5N/߯%ӭ6C LĘ%4kzZmz]/dDCʐ0_A `0 3q~`HJII HAcJppp0o~:Tߨ#gJc8kQr~$uj}q569#T46 M -q=A?M/CZjxpgi KD g/<ރq>Tě#0Sb94cl!7ӆ{WƤ1xA<0uX!#rي݃y8l!AWyS|D7.+o =WG$7@zR< -k:'t4o]1ӄc{2x m`eӼ[SoT6_A `0 B@]Gi+")%%EAPuV!0[$ ?0DWW}`R!8M9P0ώ\pz9AE)8qds r GƓo ,cN;uʍ?GDwta a!$Sy{ż#Rꔣ 1X3ɘNŎ=hڭ[,>:r.+D}./qQ5Y rؤ&o_'+5;Aʥv?C9`ָMGDŽ}cŌsy>y _?pF*++ر$Ͽ'OzRSS鿞a9 FbMtOH? +w\[<rM)F᎛_zq_ 8{C9}B24GԕyE(G(*)jDZR$HqG-[[3WCĢhA}쐴e R_r$Q!t'A }Alw$CQ^7%yZu)Q]^L 9#ףּ}>8~9C\mqo洫*AiGiWҔ;)&ޱd1Ccq_30spqs0^[/知<~k. @!Py_AO\Ӂw@4jA `0"lCvT^F!s0ޞ!6B@#@Fx09'ɓ|Лȶh]Pϗ9Ęa9GEmS.GOx:m gn|3&WɗGq:Y":09uҀgΒoJN볠\(Gʜ~Rv}Vo_"^{\v5\w5|׭_ˑݪRoB+,,du9qt{ru>|PP.UDZG}ڦq96zqrmQN?mѴ;žӵL>|kƗ_{;cw;n=&q3> yꛝM؃7~B(%HFyU@`gsQݻem@4Oǫ״뷜T5i7| Ozq7$va350tQhvӎ{z#_hEe2h!i;mM횆 P_NDa/!~iw9۵w}#>8__Nsz)|h|(g9w޴&9pnN ۃfOj9D4>Ӟ9m[QO^4dNw}as=A ~`~`} ꮾR||@ACW@y{69feހX<۰iL0 9#8eX)@xhvu=zpAux9Zm2~fev-'NBhlcm T?xjn>w:CRCZ#m38ݏm9um9dyݐ:(7 `0 A [pOb/'{<<(C?l!e 񞋠% ]PnS%#c0 zcw&P9+9\FS-&-Nt)J -#?%D>4e_I}hh\YR.ӕ>=qF\ћEA魯ht5) 6q9vkɩ/Cte=irNeEZpCvu=ہ,gv2'#΁P{mrr׍/q {zS&:b"%Cv oPw[C[zQEZm-9|JJSTDrڧXLqgwnla]锖O=m-"8 Amf/s.2*'rQj A `0 O5))IskzaaaTn]x %H } }Uu~M _S  q?nuC #G|CW<0׌^k~Ioy_[@?(DAjC We֬ `gG<J:ZՌ 45mPu2w%!Jsї9ĖMVԎGw\.+;FoSFx\KVԶ8jݮ}djzh)Ge%;2]9'Z^ЎI8n߹.|mgމSMR~|6S=<<.0BY{H_m >2^5{At*zD] A `0N=8((H6$~by?K @@j86rWt4b nzTi< rpz4tym%i:tɪE;S4{jɤ iWF\ُ"u@$T$$[c'Rôt%=JS#λqP/gj̅tؙTIuytOftu0UwO}i|c%<ݺ虽(x2Ňс2jM^_p},ͤ:1a_B=$W.w:;=K7n[4jۇP~A1=DXVN!-ۓG,ze%ԩU>xz4:/#C3HΛ"]{IYEuy|l~mBw]`^΄0zrX& Ӊ/Q-`޽%];B  iwPXpMZx~=PN~1}6(c/6od xQQ~i ¯Dߔ뉙|:dLA `8CHۥ}…'_|A1eddȍ-nZy x;m`M! 9YrxѹxM~9]>ѓ#h=Ci4٢Ä{S}gFEsS]Lw^J=x5el[hc>JeO.`ODc.Esom}PئVuO|A/\o1+I+h '<9Wf<|-}ƄܥkMӜ+1 i冭R/}Ё*=z{,ޚ;-9=_֪!PSH>8}i/7Nݬ]9Ћi)#DF&F>1>z#bOgJVI_z>0h,zﳩtɮ|OcF?{']ӹ1usp;˷񋀽ʻV ]݇<5R# /vlE<8/]Ў ZӶh=\n};z4;Ӈg_O VQ`-)ɿ VЕoN7[^J˥~){\&\4//fs=;fۺTeڲs?Bw~+[k/O3Q%1͡%;'H^I9x^ۦtuԼf ]ֳo0:s/}3sSV6 A `#5$iϙh هo9996QʞJ_cϯ5I#c0 3f̠~ګޢVZy?8 Ȳ"&vYX>nG<ھ> l޼_ejuCS6`=L|j`;*aOjJ&.nMFoHG`bϮ@:{^jkT'I5{},[F}}D7ŶGCD[mĞeZ-Q<;Ş~kӤ>$d%rɮG_MU{tyFuu[_jӣ5Ƭkh@dӷ3﹣LƲ؈{RڵЧ3 /l]\CWx%>p]?jHE6F)^]jT7^boFzwiF;lH_أxѡIQAi85ʺK&FXF_֏lݤ.ehH2ӗ{wH坬KSXclwt뙜L4 ޅ:~dMLLM8O{NM!o'd&Ӯԥjv>^6Abs4Th{dUoE X*& `0DFF;ŋg b.y׆SJcx8R䈿68)ҧap  P+q^;yG ԲNC&B<O2QtA J[{ڑ%L6anzl8^դ.x{x.z,"O-cG/;q|/꬗mc5=6l͢)4wfSy;!`}ܢNR/óYTO4Byk%=NE\fC ÙlLA)BiDЮK/:ֳwZ;_VI4UNx1aD=yX)|:~ 9/ Y[XOH%'xC~ɘ]}{24cxGh،wlzь_Eٲ'Z'2'dwRhY l7dj8t~d*"ԴvM~Y*Ba"`=&ϣm{G~i⩼6XW0,❋DWѤ+yI |ae,>Kr A `0~߹=JԈI-cx_t^~g;Tթ] ~$!~#b_7#Љ2q&v(u~)~A)7 3kB\ZtS*m ;j̅txʲf ;1Q2S*0-_pB8NR MD2y= R" fxa=}xC/j(WOGx _zx(eݝрh7 b.bLǸ8O3Ұ i7G661eL6>b4n՗$}a`,|zun^ 1ÔH;V[| A `0T΅]oWwB;D?j2(}BK2i/w<ט;oھy{2LdOecLBZ֭A\26%c+էLĮG?o/;ƪZhzw[4{r콈w52IONc毕i(?x:?&-X/^v/ [ GXzVfLUZ=(S9+PNym1u?y鵨oNס zn䡯Gg`UxzL8?2ЂoBrtwFtOѭͻCc<|u -Vw$0  yZr*-_Vo&6 N۰Ł@7al%SO_Ԑa"dy& +׮L_+dJxڄ1/Ѽ4lOžovUȫyy?P{ulِH̛^d}C4[:m30|~$;{=>`뮼,_EC.ě^줇>Gs^bdKEcXvr7mVTq~|B3Qq3(%2Rx^w/=@^ۛ"y< qpxA:,[LvƬ3!'r^26 jS:c53VӸWP|⚞tmר0^ׯɣE3ً虛Rg<^r؄U[ͤ]M=WD&`XǞkIYkv^wSzÛa/Z7i\c Af>4&SWƫ{2 &ڀndbhd6}Itڹ/2!]x:1oӦ10kVtnxB]؏.62rƞ3AݛPM;=[MsiM$6mHKJ釭{XvمԣylPӤn`T*Ԅ׾n-G_^ kԗ-1V'~*e콿Ϸ/7Ì{tׄZ1kRoƂg|iU9<,q9xqDfh>H>+G'Hnum9mc%YmNE;XX $dA=2Z6:g:Dww7#wc%_}Xؘ!scy,`m<;W/14.®DZm }>GC@Ծ2hSu'ZGt;z5iCĔg@11c\`<t,lazjټیidнqFcc최8@׬jժQ sǘl/aw]Ё[V#I9xɃ@(Th(Ab>C69i]Q_?&\v@ "ʃhb}D@ AiNeF4->~=5*bmTiG˵O JyI'_2.lQOrۊ"}_*-B `0 A? Gh>7-2~\;uyJNJ;︃nƒGݒRziT;&f̚Eܻ7j?٫sn::mxfm|e4ua:3L46A 1IϿ/t5`b߿_ȿ[nr8eT! ( oEN~"PW||\|i/*'j'N|!m\ʀ]ז kīgZ4xAd|w 9/_GT@4i5ϔ|t,ỾsH>h@IDAT}Cǂ> s0 dt\n߱gLe|.ܠ~} iNiۯo_j͞WÇS]:r;oO ث}CxEhq=e0#p3Op.xWCILbJr8\5_juA<sЗPJPh)B<8kj_V,Le`YbyЇ-paEy)rc_L`zH=Z|)6"CMKU)\ise|PG 4׸}TIeH)&CQqUT^-O.>j-w}w>tzۂr#~ydE9 m4!ִ]צՏ:ZUH\ƏuT6?-wh.Grn2mr>r%y1q3k㵤|ĮǪG;t',An q?-mv:5_/ynYw܇FnLqs=&q3>0>>ZN(ӂWbM4OLfo_zI;`wB5O0vLa Ot)ƇDi.iǎ ;1W 8`7>a_XXH_W^}[kS&,Xo g"v`5^P !6ݡW׆adb (L8PB@Η*|:Nj/O^=q-W{LZHZ~|U}is(5T^hnYoVfG݈o[|W'!sR?4x1[jW_;< jBM!.sFRHP5 qZ>u_Tz;Hy^lt$F [NWńkil/_{6M`y 1 Bt>r y `ȰdKPH (p1ĩ e0Qӵ2w?M0@ A `0 >xs3 xfeeqCQbb"?8ev2U)}9SnCI2y6cll(bG~G]LSFڶL pĆ!Xo){bo#7XQإrK0p'_d><ta)(k8・]Yj# nYdLIIs畱}9yWҾcLrGFG3Yʑr0k*z< )c z/N;i )PMGqhjrʝ25'\0:Hn`qICV??W_c{K{m-XRP;:o!rV;=O}0sS^O [a^QƂ_ Q~ԏiN϶l_Ԣw|>I(ZἭٸͳ@AαW*dϡkch3`ӧS{^|;ksd ԇ>5kX )?ɻ4IsaLCT2*v}>mTE؆uZ<\BWi[կynYwgƏyrqs0s0=?'y{s\޷0VXzy1ϴi裏?aμ'M7|g„ g}233i޽~[b#;eIIdr=q_~9}4r8Z~L]|mƳxϨѣe3ik2O[elϗ_&~W1Ww1M$>HўKjJxqa-h{R<4~$]UPl0aiK(o9c!!)ao8Aѧ}vZ/קi9|`{?yG{`UnޟGGؓiUچ,kՆʶiVr=WF毠 ^'Ռ<,t;'ghO]ya{Y=̴ņH˙KR[D?O[諨|Zh/R߱_m#P!(op҈\pD*, hGS|||Xo|u핻|Q$18- .0ˠq.@3/>xsv|:eRDNnRLޗc%1X|gVnqg\&k1aQb-:HxS<!boQ0-եبp8!zvMM%3atg[ёauJԲښdzqNVUiڞq|p%yA $h(k6gڴo߂T$;^Z5cbZfgcezOJNwOݴ$a!դ]{b:9[h RUhYc**zRM%kݴvsUJZ5e<`@?A5i5ϔ|t,a_/0&u,?~[,G+@&,b36׼Y3y?|=mZ?Cz0ݖuX9Τ >xߵuZLyΦ<]zs;wPӎF`1ݻ{Nu" 9SyO/,6!G{ g҃MF.ߟ(~LD9봜|6USj0C+q"+k$$L104~vvO>]r \M_9M9{%ӹsŚp0>5H]{XN^d;bR0"8j{ocуWjTelVY+oYMXDE;wS&u@DY n}n5o]UX\b xժ#hnjon=J]4g jV焵pzyVf|l>ؽxu)knؚe=5aI|{NhU '&X̠֕sza"kLeڼc֭ocVwQӭj3g=X@)yt5UϦXόlްܗKM\BYNYAL&ٴݺśvY{shUZLRPMzݭxaLށ[ޟb6?\ƀw9l L/-^icJL'T=Iںs/](܆mZLYN+sX҄26:` h*5 b"0ڴ-Q4Cc}g/sSziwN KԸ9y6%-Xy|i =r&Y‚'#)ZUSˆ _E-\KQAUWmSVhHaN´tԚ4?zwN4 FƫSFrb1~#Jav֜ū6cg;*GIPB{o"]7]ײme7PAQ({ $$J{{7mpFs|3sf>%ϡ#;B-&fn}勐бXfswG֨]0Xyro78E˘{>>t-aχ"kAׂ?Y'`$vR*Ur8IcbD|Mȑh\=^N_^Co z2Oݜ]򔡾O9{gzIԱ/~:=mSƿw]7~__mg`8<9۾:v"bWC8qw=f#ZnސΓf}7 VUFhD]e0O+H<]ڋWԹ}b(^)Ļxڏr)Z6I/\[^MFلx<7hV"'q+#.6=n-Hܷk20ѼQ],_}o<g\9c|)!a܇nB#_un;+N=+Y[gş8^`|=nɳW~DV x8|%s+_˽4HX*?&Z{_3:m]vS"lz{T-- wu :i[]/ዑ-IEX̭HɁrxoe?]rk{!-CbP.+&g:oZ5k!&`4Lx@ΛWo@{^Cupv.raLߺ/z {E㖋v*?R헋ZI 5_"^XpU PUFv esaej&1}18"cMxa,HlS _IV|7k^wxŢcpCuS7ߛrYMۓ%3OňKp˙ѯ[*[! &6?YOmIyN[0艊˅,74a2nIP?y 8yU$=y!i`Lyv7_^FSr,.pѱuz]:'/W?Y!`!`WߏÆ%Feq݉,k>ey,S\mNt[*G[e>ZXt,`0~ zl~3 C}sƮ=y<䓸nP4/!hZ˷#MN&]z#:ׯ*! hP*ۆ黱zv\۸rP쓓vڧ-CujѪz^tzo*}.TPVpuBA;]x#$TQBעIRS>{YM] 0Pax<`8-կ1 NYErq8W'!#K]!Yzg/Z?ڕT\u)hf7"P*QG7ߍ|j;~дZJ&̘B }uWmٮ!`!`[mo<˂^ݗJQ ʩcE+kYVt봌WMZʰN"!utFM0 =SӦMd Mp$xOv p%94kr,Xک֩Qّfܻlv12WzUL,nnu{dOeJ30Bn+r8 qI(R,n9 .I^kIvHx;Qʮkb0:8(ld!=\%DD@!veGꮜ.<(c$TP|K<{[1!~X ENx޶|z Ľ ߸jHtyqSiɶQ,u6Nڜstkyysxe$uyh/o8S9sGx9dp~wcacY!kDp&wSEB^L"g{PvsN[ ]fܑ{ <,KJ$TBJRpG\7GnҎ(>zc|?s9lMǮ}2DZn^jgn8{=?7.X~q#vg!`!p|nVݗ0~Sz3boMFVL0g Ĵh"wîٮ@^C?ßyKrJηH"&9-jt9Iɣ\x9%lxk*dI#\VHHqjA19Llg5:b}C]}!Ci rAb=Vg艿]al-_^xTEw ѶE#G /d;Znr`Ii2sÄ=DlþBI-8!أ_dȜkgz_$\#ԨvU;CpM'1ȃZ(9y1?:\J[FLͭ/)g(T$^,?$82&E۶w?.&s*_C;{nۮf O1; 93q0 C0 C#Ğ,tܔʕQT32jE6; 鸐\DFE84Ŷa?5 2C-f WMZƼ['5+g}!C?ǰax97\׼NU|l4Jei9t~y.G==*&%nX-n.ص{; ҈/,aeO㟟 s}ե Pۛ}Ķ QRB;?l/VODJx˶' 3:rKvA|6rx/`ڍd?r ℰw3xZW0MBSu _- IBc0zw9#8lo\ˁɉ^;6*$h1c* 98,coCi=6CVxX7U+%7-H)wB|ΘĝK|/2g=2CGwH)=]+iMA%z̥Oh 日;21~>~yе3z{~tm}p}?>y_ZȬ  VῸD9o+bv:HJJgD<]î!p!7>~K/=j|sT_o$dHlթNv՗}Ib!^ ![tIhb[;!I({yӹG~ eNCg(„qHFxS/ Mxq|x GfPN7y=ڡޕ}Fz1|" _4wf`\zvWz*QE߮p8qSvb=Fڊ\-^X!:'U ck^ #hސ brnp8Wl]ߣ%KBaHpa!WXJowMɓ>G)q޳C0ZH]< v׷ ݅Wvq{LR! eB'AJV'*]v&8"m19CK))'7tQ?}-|tiVoȜ69mݤ %imq#5rt JҮ%C0 C0 Cݫ_Pճ;ر8_1Çѹ]kP胦ǽ^jYP=,(f?=&KVۄr(Cir9⍵tZ$KYufbJ9U Zc~x+֬GxU d:@[< FdWGxȡ$^ɰaKEMh$bLl؟&'f^!R9AغrHib.vi黐Z#vJ9Ixݖ${c3qݸ `WhXׅmIB+yv!;n/rn,}VWBg/Y-Bv͐"*&mr(KUOtrᾁg- 9l-BfǴQ:eGVv%^؇3Êy COWȼVJX8y2+ 8r?<}YO6~e$\/Z^HL;MmZ,~إ9mwT,8L|WUMTsϝO2b)sjNwcy27|t-}[&>oL=Zະaχ??r4[ qQL | )S_4yҖ(뽳27|t-Cx(@OtjJ"p[y>yֻg9VG(/J9q~YeWe:}Ͱ~ŵǷ_@U~a6\=o- ?ZۢH~@^:f/3aN{Ge m!iQJ)s~ /b^O!Ia}/=ڛ\<:&ׄ[`~-]7spRGOt>ֶXYu4~ߴUrZ:bIR˻%}MON1eGz/{Yx [|;{&׃??ct~1<1YA_ E»tx0r#@>[>B;&KC '{+˂Ă >v55*G.91UQ7y곐ee]KgE]ԥ$"2M,|+`9o:L{nNAN[CD0{eװ;wP^ˎG9[Ag`_n[KZ]g^ C0 C0 #O:8%?}S{UCA;چIZ^wWb9C]yTg#-(ä:]Ix=Fe}a5EʼB松PWyr [ ;['Wk;PvhZd= 돶ũq/y1%n|A:ZF *YNNm;u$(y)meO rjO5OMuSNe,sƭTGoϳyt_4~3-o*\^0w{_.!`!`,FNu81 ~Pz)TPSjr%$Th9g0BdN -/k?vt>Qu>gFP)ZvA%FYiCun;ZXMMtٱt S0,T?x 8=2h[U#"8{y({1']6y;:車*Gsº_hИ!`!`'(Fk2PW&,,XͱdYΤ8ʃQ.e~M_G#΅2zV9iA؂{J-y)llj]uHmre(uYvUEOབྷZSCZnWC0 C0 C80Ğ_!E HD+;JyU/-}-_ݙ(^(*%'"N $MpR]OY8aǛEhGQm9CAr1˘VӼщuVvTWˣUNk2&W^3s0o GPLP9pzSWx:Q`Ze;rr V5Vw=uxO+gSj^ey%4NeXl5\U=QF Tw_ݤ)!`!`1#;i]3 -H>(ArC \xZ7cRWApFN[y #Pa6eQI/!lhǼG3ڎiֻӾN!ʂf? G)`$ mkOS1}j!ڤLAG-izxړdNɕ5wZEE& l+'7ZV.[Q!AWJ{G)ȯӎ%C0 C0 C0# qC@T#Hl \Pgɪu׷ѲzV9O}^FyVddǀ'>ƭiT +lGPFBE S=ZWU;5"trg[Jv/l;?oQU{ny#GGxUyױN/k9qsWWb9P|T_c>>mma1M/y/#ٌ_!-Y>6IXbzmG~ehqKcՆ?ORƽoIr{ucS~_՛#;'o }U]N]|2G6O}K}/ }z[:r%wBŕ*gc|!#)GR҇KP1 ~ nz]lPןz֑{@Ypv'ϵßAy鷸%YGѲAML\ ={5ݔ֗WZlp ;-pX8 LĭBbn-;\0w؋!`!`!`;i %Wx[oZkSOu(IDWA=V; Bib(% 7PI0W+.US"$8$s|G{4\N;-ZYNmgR;`$Vԭ {;az8SHfwؑNY?յ &$&ڷhA*á#3o@8SlW(_1R֧Em{mnƌDx<,[>xZ,T \w.֭HOOMR{O#"صm3 YHیrF BCLvF8Cߡy*:=to-ua, usupa߮>w43H[L5+''>GNPB"ekS\?t!K9vR_S1o`yiZ1fGo<dLfae ᰱhRz\ sp텧9/Suڸ^M^5iɰ2 L:ARb9={t\ Z*Kw6VRR^SvÎ^ uVtd}^9~ycg^ C0 C0 C14 !#ŋo> 8PYcPV-|'hѢʕ+Jha x9}8+O(BKڛ lO@IDATSV5h+$`U3PF"FE #v\_ٖ!($T ֮#(Ӷy4MMt8򏡴sG*E<6i  i5WBIc!?cofwj)de 1OC:+{M 'd,j/$"6ˑ/ & e7ހީh̳DzOw5$ܷa+iIqXQXRѢېGJ>W{mT4“L|֯*{Bv7ނjbCL:))8XtdػY-ٸ 5UFؾ~Xu#yJJ_ۑlῗl! +'̽FhӬyIx7i5ѿGGz!F֙bq C0 C0 C8x|4k! !RR%G$wOc&^ bŋnOX 0 ڄ5*!VŃp(>!zHIo@eE< q֪I}G"yEe+P|ZT!T:+c3bxiLXŽל<IzDb8p&hɥKSrI;bĤ9ȔgHe''W'`/!`!`!`'@Zfև[=hdF?Mޟ #p)dյoY~unv-1Gi%s%d%.{޽7' -[ԕ=&a@88/WߒUDZbFF,BJI3i~4t;V\1" 5ѵͽ>QU_B!^P"ޏ=4«ezyyf!$J Cfayrq;wFG.t5]ȱ2O Cy~+gm7 "M%W}~c "^rϰjQrg3!.th?šW`GУmck6'O<nCsSoɐ~93y?gCkYëA׊k&xo~tm}pև=b\χO5F@I.~ ԬYrz@R6#DcCuch 3gn#wQJm\&!L_ 3,)IϾa?Ae Om(@ W^y 'k歧xa+솳sc^JZblWS<L/eϋ#Dq|!p|ׅB%9 ZoVu1kV,ӻs{W.7@ŤD@3o$ÒM;q"Ci{1(')Է[[S<]\׺6Ʈڊn5p9$\ m֤"v_ l]ڊZ,9+Kxa8%97%+}|]/G⭹fk:: VŻ?ⓧqqЪ[;#/'aIT9}k]z+Miѿq Yw:<(vMRk㵧EsM<3w^,Q!TMIŒM.E#EP8b!`!`D TO\pĐ ׭؎>ZHW-~{DVϱd&|a` ]iۅr9c_8!/:gn j˾|ܻę;C$hgɪӭFd}IG-\$awkxXf#wjPf6NO:2tO'SeI+]yJEշdzTIND=!b$ܶ0lkfx3"׀1|yъ#WKnd߂t98ƍ*qx2.b>xy^{O5|,M{>>=>Aׂ}>}>EzpG YC4Rf,{5?>d?GЩm/<ˇz,gd?xO:XM'TKג/Bw Wh'Dt.Xڧ~qWW?Cqj $)ܿh@rY"z\^>$틞H<1׹bQZ[}ٰ>u~a2'yOdxqew㏮WRV՞kW-S|Xm>}aH;lk|FIeE;'vҙs48_q÷BYcpT=cﰼzY&h#:O׾2/[u;)aShyʱ3lW{^-oxz `σ=`<`C{y|(y&xٽ!`kc(C$L*ImxrNʣDDi:j髂y|}vk3r%z zZ=o0 |ː$aLzGyH߃z?ogv_hsF tdC]POZjB8_'FPV U R-8GA{G곜I ,;ubg3瓉~9˂ǡ6|Q!`!`!p\0i C L  $A ۊEZ,ɖU=>ݦ$VP<}Uu k#Uݧxn[qBB{NaD<",X6iCvL5h-ޫeHi}D/CY+˘eބT[sζyG)y!`!`!p<0xi C @DұH|t'~O=˫kx]=k$m D@ '֓dUN?\AU_%#VƺcGr+&5ZU[zeS8_: y2Vj0 fh)+1 C0 C0 C#`, DJ a&VR)aJ xv6C^r^U=vX G9KVEmOýqXs,mV,罶K[Gc_(+-!`!`!p"#`<6 Jr[F-(9t!LŋE QhQΌ=2o RkUC:äu|ftnXP26#%uxr#sd-?J˯*tD1RN,u|IxkӷK|@Ƶr"e92W3 F:e /\$XUOK߅3bQ9oraܴ 0 C0 C0 #O)pDĿQk7!αuLP**`µϻPLkwU8xpU,Nx}Lmg#B9Gfи#ecaokZ:9x}6KLFJr-[2 C0 C0 CDEȉ:0!`Ar_Byթy*nߋNXz8+6a=<{_f,[?ui ro1!ʔ.RNeΦcrvنOZ>>멯2cg[ֹVY;(wZv^Xq}(Ws.fC\ޘ7]r&>fNL$,rb!`!`ysl#4NZXUɣ J@ G`㶄o_*'۴ $7c^,X oz)OI*f? .*^g#D . 4qĻfai հj.9֬QR`cwcQTp??$D̕QٹqM)r+V˘sPbyUqX! SZS?A,n9'$bX5=_4ClBp ڍ!`!`!`'>N! CdE@ u֡yaWٳg#))XJ7 q 5{O6N Ƶ`JuBphXI=, G#{E<0٫p$aCѝ_CBk$i!ˁ#TG2]`rx1IX[ Rݰ ,!&,.Mbq+uK~1ܽ#!x˵p!.m#N<,~\dG'/]R,6~ZwP q׸I (P2'>n: 7^|iް.&Z~;{ ~j*&^{jGR%2? _ P@D֭*7?%+9 UͯWj!DCHR%cCl>?[C[7^pTq}:,HQB}hhMoZ)Uoܺ3rI1[$/͹ŋג= :9: K_##*EP'ϗ}B]QTN=?cסSs2$YK%K;4O ?n0ˑyGy]vGZq !VwڮiSN?7`>-^,TNapi.9%x;](ik&?Ϟ?{> ^[2 CA@ȇ֩S[lĉyf <e˖- z">^r~XF+!\'#Ã1vj%'Hlyό4)aēNa>^X $V~j4.3U׿KWcxz!;6cے7?W>5 T=_WBfq*nޙ5+9q37;XDj#xjޮ!`!`!`MHmp`p{߈>'(JEߓUS^(?"|<9qC҇p!%$$^BAENe!%HXohKѼЅ;OwoŲqZ!9kSllذ5TEBJ[mT!7FebB|5'^BIm؍t⡷E堐 ]e}sC /D Ƿ[jSbX04ȞPuPb~ՔPeCOD竩 CWʉ% Z IaL֨J)zO|5pR1ECJjW,-!BБxol_mRt[=EJhPjHv&jK?=׭؎>Z=ziYt k`Γ˴^t~Je_\-@^ۯX1oWǓzHH-Oe~>|,fl/UNNndfTa)LabPf!XV-%ބ˵ϐWRFǕ&#O-[:).ծVyy7HrFGPxQ "׏ g}HT=7>+ WN< qn9a&!~#;$!AL?1*%TKIvމ:{ OO.qF^*NVY3OgOеy^֏] >?'}>Z||>>(~e5PB X=XuqQ[,αY-[XYP"mR_ҍ=~mȰ[ %]KM1 ꫂWXݯɨ. z>(yѶj!`!`ɀ@! 'Øm!p!}kd}UWo#Uʤ$T-%eBX<w[mC8;ayN6؞oĿh[zUV^PC 婺k^K~`[8H>H|S`]Į5z"؝!`!`!`'Fy:I׫7H"+vmyRE˧զ h9Iפr։3t^qvz 9,/=7^{E?p۞mDQS Ehl#yY/o>|f~k֏zl}cϏ=?}@?l@t!Pk!Y!/C@?@؀~5s}|{0X7 C0 C0 C4 @1H )6n1 ~\{#Ia>F}gy jWP"PuYB߆UeWZW`5kƱ[`X}rC0 C0 C0~/F^L0 #$D<"a$!'/azנաh^mr!4#P:6S{^a^m%mic O{L絀=׼kv:| ]Yp,ζt&m@y^_Z:K!`!`!`o<ވ%NۀMxZ۾s= };B:!^G#B"kDG6)`g=uT/Z/BE:Gi29iKڒ6\ԷCt}:,_C++8#uyv({$ߛc=i9:] C0 C0 C8x5{'c  kX2H:/IgfÝz5txRmRKzs6+؎Gn1߂w_#x>Ցtco 7ޥ0`{g!zy,#e RNXydd=eyOz2v5 C0 C0 C `At C8AG<*LE(BED}>[buurrQL-m;TBy2I+ 8t0!TIžl$%CR%o?wAB8$MR i;3PxqTJ*@AgdXgqr+VpgDVv˕A|\I'ܑvg"!>)"y#'#xWX1*aÇ {.JClLbFV`\;8x1d ^Z"!J88,l"d p]A Jqs2mۑK8ϳ/}(/Wl\:ڲd!`!`@ぢ8v&>iRH׌>x%rc/wW"]Nm+-D^)GZ BI|Hߍcmxmz<ҥ14f. 7[r<?:lYn^<SD\"׬:*''bb$TM*aƝx(?O2pAj LԩQՑsc' CF<;YO}Ӻҵ[,O,AƵPXW5Tr0,Y~1w\.!:/LX)ЩAulߕ}:Qx!ٮ)ztl6o߁>ZՄ([ uq=ѦYCޓ>UzN`㽡c0bF(NIk:+#GHac&3PRBFyӭ#TsgC3[G:Paχ?cbQ}\8`0 C_~x=z4ƍQFaٲeB;}wmzS:tq =30_ /MGqq.v2.?qޝ>Zԯ qx'[xLjz^ ~:'rOiKa-~Oo,ވڟ1 N=\٫->~Fv+._Z4C0 C0 C0#'$<О{`(&I>=q/nG翴^'%>\7:\ _5}o xh}2Q=rR}KʏPY q\oKKw]~J 5/\'kfn^n _zv/./ 1?@^heu>zjR~ڳяotgoRWz"n:C~.m;Ǝ=B8'tep9Rh wgm(T]$L9'˹˗w*oپ}tn̍/WW/Z(NT6T"օzN7䀕_M tl_??",X2mFػtR Ы@nQػu]w-յpEЋ{% $!J}#`wќ̜3g;wnǙq\^-ȹz@ӆ Ze'/idƦF~#Uy$ J>5Uu%씊FIL=3ߨ\W3}z:?L:?~P{'=?XM[$"Pǃ"PM+>:>܃zEcwV.ǶIje܃\<%5=}TrVώ8,{[9 ྂMd6͒{}ZģTLV,x엕KgQ,}cƢXn[ P\ƥ,U蓽"Bɡ!྆BB6i€B 3w׭we@C]߼zc ^<5mP<<AǃA@}xpχnt<Ѩ?XM)7F[^>v<C"&I򏡤\_/^ EVl $H$^< "Z5gg@&~S픳 W&(L#,uYY['! ͡'sjs%O]KYwٱ`NuGrzrѸؼs//݈>\y_,>jԴoCφ}t>@< ~A @qE@P~1b`݈V^Lɠ[%$^xfk,s4$qn0y"H1k9QDYKѫK[S9g`XG1xoaE <܌5'5Z$H9۽g<, 3S䉺%زsZ/@; 6uGذv.ʒb+"ɿdpODrXsɮc)~|V--%#[C?Xd2A<S|t"G嵿:݅$`X󇧰q"Wۆ^E@PE@PE@(}"| tW`ԨQ^‡`yG+?Ⱦzr ,v p G8nH.zM="͆܂bD e(=oJ>B N{~ 5Đgß|SN3_fO/钾ZH1 e\sR礡MϡYq=U<_!vy=BfG9m|'GOO.44o6_W& NqP/2`t@q,A6+G VN2~i&y:C$޷>"B2t9n} <$$ʲ`\K3 CFVo؆uI }W^E@PE@PE@Fv*/@y9AHIJvԈ"5ɞp<ԹOMcsW>~a#o%ǐ,e\|\KDrbw1,=e\Z۶nth#Ye%h :_!ɬ^qQ T}߹d' c[z7dBCBP,cujaHP }iJKТQCϸ&B Vl ]Ai݌ uLAG!\Q76l9[\o`B|HChZ97cK[DLA8$WaU0k3GG} Zv]xw,%&Jպ툑%d![ vijg(+*Ĥk~~<3n!ʒ8었[sar 4W3ۣ19ܣnX#w>e '䑜dM)2iSťT/(,XG'2篯}Qr9.? 6]Io9KҮ3a}'wr1%mv!icXv4tnp[?+|mwtth`V<σ>>y7t~AA @7"WwUo_H]cKM:I~c|sc2&IıYue)Ȯ-q%>c&SErА`uh)p0T8Q˓e4?V*Ln8ay "("("cضU 88Ժjy>ǿWn㦒vLpRKzi<[i)UN?HHy_)ﯟ">S>b౗W}5M{Tx8>9(8cl*wR|t|gBXQG~e @Ã74mpG-C^^r@Bٗ;m,rs/^oJ&xI9=yq)B,3r}hӢ~+c7gSF{/r06=}ӭ۷e!_},oC=>Ïo3>/:~tg}~Go;A8_w L"E#!dwK cem9o㶼R&EvW~u5i??LۼSշ2[ߦѴ"("("(t=)"AW4`rE|w4 @969VV^ oa0O} @IDATPQY9VNĥSm5["&3)gul5-r.Cn6Wy'OE@PE@PE@PjJֆ}TKFdI++wmuVm܎7>*9+䰋P9:7b VgW;6$`}W™QCFʰd3=d2M[=Iyض_})m˚?[kkr "("("Ԗj?E@_#@X[v*;-37 ]S\2. =Sqk_g"+S:B <{ J򏡤ۀf.똲M1Nǖqc;.eMٰYmx$cuj1RE@PE@PE!fkWE%,,喹$򺶌EC\L}wvvSu1n|$!a eY/CѱlޱG"1!&!DN%XKI2K&% HڣM 3wi(18ZPFq1\ċ]uLBBMsa층x֏4Gl)#eӡ<{V].66VR?\ؐ;eD$77ve("("(@mA@ r"pZ `2KLnYJJˌ׵}kkCgKPE@PE@PZ6k'LW%mig*wh%콩 ؾO>6l@TT󑖖}(,.jq_֡bKc, l9 m5wSWa4wW/YAC<6ݴ=a Eσ í/,eHFAH p!F0Ahu3{FEF=pCcw!$] I3M}[k6dl,Ko8;&-X (Ǵ {E:j[W#IN;=_p w\LJ|w\t~=':?|A @;j(O@I[p!"#=i|ٗq2dGDŽh!  +#0R\W9C.s ~FR_\,qv((It#'! 㐌R:?|8"4(Fae+ܘd|]}OCtjx]YB ֑\wwnBۖMCx<7)! hޤ 9tKѽ}KY|K&s+??,nw1Kc?2 ext|=':?;?$2ˡ}yL@:>@VOy>,!#/+3ôk7>|~ СC!3~!u`y;~?j*!^ذ^U,]Ve| <Œ?!v:ZEϻZ㖧&x5jmH/* )U,r aUF?W'|p߭WKrń^]a].~ ;o@fѪrMEyyy@xOjՐ&\qQ({zvm;Gvx xʳW;f˥-nf<X@[xby몮~%\unπwV듕Xh {d Uo}~⪻!9< |0 _YOz99u~Qt~ѾG;~4qc?4(>!$[3`۫SB&o\AS)7)wbzLlC.*d+OePj)^~Ͼ sJnY$KwWWTzҷ;USV{=;qs(f.ZKo;Sn@S}Vm\tll򎈮.[!2,Ev>shGnmKAȧjTpF[!JnR2}0} EBH 47ʁsƒ;P)h״)^1Dzc~)"("(" G @>jy>._·&HwC"H|f" @典s7^7.⍓` owvw@ҒރF<ܲS鰲 ' O=gE@PE@PE@P=Б $ reCdj4_p#`I0wwlI`Vø%=hZ;lY3d0 ABA6X([X`ȵqLt^x?:r-R "("("q?"$H.06|+>1nj;nȱSV$NI9!l2MW;#ҎcC5On 1<0DBs실=卐ro}#&SH7rO_XmvnԷ9F$W۠r}~9t|8qC}>t~s:?ڱ}?JrfҠ(U'!Ř_iw YDFw9wE ͇嘦';3)֭ z|1}Q"("("N/OEE,uN#/7^4HNMĄ7C#{ٸ%dXwϲRrTgĞC_:谹'8 V7Lq+>u|*3UVqyc(cyh|2ɦpo+U KZT.:6qO5۴ec>c^MomU>[7 mqǙô;ϓfpRI܇@M5PN|~}c>8t|p w\LJ>:?`痆e&(  6H\$kyL<+7 Oq+>1aƏ'N^~!rx/U AlLА`+( (,:ƲD7w|e籒Rd!^ dwJ5okgLo˳ =Od)-+>`D]c(,`*/yiߤNѱd hȺF[nRח24ܖ|ONm:T3ǁ:>cA}?Ѿ_3ES}ɞ[θMQބkKaʒj{wF5o^ 聐jᲀ=7@&~;ݮ⥮=( 푴r20dp8?,gtx,[9L`V>8&ҒmԤy7@zFbc,j}#-Z폹j6س=6tl!:xJqYt[0mRjӒ26b9`E5ݿ>Ob>{/yzUE@PE@Pڍ`FC{(%f$q{ɔ2l:iFRxTTT 7/ϼ;@[ѪitJmbzؖMq0GTͷiyL['qC@ɿnPcWL(uǥHN*}[3|`6[ۙM$l-9tl ]rdX&$L=eYm/Q.re%ۖgY_y=O+<("("(A@ @"XRMaj 給@§s|wL_oV͚ Oc+Q%eB9^z`9)лK;r[ҫ~WOiYl!uнCkG,Or+7l]Q7,]۵DVM!Ă_T-u 1z>Vɍѫ!_: ĥ΋Vm}Yh$D#Q轷!Ò5гs[/ڄBY۩uStn \@׊ͻ<ѤǝH3夃$0˅T]v o+哐"DDmCf>ޗafwhL`W`mXm %1`+ Sߖ{ ٦y:,ܖٌ8K햾o1˿ {~;LRE@PE@PE@?DAQoaUwy˪{]&$[II JKK͵܌m9RVcR BR?-,{ܕb^z~(<;K7NO)a\ !Fk>Gڟ#$X!& NǙnKG?Y W[vx7By+Rl!vXUB@;ѓ_Xaȫ'_>kޙC{;ރ0k{V )a.9|2!{=:^yw Jcx|tX&6b!{c gAՐlOfo` +˫y??G A1푷sͯy7ϯNf1N؝@O”p>23Ml.ru/}y;SGY,9"dׯǸ3ޗn"5:r{/w ` l\}>=':?KU*K4{i(ᅬ)S )) 0bS8ǭRZ9I,z3Iؘ]`AÂMu[vb xHLŰgW?0Kgp>ߟ/ˈoEZ&K7!Ku釰[ !~dO"2.^Q8wg<73<Æ-;0i>AKF7\س+",~Ǝk.:.އ6Pܼ0nuc&΁pͣ"nB?v\L}\$aWᘐċ ;q+"[<C_zomCb,D-7GzK.]x{6V<{jƼW>WڶB"wgumP &a^uEz>(~Vc ;1S ݈bD!gZClr߲ $BX,MVy$1\%KpmB5rYjOc Rc1m&\~Yh-˷o{c:zNZ { >`fTr #Pd 8]5("("(@G@ Z?E@pKKKÒ%KN[c;dbHI !0bY˃.z7gn~xxvxo`}(#:w V2A!npgDl! fU=6 HkH S›/?Z{ҁu J9Oތ';VbLj4c,1Yܦy x{(.Ž:7W Cs7B)8 DZr$bx13ܟC m E!q|;4j,qnHN{Hr)XDIjI2ɷq֧=׍G 3/vK`<}q_? lEh~,p~L9aܗ0:!Bps g 1/[~gxO$9iH@APE@PE@PA@ @"=G򏡰[@*\Hp!,}|)~VW ҐGBVԖMw#yX+K{p,!<-74ft1tn#.m[`cz֋?y+!BN폱p!Ҹ_/!RCȃ:.{hd8U؝vb_G& ӽ#"e,'\x >qMKA, >xkP9p߬RtY8C)s ޑ-Ke'a99XHŦ-bPt{-֣!-!GR<@dXxH<yef#CA=I]3 ţBOvpѓJӰsa<\ٜ% R"ڶLz)On4_"("("PkhI~lpm\;6.2{Θ1\hEծqc$ Gr_tV8/Y|IѓK0e"Ơ[6"VX!Ѹ\W99{ELN!ݸq0?R1!-d)0?H{ >!hI OEhsB0WĎb$![ An {v{KmbHM#v07y]Ğ%txm۵/dI򴯖%'˒B $1ɐ*$ڧ v`<$( $^7Εϻ>OBO 7k30D%{SfcLҐXN^[=`_l ;f9a-1~z eg`W*~MM4|[ ('5[7B ǫQgnv?Gd*i;'iǀnN_ V!3# Ͻ? -EON+wA[!Ѳ Q'/L25!ƣ'"*ӺwƸOKN]n n|3< CIbCp\d:Kb ]Ŧ`HO+eymrj,ߓ1Qַ e?,nl{`V4] #q]~!dggaCZߎKu6ڲ)9}C\893pS,v!M >,Iu[q͸9 !!hnj{̝bhHPE@PE@PjMFD "P|8B<X0aÐ,?kMN%fj"ei*e^J{8'I]y(>xsͣ;ܶ|~$}-9^YN"("("n_{(5 `+30n3m%<[}5kgyN֎Ӽc]|v0M5>p=2r>q&X-s@ctPSNfY]͎^1X2gg3tAm]Mÿ`';Өy>SI6hٱ׶6w.+DB!kV+e}5("("(@F@ }?@8pW04 uO%v?mߴg 6s/lKױINlձ-L+4IftBz6 gv*?}g^9Z럛?ڶ{sIyܥkpV#4cQUEU+9aw̓@YM׷XYOhò ȍ[ޤs<]r#gΕqSݑK#sҞ>SH3{┙ҞIW13ٞ;Mo_'Syp`]S4V}j C>Gq+>:>>C}>s;:?qRUifUO:,<DqxbG"kǣ<޷ǏW?Vf &p>ͣ°mހ5[vkPU0ǫuɭL3s@.:"LڞJyEe eN5=dSb됼K}Pl  4'Ʋ0K SWW }2%% 1aҞ^]1M.!VŴDz&b,qLr87 ӞF }㩻ӪP0:t<AhpѴ}>}>y=4( yITC$BEy˰-F e(Y۶O n܅ !.)g_&FaL2@;bU؜P i: <,(8Xru[wQl,_ B-p^a*'ڹiVb+z Y9o>!?jN#,`?зSk_]9S-;_Ap+0_R!NŨGޗISa=AҮYc|<$s_3luddeg&{kT ytZ&!%!ߚ8U#1DJ"("("(+xKP3س$Ν;ѱcGٸq#>l{F4 i#JѾEc'_wM4A9؃k{U#d`8۲ oۋ!"hi集cަy_~'.2rHaky<{ѫU&شm2eIL^H2Mq_9XT+׫yvhm͐eqFg!{4C&7Rʲf& {mîhk6T;z(y຋pkpDdoٵ!wm|!8~]\s6T._GROf>rƒW .Cn-#w*aDx=ٓR`Z{9VMr}"r\z$xx)xxrɴ4,},Ĭ+qEȔ B2hw,Fx9`!ng#6`aCz ("("("pz q E@ hذ!rrr}Bk^GC յ?e=:Eއ_o@wH2vY2y}.ztb zxnlziV{W B0тⱈ2\1l[<ˆR! ]}؞// rl0չh(ִ%3^&CE@PE@PE@8y)JӼysp͛7cӦM?>իg2U^\fNťovxyRܗβXų1>+B{}/Ĥzf_ !x1=d2v◘rF|0)X&'MÌ7a(\530F=,[{ GPK>&&vxi—Zq=ޛ2Xe._hLyR A&ͭ˯gJ ɻL*D)Bڰ ;y$tbԤ/e$<,W#LjE@PE@PE@PNgZΖmiHٿx}!۟gl9t Ȧ'+ۡk$bEX&b ù еiy?m%au&7zaxR /%6,7f̷!~wsIcocTFtw %K#0ѸIXm$\~s1Z ivg(c,aZ5MY}Eq}#Ij_>^~gt­\o{h.tLwudcï㜔8|#c~=aAb{~3 !.WR? ff@b~0YHtk zVaQ*q_^)ļn8W-c&cWJg*z5ɍ0kq(K=WPi{WE@PE@PE@P4q."#voĂo^-'IE#|+;D*(*Bx gd?H! t寬Ókw4^xPt\+)-B0xEE5HHri3Zgzr.S-eY"̲\+L? z'56^laGlcYD/2s+=&o d9 !wG!)X&{]q1Y)d&IN.ۥ5\SDS/5ASmI?`;m/OL?h??FceaY[?:ҜKdq#;e%%;MBACC᲏9yY\V\lm '<386c_"("("f(x5B@ ~|[k,yD`ISɬqR6ͫmCQMѫK*sǩYέir$ηo*~qV8BN vtLmaEף糋6H@ ixkt:ĥЩdɰp׵q[G"("("n펨=" Q&mqb[6nCF)V,i(elQ6\eVi/Yէ϶RV;ƽ鶑3?̧gU qSp__A\D\/e^2cѲFɁ$E[ Ʃc$ǔ8YN}%[l/qg+L3X[U :>AG;'Av,Aߏ}C}O:; I`mWr3^~B6_f&fH+qS?TIDXXiM{6ISc}ʩ3~Wwp gTrꯩ>mtmWf92$诒 trO 9%~r#p02/r qU$ԧBWɍ)Ҧ~No(3yJydS3c\mSv0=ekfLE(_A|-O qGLJ>|ps:?ڱ}?A?A$ _zIdKӐ?Ԛ3a<\?Ln3q1qb)0`XHonI:0mvl)Q6wqzgeV72Vfz<.zk_T[TU("("(O@mC $wy*!dCM[[^Ek+o?`\3zƎS]Bս<[. |l}.w[n/ 0PNJ63^M/1nb~, MY[/lSS#X2V6Ě3u~J}1%)ԫg:(;yoVmcm,c30`Jr*i/b?6{e}WS't~#Ή~ߏѩv?VX?/7^4)Ib˛ {dSnaܔ(o}6ɍMUrSdٜ#GQPT  e|PD mܮZ"4$Khu%C򃽶UT % ҄!h+&er9q.+4$#Ӷ>*,>W?~>J2z󬌺J 86QؖE@PE@PE@Pz~?"XBWK>=며}>޲O2Y9K![CĉzGY+QPVs;4- Ewb^~0}#D^eY W#qÅqVT\r=>zQu .8Kv¥@Cz2bE%hWx} A][#hZI");,;'c?sۖ8&s`ܬ(=[4 E 78_wtj߾gx7.##!6D/a-rNphcY WMc"qAG/JE@PE@PE@AQJE@!&,+WbXj֮]=DL VlD{Fg\C9,\%/{qScQ!rimSP&:NA,'Zԝt-wF[|Uԥ[y(~Wnq]a,GḴA7e}n2hS71ޅRnWku~[~3O&o”ٸIaHo<|p<+yGģ<φ!/mX)?_W]7}͏lÖ ^zk,~[vu{aӫ"("("(G@==fZC%),yN8+}s,w^qfYYY 3YHnx7Qg!Lk7@RB,d¯.]s4^`:Ra`Nr艈PYz(t~_qE@qae6ͫS;b(Crr2ۇ>}HXa*q@N,]f NCiGw Ӿ[e  +af.b}G pÈO fnZ`g ;DĐvHkhʐK\R^%=$ހ60'F 1xrw"+)-CB F A4w% ͤFxK^Oxٻ=}-E ލ51h$Iآ؈7+(U^ﲻD w̜33ߝ;Ǚ9w=򰏾ΑD\t]iiP C m>|P>T[}އJ}b!p"@͛YfyM4q/0"j:n>\>8G 9GO4 \vZRM[wMƎ!gxsxIEGP1&:m^| m´Tϔ9K׸bk3(c]t5Ec՟.!`!`!`a _մJnǜ\s hT#+8|~gQ3L}>AXVt|vZgWΘw c -bGY %xkLL'tn/;9|aX~z"q>D:GCVf45f.ƪ c`iKr )4ꧧmVNQpqѮEc`Szfd5HGItzlod8IU;o97jBW%򝗺ܖܼ^X?nS P^NdINbxe L=kΑmI'Su#wY'=")8b!`!`!C kcL)2rD ˷akon!BIcgHU'25y4])cr>-˻C 摜 9ƸlU2r$# ko=I r`kGRŲL X}ڶscQ&m˸|Pw1 s #Jﲌ/n>Yd[pAQ1/eEi}dXwd縳S~l_vd:> !yp..!`!`!`|H`4%!SD@ 3AI3Ъ%g1T!+HhC f6\m*z3T:JȩB-R%i :V摌y {kw!$B,IivX"QOvh|yɏ >~B?y>ABJnA < `/i :抴œ ɃyNȺLg^ˈE=;`ڙRDE{?#(r,8CrU,xSwpN?ӢE\)`i'^Ln \?7_9a`냭>>p ~v΂!`pT[}oӣ-"@FLr3--!`!`!``<7v!T{;hĠwaCWf%@u5֋`\S1}}(?>x@rJG 387y_Éa!`!`!3NV0~D$Wl9P֏l9U%b=Gu0A۩$*cZrQUR~]7G}׾Z3 C0 C0 C8Rxv C❁d +j#r .%T?kq--ɝP.!Ll!2;L3h:|Wm{}F}덵d!`!`!p$0Hom(q?q&pob6sRWX}slJ<.{uv[ZU_zU}*4mi{ zKwv = rFŻnbBS ./~h{>`JMC4gUJc[l}.¾?}?}?~'._ !`j۷} wmtzEDG_=4HKIӝ]I?COxqze]ywJxuyTr:piFE *ƖA}92:7mہE;u.љBȈpX8 q1.O/ =㆏Csa懽5[l} >#!`(^nn. ǻ~zwjW|Y>s\MOu(!vƟ |/tm<6?t.RG >h룭\tM|3C¢?:7n܈_~{.~ߢ~x뭷PVVԅ۽<;낉Vaw'q_rDL>Cp'"=5 [5Ýݝf"\~j[\(ԤԷ;F~vl~C';}nr#\_+y |(i#$FuEvɽ#A=6$:sv1 C0 C0 C0fxf]_Vt?~˕8׬Y~K.ng}6z)dgg#333dͣ>C$y_^>ⱼ|,Y(o@XS^E{aH8vyg4HugNYG  ,Ŏ½.W2YqLCC^+|_P]ڶ]mdx}_q[l}8#!`=z4N>dw߂ PRR\c!~}wtOHCbiG*kT;LlMMNDlM/- Kg/N< k>eE%Ҥ#|x!%;Y88trB#kia-6dЏZ0 C0 C0 C0#0mM:Jiݺuða7tہy *$V5D%ͻʧ_#гۅ\CIq/[olE]sto9y3e"Gdڝ.[;y'# 9gi:)^Uxv5 C0 C0 C0/fxx cZ^;m[gMS0qQʡ}KyFLƓBzb}W NƯx׊5>›rߐ~poOIP,=HDD$&ྗ>ŃzbxŸNW߅Vdc^a r$IJ))FhqQx*I=:$=r~3B0d\q'N9d߳u̠'!`!`!`!p00mM? grfkk#t#)21_?2!䱎_.leXWem娇 (i/ODO;6C!Sh=q]c1C0 C0 C0 Cp!`B9f Ġ?񟓜cHJK:OLH7Z9ƍ|2~ݓ >?ZI} aږ~~GY>s;Z~j |Lk]u.h[tNOoE{?W_6tȼ_FrY0 <wʵeU@Txi-üCqToP>uxSy,?Á)D!c%w}Ji]Z;~5ͻ~v+k3`Aei,;Xe5O1^]J 2}u:ǰg!`!`O?!!`T:߯BV&Jbp8LO%!R!NC+/g| Ȉ*$^MWi→LP&c׸_^=ejϲU?͸Rw2b,V/--&2~ߵU!c85\]_䟖Iٷokvn>: ص;ץUN=jժ/q?nN] C0 C0 C80 Z CJ))ĻЁTsrUtեΨ?/.~+oFVm]t%ZFЪYCglݹs-GqI)ZI-Mְn#ʱV,R!*2RFl]e!)>YۼQNx:~EQ`nDfd4ά+"mƭvcjRkc͆-Xl5hvZ6m_Xw~FƸw -h\{K˜.kMA]9d q}mM:\('D# b٢ͱ ǂk g7@Z;r|!.& "߼m'jxJ8tn%[c&':`!`!`ф99 }N@H ~/-"\H=Gd! MLBdҟz OB\7b<2ʊСUS"!nxU^۲sqë_{d yϰdF֑LW$-~%0LYtOЦI]?afsVm>ѫc+og2J\ Og-F$cGL(.xwt э|~MQ!1cRd qj\(tIu$+ Ӟqe{⸙5w1vn<>r 6 [wS:{|;zvtϬH?<5aоusXX|-Vlډ{>7kBF>0 C0 C0 cZzy 1>)D Q١Cݶ;$[ bbbPVV&gqkڨJ=YO_0W]ٵڊe_k`iy9^x rJ1ߊuY bϡk,t)%_xt|9([rc9{O7Z~2|8wglݕIvvJ#+AڙYZ5Å{Gs%^4=6x\})rdzsNw Npb^tރ{w\=Ŷot֋>s~ڵD`1oO!B[W4$Xle3\>m.׹x4ޝ0 'Y b_g6.z%GKNY?^~*:n3ay%HK>|! ^xkB[s!^% 4.!`!`!p4!@Ђ!`$377w_1^~.e%AOx0\yqKVadL[W joBV ε !nM0ojʛ cɶUt́BR5El j!Ji 3T8>_yh#rLriNEвE%ْN? Bsyx{n[ 9$ѱu ж+ QU x>\r@oz>HxoV ۚx -l"ᢒbp% CZw[Atå'vm[ޟۮ>m=W! p{bLdlwpkw6-00iJ\4DlPe-f!`!`Q @ߟjGMAA;ˠ qrx:cPHYøe:tep '3 *׺u;E?6\)[UN2]<Gh|,Մ9˜Ybt%Af 9 rfC{zuv" 1jET&ՑXd( CnՕl鷜'"S9|/ę;^;Z mqZQDEw\=֡!91gno9C˖ᕸGҤSvɖ$N+߿`c_se-ؾGvp\ ]p "D $+r(U[`gA1_ѵ3 #:y+֔O e"mU.y KNH*I0a0 C0 C0 < u'J$gM' aXp7 Ig y/9r%>~7HKﻧ<wG<'/[,.R!xyyؔWH*VYZ-m &d!!V)p[l&IF"Ĥ|Y֑vWJUt0-${H$ ovT&N+73ZQ9Ιː 'ڼ7 )~IʯX\^I0FH Bj25]yӶx)co;DC7מ ٻQ/6"c &$({2M{]iYH1D!(ync$sE,sGָ w[W&}?zmrVX0 .JM}.|A]ZZ^}U[x1rHDG{Vl,>Z78 iS㋯[ڪuwKXi薑e6E}eA6b!8q\Gqv)\jA:0WT ۆyoƭ·<3'yr ?nup#vhkҨ&ۄi=]N:,]YE;Ra~= bC>O49{1I<`jv#5oq8%1&~ѓg<~KPXT 7qz! yK1˕HdB}6[YQ1r2^L4 g=.x5v`ԏpxloܐbI{?mHOύY8]O蛹8OAUxk&L۵B@vĥO%tk^uw ­_=ϾMé %=Cp!0 C0 C0 @3[ ܲH˷akonE?jGL@tM!D,-^u}v񊵘:w)vX:h۬o)>B^/[{ѪQ]'TX $-_ W8K)mO6VcѪ.yMKIB=Xg$-5v$]~a8XM I_Y6!_.]YeIgyv4IxkT,u/pHɘ,^nw>YRm_Y&Vq@i*[!*vlɝ`܃M֑{rwb}ȱg!۟iU8KDn9n8zvr9s8Y'$iFJfbP.VV[pBun;u-~ BpLϿ8~[<O_Ғp|n69_QXf3z& cDg:6TW.~YM2! !Պx۪9V퓶_% C0 C0 C8*-GcN"$b$ge &S=kMxrKG(G9?,û:4yĜ9Af?<#ѷh:D,JH^)Aקv1 C0 C0 C(D,‡f]6 %l i9*ԁ*奌QyeTNz"#Ġ4λ\^0oK0(ٙU]-RLá' aAW)JZwGɽ2xAk2>rWIjJ Z^vlipit!`!`!`G)Fκm?!򇤐@$$,o=u|eG?Փ~hZ< |w}ϺWye+K״|e*ڐ_wa*˫'.)]HM媶j)C0 C0 C0^8qN%ϙw<KaY=X*AϺ/:=3jW+Ez ~H~=-1-B16e| Cҟ"g~4fK0w*};/xUm:aYߋCEVL&r㰨VkhG[K!Ǫl}G#`>1=`{-w'uvd_}/?2\P PGzvBDL>IYu,ۻKjye:L8к:f]% ǟYֲK!JW )!Υx)$/GZ2Y~=Jfz?0rD$ ? ?>k-n!`!`S1Q?&cP|X_,-W^-!B5k& 25-5BX]gܷ6is!=5oFX ^pjb٘d5ѿGtnȨue6{O.0ubc@vھ#VB[\Nki-W&[o)߲}ڴD_B׶Ыs[DE~oߵ_Oݹѡ˧5]MF:vRiV^`@IDAT2}$mG wqդ+;j Vɂ;mKWovvVًWS^鱑gVXTis`>] ȵѣ}b# մ+WP3`ꍨ~s6Y ً9I]׵¶W=q-M!7| "6? >`Mm}8p}LV!p#_'WVV9 -;=~$N dzCemߊ7=.[:9ɬ[H;wm⪿B~m-aW߹x~6Cvx&ym G7G9ۅp`?<U/,£I7?Bj*)R!?k'ǃmBFv8?;-'ЛnUp3y{q "*"g.F۟Ă\1gGFlTBhy(Z]!`!`!p PPikw3y%7_Ar@ī`$WHw&? Su `/Y@ff&y䑊>$GW0|<7<@ъĸ@zZrM6J 1@P9+t"j=UL,е}KH?0v@Tν?::X֮.$,~whۢ7|=WԶe)ͦ'~CŲ.mm$Nߝ.ݰ[H@#/qSѸa&~}YgEƁI8G*)l!J7\]~h ]?ﷆbb吝O:l~=k}?~N/`" 9`)J:qe+ÍG84iRa|Csg՞o>X1aŝ3'XOCgV;v--]m_SeǮ lMj vyؙɯ8L9=~}…-X9l=:,CYm3^r}'qƶЪytލ]#[^>X%zϾE^a8u$*]u[ 2}e%db\{iرk7:0/W$?&NEG$X,7O#9+~'nXf3?'4!"tێ 9cj j]{r~bwg,oիn6ܳKh 7G} ycGWl>|P>T`>T'-n1:hѢVZm: c**Mq T`MG|l;qǰtvoHT7_nLgx:wM[qR8xjwln6!`!`!`y6 C8%6lɓ'cڴio1}tǻ ZF36W27nZfg>oo]{*RW_x}٘,g!G5u8ujf:J|%.ni)BL2X7loG+$Ǻť宫<`0?E`MqSUnSi"N˫QBx̘X^!?y.ţ'NZs:a1v:9ð]ZP3)3ѵ]s5j1/^.VmgxT$ aK7>;ڍ!O1oswiUNzgFv╮<Fk:)IvHٝ!K1 C0 C0 CA,i0 J"qǸ8@~* ci!ibYjjwsa)ⅰkpJ$IXٮs4׭=}([{M< s^JL|2yFO_;r1 h픆~fa]h)[9wצĊ՛, <)Y[/:v^C$$F-ջ h3̇-{3qRW']iIrLab!K@$ MluX6Z(&u#y8pcVXi'D>#Ǟ{蜙9mP,ȳtswK[2q gOAM'f+>(.mC0 C0 C0 μY0 `m=۳[{ɣtZE=d|$ts@G"n_)`x]bmD9o>\sڴh:)课gSᎫP Z5 |"܀/> +mR0LM䵛#[[KP739y21Mͣc'VzB%$b])d-:&O?Xfs-đv2g<>匽$m2(9/59º i/D~A!ҥL^uw )>F7vun!>(g2&J;ώQB|~݅N'Dnޑ:S۬&Z J,8ڀrY 'l}^{$a+Y0 C0 C0 Gmϭㆀ!`|~k);'dɡ]`#sg:U$Zun>C&Z.(F:hB2sllmX7}Tmhȶ !݇eTD!FSİۯDfZ*c`ܝS쳋^bMNDq2̫/}g<Ƶ.󸕙<xJ611y ;!`|~zQT^]tX6>gc5zQ!iZb|Lmem$ToXzVq$<9ڔ.z=:-Ի$ڦ'`l ?ti O yTZǬUDŽև5E] =;`2'VZ/g&|$8}vJd1h}I_R&?T57$%%q@ ]{d@fz*[Ҿ%$׼`]ԧ*9rFY.(vfْ]Vhڠ#GEt`}֓z>L?Kug`yMn|йi~s[?9l~:4m>;`ߟGØ ?4|cOLn\86sˡ q?( 73EKӼk|*' C(<1I$I`WPa1ESh}W'z"g_?N>=vjuB7T/NrH.Jj)ky꧀z})g/w*u\}JV q12-P,W%tj ھ Nm%y6?l~\qߗĆ~U늇͟"@3F!cAP v. P2lPSRPUK t1<5nr>\sP|Z4Si, / DߚW}{W~QvWkR3duc"X+ U/2cp" A}U'*mɮT8"ϡ:>!c%6?t#7|l~a]l}Q}? .z5< C\% ?q0yx G2+Ve)NY_rg+.b )mj,^r5]"a:XUf}>gG^WM$+kZ"vMy״/XFn!ÊU}W(XG<'X#$ u%j kW>翟:x9E<5nr{[;Q> CJiB<Xw5NAQujfc 'czͥWޝۈ8瘂P=iRN]^KWl=,ycl7/A/]֛hCbƭXivkȠ3mwb/0HU'^`uJ7FW?vv1ё!g4v Ơʥ3شq-kkk?nr?&cm~aMm}[k?n_YgwC8d(Qy#ͫ2QB)!5Sȵ.NBۇZ-.CbL$ڵh@?E.,.ANЭC %le;k@ H1͸iwF7Y)svܰ5wh@_=זS(>;.2? ]=j?)Ww+l|+|zј4VGc!6xQvX1j`1!`!`!`<[D$~&=!ˤnxW#-%ee0S1bNlvxfl:xV{$"kɏ#ڷo?J{1Q6r!"i w>]ۡmVFGGm.&]S^wKĦ7c#VJ&hTdk%1Xcm1^$HCBEQ>? _[ Hղݘ[z3S1mr,ް'vj3O#]󋖯/ ¦7m;wc ҿ'6کs^Z2_ev8ku%9]W";'vmXkB\,zf 'f_mr-m5f<$'͏'`uiuЁ}dV|)?ꦧvd_NƠ:qd_g#$+U!buwHK9'@BKd Eح$1۫s[Gs:cC0 C0 C0 #;Z0 C"@o׮]xwb„ bVYjÞ/D2ٖyN3H𭑭{r%ۂcqOa( OuLR6%-I8ghg?o25_P2~쇎;K}_pd'g?:6{r 0G;Lg w˟y[^5?@ع%_hܷNɿw>\! 8a"!t!ܩtO<(b5OkpEqr68wp|2nXĔY :[#}0j48\uZ_\yqձ癑,:??[wJ'[8/㣱KVCۇ#Ye `ܥҐ ğ>P,b!`!`!pX8д6oI曟YYY8obϞ=8Yws'G0@Goڃ8><>w1}g ݄軮Dаn:^5ZVM1nLĝ׻~ڵlH5#mډstu [Z _Dv 4@]vRB/x3YuB6ѽSkWmG$w}k>=|j" xjaO`:i3u%:R<blcGg ܱu3}9ke!Gő(قv1 C0 C0 C)!@ +!E@-n?nn)4WNe'y)[w{tlΖ>X?BVշaҧy I'<2$GB^'Yz$4pH eL=) n)Dc|+?б,)rET70+FYӝ3~}HS/D̤O ɳ#'ǜ]y7e`x])nrV^eb%0p,-+lڕ |tLKi\|$ {+1w^.$ܶ"=-)`c'Xv#^~w^{~&⢣7~Oۙwux~ħ\l>o-)/}a3Ӗy:}6%V\PTؑFI(%e϶ ,/g>·ep>B,ױ%|ˀn / U{l0 ?xq{ŏ?n>9a`냭>>| C!$~ˢrϯOKImӯfbM߄g6ق2G#59mcCOTJů{.qqЪSzc|:k%{:곝^ZЪ+M$UjOun|3tHRp_##5ur{Ȉ\خ8:`'>]u-Ch|00xy$ŚWuGjMMGntL1=2v>fj3f?qa pN0`As[8l}A Q03‚!? ?냮`u}8,ZcE- 1A 6Bߗȸ9LPj1eUMrZBNjLڗ2p=˥մu8L ;6CB t(Hʛc|͆lqErgmCDNw lJ"("("(7z~38k+"㹼D 'ʄsHiXu1}!")2con2mCR(^,-mے6<rc8}"("("(G@ p#Pb:LbI`R&eg !$f)ƶ0}:ڗB9}r=#o7u4a@i1H|4("("("m ශy TM3Ӂ8ͥj>`lKH8Q,03l}ݎSms ]5۔` v4x ռ qDŽF"("("(g FgɮUE[G@'?'a9 kƇPVQi~h^)|$v8]ZVn>l;X!|}wتbcyۮCO8ˋK1㝏fn͔.By`Z?B<s 1!#v\mGHkzQE@PE@PE@8[(xU"AI(wc}%D"\~|FS'r8s 0%%e&u.{9xO.{mwUU&%p,m{ zl$yGϩ/uL#tC;}sv=`D]s|u`#bǶ;v:oZҋ"("("(@@ T &84|wD=l /uX>e))o|vZ"icc.(0]Rb2a&*`c@ q1 1izC x "CQ^Ye6֕ayEdl]Yy%E#<,x &1׫EHp KQPTx:8*"ګqsA) $B9Ԑ4U5/2< ё&\q|,~ud 9y 1}1-,(*AJL _;5("("("y<L^pKZ>%IR] %1e8| Ztcϼ vXu>LAU"q6~lُ"} {t‡cĀؾ ڄa"bS|Wߊf/Ưnx<Q.k' G!hn>^Dm}l;I Уs[_\UCb!6- Cv!`v{#pHNM6{5nڇiM=#GOo5}|y|"g݅Prc|¬5xO_ן.8H}qpq'i+><t~c.όf~Xϛ\#y睯C?LV G>s>dkP0 ;oU `cb$>9~ 6L0#G`jð 闉[ă̿܃6ZP;щx0aPf;<"TӖ-ѱeS4G;Bzh+n02R0gݐv!s[=QK$ۏg|~:c3]qX~'`@g~nq0r`/M-`Ӷ٭#" CA,=^VMن-;13k6 tlftҶ?Ct`X&f0{D2G2!x-( "WAch[p Dx f>Xaڷgn3+~2/$焝VV|FvZ|kAׇ]FcE@8g`?m۶Ŷm ($ :#$Wi1Bt񯘻s4#}Dc{Z&Yض/X%b K@1XIۇ~ބ]5 m~ع]+riqHyU!5GЏKv|*=ÈHH$/2'R{T̈́2ꓜ+e5Ǎޱ"\+)͚)I :w T81VgaV-a!H!| hKp&y@mꅸw/ax1[L"F93^kA"("("(g%jI1v^ I0G&ϙGr̤&8Z{?8o2ƛO.љC?Xy'ov@.l۲:M3Ddyevjfn@!K0|'I*j7+Ek X ;oU `cb$> h/B$$$ }&޾䓆".>o؅;}q{‚{?!NteC5yzL1Q'YZ$LOy]dj/c8yq`2W?@j62&cǞھa#xe $[e(aö=؞WjFEF;;ߩMQYa;>+1vxlMhN{ plځYkk/E|:d܌c:eʽk̒qgj]L~v:?t~E~&hevZ6&vZQ|{Ni:?t~|χh( 9s2AaXGEf~vx:#۫?2L,s:Jynww%DLDGEb]~Jv"ѿ{;io0csGLj& CDd]OU=wҦA#wϘmX#㺦m)死JsNifG'oҲ 25k \3-M:z 7 zńm-9o0atbs]r<fё4pgЏ~8t$ۍ 0qF 5VE@PE@PE@8SD1LS;odfn0-{)@) +@ #2{ȷ󇷼&ѭ]:$đqo8][šOx+5o/Yk!9>l8 A֍ȴ1(>x"Zіޖ!.:\#q1ѦM&bh:{kK$3?]d;&'Ǖcb,Z m{1sjk^;NN0 l\dyD5ODBm710&-!]+6">:StC93;"\NGјP^T/9crSіN/?>}521́#L=1("("("pp3f^ )ofF߽5KfL>=cJX|#ˏ8Q Meju xKzrnb\^o#}m6T·iA"qёt>W閂<:#|ڡ~/,4k?H^zi#}*_BLJ^;Bq1mo..-,IE@PE@PE@P3n> E@n ̽'׸L:1/rV 6Y%61Q6?S$JVBls~c-, }e#01>ӧRc0q[t9zzㆋh^&<^f$7ԣC؍kD.jѴ"("("(#c5:؄ 켤D8.%Ω_@lqܐ,Is,i祌|p\x{2kխ%캦l1Dៗ1&c:BLKGbf]x{Rxo!3_3zʶ8)>N)_aR o֗h%ͺ6W9Gy&x>Hu~χ >(sAQ>8>-iPFy06?RC0%˱!ulq=_.bۮ#el]f!6$eLbVVVɍh,K\Ol2۞_.yE@PE@PE@P<x1U"p !̿87اa݊69&i_̖i[_Bq\G)IiG[lLlرX=`d[c=X+д#'eE@PE@PE@P JXը"|o`v"Θ2<;.P2'4:_)RB9k 6%{"RUꈜ?B.<pY_~]O% oZ-Є"("("(i!iʊ"p# J xyi- n:]7{ qu%_l9Rf}e>qM54b>+}|vP: d_P4)KVUu-ha['kd1e2 "("("('G@ REKC;/i6rLlRF~imE%e[suaC8x|:TX+db%2J7> Q\RD~]r0qaR3qd> ǎ#c\wz#>|IK!=.hnک@IDATRmG~0;On8SQSSk@>r}ǿlHxSo-耒ZSNdCaҕA(JyIL2 ]+>:?P }~5,~|ayd\/Jcz$u+_?Y+G0uL,r>}|/G;+"p A?/=~W4Oz",$Û WXg?Ȼ(< m C6;?dhA|+9op!Kr qՄ͖9 ѩy݌ʚ:cѰoݡ#xdۈ!B/4o)BuU5׷;; bUqxcG_/ڇg|~~ *v,T1!.~^w^eGFOݕWkGJR]E}Ңuhy஡]qە":2¼ovhBPE@PE@PE%Ѭ"pb[WOs̚5 !!!f ohh(ƏhN8YARtfG5M`kDuc덶^;wy=X}ڱ ,5y{ݹбM:X HOIȁ=QVVG2~Jz>0ހɘ\3#ڏh1O/`J"LΧ4v|gb-N8:ͳ]c-o<;Ⱦ&vOvރD&4<~PLh8a~۩_\:Ncf`_=;O߁:5D߮m1I'W"("("(@(0.Z2 9reU<+)+Qnn.n:m9rKPƩ(ȭ-C$@uTTՀ׫:i-= ?C.MLda6itozw1["kǶq`;||-$2w3L{yWE;G"80QZ[Zb̓9m%fbFG"'j}C#{(;6m͍KGŮ,,52}KL ok0[O:LMŏ.($o@ދ}R?~M3B()-7|HNmq迿G(yUr{d?{v(EPE@PE@PE^(4(*A}C׮]e 2oxPPdLe}1aハa^~@s*`dGA(_Cc9T\˕=IΏuN哐=y+r!vbE(PBۙKHcBzNg\Ɠ@ LZ'ÄjN͋xRL?#ӘqAPE@PE@PE>JDKEA@X<t"o 7aɆ؈ TP'&XZl~:߶= ?ɧ&:bݑqtn!d-'oEέљ sp2j8J}e+1(e ! 1^lo%:ǕVپH'. k6n3 䋵b[5"՘ZZ=:Oy֠ax|n1m'ڡ5J nlp߹A zwy $8scɜܳk,ٰNRΖ@ϸ8M)"("("P%9E@82ȐND A<ѯ+uruWZ]1VmkH@x[cŸ|X:-FL~wy?[,ǃϿ+y;sݥ=O}`eMNJspqqkwQ'iokT,_n܇meaf:57 8Ph{x8DŽᷯ|3k.~9dBTBlt$W>.yME$ӭ#~񓁸istoߗnms{y/Xu'ڑc<ۤ_DHtM;⍝٘?iGSSh("("("@@tS 5(>E/+ esPkY GSs @L,v!9}wJ9/0Ihn,oV=Ei.>,i&E@PE@PE@P,Ф"CD!oN4~!Y/kG([an;44ok=_'/ccg^N%2l; =QE@PE@PE@8s(xTK?P _md,po5zRmlֵe.x1v~OhDl}IŮ S=y`mO}6|%&HS}E@PE@PE@P3O{y5F0S|lz{39) Dz༤+@mq3"& e.>0Yb<̌|ƀoNPa+,.}PTR(Z&'6R;ju2777?קSv< D*P}stq1gͯu+lޥ:W莤o#/3茇!ۘ?W)ƒilfḽ:َGϏ>? |\Y/u}Qsa}d(mN]fU `cb>!Mbf|iIbiѰ7*xh `OA #<+R1esێu{ouh'6͉zmqێ_x.Oiy~̫I# O:c4N]fSr=Of/1Ӣai;ؘiGa9au~χ&i]t}A{Mӧ>`LcE+"D켝N]2Ĝ`\FEbc 9HY xa: AEg`lݽ6d }GjrSNRp!7ٌbKOA qHD5xOq^x<|ϵ$Z[\M{O?ǀ[ts|?K5ANf[/;؀ch^ԯӯ؈:'{eql$/mmQУ?ܧb (,)C-ћl$7!kNmLY$:O4-;!;d 2<Y!4VE@PE@PE@P4zL=F՞"p.!_W& w5,H4r!fuujlזIK95` 4A6؋~ {!O h>l-ֆ(0v_;Bu׽<D6v2}:t4w8}w49_98x$wu:ݎ2Cދvu A|T|k!؃y&9;k7O:q;Kp9zg^x~6i2. (/)Ea" 1-X8 Iq_+ЫK{8fZdMZ >Y}4wJ1m'3xyIs,A8/i+>:?C >룮wA]t};}(OƊWD@3nِMn(&>Shٲ%jf'i.erZ$!/6u}c7#!7_˔$Ё"8PZd:3 ĄXSΤ|9xE&<6c{ o}^9|}o6yuȐ uxC/)Cq1 @ai2B[.5{7ᎿcU8v(0} Ꭻɣ0>?#s[ٷqJ0gmC[ Hd:O/㕟_㆙mԲ5ھ IKli;ؘiGa9au~χ&i]t}A{MӺ>}[VcE{y%M6aԨQQbԩm,@'JbdW&r~sϕze((,B۷q;pC9 aQhȧ36W0&'& Ƣ[sڝ_7ΐ,: \7AaYƄ#pޣ]3l#R1;>_qZK%rGOL]u}QG^dM~៟ "@@uָ kds-" O6@vro¤Ą{m.Ucހgжɣm^SlCS",^2" tY!$$DС"p4c"Pa!?Gr@ۑ鰎R6{9g.Bf4twE5;zI6c6-pA9Ir=:t0<HL߻bOjpb,8H,is,U7[{:_Q~?8xHc RyI\ τ>>\\u +CxaR㴴4r)˫q9|r"D`&" qItNk ~;y -e2WWp3ѷU3wK`7K N[/[ hnzr q15!PDFm I^LjP$'9}̣w &6&ChahFvCֺ}~ғm̘Y'nӅWla݈o%nycy-'S$;"("("("p&PL9 jBm]M@I=[/?Y%L.z8<#"t];vNWn2{kmv}56q}5("("("It DSm) B %RCy5D65d:ˮ+u eAoI=:.]/L1؞-v: M]#y_{{%E`yu7+P/6Ğ1E@PE@PE@PE !R(4BIiL+s9T2ĹJGKI!RwH=N@pԱ7sҰ)|gmϟ|'w )HYĶ}&#mGƺܩumk˹= .ԔWWA"("("(B@ 3Q%QU'm[H/&e' rCYJRn%+Чi@.2֮77!lu2w*rc=H=IZbXPE@PE@PE@8(x6PUS!xk Cj urO<İu7Cy4;Q> }Nej.9=cŹ.Ӵ"("("("p6Pl( __C&H/wtοor!MCK=;D'X=~SB0tjֽJ;N]-)"("("(__j(i" MzIm!.Y#8ww7J5G z21`7ԖХ!YCe}:|4ٹ:!A^v=|1~O >QOliVPE@PE@PE@8ewtKP._e<|'DƠ8epdohbd:s BhM("("("|%Ji%E@ 7.5qu/ = 4$ppυ0nx?TTT"pq`2q!]mKDcї2f ˄%Q#n@3*aCML>881bc3zQE@PE@PE@PN'G" җ* 6B\ɐE_ސ<6:|cCѬI$ĉktz,XAԽfvDew-y5KǪ۱)IXb=Voۇ̶5cs!$1<4VnDNA FAxɾ olAݾ Fm0_wԐE_U[)Muj2r ouɉ޷:I3d mkZsAEu-zOhW,bOio4("("("v=D"E@y%aPLnńjT?>P]]͛{=ˤƻ/| ûd֚r{靏0ѷ0O;"0-€^]2/ł՛оYJ+p˫`8^hE6Bo_y'^E ڶK:?zMtkccފz CMI] WFM[fM|fq/2"C1{{C 4|f;-{gDž]RWc_g?>İ]ۜZ"("("(WAgfc^5Ǻ6?gu'τDrIJ9-g2ppUTTgqziӦ!//=j(#0/.W#^g,ܞMw>p>݌cFK?qB0 E%ظ)wjX"CϽtvMvcK uq {p25l`OWYv$%'S.tl=V-[?r hsVK۵j=n虉 { /^Ҿ+kVLnS&r{o=9GL )KP@}>d.~?~?|'? #`zg/J؋+y"2 6]?`lӧOwE[n~Tnc}g#-訚<]v=`{ i+.Sp1!Xi qW.Mpڦ$ջSbۯƅ]]g_R<rw&%&+;G:|σo6σ><!> M)"pծDll!θ0::AAA!?|2e0`FXe7G/.*Oe"}EhJtN%±V*ꋴ‡s$)|`o@mjy4h^6m| .mS"#1դ~A'WC{Xz J@ C>Wo< GKìE+"`>6i nly"`ģ4("("("(j+`,BdyI;v숷~|233/#-- M4a5?\V@)灘/02: .1uîQ2OްV'Jജߎ"28{ )܂"D6a5x:kvFp(,.#ǨG1^Xh(B&f$ޛ/'i͖8&!׭ى{C )qӵ=b#H?wu~χ>Ț냮2AAsw;APN/Ol%CJp= 77t.`Eɋד`k"ti]xo3WggQUV!blw`;s#zd i+QHpyd%+pόO62a{({LX+יw[w!xqHP#lg~W/FT.i%H%rG燃<| sAG]u}NӺ>냮`zS"|mlb/99r yU!88慒̓5F$ :ЪEs,Ucmf{nw5b"#p(;xrp"՜~0"ۚDZ"iewb2;}b+Dz* GA7gxaYr=ߎkڦ&cx#LL Ď)zpszWO{Z5ŋ_׎Dm>]N3o%M("("("(\)oQ "A`f[dT K!ŕ2K&sj/x#2~_AaT߈08 aC~@d)ؘN[iKKA^vA킢bz'` @yΧ7O±Wc떈4OlLya. }Av-lKI(Irg̶x:5ȣxj$; A t4-r+>:?=`!yL'2d.H^>2't}A悮}EgE@??=fBMC2mHL1Oq*USD@H.ؿ˅ܒX<|]eDJ].k;vr͡tnieu;o(+bӈIq76@=;f ;]웎}9HNsA5/:"):dlە>IZ7:e ז󬰽3x>:QT{v?Ŏ82;_Vմ"("("m!ළ(urBbn R.?G-]Ei9cs0aؕl]ԓ~c+*+ded2JxeR&Eq쏇0}FU}5Ԑ\5eρ̇LI]N$u-b)u׭ϋˣ#:_5-$qIڱ{9֭U{#}IIXlzf}ZO)E@PE@PEແߍ#?9?;/i5| \NƜ(ˏSN7ϺM75 άagrE1rK`ƢYtn >9˰?NGMhޔcsQ=ocbib-Mq=e+v\ ޡ&C`󡂺+mݾɈcy'o_=:l4| ԓ=k~ M;oח\:-#e_&wlC]mGn1,{`J~6Oh߃ِ;fΜ@Nt mӳ+KχO룬2AdN ??HvvZt2;r;}6a܆ْK9Y$Eα9LyǦ%)Ree2[W{+ԓl~1i2{"I^ceaȥEe O[^:2n]ƛaN9bNh dBP k] 7BuM-b1wց #W.m21CGh ]aԳ#&ґu JXՌv:c$z\{}!\p^/yHLi=LL \|آ^pQ}|R_ٵ0>_=f:62nLnh+՛P^^il0Y@cB\t$pbm5+(6:]ۥA$!(>U`CDLLR!(wYI89) 3ٸ{A&Ð֢9CCL{LBVTVaQ^?KV 2} D5`}.uh;8xS2i .3wKv~feHxAҘH7}spF`]p߮$w} γm}1zPO*Uզ]g=̜ebPv$vʜqKقrG͜{&^fd-.#WSI[";u=+q-lٮ9 Җ'E/ˆݮ􅛒-oKE@PE@P@@tSOWW& Eo&U~~Du8@6taػڧ'c˾lhJ$T!]?ʝ"yX Kq'۟`p6m[g{2\ahF놠@o:FCplKQ4W.>܎= E2t\Xq.ED-Ga\_סwDalKضc?KJqA9e {v2D>EfDo97mC.>W4Ɲo.DlE :N56eUc/xuuhm`bo ٻ";d Ϛλ\9+ n'V%PPXkYY(/($bBFR:ImS} d|v2sxOx+֗1n߽O!o#emEy?d6l V⢡}PZV4!LmىOF٘g\yƅCziϩut)rtk!c\sѷc'vЉ)&;-rE@PE@PpZ"D@~ڱ2鶔s^dK Lu  ZEKU!X6?p)c`8.*)3Oy&q(:" x>useHq^0VL 2 ^LMDoU4W]? ]o6ǣ8 Gv4/pm0Pt 31 ԐGo!Ʊ%}6] 1d]pDEPP"6##~<~gb# ~v̹.WDS\zp2l#){r߹=V~>G<zq{p8` p~iSQ/"("(WSUu2sV4kI0a<$G甮s=yK' ^(> ;p&s $^sڏ]!\DD{\51]BY{xV.͛'ڟ9wS#\Nm[a֧>BVMjsIk&rVA[oYykv2Ӛ"}ט}QEwO5)If|t/Yu1/E+ܩK]-r][n%kV93ܓq5o,+mq8k1J]{g)wltkXL1oc@kj`|)@\X0.=n蚻8ȋrw>ڈr"G༾D=3;۔q IĐ+! ~~ܽ3ZLw%Es;nnw.n&0ߘuF.^imRܟZluŤDP`\mg\3 =36Ǎ%.ފˡܽ`f\:61 ֧_xҷ{'t1>VXf~躣o;`59Wy!2 'b)"7L}:}^!rhxP7?߼ӽr6Wb| [e5/d덏p]SƏ09 `qo&׌`H_(6wEuq@A ‰dp{ȁ8zetq9|,[/uuhɣ{tn#_z  ܄r"1ۦ 737Sڱ'wVIFr^rZҒs9""b€gΊzfE9s,aa{E<ޛ\uηU]N\.Sh,tƌ铱м ?.v݇V+%ulq!DAG >Uh?K rQw~Z)~٫]fqE iu'f$}XgLj^C7)czo=a9+7ˊ ^J%-!?coރ9S~Ze@:4/&͓C'N{W[7J\| ?'ySRPNg\ 档O+nݐ$eGaX?Vm i&^Zi˃5cg_a]ˡiYK֩]}=md9ܢF|J@!s}gʾR`mH 3ϱ3'A{qEs?>v? ˧2RH4ŽqDHa76xo`Zx1 ^{9A|JRRZ[fzjYn;wY>Zv )e⊰m2k2MAy/~ΤE{Sn^yoؔ^[?Rz6v<*jD˗yC3kZ=Ԩyx7'qIjL:sFzs: >-w};[AG^ַ^\Zۼ}w3<3p&{4C=é Gk7KeٰvMo q>mNg-Z%-_B^4TR>6[~Mzw"gء-SDSoƭaV8;PV"?m+5QL^ ie杲u^oj{BS;y7dXJDr}0ׯ~]'hQ뉁ږܢGg 8wU){~w KBg>z\v>0?s39iK:C$gZ\=x|+nnUӻ㵱z%+ۺۻ+z]=ZJN$ y=c/\f6iR/^\m=j=Gg#/\+(`nxzip^"?SR=ZW/9 :+7ȓw* uwHhșVP>dl,Uľʻ~ri^ӵӼQSZXk4 >/i0i"Tk[y/ Zm%]GmƝ{Cq{y`gCtm D6LjWb)o@ze~_?Lvä_ʜe~H\٤o_u_V}h󗮑? {Oka_~$2RIЩwu_?>n̂Iuzxwt @޵iԫ=>4P ci4RR:bq׻ӛ`ZK8Exs_~kCPpwA'D=!;\{[/wq=D?u}Dkw8(M!/|ܱcTZ5Gbg/_>"e|&e}V zɬԌqӗRc]#n&Y&K2,*oC-Kr?۫ Y`]e@!}zi';' jTEfHjeJ|Iٰu4(K2A[DLX)>2Z&u&|Z)i&h&6JRF eo/5";28+ig]=<濄3w;ؙ e@r2֞!"ԩSm܌ԴYYaXsB9 ⌁m<:P*4&/,{@nԬmGdL7 BIChȬҷVr% TV9%˞ 3 =)+5؛ͧ .Odkk pQ@ӭ-Ҝ3N=zJqK1seS$N;H`rkIZ~wֿ?uR9p|@>!][51RJcX6<}k7 }7o߫9,k->h&+q&d'JeKŒ8|@Ys+ς biSZ%+v<8l:iqӂ&Yek /ͻ)'Nb@\M>-jӪx f'֎ qz˰O {z܌{:Q<5K޿|M{L"2w5pg`tyFrw9?*f/I1綮]p8C!p?p AP@9pԭ[7LWzy[JSQ x5R%rиk땔RcIl D% HU+jZ&7LZKȤꑼwT3mL0Q:, £,H8s:y.hϲN0k3RCMW4Hܒ1%ܲ]Ip"ExVZ$`0\H`.i'#C=GÄ9k\1Nr)z-S0$:h/>1͚QV9dY@@p\M A?xXɉ93ZJ]xU : r\<+",8E򍄠pq\Nr[:ذ2Ej>k$}G5d4FszM羜(OjB4F6ETsT _\ ,Ps>p}oyg] HlS1yIaYj\tCmfy5%Ya25+W"h 2龵,Xб|QɍukcgOHp9o ǹv O37=V,UKKe9}PF{hnVZj#.PAD,a?ߋ=Nv#z#] 2URuxiɎJX.h+C!p8k!DH2 U)l)M5A2ɤg):OWڪ#sz_.:UW$ `4?eT&B*Fv"Lj@ D9i`Z#AbZ&Ӧ hh}7B2^1`txyAySgcYeU|2g lʀH.q9` boyAܨMJc;bs4i2K lrQ]2hcԪRNI1sWqX.i.-0jWR" gZT9qܰMf+e̗@x Ǟl\ޝ)dde.0D"tBG Rᝒ7xFۅ@3 \)e ig_tůeg H2;~l VbF)yHgB:J˨YK`+7M/jk?\OgXå>nt. q2sJhV ST&A9К}dY~~k^J>Hf][%8W2URn NrQQYk=CgMط+L×JFɟU W.-3?DA_ȅS.>1vtBqO ykGC!p8l\]C!i֫lٲ)^S^XZոY8z?UZT9 ez͗;F>w+< [rxM@t/Ywh{W=鏃8 oDVHʈ*=`$("y^(ZiYGۦ&Dqh}4a޹ڥLA>zEpOF#(<#eZȿv R>6ΦyAcb7 l;4+N eyzem^0!3gֽXVxvҸ4UQU65¬ΏՋr 2s}ҫr&*`fڷkK*ZH$Oh8} wk>ǴwHixҥ7IiVȠ:e䵇o&ҳAV2=#Y\x!پح\x5lbx,uS͟NRV} מQ`6_pwr0IR}~Bs?Sx.eo/TJI`69\0g`Y3Gp* HV/i3Czuߣ%"%ȳAjT)`}Ƿ-ñ;dK_N>xN^qq:ҡN-Ix>dg Lݺ7Ԑf#8}Yh# nœWkLG8f=C!p8~?R9k׵p81Cɒ%%!!A$lbb|:+c2?FMo$n{_.jۤc/z#8zrsp>5^{TT(SYe{Zx$=sJm!zsĞWFX )oVd7ϙ/YOgH ` $2cF_wvH ٌ`,(ͬШRLuuZ?4 %K$%3S6}Ut/uWT t3: A硥HJXCWM8;Gx<4!֌nTSz[%|w{g5(] BvA0syi,7IwϻcUkidCbDFB9vso& #Y_S)tx$@ץ}kvւa2`ȞAnzwЫ^U3q]ҺB1` D|x<6{d-лBsde0S9g0gȦe]]uuۛDRL.WsܷC!p8oD M՟u]54e" q DMh9iB?p2K,Of*Z羵[R$X&?,X#;q+:5횢jbW^o"_L[,byr#7u wSGBbR DaC;-:_JqE8;sZTkJ<*d <ӭAB2n2q)m90 0,&f"ΗK$)83i ֝ɄE~Œ0He "yu0᠔] EzJV |ǹ9uHs0ɍt2Q̵)YQ*e%6%p"ZϚ+* ڜ B =5;~LǘcW N-@#EcXxо+_0=fR{?ec9YiL ɃIc=13^<% s-/~Z.SUNRf6jmFb椣RgTϛ[9K؋Vo99LB2t)/j+7l޲Cޞ@V(}ѽK`4ُtqՅ$l4Yr="clpٶW޼jژ !Q&&j^̙A1L<$8%SBk52driϵ9P'3RkŴ*usJ9V8:s,\Sԯ:ÓXI(C͕I~\i7h;̇yS>|2m҂2sF}ms hyBC/dpw t(GL4z%!ȒpLI5hQ;Vf:s(\8(R874.{ZyN]F`ݾ`wiRe$̪s@+yYdad|5c, Ihn0,M[w“r9i!^b?Y^0xY ,5ٱM)kkڢ5pzGCZ4\<˱p8C! vv`Z/D#=^B}SҠvK _ E-W}it>!8cN8 Mj(̈́y^ I#j4EAm-sX5h3H80ny$iV tq>ex |oLznK;n t w,CJG$$a`rߟA7@V(kD1K)m|QX &eb];m4$,n2Ҥ,8G$#Dp pp@sO=9+cm|ڰ|iFl.m,TD"N9['6fe{hJ#c%I`;ԠF'bɀ^t^Y,t? r-KL:2-}lti,D~iKG36 b?{E㔟 b%)Ccm=v1zÚV茆q]p iޚ#[fɺh9|`l,_h3j8GϿ  a9e>. uL"A{Z\RJAk8q vm %H> @D!Ws_1Jp8C!p& 6W!# G{qɠܖgW_Kqfh/j~ETj0XJ"$~0e|HeTb(< C,L`*Q~=ǂGcJ v =x&i3EL#I5s.g> j~Hbq~ 6 hT=FJp|UI1,\"67Ϻyq^ ?q0_t ˱>g,kZ2꧆sq1-?؞ȏKbT>5Sfn'|A&mRs!M`r!p8C Mvu0G{6qyv/" BB?-*,c}҃ilVq,uѐ;s[TjKZHObZLg}i~Ԙ|{F?d5zF8Ad7YX ا#/+˱3juWP,`aHWڲ־3pxt:ۉN8IOOm,1>gaN /#Omǵ5dmLf=)~ g}0ΐZTP, OY/ai=sZI-ڈn(lYcǙZA8:7lM)~< '% U"싄5,q8C!p&|;|s&㳗]{4*DHHV>O B/|fYGOV-ٲ˸SH'Gd9ǫiq&a)S&=Suڼe1+ë?HѲ} S.Ɯ{剔kO1R.ȠH 7~-?XϗOar Z{4˾rtLxؓo}NznƖ~(d2v%zA] qkˮ[Y=^9%cz [ޕ_I+]_^.~-RXV>xM+ Cj8 g&DVh F'2Eˊ'dexu!p8CAi>8V"_@-! ? #r2ŝq%7 ˯I~,6V~CmX^m)_-߯G,X0?8Dw֖[۷RK㾬>E V1Oh$O0Y އz c{\4&#r H楬#USdh^(`w>,9B ϲd`^4fvᾣ Fm82{6o_cP.b,[sRεGƃ,y\S)F fּPJZ9'GM9"g!Z_]5:C!p8~S•l= |OpM'^Xcsӂ._@1FftM?|gPS!YRl Cd^,4m'ه* U!7C@ Z}}I{*P>m~;{PPܸ|2O?k<Ԇ҂<,Kxcq~"ܖϸgH\`Fpڿ]k@Pkm3#`_U gZh|3׸e|=BB|[򿭾Z>È+!>FcQتߚomZ[۳4ZFXy'X|#^h* W% s|?e$B5$7) o};7W/I q^,L[>K4r]yJqe}}||qNE+hRxEv?(oQ9wQ9^rk6Xh YbT)_J '>$<["9dLiSҦNEЬkj}ƾ$|?eesx.2(JA9u씄ghmZ~0NrekeުMrgzvᑣI82dW[vȤy+䦮-%wL6]O& pD8K\ۡZhnm哒2/T"{0u8>)|X&<f,?XCce">qϴl?(]p8C!H߿}עC!C^F)lڕiO-0!s$w.7A״?U4,׽5t>{.L ~_f0)Xsd3ҤNI\DBͫ/fgZ()p~qOR3.Sk2c,g|_Z'z̝Crg,sf7Jߖh };KI3Hi$S45C:I ҧK/~4Bz>9LZֈwȎD)?Yq[{Ò $#>ovo{hy, _ ^i}yi|NiCe#3 3`ҮrQO9!C+kFɛ#$>& )NHY$HAgu0/&"3/ϙ%zhcQ{Hĭ~(O(4Q&/}E}ڴqZUPkʘ!#.md3W()؎_ب%>g}k#{+1?(h8(]MKZvjyA؆3e+s~IR`& vՈr8C! /~잝|r?>B/$:O18_nve3 aJ|Џh&oBgJdz1O~T4o<9kZU%+knҺQMw8u۽\`^ځ D˒9wY7Yd ɩ/%owDnhV+Y0ۯe SК:p=[ɝ3&sRYݔ..5%Ny.^i,h+Pd_e2e̠f/^L (S˭@\9eѶB&8|^xF?/\C o8]YP?V|fAY H О$PK:vd\9xFEX׺h2O>[>T:*Ki&%˪5 Z^$ps)oCAI&TTH,'..\w$WLvo9|˒)GP̭?l̗#gIfO < ޗ]Rh$F9/T~ zD$'A;4O7/}21!!m4S >%ْ 93\M8g=5Cy?c>Ιg+ gYÏɼ4w{>?pר_( H +{0qPrs! 8>,4O:Y9M-c:_u[S{TR3 װfe7}̗PywWl\Ym'O{|3Zw$;)37Ν?/I֪"ݲOv'Wy?Lf0/6A<,bsISg HB9wޣ:I(,[nByr8 fWP8'Nij_7ٱg|Y\KVm/N4:U+%7h#mź01Ŝ_Yv?=Юji;p̻by$d 5[v{d- M=_jMazC/S3]GOJ 4?Fx=g/)Q|5zyښ.{gF^Մ-ɂk{`?y+Ln^/ľkxɚҢA 6'/=_va-IةшfWx%j) "5C~^0N"r XKHbgź~)9兯x;xtUVMxf|929" ^|h/caLL\aN~ۡ.$}6cJ:-]}:y4M'Ô9 Lv`FұE}/'H 7*UH, m!ml=|B.+_ 6j FQw=oVU\bA{Lg7 zg_ǃ0~}< *{6zg?χPD nCh<|;v1C7 ~,Fs'$$ѣe2vX4i:uJg=h I%`^?%Bݡy=T6$@Wr$,_=A$f")Vj6[E.MSGTMx^MW~DR1Oϰ#JSEwn!1@.yy2b@{iR24 e -, ?<||~0w*З2s@Vlsoѿ74V'Q@y.rSd5=.O@#}eH2 fVͷJʤemaZE`~:}1r$ <գ:x|=cƎ> 2uR-wۺȽL!-戄jrce5t?KHf/\s HU$d]}yd܌yr\v3 F ?ߴ3B \hJb6gt2D`%ѩ6bj%5{ s'ޫfOdڶ2j|Ӟ!l835O-ԌӔk +E˝RDiMڵI>V/] ,R>>o _}r½^{߲_Ylۗ/oj>(ɀ5у75_Oe2^2찹3>&Z$׽;F@IDAT]nݞZXhc|/p/Q^$gW1I;e6ɿ BaWswv;?nΐ%`x{9gPLX{)W;yG)朸Gσ6/͑|^s{[n|&yp!p!H _ /]vM1&Y;/) !B-\Ҫ慈Au?n%ƴ{n"/ްM@.{jTҫCy/GR&% \6xMfyęly&)Y}뎋r?y# q BD pl?jdPe4_]3x4 E^{7u kۭlݹ_ Is˓6i"ɦTSG4M1¢": Y&5JQ,Jy=Dnd r>h]e13؎"ߨu8so<0 6'O,7__CjVW 81f9v+!Efͱ2H)M6h2ͻ]C_ MyOHe$S箐w|$MÍzJ\|8cLx.;tJx&_YhM1]-F/Wjt*q>= ~ט~Ú!-ԹˤNddHwG-=۩RW}[SҳbvrƃBcϟfr]4U4C+筒-B#2̣_xI5@'ACqJ`թZNLw5ù\vxL ڱu SJbtkR dAu T\ aF&`Rye9n6Xda_\Ϡdd;Zl eŦ]I34Yӡ$m‘$h%}N8u|5ҧcS~Z"7w"}nځ4{g7iH xHRL{AvBk;W#-)7dF_4=JJRr$ͭ+4~OVv:~ҷWbq<{O* *4g%;`]6uC <0t(~x];lS Y$IϿ,oNZ,n!K~k_ P.*"FPL/_AU+T,Uqߨy;DzrH(Q$ptҪtAYv\ӾJ,kȆw szBh8Ksq`uqyag$X8Q^ęK6gg&HGޓʺOrk[JQFH])?^ig"@&UI XeHF5pܐP ci0\D>8nڼM&Q}pp9v γ-׼3J>FU,Mbۜ Lc= -Y_$[l͑-<\/Wm~6f2)Ru[wx:v~YEi2rt=-OǨUC{8vO&A[2h!µCUY,-L7Bg,歕V=Ve`8I?.JNj&2X'@p8'gb z ρVK:ؒnYfQ," n{>#`?H$\pVk"޻| &!gWz뭒-[6ush3R09U埤Iw6|"NI<._N^'_'lG5=ɱIߟ'A~$yk2ख़C3o䔍M{_2[ w엖5kRŭaO?5*;^/Z@\<=r3_Ad11^H-|Y/xF12>I-l/ o}T(UTvC+ﭿoZD'7X|{=rrmF]I?Atym܋7o!Ou'C{$]$sa\iZDNn͠ Gh"r9r+WMęv]Ю۟wW0 bw>AL[n}GO|>DޚL:wu8pqqq2d}If_,JCeڣ7uO~,<ڦdf)凧̿|Gj;+sLJepZzIhN8I+ȴMF /swsY_6ښrCd?{`MMrC3k?JF-:dvP#~#?NS3pсcZy 45\ SAA֫mzWRlq2pr]t ԊjZ;fAxFL_,\F*2hɲK@BfI3o7>AԪMKeYu[8DzGnJR q[Ƶ%]k:7v&wd d,'ܭp 6a>y7WIh RXOkx!k_MaVLRl0hȉ0&~"1]0^3=,gDcq?.zEsI|ɢJNyarMI7q>fԹ#4FB *IRSߗ{{vm_ːc.'?AO2W+i5c\VX^D~/ݞ w<ԷO\ =Ugaw#yN{_-IEB3p㻓dR79X_3v ϋؽE߱3Kw`uGC!p8~d/[ߡׄC ؑҿkSx0p|!=,qw:|"I-917R%\>u+H `Y *0f+AG@^d.Xd@Or# $"PxF-+3Y8&fqD^<͢U(x,^-x-3۲[#uu*ѶNEu:Q'㜳epbP*6ߣT+ eABPӪ\SDX 8+FI0\bpX;?yKIBJeDmTb1t 8_@ 9V| Pz R }|Xn9% dhBzRx᰷e{Vj!+L;ܙҨ]JƲ+3(>!A5(_P"8&8t<ԩګF=# uc dL~1,|Rڟ Amf(.`^9 aPì<+lkgVN`bKX'UJPԬb`:5\J8$SDCĭ x IUL!WΙɘb~)sR< zp$St0EMר)R)s O 1f=[ՑׂR)5b, p RsZfM*9+7\m8f=š6&r^bp^_Ö%VrJNhq x+c5_c j̝<&I!u/J4jR T ź$,(A6 M26(oSB* 4&@w9JugUh=wV_#Km2΀6)gP gdoHz,[wڐ-\ƽW$ͥW8G  YYA\8'sȠjNֺ]m>,Ϋ}u\԰1<~߹X8|$xqp=03%xև[8c7m!!͡k^|4]#Li`i=s0wc؇5|1Y~i~<)%q辝EbX{I0 D?k,k0q }ڛ ?.Y-mք3 Qa$ziiJ.YcQWէ]J>HZTxGZ,&Lvy϶iw̙8Q{Q?pҗi膮Q 5힣jD=3o}LWg_c4b1]j i_֧%jZ#3+_/+dkӮ,ISc |l)8 2AjZ`,qCGdd+Rƹn-gJ%ڮ0l&&;|p=xJ|p|< ߈xX`84ߗ-11HnE:T6e26~-؜ds,Vec$q eſ3PJ$l%ܶ3'e$uX8(@bII zN>=?縭^v8]a0mMFCpLmԚ҆ 5 k)e1dZjbxYoMFC/2^|>"\{>pkxNk`j?$/oɥVR{ mR{|>Z#4e6-]d"۱`ׯVN׮拶)~ i6/_i`Zp:tmԂbVb&'d.ڽV$>1fhģZ^q 6^dX~V)Il,OmK }#x?k*=gwy2"6erVپouLmsV,n`=`yM}Y#%4KkX~"@F"u|`P>~R˻R>ӵ cy\ }˷mmY]\t?R>:q̚xY*B1%S% s?Ѳ"qG".>p|7nGd8' |"~ M>k4|][|/U9Bk!vA/6zYgE+{\gw޻' .\95Jv&w8C!C?zr8ctQxLɲ FNXKhʲZW`*H3H}e×sY!yorBj}-O P @mj[H~)Ɖy2 G ) v?0668^h=D!`f>&uu8C! ,CG+LI6񥐚~~ike'#G43&G6ɗ'G8|˳8K,cuxOgO8$IO*'W͝S~]v)'~==Y3E?f Exɑmr6`Ym0$ I`3(7+e_qڽ_ Gxh8 ; ];|p8C!#_`w:{& lnW?=u"ιBy)Jn|L<Iw/4Vϓ2ɫt=Ϝ{+i;g=}2ʛFM:7yy {2u69&_!] d#g/EzҾi]IϟWyjRA윽˾䞾]#6$7s2Ym CP?֖ʍ>qơG+4vzychThӈE;QU2ζe>7ԙ\'7C!p8p`j4CBH dq#ՌtQ#ek3_{H5ijwr5|T m{UR )!B( %^- ">ٻ"HBB H|s,}gީg|Sv33p$YIi]8-й].IQaۇtf*K{4e8E-X7}t$DO mĒ.*ўe 8X#9yCl6aN?Y-),AA+`}_ރj!qQЪ$Fף'Qv?jo ϺbnƱT+8MSR֑ 1ܞJ'v/(>As(n(zs:zvs;QO˦ )!Lnݵ2L6-;P^AՏ&q țP<~$:eWmQاgRթi(`E?! 'uE*PCLJz}>d.`]ߏQ?GY?V ;Nw9?\nce^N-%FVVOQQQwD֔⇭5vo6lI^#Ƕ[q&1~kcb'}Lv:#T23Joì[ d鴟̺5!U&6y{#gLuMqd6aqiNWyuSm5|L(N:xU mCni>xxTnVrIjc.Lޔl<>zBE'hQF1c5FjPS P+5~zXC愞?Dz}^^q\cz~@ t a9 !~lmkTwZ\R2qXS_tnjܹsŋ 4t̸8l-妫3l?wk@LK(jT٤a}j]O߰=we|^~AԈ/f 2czPifRJ{?lhxUTZ^a>{pѣCepùyL+2&>{7ectm}_Ncyt1Skn7_ndzb;ٲ1qGFzatg2fd̗u좎4DPL_j#t+W5o@)9f*؂1ߘSx֓ Ɗ;~=?GLn?{@Ƃ񔸿c>=eXz˘#ֿjI/`9^˱-,ixt?n|T 0È.sBY!ݻiʔ)c=F}Q[D4ڶmkxzzG!5p;Ssk:TP|nM~xFzAlܨ~quo0Ug 3.QP1q*O{79m},߸KyzxB c5^[xmK3Z؏V`kI4cU2]ѥx{g9{V;szEHj$VuCw{ D[DѝE ?_ᗋ66YKu]Ѡ˺ķ8$u~k1 uQav66_"&(a˲۟>4sjߤ1i*z.ԫSۋzFٵFg-\Nbʍ!Wyʡ)}!rj x[)Nx6##;b&?nSMIM`TYOWa Bgtz~_z}^kݯ>A5G @tvoF#GPv(22REuԉ6nH|n`~a")Hy{mщu}ޝFS?}n6-۞[HoAիET}Y"ERASL.^l=V^&TzV[gr. @姩\^t:\xs4>/,);Mm#U^Q&jz{yjl:JsqН>ypPgdHܪWp bƤDV# '6Juq3R3 bb^ R*~5y}f,y-W <ׇk\O#h4F@#hH\C4/.W&Xh[`"T.b.(.^CsQLbE-ѽ/wCoHo=r 4~t(/ͤc; T[toNA",= eهJ8ڋЗCݚDҰP!cj-5+qH;gE'*' Yv X_ :Y^X䦤SpMēet_} vC#иǯQuym(2O'uYKStp_Ih¼ԧK\֏']\SV~|"6E`% Rɖx#N]Q1ƑԈjդ)WfdMc~@wiCn\2uIm^LN߯'_ᡵ(Ar|.tE6^C~s a=PT჉VM:F@#h4F@#?A Rg @u֙l)3 Ƴ~Լys۷/0 236d3SߙrrLc vϕL~E(Bj-ޢtyXWޞҷY4sz'DkOoۨX;jZǷ~ռ6Lq?Gb/Ъ[4-3^36RzKN)֓蓇pß-\O7R;'y:CHl[~p^t睓h-Y[g׌$&9G;HrL?ig"G:͖R2,8Yw|#;J9y)6=|S?FE}ih j<^Y[p7&PxA,1xl:WD}'Ҧ]^ZJY{gڭ)t0VMb|ö|#Ǩ.zYf(8M Wo )24-qzSWdfBXEl;22TtY+6~ԻcKV/JNjJ(^umy lDgVP0^':qj;5 e2ԲY#(AVoij%FR-ɟp}F@#h4F&h!;$8ORLH"{ t%BJY! yrz|:7;wzNp^AOmtOzϗ_z+۬{:+g8zwˡbi+rO{Yh4F@#h4?}o;vCOHwo\!x)xQV+?e +f d`T䢃y+CI:W/ES|SeP ʈ )/qT>CR-zJ~iK''zȃ.μp/Ȗtġs&z.ɏ|V,;$,6IX[}%xh|dYI=>dN^K"a<%N=~d,~ @v |ڿx%ʊߙQLs䷇׿g;91]t'O E(ǚ#tn !Hd"+UWԉ|T]'D|+lI|Re^Pv/:i4F@#hJh[Z?%Brݯ-U#=ͽLUy$%wv ,K1pY!Bd/i3W%Jz.. %,="9.rt˒\L1*HAW],YH'zHe$ΕۥȔvH~ҡˍxZJC9MNU >R@>&~=>C`A&eVF@#C/0w%/=" hq+roC^vVr.e˳;axJY.8Υy]< 'U'e]I(/~ѧ*6NzGR,'ߔۡu} {X#d0g{벗~Pj4x 1 2HSY9ds$ %V,ʹs s=pVLJ`OED]==~'2yaj@MqWBx e$lMzLQURWU2JEϪdI~yJۇ_^(owx2g_ ߶[2$!O6QFW)TTN)ۭi, %K鞦"lR'$?sK=J$u߾ l߉mWmK.mRQBPF@#h4RKhb 0Զ0x~K?,3RF*~Ըa4 T/2gUrUxE뷗k%8=O%'KAD**9I (2<<<2]4ȔJ~)q,QLd],2% !o/OgigR9%AҠGщm^ˮ.w3EPqpq`JN#T/6x{!ӝ*-Rxh0*1.V!ϲ V@M  `GEÉ H?8baNgVD&s OQ/$eD~A *P+d|`gԄ|_N0yyzҁCG)v/._RU t\>xp2Ux9s8H(A_Cy/>{X(F[h_%Pq>zN󜯫)K.ߡ":k'G+`V8ZR~n+Ʒ_Jc g{EqYa >('e'4xN%F@#h4 ]hT[PoEQߥDsVnnoL!EwV 2Xu v ɟekЎJ)϶UvmN8Խscg@8 =DWi]oISyosаb& p{$/)PakˤAd48%Ana ʍ;w'I&ڬ4WY'uI: l8 M|aTG)y}W/,ޛDQað0l |&inymٲ串T;A߽E/MقG:ß<>VYA:rc[w%a߼sg4RC_#Խhf2g8L:0~y<q]g?cɰ)Tא!)X?#–5owъ @qpr's&Z@z^F.ZGm|sn!dU 9nq#\zK{\! hyT~ Cڀ(7s*|-]D ˿cL:z xb4Sɤu3ng"gVPZ9O#%.C5F@#h~Kk4rz!PIso?=uRc9X@IDATd`j==V~[{ VWYڇt!D~j4F@#:4pӥ4hT^@E^0eOиw{khSю-_VSn妝.i,hP<oOM?@iWX|J<-ҵ>y Kʨe;#0]AWꭟOId&hk\Uhޟ4>M%Π_/LВ~N?Lf&ӭ/RA&?a%bi͎=Oh뮽X}X踂6ؽo|F[6s ?Q/(O+c#POL9vMNjӝoBv?j~fqj>C[M@t7\q7s)5|z89&(^Ǜ4eJ9nb&3j?|4xݱQ4wzUWB/~5=8v6e2MKqE]ZdE%#-]!ۧ+RKѮyk"o᭿Ȼ_9r9|~_-.Yǘ,=IX3r*\xq"}>c>[Q_e珒3mѪr@bb4j2=\XɢF?<ޚ@o|3i-yJ_f3]<ϨqhEj ֽYtlEzI~\D/c>1cOZr#]Wt-]>>_xѸmS(%08Bn٩񑜶bg>Wj{ w -'o R8_fW\;Qu&1F|>ӊkfzij\eop u~63 wOϓ3i뇏(Of8ngU"GNNi&5iTʺ1{>v :??nbӺt0' K:Aj׮M BBB_Z/e\X.3hR|8lĶVEpyә-/Qq&P?KVq0ap{hz_bHtǠK+z̕۩WFԳCK~?H)OK}[Ӵ.WK`z#6|ma7lM}w\=jjI1QH%NѠgO^ϖMUٶbs [ h嘇Ί胉to Fa*i[0=2Z3v(u` &y̢̢z= Z3 BMJ95j2rD&B۲SVsY'Rn[ zjs0e]-)o8%2Dbr0Њ2dSYlzLYm/#%儋]l3]Ԉ.ZН]hʛ"BWM{+kEUiU)|wN ܫ$`|Jm VlSƇÔ"}v)_[MCZҰ;Q5OxY7zi ꌼVQXZh .oX"7nH'iأ=;(˜ѴbS ui\[Ru:y4 Ѣ!c?E.r>DȦ9/۫ צ-;2eѺIé[]s܏tivtG^J-]SXϦ{&ޤ,Pc5oOklM׾ {l]JR&qj Vw|Vt'59v.̄"v+S}&Wxb4Tekլzt=Tco{oW-닟dRowƃ7Npҩe8u)tuJLg~=u+xM & d'놹דا"zOKzheמ{Ѐ^(>H9K޸OPu SxxUƐۓw D\%U M߭JC^L/n ţi4޸ekmSF@#h4Oc~~~귪;(a+`'q:݅p&i+2qU! os3B}ԙ}ĶBoJ ̤^ƀ(*mu|qu$:ߏWFݪ|>eR-R)?R-acϘŗELT(f䛻eAI!)A$z,4,8Uc=٪봹-u$jۢjL#o䭎G͔,cUatMƜռܸkCq헴3vg#ۀ8ihޡ1q>i$WLn֚V#t,z%śi wxYxgRys52HgIaj9l fy{p@)Fp Rj5$/H"Am{ ldgf^13p >6e3ijy}> [:VqW96d"蘔gyC3L-yxHP39mmysزamڢA*8GazWɖF|lxL5ҳj}A8Z;?eEߟ_W;V-Hz|Q?/j't"iEEE`T? Ғ8ů5>񁉦O0,tV釡HN,PF0'˻UC0gqaѨQ#ڽ{ٺQGJ"̈a 8H߀ogf^&| \f.RI?j`(+?mgAB`fxLȚ 8=wɿI3)ba7>D=EjAL:9P\R~笭~9+5;w_w9&6-rփ y *-lI[7X?x1ˤ#h5S +LTEJ:X+3/}`(=}ڬD]%|me(-7c#PLU:LQfÅz0(Hdgy&@bͦwBRu)ے&(Yq&.GXXuI<~q#[(eB6 ظ l& 6MD8dAWnN.# Y{Q[0D27@yyy/_)'jY?c;KaI6] |=wnf6|֛oU3g#'hO;H4ƙFmkP.7l2,DwO^B~^[7+Y&曟Q_!3q\dP &U:"щukC qV<ȟ7^laRl8o?k5ghF m?`|;w9}~|a$@U󓧲yl jL<03vӗi>z &Džx묞+鎏~0zwl,-;M_eAL?pPӏ/(02ͦFƑflhu1Aj;,.)sm )nmuakXڸ.J?q=KX[ x &K:]=>w~k?}AAAo]]oaheqvNcbk|)ۈ%])?%=vLSQ~2%KoT$=xh|yD,_LsΧ=`uXÏD=pxVg.z~zts)8Bj>ԙLzǘ05 T.ay f%OeAz0 Ռ /fQaj-e!WB gɛ(3 h80c*$g>W%AaJ}||&[RT͸843G$Adp>gڥ=:xkioa:c+)/] |.PLO򋍅o>Lcb" ;i[AGY9|g'Ѿ82_ɂC& |` y;3dm4.gOb |߭oG޸1 *sRx)]L -WCe*:,?ٓp8q_p>b6E/c)!85CtmD0=;#ޙBiurHUd2.gb*"Ci@c_s9㇨M&܇\ofi=J(Qqզ?8y:sTdc}rC>rYgt _=>þ&z}ßy}/Y ~&u/ lFDPOFoBZx1-[@\RE#M"!=/yKO)4{*ue11nw7ʗԫ!YVU||`>nřf|9ĂX"βi;t4!ƻvϨEA>jC|&,,_O٢5pHIhMϗV@s fLr}%/,x3έy'*M[aIU`q), .izEFLp%-pF&^sܘ8PVsާ.u[w9nFOL^el~;Gc[[7g?^D)uņm4%rVY9ajM ۷W-H&M,I38{M>|& kdlIBC_@Ӥ-L6\\7㞭S߬T8Q:zjNLTGա{'b VJ{q"AW4c4[Dl]~TTd>/?bRդ+6З7)2mh<_Yغ0ex1E1&pݙFgW$>2oF{U۹`yKl}h #C1댺wEyRSg5*2D12=3Sjw4E2I~YL}1k~zy겍K'E2ꢔy+ش3)Ϸzyk.3S\J<l&hrɫ7kq>OH r+ݧYB*y.a y$gRsW9WB8ܚMLf㭋E`w$cݓwY p ʲC|quIK wמѬ,4ֵSnc:`ުqsmX:Kuɚ- ]j2?F@#h44w pUgHoC[&N#M ԳgsZ' x8|ˀ>"[{,>4==1s'6-~F$Z}` qkv+˺&`UN~6(l51/dU}&)I ڋ;Pg>$?ӏϗ$zrJuA, F8|~u\{%6Qb` ! LGL;6R^y|)od+xz++ᮛ-hGm?l}f}+_ѓ>7-|ro·'ЗDwAIL*0ТNqүwGzo>IԶ^-n S&`7pFr: " X\ Y-oNPZwE5sb8C]0!*"V` 8msغCđ/[^#_<H=[O[Fb?6\7~|F,j,"۫9m{`Az@l񼖭M_–CS~ҭ} _no~sM }|Koe#'ԣ/}I{NO0cmHkbjѸ!vG?紓o[__>5-g#1){3)u,N]Ws|Gh 3Itoxx!!2q/K+rgt[be15jMj_EQ7{sݯ7~kOزm:xf P΋=Jݟ@?v(4( @=.~em3+|nዄ|5[[>=k5]ϸ9yCWfQluH~o LJu>A5hS8ׅ[1VU|&);ukD6z?062?)_ަ{Qv=ڄsJvw]ڋ4 _GOQ6_V3/iܠ]Xpq=.[y5iՔ:jBZ6Uz|S;F@#h4_N{aK۟M+?:k|_#{ݟh8`U7#ee3IVA7/ "/1xpz!3(m8 /8/5<&oV?@U JcT[[4e3ZQ\@dOz?VZ,J--Bx]$>-ͰugpVh:^< !,<_@u>Om=ݞp b7e1VetuXlڝ4黕.8#ʘA^O 7|U5/  uL8et,8ˁ)dy&j-tCGG&\ѡ#ʪ,0ásfdXja-ny :!ϏQm΋p.|e26vZeX SL8cݔ}mPb9Vk]3|K v" :U [1Yga۬[8c7ĭ{!Er 1gs@u b|1dO;XUcJGX! %: c~ -j.8b+g!c ֒ M([U7q`_4s_CAE_́v@n,U.qI9ȪQט'֔)`;y}Bׄ^<766d1yk0o's/DŽ: Vx#<; "sbs *Οק¢bF9XÊ6=.`˿Hnss<—aՂ-mx]8C?Eu}~@^ "C{ߏVM*rfjQ;S;F@#h4P`ė}($j֬G򕔔#4,ٿ _(qcۚ`G#K_StAXH݈J}qRa)+il K{~O؟U巧d%eB@rſ>\-ԄI% 7g4]9*[ ]C BzW1<{4yz1E`+όA7½-UQ=U=/eܟʃa:ɾ)GnsjzGӼu] _Hn..=l/48;/$*.Be/4^?B:乷=.a;֒_>rgrUoIp+gi|*==>Cz~an^냌_Bi4 "a^B))^2߂]p ~ӵڂ-F^l ?h%͒aVaC=?QEKU$,bʊRX]ER,Gt 7! Z` "GRg>i3.\YuT'?!CQ}<]ڵJ.?@j5>;$eR!`Q..mp~BVÂ-ʋJ'{ܹءdqiOKRr+]{P7&ɦwlO]4GuDdY+[e}-m%WV6"Nhe=\O|ָD~8?Mua s}`*Mq/V].\Va(QNtAYZP!,tN"L=MY]~nRO{a q WJ mK8EW%˒0;{/qvNcbk|4>@>&~=>C`Y_%^/~P9s3nUuڇLgaWe0^%.OJG]vE/~䁳d[֧=Nʝ/U9o^l{>I:?^t۟ 9Ϥ"meż]q/co_`tho dNRqYh1x+Z>K"}'_ՇJ^DHsɷD_+dJr_؝{=}~Uʏʣڀ6;Ƀ6~i*{c_WVz8t@>!%ZmsŹ!q"g/[cW z|`.~,z~\dnJ n8g<` FgW?#/l҇1R}Q[Xﱮ"˽Y<_;uU䮯 Usrr$,`wn sF@#h4FςI@XOD@^ei1()~;psBg6J]:Iز Ш9&R abwJ{YUز%[$VXX-m!Cǎ;K'lIG_yTS".$ipo*P)Cʈ[ZR&kvEj#G˺.) UƓhwjI?5F@#h4_b @AH?5@0q1w'q^ei*lgUv,QFeOJ>uX~&vi+ɉ F< w/qUtsjJ(b+#Qi2ᗳQPaIzzԿss@aٸUʊ1!V}4)^֝{hOql$yyzЗ3Q*t&l]]t<ڴ#oK iރ!%Oç-Eh d2*_?3/]YԿSs ^/tshԉXW\e\-JW.P~%:(]OF@#h4F@#\Ti}R[VF4M0A)V!?|+;9ӶRb|,4DC.7MK{x-ÝۄO)"Ǜodua8~ ֪U4G|k)M~. JWOgꕈ"PUԇd0hgƂ[e7!zEri,h'I8f %a&:UvqҬ. T7-I uhJ'(<^|/r`zг\"2҇tI;y<<WV +R<_;F@#h4F@#"F!vbۉ8)>y7lip8E WPD[qtYݹ5ԬA oAax!ZnM"C˻v d eк{qL$ }\WB9Kц(xpɩRڮ;^@m˻zۜ2t}T78-\Kn\no~F:WLuj]cR3ړqJ1++{R.q voZMra`اhPa|vV r&wKRuȔ>qA5Nhm5TtVMiX攼"ͼ˺ZRLtE֔u$f,ZKQ>]҅-Rh4c:VH͢èoԨARlVEƴLz}5zf"K;7oH}kswPݐ JMϢulج~w' S:>z_BjР^#oG_xuɄHjL=;&1jm)8|S#h4F@#h~` /S!,~.0{ÐLb=Y&TZZJfNNQ9 2HzCf6c<&ss̨0mkф{}TK53}^H]iܼ|mDړa=m["zݯ͢LXnJmkYüʮA=LM4=2M}jժ[-X/\kG5 hkHڲsJߒ^2œ8w٦Iւ5Rf:TXtQ澬̖݇q A󟚻3nI&&HlMw;,f";50#$oWumË́2يlhޚb9jr `20Yj^S*|c-gΘ׌ħT8*<u;yw'324v;>;nsͫޟnvJU#㾝>dJEǣ]0s8_>W&zOz}룅 _=?פާ%aX!r8_k|}L*i54NLt"ΐm4n86lѺuk9r$uQe('tR¢TCme17fWytll5gK8v '4oW e˼Ռnұ~w\MW]܅|س 6le\-l7mA@z{T7fOQjº̯Q0r65r7\j"n-o[^mr.coX( U e1YŬ`fw_KLmјOsV RM_opS#PܜdҞJg%yp}w?yLWatEJϦ/0:7|sՏC{4vk[%1AϠaF'=1 a-oO]D[v37eОE.F.)'fe=:s}&hрԗ-7D'^iB2& yDŽݯ- _=>þ&z}oYI}+/ۜ[mhF ה-ed‹d*i&Ehт|}}%}GcG; IAT;Ŗ8LoOSvlܐQAC:RB ||V[q%gΞQi /㜽3QOcgd&fnLcBE:SΏ,ig8()!ޙ֩u"-süu)R2S3gjmɇ.Vy}5eKȓ K[6T 1")褒e}PA(ۊ[|ق)*2ye|c)dP]Vt&ƝCŔ]PbeOF@n~4oZ_HagF6[s- !Bw4EEbY[*V b4B )@ }罛G(3yw3g|w <3v veW1y|Kљ['[jZRc%zD1kMRI>:Z0rw M"! ;c_v!u%EDZWE"`X,E"`879wdt#d@,.<-ƫIMarN\D‘bj$dkc~u6#œ$d ňzi KeH\*O"Ft' wfٍ}d62{Dέ,ﻅ+ۓЬv-ߺZ4HE )flh@IDATzJp Y($¨C& &㒐>h?h8BDG8QzA}hpSrfAy^1lߗ"KBW&HIem0qG3UD&PLP" ӓ ԩ.iҥρ}&F>=Sp\"眴gu ⣐BhяI@G:V,E"`X,E?rncta^ӦMs3p"4!"bܥfB$x㱹"ȹ~/~ Hਈ0#;UZrx ,<D$!DI"aHۍ{%D$p^Mwg@TENaqG|?sK^.ҕX|3puW,x[P10F,_h2%ػIFFMzd6SX, &s*QJZ )q%ĩ{%#51ɖ˯/3l@-aX,E"`X,M!Qm/S>JKNXiDVdd!6oތ[7<7QueP/-#~1xd݉;)qcck@IBVm=QIV>$n&cd\yHyGFI܊\j޸;L-u#vX!H0Al"ޟ/eo|#0Rh2RSQ#11/6z,g iI!~X$Vp 7?Xg̜=.DL! 2pny%8&u~ CYE-%zOK0;Yܚ;jt[=xk%&.[FϐQ Dތ9q#pDPG$gcyԋc`ovNͯM6$}Zz'7YMT`V 3Y9L \*kh!'G>c7&J-ZaqkW-ֵr]}X}?}?}'`ηîyA\m๠du,g@@Uq߻-9_?m^N4%H"j Wg޽W}*ÂqaFxŋ٩4HG&xk,l:pȸ>؟}Nˊx2ɆslD?rsː3c<?jv⮒܃g?:UצA2g3b$JyEȳA/}.c$~cO\ѯmǷHrY/0q]R ^><{LLq1xkq7!Bvs#A+U %4ŬL9ocg⳹tҜ?ɟ&`ƣ˶r׬70D"|QI@v@W\ZܘV ]X|{Mv}aׇ~ }?}??\/siu,!w@n߸s]:#YIB Zcn_Iz qѨlP!>}D˭ZW#\!7Gl$ŘmQϺ b'xG(XJb!">pH5Qw2vHsvגRc'8Lcfn!Br[/]wPDdm]q ܾ'D*KN5q#2_΅F/5)^%ttQϧ3,3⹐,ĕQёaf~5tk]BN](ӧ-aYgg 3L6\u*S?쌼@ԭ,}d\gGevƢvYwpsvSE"`X,E"`s!aD@ %YlΒ#g>I9Uo)U1""7#T߱DlArวū@Rܵh;vTB8mItvXԷ:f܊/޳{\rգ5)#猫-~U_%{3WZq Ad-{1cKIa`f>;m96IjX,E"`X,],Z @;>q:ASq C ɧ(u{F圹A@P$Skف1&ֱ'.W䆷ls#s]r[oNQLP/?{wu̘Omsn_( w}uO۪%6+i_LjX,E"`X,ߺi2Km(T?2I3͍?gԩlzn@_N;ha?/W -V#  m8u'~νcs>wDcwzbǭFe@gdm_3;ݏs:^qmcGK4n>s۹p@=e,E"`X,O*;9.smS->5*և97r1XTnnZȕS<6̘2׶ϾN?m|Ol{r)ٌͪk޳yr]Z~;]~~p&٫E% H%WJխnSFޛ~$u\hեٮN#c;UOm2]dAT'P:j-z-,ƚ]ia죶Y,(&< #a T(hDrO|T/wpypՇ r }D_m<:{X,E"`X~]ol-H`1waw[KmEVh׼!JNz#0mb<\KzGrB/DS^^~Ux۳?_~CZx0P#T_9WVHI5YzɱI}[}|oAL,^ 'e{[ty!uY̧ZѮ(p:c߭;Cf=t.EvMQ?7t'.^쫾=v•?]/NFFb#~c9\PGLCΡ|s_*֫-G7%3 usKd v኿'CVqU~> eǏ>]3?3lKjhX7UȬXa;=f@yk[m:@|,[v_x$]Y^"}O[|1)8?!fnW'cզ>t!`>FN߽lH=~'>&"zU$ @T]+/mRt2KMmnE"`X,E"`86 鐱OBMh(BC$GMU6H G2m܍Y(=ŗx@q)e&JC#s!?~1Q )JJT ZѨ.[pE9V"Ou!{eb :1'#( y9Պ2c#Ut($/܇D_hZ?.zM{![ps?C$Fq FD}17}ѦY#CAx#'SBJP@X'eBjtbܳЏpcpa1 elE5Gp~svk…ۣD>VO$bCCCL]7m񂼑nD;0.;/f/BV|_w+KCbg o I\8p'n%vRZ8tX`k.7P+*̃!Iͨ  6GGl6 7<8UL na?ԒD9ĈExeaX,E"`~ X,>JIرc 3JTn}mv7l5K-Y c3o4MAFX#ˬ'gbDU坛K/0dq3ѼFWf9H /h{:~r,vj&=r+hL&-7\z>3\ b̹]Z дQ]Y. 1D^,E"`X,_[LSt]ΤaeE,(H|mݺ ^{5=Jv&IhRԹf/Ygpk!F6ݗFMăSbo0=9{_!\^mWaYN,#>7ae,;Fm.)3TxxqBx٘5ES5u(g}P""+d"Io|=]]w5nygNe);5첓hQiɉظm7:?&D;`s Q /2с$n)UҽW,<&sVl-WHyVZ"G"N򇘿~Fw uxhwT!XObW↑_OW:o|ncwIGܡٚE"`X,E"A1%# Ţ_@ r##rrrK/K/E-0vX|Ǹ[ DRz+$ʂ%:c !f-jҠ؀xپ[GJ@Re,}"}.tjԘWað|f$H{?lW3tT`"O|`jAѪ~o{*B/9DaJ "YG?/#ceѣw]&[yta䕮 3Sc w W7т50A&ʎ:=DXmbйy4d_VzuBkc߯d~}omu%/|NCܕq}%oѳsTkuK" t 6G%*NMҲN`⬅wp[v&蛹̾ط!pe]<~U&=vflڵոnHrME!B0f J [8\ԣћbI߿yl͍0ѡ({mqqQĈ_b`{ \#$Zt߳ ?wُFԇAn͘JpXjmOv)ns+ś X1AI^g n8=Tl~jtocTX*4 3Fbu.^5(ȝDqǁi)[b矩NWj/Ydݔ [7O^m9c3FYs3 oع`P,(~2 Lr 1)(d*arv ;_g΋;Vd!Xxvnnyiy1d0f }~0tȚ3XӐӵ@MX߸c׶-G'dq^殫]r7&Ck]î>NpwǼ* *+C{ bѿgʉW>_,3W~xeɵn{<WL9[{.JYJWތ|,& f;C >|VO2Yx >3rZ#טi#?)@ Z׊2ѦYF9SK Vjy VIbR>q=Od#:~p:gWv;akѾGyƾQ!εa_p]痃6w w5k(ϰa0uTի'22"$oreHIK;x~TO&dbT+I ضks-IOG$o6b|}{QaSFeVS~J,ۈP򎡅${{>]$YD#޸Cϖ8E̔L_3k? Ϸ_nBhG Srr=#se#Z>,8OD&TՄ)UL$ݤ%!Rh޸ _qLn*fjk3_dp}vUP쑨:c S8ܲc/="$f^ٌzj4iW e-ȿm \241{3鉒ݸ!@Iymp$ODY޴C5㳿d0Dž;ޝqINBLVl<>z|7kqOc! Xxo.BvYGI 2ҙ0p,b!%3u~h'4o*iU'{hkMrNFYńuwV]X|k]î>Npw!X, +n6CTG}6IPtHΊ/2QuR@1|LtlސT1&^q`Z!$ňOqlm$K-S+cɪLb9U`\DF}b$^+Y ~6|4e[0,Rdԯ^w0ڌl&ّ|b"#Ģ#-7ps#1e|p<7|-2!Em2J9O7?E:жyc_٦-$ 72bٴ7Ȝ:'lgm..|#Hcę杩 6F !1ع22c߼3ly*B'b-lOf~%,nډ#Su۰* g7[&V/?w?Mr"pqcyxYG}Y9&8,[uUde|iTwwц2O7s!<'Xy}:Gff7kc^<o&%Py(N#z<fKUFI? VVc=Ӝfm5mTWwm1\I_o$3=`{"Yw4>{enE"`X,E"`@Ոmbo, 0 N~nniz ᩠koLHl09CZZ222ga{eXzXCK4v5WAݖɒСd[ 3QOX"b#:.N d&IGnBS3gu{fa7KkzBO!2%B/!6-$Ȇ{0}z6ѻ/=MjǠefC#]i `x֋O"۸5 5d& /ܥ3m.ag_F Lfe`x1EDKrF9+b.mڸҫǻ(qgYl d 2Rd9Uː)rՁ˅tݏ T=w>ꦒ1E"`X,E"@0%(H8ro U~9j1ѥC[orSP/ֵEۜ;)~_AevxILAŕϮKwH;ma5CI}j<.BH2i_>|¢<$ZB@RJ83ʾLWPds  uJ;#hlsX??|mc9Vt)+$Hh2BySu%ү ɽk7UNӑzL=&Cْ2<[tdT" a1r}D눎w̟h Y#9ktWP(U_m8mc~X,E"`X,8BIlk=eŲ)I@("`j\_Xwe.zrh$x$M6$Tri%a:݅c1̛pˆH0C=qё>Slg-4/$~6W89ܲR!>=178ߐIgV\m4>(gdfD>U[ mRE3?*W^WW?gN~"jc2W5O}vpxb?N']=gœAY/fGOl_Ү-E"`X,/,Ld,s􅤤ޟ=)WdT\1d o> Qϖ|R9t,wq2D;ڮzlWɩ;69UկݏOc9o'[K;9;6?%62F\POa]u+ksYgQ}^Y*zޤ*S d;)kC5?i0mOնjE"`X,E%hغE"G@Ɍs5L}%Yا½ SGF $s J@QTy: &ݒɛcI=d]9ڗXIM;r!$Ό-&Bɐ3ŗbtEYaLRyn\lpg/ږAh[DzWE"`X,E"P f^4gI%Kj7>#!Ǣ'eSGenUtهE}rx/ASv?}S{ƬKp:{keLD=uKsӹIKu\Ѿ*M(RuW/_m8l{OrJ9LJ^ݺls{ڟm,gr?ɫX]aNϊCѾѾG~W[x [X"/*^C? yfQpJ9UE_NhC}Iup<I'rK2,*Ti$!q_죟]73::$iJ<ݾm [rj@ݟgoE"`X,E7ʊ%+CŶY~_.&m;Q8$F1 D2c]%VK b:N=67~lcZf=~BB$p)vU9cRRD(wd8+#4[M:I*2ePxox1{{mNsjHV[-gxl C|<}>֊^!T" 'BMoC}u^C9jʵ㓓YVb{/#7)ubi;:dL]E"`X,E@Fٮ_;Jjqp$^(Sab:V~4vS&s-#BQ7%Ѵ H0D{r{}HA)--3PX5#GҎ[xbab770|s<%&D464Lܸtm4zwjw4q QVv\|HBZyEEDE#v#zix+.0s9/~^LD8c7ʹWTx/oQQ"#ԌÁiP7_ 3;dyFͨD^Sk#.&y仟aD˳ nf:1gq6p1y7mNՇPMV,E"`X,OD?8"`#梠BօGu)W}Q҅m{L4ܢa1Ag_ḁhUrѧq v8()9yoVԤxCj.Z jC~t<NCccyņ,vJX 1!X ޕɉq^!+Qي]K%85}8Ƿf_%j s}'XYFLD>Dc;k^x7\[`w+YPQw-$^}|:hO sH]j0c6c:pq7L|^θ/cnCMXD9a"F.UC&9 keΒ_c!iӸN $E6i:<7[hT/[P"^^=.6mcmލf bSwޭ0pdH$w@1ؾ1u7 %F#=.,ټæ0g1$ҮȏGK0m>Gc#'.bƓ7 :a7xϰ)xAo_a2ެ%j-7rO(HTlܝm׷ և?.Ƈ#ӗ/1sFBL$x7X5Xr3 Y܊*(2s`$6~C&Ϛq7>g>ĝrFxy+wdx+rğ_ e"\/? |xwWO`|imujgt>yҫ-=dd邍7p%w-q) MtFBz(?y'9>bK?0 7Ŵ'O;lE"`X,E"o"` @"?ksJܹcƌ!C 333JĚnU\L3,r@/_v3f=:F`RBDp\}IO m1I :xh:0ҬuT"Kr+.2 ukǙ:u^d3nfWo_nhFkFfI&zOBio6͐(۔/"N!)[M%.9: sx}d{julزNr"Zd#^BL(Vӈ(\s-b iRKԉƟo}P4UZfҲ\ ](8qnU!'CN4ݦAZ(;akѾ;]~9WׯjѰuO@M]W6w.KFctM:[nÇСCHJJ驾3w/B=al8[B ;Fq;n7B[tId2[n˨g˪EHH,2T{Ԕ3VS,$/YHd20bE/ Hub<׏izy~pK3 +5;i2jiDtTZl>ʆL4%\9s4HК5Ux(sJi[q} RB<6Kd EǰY@IDATp1zmbE3q@2#. Ck0:|Fɪ+R-,G"6H0!%#Eo(z"\Im;/=7^vc j#9Z(g% IS g-voVW|eHC&C^:T-)KĦ{KO`@vh BU#Cy8g-:c')!feNFbʈIBRg oummd4G|pQ9;6]kDWE"`X,E"E{ߥ /sa,i0222н{w_[oc 5DҒL ja*yLaHF-[DQin:4m[*3.Z! #$b]-{4R>MU2ò/:DlqML%[9@$̒弭D)V1_<AcؤN:iٸte?V6Kɶ|>K&>%„TFۦ(isWmЮMqyndEIB51)h/V"-qJ,>T5L$['; A]&Pڕ$Vd,tEMmW`Lf-4Q?d0xJګE"`X,E"`p#;VĜM-pz$E.24k yyy+kzSƟS^X$ |-dMuPrΓC% dIrd(4~IZZבȶ3휁'-٢IB+XO"1NyKGǖ(/vh`T6mć\d#7ܾ='` ͸`m7ƱcǰB|P-'$M7,$ە+JмI<@/t{ ٲUI9OKl^:ǐ᩽C~^~D y& ! f4m3yI6eWra<99cZG| }5bAI1E2jش{y.xx运<| wk9Kיp9?D"P.+-e5`!\BҴ|2o-nZC} C/?_,<4|!Iݮ8&{,] m2՟;Ĭ˰{Qr }|^Zr>/.C!f UGچ{>nrP,s[M7 dfぁ]1ɏ}L6Q4uڷWE"`X,E"@jD6' Y_*L"C[[ھ*QkGlbbbPvmԔL6O9떂̆uV3Dr0T7$f%Q*>ȹrڂo[HٜqYLsmԃ^uѼV(gDDmPO\Ѳ| B( n"S}'EyT͑mhqI/D$r=mc! LNXcR޻mV?xoE"`X,E"`8;ШWbsn>Vnh\1gy{l䆑WBh?$Č]rف#d3JMnI'-n;lstd2y%NOs V͙Kȕ=G ;z#Q}իS1Q*p.[uz[0ў<:G3s;~-{Tϙ}IZpCwϳqJ}HOm䟳ʐ|e]UZ5pFh?,E"`X,_!֌E׆pgQ"}u+7ńxi>rX|- ? *I>^"4 ,LA"%tL7YDخcOAIC1_ 9>{NŜ8о\*t5:&Ϣo1{raw] 'C61biɺV:껯j󴈏,U=>3_^)~zmN3.תZqΓ:n}vŅD egHj>CM04ULxegXsg->\v}pya}'ׁ} t=mv}k>>~.n>ίo_ \KY u*%}U}]U*ˍP^ }V6FLK}Czu*=p~w;LKh瞛bVЯRn|VEוc*Хj>]s6g]exaEuYW}Y2I3fX,E"`Z v y[G)䅒$sH8܎_Tζun{`%ЖbOf}czcGw{Lc~emXӢwe'_=\r?ώ{/{Sq?}6(WgF`3?tl YgQ_v8:Zg6V}j L<g-::,n殫^3"`X,E"`3v 9Ce-!1Q!*'PhG>>hQ6J)$^mhi ǂ[O}ph9}ݱG"թsVcjUm%%pPޫ* cuo{qhۥm/3aWҞ:Q{{LrޫLmثE"`X,E"`1XǠeu-"PY&/* {b&EIC qL2DZ9 }..,FTD${_9^rGtѺFٟJ G$znڏ6ծ;`\ʙv,VL3S{XSeKEIus9 Ii,x{F)-(0Pt䨙8=! H%3r]SVvcam/e~I#[NgvCmt;*M3cPtՎl?,E"`X,9"` sʪY,熀pPBzO.a{cרq7^{z4_/&w0蟐 LKoݦmBZr"6؃_q 6s \o`HLC?9׍I-0o\V1a\;m|6Nd4Hm/}8$@0),83] {=ם;soAhR_9~ AW1YpjKҔ9U|?4 P+46,+=qժ[c@.i8 lbrC»'`}$ I+NSm uqö2LX"`X,E"`,cвJ?r(w19ޏ[wӖӲFCjUۃIT%s%$C_ gZQx QKU~$o (||R'H2kopaעO׶{HH}CcCC}->[gny~ȽOu.>ɉΏS%&Cnڮ>E?S|LT<"-%dPGwnr"@ anذ6m!<)o{VUeQ@B/kB"bcwT,82c/QBQAA^H()@{{7qg䜑wOguϽ/ogCBoë3W"\ɿxrE 9x1}ٴ3Wpr*z=L=Iu T8<)p_b&DxhY[sx&L/za=7ëSw$X=6n\'HN9!{n|&ZEsn;Bt_l]O/‚YOw}~Jn?p?}}?Grf<h"`.bQr'O5k֠yꫯpwM6F&/ {r -qٌܹN۹Ko`kB+ܱ0v6bɆַzwl;b_V>hG<7 1/ög`KҪ)BB0;9 wgA, +eUү7p_l]aFoZ$+ X,:K9^nn-y $tjLgT–tn\iu)xab  kwඁ0gY~̓9*d2nxV<<pyKMM7s3Ei Tk,讻v{*z6]<0}2u?PZUHJAQcݸW'?&rah8 BIRDVM ko;h>c!j}ص: zg . IEooMOݱ/PJ%Z"N6wa7x5 ^NN^|;Ow1}_o-O>hɫh1Ścuj`/e1_7ޝ%H6}<> tYǠ9K0oE +9Ҧƒ;h5~*^ .C@78գϧmpC$]&G& x̂E"`X,E"`(#Ï8vX,C@m۶a=z4nVtM#wԒkw˪0F3KӺtf@LWocѹ='OFv)d\XwUnx2]˪&O u0P'Lv>m*+ V ڂ&x9J#A$@Sݦxn!(0d@!p@ώW X[0xmCfuW.Bvn+4$%#ֆ[L6:x,۹ IE`,5…d"!Lhu#..q+!CjD qڛ&H.C7v1YhZQ\w^BnIaYbx!rNgbxc[^ygEXy/rjs^? E! )'{1~9Opczk&ǘo KѠj$y'a-}Cc)(LhRGLgHs-@1n| 2D\omR7 6HXRs -#Mţb YKFR6rwF;= |{OͽWU1?˭صNq&qI\2bQ19gakE"`X,E"p!7Y ߋo%?mۢzu!0$op҄p<_dS0w~>AaYJ]{O`-U5VKl#BK6K >&(bFK1&%q@9-6R+3ZQmSU3FTA3CCBp # 81(ޛ hD_gȍ.TYCs5]"9п&F=v2 U YH$x:#!z`?Fe2n54!>< DP%I G&9Ef~~X,Y'>bT$tӢ/]{!yFGS/3qŀx塛+r9'>|7lC &r<|p2;aG 4ethNZ(&B)Xn?T +h+Q)D%sHTj!AemǪ֫+Upxh"³ e<#w\!iN lJuYf2P0*Ϲd[X,E"`XwM]<۹F]o\\&L-[S RUVe7_?ϫY'nEci6oNłUk`54.]e] 2- y#dP?x,g)%hp8aB[/eYO_n1[vG͘c:k/V?#.!v4`l Zs) 7?M!H?-r q[>&$$Hc3 Y`,D4O7NdG>3bmD],j2?3CႥǢ/D7$1GpRWJIŊ,֔J~̫LC:n&##3 p%xi8wĸhx?eYj9C &zkwwJdab@2„;3$H L1v!H˜bV%-zBh謑}eRZx` *2_0kkVQ uH Jspw %Rݯv7g6ńxhc}>u/`u,k,"`(ˁ /v0Zn]~o")) 7pr~;}xZ}`-FtmZKT8j3Xui;@o`#lk/`L$N6M䌹Iӷ`-Vt󖭃Ydkț\pR^SƊeYI-ۢ?DBo{yl$d/qm vXHK/oZbNfɹwu a#kZӫPJM7/2$*paƄcFEq!„Ģ<{vIdaщH`0qMe2k<5lM®cL>ZܰSKte3L;ǨɦLr,W,:[|-X܁O6еucs]g^vX#-H5VebbgkCe}/k:i%]wNc%ȽgxXɊuj}AiW5*Ơ7'}KlrE7&>5Y?jXd/BoBz+&aԘojXuQTXF|˚UֱynA@ |~G~Gw;o~P=ru(X,֡C#++ 11tO 2sj۱dlL^=MEc9L/k7ُqcVfv!3GwS4 W?'#wpG&bV܅[[Ów^cι9xc W8/MKb}j5ĐIB k'd^헠$X^X%o\+.&OW!3'I٨gȱ"EڠD}cRѸVSX;9I"cHi49qG=.0E,o5]?n<eh?\oxz׫fp %#g:v.дӤ.-+g?lڃ¨D\r4sit1#ѫM#=w=թ`5)OckFkcWbK1zC>7y9޾? 9 {O3B3@>ƴ\6oמ}_ ܁ {#W n|wIX〱h@]l"`X,E"`6:W m LϟANybD42Bպ1ҍc,֮ hvD6/.!,lYp;ҏ5+oQV_!*9g 2`/uULRFFVo܎-{%WDml/Qk֎5Q\97;|`7psA,NΠBJ}Hulk7č"ڋ񕖏% a#X5zX6qZĺ1[֔FB,(zddd1SFI9~ )D^KYk^5n`{YCњoXubHt޶dQIܖסM3 Ԓ-dYq_%fSd/ jU7c>h[^~c>NH6mcvz1e0֍rWխ0ۜv9#K~]֒ٮIk(sGmSF ɦkw*!TOX{OH$>`,=dՇ3inȇW]kw;oܘp w?χ}?}? Aj dX,^n%Dǐqr.^KxySmJps<+YC|: о"E8Α˒LGu1Eo^g91II_Lt}n:Bqu-x].WPGu6^MlgZĂ~_~|M=?\IzzFG"+izrZeSSŊ;kWs*J-ٔudX,E"`X~/*J(Q";H{܄tQ崯y9cX/Sq hX  Y|%:1s68#|lפsUy| qQUW-v-^z9]:ӍzWlP5: N%Ǟ3{x^{TY nWL:]tkml^-E"`X, }{m ߃k#PK2HٚJrewd֓nls[u|IYJpir {NPc~ҋ"QdG1tJʡ<S=4zzij0׫ղns Z1kwyE"`X,E=aWg/B@(C̐Qe#ne8̲ad尝ĜPzK_7 ԓ=rMp2dYW(y&Zw,h(}si_.ΕI]VYԫގKh@\s EKGOm6:5YME"`X,E,2 .D2]~ AU;r, )ӄ ##ՊFl*>$rlVwzQ!d#ؼ}/2y|C@LcK#UJӧn.!Ms;gPK+^>'3NHI4iXAr~%{u<QX5cZ>lu\ Ɍ,ݼQغv3ԟ]ȕ&--E"`X, wH$Kp++"͗YQ_8nlXCҵ[pݻSѳ^4*V`,֟z1ߪ#_>yc|bqċQ}628LSb}֫/AEBXC/Q3#p^>r-X]K c~랃n@ a ƣ7 al*!$I10R?1:W}12-Ǭg@TH#K)i6mayu';1WE`Y/-!`Z\]Q漏wLpކ1|p_nnurW_ ?e0TB,{mڷh?,E"`X,?<mʺ@ l1Y|{EY׸o$D!]?p\e·?'O9O9ԍ,nܠ',4co?Y']L,NN9eF{QTtx.ʗsA܃Z\9<ԓ2_;8zU,X62Oecɺh߼Qq ɚ͞q>Qyhjv2ݳy~Ԉ{o^#߀|RLXcj}t8q2CH_~gWAڶiq3G=z-4Dū7aنLhQܮEǰ?)smth]۷0=IhT;3h.Wmݾ*|(۹ 5o,e-yY!G_MȺ+E5%=^̽x85 MD.k r#@]nVxԲl->'!gaO`IнV~s\A-l7>\&,Ύt!R@^^g4i6mD!8ǺW'uXAi8vsJN "Ñ+ѮI}!L#=})nxa,݁|w3zt:ZF0O;ø)?ɩ'==!B.^xLi]^ /oN5(-8LgׁdOd|JT%S9O| `s D|=ٹ5{|$?|{*OLJ!yM=n|ٷjDKw<poqGf/\׻^joχ{~?;~iE(!/QJ>+"$$$5\/~L{c!w2 ume`џs7D1ؾ? 52PHGN`г#- y8%n|=8AsW .3߼8Vl~y_P(VRڲrHNM7 wIx@BFU>85dX /[쏩+cnh,Nܠ!r O?K>}Pnm`!z ߠ_De#\]s`W` + @IDAT^\s΁һMwPh L0Z?zbpo,{6Кu|= DJlZ5N=1G!D7bkɽmb7[O|5uM@Dx(p.c~-w!ʽ_dj{Esq>|&z\cGq3ʰ}uFNUp$Ly z4W|B+bh;h5vq&I[,X*ƝVhhH՝ᡉܡCxz YHl}IF *(kw' lq)Ws$j"ϘqL<-/v/m?]TT̀&Ozf<9#.-J{w(&.]Rϴ5N+Sbrb-L+Pz2=zwdc渨C!cZhdM"OkM{zvgEIkC7_i[}z\qq@qV{g%͑кp?4 6R"(W+9zul-ioW3uNf~&c.IEи覈ܠ -ɳ[,#P/_fyxq~7Xl}MÊ3\v.ù;;!ѨEhTŽ;#g,7N.W=ʳsA!"O#88ֆwpCztT%b's^ݝѷkBF!7Eq[vd]rūͅ=%z87#eͳ޶[|χu/h>ؿ𧀾 @[dˊŃ\A`$DW+˲DCvqEj ǵGGG#((# :x#_ֈ}SAt.AMdb]K5EzA9/Tr=BIc7\HpϱEX8QH4_Âr}Dd3E8D|%xJPI`I>"Ċ.*ۏ8E[!|t:*.}#nD,.׋E5qpm{ʾ]QTӗ=4 "`(; r5y fqޏ͛oŴiЮ];|WUWnzhS7>l D\QI1Myy˰IZL=I f #&Cx߀^$"o// 8ɑZ%##6̙p[Xi"Q\Yߎ2CQ.Xn\VDEB yg ^.t$9+W, >X\*ePW"q>ʕn3` lpzYroIWSVN.p"ǐu!IIMs+Kw`и#4;OM7:_UKR&i,Dߺ)&H 0c`RIv:f?"֏2I%FG_r>S[هt&\ "1٥jR=@5zKC6ZWxx##X>TWbN[++_%2T%@=) 7 g-g<"։LTgc8daw}>~}\}?aYߜ#l?E?.kޮi'8|0&L8 6Mr:\?Niu"XFXDsH1( $-~ r1O-4],3n$ŷZ!H #Ժ1FOZyϱ{bt$+s'ǟ{t|buFΏDި^f6&+ᢎ #nF\ NR(cf-S1pI*xmtБT|2yDH3Izѕ0U, y&DQS8g½ap͏R>o`زED/wʺVK^z{ DA_ d/C𨀚A4hfd ±_qQ'\ CjUG=}uث[I,ќ\ q9Z\d,qȞ(y "!O9#[ϝ`- BU5i/K4.׉j۹z$V|7իeF=|`<5f"0c6;D7o ZM\oMuba,PbKR#2v ~r U[*ӭ9ǐc^ C6qёhA7E>]ڡ$2jGE0t& uiV~ OO~&\On2s$jAb۶ZArJDS̉Ce%Wrd]XY{&\$\ӸoJĒǮG*#؄ 5]p՘1|zdW1_OWp" 9\ڋNVCKf_g#8Ɨ<.LWb#⑷M~qF|1~^u(]uϡ]ѿLk}gno'k~\~?yσ7K<<ʽ5_ZO+n/Jm "9%ߙ%?}? )E& _8nbn7 B#ZjIˋP0Z:pql!gѵsd6у3OeWSVg=tԔI`r@(ܶG,OF*oPq电d,ZE k,J9iYsPta9ĵp̶>`cIFkWPgr%!$J49=󔣋C P ң~+7<)^ mVgI)')}׊5:p,c:7?&Ev;lqYutemqΔ9E^`FY[r%C+hϡ#lҰbisD7d=t{/^-O ݼ9?fCEĘ}}Fu^;rYST%㢭o9Q.1"dP(}=)ݲd/ҍ\lhƙb Z[scًtWL,>!7"~,uL`ry!ḛyn /IB6)V$ʌ'lU\3›|;os,?fU\ufKci|*xŃ޼i'x3xzjny>4n/?Xhî1skI$Iǘt#7Y,vesyu0P?W79y*f>Y/,KbOdYf۟d K^y&4ʥ8eIUֱyn~?=~G ~?`ߏ,#;;>r=$%anjw^Ӗ}PC(1S/vYm{!+)2e2eO _>+CfW蘿|rH{;ekFݥnDM9ka;XL,Z=|xbt5>7BaFW>'q~}Ύ"IuaWg<HLy~a5 7gƊ|󻒹nͫig^Ϋ%վ6mWN{}f?f|ls{]'Ї.x|Z@,,>>wχ}?}?~'G~u=#j%uVx"p.|\\kKg[`Y:^eV}t(M}ys/QNN帯l9&oS0kH`u-We^紓D_=y6ݍg;SiJXgW lX6&ܥՙN|&[JSZ])bmE"`X,E"p! eq`˵X ?/| us,,BnrxSjWePaUdSp=j't#:|:iW&hyës1՘|II#8 5k=+g m*>^u &Sk?'|NֱU:љZykYxsuw҇%8.pצcue[^$ZUWWE"`X,E"P,XlE%Vܓ(!v#&CwW%^(8>)J|v3}YzfÑz#'͑ ]й:5W}]_4x8:|`*:s׫>]:=^ z& +7o^}}z-5Kkw׹:}-:X,E"`X,!` Puo(ëJ$HsHh*XzCב1H1电]Cl3;U$D43۵4@.ۘt)|ƻ굿[ֹJڷ4xew]6όunVgvW\Tk`GB6Cl%~T>re%vw8&ӭdSME"`X,E"` ߋo%28@ l!Yz]c8r$*V@ú5=5ԩar̺W -OPSD=:7RD:jbքڗz:8a9,;#VfmCpPtjӬn{busAӆqqDԌsq"EJi)(np>&Z!$$aۈ/0到!=SOe(<~U ϱĎ($riq׹QXUc!ɘN ^8R,(>*o͎WVcK0vH̝cV2ʒ>bɤ19-!ȫbαdEpcѯKtj‡㼑~ )x>qe%>,3oq~)s"ADo֩"1J|r7^丈pG&۔~}FL3ssEnph?3;ydKăc}>jv^y_þ|YRd2X Rp G aRBC闆WRLh5z?Wf ^zty!VXGMKlƸq$= W]c "4"vLǓf`B\=5!H,sXY_ [7u%X87$f-ZNbqǰAS2~XL~z,Y!{\eX-.i.^لciBaΪ8==p (!2W?ǵz#EAݧkUҵMH'63dXmq?&16:C EYѠV5 VnDfV6 @j^~`s-~P,"Q-  uk+@ rOA+k^\y1eF ֹi=7 wNn>~BEl-&[|C y\Gtp%n;JanB\5q/6o~X쿞-0_WԨix-լK#n,v[?Ê]Ɉ =ql޹գ"1w6:ahUɐngVu+.Bqf{&bTԎ>Уcs Z>82n=l07 ΝnLyŇ;ovNp~,W5~(K_"` z))){aƌB~rĘ~zPc 3+ǐM{AU!hFk3Zs5kT9 ի6P,Vߊw jۯDتq߻X!˕GX|$E\lmO1G[6M]ZDmc_)cw^Blܾ bWK0{*GwsWҮmгe 3ڸM…0 )!*GyAB,nإB{/e`M꒗c!Ӿns'?¶]LCG;jJ\ܶ!7Bseo<4?mދW>l!b%%W B4ф1fn+|ذn}H4'?-å>B98Gߙ,ryBRoӧ l_lծa~+ޠD߄&Xy}c<}b(ªT"3}; ց0nZ<-%%[B7eۦ r"1+WAVq1fSyx}mFǠUÚxbyaκL}5]{1׏EcҵF6),f?,E"`X,C[ʈ*?l7z믿t Ǐ뮿"?ZG5tX?|('\piwEhӼ!#Ū.3+/cw}7 K=m8r"M s_? GNmclڷncpթ d2%ІC8qq\Lo@,r_lte_+-a_ZArDKhyP=)U}ѠnMμ|~sX y;pXUDVN+(,8Yvƣw\g,<27SV9CL~q*!L0e @moiZ!ج!v& >u#gӅ־%HKXV&GX%V4.S1_0b@ώfl1KBnCkă\eCCqH3IRO%yϣ_!W\iH'?n;^ e _ƔLJ=hs^]zh0q =xdz{ԊE?{܃!xjP'q¸,9uI1[MUo谈+H&?M Oɧ? Zy5DKiݧ;fTZ C қLJܲZ42=[tޙF/ @":8~k,WnF.0Ҹg()YHKV&q=$_ȕY/gEb irˉ*#m+eIƅ։W7A\ZfY76E4~ܑQW]d?RS\?{~ws#X&a!!+nw2eE!$^Lmd!vF' `lB2912DR9*x+8 sC96Es,!%K:-D&R ֯|4 k圿ZGf *SWn3$.Wo>Vŀ}:>_#k;%$(mo\M!<1KESK?-8 dp0j({ԍxYt.,рeKp³#дQ} | 5)\)"y*/Rl,?&4nŻ ~}q&!_pp`{yyf؇g%=$'{XqycK9˲cY(}t/sME"`X,E,X,(>@Pbu֘3gƌD|׸KmFX^ 7ݸj/sԲ&ƒKʠ[DV>qX51ZTy!Z8o+3k `a`FM;aKNpHERUҤs׹7n}$_:gԒ`ukŠ[D' @qQ)ԸR9A$4 '3L)~S~Š&y SW:}ePkD 1eO #Lz_TMOVN2L[V--ԉL= u(ȿHQ RRJe37vA\ӷ/Kk`F3è{2u*l#s+%2Stb#7gd93wLЌ>Zq$`K%19g QѐObe"z'+@ĠerfֆI], >9αD[zg"{pL`u!-Ng g?a]Z6x* /3xIXӥ.qpMb}$`EBɲP Ѳn%|9{9Voك&bQ~jl= 6-xQ!ϫrn' ⰐtVMeIF 1c/*/xwjb٫N_[, Oe|}?UФ9Y+r]޾ZK@axh6D2օO"[G+bIis3s#6*-4D;$Yכ3#)#&xGk C鄦a>7c9f.(fb#$H-ٸ(:nZ^=oF1{Epaf֭2cy T8s]1㒝,5\O5Wu+yer3Yd}z4nPDS(MYY+6[p$LA},E"`X, sIGbϣO+nw~_88ٕZʌ LϟAN78Ą}8h ?͗6Z  ERW'EH1 +sLBPkU(N^xkɑ6ʍjUL~A]#%Hc(5WR@)ևsw<:3)y|f)҇ք^ʦ|yv JΨt5 A:<˺ CXNH g1FyV/vcɾϳ%u-@,isπ B7Yǔ+{~5ę*zbA짮H Lݘ8윟l=?-8p;39㾉R2OOHepgNjddՓ:RWLXqKt1U}n µPO՝u}J9Ge1Q K heUʼnu6Y,E"`X,|deo4Io4Er$`fSZPaW~๸Veƻ1T:6Lͧ}W'([>:NVKNS3`w Fͩsa/e$,ACf{~1Z+ۘǗV:8`$!xcG׹~Υka^0IeG 6٫E"`X,E"p#e!+\٥[,G(Z[S*9«1Xv˥\icjEP9rBpr`^S"sjs6C}Ѐ1.S;D"W>^ixP],=q!؟{ng^.[:ߨ(T[[8qvCKkcDzˑwy.g)LeUhm> ~%659m^grATOE"`X,E"P,XlECGpn"$CP2F:WP4JIRאdH,CeK]:5J>,F mg[gS69cŕۮƭWI qf0LbsM[s)-?(5k.M]ưY (_+(ȥLƼs_UO׌\iXVfqb?ެVu9l:_۴^-E"`X,A-"P _˚0~.ˊӹPw[Ѳ!6ItpSэ1"ď[oV93g;sy%H# LAAw8>4^*߿Oh]3QNY{N#7)&]t҆tT {7K/yk|eb:/:?^Ue?wvֹGYOi)o龲Cow^?t/=ރ̗%Y,(>={_UgBzB;*`Aa]{_WݵkٿuW]]+(""%B)?7/g@p™ywfΙ33ߝ{qΌ|q$6Gbt/C;s۸y+\kTDyw F?4kvg;px'k}\숎({9\؁:)5k8cuZS;YXJl컍UkK"("("B76)x"@ݼmֹy{_c..| }'+2_S2WY}aD# emؾYvqvU<ˉ+"Rviڱ5_Uɛ޶ DZ牾$<{]{7"_O۶?dߘr{.,&vnm1z;belRI4h|)m8Xۮ]zbHV~(gC0%;TԵ6mWW?\%ގ%82ʽ{Gu}TW!O},TC5u}kHJ)R(GK*aMXO=W6brF%*"e(=r 5)oOfaMFACk^=׮-1S埤a֠#O ٶyCɴfm<{2T(_a bm@xD6LYJק3^$/^{^/F):w .u*bdN=~x"훺9Z ]ƴfKѳc"!>>t'3Q;!gSPgg<};sxiԎ6t|b7טhnbzwNC͌b^ ^ _cxKмqC6*ȵpCk{Ⱦ8thQ`cYA}ڡ&E@PE@PE@88؛H"~gnyֹNJ΍W qc*'| 𪨨fW[YT,fVd[WXN7⎿Cii񡨨wj$ScK1عk~e,2> n{߭Xg4=qrn W? F I[5wzub܆]ƵY]>ζ8dֹy{xyGz`ϔ,]|_C2CR?G{Hx$("pI  r·/k^beL-zU'd~XHǥCc !LDE[B1, ֒cD13!^ruk'2Ɏ|' 5%aT\Z*Sy` DB 1!S#ίxEJ8.SEI{+_y2X9#.` ٴ++Gz)I;3!"|ڳ>>n=b$ʼ F%^DѭCk3WF *T(##//B& >^e"qiH ؘ(ǜ+nyBnś?a- sL$xbb]V~ه0i$}:dEE%HrCP˔y/ޑm߬Q*;s!yc`l 1>?pثblz2';iC{to,iRQ.ǜ_=;{[Nn>\[[!Dwi@7szL6(q˺)5g_> ZO֥][/B4:*emڪ_[iMx֯[̅ߚt}ܼ}?7oGsUhR]E@8,?EEE'11ѐe|aM {oEb%B^t'xUƜy2ԯD,EextZ\٦>F KץP)d9C;[vKkw V4.fce9H/QؚF }b>֧؜2[3кY#W.8(lؑ34&w_: w4s\ymFGC;5.dM<-Bnڭ{1+ YGRH2X? A\tsϰIURፋsjѤ܍7BjŕJ0\"^|^!ҷOfI$\טq mq| "A\!n2˟G0qn3 K )$ؤiyщ ܒrnD}=ul>IF\{ piqm<5F‘?h#DRMjCis[PnC~s59Y3KKqߵa:<|<׬{1l`cO 3`L|o|.3)7#R۵`64tJkaָf Nڜi?dE\h!̴@o}%6]p޼܅3DT\wf/s9yiRE@PE@P_=¯~:E@_#`?;UVaرxW/b޽sÁ#'ɒ=^I%(5Dϗ/;xܰ w  +БϙPwWg?3 ˴;w_yx{[5 #' Wm;SW !T0ϯ"):owuv{xKqsp}W1B">4S/.uD»B 0sfO E IFY4cwBDCCs BK! woʾwUx˱MH?3x@1 YK w^m2ِׄQ(ψ>ӗa^B&)xKѫ]seH>d+٫w=0mFCDx_ʻoS䵣փQ'¿Nӑ֢1hx!Fx_[vfS^Tqu1w1UK\ B̭cp˟?Ʋ5<@YVz/@`__r 6`n#׾)<:޽j:$\G1;4k=!>o0&\<-_k!n}Yx#oo|9kuY${j__--aذ!m?73ΗУe|еx暳po Q(/ Yoɚ|Y|Fv.oB&o`E@PE@PE@8PctXƒTn9c]n0LܫK[TLAo 'N/9{b:oB&ɸQFֶE(s`gމ S)j{amN- r390uc%8_8i!Dns|` z! 3fj'[` /$|ĩu;0q"9$wµcFcÇ/A3;CUcyٷM/[,!˟} 瞖f<7yK&| gbq$a!'}CO>obPf=8^~ Dlfz̜ ;!VBy7 7bѹmK3.'~Fpo7.:#No|.af¶q=„X3v7%+5;/7˚obl~qsO֝]cY4ʔץʽwS\#>:[χ]SڵOHG)@~b9ayE]{٨W^ˢ#_&Rw4/*ӫ˕}DP*5W]DOh+*dz H/<Z!ƽUxyyrƠg.`?wK3^vK/'މZH[q1fmѿ4!e_9ăߵ!vIhJ@]:p/.37bؿYٻ/JW7)gO]aAX=xxN2qn,1{*l#1x!BТq}2zh\=d{z(K86ɴr!ӺJ*Cmj"D)=ޜ<{̒=|CRa\T, >x~#u:{٭ECV$9xɱlfa.)\xӏ>[6WgCBomh +^%fRq-y9A,P|#-6qOfc'$k pH?CO@`S^QnCChk2BEr NY:4A|L"̹CO6%dϾ,ȍ R.㰉ϒ#M}vVǭs*p1qC5u}χNp~C໳}U #IUEp_@oƌ˓ !S{C%\k1n#d#$Izud˄!Ô BJ!@ds?&L9tC$ܴ[LDG9ԙc$dZIqX*ٗ?qXB)%{ JAܞ{:Dhx N[ʃ3,ƼnB;'rC75LVv<Ĥ`#MbI"&^l;L$1zH/i~hSN^xh@DŽ)h=Є{^P= Sv梣:' {wZ\oCSHk?f#n)w>-s@Dc! Ncʸb47!Ϋ5D&AHB/뢅@NV/]c9rbh۸D=D;K{1kG $!G\xrdBys߭Y3;ߵvl9nAxw$'{:Cc'*vEwx 6~s*z]: IԕC5={]=҄ |\U=s[zUE@PE@Pc 6<&sQ04߰ssQѸ&~Hdۯ[y^mu,&$`jj*7oT\mbCEB(:i* ϻRZԋ'6k,3M`&}{rzNѫMkC(|Eh I߉vuciQB#$xQF[i߯CKsc]S̞sg^0mT۷}MXlS9m!A$-|r`H[3R4 M'c>wH`ӫ^<:0c#5y ~&4{ pj녈IMǧD#v˚Iih ؀H| ЭCkcWZi$UՀ1aGrbrϧvnfgZ6 SFq|43{>Sg.Y'>h鯍!!{o!,d5/ފfU$ȫMN劏] >}&GG}?`e)<<\k| Ϻw4)@ _~ ^#e=h kx9bah&Ocr jb>j{b1O1$\ۦ6:x a~se ?>Yl&lz։xIظ# cJ+\Hr!Ţ$TPɵC05+~ 5ZadggoD \˾$\Sy\3{ٔMe &.{Qv[7*=Xc0MEP!kүin04&DiȵX܈nmsc_Mׇ;Aߟ>~] ~G;@k|pJWТWE}pKrsG aٲz~t40kEO-sdGDAW DWU[clWm eJ ۓ@kmYgېIqL$ĬN!l]0Es#H!$vy9+^w͎{dbmo*B;΃uV`VFsĞs6oE:iQ}sI5ko}H8R8I1cŠ"d.ŏHͳbSڮa͋4)"("(~8@گp:dE@! kxHӪF3t?v,[}7oICXeTgX\5um=vnݡ9-۱lG}]'pmzUE@PE@PcoPtV /x(,A`k!* "&ٹUyʼߡ;{P6m f;&[uv<,3rQvymW&׾-۫+ͳlSuyQa>Xu51rCLllk#2{:_qZ9mQnm1@lʭ̖m>L4eS\Sllxw^|gշEB!=WQ4_$ K$j'zK.X+Jl[аcnұ6w}v+d~U6wzYgt<{+xayJ_%j}:F<.2 :*ة:ؠ+̞빪2qߘ0|PjdmѰ.cMx|lc?CQUoM3WLkja[ꅆn]-VU& X+o-MW_LC>/]`Nׇt}Tm1C83$I #AIu_E`q:'Er $<ٸҳh6m{8У|]Xish۪)R$0RD!r y%!Ihդ!BCCiW }./4 M-;+0Z7GYyA]b\4veæ-;P!a4CrBCY?%ِySFVW/o߅oކxtl 1;HDcÖ_XMAFJcq̳\Cw*dL" k6E@PE@PE@PE࿀4])x4h"P[v[TN=ێWYjmJO-'V b) }G_n}hX1Ÿ8I @ۻ^3ʐ$~}cvK(u1۽#>z1ݏWg.E|{dhb3כ=Wmځ{xh=vdŠX;m[/6ܜ1uj .:ڇѴ^2vhwf.2dѰ~=|| vgwRv<kXGą~͑/Ͻ5/}SQ?.EsZosƉ ,*8PyʘTyzcaQ|t}%}VjSyV&ܼwMy]>t}ܼkx?uz$DIuEK)[t)z)[xmLؙ#[ )>ƈ}B {a) nxÝgX/0qZf -0Wo<9x7CޗqQqhogeXӵ-ă0#'O3^g^M_Sw0ȸBē/T~+hb! -JDŲ Atd)^$=IiD 9{ 6|edtEK=m0a<=֛ffI1-d*/ h\ {&$&ř?l 4("("("B=!7BEp>y%9kFдiS̟? eȑ\};NibH+I ;ܵQjش-?s0d2!K%cbeܗ=ls|'s<9D=QYs!eTKBʼn_& ag=z}s(i̗ iD;̖7JI2u?~;*E@PE@PE@P>~jۺW}wk5(G@M7`[UV4ifϞ 2yv|jd;Kml;_Z˫ovً^7wc8\;z!L" A8}k |ஂ"U쏸EN$H-y yPxeѢA|v+D_0E@PE@PE@P{',g]qB?W]lx6mɻZ"ζu?A2=wUI1Q&l:鲍ג9OĊ`I8'Оt/{::E@PE@PE@PJ;PT1%H024:-?/g챎?\}Y,yH9;!?eYEmqAmkpy>ܙxT&+-u^}q1[K٭?*"("("/P8Rp:5:7eK(٫'#!c}?F˵Yo,e>y+k`(cvն 3v\Mkӎ>!! ȳC9ٶ1ؾl[ 9m{v]82o$V7Gsd7s "1X=y>u\1^X_^]][yE@PE@PE@P{XThR]EZuX-9Ɔ!};r  YQ#ܬ ~m;w 9!Qز3bglȇ%%mrk:6aמ}j:grmv+ֻWSiGf6o@IiEF[;ѐl 9H򰕢؝) afE@PE@PE@PT}n~uk=wF">|n7yjVN+m ^w}{s)<ťe#)We,[yeJ e=Iblﱿس׵y{ X!eBwjf57lnZ|ji7!8YaɫŀyeZW͋L޵ʳ3mO?/bo{ÂW6쇞OM?~֮9d_]ŋ-;vedsݼǭs*?z=@χ}>w?{h;MYlW9QD‚pgB_旴͢ '\yYxټ}Ġ^d񿈘7xY;lAImږ15)|D 囷xIjmdÇPZZ~="IuM0mOfL5C>iĄX!C|&_aq}:kK;1Q?|Fߴo`/o=CxX;gyr=q!>&q:nYKWQ|sۖ'ֈG.]+zu*y_7ً|EEžX~ a|6ko隍rNrB :>䃙@!(O+>>$xł5| 7C}?}'y}?AJKKg &=5T!eh˅!e˰rJz!1U]|<> xjwүQ[L$P;)ۄ,WzNn\|S,E- 7ۥtرu޷k _bL&w sЪYC|&~V!`Z4ϼFuРnm|9{>iN(Gv׎ ܫ8KzMġmfBʿ[ј-FeIXc#qï`PH.zi ʲn<y[ _ԇǣ~d(Vmځ|-\Xhƭs5#85E տ3ī1*23/A?vU 9K Э}+i!a8VKM_}%`PC~Y RXvS<tlwXCPE@PE@P?LG&4eB~("p$ 7|7oFΝ㪫B^YK`x5+rpKdSCxøh~0x7Z>?.xY1Bh.YŸ8w! 0gCpY'b/pgnCq^չ-#Be E[s딾WvAdr 0l`s?dOD3Eybî|=% xÖ.y]}VA2-*"("("4?{Mm"(E}UVr@HRtLMV@}#Dnq Im*> n֨^`2w/"A† "v d:q2]" Y]x6me$ dz%YbiS'6 w_ 16?,ZVE@PE@PE@82~*% [R@}{wѬY3t>bccQG Q78ٺd [=ss$TG⊉Ջ@ƾB6%'2cڝe?;96T%!'w#IRmH!L_}2b9c]hӸ!Ke>;*/@X0q1색 @,IEM:WT?۶,HY:Gvًk_Ä.,bٞ|K*--Ɗm{pb4wgXvL%ycA1 }q^m-AR4Adה,aYLE@PE@PE@P~*8Ǝ>oz}[9B {+̙Ƴ/Jzh>?؆x1$17]q>睄VW&,/W5J70z'_exSiܟB<`s#g_>c$ Kɶʗ'6Q&D>z+ʷ?#ܼgb\x%C9w SRnIX_oo+y!^hf 2.??O[S+wdLl˰r]<mNj3NYٺiC*,ŔǶ|]f0k0녂cee<[ٔx:Wwdkp iXMq|AͳNׇwMy]|A;=3 dҲT<,Ò5T.CX*6nNm[`֓n~aY4.l]_BZs}BiգONJ'%tn{5g 9` ǫO|y|m<_|t !*c#`z^Z{Z6o|{vEdX('NM l+/x[7}b%i(cd*s+@xhk} >x ykW;.K}%#O{o%8I8hR;8a2&w$ C;VoKf,wM yُp_en-'kGbrܕ}rߧ;Ζ }3qv~UAߏDCC uBsvdg>Ko톭Mm? 5_^;ʝ*u;vWl'@IDAT%jy!ʕ[io[9i7YT_^~shHlLte>v_׸~Y97&: [wdVo'ދ3vRwrx֌[_נyT;q֧>α>}+WMG'')hcr`Dzuef }$W®.}geC,lլX|k's ؞!oíos}Qq|~_GWAiy]Ѯ8l~ǭj޷OPJZSP d@s_{u7T=TeZz+de*Pܑε\v+OgV-t>5\1ztDx6>؜w9Ř 6pAul`ו3ou%٣u6Z;^"("("(>N >8UP$GhT#._XjJR'5F$ѩS0І 6e-!Y&ʘ}H k=_oL2ʍ2ǵmSa#⭈ĉu=ckN>J*mfǏ+j9ɜ (kyM"("("(YvnOJhh^:?Ä6qĚyi %$#"{B"FOC&y#m_ν62?lVnI0X{Hyp mUI3n9zRޓ0-0oV^mܞ#hW'>WOJnt<yOdgVfE`öm *"("("p<"xuVl%+Tǽ'$Kʰd:ݸeHAmѺYCpQ~KV}yXnk%?M󆨓`.\{Lk핊?oǒQ @EED UStLkZ7c5OP}pX_Vnv djSA۷2BlXadGV+4p Gmt)-keUgî}>G}?=` A?ص~~pA$ĵ("p"B#W /@ Tjѡdn={⯯Lc'Irb7+pѷaZ E=Dc )*I߱ ~ WʹKե%R58#EP_X|nngH8 yV VosElcp6ϫMjr`Xhڠ#>O&ټ}Mr>5BcXr͎ˎS"("("w23jS|SjhAPU,ydg $[1WbףO/( o!+&%cx ci`KQ@)$[ZR藣vb<?~$'smU8t4 _=qeg#6:E%c.ڵl}`[f? #3G!6H?O` Bg (sw1/\%L0[N?bL¢bLf1؀#!6c" UVQ[w".& oة1g4F !ÇhtkTn[ U_pߥ DEcip3_( 7cJtSy "#0{jM:8CӪiC Y\L4 5+B{ -&WRZ& +֤gcLx1W_]6®=PN8KV$'a' {0q\dÀέ3k#ĦUIL_b նRm0E@PE@PE@PoL\u"p!` bܹ'33ӸA[&X,aq[P/]Xco5z6Iw^Su7^/vm#umq_౗7D=Χ{hՠr q zo!7o?Nx<2L f b[ѳmS?~пo>:]>ZCgDhY8J,YͫC >mcCtLNb?lgR>#x1RH+$D5THRCZ !;T{bTNxJ6cfXS ۱++䣷7F>7?1/3 +{S?N!i[j6uC8eB8 SCCugZkĈg# )>NjsVn>s7f9_<՗Lo2 y[0~B|$0 6ʫ֡! 7(>D]n^ׇ]|7}?vZ+_rq"u`٭s*W|!Y`ͻy.~:7->?*3{J K$`%sӷ2T-e_r=X;1˷VK?UI[ϸĸʗO̕X+%^oK M.BO8Ah@Ѭ/|JzT/)g;K&d@ @a a "ZuZWUmmiUTqD+wHBH7'gy9w/{x9rIp4} ^`2RmPߺE3t<#uʡ%; wU}7\7F έZ%{{ON ƈIy5_jcgQx*,)zs;\d5Uzz^Z׉7Uzuڱb_*x9Ue&U-[QDir"쫚:{QU /&FOt:F/mݿ}<6c`{>|>hнf }~0Ҵs! "sO2i5BmbҥвeBPu.sfxo?zq!MοrF-BzwmE'_)1X[ۄ[~s6r}Ь]e!°}Yb[J&zui) 6F}Ba{o2"V{J}O -Z$nG S1gG6̡k ln2阷jm诣ƅ.Nr|!Bϼpp=+[NnPN=1f|omRIn/1$7sVh/CdB%At }㤞'LE?A(H^`Z蚻cBY6t%vV?xyLnwӜ#6?l~sOÞ| ~ڞ|×|I;7C.C$]T]8 ZDI&G k25mkÂwG&M"1RF["_&x9w&^<8dx7s) NYxOx}l}2o%^qzS0yp9Zg4S1|@$J,\%M9dݮJ 尋kqƀn ƋޝB!a;Kos`eX0w -\n8 |w՘p%>%=~S`xti+ތtrmݢ):dg>e+qRhת9r۷sfㅏfb<4j ];EʁR|g!xmظgw 9.얙,н23IǕK^'h 1|,oߟ?ߙ'>N9ſޚfA˘״ zOa |=M|=C=V.N |***Z}dɃdiCIy[0eH<#o&-^E׉*dO5iQx.O2U݇:[Ż.fĉWZ[!i!F(Vo898-$}ntT$KHb0+vl$vŲ]*9U'?N>)H#e{4ۄ"Ӌ[ LN}B^Pl!ą%h)ymq.}pˡz.+C}þ3P?4LNw$*9'0Lk '-s2/O[:J\nC$KaZL‚]A(''7F[r_[:j_!`!`!`#Lwe ņx0&'R䁩Qmc1ĤDqmÕVwbNew48;~tŮJvm66$ukKVeƒ6$Q]}>\[0 C0 C0 CxB`m,!`|* H] N1*A[rM+6&c JrO?M}k+L=z6$=^ Dk?Ld\o>o/+xvk*o#we:?yjpOmik0 C0 C0 #O+m4N@h кɥXIC"'>z V)rsY+-slM/'S1ii3+i#_?mG˝3}iݠN 6#؍ߙ Ak]JTDǕ} ۬އ,J.`!`!`'U1Q!+WJզ,rdJNLN&Ě)Cs\ڵ&h#31O8Ï4_UXjÏ)-RinMͯQ36n+aCZ5ۓWVӊ C0 C0 C8 X{퉅8;~iDaE8Rv(V~L#'k+srouIM.wGx(THUGc-|=uuG:G?_~:W!`!`!` g;`A P#q5r9oHa̘B@= Ztgm1O:Yk+V0 C0 C0 5BU2[Yl`48:CQuTyY.k)1eR!+ {ug`hټ)+wuj>jնv]bƵQV C0 C0 C0ͻd!`$ȴE:uN_BVֿ;Oą<Y:*I3Å$8ӒV/: 0YC0۵F-89wru1!`!`!`Ah%j"C8>CvvzВ`% JݒPYy (-3q>8^WQ :VTGAdArĖ,6 C0 C0 C0l)euAt C@P r LȭYƍcڵ'fa"lغmcۣ0]k7>3S^@ GX0 C0 C0 C0,8t[Fqq>y4ICm[5齲0굏ѭS;4JIT[+>Dd&%DL~; {/T~^% C0 C0 C0 C"p4FNzi̇"C1qDG1&#eZ1Z7a ~{y8G"6f.=} RSAf`R4;yS Xlc,ѹx 6uMl_!`!`!`@8wI#mhܸACSu|_N=1o~;GX4 Z7 `z{N?9 $љ;~Xv+f-Z."O!uU߼ C0 C0 C0 Pͨ>WHox![~L5'ܪ<:6 C@&Iɂa!<:>)ȴ4qpW:̫=_66 ֥֯W!)s|(!C~8j8_~@Y!`!`!pL!ԵF)3 * x:25|NTBK{wGihոVy*X ,humO*bڇHs>jbC0 C0 C0u2/C8 !@Š V^5ǪE}-2?VciUG3mGE]߷M[T8b#>6t+SϝV>eg^cQTu46kHp4EBߞ&U5i&V؎RPi߆ C0 C0 C*#? ZkԂzyMu!~ə%t)=~-׺l~8 Bp #{moMp9ҮG8P%/7mÿ}.=)Ig#gN;m&<}.ޞ2H*!۷Hz!}i&ͲGnX1V@Z7UQ}-Ӽ3VĆXm3,tJYa.ڧXFDemy+똼;&m~}烦~1s:`~8t]BLjܑuQ4CDE _T]8 ZDh}0G -a_tzqI6+IHN-O@ ҧ O:?I|cذy} ᜁB㜑AѮU04rk,\35JAz$4¿ޟ砱k$bċ?>e2-; ~vvYCόC^F );]:2 C0 C0 Ckg]j f5!`_h:yʔxҸ6UzW_p/zw퀡>.߂ƍRRR]ard4n$Is~nin9rk}1;wYDڣ1k o%_,+>u7MG&w@5{b͈í7E}LLLp^zBF&7ZW^ݥHMj3>$~ÔHWYf_㴆hݢvQXۋP?qvBzZ ۴aP0jp pWJ1 w-\0 C0 C0 c#d]4 cc::(E0Oݲ7NH=%#:{k7nxt鐍B,cx?oՏGxqЫ#6Ǽ53%aBAxwldv9٩'hl5=mۊqӐaʥ&$zM\0 C0 C0 c#g]7 /J)G2ISNE~~>ׯ2tz"hcYkۍdسώ@2`5g5~%{j(ڵ79o .SZR[p]_ 7u%~=gXE\1nh O<&>3l^k|rv0Gйm+!Y##Xv8{Ix9ئ9.<F_C]Hg-a!`!`|&,h!P J"C͍CGy$Bjaͺ.Fۼ?{x R߷y[vi6 jNu FLW/5 ^{t9JފT8va9okk>;r_1i T0@!~p5{=4r`<ד;2e{x4>L筮=/;Tzl,[ e2/DCOoi)h0ٙMf$yGA!wL$G:I5Иr !`!`!`|8{G;2ujևMK1!>'yZZ<LNN.]j=(>w~ll/u鲷 _95OȺ_1V7Qp}"īI dIpTJ[ }n/YHmesg1z7ǰUse)p,?fSr@JJӰBʹw R߷&oOvCn]_DF7pe6`x0+`Ubv17UFE#ӐAq8MPδYXKvo_>8oM_3}>eFhX8 o,?մ_M c⧏e|ʻvr!e?. YC?x"x;z\L)ݳO^%\#8eY,opd_ˌF__UsSSSSvN+ 9oX EX&d```a}%, 5_ {#@YO,9dp/GN.D8tyJۄ cOǸ?|q`KxwX'1oj|SNA~\oJ}uG0?m?m>D~v?m{>3OXN6Pgņ!`|It ~;4i۷#;;-'KfgI5Kr#HM\Nngq ޜg_$[f^* }d?$هSƎPk$Km$%:GOh۪9|Ò<FxƭNƯWE{܉MH0n(AäDZ O!~|y`|,ﺶx'URۊK#]!@lbY =tן ~,JC1yNvչȒf.xJ x~rQL38Wםmz+M O_Nc ^ m'rˠ݋?== di{}+OtG6emIX#^Fᴒm{d;pQx/CRɿH];yYutLqn\lϡm01E<%#eR^:v\2 C0 C0 C+DW2^"dIӴAU xt#PU?o(\Ba^&7|dv~& K{uT\M0/B|g0tIU_? `3#䙳/v#r!4Mr#DdbB|ίꘝꁱ?K8>{*H/zbHR>nG;rs/E5az~}3y5O0_l~T߿v 6?й`i>OmK;MKeC/2j$NЗ7 X^ K~ >c?tmi*xvaT"?kH2r5 ڕِ'yGÅ hU;cs܋o54hpvU~uXk֯Kc!`!`;^RR DޟX@Yiiid ޚY0N`Es:IApO;}Ѹ{Ww+I=\HUyEYc "G-GyU~yu}-UgkjӍ>.Ͼj~y&]Rm嵕Qrίw.c ,> uk:!`!`!!-7|5wZ.!`|Fx7) ć#נ8>v=̢/r2?}}n5yߦVZ?bGb5.%F ֯- Z~U;OI_?"p V@Ѽ_ϕIk3]=/2 ]9Tϼe:GjH6XG\p lkki6| Ni6?l~?=Fk ד:1sG֦le! C"E/*؍.Y-"ԅ( #ar89el';"/ r!uke::z]WRrWymT갮Ӵ>uYFŻ]blYp#^=mqX m˜8UΘe׵>Jbg.9>1116fF{QC}%v/ί NG|T<> 9%r=9U]hZV[wFl]a١\Zv.u'+16vv4v(IՎS/C0 C0 C\rg3!!x(pXl Ѥ@˿ƨㇱM=beoyqxUTP>T0͘5OGןRT /Ƕu)gP[}aXh.%+g>ז2f F?34}*y $_9ӝ+Y&B`t-_+׬w:a502ť\,^k6lvXmUJ}lKuغc-\_<" w~;boaa^+hѴ n94HLtXGK!m-3s|{ž|Թ`G{>~> Gc`rC8<rZ~Or>tWbcg1eh(IHn,Mp96mہV͛wHMjؼm[f"Y%{v4mH>i/mrdRvV˳Zk+עiM:ًLOCиapRm)e̳,%E^];c{oZ#i}VbذeEB?:EMV^KWa@. %=DhzuinڢAD;xUT qf.^B7 ^ٵL@ e ,¶V ڮUsGV x]ڷF-5$ $^,{$Cֺ>/-33_.^k Vgx,;/A{njTwmW(׼]:A維G >ǕѸ!wnF{@IDAT)ɮ?]'.7o,W@Z'^hۺ9zw(˃˩ea\΂Ewo#׍_ 5tZ-DIJYFci]1G<<ܵLOk..mqH[ZCvKG(]/׬aJ̑]Xz=6n9$יarZ6Y[O\*ީmKt{$ٟ83/#(B.-\ZƢ\[w"=-q~7otht"_:gjG˨i c ÇsOa`{>|z%=낒n@NhlO?[r%&)))BW}?[ p' Yęh('*W3梡xOl%vqdIןuo㈧EB&>toPHn?$ғ`vKSIg~cx iɸ1 O8 g/Bَq"ERhB})p..3/bIh$DS+ GbeXv38oLr;c,t/ \ثxx{vP"`a{!n{eoقAQ9B^1ys!۟-+d7aY&g#IHk\_^ޚ;#+A/5gyKǤ+;;3 }?$x6`ѺԹbLL KdjhhBr_z>2Uǿ:͚]Tnsm͆-OI P}'OQ ~ѣs;۴?i|4o#~Gؿmz =Iǧ1w qwo#73s>3KWoɹ]y=noZ4N- >{]e7u<)hdž xuLL^_7b@N]&dmҗ.ҷ׏~ٱG7y/7&b^,kQu}9xn2۴=3IH1o}zX"DߵOHw&a̢5ز۵@2|%>+LİC8.\?zk[ga`/b=nzyw.ޜô?@V8g,y0Bfa÷TGۆo_xRlkŻ13Z7|s /η?sNO/??Yh!}ŧCxZBT2bq:/kf-)>~=W<ӸTwF9 B~3bqஸ9ܷ'G_Cxu2Hƫ9+6``>g1KxlKXxϭH=凞7_z]W\)xWm?k.#0''sqޘ:kn~C_#wm| e/Cܿdry[v{MǟQsXG?;VGK߭W68k@ُ IOw\(?.בޛ8&z)dމۿ-^+▫G 1w`̖4K*:h_rx4&2 ظC/wx{qغdrRo1z!.>kk^7&ɜZ D県azbڜEXSP"qXv#.s/÷7qcNnN|h~~^.˜_Ͽ? #Gx V C0 C0 C G o0  ˖-Ô)Spwn-K(--u[ذ,̑e݄X*i:eRϖh${H<ޙ] GFg!R|^t좓{`-rܵ;c[q)ExwDvTg$&!$|\'g8y.ɥ#0~aJ>̟!|]1‘,"9rLdy,[;[rz/qt$y9SMC:M,c+DMg奩L6ɲDXci~|!nY0=Nd)w_ڤ% iX{_ll=oRi,SK6ax_Ŷo#߶R,[7HfM-L3w\ -EX/KHGXId բ@ƛ}sP"$g`\߿7KwP=0|pHU:mT#=-_3uusd̜w?߷{g!B"sߊ/>-e?}pLuH eKxr;!n$7aY~K/ Ǒn*!)1_7!=٭dB(g'=' I{ǷNsxy'lx&'912%~1P#URޢ2$kY$g7Nvyr H-p3_x)f;dJڥ O[|I=ݾ$=-!`!`Wy~5[qI%nn݊\dffq| vi$zf5U$'j-wriTٲp4zKm%tbnOs,ɽmVvH@?~c2zF+dT~>|696G>ir6mR,MBg )BHjT_:íB<؍!^h#& $bs!6vywݨ${d\z =a੼ 7'\Ky#!#dQ،ʅ|d_8Js'ؽms.| ,!{I(V`0,c`_{d4thK/rpޠ+7bx% S{8K0^r]23! [ebbȓE\hdkCtY~~{1Kp7LMrrGlCX ;1̯6d&i,LlR3p:]8 5c>qL$ґ<4$I}@\8)ozFNծ:N~rBH :4MÂ5ѿ}sG&zs^>q/yy,>5 kHd5r}NSz_mse.2WOpE!`!`!E `4N@HÐ_|={DNN|M'kҤBT !k:H$9@2 Q# E%H/A)4潩HK/fȾ~xiE2ɓx~.z a#eNE)gMܞh蝜'& J7_#:-I li;;1㈟ph,cSQbeb9q$;*ۤ4!>TXKWp2OIิ\/;SZ1X!$~9pc ڴHUg}zL/v$X7uLZI-^V3iR1 )>S}yI :ا؟ʊrl(txwJ#?zbw^u#(=/y^=xN杷*Eekyw*3.]V !HBuxd`'g]9\J:af'%~s%NMdOw?]q7Ib,7&a#A;wc!ȁ#5q~xue!`!`_a/lV_9V?EqhӦ w,_W_}; D=DRB#:&Ҩa2zi-r`qVn'GZqIlNLT -e&xAv |_;SdIꃞBҥ[ʱ&[!{ɑTdp3v4K)'zYB|;q3';B!,ǰ=Ъ|rqxCcI0G\?]gyio;Wg)+.=ޘ0d鮌_$O;VDL5ڋDUx\[ċy`ҳ?SD2dywc< / 9\>/[/ݻY#'Wǯ@77K6w'v$+펑O3n̍Ct5i<!Xy$v 鋸!FUdmE-H] qnCD5O@!N9Lgś)D 9GH֎ EhւN!Lɦn~㑤rd>{.H"j,׏3e4iWs?<`9m~pd|~V Gz/)6#!drC(1j~Or>t̃ BΝݲ_.N}(u)>=aW@(1$!{^WC*nLQI /M\x`Vs^a$Ģ,JB̦5d)*c?}Ń lݓ/8 uxeYR{Gr bLo; )ST/FAuw?KN bxwחbٯpxi_X=~6Wpvdys[(T h}48y^}Z?|瞗ܒ`kKcwˬ`vtthl˾9 5w-[<~5z" tCX\izvo7eעQ٫qmBL5C Fx_3_,| y0ve;vpԅ8a•xa =Iʅr{spO߿^<-ɗIr^ [W|F;pҿ#@޹8C<(f_\ף#~??L qIe,V %rx |k8 bl!bI5~ Xf Z7^_ ]:d}X_\=*˼ eh\];f{7`ek8i+q'dsr=O~ˉo? CF?.?Ց#_?-.{'N|@k19cte~>&~1|?'6? ~ڞ|i]P?x]j!p #^^~FmQ#q򀾑d c´Qri\\٭s;w()7[|[˓SVۄI3C >}r] t$YXldHMΆӕLEJ\ѳK{Yf)wc,mլ1NCx*1齟Y]BtmB%"3c,lٴ1pIe'0!/\YHO5.,{'.]`h&'q,^[2q8XwX~;Ur\Ix Z<5.2g/scx-Y2dܵc[`i'ONq^j-ɲw͆c^ve;)-;L u- u"'q|KwdW*^[7{ݜ'e8f.Z;wnl[$ˁdsȃKZ4iLaK.[M[`TVet,yQf&n1Y[׋&C[եܞ('B($נip7aޒNp$?q@NN_2^G+=yM2.rXgl0 C0 C07[R>KIIq"e<nb!p0FI]J&/$OýxQ:5dAm~;~%UWHO]K˗;I^UGcF}V[u)e:Z?Z˙>^0h5WWV_iE*_F26]_6ymmzyij˩s8{Ѳأͣ ve닎Qu|;6 C0 C0 #w!` aE_Z1T2X5O]HBP[ыSvnTePoGX1 A@DFbEZ4")-h2 ~{n@)ӺԕLtyW_a3ϒ`<XQ}K}cqK]wžڢ.ڏؓ˗ꋌ:lh)ʹ|E}~T&"='ŷVu0q֦uC}+ul߂!`!`!`|9l' Jh=CSP|-r2̼ObAmeZl;yWT#Īh-h۬uxfj`dr_/-֬O= ڷ9 \peRCWyZ8 fd5k):i=M0`D mWk-c!`!`!p\"p4Ggؠ C@ĔON9"KT1ôqᴿ+3=/+du))ATWLĸi ph2'^8lPk־,?7 C0 C0 C8~2˜ι# hokj&RL `~Đ vW]pjp5?a焖 3-AG)"Vy*ċoxwՓw/&b:fDzO{VIYh-D`ZzI7nZ_j]hպ(*.IPǾ7 CbYQլEyؾ8VߞXi˶PF_Ͻqe 1.]y3*qT΢]2{QqI?t޽XcޝR~VK)I \E$c'̪*۳ 6nTef40$>҇ %&If g#2>6?[CL3avQMk{i~?=xVdt^̧{»5Ά e6{&2>?yf.|`߾}ɓ'cرXdΗ\ D-'pD{A>n!Z*++tɯOd!Vـ/\B\:#ozqOЫ燮Qm-t& ٣X(Лg\zc-|⷏JCc,]s(Wn_m1:^PB~ ]^h ]؛?>2*W4tὣdҷR|~{hcEx%.othg$ߘzCp+ LΫ\4K ǟ~|L|=?==5GeL`ޖ jX9|pJiO`׮]Ń>+zH|}XT\ BaOmP?}H=һ蒞{HǍ{ߘ?HO&񓫾~=r yrÃo ƙV{vw9M.s^_W| CĒk'[M#nr8zz$ތsۮr}d7!>>i s;a~v\upw0-nL"0cF^~=ȠkDon/1 aG5v?P=;0<`Clk>R:H&7 C wq:,?G}Ave;T'~d y7}F\sGL}19o=@|ox!S&i%d`'/db`.W+ / [;vܾޡY>HX%JY@ A0H^9g6PxBh'3Θ:w˯ZK!{GA"Gw0 C0 C0 CC  0c+++C-7k ܋@5%wfF mtɏUVk%xd8lپ-% u+^#!GYn .{pߛJ9\.ۮؿe=MDy ee@<d`>WջR1TH>2c!NFY̽omM,KCt C0 C0 C0?o؈ hJ`ܹ?~<6oތ'|M6EFۨ|U;uy;g`6Orm,[^ƼI 0$+D\\In"c#X(& qp,m{y=y7a# 9P镸dY/y=EPSgURbL|v{ӍDk6㖶J|X#~KWu}7x~ /?9n [ϼ.%6w 义8wpˈς@(1Iv?[$z ,W6Cˑ=fw3~8tC8mn߅X|-- {[ poÙ]ysSK64~f8GiYRBbc!^>|̳MǻyWA#w_MDӔh!KG-Yn鯎#KZ qW6CN{#A} EdoѼYӫa/j߆!`!`!`'5M8P~ֱ'9g׌mQ#q.1Gso8hZ>z1nm1 K<=vйm+91Eb[k7Z\N֑eŻP.^xin>XhtumN$>}i S]:F79CqnAF4>Y\))I4^_a 6^0=vaj2-w 59 {]Ho-.m7LMA,+ފk6lvddV-$鿾zuqģO*ne!`!`!pB 2]RRƝyfe}o 17lGG>HüO\Ϊ֕*j_kT9mi~%4nmqm|辑h.Dӯu /o  K!`!`!`x.->憍P‹-b%WU'ʔc'SPj2iCʣٖo {֔w\Vu%S o? C0 C0 C0 !``p2-C8 R)5 $cY@`-3ɇ +GU2ϕW$/ʣUWۢNgjb^ tYN|.ѪES\4Cږtrױ~,m!`!`ꕳ~9JD˴t QΫ-"eQ }T?Vy@a 'aN6Nկϴ?Vmyu}2}oo U6 C0 C0 Cx@*RQBk4y5x|q*LDg|Rqu%r` Ti씽/E??.W-!p~jZ_U3I@瑀ˢ -۫TWKn;VtM^6|'_6?l~\?8tN:`G`F0]``]P2C0YU6y:^LwXŒ1,Ѧʵ>i]է6=-׺:\V_M9`>x|}M65 0IU1:]N͜A Z (Ae~MmCSv3ΈX>6?l~v/VC9m~aL|8>zXL8 J kM^H!_&>ї?*+ۻ^ҲAjB {c[A8ѫOzBmypgT=iƭXbM 0&#]+7n,9&+Y"]z( >]}`X> ڣ}g<.~l. " آbKFF5%M4%~Ec,bD:K]ci 7w9s7N }kѲ6{AP1Oک-6׵8pљ)sﷱ?۸ s EZ P1/ٱ ]/h|hLt}}AׇHKVR4}L_%#ZoYkKuxnGxek0ҪZ\,^ 'pB[2};YNXk .q=TԛЈf/ ^݊\䨉\ċR;u,*í6UGx v"<\qDZz0'(Vϖ 'Ԕ :8IԈp9 2\[1ϛo\ƣ7}_x_G>WPP4>h|v'O^[JlD@vj~ # 0 d9Y㜥_ RO&ny]mQWW /ydviXmY/h:Dd|-*w| 1w∉&2fMY-:xl)V㦦8kEXW_Ꟗ ud܊jҷ/*6TTUY]nNw̃u=7JǽtBm]pmcYREP|(Y.BWW߀JPHqӿ/KYo:iV g'Lt<䓑n֠9;З| sD(K@X~o|OGA)'+{#ANoL%&&`M~wϱ '4G >l.?Wo]1t1)ȩ;#5ى,ǕeACeǼ+ / KA;p0u$$Wh2t-~6= &M3)(Y_vf71d6WOwu>h8QhWLG.^Z7)\{6ڏSVJ ژ>a{*Pn<]tjW'MC.p a܅_>71ڻNs~>>&攬Eߎwkb;r0)2Mݣ#N|{{+꭫D@D@D@D@D@D`"<1PUReD`"@a!,.›7τg]|W^^9s`޼y;w.ϟZWR@u?tfUkaLVmYTDe+VYVC~6Fn񞯇+VVeߧHȏl05۽Wg~qp׷[GcqKṿѿk{.j|1Ƈp,DH" ;-/Q{c۷/&NmƦx2ns7~ւFϮLت;13L[qx)أW7'˧+7{GvF kqӻ3q𨃆|cSfSpGY'9`{WϾ;0, 9e7Gzr"rf՘Fuywq =->!N;_Ա-T ѼL={`=ϚDʗޚl7l`cbmJC/Lpֈ x`gWGEa,7dE-݀Ι∡Nvb/n}l_aa&m9ػh6\Nx?`쏬Bǩ{uGQ. nfAW^UcRgᩗFeu{G< R⦗+/AC~J"zw=ZJL[M+i+w axt^ w݃&}yKJV#َ_vqkMK\􂕸iC9OـK p1pO`[1f{8NxS0 %q:l(limLwE{BԼ}((q05A e^g>܉:|P_LU+Va8n@'l;y]}&4F?[ Z[ /xg^s+w ˦$s={a'k돡vv|a]Y~xta~0L#>$}]1!AƇ|l%n %%P/֨؜ܼLhk*laf0k.54. cIPd+)Ƹ!;E8j 1٦w2le/(UG vnZq`%X-qM\+3qrqAW͢w(=l1pǼ썣{a蓑3ǎA1>E†F&|"8 6=-n$%t T \ z \g֔V:iE1m?c7~p:x\ :wC<9Q HQό%"Sb df6/ a"ùe4.6OK5~fgVy5&^ 1O}XLĤ>K1^ T:\3zz'\w# Owy3U@tsϼ2K9Gp~{jzL/][7VAa=}^bM=D4-'gp ~ޙ0Iѵ~.sw?p_;'eR{cl ޱ-!W[؞D@+ 2t={Dqq1>,Z?8ڴ VqFjהo$p 0W ۀ n[`S[psYw=`zteי]Y`bKUznju<]nq Z5unJ#,ǿ@IDAT%3AXx dcX|.\?&s6!eUxpcM+VE,tj_QCG'X~?-Cr|;qAZp>XXb <˸7ѣs{<|o}\[Ogqݍ9M/Z |jhv>g!6|6gdmfWW5uvD@D@D@D@D@D&c%ߍ̶%⊀HF]nTS8⑗Ka`+˶i9<&PnSc)ݝ|h[n=m& >q8hdf.N1Dr({ O²rQ8]ؿogۏbнgG_CKp˩p1;+qnj/~ 'NtX{>d`t O ͲӒM$=?8{__CW{F&G>|[slZEY֓M"'EOM6dzuo1ϟŒuecpYҍM6ݯV7~yxt4)YOfuEmӃiߋ6X :HHsߏs8 eyΛ4L/?cmM9c lM݆/>J00rИUҶG a[Se\Zq:jYy{mt{<.>?imsZ>pam)˧m :RnKqm Zp·TO[؞5oϳvI^BB ,<_XNkZ|췭{?j6pϼ|xˣf>/>=-69yAt*A9mzKlAk- lΔAYu;kLsVCDpݲ a"2/)\x">>4>1AYk~ߝ7C>WPP4>h|}LJ"?ln+pst&"d`Yh-^k~>M)Y"~܆88>~8<6w 3]Â"}MX>oy> ()" Jٜ`?Em-cKiru"?<[* qiR;c_WWD@D@D@D@D@vwj@</9Է@lMC sԷ1cEΧ [F'(wZcևq]BSj<֔0V{.3) ȕ؆3s+'" " " " " ; >msL蟂>9(< fI q[c^pnpK|ch79 "oLf .̑{)ɑh><^<t5Z.!=7ōL5}6/z"Y8Hcs4/We/Un|,(\~BBB|a{̹x::bܐ<]zf3O1ޏO׃ǀׄ~?/?t}>A [3>_,^&^t,ؓⱛ 2F'/8~> phG':WSbe𣿾+OiW)^o}> ÅgOq y iY(.Lavʅ7>A%W'ߌ{pPdz6-2 m1By"|#&Rxt"|1ٸҳ") 3CDŽQt,4]?bc]/uɞ/z=}\mE@].fŠ0z(UTaͺLGa^󯭭Cu]2RhY[2+k`HsřV-Ek[39) Eb֗a0cB+BKVqضl]uM3EZ {zTԸz/ǚ (+D~lde 5+$ XIɉhVkےkeXk6#ξOzUxxYh|c?}B5>h|}B}}A×M[rDH"}LͭMū2̇Q wA?ǿCjyixo +I88caXiBo~9v4:Gҿe G^둝G l[{ȯ6[M)XWUF9gpda~6ϬS9<gx,|9xOѬ_9-ǵ'Bzj xy2&Y?8tj_ںz{2n-T7Rpqq:!YkO`eE5;w&<!-nD=c7l3 @O???t}DŽ4>q ~˱"p t,H 䊾a6mJJJpڵ+Hx!+& ;:{̢nz{^ĝfU|jp)p1gu݃&xecUiz} K;{\k,N}7/ #3sND 0k"xqEG G]C. u?\| HguV \y1ә0p!=Ƣ1u4Qp{ON>I_܏)ƾ@.= ԿCwd믿>}wfv9- Z_QYޞqӎEY w_w?72xI\in9]<}пO01'u ԡޟ11lbQ㜰gSo~#,[={xMF k+@_" " " " " "  D5AD`$)Q)77Uxb"Ofa-BBW >/M c }Ol.:e{)==#jL7鐕ʼhzު\3haܱ%87/934§ƿG}{Ix9sL%o/_zXs.ŏ<{Hz{ʿ9eZ7TȪu3ƱW & G/u|xND,Y[1-}+ [h7>)ñpu"?W~KD@D@D@D@D@v9\ CM?FetM9=`t-+Bl+d>KIIR P}&픁z|]~N&Q8pVxQ+1bdz¤(1cnjMeܢT07=`/Vnt{ 쁏g-3N+pbsI(w -t+vroMe9ӱxr 5/'so.:DjUU蚗ibdgȈvyNBNۣ- ng&|7m@vw7;Cw[PiF:5FQVVF/dggǞx2+**;[;c6?l>Q8@IxC%Tp@a~>/'~˸89}Uϋ}ϋZۦ tZ?#qYnnR0+ED8_76v9 ľޏqb%􋯇ˇt~@`~F$}]1!A0>~5[ [CIqD@D#:/'5 i\ec>oެ+M?1VěVmWeӄ˱Ԟ"VVe=2ZްVkP> ڸ- q"Ǝ[$gUmڮ] Ua'ٗȾZlù>  y>m8 nتTebbh-#g8hk&N8O틀D? X ;YT]wHYIU ~[>c i+>pUtVM Wm⊀H ~mz i+" q8pzAފXL `j+R |Zƴ|p|>*Ѭo%×y磹B-@D@D@D@D@D@DK (/'=Mj%q)bX3>9(|||}Ee+0R,_ڭBoޯVѵq_81YΧ6̋eUTVs_*Y8Ojfc~tpӧgaOZ}u}\/ֶ cpQ9g|Ο_O5k|!<&5>h|ؙ_>>,X /:ti&~T}|83?p,xa2 Ēҧ7`wPVr5RSRоm>-[>?\~V pEX e Za˺+^ʨr #X>>?yz0sA&im7Ip rBiSЎp5ìͥ-8t,t=zh /u=zL@׃ޠ߇z`]_͝/0LH" t0{L}ɟ`bBV#r{뒓]px#}% ',-k-ߺ}.B<p9j@(ZMG>ݪKO/;mr\V}w^z!{p{)֕aIjTTUSa.1KJܧ{f ؾd-<;+!3#͕3_x+s [jo>Ěy!#PZYק@FZNr/_69VV'Ҭ\,VԾ0VφF|>lsa^.dPeӣ;!DN[z'm~)Sl2A^n6vּENXm<;ʫì@];OKfKKI Rʊm؍H܍N*oQvǴ8ytv{2.9.j9ל H8ĸ%j7<> HGUUU׀D" ;mi(-DrRxM著1cـgE<}|\ӰYĈZVomǽ^#zwūpn'~3oO.?ٙ6w?M,YckQ^9_u& aMurM#/6gO^? 2;Ӓui;NyYXjVyfx%_ϮĿpOо"  /ykŋCHKKÉ''yM_ptd ȏY1ϤDgr5յƆzsp4أ+ƌkpI\_0}mwo̞WHgw-^čW|ωz~#;1K[|])chV5H0+O?g???Dpi/^ `,Z^;Xo!,o<׾$n{ <&},޺@̞m ~r5k9%kC,Xe B%~ndϜg!Dk ?x.x0xYG8^]ѣ[g\z3}3:f?x쥉EYĝN {" " " " " ;Y=@]׬1KZ裏 U]e@*a+RQdSp 3P6Yr+HIO>=tt3j;6}<G0bU8pO'[8?w ݥ8vM瑞FkD}^TC;c}\CᎻآ$>Ͽ?Ǐ$L[ s.A]vÐ1|ph=>L74mb"q1?lqvӇʓ[/sևsy'aNl(' ٫SAmouVc^̄ٶ,u)?GXND@D@D@D@D@D'&9 L`RGo++#>/& 4fѣݻxssk:-KM`o|L\s"\ZH!UH35ﯣc=r3t{_μʚ:,\[t k̚;Cz2޽N&veg<㰣'+7]|\IɁQ73}Hto[8l2ӃЭ}*|`1WA=pⵕ;+ά8]A.6c%!Epښ0ҭPE/^ޙOyPY;~{%3W9 -\UA znO[_/EYCt+UqRtm\.}k_\Ƭ laﺷUymO5+. 颕hot\eM)ȓBҬ_xtgwبa#ڢ5Nؽ#?,1{{[M8ۄh5JMi>i<-,ـ?g_õ{fIޙEB(bOu*kpnÊUkпww=|~vxgr{a˯ ,o툀N@{/ /u W]uF-|,{瞈bnïVm%&D܇YpqƒUkϻy5Z&^]|ZX,qȈ}WǷ+<`Y x/sV3+@PyxmHt FZ}O?>z4)8`<ɘx%Nܫg'}'ȳ{4 =zwp՟qfޏb/p&ŅpcXxo`Yyl*tUM:l`G??;̲Ҭ~xgb.:~}XkV\IoϼmmID/-.]3q>ʕ'GG ¢.S }^ݖvD:=oOے.HG `V &F3".ioRX W6,sږiV^lGߠ>wde>l7m{;ki3`f)㊞g"b;b^4kd{)| {w˓y-^3,xD(&%]X\b5f̚a8~+f1ʕ.) SVmo?tAd+޷}{v눣FC.|ExX ]۶mta|7ǟqԘ9jȞU"cm9+߈bֈt|O۶2is2 %bNB^y~]㰑Cc+1X^/9 -XG 'l/E ٱ̵.;;ų***Mv5! MoSbXp8<.%)965S~㸈q_8ǵfwػ>aܧb;<f? Q+ ք;pۦ\8=η+3!\{Gai)"1E.B%" " " " " >mPsD@vO^S߇Epp8)}w0'\h_1 ^SD K?zqIhV_8Nk $6QD5-x^\:|Mcc<y>}"kΕa[۷?H y~K?9| ™WD@b "6ć𖃫`)>yG`> YNxZq`%.B&_X;qjD6mͭW Y[ _k_>ˇcE%t " " " " " ;1/#p'>᪺!W/zKa}<㰟pۚ_Svn./-Vӻ^sZ-Ú=_f,ժ2 i}>LZZwJ" " " " " " $ P@D@@XT-i-5?)pq}5/ے뷾vsa+oKeh_D@D@D@D@D@v/L]ZvnD@VSi_O UD@D@D@D@D@D@D@Z ^$%;6)|I$T%o/'%Mx&GCׇ~L>A}~otbk]bN!mmdݑ@"WLkq kQ@4PֺRSS[Ȱ:466B@q |C$ ;TD@D@D@D@D@D@D@D@DK*q Hqύj&" " " " " " " " -"`37GA" " " " " " " " "#;wvU>a(\|}"CƇAƇAƇkڏ?L癐]>81AG>A} ? ? {hߚeF`ccRE@D@D@D@D@D@D@3 L)8)yVF" " " " " " " " "pVbRRP^^d' ##))))QI" " " " " " " " "DTUU9K@NqK_o 4%OOOwaf6x ]1!A1!A1!A~L-3򢹹QZ5[t{^L` 9f8Rx1J00rPyMSs"퉀7D`Vw~C'C:]AjNK_V!p=B ^UQzⵊwTjE p=j#oVJVI" " " " " " " "eH1D`j7Y" " " " " " " " h vD@D@D@D@D@D@D@D@D`{=i,$ng*ND@D@D@D@D@D@D@D@' ۓL@vD@D@D@D@D@D@D@D@D`{=i,sy*Nv9Hĵ)m3@~WA7A}}A?tU$r;@)58ѵS,"/FԎ@4x:|$~D@d*;'?'笽j-" " " " " " "ak'w~U KS݀>"T?5_nD $+RpjF+~[\eh3wpGsbS|n#LB_" " " " " " " ;Ȓ*-֦ ̗jmc2}Y]W~_%.}sz D%%6Z㺹lX+±b¹e+ HOJjWˎBJ?Ԯ%i Ӳ=V^z}˰ҬlL<|ܔD7xRY g|_ J`3Azf}#îuƮ{VLEsnmR1|vFD@D@D@D@"&~GlN2ղ[^dڳ{i,U3lnyaL0SVW737lý:f1_{T>Mn LC=O[gԛ?y 0x pX/Hv;˪uKKq5LLJM|~tuk퓗|P\h gt_g@HB-=}Jvl;+i]l0 [ "uMO"ay#.\iON@ w̰xsc#1G}xow8un5o8SSSt#>d/k<kɂi6ցKgpM^h% [ S 7~mx0mmk}bku+cR| ^|=frrcAH3؞ ~ OeiY| uϦϠ p~Z VbDvc.#͝_" " " " "& s?>,+-iHmƐ<⏙-ϕelX(D{eZj-~x{voLȗl\vWաM\W?>2B>kk1|.,Ugp>$Y9|V}Lj>>bS<ޅGࠓh[&e$V 2'(6zΎ .>CMi(mm цzp\h ćK>&J2Yay |PjP.R,򲹫ŕ@4Ątԗ阞G&-/ʅ֩eub*fjk 2%+a($섶fQeBRXavdZ=zh[SÓdCNiobcƸ${UwWϥ`̗ vg; -!-]g~E( r=Po|m*Ƈˀ~mPŏ ,)=wh|=))[]kςul. ?fx}姧!Ǚ+*k#2+l7jc\4cm؜o$X.pcz3g9jTQ{p9x^6x~e{bsy韱05yOjϊYvO]U]mv)4X,}2~yAtUX~=3:xL)YB{NZXηg'+ω=[M3ìn sˑq`rL`~ޞ xw"Jogz0>g0J"hc5/xny6Wu |^"31~"Wy]40'dL^T\[;~# @^\yDO:GA`6 oEkLGhe!PPUGuoґf•CK0sl~o{֓"e(ШYEh))Ita2&Zme*ˊ[(뺸xMY'ж b<+cF;u-@gU{Gr9_<Wl~”zw_]u)‡C{TVm^P3ld%h 5X?v0)ۄOVF9klyq\spw+Rf*/HM᳢.BQ¦E;?(1A211B

b s<&N}ib4#S+GXR["=55ru\=1[y)3O,۪#NQtUuk!ʺZ"=LG d+邊ZH,л&&-h^= >'[*+"W1D3R]e7hM׶#v8M6Ymufy9?Y/㗜DhtWnLSZS5+H QϕvYNauvLf}a1GD~ȟ,٧WD)J榥D_:t7@4R) EM]<}Yx=t}U_?C nbܢ%)^w=dMBnQw̋r?\/z:f s>li,^bbg~#Ep}xѷ"Æ*H/^WF9h4vI)/36Dy]sVۮ2r>?+++KA;hmm2Wr v(]_&x=؏ZԮ k{;f}hfǑ4ӪXc}/y]Ym-ɮD7[ۜek.jp}uh k9~4dz~/ɮwG(XWԍVKZ-۳(.AϮE`a1ًг0K&t1WKavN6Gc<4n7ZeToV/w}›"~ci<1ߊXo/ω\}8Iw\l#V\dκFsRm]kcun|xו{LGQ[+Bѓvjwxbcn4ϵ<;g׮M믏ڱ 6'8Yv}}z=:ɉ<۟~ע]|}~LY|aOќ:tpCs!>K c7h4Jƞ|O=D#dJ`֊h9쒕s =~/{Vٽ,vfvO@Q>ޕ-t~s'ADWc~qR䧗_{+:#cz;c(>4 {`ktχ|F|fߦPԣ>_LgG"?m(aŧvyg'LU#=ɞWF~|գ;G'|8=5M6TRth\֣9voӏ߯[7jEHɂ5}zveԹֳmNϗ;']uG,_ѽ{a`~ߑ?uJꬣw3o W|{ġʗ Ӎ楑>'>wޘ^kكqg'h` }?p59 /bOCu7E~*>e)19t}62Knr)++Gn`3?NЯGoi: <'F9! k|U&ZPm_k#@@5>}wtDH>e?Ge+C#my :אΘgeM5+ǩ_$tW7ev340EY1X9wAm9-Vε0 t(G]"ݻץKQaN[FvGaJrӘ)bb&v6 8t6en]5zu c|<5f͉wb¬bYhk 0K/اm$gT6L ͣD.A7w or~Sؿ4+m۷E^="Ev>|,0ix=ڷqYv.2̿] j"xi!eѽsH1PmV)))=Ann{ٟ":bt;_KٯR-e zѬcAY|s6л0ҥ[ ֍vY'E Âw,/[ >*NBBI! wRTłذDEJGQ{%^B ιo# $y);yJ&ӸŊ:$ ܎dR7IT?׳8`/^ũm” \7@1uga5[L:9s/Pr--j<8Gr<A e]qy !A ,SCq( .g7?qr;|'P:!A<pR[dee}E%ϳzz(&]_1ERÜ\N/t1=?E!¿(Nſ 'XڮNj# 7rm!K|/UBjN:6WJ#t: r¾߶yIh(W:έL_ F|6QG<hţvJUq7RRa-: N(hzIp KXiiTݢ"A2*۱SJ"O .i άJU:5i w{K7f ?{ۻܤqQf?s/mH#(eb5m>E7?|}<O7u+1i%5cDNEk׎I}A' kl8%K㝉}Q*& Y_惻'>jÁ$gPϏ"n!Aj mZ_|t_=yZ6bF3N2"^1e_1'ܹtħz\86;wj|w ~!վ<6'Ǜ7s!J2%EZ8u,G eP?SaN K/BG1SI2#L cIGҍި[] } 94d`~`ؼs/^!Iv\vw?bÎ}X~32Έ8G^h*iGc٘ t} RgiZ Z-ߐ>«HAc* SY$C>6&I˥;Npağӎ䇱:uv|6<φ+O?*Ѯ[;ԫVXT &ǙV؞i c?gEn\s.,[}; gEh;P5,h13ڣYx<ٯI}6m$Nsy=WemԨTwXB# k"oj2\Al|RQ8?} Y@e q=?I#YGa*aHw_>Y+ס:EӾ^f̉hZ1$D&Y)/Џ5_a_؁ZG!I⇙ش/ Mt:|׬#B~T`EF}?LrXM;jT.o0[)Tޟʘ{ %piFDN/EŲSq7m? GYx#_[G}1xH(IF|;a$Ρ8~ڵ>{7FoNMۣ'!OM;ħ=XA<()a*sܝiCW/*#}HFVP#>֌iBl$@O9`+׵'"$G?a枏gW !?ڽ)\WoMƌqC!?-\s n\C+ GW$&:ȆYGwqzh!j7zeiQ3INeBp a0 C_7_3IZAAAAAAAAwzɤBZ Ⱥp JP7-B{ z}=j6C1m{\@)r<:u'z4-\w9DNaxFZ Vn܊aCo o>}ԿZ >skղ*:Ѓ8AY 1a t~A}i,^OZz JwDwQoM=3m؟mO*ÊɣsH%_rF, SiLөE x%N*ժM[8gubeb" 1yR|3h1>a4\O=7KhܳCHݠAL'Qw"vR' rߵFbDR3[/ Izv9뼌 ad 4;h_@ePJ: RMR}wW4>]Ѧ^Ytx\IQ~ olP8;XJP냊N"2{NՊ ]|*cv?DwwLz*Qx3RfW@CP ? hP:"&1ǏbT֯SzàT!Ńۣ5R,1strUHBQ*hNpYn!ԬnF{c9dRY4zËKu(^_{b ԫPwD"I!^1ժ0IT/;6uEH025m~W]DGGa4,*m{QB<owރ4[z\MP;HR,>6uP/=Tt$Z< MF ë́Xo&4뚒QLeg'PF6$Mmb(eK4=$NH{MVf8Eˢ2kwI?M%*'KCƽjJF b fO1ցx|}np)zݞhڦ~M]" 5Bє!jV`)ۡ^} y% M ~%qio.-܍a?ndN^tզK` odyӭL.NfM(7?~]^k+܈ІFl]O*tn{4 gx>xk- |^O]i {?^/>< q1|_fl}7J6hIxb}(WC3i4i9 Sɠ\4Hr#+}?SĆޅokףCЛ҈<=UkcA+.ElP؛jovEWʫFu>h fy{v*k?__h F-K@'Oʌs4p 2G] !iҸ~۴V܇&U;vhP.\ Yۭ< )HʢSA ePDǾ#) hSXklܺXn48[Z+?; l}QnvcjرgLS.&m4V)l׬Ex׉3KHf&- i !5Q< C%Yv/- Wh !D0v?l~e6pхS0nu#`xZy$!(x` IQ+ =ߐ󖬀_G064MկC7h!ZaF ]w)Ef7s 6za(ڦ+Ҏ vtj4y}jD2.jZV}4 o95rqFD-_q *}]UIÁ#I̻Ȗ[&v`qlH!tGz]ߪ FѐIf"s L6q/Zԯz⽷ƣϔѼ]2kINFe[ 7-v|2f~|KM"!$vZO QԻ]3%Q 04?$@BA֡|cXy&֮lE`՝쳔 5ہ=SҕWl=Uco/ƃ4Oc/6eϛD6 w$INjoBqvkcMXb/իid Ug8̹D.>2n\Y>pu#3=BZeCWY9՛${!C=\)/zmedmc4 J$.jẄfЏxSR}X{ihۜ]u ڵ6_.ПmnHei *qNLyz #㚛_ꉁ0՚P$yܐy2\^sCuy>3'I_퍗g6_g(V3hx ڼⲴ%vO2$"iʘzC/t4"q7Zfzj>tqã9zЧ§e'JN|Ehϟ;e]VrYo~k? ?~.B并"} B$vJyU+0Vl3s!7w=N2ݗ}3/6s\\ (7Ze: w1"gLڀ~4ꔅi!3Ezؼm'S!2mbH2,>H~"oymp.\`ԙ(x%GI~4jd,bPsSÇH @H+Ծ?ޘH9')> C2vwM,+vj xH߷ၻc\wf89.<1Mu~98888888W"(1 LGCkM>Ktv$}s ]s?d }CSűϲ h CPd 7+Z*POāCG9be2NhI4 ]M|VuIƛ} m2P^=: $L:̤.n,lB̪] F/3}!olNßSM3yU$.@QXf=ΑdHL] 9t^g CE K4^yyIOZg4mPcxzBӨM7Aмa}x3<ۨJ/m>1tcrкMȅT'\ eej|N0ap?cA*94/& Y7Xxpи,ф]It7p׃oYj"O4kqfL`!c Ҋ+h:Ǘ2xY_1ar:]5`Cv3M!v)`1-Z0Cua~yF U8|;o|{3]KC.ݽzfqk~ahLܼms=LS7Brh*k~ݩ$^ÃN.p3m|cG|teX\]2 SfGu"o߄ c(a}3 yIj1ͱ<I(%|ij*R œbNdiYa$ @a*1/tseOc7\nIhETX֬X` ZO,UHHiw=vD{e)KbeR 3!" .I7D/f bb 2q 4<Ł#/hit|5vaO3z|F|5LıY$棒fj3P1q(D-[d:(<}IoL1 2Ԫ͐lʤE0~v=sov#Ȧ]qm*k%K7$d+&@43 iR b"ͤl^ey[vi?Az-V$\aD*SuUm-CSI=T֍:\6WYUhZEC5Z$l+M\}ҕaq^Rh Jи7> T+t2ɀ0ܻ1J3JxzLѪ6Uȧ_a7k.D7`.F^:IW &1UCmqch =M͵REO`%z[b ,o/~'ϙX'ivj$yLe9:YEח?H %Z֊7\<%GCпc>s9&,MC/'K7\G2$֑5[8ݨ>qNjeaQڌ,q]Zt#J I?`@csXe ×3p1tMMD s3BCjފ98#>wU@)`\ wךq YWxC3rx4KL9AGnaO4"o dIɌjڠB@/ Hs| nAo¬C)'"}x>&&H][u]a:tc6=ZXM[$doC\;އ>=,6*(\ڼ}U\EWG$ҵX.^<T,Z1Q~+ ~PDdE ꤖL6rĶn,%L,C2;pA3Vb-^>|꯫Ϯ vge1r@_6u-ԪowȢEU!珇Leڲ-;m'"c+WɵV咑3X$@,Ʒ7cb+xuphk,^Xc]tlE%ۺ4TMANY6~g۸Oc~-cW6Ť/[, peڭTױCGOX6m1ч5e|aQϔaڹ{\גԵ[V|YJ}ӧX|+``dz´G>Zزz}cY_`)cч=pw0Wco,8b%&? +!&庫Ŧ|*{b@N Je9Xʄ[Q#-Z>\ʼ{~+6:"qeb$p/y͢şŅb덧Lmac/XֵSmg^*-cwPi-6$-Z\YsGPsYko1UJEN( ;XE>Z( [سĪVSJ !fBC]#-ל?'qpg%k[IgJ:v5}Z7 ZX-jTpJe]YV⣃eS=NnfgWƙ3u=T t13ּÙ}$*E[3?lY5NMA=-%}87m#Ir2W͸h]ùk| ?7F]^hAjʺxŬs$X΁[m;uz w-&0mݟz55lmo{銂eZ hM_hjƗfINcֶx,|݂UVƉSVrZz4qy/ZrϾk1{5rtb}8wuD[Is\<}XW8>rwn1uy+&ςOsMu&*HZ-ZnU-W`r,Ì#]ʭ:qSJձ޴hl!(רyVê,&W4m? WϢuU|ݍ-f_6Y>B/ʱL}>\sGGFr72-f.^{^wi8? 82Ȁ# 82 Hq鯅W//|vFΜ`ie7:0uJVROg}^w֌,zY[`=ea :5kid-a!qաrixH8i5;W|'?23F$V3ΓfͷZx8hygVӈu\QƌN-,DE7mbN}:Ƨr7>kɠ.Wό = -^X6ﴞ{CuZ4^{ "2_>[$&&C"(Rɪ.Zvl7k6o3Kk-0.u$T+ ;Y5S+}]d$=*XtjѸ>=0}ȃl->&MqS+(F1'b\ KWzPKæm;űbڴ`&%I)T (a}13[<8ZUsK}U_/<Ƃu 2V$AOU^6c[Xݴ٘+nKنrA9عae+]QA.k0Ѣѝw$4[_^ $!~J$s/taN:Gf.GYÉm.pGF\m3C;v1)CeN6w[2QhkraedoHU|fAFtd2Wb)s^`Z}> o?R@xJjJs]gъ31f\kz>->3Y]V14a08b2`ea?ҁF=FFW r7DWWr!U2dG2!7Y)0W&`!Wy-6!Ni)P8@IDAT,%HVt|6 2 O3v3K ̴.ȱQ(E~~,@/-}+OoƖT5Fr)lܛߠ=A"D(2y pUKziһuKID LMKvX5S& zև&A㦹9*sDWqLCC)0w(l~:qiǽtպ5UjZ]Yԁ}p.&^\ ݵgX6tc"N2%y=C؟p3>s*e/K>tm;Q1>I7VΡܽibJ[E"gET8\bVdr9el;P qrd<׸iͱ~zthsq_̶(Ez o+pc'~4qL0 ~OxMp߭?|A{wt~hޠ}%&YdN=RQ^|F` o\*m~_d'3э~}?G4~.qkm1c%AAAAAAAA cgCo=zwk'zߟn,0ovg%شUy՝c7>i Ym!ubm#{ [U񀞯R_pCSCN=Y<6VuFd~XQ2]:I{Rd{H{Dŝ!NFݣ^`Phc9K>|Qݍg0Υ6~K׽DS_tbI|L [֞þ DTTn|mRgAωh,A1XGK-TrCQte^9ɘ,4U%Bk_+ȋGĕ4Jo{a/tÐ N8fĔ*cc]LXu7y2;Mɮ*iU@ C8#A2Ys ʇ,Lt TW$+ܟI70?&_0I1+g~ e*`$y1sjy hqFGѷL<$hخ t*Em)Z&$N8'!=}Kb,y^g(E1d݆J&A+AG(VlH;cv\\f#n9 \E7b_kXθ}1{)v2~X0ēXPL>#hܼ񍟵jNJՕQ 03N*ћDԂkɄ+e9-"|g1ERf(\֒D4T*j0#6I(~w>G:Q[yMBKG ioڽ/lt^~7Dd?74)$>бDj h\&?,\3"Z6gE1fa[Ƹ)?cɡd쨒2y}^}m\|i?&Qo fX u&>&b=1kʠO]fYfa.2 *t 15Zed0b,g/F1~K YfGX/~~zg6.܉5ðOELDYR"j—+e58Lׂ%X 9J0kr&C2CŐ1i6$mڷ77ctl˾/!?@)2a݌V9d]fz}3u#)'1&30i8r->LrOJM7<$Tc\_^bf2|:_>#"E"x lcYɇ@b$U#/'"4&$Z GZqnځq%(&O܃(nW#t$S0;g zQK0Cq)3ƋWŃ/2;Vx^","~Vk:qRĕ"bտch=Z5V+e:%)VKa]VEF ys,Qk? LgHܔM+q5"^7z1N=٣P~T0xĮR,%#_Y X-XsD㮹k0ޓlbPCB8ȜO n"͋񾃧BP5qL#O9!Oe,cEs'lʆܛŗ%k$h'F7dT_ajB60L29OtcQGp 0-mU֯Wj0 ŤJ@ĊӪ{54Q<9>tYwq/ډZ\waѓ9#痃+zVW3V\қd :w׏;r|~Wv06)xAr+7hB*pbJˡPXMP *1?Z^sF` ?Jלz He= ".JN(W*@Zr_:N0bB|p( ʃ5J%KvW&|䓬*) YT2/NG!*l-1 cS7Tĭ {hϋGrؐ"z%pV=q8yG`[tdܓ$SYd5`/Ke}fh ßqBF9-WQ">',,Y(iׄYTqL11oVϞG&C|n8maۼHndegP oLyXB˕p#9l[9Nc !ȷ,vKÓO-3 e 79 sɽs9vGw/[D'}a mΏN\(ZZ T Cp,q-XmI@0 F[f^x$ *x|QpqvhXc7a"ʎ'~,̟tAHodvRq,b F^! 18yDc'j5ouƯ#IE,!~$>c)U}wemh1KҋoD8H>bqFvZAK;F~;|_bLސٙ Ee؝o[23EAywEkQB9y\8<(f-;vH~ڲ'I4Is|}=XŸf[$e <-wG\ H8cqG /׎Ādḟ!)Uw"Ms%߹΄qN-Mᘖ@1؛~S8Çy0 D;={2@;~D^̓ LAr25Dw.8-8$:TX7U-L`3|!ú>3Scy-j>#~M~e<ʵǏ6u+3̟Q8”ʲ=k>EXlӝ3)%0k b۵o@*!1q:P7;ua@LS?Syϊ1]!1)[@nL}3^Ihx\ 0@v!g$`24CЪʷbFe1[z K@9Jyە"gޓ:UXeh_hQ^˙sǬ,xR|{=؄j47Q{gr{qPߜAAAAAAAAql_n]#;B[&Zzfȿ^rϫٶ2e3i=IAP4zq#E0>CQԹN>0IG+ :k!y^ՋE WB:Eޚ3_(XG|oں"yݶuZA>t I. ?o1yճq/F]F a|O[ hUq'NC ԫ+2pƶUT+7IIbkp ԥ S1xܪi) 9c0K.`C )n"<RJ㰅}?0}_1ݕŔi옍@mcg f~r%{p3L[2X2Q15%/}О:+RDc,5z1 "@EFnu1+t1P{OF? 3/ܫ"%`rrJMg:?&хǵ)IXgqLnϟd7C7ON8v:Vi5&lMRKY*tQ{%€0k~$E˜$a&M{S?oC)92p#lt2Et#(צq>vmqD7 MCPҢD)e*T\92qO6 SÿdLF)DZ#|=\c07MFf]s/nw̽LUWo,q!12/ #"%OGY"Zr<\BPٞ5Rk6A] M?=ݵEcCc9E}CO )Mȶ2[3yB ,-#g]{8ܽsrjAfl$G86׸H_wPo8>z?þ;?BCf3уH^z׳%Hu\M?JҘ3N.q39AzҘ#`,+)ɼe"!&+ Y)pey>[¿"KUuU&5N.~CN6A%Dcs5RvS4^t7eXĞSc졺ЀVoفNm5S ɇs ~+ʔQ 5(۪Bg0>_c'bҋFDŽ 6SrlL4+KFdB& cJ'R3mpR.zc%yB>DL`X7Hrn|ΑI浖u.SEdOm1ɤpLruAk䗧Ԝ0%'w#Fm3*Y0.̲j-:v2^@D0EN Qy¶ _ Fᠶ ?YB֮KXj8o*_sso*Cd猩HS/b$^Unzr6^h}6s^59FNMftɱ~Q4ۣ /w#|y۷]sw,B) gHndLejxj^7^ڥuT}w1gspppppppE@Ϝ>iW+kU0a^u fIsY[\/ҙ-3K?G_rm* Ws [wmvtaN!c{XF^! u -L]m@Pگ<3#~LɽXvݩD "0 ,9\{곚.|WtfuӆU9j2]}ju:fi ?e_)N Qr"#sn=L,N`MN7{t}Lxe 3:-魇z3:~6/9I0G:MRʸ_:oSm~a]#"˾6rZ\k q6Kd5"%eL{X:1su.9j˟njjrrN}XmGӹjoɉP9:vuP9Yj~n_f%` UuTrOgSf,r=*#ZR~kx}PњV[<b\{g'< y{\eNT98888888!gEUY"y ad!0/.<4Bo3 f!.)68j }?y:%FYV'Z!|ekMZ)e/Rʸ]!Gv{_Nݯ7Zd}Vgv{u?Y%Wuր+9 `d%ېΉRs7uSy^HV7Fy눋N|MΜt4̕$a/2͔H;)CFL,D:E_mIƔ)Q$G"w!;ʸݮS5߅fLNӾ柕mZGP!"_-q oknRg_ùAAAAAAAAK7Fyw -`BO۝R˯϶9AF@Svٌ'{3 CJ?Ktvpppppppppt sԐ?db{U;n<(t ޙ_u&}=pJv8sc Gy>cC fmNIY gH-Age_N4{Oq_n\sܼEτ0bI^#:888888888888888888x?yWsndQ 1V \]c]\.&Q<}L:88888888888888888cH8uppppppppppppppppFr,Gi?"@_6fAAAAAA 1L9!ywS Y7{ w_?: LN'ɐK];,g8ءS68~avZ+p/$!"phr&/X#///< g"1 ՛7xO7~3 R0oC.]EHun(ru{>k"gQgcg|~K QǓg®K{sm7yPg >WOkd,'w=*SN^y&$/~_,/1kɥ=~I]2qS8p]{:$9AAAAA?4 Bs ]pUC$wqNp5ْʃВA,X/_rPLun'.[:iR1m'Reh/($\ɾpE g{ uϛ$/O]ΆO(BRgVM&;s 2Ĩn$b\Q$"?3IproMQ]oܼ,tfASW^|us-/CXp8?gS?Y)mj\u相fҸ]"vr ^?/ovk:m/pHڗΆCh$/Wucl׫c˿ʱ ze\{gjX&u˾>Gu5 hכ{ֹ볳988888o![AAAAK$8ƓɋC{(Ԍ2DY!סu6i+$-ZY,L"1?I-Y,eX(1"D'!2:I::e&ţ@>d^o \t6un D׌5ph-CQT2,I<$'ͯ"q)C)[ow+S$B69o:$ ܓdF$ |Eb/cˊ[^Q/zJ2$/޻ZeBMxLp_{^Um==!zU"TĂJ"HQPQ^PIB!{\'\_\ޓk2܇8cyy,нC?EL Ƣ,D'jĒ2zRɓnD ($J5 B \:t㘎$/BwC;KJA+rRLėv6'L>dˈύѤG+BO΅S8S]Tٱ@psY4sMI @LG,NeAW[. ?. f@lҶ &0"Z+uR2heԜ=*Z.hiž:keקѮ!v=HKkQJױaWN+KU ގK#G#h4: ?jb5F~$H@e-~X6mБHRB0H;xc<ظu쏎1ƞI*RBpn$3K+QIމ>BJH!rHȃHRwa8'FHB%E]YQM&jªӑzp"d$;q<˫шIFf"BO7*ZsжY0֬ۀ⍥$9rvq } ^9H>;~Ea񊕨/B6DLl** +m>lں㟞pZ4 rTۊO+PH,X&y|Ͽz{RPsz$$L]͗_/S"~2lA~"f.$.jcOgntjbR1(mjH򺓌}bߵT3fBXeT%*RC cIw<ϋ"j̲*xp!W؇Ǭ2Th;QE 'v$̌,/z!ڄ9|t z![ŪEӞSY,KY\;.0eJI B.=G2 vɪy;r^Y:wWBdQ:]~+SipCf&y]|~{F@!Y[؟`I{(,S'Ģh ʕs˜WF@#hCM @0F@#hE?}I$HM _TnɩiT]fxx#8k[΃ X?,?س}u@>X|Rն{+hNc/uBr7 mPRPTRʹ@#1 lSϗ'rn$bPDyDHỔҩ#Xk P~~?aq/'+E1}z@zyڴX 9y<CdDЯOOx{6`+s닒2 M~ pݑ+{P_Q#g<=ѳka1{={M{ch2L|K'3}D sssÙIXq NV[ _q_YuJC$x8sz$E&]й#AQQDvic]>Ū=c_xv CZ][0ԃKtF8{6Ϡ4?uI{x] 4}҆^Хg=gUv }'XIh+ KVj7 pˍCеSxyy"JɆ],u}[ڥ~ٶBҥǡԮM"׾hՓ$v)T6c ׹9EyEE(Hwh&qOm+HJ6PwTrEF@#h40|-ECk4FC@Z9I#q+zKlR:o:*ΟWG裈;rL{?|克p,]܅>];o/x!$2Hx#?_} w7W4o*,]];/'vbo72s~H$Fס#3@b+~vYӦ8x8c)Uu١edBCk$&cЋЛz*F9gOE6dN%E~}·ЪEs|gs8n7H4 ?Ŕ(2oo1a("#y m4^;sg>?͐[b!0f7 CG7B``|~Tg墸A$6ːT3>(ccȀ~ ͉W4:Ƈ~}{+=o1rI8KNAxɘ23~@u=tD޽HqJJJIuϖM(,,:˾@v!*N⅊,_'G':}-\A];/ɉn!nos?n+?\$jg>"kHIEogȇƣmV$ObQbg~\$Sґ_n>scf.DX0_o݊Ea5q@ c/=Bu| mc'1oJēlBr*N5p7F@#\\[&Mkh4@*S(||A8x ~:t !$?yzu.б?6iiEwo@Rb% #bt#\I:8|T$%bp~=gp#þ=#)%$f\WS[G-u;yٖчy;PUU\% }#fį;~'_~p"YXԐݸy#)6h'I&s-O'ѽKg岙}za_]E!J^j9_Q/Б6iD{,eQ4?ꆇ}UQNQv> q$yAa-y~9&oXL]K^cvFJ\?<9m&fkCrHHt,>غ}'qO2A c0mo'@n>...xd{FbmYʒ0p}eѻk'u'1.lɺw1$xg@0VrQ΅ddk"TK{[ R*h45(l埐-rڶ5>6a{CA?~'&[)?no7L9&l i_MX}JpW`C_}kb@d21~K/,4EW5^ӕmtUd$Z:;wQD*V-[`ӖrpӖmfuu).Bj:s]TΘi>Y$ YfVXJa.($sd{3d2UYQIr(n1otsfFJ4{4۶ji}q^9=d>: D>bFq陙*vy1 lwSNqe>6zI~uYLĆ̍6soDR d#>=+dfMa&nsg ~9l0ܹwa 577W 9am7ٔdkiFvu_J̅ m\iǂ'՜f?J[ f60}Bssu3]٧#mZLBHMϐ/lմuF=٧3KGۨ4^)4r6SPb͵1a#ј䰐i29$ Z쏟JkYXeĺ1UCl5'W7ҩ&"}(Shxq.!،#q&ARX:~ޞtAWgaq,Df9,R359Yx6 fTYbI6><0]ǛɘB7c::8bBP), n7rsU\NCFԡ#Tz+|8%6lN͑{i's{~>bܫUO62ެ1`Ubտ| %(ԁCa[4ǏO}IDATڇ00e$_DA_$ҥ4݀C^C@'L}|<ڷkØv+kw~LUQfV"TJ.I7XcA̸(JErK$шn2GW&a`ۣ+nH$֒d6v^HHr*e/6+U]RB%\Rs>MS2Ncɸ QNJƐ"hmoؐG-UQzYrRHN)6Hw$N:I tw^"xwy"nb\XHP)TFbQ]\QQy3F{ s"`bqoѧʿIJTĬM zg%Eޣ}qĜW@dd3t܉E]JYGut×Q1&: Q:Z0B3/xp5DYs1s+d3E#h4kkzF@#g#POBA":j|j+RAs-0 Lz@M=PomR}w{$/WT+8kҬr)w,vcڢyDMvUb!,IKvYGRzΩ.xsT/^"!duD8K7QEUn1^܂Y) I3v&iN?coa c/܌&$eV̊O}{ax(䒤 ZI[$PQ& Ss3S_|#v ",>LBI[) T-zS5)* uptz8\}*IQmJI֍Уi0=!AA*]+?drR yhD!_VgZbWENxy V;L[\ @GHϾf@pcvӓkqո$e%iѣp= 5F@# >?uؚW+/_Nȏ%|>çsiF@#h40|MK:q}--z j8ЭV'BNfTU}5F;$.P}l >Z~ gkJŨ3O d~N!Pqc0jP]o?~J);IȊNrFx,2醜QFTh.:desrBV2_Iψk'#yF|D=? vIP4nZPW>cT?iFa_9XN`[D(R< ]i19/ւkDTxo(R1!L:QYrwGpc:>YXݸ#CBE4n$r{"uc$EYԷsɱ`q#8Qiw 4;"8ݑHD0Yh/(rj(v-ФK2.h8q>`Ɓ͓̊ݒQs.s<K9ۇ\1=Ϯ|Q%)/yg MPBBWRVaiQ7ZlދS=gɷC]n}n .*cnU-̓rq68Okzv'( ۴CTurA㴬ÉF|e)|H: %U:,>ݖxQK] P~ש%MzGkF1mȾazoF@# '7\& s 1;ѢeK -g]#iX#O04#E>[Z_Bs XۇX~~Xyi>`Yft0=2*=ӓYK%nYAu!ۉ+__L` ŒF8UR)h$k*GvqI,Ըu3zrs8Θ7ytt3<_R#~JZ\n,lB!0Kc/IIřA[*YA )IuhTg80Kfy%NB`%F}+8M42 l $oe/r^Blr})$k˽ٙVTrd<9g8WR?, b"xe!*2hEÃ5z%uA%k||=]<&n$:쀳eJǃ${@Ɨ]i3 x9;5`DڜWL}ނ=Xm>MX..c2}H|5@a%E`4V h4F< i"rջR#ӕEJ;!hdI<WЍZa)TQŇL\#Lr!lABO'] 3\Q⟑)V0ah-$dѽP%^HйgzI[.nТb#xz!]=T!,!dQDàVB\\O*yefA&fbCZd Orm,mkwyi/?kzY[LA.QP Cvrf,!D"϶]o['ڣIgIc~祏+uRo%:m=bycigYʵ6W_z+mU뼅8_2_mK:NޭUbe ۨHb.Ƕ}ٱE#h4o_UT/  E#h4 W#' Bz]cZ9 iD ? "uL"DU҃K^OWvm㫵k/WcWjsU+]z:!6zX?km[|XWa~iKPY=o{|x^mncH?lkWdڟj؞۾[g[5Wj[m=i5F@#"م ~&h4RA2D& .$!V*rZBx5!oˬMw:i4F@#KjŋA7t#BF@#h4?#T!%͔bğh4F@#]y0|ι4rG23WJZ];y\h4F@#h4F@#h82V9a:OOO3aXUU5NLX8In-Ê5F@#h4F@#h4zpee,~/*F4^^4F@#h4F@#h4W$+,jxŽ//-(^|IENDB`source/proposals/big_restructuring/book/0000775000175000017500000000000013223143453017555 5ustar rgerrgersource/proposals/big_restructuring/book/queues.rst0000664000175000017500000000041513223143453021616 0ustar rgerrgerQueues: prepare for the worst ============================= What are queues? ---------------- In-memory queues ^^^^^^^^^^^^^^^^ Disk queues ^^^^^^^^^^^ Disk-assisted queues ^^^^^^^^^^^^^^^^^^^^ Main message queue ------------------ Action queues ------------- source/proposals/big_restructuring/book/output.rst0000664000175000017500000000152613223143453021653 0ustar rgerrgerOutput ====== What should be logged --------------------- Message properties ^^^^^^^^^^^^^^^^^^ System properties ^^^^^^^^^^^^^^^^^ Variables ^^^^^^^^^ Functions ^^^^^^^^^ Transformation Modules ^^^^^^^^^^^^^^^^^^^^^^ When should be logged --------------------- Filter Conditions ^^^^^^^^^^^^^^^^^ * “traditional” severity and facility based selectors * property-based filters * expression-based filters * BSD-style blocks (not upward compatible) Rulesets ^^^^^^^^ How should be logged -------------------- RainerScript templates ^^^^^^^^^^^^^^^^^^^^^^ Legacy format templates ^^^^^^^^^^^^^^^^^^^^^^^ Properties in templates ^^^^^^^^^^^^^^^^^^^^^^^ Conditionally choosing a template ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Where should be send: Output Modules ------------------------------------ source/proposals/big_restructuring/book/overview.rst0000664000175000017500000000145513223143453022162 0ustar rgerrgerOverview ======== Write a bit about the logging challenge. What is Rsyslog? ---------------- `Rsyslog `_ is a **r**\ ocket-fast **sys**\ tem for **log** processing. It offers high-performance, great security features and a modular design. While it started as a regular syslogd, rsyslog has evolved into a kind of **swiss army knife of logging**, being able to - accept inputs from a wide variety of sources, - transform them, - and output the results to diverse destinations. Rsyslog has a strong enterprise focus but also scales down to small systems. Message flow in rsyslog ----------------------- From where to where and when... describes the flow. Input ^^^^^ Message Transformation ^^^^^^^^^^^^^^^^^^^^^^ Output ^^^^^^ Output format: Templates """""""""""""""""""""""" source/proposals/big_restructuring/book/input.rst0000664000175000017500000000010113223143453021436 0ustar rgerrgerInput: from where come the logs =============================== source/proposals/big_restructuring/book/first_setup.rst0000664000175000017500000000023113223143453022652 0ustar rgerrgerCreate your first Rsyslog setup =============================== Teach how to get log messages from `logger` command and write to files conditionally. source/proposals/big_restructuring/book/index.rst0000664000175000017500000000022513223143453021415 0ustar rgerrgerThe Book ======== .. toctree:: overview installing first_setup language input output queues security extending source/proposals/big_restructuring/book/security.rst0000664000175000017500000000014513223143453022156 0ustar rgerrgerSecurity ======== Securing your setup ------------------- Dropping privileges ------------------- source/proposals/big_restructuring/book/extending.rst0000664000175000017500000000014713223143453022276 0ustar rgerrgerExtending rsyslog ================= Native plugins -------------- External plugins ---------------- source/proposals/big_restructuring/book/language.rst0000664000175000017500000000070713223143453022076 0ustar rgerrgerConfiguration format ==================== Currently there are two ways of creating your configuration script: RainerScript and the legacy format. RainerScript format ------------------- General guidelines. Legacy configuration format (deprecated) ---------------------------------------- General guidelines. Why is there two different formats? ----------------------------------- Explain! todo:: Este item é do TO DO in language-rst. source/proposals/big_restructuring/book/installing.rst0000664000175000017500000000737413223143453022466 0ustar rgerrgerInstalling and configuring Rsyslog ================================== General procedures to install and configure. Installing from packages ------------------------ How to install using apt-get, yum, etc. Installing from sources ----------------------- How to compile the sources into your system. Testing configuration blocks .. code-block:: bash #### MODULES #### # Load (i)nput and (o)utput (m)odules module(load="imuxsock") module(load="imklog") module(load="imudp") module(load="imtcp") module(load="imrelp") module(load="omrelp") module(load="impstats" interval="3600" severity="7" log.syslog="off" log.file="/var/log/rsyslog-stats.log") # Module parameters input(type="imrelp" port="1514" ruleset="remote") input(type="imtcp" port="514" ruleset="remote") input(type="imudp" port="514" ruleset="remote") #### GLOBAL DIRECTIVES #### # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # Spool files $WorkDirectory /var/spool/rsyslog # Filter duplicate messages $RepeatedMsgReduction on #### RULES #### #...cut out standard log rules for brevity...# ruleset(name="remote"){ action(Name="storage" Type="omrelp" Target="10.1.1.100" Port="514" Action.ExecOnlyWhenPreviousIsSuspended="on" queue.FileName="storage-buffer" queue.SaveOnShutdown="on" queue.Type="LinkedList" Action.ResumeInterval="30" Action.ResumeRetryCount="-1" Timeout="5") action(Name="analysis" Type="omrelp" Target="10.1.1.101" Port="514" Action.ExecOnlyWhenPreviousIsSuspended="on" queue.FileName="analysis-buffer" queue.SaveOnShutdown="on" queue.Type="LinkedList" Action.ResumeInterval="30" Action.ResumeRetryCount="-1" Timeout="5") action(Name="indexer" Type="omfwd" Target="10.1.1.102" Protocol="tcp" Port="514" Action.ExecOnlyWhenPreviousIsSuspended="on" queue.FileName="indexer-buffer" queue.SaveOnShutdown="on" queue.Type="LinkedList" Action.ResumeInterval="30" Action.ResumeRetryCount="-1" Timeout="5") } #### INCLUDES #### # Includes config files (Do these last) $IncludeConfig /etc/rsyslog.d/*.conf .. note:: You'll learn exactly how to load each file/format in the next section. .. option:: dest_dir Destination directory. .. option:: -m , --module Run a module as a script. .. envvar:: nome_envvar Descrevendo um programa. .. program:: rm .. option:: -r Work recursively. .. program:: svn .. option:: -r revision Specify the revision to work upon. ------------------------------------------------- .. describe:: PAPER You can set this variable to select a paper size. ------------------------------------------------- todo:: Este item é do TO DO. ------------------------------------------------- todolist:: none ------------------------------------------------- FIM source/proposals/big_restructuring/documentation_review.rst0000664000175000017500000000546213223143453023616 0ustar rgerrgerRsyslog Documentation Review Proposal ===================================== Currently the Rsyslog documentation is spread over many places. It's not logical and well-organized as well. The objective of this proposal is to address those issues and establish a procedure for further development of the documentation. .. note:: We SHOULD NOT write examples using mixed formats, RainerScripts and legacy. It confused the readers. We can provide them in both formats, but should not mix them. Compile information from current sources of information ------------------------------------------------------- Below are listed the official locations where documentation about Rsyslog can be found. * Wiki: http://wiki.rsyslog.com/index.php/Main_Page * Rainer's blog: http://blog.gerhards.net/2012/10/how-to-use-rsyslogs-ruleset-and-call.html * Issues: https://github.com/rsyslog/rsyslog * docs: https://github.com/rsyslog/rsyslog-doc * Forum: http://kb.monitorware.com/configuration-f36.html * https://www.youtube.com/user/rainergerhards Add a Cookbook Section ---------------------- We should create some cookbooks to help people get started with Rsyslog. Some candidates to be a cookbook are below. * http://sickbits.net/log-storage-and-analysis-infrastructure-reliable-logging-and-analysis-with-rsyslog-and-relp/ * http://kb.monitorware.com/omfile-with-dynfile-syslogfacility-text-t12515.html * http://www.freeipa.org/page/Howto/Centralised_Logging_with_Logstash/ElasticSearch/Kibana Add a subsection called "processing logs from". We'd place articles that'd would help people with specific common scenarios for a specific log sender application. Add a Reference Section ----------------------- This section would have all the reference configuration of all possibile tags, in both formats, RainerScript and legacy. Write articles that address common problems ------------------------------------------- Some of the common are following. * https://github.com/rsyslog/rsyslog/issues/160 * http://kb.monitorware.com/nginx-logging-rsyslog-t12359.html * http://trac.nginx.org/nginx/ticket/677 Extra ----- Some resources worth taking a look. * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Viewing_and_Managing_Log_Files.html * https://www.usenix.org/system/files/login/articles/06_lang-online.pdf * https://media.readthedocs.org/pdf/rsyslog/latest/rsyslog.pdf * http://download.rsyslog.com/rainerscript2_rsyslog.conf * http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-example.conf * http://www.rsyslog.com/doc/syslog_parsing.html Initial Summary --------------- - Troubleshooting * http://www.rsyslog.com/how-can-i-check-the-config/ Proposed Documentation Structure -------------------------------- toctree:: new_documentation/index source/proposals/big_restructuring/contributing/0000775000175000017500000000000013223143453021332 5ustar rgerrgersource/proposals/big_restructuring/contributing/community/0000775000175000017500000000000013223143453023356 5ustar rgerrgersource/proposals/big_restructuring/contributing/community/releases.rst0000664000175000017500000000253613223143453025721 0ustar rgerrgerThe Release Process =================== This document explains the Rsyslog release process (Rsyslog being the code hosted on the main ``rsyslog/rsyslog`` `Git repository`_). Rsyslog manages its releases through a *time-based model*; a new Rsyslog minor version comes out every *six weeks*. .. tip:: The meaning of "minor" comes from the `Semantic Versioning`_ strategy. Each minor version sticks to the same very well-defined process where we start with a development period, followed by a maintenance period. .. note:: This release process has been adopted as of Rsyslog 8.2, and all the "rules" explained in this document must be strictly followed as of Rsyslog 8.3. .. _contributing-release-development: Development ----------- The full development period lasts six weeks and is divided into two phases: * *Development*: *Four weeks* to add new features and to enhance existing ones; * *Stabilisation*: *Two weeks* to fix bugs, prepare the release, and wait for the whole Rsyslog ecosystem (third-party libraries, bundles, and projects using Rsyslog) to catch up. During the development phase, any new feature can be reverted if it won't be finished in time or if it won't be stable enough to be included in the current final release. .. _Semantic Versioning: http://semver.org/ .. _Git repository: https://github.com/rsyslog/rsyslog source/proposals/big_restructuring/contributing/community/index.rst0000664000175000017500000000011313223143453025212 0ustar rgerrgerCommunity ========= .. toctree:: :maxdepth: 2 releases other source/proposals/big_restructuring/contributing/community/other.rst0000664000175000017500000000075213223143453025235 0ustar rgerrgerOther Resources =============== In order to follow what is happening in the community you might find helpful these additional resources: * List of open pull requests `pull requests`_ * List of recent `commits`_ * List of open bugs and enhancements `bugs and enhancements`_ .. _pull requests: https://github.com/rsyslog/rsyslog/pulls .. _commits: https://github.com/rsyslog/rsyslog/commits/master .. _bugs and enhancements: https://github.com/rsyslog/rsyslog/issues source/proposals/big_restructuring/contributing/code/0000775000175000017500000000000013223143453022244 5ustar rgerrgersource/proposals/big_restructuring/contributing/code/standards.rst0000664000175000017500000000072113223143453024761 0ustar rgerrgerCoding Standards ================ When contributing code to Rsyslog, you must follow its coding standards. To make a long story short, here is the golden rule: **Imitate the existing Rsyslog code**. Most open-source modules and libraries recommended by Rsyslog also follow the same guidelines, and you should too. Remember that the main advantage of standards is that every piece of code looks and feels familiar, it's not about this or that being more readable. source/proposals/big_restructuring/contributing/code/git.rst0000664000175000017500000000243013223143453023560 0ustar rgerrgerGit === This document explains some conventions and specificities in the way we manage the Rsyslog code with Git. Pull Requests ------------- Whenever a pull request is merged, all the information contained in the pull request (including comments) is saved in the repository. You can easily spot pull request merges as the commit message always follows this pattern: .. code-block:: text merged branch USER_NAME/BRANCH_NAME (PR #1111) The PR reference allows you to have a look at the original pull request on GitHub: https://github.com/rsyslog/rsyslog/pull/1111. But all the information you can get on GitHub is also available from the repository itself. The merge commit message contains the original message from the author of the changes. Often, this can help understand what the changes were about and the reasoning behind the changes. Moreover, the full discussion that might have occurred back then is also stored as a Git note. To get access to these notes, add this line to your ``.git/config`` file: .. code-block:: ini fetch = +refs/notes/*:refs/notes/* After a fetch, getting the GitHub discussion for a commit is then a matter of adding ``--show-notes=github-comments`` to the ``git show`` command: .. code-block:: bash $ git show HEAD --show-notes=github-comments source/proposals/big_restructuring/contributing/code/index.rst0000664000175000017500000000013213223143453024101 0ustar rgerrgerContributing Code ================= .. toctree:: :maxdepth: 2 standards git source/proposals/big_restructuring/contributing/index.rst0000664000175000017500000000016113223143453023171 0ustar rgerrgerContributing ============ .. toctree:: code/index documentation/index community/index source/proposals/big_restructuring/contributing/documentation/0000775000175000017500000000000013223143453024203 5ustar rgerrgersource/proposals/big_restructuring/contributing/documentation/index.rst0000664000175000017500000000011713223143453026043 0ustar rgerrgerHow to contribute to the documentation ====================================== source/proposals/big_restructuring/index.rst0000664000175000017500000000046013223143453020464 0ustar rgerrgerRsyslog documentation ===================== Below is the proposed documentation structure. It's initial content is the current documentation available, just organized differently. .. toctree:: book/index cookbook/index reference/index contributing/index documentation_review.rst source/proposals/big_restructuring/reference/0000775000175000017500000000000013223143453020561 5ustar rgerrgersource/proposals/big_restructuring/reference/input.rst0000664000175000017500000000007513223143453022454 0ustar rgerrgerInput Configuration Reference ============================= source/proposals/big_restructuring/reference/action.rst0000664000175000017500000000007713223143453022574 0ustar rgerrgerAction Configuration Reference ============================== source/proposals/big_restructuring/reference/parser.rst0000664000175000017500000000007713223143453022613 0ustar rgerrgerParser Configuration Reference ============================== source/proposals/big_restructuring/reference/index.rst0000664000175000017500000000020213223143453022414 0ustar rgerrgerConfiguration Reference ======================= .. toctree:: module input action parser global timezone source/proposals/big_restructuring/reference/timezone.rst0000664000175000017500000000010313223143453023137 0ustar rgerrgerTimezone Configuration Reference ================================ source/proposals/big_restructuring/reference/global.rst0000664000175000017500000000007713223143453022557 0ustar rgerrgerGlobal Configuration Reference ============================== source/proposals/big_restructuring/reference/module.rst0000664000175000017500000000007713223143453022604 0ustar rgerrgerModule Configuration Reference ============================== source/proposals/big_restructuring/cookbook/0000775000175000017500000000000013223143453020431 5ustar rgerrgersource/proposals/big_restructuring/cookbook/templates/0000775000175000017500000000000013223143453022427 5ustar rgerrgersource/proposals/big_restructuring/cookbook/templates/rfc5424.rst0000664000175000017500000000014713223143453024254 0ustar rgerrgerConfiguring an RFC 5424 Template with Json message ================================================== source/proposals/big_restructuring/cookbook/templates/index.rst0000664000175000017500000000007413223143453024271 0ustar rgerrgerTemplates ========= .. toctree:: rfc3164 rfc5424 source/proposals/big_restructuring/cookbook/templates/rfc3164.rst0000664000175000017500000000014713223143453024253 0ustar rgerrgerConfiguring an RFC 3164 Template with Json message ================================================== source/proposals/big_restructuring/cookbook/index.rst0000664000175000017500000000011513223143453022267 0ustar rgerrgerThe Cookbook ============ .. toctree:: templates/index setup/index source/proposals/big_restructuring/cookbook/setup/0000775000175000017500000000000013223143453021571 5ustar rgerrgersource/proposals/big_restructuring/cookbook/setup/index.rst0000664000175000017500000000012113223143453023424 0ustar rgerrgerSetup Cookbooks =============== .. toctree:: centralised_logging_logstash source/proposals/big_restructuring/cookbook/setup/centralised_logging_logstash.rst0000664000175000017500000000015713223143453030235 0ustar rgerrgerCentralised logging with Logstash/ElasticSearch/Kibana ====================================================== source/proposals/lookup_tables.rst0000664000175000017500000002106113223143453016457 0ustar rgerrgerLookup Tables ============= **NOTE: this is proposed functionality, which is NOT YET IMPLEMENTED!** **Lookup tables are a powerful construct to obtain "class" information based on message content (e.g. to build log file names for different server types, departments or remote offices).** The base idea is to use a message variable as an index into a table which then returns another value. For example, $fromhost-ip could be used as an index, with the table value representing the type of server or the department or remote office it is located in. A main point with lookup tables is that the lookup is very fast. So while lookup tables can be emulated with if-elseif constructs, they are generally much faster. Also, it is possible to reload lookup tables during rsyslog runtime without the need for a full restart. The lookup tables itself exists in a separate configuration file (one per table). This file is loaded on rsyslog startup and when a reload is requested. There are different types of lookup tables: - **string** - the value to be looked up is an arbitrary string. Only exact some strings match. - **array** - the value to be looked up is an integer number from a consequtive set. The set does not need to start at zero or one, but there must be no number missing. So, for example 5,6,7,8,9 would be a valid set of index values, while 1,2,4,5 would not be (due to missing 2). A match happens if the requested number is present. - **sparseArray** - the value to be looked up is an integer value, but there may be gaps inside the set of values (usually there are large gaps). A typical use case would be the matching of IPv4 address information. A match happens on the first value that is less than or equal to the requested value. Note that index integer numbers are represented by unsigned 32 bits. Lookup tables can be access via the lookup() built-in function. The core idea is to set a local variable to the lookup result and later on use that local variable in templates. More details on usage now follow. Lookup Table File Format ------------------------ Lookup table files contain a single JSON object. This object contains of a header and a table part. Header ~~~~~~ The header is the top-level json. It has parameters "version", "nomatch", and "type". The version parameter must be given and must always be one for this version of rsyslog. The nomatch parameter is optional. If specified, it contains the value to be used if lookup() is provided an index value for which no entry exists. The default for "nomatch" is the empty string. Type specifies the type of lookup to be done. Table ~~~~~ This must be an array of elements, even if only a single value exists (for obvious reasons, we do not expect this to occur often). Each array element must contain two fields "index" and "value". Example ~~~~~~~ This is a sample of how an ip-to-office mapping may look like: :: { "version":1, "nomatch":"unk", "type":"string", "table":[ {"index":"10.0.1.1", "value":"A" }, {"index":"10.0.1.2", "value":"A" }, {"index":"10.0.1.3", "value":"A" }, {"index":"10.0.2.1", "value":"B" }, {"index":"10.0.2.2", "value":"B" }, {"index":"10.0.2.3", "value":"B" } ] } Note: if a different IP comes in, the value "unk" is returend thanks to the nomatch parameter in the first line. RainerScript Statements ----------------------- lookup\_table() Object ~~~~~~~~~~~~~~~~~~~~~~ This statement defines and intially loads a lookup table. Its format is as follows: :: lookup_table(name="name" file="/path/to/file" reloadOnHUP="on|off") Parameters ^^^^^^^^^^ - **name** (mandatory) Defines the name of lookup table for further reference inside the configuration. Names must be unique. Note that it is possible, though not advisible, to have different names for the same file. - **file** (mandatory) Specifies the full path for the lookup table file. This file must be readable for the user rsyslog is run under (important when dropping privileges). It must point to a valid lookup table file as described above. - **reloadOnHUP** (optional, default "on") Specifies if the table shall automatically be reloaded as part of HUP processing. For static tables, the default is "off" and specifying "on" triggers an error message. Note that the default of "on" may be somewhat suboptimal performance-wise, but probably is what the user intuitively expects. Turn it off if you know that you do not need the automatic reload capability. lookup() Function ~~~~~~~~~~~~~~~~~ This function is used to actually do the table lookup. Format: :: lookup("name", indexvalue) Parameters ^^^^^^^^^^ - **return value** The function returns the string that is associated with the given indexvalue. If the indexvalue is not present inside the lookup table, the "nomatch" string is returned (or an empty string if it is not defined). - **name** (constant string) The lookup table to be used. Note that this must be specificed as a constant. In theory, variable table names could be made possible, but their runtime behaviour is not as good as for static names, and we do not (yet) see good use cases where dynamic table names could be useful. - **indexvalue** (expression) The value to be looked up. While this is an arbitrary RainerScript expression, it's final value is always converted to a string in order to conduct the lookup. For example, "lookup(table, 3+4)" would be exactly the same as "lookup(table, "7")". In most cases, indexvalue will probably be a single variable, but it could also be the result of all RainerScript-supported expression types (like string concatenation or substring extraction). Valid samples are "lookup(name, $fromhost-ip & $hostname)" or "lookup(name, substr($fromhost-ip, 0, 5))" as well as of course the usual "lookup(table, $fromhost-ip)". load\_lookup\_table Statement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Note: in the final implementation, this MAY be implemented as an action. This is a low-level decesion that must be made during the detail development process. Parameters and semantics will remain the same of this happens.** This statement is used to reload a lookup table. It will fail if the table is static. While this statement is executed, lookups to this table are temporarily blocked. So for large tables, there may be a slight performance hit during the load phase. It is assume that always a triggering condition is used to load the table. :: load_lookup_table(name="name" errOnFail="on|off" valueOnFail="value") Parameters ^^^^^^^^^^ - **name** (string) The lookup table to be used. - **errOnFail** (boolean, default "on") Specifies whether or not an error message is to be emitted if there are any problems reloading the lookup table. - **valueOnFail** (optional, string) This parameter affects processing if the lookup table cannot be loaded for some reason: If the parameter is not present, the previous table will be kept in use. If the parameter is given, the previous table will no longer be used, and instead an empty table be with nomath=valueOnFail be generated. In short, that means when the parameter is set and the reload fails, all matches will always return what is specified in valueOnFail. Usage example ~~~~~~~~~~~~~ For clarity, we show only those parts of rsyslog.conf that affect lookup tables. We use the remote office example that an example lookup table file is given above for. :: lookup_table(name="ip2office" file="/path/to/ipoffice.lu" reloadOnHUP="off") template(name="depfile" type="string" string="/var/log/%$usr.dep%/messages") set $usr.dep = lookup("ip2office", $fromhost-ip); action(type="omfile" dynfile="depfile") # support for reload "commands" if $fromhost-ip == "10.0.1.123" and $msg contains "reload office lookup table" then load_lookup_table(name="ip2office" errOnFail="on") Note: for performance reasons, it makes sense to put the reload command into a dedicated ruleset, bound to a specific listener - which than should also be sufficiently secured, e.g. via TLS mutual auth. Implementation Details ---------------------- The lookup table functionality is implemented via highly efficient algorithms. The string lookup has O(log n) time complexity. The array lookup is O(1). In case of sparseArray, we have O(log n). To preserve space and, more important, increase cache hit performance, equal data values are only stored once, no matter how often a lookup index points to them. source/proposals/index.rst0000664000175000017500000000016413223143453014724 0ustar rgerrgerProposals ========= .. toctree:: :maxdepth: 2 version_naming lookup_tables big_restructuring/index source/how2help.rst0000664000175000017500000000432012704114446013324 0ustar rgerrgerHow you can Help ---------------- **You like rsyslog and would like to lend us a helping hand?** This page tells you how easy it is to help a little bit. You can contribute to the project even with a single mouse click! If you could pick a single item from the wish list, that would be awfully helpful! This is our wish list: - let others know how great rsyslog is - spread word about rsyslog in forums and newsgroups - place a link to `www.rsyslog.com `_ from your home page - let us know about rsyslog - we are eager for feedback - tell us what you like and what you not like - so that we can include that into development - tell us what you use rsyslog for - especially if you have high traffic volume or an otherwise "uncommon" deployment. We are looking for case studies and experience how rsyslog performs in unusual scenarios. - allow us to post your thoughts and experiences as a "user story" on the web site (so far, none are there ;)) - if you know how to create packages (rpm, deb, ...) - we would very much appreciate your help with package creation. We know that it is important to have good binary packages for a product to spread widely. Yet, we do not have the knowledge to do it all ourselves. `Drop Rainer a note `_\ if you could help us out. - if you have configured a device for sending syslog data, and that device is not in our `syslog configuration database `_, you might want to tell us how to configure it. - if you are a corporate user - you might consider `Adiscon `_'s commercial `MonitorWare products `_ for Windows, e.g. to deliver Windows Event Log data to rsyslogd (sales of the commercial products funds the open source development - and they also work very well). - you might be interested in `purchasing professional support or add-on development `_ for rsyslog **We appreciate your help very much.** A big thank you for anything you might do! source/licensing.rst0000664000175000017500000000603613223143010013537 0ustar rgerrgerLicensing ========= If you intend to use rsyslog inside a GPLv3 compatible project, you are free to do so. You don't even need to continue reading. If you intend to use rsyslog inside a non-GPLv3 compatible project, rsyslog offers you some liberties to do that, too. However, you then need to study the licensing details in depth. The project hopes this is a good compromise, which also gives a boost to fellow free software developers who release under GPLv3. And now on to the dirty and boring license details, still on a executive summary level. For the real details, check source files and the files COPYING and COPYING.LESSER inside the distribution. The rsyslog package contains several components: - the rsyslog core programs (like rsyslogd) - plugins (like imklog, omrelp, ...) - the rsyslog runtime library Each of these components can be thought of as individual projects. In fact, some of the plugins have different main authors than the rest of the rsyslog package. All of these components are currently put together into a single "rsyslog" package (tarball) for convenience: this makes it easier to distribute a consistent version where everything is included (and in the right versions) to build a full system. Platform package maintainers in general take the overall package and split off the individual components, so that users can install only what they need. In source installations, this can be done via the proper ./configure switches. However, while it is convenient to package all parts in a single tarball, it does not imply all of them are necessarily covered by the same license. Traditionally, GPL licenses are used for rsyslog, because the project would like to provide free software. GPLv3 has been used since around 2008 to help fight for our freedom. All rsyslog core programs are released under GPLv3. But, from the beginning on, plugins were separate projects and we did not impose and license restrictions on them. So even though all plugins that currently ship with the rsyslog package are also placed under GPLv3, this can not taken for granted. You need to check each plugins license terms if in question - this is especially important for plugins that do NOT ship as part of the rsyslog tarball. In order to make rsyslog technology available to a broader range of applications, the rsyslog runtime is, at least partly, licensed under LGPL. If in doubt, check the source file licensing comments. As of now, the following files are licensed under LGPL: - queue.c/.h - wti.c/.h - wtp.c/.h - vm.c/.h - vmop.c/.h - vmprg.c/.h - vmstk.c/.h - expr.c/.h - sysvar.c/.h - ctok.c/.h - ctok\_token.c/.h - regexp.c/.h - sync.c/.h - stream.c/.h - var.c/.h This list will change as time of the runtime modularization. At some point in the future, there will be a well-designed set of files inside a runtime library branch and all of these will be LGPL. Some select extras will probably still be covered by GPL. We are following a similar licensing model in GnuTLS, which makes effort to reserve some functionality exclusively to open source projects. source/tls_cert_100.jpg0000664000175000017500000000072512704114446013750 0ustar rgerrger--2014-01-22 12:50:33-- http://www.rsyslog.com/doc/tls_cert_100.jpg Resolving www.rsyslog.com (www.rsyslog.com)... 176.9.39.152 Connecting to www.rsyslog.com (www.rsyslog.com)|176.9.39.152|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/jpg] Saving to: ‘tls_cert_100.jpg’ 0K .......... ...... 70.2K=0.2s 2014-01-22 12:50:34 (70.2 KB/s) - ‘tls_cert_100.jpg’ saved [16607] source/examples/0000775000175000017500000000000013223143453012656 5ustar rgerrgersource/examples/high_performance.rst0000664000175000017500000000535113223143453016714 0ustar rgerrgerReceiving massive amounts of messages with high performance =========================================================== Use Case -------- You are receiving syslog messages via UDP and or TCP at a very high data rate. You want to tune the system so that it can process as many messages as possible. All messages shall be written to a single output file. Sample Configuration -------------------- :: # load required modules module(load="imudp" threads="2" timeRequery="8" batchSize="128") module(load="imptcp" threads="3") # listeners # repeat blocks if more listeners are needed # alternatively, use array syntax: # port=["514","515",...] input(type="imudp" port="514" ruleset="writeRemoteData") input(type="imptcp" port="10514" ruleset="writeRemoteData") # now define our ruleset, which also includes # threading and queue parameters. ruleset(name="writeRemoteData" queue.type="fixedArray" queue.size="250000" queue.dequeueBatchSize="4096" queue.workerThreads="4" queue.workerThreadMinimumMessages="60000" ) { action(type="omfile" file="/var/log/remote.log" ioBufferSize="64k" flushOnTXEnd="off" asyncWriting="on") } Notes on the suggested config ----------------------------- It is highly suggested to use a recent enough Linux kernel that supports the **recvmmsg()** system call. This system call improves UDP reception speed and decreases overall system CPU utilization. We use the **imptcp** module for tcp input, as it uses more optimal results. Note, however, that it is only available on Linux and does currently *not* support TLS. If **imptcp** cannot be used, use **imtcp** instead (this will be a bit slower). When writing to the output file, we use buffered mode. This means that full buffers are written, but during processing file lines are not written until the buffer is full (and thus may be delayed) and also incomplete lines are written (at buffer boundary). When the file is closed (rsyslogd stop or HUP), the buffer is completely flushed. As this is a high-traffic use case, we assume that buffered mode does not cause any concerns. Suggested User Performance Testing ---------------------------------- Each environment is a bit different. Depending on circumstances, the **imudp** module parameters may not be optimal. In order to obtain best performance, it is suggested to measure performance level with two to four threads and somewhat lower and higher batchSize. Note that these parameters affect each other. The values given in the config above should usually work well in *high-traffic* environments. They are sub-optimal for low to medium traffic environments. See Also -------- imptcp, imtcp, imudp, ruleset() source/examples/index.rst0000664000175000017500000000012713223143030014506 0ustar rgerrgerExample Use Cases ================= .. toctree:: :maxdepth: 2 high_performance source/installation/0000775000175000017500000000000013223143453013541 5ustar rgerrgersource/installation/packages.rst0000664000175000017500000000607513223143030016050 0ustar rgerrgerInstalling rsyslog from Package =============================== Installing from package is usually the most convenient way to install rsyslog. Usually, the regular package manager can be used. Package Availability -------------------- **Rsyslog is included in all major distributions.** So you do not necessarily need to take care of where packages can be found - they are "just there". Unfortunately, the distros provide often rather old versions. This is especially the case for so-called enterprise distributions. As long as you do not run into trouble with one of these old versions, using the distribution-provided packages is easy and a good idea. If you need new features, better performance and sometimes even a fix for a bug that the distro did not backport, you can use alternative packages. Please also note that the project team does not support outdated versions. While we probably can help with simple config questions, for anything else we concentrate on current versions. The rsyslog project offers current packages for a number of "big" distributions. They can be found at http://www.rsyslog.com in the download section. Note that some distributions (like Fedora) usually keep up with development rather quickly and so we do not provide special packages for them. If you do not find a suitable package for your distribution, there is no reason to panic. It is quite simple to :doc:`install rsyslog from the source tarball `, so you should consider that. Package Structure ----------------- Almost all distributions package rsyslog in multiple packages. This is also the way Adiscon packages are created. The reason is that rsyslog has so many input and output plugins that enable it to connect to different systems like MySQL, HDFS, ElasticSearch and so on. If everything were provided in a single gigantic package, you would need to install all of these dependencies, even though they are mostly not needed. For that reason, rsyslog comes with multiple packages: * *core package* (usually just called "rsyslog") - this contains core technology that is required as a base for all other packages. It also contains modules like the file writer or syslog forwarder that is extremely often used and has little dependencies. * *feature package* (usually called "rsyslog-feature") - there are multiple of these packages. What exactly is available and how it is named depends on the distro. This unfortunately is a bit consistent. Usually, it is a good guess that the package is intuitively named, e.g. "rsyslog-mysql" for the MySQL component and "rsyslog-elasticsearch" for ElasticSearch support. If in doubt, it is suggested to use the distro's package manager and search for "rsyslog*". Contributing ------------ **Packaging is a community effort.** If you would like to see support for an additional distribution and know how to build packages, please consider contributing to the project and joining the packaging team. Also, rsyslog's presence on github also contains the sources for the currently maintained packages. They can be found at https://github.com/rsyslog. source/installation/install_from_source.rst0000664000175000017500000002511713223143453020352 0ustar rgerrgerInstalling rsyslog from Source ============================== *Written by* `Rainer Gerhards `_ **In this paper, I describe how to install** `rsyslog `_. It is intentionally a brief step-by-step guide, targeted to those who want to quickly get it up and running. For more elaborate information, please consult the rest of the :doc:`manual set <../index>`. How to make your life easier... ------------------------------- There are :doc:`RPMs/packages for rsyslog ` available. If you use them, you can spare yourself many of the steps below. This is highly recommended if there is a package for your distribution available. Steps To Do ----------- Step 1 - Download Software ~~~~~~~~~~~~~~~~~~~~~~~~~~ For obvious reasons, you need to download rsyslog. Here, I assume that you use a distribution tarball. If you would like to use a version directly from the repository, see `build rsyslog from repository `_ instead. Load the most recent build from `http://www.rsyslog.com/downloads `_. Extract the software with "tar xzf -nameOfDownloadSet-". This will create a new subdirectory rsyslog-version in the current working directory. cd into that. Depending on your system configuration, you also need to install some build tools, most importantly make, the gcc compiler and the MySQL development system (if you intend to use MySQL - the package is often named "mysql-dev"). On many systems, these things should already be present. If you don't know exactly, simply skip this step for now and see if nice error messages pop up during the compile process. If they do, you can still install the missing build environment tools. So this is nothing that you need to look at very carefully. Build Requirements ~~~~~~~~~~~~~~~~~~ At a minimum, the following development tools must be present on the system: * C compiler (usually gcc) * make * libtool * rst2man (part of Python docutils) if you want to generate the man files * Bison and Flex (preferably, otherwise yacc and lex) * zlib development package (usually *libz-dev*) * json-c (usually named *libjson0-dev* or similar) * libuuid (usually *uuid-dev*, if not present use --disable-uuid) * libgcrypt (usually *libgcrypt-dev*) Also, development versions of the following supporting libraries that the rsyslog project provides are necessary: * liblogging (only stdlog component is hard requirement) * libestr In contrast to the other dependencies, recent versions of rsyslog may require recent versions of these libraries as well, so there is a chance that they must be built from source, too. Depending on which plugins are enabled, additional dependencies exist. These are reported during the ./configure run. **Important**: you need the **development** version of the packages in question. That is the version which is used by developers to build software that uses the respective package. Usually, they are separate from the regular user package. So if you just install the regular package but not the development one, ./configure will fail. As a concrete example, you may want to build ommysql. It obviously requires a package like *mysql-client*, but that is just the regular package and not sufficient to buid rsyslog successfully. To do so, you need to also install something named like *mysql-client-dev*. Usually, the regular package is automatically installed, when you select the development package, but not vice versa. The exact behaviour and names depend on the distribution you use. It is quite common to name development packages something along the line of *pkgname-dev* or *pkgname-devel* where *pkgname* is the regular package name (like *mysql-client* in the above example). Step 2 - Run ./configure ~~~~~~~~~~~~~~~~~~~~~~~~ Run ./configure to adopt rsyslog to your environment. While doing so, you can also enable options. Configure will display selected options when it is finished. For example, to enable MySQL support, run :: ./configure --enable-mysql Please note that MySQL support by default is NOT disabled. To learn which ./configure options are available and what their default values are, use ``./configure --help`` Step 3 - Compile ~~~~~~~~~~~~~~~~ That is easy. Just type "make" and let the compiler work. On any recent system, that should be a very quick task, on many systems just a matter of a few seconds. If an error message comes up, most probably a part of your build environment is not installed. Check with step 1 in those cases. Step 4 - Install ~~~~~~~~~~~~~~~~ Again, that is quite easy. All it takes is a "sudo make install". That will copy the rsyslogd and the man pages to the relevant directories. Step 5 - Configure rsyslogd ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this step, you tell rsyslogd what to do with received messages. If you are upgrading from stock syslogd, /etc/syslog.conf is probably a good starting point. Rsyslogd understands stock syslogd syntax, so you can simply copy over /etc/syslog.conf to /etc/rsyslog.conf. Note since version 3 rsyslog requires to load plug-in modules to perform useful work (more about `compatibility notes v3 `_). To load the most common plug-ins, add the following to the top of rsyslog.conf: :: $ModLoad immark # provides --MARK-- message capability $ModLoad imudp # provides UDP syslog reception $ModLoad imtcp # provides TCP syslog reception $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support Change rsyslog.conf for any further enhancements you would like to see. For example, you can add database writing as outlined in the paper "`Writing syslog Data to MySQL `_\ " (remember you need to enable MySQL support during step 2 if you want to do that!). Step 6 - Disable stock syslogd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **You can skip this and the following steps if rsyslog was already installed as the stock syslogd on your system (e.g. via a distribution default or package).** In this case, you are finished. If another syslogd is installed, it must be disabled and rsyslog set to become the default. This is because both it and rsyslogd listen to the same sockets, they can NOT be run concurrently. So you need to disable the stock syslogd. To do this, you typically must change your rc.d startup scripts. For example, under `Debian `_ this must be done as follows: The default runlevel is 2. We modify the init scripts for runlevel 2 - in practice, you need to do this for all run levels you will ever use (which probably means all). Under /etc/rc2.d there is a S10sysklogd script (actually a symlink). Change the name to \_S10sysklogd (this keeps the symlink in place, but will prevent further execution - effectively disabling it). Step 7 - Enable rsyslogd Autostart ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This step is very close to step 3. Now, we want to enable rsyslogd to start automatically. The rsyslog package contains a (currently small) number of startup scripts. They are inside the distro-specific directory (e.g. debian). If there is nothing for your operating system, you can simply copy the stock syslogd startup script and make the minor modifications to run rsyslogd (the samples should be of help if you intend to do this). In our Debian example, the actual scripts are stored in /etc/init.d. Copy the standard script to that location. Then, you need to add a symlink to it in the respective rc.d directory. In our sample, we modify rc2.d, and can do this via the command "ln -s ../init.d/rsyslogd S10rsyslogd". Please note that the S10 prefix tells the system to start rsyslogd at the same time stock sysklogd was started. **Important:** if you use the database functionality, you should make sure that MySQL starts before rsyslogd. If it starts later, you will receive an error message during each restart (this might be acceptable to you). To do so, either move MySQL's start order before rsyslogd or rsyslogd's after MySQL. Step 8 - Check daily cron scripts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Most distributions come pre-configured with some daily scripts for log rotation. As long as you use the same log file names, the log rotation scripts will probably work quite well. There is one caveat, though. The scripts need to tell syslogd that the files have been rotated. To do this, they typically have a part using syslogd's init script to do that. Obviously, scripts for other default daemons do not know about rsyslogd, so they manipulate the other one. If that happens, in most cases an additional instance of that daemon is started. It also means that rsyslogd is not properly told about the log rotation, which will lead it to continue to write to the now-rotated files. So you need to fix these scripts. See your distro-specific documentation how they are located. Done ~~~~ This concludes the steps necessary to install rsyslog. Of course, it is always a good idea to test everything thoroughly. At a minimalist level, you should do a reboot and after that check if everything has come up correctly. Pay attention not only to running processes, but also check if the log files (or the database) are correctly being populated. If rsyslogd encounters any serious errors during startup, you should be able to see them at least on the system console. They might not be in log file, as errors might occur before the log file rules are in place. So it is always a good idea to check system console output when things don't go smooth. In some rare cases, enabling debug logging (-d option) in rsyslogd can be helpful. If all fails, go to `www.rsyslog.com `_ and check the forum or mailing list for help with your issue. Housekeeping stuff ------------------ This section and its subsections contain all these nice things that you usually need to read only if you are really curios ;) Feedback requested ~~~~~~~~~~~~~~~~~~ I would appreciate feedback on this tutorial. Additional ideas, comments or bug sighting reports are very welcome. Please `let me know `_ about them. Revision History ~~~~~~~~~~~~~~~~ - 2005-08-08 \* `Rainer Gerhards`_ \* Initial version created - 2005-08-09 \* `Rainer Gerhards`_ \* updated to include distro-specific directories, which are now mandatory - 2005-09-06 \* `Rainer Gerhards`_ \* added information on log rotation scripts - 2007-07-13 \* `Rainer Gerhards`_ \* updated to new autotools-based build system - 2008-10-01 \* `Rainer Gerhards`_ \* added info on building from source repository - 2014-03181 \* `Rainer Gerhards `_  \* revamped doc to match current state. source/installation/index.rst0000664000175000017500000000101613223143010015365 0ustar rgerrgerInstallation ============ Installation is usually as simple as saying ``$ sudo yum install rsyslog`` or ``$ sudo apt-get install rsyslog`` However, distributions usually provide rather old versions of rsyslog, and so there are chances you want to have something newer. In that case, you need to either use the rsyslog project's own packages, a distribution tarball or build directly from repo. All of this is detailled in this chapter. .. toctree:: :maxdepth: 2 packages install_from_source build_from_repo source/installation/build_from_repo.rst0000664000175000017500000000532213223143030017433 0ustar rgerrgerInstalling rsyslog from the source repository ============================================= In most cases, people install rsyslog either via a package or use an "official" distribution tarball to generate it. But there may be situations where it is desirable to build directly from the source repository. This is useful for people who would like to participate in development or who would like to use the latest, not-yet-released code. The later may especially be the case if you are asked to try out an experimental version. Building from the repository is not much different than building from the source tarball, but some files are missing because they are output files and thus do not belong into the repository. Obtaining the Source -------------------- First of all, you need to download the sources. Rsyslog is kept in git. The "`Where to find the rsyslog source code `_\ " page on the project site will point you to the current repository location. After you have cloned the repository, you are in the master branch by default. This is where we keep the devel branch. If you need any other branch, you need to do a "git checkout --track -b branch origin/branch". For example, the command to check out the beta branch is "git checkout --track -b beta origin/beta". Prequisites ----------- To build the compilation system, you need * GNU autotools (autoconf, automake, ...) * libtool * pkg-config Unfortunately, the actual package names vary between distributions. Doing a search for the names above inside the packaging system should lead to the right path, though. If some of these tools are missing, you will see errors like this one: :: checking for SYSLOG_UNIXAF support... yes checking for FSSTND support... yes ./configure: line 25895: syntax error near unexpected token `RELP,' ./configure: line 25895: ` PKG_CHECK_MODULES(RELP, relp >= 0.1.1)' The actual error message will vary. In the case shown here, pkg-config was missing. **Important:** the build dependencies must be present **before** creating the build environment is begun. Otherwise, some hard to interpret errors may occur. For example, the error above will also occur if you install pkg-config, but *after* you have run *autoreconf*. So be sure everything is in place *before* you create the build environment. Creating the Build Environment ------------------------------ This is fairly easy: just issue "**autoreconf -fvi**\ ", which should do everything you need. Once this is done, you can follow the usual ./configure steps just like when you downloaded an official distribution tarball (see the `rsyslog install guide `_, starting at step 2, for further details about that). source/features.rst0000664000175000017500000001623113223143030013402 0ustar rgerrgerRSyslog - Features ================== **This page lists both current features as well as those being considered for future versions of rsyslog.** If you think a feature is missing, drop `Rainer `_ a note. Rsyslog is a vital project. Features are added each few days. If you would like to keep up of what is going on, you can also subscribe to the `rsyslog mailing list `_. A better structured feature list is now contained in our `rsyslog vs. syslog-ng comparison `_. Probably that page will replace this one in the future. Current Features ---------------- - native support for `writing to MySQL databases `_ - native support for writing to Postgres databases - direct support for Firebird/Interbase, OpenTDS (MS SQL, Sybase), SQLite, Ingres, Oracle, and mSQL via libdbi, a database abstraction layer (almost as good as native) - native support for `sending mail messages `_ (first seen in 3.17.0) - support for (plain) tcp based syslog - much better reliability - support for sending and receiving compressed syslog messages - support for on-demand on-disk spooling of messages that can not be processed fast enough (a great feature for `writing massive amounts of syslog messages to a database `_) - support for selectively `processing messages only during specific timeframes `_ and spooling them to disk otherwise - ability to monitor text files and convert their contents into syslog messages (one per line) - ability to configure backup syslog/database servers - if the primary fails, control is switched to a prioritized list of backups - support for receiving messages via reliable `RFC 3195 `_ delivery (a bit clumsy to build right now...) - ability to generate file names and directories (log targets) dynamically, based on many different properties - control of log output format, including ability to present channel and priority as visible log data - good timestamp format control; at a minimum, ISO 8601/RFC 3339 second-resolution UTC zone - ability to reformat message contents and work with substrings - support for log files larger than 2gb - support for file size limitation and automatic rollover command execution - support for running multiple rsyslogd instances on a single machine - support for `TLS-protected syslog `_ (both `natively `_ and via `stunnel `_) - ability to filter on any part of the message, not just facility and severity - ability to use regular expressions in filters - support for discarding messages based on filters - ability to execute shell scripts on received messages - control of whether the local hostname or the hostname of the origin of the data is shown as the hostname in the output - ability to preserve the original hostname in NAT environments and relay chains - ability to limit the allowed network senders - powerful BSD-style hostname and program name blocks for easy multi-host support - massively multi-threaded with dynamic work thread pools that start up and shut themselves down on an as-needed basis (great for high log volume on multicore machines) - very experimental and volatile support for `syslog-protocol `_ compliant messages (it is volatile because standardization is currently underway and this is a proof-of-concept implementation to aid this effort) - world's first implementation of syslog-transport-tls - the sysklogd's klogd functionality is implemented as the *imklog* input plug-in. So rsyslog is a full replacement for the sysklogd package - support for IPv6 - ability to control repeated line reduction ("last message repeated n times") on a per selector-line basis - supports sub-configuration files, which can be automatically read from directories. Includes are specified in the main configuration file - supports multiple actions per selector/filter condition - MySQL and Postgres SQL functionality as a dynamically loadable plug-in - modular design for inputs and outputs - easily extensible via custom plugins - an easy-to-write to plugin interface - ability to send SNMP trap messages - ability to filter out messages based on sequence of arrival - support for comma-separated-values (CSV) output generation (via the "csv" property replace option). The CSV format supported is that from RFC 4180. - support for arbitrary complex boolean, string and arithmetic expressions in message filters World's first ------------- Rsyslog has an interesting number of "world's firsts" - things that were implemented for the first time ever in rsyslog. Some of them are still features not available elsewhere. - world's first implementation of IETF I-D syslog-protocol (February 2006, version 1.12.2 and above), now RFC5424 - world's first implementation of dynamic syslog on-the-wire compression (December 2006, version 1.13.0 and above) - world's first open-source implementation of a disk-queueing syslogd (January 2008, version 3.11.0 and above) - world's first implementation of IETF I-D syslog-transport-tls (May 2008, version 3.19.0 and above) Upcoming Features ----------------- The list below is something like a repository of ideas we'd like to implement. Features on this list are typically NOT scheduled for immediate inclusion. **Note that we also maintain a `list of features that are looking for sponsors `_. If you are interested in any of these features, or any other feature, you may consider sponsoring the implementation. This is also a great way to show your commitment to the open source community. Plus, it can be financially attractive: just think about how much less it may be to sponsor a feature instead of purchasing a commercial implementation. Also, the benefit of being recognized as a sponsor may even drive new customers to your business!** - port it to more \*nix variants (eg AIX and HP UX) - this needs volunteers with access to those machines and knowledge - pcre filtering - maybe (depending on feedback)  - simple regex already partly added. So far, this seems sufficient so that there is no urgent need to do pcre. If done, it will be a loadable RainerScript function. - support for `RFC 3195 `_ as a sender - this is currently unlikely to happen, because there is no real demand for it. Any work on RFC 3195 has been suspend until we see some real interest in it.  It is probably much better to use TCP-based syslog, which is interoperable with a large number of applications. You may also read my blog post on the future of liblogging, which contains interesting information about the `future of RFC 3195 in rsyslog `_. To see when each feature was added, see the `rsyslog change log `_ (online only). source/direct_queue0.png0000664000175000017500000000400012704114446014301 0ustar rgerrgerPNG  IHDRݾhsBITO pHYseIDATxAhSw{FfbG"+WTW$Rp ] &SeHP=zf(hbN&҂$VmI_CH__b$c…+DJKKB4}է*ܰS    6kH;uI.H^Hػm?ϿoMҔ+M:dVTKla/ H6<\lƋrqHFD\q{5A>NnWܬd:/H~ꃆ5ΰ7AMϔJiTʫV}*.%=AGD?OD__ j?GM3ZWUtL37"#OӤLN=.ɥ* w1XiTLn,ypXI|RdO|!9.iIJgYm !9.cg|OITdV؋`{z         x[n?~+ϟh?~l8k׮UVwuu]pppxll"rcǎݽ{px۶mׯ7rӧ KJJc8,"9 bK9sˆUUUCCCG5={vKKᰈխ]p8H;wpxʕ 9߿pĉ[l1w^[[W.Y$>|h8yf`][[kd2i~"l^˗kY&l<,*RV&O޽ a,^,|##"26&sֳg}{II$$yqu%h+#/<?OF6+"8S)_<,_w)(o>u ,*|$""Ѩ=_B3܏?J2ia|aH\T820 y5x(5555555~h<?u뺎㸮;u&әoyO"v]{4Ǥo?;XeWN\O{^@M&]bE2<{lw@v3Mi6<]{Fx֭S%/_|O;ɷ۸qcss40_K8wxܹ?-rn$k`QAJREEEG {؉`!HRt:"+ ͛7{ٲea/;,)lذ!-`-K@ @ @ @ @ @ @ @ @ @ @ @ @ MLLbD""BtkkիW^v"X X X X X X X X X X X X X XҜ9s^vRXX              Ad27n {؉`!H'O {؉`P`P`P`P`P`P`P`P`P`P`P`P`P`P'4Y:`VJUY8i ~կe*y N!XkN!!욢)uTӃ vÂ- j(W9+;yR/;=D$,زC;?'{պxQ"`}w%1))V^lq TNI_/ճc ;,X]Љ 矗aHٳSZZ:úxQO=aRg2Uq;,֦RW.| dձ1MFhיG+FOHa( ^lnVmΟv8ks5D%wzz+`^zI ֲuQiӃZsRS$I=zDOxQXVu2Y(LUe]UP uzXknֿET]wމZ,˺4ӧu옒#b,TZ;,OHOwzT%܀`B} Tz&"`Bj^%,d%;= ,XjUkwuwz @"XԦ6U}[dtMMM7o=vXfͺ|1M8+++???ׂ5ièѣ&WJLL|ׯ_y/v*gW'5jV!͛7N\ÒE,`C簚{]XXёB1evhefssskkkDB"X]LW",Ҧ6IyZb5S?\`!^e8NH ^-jqz@"X$ X@ ܃`{,XHR%,$*VZ阃 , ج~2?է#4"E)EW#4b֦*@u 눎Lٚ=A hYeެ eAY=↉eeeÆ I[aҕ^dE0e2Fj}/ 'O0;7 m"X`_ **to see these options in action**. With that online tool, you can craft regular expressions based on samples and try out the different modes. Summary of nomatch Modes ~~~~~~~~~~~~~~~~~~~~~~~~ +------------+-----------------------------------------------------------+ | **Mode** | **Returned** | +------------+-----------------------------------------------------------+ | DFLT | "\*\*NO MATCH\*\*" | +------------+-----------------------------------------------------------+ | BLANK | "" (empty string) | +------------+-----------------------------------------------------------+ | ZERO | "0" | +------------+-----------------------------------------------------------+ | FIELD | full content of original field | +------------+-----------------------------------------------------------+ |   | `Interactive Tool `_ | +------------+-----------------------------------------------------------+ source/configuration/droppriv.rst0000664000175000017500000000437413223143453016316 0ustar rgerrgerDropping privileges in rsyslog ============================== **Available since**: 4.1.1 **Description**: Rsyslogd provides the ability to drop privileges by impersonating as another user and/or group after startup. Please note that due to POSIX standards, rsyslogd always needs to start up as root if there is a listener who must bind to a network port below 1024. For example, the UDP listener usually needs to listen to 514 and therefore rsyslogd needs to start up as root. If you do not need this functionality, you can start rsyslog directly as an ordinary user. That is probably the safest way of operations. However, if a startup as root is required, you can use the $PrivDropToGroup and $PrivDropToUser config directives to specify a group and/or user that rsyslogd should drop to after initialization. Once this happens, the daemon runs without high privileges (depending, of course, on the permissions of the user account you specified). There is some additional information available in the `rsyslog wiki `_. **Configuration Directives**: - **$PrivDropToUser** Name of the user rsyslog should run under after startup. Please note that this user is looked up in the system tables. If the lookup fails, privileges are NOT dropped. Thus it is advisable to use the less convenient $PrivDropToUserID directive. If the user id can be looked up, but can not be set, rsyslog aborts. - **$PrivDropToUserID** Much the same as $PrivDropToUser, except that a numerical user id instead of a name is specified.Thus, privilege drop will always happen. rsyslogd aborts. - **$PrivDropToGroup** Name of the group rsyslog should run under after startup. Please note that this user is looked up in the system tables. If the lookup fails, privileges are NOT dropped. Thus it is advisable to use the less convenient $PrivDropToGroupID directive. Note that all supplementary groups are removed from the process if $PrivDropToGroup is specified. If the group id can be looked up, but can not be set, rsyslog aborts. - **$PrivDropToGroupID** Much the same as $PrivDropToGroup, except that a numerical group id instead of a name is specified. Thus, privilege drop will always happen. source/configuration/config_param_types.rst0000664000175000017500000000336513223143453020321 0ustar rgerrgerConfiguration Parameter Types ============================= Configuration parameter values have different data types. Unfortunately, the type currently must be guessed from the description (consider contributing to the doc to help improve it). In general, the following types are used: - **numbers** The traditional integer format. Numbers may include '.' and ',' for readability. So you can for example specify either "1000" or "1,000" with the same result. Please note that rsyslogd simply *ignores* the punctuation. From it's point of view, "1,,0.0.,.,0" also has the value 1000. - **sizes** Used for things like file size, main message queue sizes and the like. These are integers, but support modifier after the number part. For example, 1k means 1024. Supported are k(ilo), m(ega), g(iga), t(era), p(eta) and e(xa). Lower case letters refer to the traditional binary defintion (e.g. 1m equals 1,048,576) whereas upper case letters refer to their new 1000-based definition (e.g 1M equals 1,000,000). - **complete line** A string consisting of multiple characters. This is relatively seldom used and sometimes looks confusing (rsyslog v7+ has a much better approach at these types of values). - **single word** This is used when only a single word can be provided. A "single word" is a string without spaces in it. **No** quoting is necessary nor permitted (the quotes would become part of the word). - **character** A single (printable) character. Must **not** be quoted. - **boolean** The traditional boolean type, specified as "on" (1) or "off" (0). Note that some other value types are occasionally used. However, the majority of types is one of those listed above. The list is updated as need arises and time permits. source/configuration/sysklogd_format.rst0000664000175000017500000003051713223143453017656 0ustar rgerrgersysklogd format ~~~~~~~~~~~~~~~ This is the format in use since the beginning of syslogging. It still is an excellent choice to do very simple things. For more advanced things, use RainerScript format. DESCRIPTION ~~~~~~~~~~~ The syslog.conf file is the main configuration file for syslogd(8) which logs system messages on \*nix systems. This file specifies rules for logging. For special features see the sysklogd(8) manpage. Every rule consists of two fields, a selector field and an action field. These two fields are separated by one or more spaces or tabs. The selector field specifies a pattern of facilities and priorities belonging to the specified action. Lines starting with a hash mark ("#") and empty lines are ignored. This variant of syslogd is able to understand a slightly extended syntax compared to the original BSD syslogd. One rule may be divided into several lines if the leading line is ter‐ minated with an backslash ("\\"). SELECTORS ~~~~~~~~~ The selector field consists of two parts, a facility and a priority, separated by a period ("."). Both parts are case insensitive and can also be specified as decimal numbers corresponding to the definitions in /usr/include/syslog.h. It is safer to use symbolic names rather than decimal numbers. Both facilities and priorities are described in syslog(3). The names mentioned below correspond to the similar LOG\_-values in /usr/include/syslog.h. The facility is one of the following keywords: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7. The keyword security is deprecated and mark is only for internal use and therefore should not be used in applications. The facility specifies the subsystem that produced the message, e.g. all mail programs log with the mail facility (LOG_MAIL) if they log using syslog. In most cases anyone can log to any facility, so we rely on convention for the correct facility to be chosen. However, generally only the kernel can log to the "kern" facility. This is because the implementation of openlog() and syslog() in glibc does not allow logging to the "kern" facility. Klogd circumvents this restriction when logging to syslogd by reimplementing those functions itself. The priority is one of the following keywords, in ascending order: debug, info, notice, warn‐ ing, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg). The keywords warn, error and panic are deprecated and should not be used anymore. The priority defines the severity of the message The behavior of the original BSD syslogd is that all messages of the specified priority and higher are logged according to the given action. This syslogd(8) behaves the same, but has some extensions. In addition to the above mentioned names the syslogd(8) understands the following extensions: An asterisk ("\*") stands for all facilities or all priorities, depending on where it is used (before or after the period). The keyword none stands for no priority of the given facility. Multiple facilities may be specified for a single priority pattern in one statement using the comma (",") operator to separate the facilities. You may specify as many facilities as you want. Please note that only the facility part from such a statement is taken, a priority part would be ignored. Multiple selectors may be specified for a single action using the semicolon (";") separa‐ tor. Selectors are processed from left to right, with each selector being able to overwrite preceding ones. Using this behavior you are able to exclude some priorities from the pat‐ tern. This syslogd(8) has a syntax extension to the original BSD source, which makes its use more intuitive. You may precede every priority with an equation sign ("=") to specify that syslogd should only refer to this single priority and not this priority and all higher priorities. You may also precide the priority with an exclamation mark ("!") if you want syslogd to ignore this priority and all higher priorities. You may even use both, the exclamation mark and the equation sign if you want syslogd to ignore only this single priority. If you use both extensions than the exclamation mark must occur before the equation sign, just use it intuitively. ACTIONS ~~~~~~~ The action field of a rule describes the abstract term "logfile". A "logfile" need not to be a real file, btw. The syslogd(8) provides the following actions. Regular File ............ Typically messages are logged to real files. The filename is specified with an absolute pathname. You may prefix each entry with a minus sign ("-") to avoid syncing the file after each log message. Note that you might lose information if the system crashes right after a write attempt. Nevertheless this might give you back some performance, especially if you run pro‐ grams that use logging in a very verbose manner. Named Pipes ........... This version of syslogd(8) has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipe symbol ("|") to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo(1) command before syslogd(8) is started. Terminal and Console .................... If the file you specified is a tty, special tty-handling is done, same with /dev/console. Remote Machine .............. This syslogd(8) provides full remote logging, i.e. is able to send messages to a remote host running syslogd(8) and to receive messages from remote hosts. The remote host won't forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign ("@"). Using this feature you are able to collect all syslog messages on a central host, if all other machines log remotely to that one. This reduces administration needs. Using a named pipe log method, messages from remote hosts can be sent to a log program. By reading log messages line by line such a program is able to sort log messages by host name or program name on the central log host. This way it is possible to split the log into separate files. List of Users ............. Usually critical messages are also directed to "root" on that machine. You can specify a list of users that ought to receive the log message on the terminal by writing their user‐ names. You may specify more than one user by separating the usernames with commas (","). If they're logged in they will receive the log messages. Everyone logged on .................. Emergency messages often go to all users currently online to notify them that something strange is happening with the system. To specify this wall(1)-feature use an asterisk ("*"). EXAMPLES ~~~~~~~~ Here are some examples, partially taken from a real existing site and configuration. Hope‐ fully they answer all questions about configuring this syslogd(8). If not, don't hesitate to contact the mailing list. # Store critical stuff in critical # \*.=crit;kern.none /var/adm/critical This will store all messages of priority crit in the file /var/adm/critical, with the excep‐ tion of any kernel messages. # Kernel messages are stored in the kernel file, # critical messages and higher ones also go # to another host and to the console # kern.\* /var/adm/kernel kern.crit @finlandia kern.crit /dev/console kern.info;kern.!err /var/adm/kernel-info The first rule directs any message that has the kernel facility to the file /var/adm/kernel. (But recall that only the kernel itself can log to this facility.) The second statement directs all kernel messages of priority crit and higher to the remote host finlandia. This is useful, because if the host crashes and the disks get irreparable errors you might not be able to read the stored messages. If they're on a remote host, too, you still can try to find out the reason for the crash. The third rule directs kernel messages of priority crit and higher to the actual console, so the person who works on the machine will get them, too. The fourth line tells the syslogd to save all kernel messages that come with priorities from info up to warning in the file /var/adm/kernel-info. This is an example of the 2nd selector overwriting part of the first one. The first selector selects kernel messages of priority info and higher. The second selector filters out kernel messages of priority error and higher. This leaves just priorities info, notice and warning to get logged. # The tcp wrapper logs with mail.info, we display # all the connections on tty12 # mail.=info /dev/tty12 This directs all messages that use mail.info (in source LOG_MAIL | LOG_INFO) to /dev/tty12, the 12th console. For example the tcpwrapper tcpd(8) uses this as its default. # Write all mail related logs to a file # mail.*;mail.!=info /var/adm/mail This pattern matches all messages that come with the mail facility, except for the info pri‐ ority. These will be stored in the file /var/adm/mail. # Log all mail.info and news.info messages to info # mail,news.=info /var/adm/info This will extract all messages that come either with mail.info or with news.info and store them in the file /var/adm/info. # Log info and notice messages to messages file # \*.=info;\*.=notice;\ mail.none /var/log/messages This lets the syslogd log all messages that come with either the info or the notice priority into the file /var/log/messages, except for all messages that use the mail facility. # Log info messages to messages file # \*.=info;\ mail,news.none /var/log/messages This statement causes the syslogd to log all messages that come with the info priority to the file /var/log/messages. But any message coming either with the mail or the news facility will not be stored. # Emergency messages will be displayed using wall # \*.=emerg \* This rule tells the syslogd to write all emergency messages to all currently logged in users. This is the wall action. # Messages of the priority alert will be directed # to the operator # \*.alert root,joey This rule directs all messages of priority alert or higher to the terminals of the operator, i.e. of the users "root" and "joey" if they're logged in. \*.\* @finlandia This rule would redirect all messages to a remote host called finlandia. This is useful especially in a cluster of machines where all syslog messages will be stored on only one machine. CONFIGURATION FILE SYNTAX DIFFERENCES ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syslogd uses a slightly different syntax for its configuration file than the original BSD sources. Originally all messages of a specific priority and above were forwarded to the log file. The modifiers "=", "!" and "-" were added to make the syslogd more flexible and to use it in a more intuitive manner. The original BSD syslogd doesn't understand spaces as separators between the selector and the action field. BUGS ~~~~ The effects of multiple selectors are sometimes not intuitive. For example "mail.crit,\*.err" will select "mail" facility messages at the level of "err" or higher, not at the level of "crit" or higher. Also, if you specify a selector with an exclamation mark in it which is not preceded by a corresponding selector without an exclamation mark, nothing will be logged. Intuitively, the selector "ftp.!alert" on its own will select all ftp messages with priorities less than alert. In fact it selects nothing. Similarly "ftp.!=alert" might reasonably be expected to select all ftp messages other than those with priority alert, but again it selects noth‐ ing. It seems the selectors with exclamation marks in them should only be used as "filters" following selectors without exclamation marks. Finally, using a backslash to divide a line into two doesn't work if the backslash is used immediately after the end of the selector, without intermediate whitespace. source/configuration/input.rst0000664000175000017500000000165513223143453015607 0ustar rgerrgerInput ===== .. index:: ! input .. _cfgobj_input: The ``input`` object, as its name suggests, describes message input sources. Without input, no processing happens at all, because no messages enter the rsyslog system. Inputs are implemented via :doc:`input modules `. The input object has different parameters: - those that apply to all input and are generally available for all inputs. These are documented below. - input-specific parameters. These are specific to a certain type of input. They are documented by the :doc:`input module ` in question. General Input Parameters ------------------------ Note: parameter names are case-insensitive. .. function:: type *Mandatory* The ```` is a string identifying the input module as given it each module's documentation. For example, the :doc:`UDP syslog input ` is named "imudp". source/configuration/rsyslog-example.conf0000664000175000017500000001402512704114446017716 0ustar rgerrger# A commented quick reference and sample configuration # WARNING: This is not a manual, the full manual of rsyslog configuration is in # rsyslog.conf (5) manpage # # "$" starts lines that contain new directives. The full list of directives # can be found in /usr/share/doc/rsyslog-1.19.6/doc/rsyslog_conf.html or online # at http://www.rsyslog.com/doc if you do not have (or find) a local copy. # # Set syslogd options # Some global directives # ---------------------- # $AllowedSender - specifies which remote systems are allowed to send syslog messages to rsyslogd # -------------- $AllowedSender UDP, 127.0.0.1, 192.0.2.0/24, [::1]/128, *.example.net, somehost.example.com # $UMASK - specifies the rsyslogd processes' umask # ------ $umask 0000 # $FileGroup - Set the group for dynaFiles newly created # ---------- $FileGroup loggroup # $FileOwner - Set the file owner for dynaFiles newly created. # ---------- $FileOwner loguser # $IncludeConfig - include other files into the main configuration file # -------------- $IncludeConfig /etc/some-included-file.conf # one file $IncludeConfig /etc/rsyslog.d/ # whole directory (must contain the final slash) # $ModLoad - Dynamically loads a plug-in and activates it # -------- $ModLoad ommysql # load MySQL functionality $ModLoad /rsyslog/modules/somemodule.so # load a module via absolute path # Templates # --------- # Templates allow to specify any format a user might want. # They MUST be defined BEFORE they are used. # A template consists of a template directive, a name, the actual template text # and optional options. A sample is: # $template MyTemplateName,"\7Text %property% some more text\n", # where: # * $template - tells rsyslog that this line contains a template. # * MyTemplateName - template name. All other config lines refer to this name. # * "\7Text %property% some more text\n" - templage text # The backslash is an escape character, i.e. \7 rings the bell, \n is a new line. # To escape: # % = \% # \ = \\ # Template options are case-insensitive. Currently defined are: # sql format the string suitable for a SQL statement. This will replace single # quotes ("'") by two single quotes ("''") to prevent the SQL injection # (NO_BACKSLASH_ESCAPES turned off) # stdsql - format the string suitable for a SQL statement that is to # be sent to a standards-compliant sql server. # (NO_BACKSLASH_ESCAPES turned on) # Properties inside templates # --------------------------- # Properties can be modified by the property replacer. They are accessed # inside the template by putting them between percent signs. The full syntax is as follows: # %propname:fromChar:toChar:options% # FromChar and toChar are used to build substrings. # If you need to obtain the first 2 characters of the # message text, you can use this syntax: "%msg:1:2%". # If you do not whish to specify from and to, but you want to # specify options, you still need to include the colons. # For example, to convert the full message text to lower case only, use # "%msg:::lowercase%". # The full list of property options can be found in rsyslog.conf(5) manpage # Samples of template definitions # ------------------------------- # A template that resambles traditional syslogd file output: $template TraditionalFormat,"%timegenerated% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\n" # A more verbose template: $template precise,"%syslogpriority%,%syslogfacility%,%timegenerated::fulltime%,%HOSTNAME%,%syslogtag%,%msg%\n" # A template that resembles RFC 3164 on-the-wire format: # (yes, there is NO space betwen syslogtag and msg! that's important!) $template RFC3164fmt,"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%" # a template resembling traditional wallmessage format: $template wallmsg,"\r\n\7Message from syslogd@%HOSTNAME% at %timegenerated% ...\r\n %syslogtag%%msg%\n\r" # The template below emulates winsyslog format, but we need to check the time # stamps used. It is also a good sampleof the property replacer in action. $template WinSyslogFmt,"%HOSTNAME%,%timegenerated:1:10:date-rfc3339%,%timegenerated:12:19:date-rfc3339%,%timegenerated:1:10:date-rfc3339%,%timegenerated:12:19:date-rfc3339%,%syslogfacility%,%syslogpriority%,%syslogtag%%msg%\n" # A template used for database writing (notice it *is* an actual # sql-statement): $template dbFormat,"insert into SystemEvents (Message, Facility,FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%',%syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')",sql # Samples of rules # ---------------- # Regular file # ------------ *.* /var/log/traditionalfile.log;TraditionalFormat # log to a file in the traditional format # Forwarding to remote machine # ---------------------------- *.* @172.19.2.16 # udp (standard for syslog) *.* @@172.19.2.17 # tcp # Database action # --------------- # (you must have rsyslog-mysql package installed) # !!! Don't forget to set permission of rsyslog.conf to 600 !!! *.* >hostname,dbname,userid,password # (default Monitorware schema, can be created by /usr/share/doc/rsyslog-mysql-1.19.6/createDB.sql) # And this one uses the template defined above: *.* >hostname,dbname,userid,password;dbFormat # Program to execute # ------------------ *.* ^alsaunmute # set default volume to soundcard # Filter using regex # ------------------ # if the user logges word rulez or rulezz or rulezzz or..., then we will shut down his pc # (note, that + have to be double backslashed...) :msg, regex, "rulez\\+" ^poweroff # A more complex example # ---------------------- $template bla_logged,"%timegenerated% the BLA was logged" :msg, contains, "bla" ^logger;bla_logged # Pipes # ----- # first we need to create pipe by # mkfifo /a_big_pipe *.* |/a_big_pipe # Discarding # ---------- *.* ~ # discards everything source/configuration/dyn_stats.rst0000664000175000017500000000755713223143030016456 0ustar rgerrgerDynamic Stats ============= Rsyslog produces runtime-stats to allow user to study service health, performance, bottlenecks etc. Runtime-stats counters that Rsyslog components publish are statically defined. **Dynamic Stats** (called dyn-stats henceforth) component allows user to configure stats-namespaces (called stats-buckets) and increment counters within these buckets using Rainerscript function call. The metric-name in this case can be a message-property or a sub-string extracted from message etc. Dyn-stats configuration ^^^^^^^^^^^^^^^^^^^^^^^ Dyn-stats configuration involves a **two part setup**. dyn_stats(name=""...) (object) -------------------------------------- **Defines** the bucket(identified by the bucket-name) and allows user to set some properties that control behavior of the bucket. :: dyn_stats(name="msg_per_host") Parameters: **name** : Name of the bucket. **resettable** : Whether or not counters should be reset every time they are reported. This works independent of ``resetCounters`` config parameter in :doc:`modules/impstats`. **maxCardinality** : Maximum number of unique counter-names to track. **unusedMetricLife** : Interval between full purges (in seconds). This prevents unused counters from occupying resources forever. A definition setting all the parameters looks like: :: dyn_stats(name="msg_per_host" resettable="on" maxCardinality="3000" unusedMetricLife="600") dyn_inc("", ) (function) -------------------------------------- **Increments** counter identified by value of variable in bucket identified by name. Parameters: **name** : Name of the bucket **expr** : Name of counter (this name will be reported by impstats to identify the counter) A ``dyn_inc`` call looks like: :: set $.inc = dyn_inc("msg_per_host", $hostname); if ($.inc != 0) then { .... } ``$.inc`` captures the error-code. It has value ``0`` when increment operation is successful and non-zero when it fails. It uses Rsyslog error-codes. Reporting ^^^^^^^^^ Legacy format: :: ... global: origin=dynstats msg_per_host.ops_overflow=1 msg_per_host.new_metric_add=3 msg_per_host.no_metric=0 msg_per_host.metrics_purged=0 msg_per_host.ops_ignored=0 ... msg_per_host: origin=dynstats.bucket foo=2 bar=1 baz=1 ... Json(variants with the same structure are used in other Json based formats such as ``cee`` and ``json-elasticsearch``) format: :: ... { "name": "global", "origin": "dynstats", "values": { "msg_per_host.ops_overflow": 1, "msg_per_host.new_metric_add": 3, "msg_per_host.no_metric": 0, "msg_per_host.metrics_purged": 0, "msg_per_host.ops_ignored": 0 } } ... { "name": "msg_per_host", "origin": "dynstats.bucket", "values": { "foo": 2, "bar": 1, "baz": 1 } } ... In this case counters are encapsulated inside an object hanging off top-level-key ``values``. Fields ------ **global: origin=dynstats**: **ops_overflow**: Number of operations ignored because number-of-counters-tracked has hit configured max-cardinality. **new_metric_add**: Number of "new" metrics added (new counters created). **no_metric**: Counter-name given was invalid (length = 0). **metrics_purged**: Number of counters discarded at discard-cycle (controlled by **unusedMetricLife**). **ops_ignored**: Number of operations ignored due to potential performance overhead. Dyn-stats subsystem ignores operations to avoid performance-penalty if it can't get access to counter without delay(lock acquiring latency). **purge_triggered**: Indicates that a discard was performed (1 implies a discard-cycle run). **msg_per_host: origin=dynstats.bucket**: ****: Value of counter identified by . source/configuration/examples.rst0000664000175000017500000001516613223143453016270 0ustar rgerrgerExamples -------- Below are example for templates and selector lines. I hope they are self-explanatory. Templates ~~~~~~~~~ Please note that the samples are split across multiple lines. A template MUST NOT actually be split across multiple lines. A template that resembles traditional syslogd file output: $template TraditionalFormat,"%timegenerated% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\\n" A template that tells you a little more about the message: $template precise,"%syslogpriority%,%syslogfacility%,%timegenerated%,%HOSTNAME%, %syslogtag%,%msg%\\n" A template for RFC 3164 format: $template RFC3164fmt,"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%" A template for the format traditonally used for user messages: $template usermsg," XXXX%syslogtag%%msg%\\n\\r" And a template with the traditonal wall-message format: $template wallmsg,"\\r\\n\\7Message from syslogd@%HOSTNAME% at %timegenerated% A template that can be used for the database write (please note the SQL template option) $template MySQLInsert,"insert iut, message, receivedat values ('%iut%', '%msg:::UPPERCASE%', '%timegenerated:::date-mysql%') into systemevents\\r\\n", SQL The following template emulates `WinSyslog `_ format (it's an `Adiscon `_ format, you do not feel bad if you don't know it ;)). It's interesting to see how it takes different parts out of the date stamps. What happens is that the date stamp is split into the actual date and time and the these two are combined with just a comma in between them. :: $template WinSyslogFmt,"%HOSTNAME%,%timegenerated:1:10:date-rfc3339%, %timegenerated:12:19:date-rfc3339%,%timegenerated:1:10:date-rfc3339%, %timegenerated:12:19:date-rfc3339%,%syslogfacility%,%syslogpriority%, %syslogtag%%msg%\\n" Selector lines ~~~~~~~~~~~~~~ :: # Store critical stuff in critical # *.=crit;kern.none /var/adm/critical This will store all messages with the priority crit in the file /var/adm/critical, except for any kernel message. :: # Kernel messages are first, stored in the kernel # file, critical messages and higher ones also go # to another host and to the console. Messages to # the host server.example.net are forwarded in RFC 3164 # format (using the template defined above). # kern.* /var/adm/kernel kern.crit @server.example.net;RFC3164fmt kern.crit /dev/console kern.info;kern.!err /var/adm/kernel-info The first rule direct any message that has the kernel facility to the file /var/adm/kernel. The second statement directs all kernel messages of the priority crit and higher to the remote host server.example.net. This is useful, because if the host crashes and the disks get irreparable errors you might not be able to read the stored messages. If they're on a remote host, too, you still can try to find out the reason for the crash. The third rule directs these messages to the actual console, so the person who works on the machine will get them, too. The fourth line tells rsyslogd to save all kernel messages that come with priorities from info up to warning in the file /var/adm/kernel-info. Everything from err and higher is excluded. :: # The tcp wrapper loggs with mail.info, we display # all the connections on tty12 # mail.=info /dev/tty12 This directs all messages that uses mail.info (in source LOG\_MAIL \| LOG\_INFO) to /dev/tty12, the 12th console. For example the tcpwrapper tcpd(8) uses this as it's default. :: # Store all mail concerning stuff in a file # mail.\*;mail.!=info /var/adm/mail This pattern matches all messages that come with the mail facility, except for the info priority. These will be stored in the file /var/adm/mail. :: # Log all mail.info and news.info messages to info # mail,news.=info /var/adm/info This will extract all messages that come either with mail.info or with news.info and store them in the file /var/adm/info. :: # Log info and notice messages to messages file # *.=info;*.=notice;\ mail.none /var/log/messages This lets rsyslogd log all messages that come with either the info or the notice facility into the file /var/log/messages, except for all messages that use the mail facility. :: # Log info messages to messages file # *.=info;\ mail,news.none /var/log/messages This statement causes rsyslogd to log all messages that come with the info priority to the file /var/log/messages. But any message coming either with the mail or the news facility will not be stored. :: # Emergency messages will be displayed to all users # *.=emerg :omusrmsg:* This rule tells rsyslogd to write all emergency messages to all currently logged in users. :: # Messages of the priority alert will be directed # to the operator # *.alert root,rgerhards This rule directs all messages with a priority of alert or higher to the terminals of the operator, i.e. of the users "root'' and "rgerhards'' if they're logged in. :: *.* @server.example.net This rule would redirect all messages to a remote host called server.example.net. This is useful especially in a cluster of machines where all syslog messages will be stored on only one machine. In the format shown above, UDP is used for transmitting the message. The destination port is set to the default auf 514. Rsyslog is also capable of using much more secure and reliable TCP sessions for message forwarding. Also, the destination port can be specified. To select TCP, simply add one additional @ in front of the host name (that is, @host is UPD, @@host is TCP). For example: :: *.* @@server.example.net To specify the destination port on the remote machine, use a colon followed by the port number after the machine name. The following forwards to port 1514 on server.example.net: :: *.* @@server.example.net:1514 This syntax works both with TCP and UDP based syslog. However, you will probably primarily need it for TCP, as there is no well-accepted port for this transport (it is non-standard). For UDP, you can usually stick with the default auf 514, but might want to modify it for security reasons. If you would like to do that, it's quite easy: :: *.* @server.example.net:1514 *.* >dbhost,dbname,dbuser,dbpassword;dbtemplate This rule writes all message to the database "dbname" hosted on "dbhost". The login is done with user "dbuser" and password "dbpassword". The actual table that is updated is specified within the template (which contains the insert statement). The template is called "dbtemplate" in this case. :: :msg,contains,"error" @server.example.net This rule forwards all messages that contain the word "error" in the msg part to the server "errorServer". Forwarding is via UDP. Please note the colon in fron source/configuration/ruleset/0000775000175000017500000000000013223143453015372 5ustar rgerrgersource/configuration/ruleset/rsconf1_rulesetparser.rst0000664000175000017500000001203713223143453022462 0ustar rgerrger$RulesetParser -------------- **Type:** ruleset-specific configuration directive **Parameter Values:** string **Available since:** 5.3.4+ **Default:** rsyslog.rfc5424 followed by rsyslog.rfc3164 **Description:** This directive permits to specify which `message parsers <../../concepts/messageparser.html>`_ should be used for the ruleset in question. It no ruleset is explicitly specified, the default ruleset is used. Message parsers are contained in (loadable) parser modules with the most common cases (RFC3164 and RFC5424) being build-in into rsyslogd. When this directive is specified the first time for a ruleset, it will not only add the parser to the ruleset's parser chain, it will also wipe out the default parser chain. So if you need to have them in addition to the custom parser, you need to specify those as well. Order of directives is important. Parsers are tried one after another, in the order they are specified inside the config. As soon as a parser is able to parse the message, it will do so and no other parsers will be executed. If no matching parser can be found, the message will be discarded and a warning message be issued (but only for the first 1,000 instances of this problem, to prevent message generation loops). Note that the rfc3164 parser will **always** be able to parse a message - it may just not be the format that you like. This has two important implications: 1) always place that parser at the END of the parser list, or the other parsers after it will never be tried and 2) if you would like to make sure no message is lost, placing the rfc3164 parser at the end of the parser list ensures that. Multiple parser modules are very useful if you have various devices that emit messages that are malformed in various ways. The route to take then is - make sure you find a custom parser for that device; if there is no one, you may consider writing one yourself (it is not that hard) or getting one written as part of `Adiscon's professional services for rsyslog `_. - load your custom parsers via $ModLoad - create a ruleset for each malformed format; assign the custom parser to it - create a specific listening port for all devices that emit the same malformed format - bind the listener to the ruleset with the required parser Note that it may be cumbersome to add all rules to all rulesets. To avoid this, you can either use $Include or `omruleset `_ (what probably provides the best solution). More information about rulesets in general can be found in :doc:`multi-ruleset support in rsyslog <../../concepts/multi_ruleset>`. **Caveats:** currently none known **Example:** This example assumes there are two devices emitting malformed messages via UDP. We have two custom parsers for them, named "device1.parser" and "device2.parser". In addition to that, we have a number of other devices sending well-formed messages, also via UDP. The solution is to listen for data from the two devices on two special ports (10514 and 10515 in this example), create a ruleset for each and assign the custom parsers to them. The rest of the messages are received via port 514 using the regular parsers. Processing shall be equal for all messages. So we simply forward the malformed messages to the regular queue once they are parsed (keep in mind that a message is never again parsed once any parser properly processed it). :: $ModLoad imudp $ModLoad pmdevice1 # load parser "device1.parser" for device 1 $ModLoad pmdevice2 # load parser "device2.parser" for device 2 # define ruleset for the first device sending malformed data $Ruleset maldev1 $RulesetCreateMainQueue on # create ruleset-specific queue $RulesetParser "device1.parser" # note: this deactivates the default parsers # forward all messages to default ruleset: $ActionOmrulesetRulesetName RSYSLOG\_DefaultRuleset \*.\* :omruleset: # define ruleset for the second device sending malformed data $Ruleset maldev2 $RulesetCreateMainQueue on # create ruleset-specific queue $RulesetParser "device2.parser" # note: this deactivates the default parsers # forward all messages to default ruleset: $ActionOmrulesetRulesetName RSYSLOG\_DefaultRuleset \*.\* :omruleset: # switch back to default ruleset $Ruleset RSYSLOG\_DefaultRuleset \*.\* /path/to/file auth.info @authlogger.example.net # whatever else you usually do... # now define the inputs and bind them to the rulesets # first the default listener (utilizing the default ruleset) $UDPServerRun 514 # now the one with the parser for device type 1: $InputUDPServerBindRuleset maldev1 $UDPServerRun 10514 # and finally the one for device type 2: $InputUDPServerBindRuleset maldev2 $UDPServerRun 10515 For an example of how multiple parser can be chained (and an actual use case), please see the example section on the `pmlastmsg `_ parser module. Note the positions of the directives. With the current config language, **sequence of statements is very important**. This is ugly, but unfortunately the way it currently works. source/configuration/ruleset/rsconf1_rulesetcreatemainqueue.rst0000664000175000017500000000627713223143453024354 0ustar rgerrger`rsyslog.conf configuration directive `_ $RulesetCreateMainQueue ----------------------- **Type:** ruleset-specific configuration directive **Parameter Values:** boolean (on/off, yes/no) **Available since:** 5.3.5+ **Default:** off **Description:** Rulesets may use their own "main" message queue for message submission. Specifying this directive, **inside a ruleset definition**, turns this on. This is both a performance enhancement and also permits different rulesets (and thus different inputs within the same rsyslogd instance) to use different types of main message queues. The ruleset queue is created with the parameters that are specified for the main message queue at the time the directive is given. If different queue configurations are desired, different main message queue directives must be used **in front of** the $RulesetCreateMainQueue directive. Note that this directive may only be given once per ruleset. If multiple statements are specified, only the first is used and for the others error messages are emitted. Note that the final set of ruleset configuration directives specifies the parameters for the default main message queue. To learn more about this feature, please be sure to read about `multi-ruleset support in rsyslog `_. **Caveats:** The configuration statement "$RulesetCreateMainQueue off" has no effect at all. The capability to specify this is an artifact of the legacy configuration language. **Example:** This example sets up a tcp server with three listeners. Each of these three listener is bound to a specific ruleset. As a performance optimization, the rulesets all receive their own private queue. The result is that received messages can be independently processed. With only a single main message queue, we would have some lock contention between the messages. This does not happen here. Note that in this example, we use different processing. Of course, all messages could also have been processed in the same way ($IncludeConfig may be useful in that case!). :: $ModLoad imtcp # at first, this is a copy of the unmodified rsyslog.conf #define rulesets first $RuleSet remote10514 $RulesetCreateMainQueue on # create ruleset-specific queue *.* /var/log/remote10514 $RuleSet remote10515 $RulesetCreateMainQueue on # create ruleset-specific queue *.* /var/log/remote10515 $RuleSet remote10516 $RulesetCreateMainQueue on # create ruleset-specific queue mail.* /var/log/mail10516 & ~ # note that the discard-action will prevent this messag from # being written to the remote10516 file - as usual... *.* /var/log/remote10516 # and now define listeners bound to the relevant ruleset $InputTCPServerBindRuleset remote10514 $InputTCPServerRun 10514 $InputTCPServerBindRuleset remote10515 $InputTCPServerRun 10515 $InputTCPServerBindRuleset remote10516 $InputTCPServerRun 10516 Note the positions of the directives. With the legacy language, position is very important. It is highly suggested to use the *ruleset()* object in RainerScript config language if you intend to use ruleset queues. The configuration is much more straightforward in that language and less error-prone. source/configuration/ruleset/index.rst0000664000175000017500000000161013223143010017216 0ustar rgerrgerRuleset-Specific Legacy Configuration Statements ================================================ These statements can be used to set ruleset parameters. To set these parameters, first use *$Ruleset*, **then** use the other configuration directives. Please keep in mind that each ruleset has a *main* queue. To specify parameter for these ruleset (main) queues, use the main queue configuration directives. .. toctree:: :glob: *rule* - **$Ruleset** *name* - starts a new ruleset or switches back to one already defined. All following actions belong to that new rule set. the *name* does not yet exist, it is created. To switch back to rsyslog's default ruleset, specify "RSYSLOG\_DefaultRuleset") as the name. All following actions belong to that new rule set. It is advised to also read our paper on :doc:`using multiple rule sets in rsyslog <../../concepts/multi_ruleset>`. source/configuration/global/0000775000175000017500000000000013224651466015160 5ustar rgerrgersource/configuration/global/options/0000775000175000017500000000000013223143453016642 5ustar rgerrgersource/configuration/global/options/rsconf1_generateconfiggraph.rst0000664000175000017500000001623213223143453025035 0ustar rgerrger$GenerateConfigGraph -------------------- **Type:** global configuration parameter **Default:** **Available Since:** 4.3.1 **CURRENTLY NOT AVAILABLE** **Description:** **This parameter is currently not supported. We had to disable it when we improved the rule engine. It is considerable effort to re-enable it. On the other hand, we are about to add a new config system, which will make yet another config graph method necessary. As such we have decided to currently disable this functionality and re-introduce it when the new config system has been instantiated.** This parameter permits to create (hopefully) good-looking visualizations of rsyslogd's configuration. It does not affect rsyslog operation. If the parameter is specified multiple times, all but the last are ignored. If it is specified, a graph is created. This happens both during a regular startup as well a config check run. It is recommended to include this parameter only for documentation purposes and remove it from a production configuration. The graph is not drawn by rsyslog itself. Instead, it uses the great open source tool `Graphviz `_ to do the actual drawing. This has at least two advantages: - the graph drawing support code in rsyslog is extremely slim and without overhead - the user may change or further annotate the generated file, thus potentially improving his documentation The drawback, of course, is that you need to run Graphviz once you have generated the control file with rsyslog. Fortunately, the process to do so is rather easy: #. add "$GenerateConfigGraph /path/to/file.dot" to rsyslog.conf (from now on, I will call the file just file.dot). Optionally, add "$ActionName" statement **in front of** those actions that you like to use friendly names with. If you do this, keep the names short. #. run rsyslog at least once (either in regular or configuration check mode) #. remember to remove the $GenerateConfigGraph parameter when you no longer need it (or comment it out) #. change your working directory to where you place the dot file #. if you would like to edit the rsyslog-generated file, now is the time to do so #. do "dot -Tpng file.dot > file.png" #. remember that you can use "convert -resize 50% file.png resized.png" if dot's output is too large (likely) or too small. Resizing can be especially useful if you intend to get a rough overview over your configuration. After completing these steps, you should have a nice graph of your configuration. Details are missing, but that is exactly the point. At the start of the graph is always (at least in this version, could be improved) a node called "inputs" in a triple hexagon shape. This represents all inputs active in the system (assuming you have defined some, what the current version does not check). Next comes the main queue. It is given in a hexagon shape. That shape indicates that a queue is present and used to de-couple the inbound from the outbound part of the graph. In technical terms, here is a threading boundary. Action with "real" queues (other than in direct mode) also utilize this shape. For actions, notice that a "hexagon action" creates a deep copy of the message. As such, a "discard hexagon action" actually does nothing, because it duplicates the message and then discards **the duplicate**. At the end of the diagram, you always see a "discard" action. This indicates that rsyslog discards messages which have been run through all available rules. Edges are labeled with information about when they are taken. For filters, the type of filter, but not any specifics, are given. It is also indicated if no filter is applied in the configuration file (by using a "\*.\*" selector). Edges without labels are unconditionally taken. The actions themselfs are labeled with the name of the output module that handles them. If provided, the name given via "ActionName" is used instead. No further details are provided. If there is anything in red, this should draw your attention. In this case, rsyslogd has detected something that does not look quite right. A typical example is a discard action which is followed by some other actions in an action unit. Even though something may be red, it can be valid - rsyslogd's graph generator does not yet check each and every specialty, so the configuration may just cover a very uncommon case. Now let's look at some examples. The graph below was generated on a fairly standard Fedora rsyslog.conf file. It had only the usually commented-out last forwarding action activated: .. figure:: rsyslog_confgraph_std.png :align: center :alt: rsyslog configuration graph for a default fedora rsyslog.conf rsyslog configuration graph for a default fedora rsyslog.conf This is the typical structure for a simple rsyslog configuration. There are a couple of actions, each guarded by a filter. Messages run from top to bottom and control branches whenever a filter evaluates to true. As there is no discard action, all messages will run through all filters and discarded in the system default discard action right after all configured actions. A more complex example can be seen in the next graph. This is a configuration I created for testing the graph-creation features, so it contains a little bit of everything. However, real-world configurations can look quite complex, too (and I wouldn't say this one is very complex): .. figure:: rsyslog_confgraph_complex.png :align: center :alt: Here, we have a user-defined discard action. You can immediately see this because processing branches after the first "builtin-file" action. Those messages where the filter evaluates to true for will never run through the left-hand action branch. However, there is also a configuration error present: there are two more actions (now shown red) after the discard action. As the message is discarded, these will never be executed. Note that the discard branch contains no further filters. This is because these actions are all part of the same action unit, which is guarded only by an entry filter. The same is present a bit further down at the node labeled "write\_system\_log\_2". This note has one more special feature, that is label was set via "ActionName", thus is does not have standard form (the same happened to the node named "Forward" right at the top of the diagram. Inside this diagram, the "Forward" node is executed asynchronously on its own queue. All others are executed synchronously. Configuration graphs are useful for documenting a setup, but are also a great `troubleshooting `_ resource. It is important to remember that **these graphs are generated from rsyslogd's in-memory action processing structures**. You can not get closer to understanding on how rsyslog interpreted its configuration files. So if the graph does not look what you intended to do, there is probably something wrong in rsyslog.conf. If something is not working as expected, but you do not spot the error immediately, I recommend to generate a graph and zoom it so that you see all of it in one great picture. You may not be able to read anything, but the structure should look good to you and so you can zoom into those areas that draw your attention. **Sample:** ``$DirOwner /path/to/graphfile-file.dot`` source/configuration/global/options/rsconf1_debugprintmodulelist.rst0000664000175000017500000000044313223143453025275 0ustar rgerrger$DebugPrintModuleList --------------------- **Type:** global configuration parameter **Default:** on **Description:** Specifies whether or not the module list should be written to the debug log. Possible values: on/off. Default is on. Does not affect operation if debugging is disabled. source/configuration/global/options/rsconf1_moddir.rst0000664000175000017500000000106613223143453022310 0ustar rgerrger$ModDir ------- **Type:** global configuration parameter **Default:** system default for user libraries, e.g. /usr/local/lib/rsyslog/ **Description:** Provides the default directory in which loadable modules reside. This may be used to specify an alternate location that is not based on the system default. If the system default is used, there is no need to specify this parameter. Please note that it is vitally important to end the path name with a slash, else module loads will fail. **Sample:** ``$ModDir /usr/rsyslog/libs/  # note the trailing slash!`` source/configuration/global/options/rsconf1_umask.rst0000664000175000017500000000107113223143453022146 0ustar rgerrger$UMASK ------ **Type:** global configuration parameter **Default:** **Description:** The $umask parameter allows to specify the rsyslogd processes' umask. If not specified, the system-provided default is used. The value given must always be a 4-digit octal number, with the initial digit being zero. If $umask is specified multiple times in the configuration file, results may be somewhat unpredictable. It is recommended to specify it only once. **Sample:** ``$umask 0000`` This sample removes all restrictions. [`rsyslog site `_\ ] source/configuration/global/options/rsconf1_abortonuncleanconfig.rst0000664000175000017500000000260113223143453025226 0ustar rgerrger`rsyslog.conf configuration parameter `_ $AbortOnUncleanConfig ---------------------- **Type:** global configuration parameter **Parameter Values:** boolean (on/off, yes/no) **Available since:** 5.3.1+ **Default:** off **Description:** This parameter permits to prevent rsyslog from running when the configuration file is not clean. "Not Clean" means there are errors or some other annoyances that rsyslgod reports on startup. This is a user-requested feature to have a strict startup mode. Note that with the current code base it is not always possible to differentiate between an real error and a warning-like condition. As such, the startup will also prevented if warnings are present. I consider this a good thing in being "strict", but I admit there also currently is no other way of doing it. **Caveats:** Note that the consequences of a failed rsyslogd startup can be much more serious than a startup with only partial configuration. For example, log data may be lost or systems that depend on the log server in question will not be able to send logs, what in the ultimate result could result in a system hang on those systems. Also, the local system may hang when the local log socket has become full and is not read. There exist many such scenarios. As such, it is strongly recommended not to turn on this parameter. [`rsyslog site `_\ ] source/configuration/global/options/rsconf1_mainmsgqueuesize.rst0000664000175000017500000000305413223143453024424 0ustar rgerrger$MainMsgQueueSize ----------------- **Type:** global configuration parameter **Default:** 50000 (v8.30.0) - may change **Description:** This allows to specify the maximum size of the message queue. This parameter is only available when rsyslogd has been compiled with multithreading support. In this mode, receiver and output modules are de-coupled via an in-memory queue. This queue buffers messages when the output modules are not capable to process them as fast as they are received. Once the queue size is exhausted, messages will be dropped. The slower the output (e.g. MySQL), the larger the queue should be. Buffer space for the actual queue entries is allocated on an as-needed basis. Please keep in mind that a very large queue may exhaust available system memory and swap space. Keep this in mind when configuring the max size. The actual size of a message depends largely on its content and the originator. As a rule of thumb, typically messages should not take up more then roughly 1k (this is the memory structure, not what you see in a network dump!). For typical linux messages, 512 bytes should be a good bet. Please also note that there is a minimal amount of memory taken for each queue entry, no matter if it is used or not. This is one pointer value, so on 32bit systems, it should typically be 4 bytes and on 64bit systems it should typically be 8 bytes. For example, the default queue size of 10,000 entries needs roughly 40k fixed overhead on a 32 bit system. **Sample:** ``$MainMsgQueueSize 100000 # 100,000 may be a value to handle burst traffic`` source/configuration/global/options/rsconf1_includeconfig.rst0000664000175000017500000000512413223143453023642 0ustar rgerrger$IncludeConfig -------------- **Type:** global configuration parameter **Default:** **Description:** This parameter allows to include other files into the main configuration file. As soon as an IncludeConfig parameter is found, the contents of the new file is processed. IncludeConfigs can be nested. Please note that from a logical point of view the files are merged. Thus, if the include modifies some parameters (e.g. $DynaFileChacheSize), these new parameters are in place for the "calling" configuration file when the include is completed. To avoid any side effects, do a $ResetConfigVariables after the $IncludeConfig. It may also be a good idea to do a $ResetConfigVariables right at the start of the include, so that the module knows exactly what it does. Of course, one might specifically NOT do this to inherit parameters from the main file. As always, use it as it best fits... Note: if multiple files are included, they are processed in ascending sort order of the file name. We use the "glob()" C library function for obtaining the sorted list. On most platforms, especially Linux, this means the the sort order is the same as for bash. If all regular files in the /etc/rsyslog.d directory are included, then files starting with "." are ignored - so you can use them to place comments into the dir (e.g. "/etc/rsyslog.d/.mycomment" will be ignored). `Michael Biebl had the idea to this functionality `_. Let me quote him: Say you can add an option $IncludeConfig /etc/rsyslog.d/ (which probably would make a good default) to /etc/rsyslog.conf, which would then merge and include all \*.conf files in /etc/rsyslog.d/. This way, a distribution can modify its packages easily to drop a simple config file into this directory upon installation. As an example, the network-manager package could install a simple config file /etc/rsyslog.d/network-manager.conf which would contain. :programname, contains, "NetworkManager" -/var/log/NetworkManager.log Upon uninstallation, the file could be easily removed again. This approach would be much cleaner and less error prone, than having to munge around with the /etc/rsyslog.conf file directly. **Sample:** ``$IncludeConfig /etc/some-included-file.conf`` Directories can also be included. To do so, the name must end on a slash: ``$IncludeConfig /etc/rsyslog.d/`` **And finally, only specific files matching a wildcard my be included from a directory:** ``$IncludeConfig /etc/rsyslog.d/*.conf`` source/configuration/global/options/rsyslog_confgraph_complex.png0000664000175000017500000042754412704114446024653 0ustar rgerrgerPNG  IHDRPmbKGD pHYsHHFk> vpAgP XUIDATxw\?v#U(6cwa%MLb4-cbGbWPQ"* ݹr9$ꪼx2goJ'BQb @!o!3g~`~Fjjj |[lAVfEEE tu\qPubՉU'깡 Q)!ě=9{rd8PCavu֕ZW@rWdiF4CL1 bJĔ)_|}}1c-J:)BNg3љaW]A}=hjj A ^#FxC\p ]`v0#aF ;^}k`d&C%!īWԅf1bA`ց&Ǟ?:ܿs0C!eqp1bdȘ1+cWWW P:(`z]hf̬]vPԽ{QwPpBlnnӂ&Mv`Ȁ! _WL3CoxIB2YͲe5}M7N,>b;s+er(^4h:~orYl#UUUxS ޛ7yo}BoJSCox_IBeEnEnEn21dbDck=""";v unԹQTA ^{ %%@߫} ߪ?z+{{JB+[;o 0H=H=H ^yY |9=sz{:h&U*sR/!kfeF/^ 6Om@oަMLי3]aaajN+{)R.rRIvٍ/ryPA333(((CcK?h#TʪU) l.\ 9s Ce=T?tyYf``߁}r.sss޺zjppp+ 3@}\}\}г URQzaO=TVN[A'> 898989@}}=wv\׻w]C̆ 1*UdrU\aÖÖ[o)SZ@@@P"%гPBBBZ:k57o\Xj`)hꦫAVVbbb hTШQp2 A,Yn#G2>>> |uYd@MK  = {E&M`{`jj z2 xPAp{m2Ayd摠=== q}1lp3ɹ3tt J,5LP)E^;w& \pڻk#`piPsU:6Hx#teK(6.6.6~wB'4zFmǾ}BеkAzQGMЧC}b1$ @):EQˢE-@xyݡߴ7`x&H'l7nֿZj}hC2ze i$ n{ppgBa?r_W.Mr6{o111m[m v?d 93888;8wp.TRJ*;;;WG]uula [F7n& n,hhhzVF %Xܔ)saϻ~3\8z腣ТA-V߭[}_'>aouց ]*t6l T*S ѣ/R% \T.*|lǠo!!!Cʫ ;wzË/־X ;w hy籰mo ttt3grd(5R!353534>Hc8\|p1xYxk-puu5!J8W\su`흷w>N}C >U;W(J7vv Uͫ  Fvvvv]cw (W\ra!W\o{!eX˰:`uJJJ 'X2Cφx4_!^O?Y*׬\rMgPA}h\Ѹq;jVg;vL1ƤBBBFFF wG!|b0:`t9ԞSuoކLkk^׼ggg_ |v{ ZVUCW:TS}4lb2b2b2 |`/_C+8444 *-*-* Zj9,P憞 (A455xB&0.^xEztѭGai㧍VoX4& <⣊49hrdx 3h0555־CVUe?-iYKa[muՅ{94bV+V<ڥKkX~o@AA2&m5jS d DIDIrqVLVLV qV z|q86؄cL[xf9rb 左5z뭯=`7 m6SB5׼͌53A)Rn1J/x Co0! \~g֝Ywfށ{wM5}L1Ƅi.CYi=CCCnwxf㙍 U8 MM*yʠRໂ @au~a/^Atqtqt1(oYx{{k^z뵇*U :xHBVz= ;C)lyAPԷoQ_COB{{;/op`(7 P|%г#URWH!v[mmDω= :)jyst_}aaaP\\ /ӏ׏׏Gtx ݵ \zplz۾].N6ACC ,<T!or+++tpi;Wi\q`W<V[ &L s\Kt- llF)nE"5O?3<2#1.c\8X7jݨu`ѷG߆ )R6@G~ݟ?nݬ|#0f6lTSN;wNyx!gggIn'neRߗR1bJE???<y:4ȼy#o[߶ 3Kg!<κu; {.]:t<}=zupo½DO=C(V֭ԩ]vlJ)ͦzo߆aV<}<}<}{㞡gWO ⭡I$jALL ԱXu,TY,0+Roԃq3f wYePG#h `jj fffÓO:@q|q|q>>`U*ԥեեAOO-0Z2o=zڴjӪ m?l??$x&x&xzR!۲eotH-orvE:u CU@Y,SA~!l|mطaB) R ʹʹYgՇ 7(V4hɯ_LT&*RNL9 'xr YYYA{Mc㏍?OzV"@!-h[N; m4#jͨ5 ,oY޲џ~xۍm7݀ *p :n8ZkGztW\qnmMmj.s1__Km&s@;\\\x٦g J֕+ON:k>r_!ğRg3z2dIHx1k}[`kGUW\l;v 73g,X n=4 o0ЩĻF!PN+@#ꋫ/<{6l sΝ:w*J:t( ~!<+_۷7770000th|pEWO]kPײe]˗W7Q7Q7%T UOHB`t9ou<lȳ!`ܦMs0+aV/pO}wAHH[S6( ޣ{"""l8膣%K@]r]r]r!uN9p011S9͒ D ___/7>I<'?]bnn7oZ*lUK.m-xn]]vuU!⇈" al؄wOzZzZzld"`ʹʹ̈́ESM]4|}}AJJ  8*;,X&Y&Y&OOO+U*JP(S)@6dz2t!b: 8x`Ⴥ>G=7o _X~[ڃ! j;0aztмммMћ7AБ#AGQG57{yOi?Ka\a\a\jqť̶3΀m&M`PĠAP3fN B "6"6"mmm!-#-#-Yh>q_s/XxEM)RqÏ~T}U}UoSś%@$J+xkbr˽5i Zky`7nPȫW-wdޑy> 6ېnPz嫃nnn\i|ư[ʃ2 >dPwXaug jG;ATJQ <<͉}=(mڶiۦ`RդIUH% lwL2hwt`hh999p$Hȑ8`Znja(R(A }+uԽRp*T)H24e(wZlNЎ׎׎}yzn9:< z4i Vb@fpÕW#;<jש]v7o vpo*jjԪKKK Ǟ{~,4_|eNNN_%J~8ʼn/N|{Gwt,pBS9r ;;;7^Lr0h젱B+֯Fj2C IA&pnƹf;;+W8&M@nպU,g9-[r7n~ƃ@{L{L{ V{Zi5Z6h-ktѽFnvҷK_m^~~~~~>q~kͮ5@s΅ju|< u4R)@C͇q]uA[Pu:?LCq?@*mӦ5k6[%wR]VpVpV0߷}p uTQ0jl+(r.r.rb AAAο 7rrrA5  1ǪǪ`1Ưr4!"! ;!%! B@RBH BQIB!J )B!D $@!(!%! B@RBH BQIB!J )B!D $@!(!%!D  FÒ x u:H\>q=xaKYyYyYy1ecFH8&q kx3T?:B*wM5~CFJ QNFOӧj,Y`ee+mWڮF:z+x#.x︪\U*(g^μ9M7|_d}kZk5oUwBwlllk'N`? N*'x3Ֆ\4tixƳ߽nkk :duu5u5u5C͐#B_x|555|ڻkzC͒ xo@.]AZZT*S)Տ~5k:o!{{&1c$hj#t=L3N'a5B7000n=SHNNU*MP /SUU CUVZŵkׂ 8UTSe@SS5lINrLZ6i 7hޠ9g0)B7&@tҝKwB{5ռ@"$'~S /_"5ք[@/^b-ڨڨaaa0ְ[n&&/ɍ]֊Y+`N9III>|nJҫ\r}nnnC>MLLL(^޽;({=ʞװZhA3g; {7v(Q3gN7t: xeBrBrBr ^B =.`To.k L3N;u씡S!ߖ0kaBq#Xc}XѱcEC{fȥ#\2 e:x_IBmǦ~l:5k4jw!Cz4mh*i*i*i`Kw,ԨU/Kx"iqő0耣|...~^~^~^I'߻ot}#@{#N{:生S~4ݸvچsuu3g[iq⦆N'Rȟ" .\/@NU:{ ,z/c)\bp}!@_+._\˿Hz =n{6tO鑥G >w|܁w 1rkΕ#-o ]=pcǷS:tЭC7PTT̈́78zЩĻN ?y l}={Dp q q 1tW((( 22KPZ)VNJ+E ++ĻJ ?:yœAw;CvZhTޝ~w_|Jo4pVYP~PAGiT]%@^H} p>on`ݢEwC{/p_c7fXeYeYe:KNNN0ZkAHnHnH.D}M7N'5F x{黧PƸqchr&ԧWKץá:Z>h%TNZ9NF: n*7 LMM7y t\qA9s|xႇ 䑓GN}>JoPt){>8yɓ'SNp竂2X kccc_~ѥK׿_zW 4 lޖ-涘bn P_P_P- GgЋCM5hl46~$H Wh\W.^ Grd x{{CQEaCƆ /חu"D vځjQqFŰfњEkcFJo.]@Mٛ<C -.gޞy{&컻opu+]zOǾ}BhHhH{tMx!Eom ?hT^yo>i5jt~bbb 9׃+ή8^x1(SxTJV) >s3(\`3dɜ9g3-fZ###0l4h0L4h2{4 'O8cǜAIv)R:uuAӃM\\\7G[!ڶkۮmVXz RH)((@4Dn *l\TT 6l,+-WZí: n|F(jTԨ>U}УGorSL1K,[Ђ0SŝwZ p2d@)B?m۷mtV:+p2ŀWi4555333qkkkbXnu?Bڜ9k|3gB]Nw9 fZ`V-t(k5???:{wVz+y}f,xbh}' l3EcjP|}>zW_S_S_}>K b(((Le*Ca:u@LL TZVuOuOuOPf(3 8I$ ''';;;Le*SQ+VTY, 7}#G%O/y@垕{Vi**R(6xj)x݃|[4o2eR_N8/_d~SfN7o4r߀ONQEo8twAw{&5 p%@a}`pm!@\s *@ջWWҹt* 4doM J-Qy2ʘ1+ctm!G(*.bhMkZ[FmE& <1cccH)RзззHyW+@t:P|_"=OwCwCw- t;݁ԥ. uBP(w;)iJuɺdP*W{|(((nr'꾫cB]?~_xh'CBNg埕_[om ,*XXc'aOž54j(:׉NAƃN~w;8x] /\_Zj}54lXap=kؼo $3$3$L|2DpNtNtNcϏ=?*P|Z %K^{8{rɹ'Ǯz@CsJ[*mTMUMUo{D=`ǣv<~4`_þ}?x!-[ڷ'zyv0a٣Gez}kkkϺ?fA!TS`헶_Bx~SO-?v3fBYY;~Gkp6m. :갫ٞg{Aܽ{q@NNyxsss]qW!Ot>8!qBO~~ns;TGT?مم5kPWhܣ;;;ŻI _5jk&LL#w9n%0*kT֨,v>LMMALL ԏԏԏ@JJ TUURHPGQ?1bD/b$,MX}{kBY_d}iii`ΨQ;PPPxOcX/á> #GvԥKSBN29oWf_ ^{qŻM.BYYY. x2ɀ'fޚykAs͝%%%ՏDP)re.sOs^x宸 =Qg`3fpոj\5`҂I &A5Zh 555`dmdmdjѢ TTT@LL lܵ l@AeWaGsQE=AQ^߸ GPߨQ}#4ҴJ`׮]vz}yTQw- aaaMզjhTѨQ,V[X YgdN&M̛ gTTTSTNByR^5ske+V^l}Vȶ˶˶GA^~ytҽJ+惮TTySMPcTQ5F*U^߼;xృٮٮvaO_"@!KKKk  11W -Z:|u9r 뛯o~8ې:ub{1(cP H0N0N0BP,9sPGQW&9,rX0r˟w)v)v)TTT>!gz@*:Tt 87pjcVPh]h]h .V.V.Vxk_|%^Ix~'_tӡO⢊*.zΒ !Z; o%|Yh 4838.>>>nY1`^1ycFh@S):xW)!ԫC:@MM \l{哖OZBVBVBVދz7ӛ =+o^ȱc!$"$"$k!#;@;t[cnMٛ7q9s\?O`W_:::CʛK%amc&tj Vqjt]% /'?Imh:u6qG~6!!!ư>|}pXkQE11ܱ$ B,[Xl~'NCЧ/_b?C{¶ok tkӭ!׍n5ŸŸ{ s鉧'nnntas͆N%R3 'VZ=hetᄂI?K/ݿ4XjcB /_5j<4? [(X_koTG{.]~_}%h~F os~t ->w\;ʄ_""D(EEE/.c>r}zw;vzPr\%Q;v@⇉&~9s&L{lA7 F}gX.\hdɢ={{Pҕt%%KܮsD'F'F'Kݗ/!Yg AdxRI'e ** XRzoMь֌֌uf֙,Gvq$l)Z j,:Yt7v_Ͽc8k^ڷ0tCw@u.ֹqdɾ1C 888 f9f~x妗^n:I$PTRQ%q9r),SXK.;8q0 ;຃PC:R7K,}Yg9k꯰|˗ F V'NX^x 4hzF PVVU }J.]ÅM6]7_|qT?TPCpʑ+G++uuuOnÎQ;FuC3cccT\r`>|8W^z!FJ5kAHHpG h_Zi%=[lٳ`V`V`V>Y໧=)PZԂ,3Yf*p?L3`kk =z0k׬zzzxУGdE@/_VPP}}}}}}<ϡ ̃̓̓_^mWC"$7GM4(mJorٟ*T<)(DDD{58j0lꆪb‹ /&KKK0Y#0LzS=XN`9TTT &@QrhѢQrvw;P\\\ЎЎЎ&M|{z.]ArPW"AuBuBuw (tjjj/$&1 0;NP(C!/WcooUW\e0?>]tS5k駁jjj*9M (1Fe#p܅ H>8}0$vJ >J(#km?o9oȾ!b>}}ӧΟ5.k\8x>C槛nI˓)S c]ƺuÚk*<'<:u: 7ݬvAYg9rt]UwUU7 nI{$888cH6%m ws(* D!^6.ڸ$]IW_=~5999i@3P3P3jz EEE.j]:(ࣂ)))*̯0|PmQmQmًg/k¯#z8{8{8C]]Č3>p066vz x*6|j)D4h 媗^O> Gr?ϐcw_u|S2z/7E ذz !uYe0#zFhC0("@AA%! B@RBH BQIB!J )B!D $@Qr-L01t! K ⽣ +WfD(]0`6|UUWPIʃiEӊ:o<Xyxፇ7`搙Cf].FmcƶEeee F3liNsCo!{ZVH^:y5W|^1W\Źs? B^r @qssNQ:Eg9? m m -T0`RA %!{ݶvm\\[㟍6ҢK 0ZnhS f)!{N:uԅŵkINrwWW=5HkfBYr@޲ʳʳʃC:7'M> +:oBZjq!(沛!uqcccbU)x!^RIJ;? &7ly`;TQR.?,ۏA Phkk$I@VFRu:,_X|ppW8P8%QVV97rn@kk+Ly8ᔇ4iH MhE@!޾z*|vO=i|.\FFe[Tn*7xyM!..j5h^ U5T5T5@kp)R`p)l7vfGmvHB}89vkwW"ssЧE}Z#G )Oy }l2 )~c/^np0qGiƧ TY,C @񗝉?&~924eh tqgǝ:ֱ)ezBk+.2~QEǺukPg3R$G5D1QLXcp݇[7tǝwy;,ﰼt^{lM&)ŻJ ?RF(#v$Hڑ'O&MB:+Md6$cIƒ h~G,YECO)s\ytѝGan0zSAMv7yWtUT=S |29́U!BVϷm(X0`SwBA!(*(*( d> SO=<0xyyʽ I'$rIHcG=bbb R!QѣG)gSΦ'x̚{ WΟ;/WGBei177*ԯRljԶ w߹>___TlY+q8(((}/}/}/ <@IQRP|G=>Z}>T }>@e #:PV(+___ƿnѫD+J4GGG~~~rNR&)@9PNrE\RS P@***(wr7r P|݋wsSN9Q_E}0aJ,=Hp2eV[n0c#Usss֜[sn"""h}}u\q]G-[: 1xy77ӿC7o k&J2˔/S zwhC#@QC~I%dx|Ǘ`Zi-֋s\(uROS>xQEŧZ|7mo޴JC* 4LϚ5= /TP$I8pҾI&0drwekjN9D]ϻ\ta҅IC/HHHS2Oecޏ444Ngeee-<;UW_;wllPcŎ;B5:=hii55kj4 5 5 &[MlvFہ",`/ "J)BB %ڛ7kof*UN8:t5t5t5^ rZ9 &LΙssshPA堍_6~/߯٥٥zKwA `/S9VEt۴nӺ ܩ} c2v \hvمfC~W;/o3`1 /+%X VA S”K_;Xb%Nos솋K/.wd~mUmUm7C!c^o;̰a;&-MZ={!K,f6 U@+3WfNf5kv^;;;,,,!9 9 9^NTRJ666 \+ZkkQdEtֹ[nn]wtnݐJT% sj̩9sxPAe!##r,YEZ5GrVL[:t:o7|Χph̡1O; uԽRS Ck(*<#~?OaUUWՇy:_/n_> |G;tI<'Y~B#G.Ǿ}DDDXδi9)ş)[ط/F4L1r#jV0tJ X`郥O,>n&z6 R&S~NCDZDZDt0*ͫ4<|SM7ŠQGn3f lφNYr<,*좲ma9_=r@?+h_о=ln޼yM:u+T P))]Iw$݁%Kҗͯ6 GN9y$j\qWfQIBe %@ Pb.Va3fAՇWn#|>^rzipqwqwq j8jq⨡S!V|T)vn۹mW_^3fx"E U.*x8qL;v2tJ xeawvwv0SN^; hͣ5fK-iu FYLt5j}%@)M&J8r lߘ1ԏVX}b (J7(\rAV (}>78^ϪU?CNٜ9ekn~P>C}@[E[E[ ̋(Ѥ!^Bi!!!BhРy9ԞjO'\|9r>}RۥK]K]K]70!e)KY777!Cʇ@kmFZC"@Qbl,XRzN 388㠡S ar!DVV+p 7t! K BQIB!J )B!D $@!(!%! B@RBH BQIB!J )B!D $@!(!%!xC}}}沛n.K+/tY,]0 &J(J  }!@!ސܐܐ\صx]!vtpӛ|%@Zi!j0¤ *!<b )BC BjBӅ aԁSN;w@uz kׂ*߫|333 66SSS!IX&T22t!xS333V[o i.;Nȍˍˍfj ,Xlp-[ȋɋɋ\@5׼(u:㦤BA=Q=Q=>}` &eLʘUgUgUgwwwY GGG88>o-L91Ĕ+ǟzl>;!rjȩx<-[s3f̀9s"ï~+MMM7!DQJTq~W+Pu[á> ?l>\b:.bhk_[ kUUz>lå: NNNۗn_Bʼn'V;&MjXc O>0Lo?~@I$zgM УGdEpCd xottt@kڼ|0a 볬ϲ>/_JO/څtI $w33qWvq hE+ZAq5}@5Z5Z5+++X"zgMB]h &@YRwb)ЈF4kkk0mv6?Np x/999aPzߊ .)Mi@:b?s>E5j\M2e!44_ `u:B^ d̘1 - QQQP%JfLpýH#5Ԁͻ6\[sm5֏~Ζ;[,xyyOf? yf͂G6lـ=z'7F!rFK7j/L4J`R[!%%%%%www_~WU|!isPUUݬYwttt`C7/,,II&S-[ڷe Aƌ3a`dndndf|-Xݱcű͋͋!qG`ii N7n8݀-[ҷ@[xH`ʦM+ۓ'od 5={J 3^o!DaՆUVAag<6t*! C.BSBHB!J")B!D $@!(!%! B@R//@ygϦP6F!?ڗ׾%l> گ*4l ̵ZsC\IIIp7n1ws!5=5=56h`#h2e>h"5HCo)B`\]>|s8s8)SΧtv,Zlk)S0e< [7lݰuxFQ~DyijԦӊ!J[2o: '̇3'f,Y RUcƏuy_Ìy3y N) M D W>|^yXUpU!_oa9r^9p !WB l`p{p oooe (~g~_w |]2~1G8\s z^y{ysq8etнKզW^ l^_lf͔)0wd_x;~{w~w•W_)&{][ l˅ eWG]uuԫKŗ/~붗WL3tiK'ohd,YVv] ˝;/wQY(mQ 7x`pZi!ޠ|^ @+﯄000hG>UXWVTDEmb5׈_!mTڨW V3P3P3j(QJ%NK@# zP/rIj?ujԩQJ?-W?UfWgϞ={Z o5phYزe!TW^zPaBOK}ZSLLLov[[[_}3gFygHڜ9i3\tNo\v D pdGC6 4h厖;Z__Q>F}@y@x2eO a6@֦MYԾSNRKA䘓cN&M›@G888oοquF:#WWW喗[^n __\seΕ)[SIIIʯ_ av:4thP8pm }ty -- bbbn/_D9yJJJPPPٙ3g'\H~!M= уE96sl@tZZjy%-8[p5}[K ԛ7SovoMG7t+Xq.??qqq8hI$Xcz5yn繝/l_ؾ0؞={{6|lǰh#t{MqucԎQ;F666rMyz0_a|39fr f{Yg!&&_x~y(=)XcU*kA{A{A{ALR&?8uXH ߍJ*ޠޠ:ۍm7B5oԼ6>6>6>`P}N/_b̽ͽͽڢj-v9r@LXLXL3fUͪ Iۓ'm_T~Qtuu6mCM5=m/^ӧNQ5]5]5c{ ^&@f!BYgiiiw-[6cǐ4i|=đgS)۔mE`C Vr^xx(5R!q`ϴi?1y 7#@٪lUn5I~ 4TN*'cP%P T?ml­C:ƴnL;piȥ(Ί J=R_r].Li8؏n-.[\M>mrPuTuTuAAW_;A 1{c{c{cPn+ېv4hQZgj+ | T7=pTYg+n6m rh ,LYsss!88'>O|$'!"5"5"I$5[[[,؎k;ڦkHܞ=q;ծW^ M 4~:ryȯ_% <|yhhh&`W8%*-[><q6?.~\ ;w[Kn-bn܊v-Z5uPA]G* U@eG &4hXZZTEz lllfOxNB7RnHMMMz;mӠқKo +lK[BS nNݜ۩۩ l.֛7CE} f']]]`0 `ժUWH[8m1EQPʣG) _Kw)ݥtHߜ9}3vc>㢸fwM *XP,(VD51Fb,1jw{ް A"{]6w߹r_I٨~/vS)U~Sv n7@@@+616161jjj /^^l{y#FiuYb?rrrY-Z`nnB+TSiN9LQ(S@RT*mcƶ YYYBƍ7@QiiiX?~f py_?+Jeog}; Z5kլU3حc}JiR t}t}t}`Ó O6wRcԀlll8Nqcq8Gřřř1-cZ4H($M RVJkkkVk[-ԟUVYP^{}s`Tm#+kXְ!`FpjCc!'5'5'mb&ŷZ| U|T```[o[o[)mM6l0 ,E?E?E?V ,, f6AW_W_WtuuA;O;O;uuuLY,SB__]2e 6lܩSsBŅA(zV<7yn\;慨,YǯI$PH$]t@t@t0 7@ӰaM@}Z}Z}Ǘ/bbbT@eee= U#FTjՊvvv/ ;NrF6W+a0D0A.T-߂bbb)B _P~Aqqqyfphڡ5dG`8pT@D_zғ;wt@"6I'yeCnMӦi@m6RUqXH@@۠b_].F2q A,T*\!W)d YũC_41ibn}DHD"N(P8nu@/VZNh9%(&*&*&;wݝvw8iXmإ٥٥;DHkH$VUkհu֙[gA&M`tF7{sx_}AjQ~N%5R H6^vzD^{ц6|L?6c}{ur[j`+y0!$JlJ$?G H^#GaiևOzS)'v`y}Qj0yTgomH Deddo[;w-[@^pJ8;wpppxɦ'N"c@"i...m׶]vs?~W^uz>3>wׯz]w-[Áq@QQQ$TH$?¢ .,b> aaaN5^!A,Y3}HoR H}a{Z k1899_ftqpV[ALV&/+MD_w;v|88ܚskJ"R H~#Gtbϋ=/@Icc'O@9N DW??????p0apI$)?lÕFW]i%%%/"@suGGiܦq}j)I>|&Yߩr)'@e_~p+VXx8qKoH&d(G9 1q PBο@";&QM@ ]7t74#O?Y‘#EG@aK-}uA+a/Dm6Q QQQ!BzQ{F7߀K/==L{t/oҿXxRSS::,!>*>*> =wQy3SO<feʂ"fN*$ɯBlClClk?~PE[ d$#zI%?8qhHOOOOO\4ui ֞Z{*XԶmQj̩1H6J6J6ŧtT:*Δ;SL<<ͼ~|4iUN9(k_׾=7n<۫۫ \r Zgk#Gp`p r r v5jځ8&:&:&Bظqa@ZZb=qK-h} HOYYYYYnuVvځk!;;zXob=GW]n׿]v}0c6lhGhGhG;60l`׵׵A-D "3e֗'O"G=Oҟ?Ij0-3-3-UUUUUUgYpLvLvL^vx j |/^ iKӖ-ף4hnoooQ(U l/^ + nnn!{r.\ȹ&MƛU ~m-[ӣO>= ~b h7i7i7Co444 ʎ/;|w|҆І6x$H;w$<d쓱ئMc$! -a ~ >6c}*T)d<a퉵'֞Ck;̆UUU h|4L(e2mmm >^zp ߗC!󀜌 ([0`.$$$Aʕ+)W`Ye=‹ /7h 6m.b\wyzR>J(#~W]3g?ޯ~g#FptљGgdlll}ްi'0p1p1pSO>uvzwk(T2d|R B"B"B" TStV:+awW܅;w  b-("ՓՓKKK0C!>4>4>MozAB*d mpAAAMMM'?>~p᠋`ͩ5֜'=G V/X`5ĝ;w➒PPP8{0`._?G: H23d&4 l0̿7{iA`>|ɫTSMppQGK.=!!!`.7a0T*". c1g?|+V-hkּ9æ:lw?3 Z|A9 4q.-\Zf'N. wp}Â; ,]kwݵ6ƫ̰lԦMSүJ*E[F kn ]>Ay[вVZ-kA%[`3a8puu*t n:8pd2[-0LׂM)GB展V UnWQkG`æM8_B땭W^ {EF8~xU*]$uI///}kHg$wXY!>>ZmѶEۗ`@08!---y<@J/^!L@"sT|w'jРAdA vhт^\/ӜPZZ [>}@|@|@|rcˍ J+ BdtY:2LMMM`9rdg3=V-Z<ރz= 68!Wر?KYҊ1ncÔÔ@e`/ {!{!{ $$F//wO'Q9r@89ኗG͇-:8yA7H7H7b?/O >5M7^QrʻB*$wXCC5k^j̨1ƌX}C }PܠAqPTT'X\,.\h6(C hK[c=IOSL:ttMhB>˙ojSڠ|q8,"zꥪ`>0SOzMF#F_Tn*7<y80-6(lPvݹw^WۯԫW^z~AɆ'ln ĚŚŚU E_t"GECOj|RhђFKģN1SM8 @Éa]Ww]>0o@ٴigASAlتUOO!6)6)6 B%+OQ$Hؑ >*#>}>Ql>}(?q\-Zr5Q,..E555QLT)(&&$&$&b1cDQ]_]_]__}+|<Ţo)ttt_\|qQ{)?   Q|6gCEŇ/>|(uY=+{V&)7SnElllQ|]E1{v٢.GǏ#Gb{D1ӘOc>Ŝ$QV[bE1==]KRTŔ)S⳼gyDԫԫԫ"omm(f|eƗۮۮ{HD ) ) )ŏe>oߗ>}R{Ql"E( S~CׇyݚwK5cqkǭ'}}(?H߽H$wУ:<Kj.߾nݲ0x5׀hFAw[w[w[߽x{ҳK.=zux8XT﻾:%uJEwWJ@A$˵/" mi&///w:Ζ;[V_( G}3;$qǠ2OMMMUqV*[z pV=:ܣ3Ͻ?^ߩ$o H!Wkւ;6W%KvӦ6|mY۲]-ZtM<4DؿzAFFF_Avp7QQQ}@"yD>}½½zԣ?#FB\ոqU0ְa["""ϻGGqth{j{j{kT_ :'@{{;܍sU& 0!/@{=:J*$w@Az /ssnκκW=z\uȘ1'c,=Xz dDDD1{b쁲ef>;w@vKvKv m6a}[mѷ}-Z5cPڿiz;4t|bbA?OMTek֖sϹ>Yw#h0ԵkQ,,,tӍO7fA}ozqτ5kU9rHա?JW뫷T_^}y!zGФZjM3n"=xcuyyyI_&}!CJV%˂/ ;ؿccc[z=b҄4! ( 6ڐkC`nnF^ ڳڳڳ/`nnnnn㧏>~:yɚ0SBĦM@Ɂr(P!8z詣̅3\RRR{=]`ށ~2+dVȬ׿]H0Ub} 7MI#F`gFPB %/7  PTT)'SNŎ;^{JG+tŒŒ|%-ۥۥI%6ژ_(PpA \E"T 747474p3nn4i7 nR;?'l6 AgBkM6/yU*nad`nN6n75 ^EEEp?- Z(M?7ul ,@l(6Dl"6ņF7/ TjXJ)R{b(a0  c14inڷok-,[XQGu |R ŲgOϞ1cǰ>vvv$oMޚ2?8cH2K2K2[-V0x=wH] uA"1驐JQ g| ;wS`4+lVج=~]hrɡ&jzKKKދ#[3g,X•W_9]?yPYYYmP/^zt(t,t,t[InU,XDN@^Q^Q^4 iR R R P, E].III*_|2hii{6ټjR awL P"y 6vqrIXmˡZZZ C>8:uF>F>F{;w>|9s/_lvďŏŏɴ'ӞLi-ZBmUUŹŹP͸q5ce]˺5eee?(Y, 員a`I% Mox\q1OOOuuu1+ 0\bpG%[_N";_i B+;R:tP 7o=`ۃv۽5$C P"y%|uwoK_o'}LAmm-9s %ɛA*$*^ M&CUTmSSI^7+WgY|ǟ~SI@"y AA͂5>>>Uߩ$aaa:fߛpĹN@NNNNNIm@"y e=tFFz7!~C666ΤI;THB   `9r\ܬrJO105050}Ō3 㓌O2>w:ɿTH$o )R6C{Ah} j0 pvvSCO =5Tߩ$R 2b2b2b]ޞd`e`e`߿?\2)eR$}TH$oM&[ O3f>Mn3gWN|}_WRRRWo@SSSߩ%4D)Ur,YxZSIMNN9s -h)b/쾰-[v.̽0\D%*;䵑 -RҿIru`c}蛺qZ OO?=4߼Pn^n^nnN)#RF@J"^H$HQxQxQ8~vvvN%ї+fr C† SN;(?PjAuuK^7 Dɉ͉͉N&L:SI888\>t}b7 xCy DDDc}n-4iSt% |fgVPkQE;uކCƒ  99n'N )S*TIIIאא-]]](xxxEC AQc%JEs`s0jjԨ)d0T U@5Q @;wP~CɃ%888J\+W7rfffP`Z`Z` պպՠP)T 8p8nr79x5]]]<<<f 3ڿTH$otttwk殙`ᜅs;UijjBRpRpR0<h>.|\8H~/Ȓeɲdp9ɩOA`gg-7r#4m4l l l @^]^]^Nu7{O<Ϯ r/^ν a7n݀k̯޶޶޶УA=FADDD߽Hg$7H-[l`3\sε; JC,,,C,hՂVAE/^<#GnPw`݁uBnA݂КCk] w;KU*TBL3`F^{}c  j4@ߩ_TH$o999r_w~uA|,>â?N]8u#qGA&1MbSRRN%J',OXByuՙ 7Jn*^X/wwX#p}KtNW^{ f.;'n%B޸qy~Nݝ;z MכJ_,~2DȘ1%c 9Mj4$wZLjc1aaa6ymӻwM$&1 ꖪ[fH@jr^lz+**BLJv|(}Ӟ={ .x!M1b6]oW!C~/7Y,l>+}V ëoL1ՋTH$o*5ԬRMo7tMMMxafnp;#&&VŬY>W|\O~2P]v;囧(((@iU/"EV` ʷo+_X6pe!crN*$7X{m?0;`6T_P}ANށ]vt׬^zMx_}%}b'?ikͿ6ڲj*(SZΫ=f5j3gτ?Di~7ro={|!{e-[roھi&;tw(D>|>n1~#晛gn !] E E E tvAgn5j eNz}UR jݷv_}~k>}xp0kf̬S߉YYY0ۑߎ < < }@]S]S]l'<*xDEDEDENkK !}D>>~ N%''S7O<<1 t6@S`ii a3f̈́ot&.++ G 1x#^*H`&ṀQMFMW6]w#FNi4ApnܹqAqQ]˖-/Cby/潘 ?g%JA1סrQŬY- gtܽr`QdQdQ̯_{2d‹ /.WW^]y>} ƳgςuG`tvx"Erx7oyNININIо^z끋'lj{*quuug՟UV.paz~k{SѧOECvnvnv?s\M3>:(H $ N)~aK-={0[-4gIII"~gwK~@~@~ttt@SݧGȑxH<$q-6Z ֵk[׆|[lg`.vaRfa~P= (C;Zh;K9#?#?vvvPA !(-(-( sEK-Ep\yD':lׂS+h3 1H!@ Bg A|A5oSL1a0U &&&0*ë(((ڀ`(hB % uwv ]G|G@ jP0s033 .@Cя~`ְaۗe-Z\\\ꔪSN6 S@"'eEASVܭ[qWWWw ށ:fuc ;wJ+VcnrP١5zY`llN,'XN=f{̆;K7no7wix!yyyy{!pf.]d;u u ucBQFQFQɩS/$_Hy $$$GHNN0H.S]R+VJ-`tU*={:4? &L,Gsx\0<<r{K.ףG]"1Wsy癐{8paxۀe,cd8q4W4W4W %(%(%/g_ξ̯SZob5Hk'Fqb 3]~&;[lz.\ꁃߒH^d$(Qp;Gw !'BN6 };vơCBM5]}skBׄ]wu_]|uU0I1I1yd$SfO໔RKAX.c|{ׇ'~@wLwLw > > P-ZB5(^ܽ;6m,--éqo“'O u@-[HHHWP*Be~H&j !! F5`(++Ó:O<RyzuVV?`%0kC߇}TH$ Ox4iS⫋aØ1 |%|%| "D4*UHϑ#x5 1:.t\sUuW022 ;vYkg-Wg^y*uԽRw}.ϋ?[^O㯌2 k'UI$?A-wCk;Np-'(Wدxxxuc֍Y^z w-^> 2+e@uԅiCӆ²ei`ʇS>!X'Y'Y';R0`hPXpu AkZAC ,a0K)DSL1 94?;l0<9tb [@ɠA'_uMc) {=&M> ,,,a'ӟL2ğğğV-a K .7.7.k{кiݴn0y䉓'eM˚5.H$vvv+$''ÕW^\yw~;B7;0zwPjA_ЍC7®ջVZ -N\\f_S>|J gKKKKv.òeKi9rJ~Oҽ{ DŽc.h]к.d0M4M4Mw?N y'½{y/$$$/p3s3s3VU]ϻw=xdP)~~~ /A(v߀vF+V%CKO3f>`W]wՇ;o켱zG -hE/1cNR+˕pG{G{G G+>+&zM-Z޻wpAKK㼭įůůhf̢mmm 7pcD1 [5j K.Š_x[HVUUB^_8RWN] o\1tlױ]vP`̓5 /C31bc,k`f;*R~ $.K\ BBB iP~Np=zQoDPy5r.d)Xjo-..dddKk(V>VBg{h817qoݩO*$o_V_o|gƟFhuTQXcMǛ7&&&%,ٵdג]`6l[pR?N,; gφʑ#+Cd ZFj ''j9֮][{{{eee]6lvL L L @){z޿J7O7O7J_/w,X-(ZYg xxx3x!Ҿ[hn!SO>{S͟jޫ# `9s.B[tK888t)R-<3g>OyRnӎҎҎbMX7$ncBBqBqB1XbPZPZPZbMXkkkjbPsΕ;UV v4 &LnCP`0`,qM&TkTkTk@i4UBiӠD[-BGG;w -h/k/k/WU0`2d899[[[0[o;PV[oe?~@BBſI(%P/b ?.n,2b7n {44hhLMMow'G,bKR8Q;"&&VXaԧ>?OMnrʋˋˋxTQPԺuQk( Q'NFȨQ?>*}GQԂZPkA%?`F;FwkMe*SH# $LgaEW]f\!C^^*85Wc8|{H)Y)Y)Ypֱ[nJw*ݩ'՞T{|EYYY 律 +ŠeT2D8K`+عb"$zЃ+ߤ@Z'7?!xzzN? ȥ}cN:ZֲVߡ$* ǃR)uޞ cӘiiipzaAȊ!+{G־[.ȍrc} J*WWWFl#w(ɻ ɻ4#rkւN:y.t pmܵ9L7{ާO{wPevvv'ЉNtf0'yXܶmqRLI4#?888.TPB%8p*T§?=A={:4iP8;O<O4w\n.YYYYYY}B*$˷---xhࡁ [ [ [#"GDfכ]ov ;v4版/)yyy:(/*/*/4bI~%h&fv'N05^#{`jbjbjt#2/wc %yW為hghghg6}B*$SOpͽ7\ ?+e2kc=2 < A,2} 40hۺۺ۠iiiTM*QJǕsC 97?Xq:|J/r_DWM&h|TP;]cg9hninin; wDl"6G)R]Ż~Y0i8'hrɑ&G@.O; Մj@;=qSIU] vZЂ=== |G|t_@zeTY*Xv]umae핵Wk| &|k5ռ . Al+;](V+ABB*J+בe $IؓՖV[Zm)̍77e,cSK^pD8"m=m=m=*bbb[-\\\w*&o'yq'aǥv\V[Cn mצ0aPA j;"/ @/ƃ[' #DFGRJI~!R7V7V7 /þFk>>>N ;}}}*P*Twj"L& AqӸ2d򨒿&H"AtD7DAD 3GW8H$M&YTbPP1/ +J)rZ%JjXc;#0fܘqc䝓wN eeeH_Y@V2i4qS q\z+:Ó3O<9SRŇA9C9C9!00P߽8ڏk?wߧjjjϭ[=CR{p3mɘ1%c %$%$%ttt*^8ḇ`*U.pmoӞממUW=_fyxa0cZ0k,hyAEEEߩ%4 L444꟣٨٨b$}nNݜ~~߫=G#"kE֊,M M MeXY /j=lk/\YY 2q{hhh tV:+Tn*7:b눭#`aq8Qp #ˏ@ҥKxH!w_puu67mn~KTs`57܄;ޯ~k)Scۏmŕ!dBC!Zh- tݨ4Кִ" XR[˅ArĮbW+;⎗>*>>>c>~iMB A<%O8G#)\Rq $T|nj /M4|ɗINr&׬#YG@?=fÔSLYMn5TY[em`W`W`WpU* ;v,[m}d5 _xP<"q_uQld#C 1p3\Go)T B .e]e]eݿqadq8O 'H$D`"@LL D,hGhhh(((D4M&DAT,Dq}||sϭ>f.B¹s!11<'zN5Z?^&$9<~d6>`+`/''' rZoTX*,ARy⹋. 111|y(]Yt% m0XXX֟[n=_o`|)%K$?|Ðr#F P?V?V? &B㳍6> k=*KJprre2HC͆ 5- 9rtWtWtWjdȮ ߵwfݚuk(1*1*1]Mv5tgugugAQ(T#a `gegeg;Gs$ִִ@S,;Pv^}{ՐP?~B}8}"D4ѶѶo[| `<tOuOuO!,, 6~C{7.xiqE:MO6=$p=zE\ kE׊].T Ʒn<WWWO7n>ݠ}Rx%KJxv״״b݋u/օؘؘXh7awwoMa}CэF7 ԡu\)Rv {w]7oԟ[nή:GGGt2dɤ"X|,>=z-ǶЇG'N]QV]iti׷3zjjj {O=,kѲFvwmwÌof|3pIC[{F1Q`nenen...PSSC[m9%d2U*؛7{o6V\[}:RRRrʥ+ 8"8"8'On t?444?(Vz/_2fH۔)mAyy9>SdzMC@ǀaݲu-3#Gďs9rA M&4={>J#*4w 5oԼDDD.@ a0ES LjԪVM4`(W)W)Wk{潚j M\7qD}>0vaBFJx'`c===`nnʡʡʡnxaKw/n36z=Hscύ=7 <*<*< D;NK/}뺯>0fvٲg˞t|@&t;$&'&'&Cɺu%4A MxyyG{ѻGAVVZ6lh Nv;~I*$#:#:#-)[R78~8|E0`рE=FҌnBCC)y ȳl0kx.XDYDYDA㵎:}#FyGyGyG0?c~ xyyAkׯ >*U8}etL]&"TVmZi`kkkkkj̨Q3PWWOL?1urrr|4hR"E@RD f tldzv@oo/Cnnn{JFscǮarPգGU~{ᷡܦsQ  ZV_'g}rOOO%%%V Vͭ[5u:B F+V 356k ;w ^^L501888!C \{9̒̒***܌܌܌~?|EEE ;,;,; FFFXXX Lۙ)=r}  B{>#PqI"dr\&ȑMvO*ާ2s̜_OUz9y^~!Gr@+羴<*e?Os`Pv]]]9e ƉqbC!MMMO>u{38***)Nq&`¯ar׾*tޱ{pkշVCȜ9!s__b߬+QJ/ô +@m< x'pMMMo:t _zkc} {=` ~i{/cxPrT%Kp_8ǩ8^E%g* @ %5(P]B7 7hobWŮ-<|=$ycLsG7x455CeJB>tSM;M%L @HRԊ˿/{ȟ??><-|Z=i\\\u:N-[hw~ iSӦMQ :xxxvvvRI')S~'xz_|FvAa,,,72nd -:ԢSlll(S)^sI>K>K> @e d1m? [fnP5j@Հ>VVVe2MuPPP(__|=b P|kV~\]] ׃J*ͪ4 \ v hTQFu / NNN(2"GYRYRYlx?[o 6nݨ;'''z{ur999H$ڷnߺ}k///wZɛN4:xⱋǠئئzJ***`̦M3迷{!>->-> Ʈj8E^-ZP ,! nO=tH,H,H,=z@ Lr=.O<T6* ؅؅؅@[3gXπj[mnv~1(((]JW{-XXXG>|fߙ}g B<lxL1lf̶ kf_C_C_CJWW^ ///SΧO>DZRT˩S!) ) )^z;³grsCPn)o)o)!-- ʋʋʋ@/Clnlnl.T[nP׽{]w`! Y!!!!!!`spݭhP*B;wﰿޞv#mp+Vx3#fQQQAM6i ,Kc A0aCN PL3@9s@|$>WWW TqPJKKʡm:ϫ֪j-,}(r:U)))D1ia¤N'y[Xc鏢8)uRTQ?D_rKo<'ωբZ;Qg?ϧ% b(:N)bg9,l2Quv]_zxAt`8R)KKK([-EQ^^^y([ŭVQOŧ/}>ULSEQNNN{)9|(迣,kYֲ?0b)8q8N璅(f/:qN`1X Eq8@ fqܿKR]TŋEK"(ϢN/mxI$&q\Re ' 9b(h+buX]8d1Ybq(bҸ-KDQLDQK\(+6SPP E׋]L1Y[$Hlrfb(Q(Qc1FR(1J)qK^3ᗿ+'r" .,Y4hKW~Õ%.+YWoyiY}aiԥPsU:a=|e˗A65lS!`き6U*C&M4iSq[?!jv?\s C WtI&m:u( z4x\<.e>A涛 ~~~O?QQQ߿}QQQH,峔@w@w@w:/u^ F{#y_}zzzm\۸EGEGEWn^m arɹNe8e8e8AAf'E*$].U ;wyÎ;~ITJp}K_|ϡ=4 h՛H]"vE@zrzrz2|.wyv%i&?H3T3T3Kݗ I'u/nt3D_ZҒW+A]K]K]՛H^rAc1ј$z%=_Ty<ض|muF0kݳvC7ߓ[sq8Eh>|Lߡ$:"""wSQQGmxntF'PGQ]1R#!eRʤIpqšB~sR;˔˔`̍37΄K/uZN)Zagop^^^ V%o 6a-7<@ :u7ݿMw(ѕJt˾k{i{i{O,>wIRQQ߹| f [3fnXS 3gB/jQ }ʛ˸̸̸ _ k\/A8#@ = RKps?***!x{pŮʢE+%Kp={077Cm>3_'C-;\p8i4rɝ;vرcȼe2o(苢/`~7n]g_}}ߤ~M;wBuG*QGn݆ u/^\\\ //E߃6l؀e&AW_W_WN;i$0{n9잴{I^7nz]os>deeJh%3 gJG* yyy0ٴfӚm=R"cty:h|y,[l L3 @]v fffPlaBWmö 6;9wr! V+ rkέ pH8p L3y9`qiI'ףWfXӰaMMMM xèQ%JZZjiPkջ‹e/XDE"q)gSΦNS`o=5kl>%UK@qIqIq nSM~۽E8bOŞħ8qFckJ)@PPm=Vp8q BNrԎS;N#8> `-f``jgb}kݺvd?T:j먭={O'|:{߻ :N+N+N+ ` 42bkq8L?f^|g a =3zf6Sm@UjWɟc`e`e`/_ a0}>aK?o+B%J,Y`Y XbA^^t& a b!33RVLY Gݎu)SCq>}= o>í[ BP*U?6uuSW(P:t΂ BP,#V+mr[4ӰNX±c e"3(gABBP+JF #}9rek81K9r  <2:etbmX L`@*T6l>T'U'U'A__bĬY^ݽ{<%/Zb!hkhkhkNO;=pl䱑FB%+J*tl"l"l"Ld"ЍntTPy U*P7%nJpszt鯼D/ry9hviviv;+0s~/즐BK?e_Ve_V[k@Tndidid иZj'>6<#xF*}7M_,Z ‡?a{A)fOx"@{ソ~8 o;a0u݄nB7z ^ `t=0r7r7rcA㍍76A)_MjW f0#_/bbb }վjߗEЛ2eˠFkԆn,.Y\=?QϏ@HH4-4-4-'Nj 6wОҞҞ]w5bZƴi }nI%o8sssPTTwμy;vp%Jxf5@KA}V}V}  4QQQ#GtHPQQQqXf¡|i(Q#P|^=0a6Cߣ2 N,; f7nϮ]=9u7n---鹧瞞Beϡxg❰yAuu5x}w`QɢE%` jGd!Y^WzhN}-lH!͆@QQz?3.sg KTX#F{=kb/%KF=E,XT^Cs9'e3߹fa;s L˙3-PE_@n@n@nWWWASr(Q@ccދiiiPx|y(++HP$(PxhQ033^^^yǡȿȿ.n6H8p,̿rrryW82#Cb03jf(p2eCJ$ǭv Zc>WXѱcŲ?w??r#tҕJW222\s;>#kkk%xX 구ײ^K1cCOOXll,{[ʸq):t̆ 1]˻wn6 69mrVQVQVQMצkK/XXXZkZ1cfUC_u_u_55kv?`ppB=wwCwCwC0[o#G{"D 044<<<'ezT[nźPYY 666{:`K>XŇIvjjj 7ro< = = AT.{D$Iޓ<( * * r.\ʹ{5jkoe.\8\ \ \ V-u[deeszCu1dPɠ!=S}HތY6g du}1cvL1c +W7TTTW!Wm^yU!vFکx {F퍂G]Uutɛamm ))`ߛQ(w-{ B#4Bw#F 0nTݨ:,Y xCU]3agNf7ӿ= BKK bRcRcR^tyEx1Ťm>`]ǺuTX*,xh@v[v[&zkd/'w/^]wu6\paCp9r尾I$oWܐ!qC{y xa0{ӟZ֨5` )R% 04>7,y;{݋v/ڽzM5dp2oڙD*8vq^ /›7 o۽\SK/?WN/y~fgP3fR$oAgYmWH! 7rO޼utt`O=P޷oy_h6لfN"/ΦM;C-Ff[_o}ukmڮ?Dg4i(<<<~*Ϫ< /y뇮M"6*cX$wC&^M7---e  ?(?(K/ / / {orRI-'9s+[{{{j]LnmbO5~vjK$}POQOQOp[v܀ҀҀ(xPw)RJJJSIN٣٣... kkkPZZ "D>=W+A5jZZZ U*u5 :c^J/Pw#I6(U8p-.Z\J\)%KtRRRc-EK"""um`?~txht 5[@FFTTTp4i`l`l`l+ W.qKn/q}1܌w3.pBP4R4R4w:Ոꢺźb]r!!!6mr[H K K a҇Af~f~f>'y:SLT:_| /}>|%n[@8ShP6d5IM)Oy ڲڲ`~yimڦ5k555\\\;```K G?(X2d \/^plCԕ+!mvِ*Uf+Pa3 >O<~_|000Rk)R NX:Ar#s2 d ;###qqqru.{9r.w]7MVCX UFV|||/»CmavWaZiT"yQDeeeccc-<icƤaeʆvBۅpQk`888|6Q'N`U*SSSA9W9W9 'N(EW]r 5,Hm$⢸Xm6JJJӠ䓒OJ>j%JA# $$}Y_x6}lXH#I?~&ЮЮRRR;;;<x4h-[>pAW["EL^!lYزeiiiP6ڠj...}9DUQUT>} @bz֊[+ngn}2b3b3b S+Lfkvjo60mjԴս@[W[W[[0o<9wsK͗/!V[r}PWW_S]S]Svo _|_| 8e2}}Cvt\g΂AÃANM:5#F0 7nK'N.@9J9J9J߭-[_1b'|z2,/X^ީ{hƋ}J`x }Or6m=\8uԅSp彖Z .kۯ:uăjjjOk5?j~|8䶓#G&PiM5@-ͷ4UݪUu@@@h)..Ė-[+W Zk hIA&`3fD}z#:3ά;.xzzmW(U* qu@A5/4_h!BZ PiSP FL`gf;sEs+ϭ v[mZj ,,,aܘqcƍou t }c7PkZiwA} <x.ɓ'Cr{UW[go|||5-[?dp>}lHܐ!? |da|>|X͍77CCCȨQ5*UVb\1|9GGGÖ[ovvvH6#m|~ӎ և>}@f:uAYYY:u+~t0hk[El[ b6'lN],v.]f o.rd921c/W\r0.l\ظ0\&p >2}d?lCXaEߞ~{n_Caʇ)¶۞o{;=v]SB-6&&&oC΀#83gπui[~ 1`X};|0`؀a6m΅ |T"}m!FK.]o?v؅c &xM1vcXyy啗?tmӦ#RGB-S2!o\qF!,YS#GC!b^ļy!]>q!ֻw_^N+ĪUɫ"BDN&ĵA]Tד nvf 4?h~|! 8x㝄iO~*DG~$Dkk_~wxwwzg{BF~; :t*Hn5X>|Ç iƦfM 7[o]u"xI%BtٽfBj!n0a.D]v*Dfvfvf_:~tө)))B>TSB֝֝ nnn*Dㅈvvv"]vv.BȾ}#[a\ | s!RRRi"M++BĮ]Z>3}f1}$w! Z!/ӾLR9[W_]; 3PIII}QYNYNYNBl9J?_3Ϝ?s^ we.s!..Ȣ>/LJg?VX?~d_vPRR~6tf:3$Jn MMM/KKK*Jl-Ȑ!~_/cj2Hߜ9}3DDD@RpRpR0u[?"D(7ܜrs@LL ###e`iiY6FDH ]]]PɩS%'ꆪ VЭ[P_~Aʑ#A@@f`1X ޿2 3<@8Fc@"w@VaVaV!$VHX<0Hٕ+ge X:ցKŗ/t8q`kk[5k_GC3Hh:u( /6sm{K .5jfXͰCI"/`Ye3+f”SO=-{Z|H.ac5jʖ*[@·9|t[m ''߁UmTg_<@__ wC `-#w#w#wp8q>tig0~Yg{lVuX2@ Z7GkH!h۬m 4"4"4?2eV((Q#>/eȾ}E-j+YJ~%/QC5fsj©t9 &MhG~4X8nqVUlҔ9K VJ[[3ߝ VVVAz E݅ wCQ.E]l5L$D())1JaIÒ;vmеӵӵ/EQEQEQ 5 |I%poBK%j(**T,KxJ)PVV/>d 6<(L}0pç3ϜF ;;;;_;YXX+b$&A\j\j\* ^2eh-[ڷ/*R֥KVVVT7n|||L3p$HP߲~-RiJQj%}QGp:tp6lT(t.t.tw`ddnSܦMvFh&f41ibDxŢ E^-Zz5Ș1?c>$?J~&M[Y2//T-U-U-!vVpz-xX<<<9|&Λp×_ .ݻtᅩ?~`ޤyMWD{m3g$IZy}ZZZVO[=mq>qv?K>>>-[dHݯ;e ѧ㗂+.c]`v@Ue=L3qDؑ#wk\,-HRfkmC#4:M7m4Ⱦ}%|/>^|nYe|{vmgeˮ]ALL n6fsXeᖅ[ kZִi?0l͟Tm^y0xc8zţSo[{U߫= {k%-i &&&0|Ds׫/())Y(((l7[o]5Xnk'OzQTWm^y`4hp"Wko$SSS1)cRx=d>}3Ϩ>:ܯ&jjj;VVVeˎAWCWCWjqX([([(mKmKmKba=zT' ?in>***=#s5j`xqՄqcƁqqqhNhNhNc} LoGoGoGXdO@A頄g4_~9P|0g朙sfsss/%Bg>C W^a8P Tcꏩ?{#F 77O} ;]w!B&Lu߿1e?~.5ˣ<<<(?!`VY!!!$~І6F-Z41k!bhЈPsϥ?UUU:ThZi͙; j2uoԽQo^Lf&D':;Ld"26 e_ 'Є&#TPU>|Vyt#F7~ Ď3J> NL91˃:::*055}Bv |/BWw\  T[QnE㇎:~ d+d+d+ ~Clilil)X(, 0;kv,ܚ{k`aa¯_ҒҒ0e~V0Ԏ;ڃ^H^H^{{{£?:]wqx}} ܻws'O|O+? ^^^ J+IK K',x=8w8p &L. nǻa[öm'OnQQQ`q/^><(~J?p+V}ۧ ## @` ]v}STmgζT\UqUUe{N?~L3To|?_pơn7iӴ'8;;ǃM6r=+r=,N(O(O(mG&m lلu9_@oW YYY뺃5k/rHR-<--\P2u|?׷YMYMYM(ܶr۠ `u%i6lVk-Ž ;*#c#c#cعc玝; QڣG **ZwB:t } j/ии88b+|xq%`v"w{_[OykNk@ R;bwe/TϩS=ygv}k-LI0%,--boq@SOi?=?~x{8'Jߘ1}#ƛƛƃ-n<bbbHf$3L.`˲e/PuVuVuY,W j T*?pS2$8qIrJ+Fi v& n22l)OM?5*\ppKqKqKɷoͅ~/^ƽ GzT d Ye W0_._|5X\dq 0 {${${ͨU*BOgx&ررlkֲZpkgZ״i]P,Q,Q,WRrP!(j]Ժ5Xtj5Vݭ[uZkA_?U@xً^|r7nHHH{ i{`ĸqgYϲ.].lmme`gg9S֌piĥFA v>}`t5Ypf_6y y y x`d6lͿ[{߯WЗ߶`ī捻455$$$x(LMMz-[(_M qFgg<(3L-Z5h:h:h:,\. :::~5ȑ(G?/}G]RC AV_V_Vr,s,s,PCՆ xaB illl<4(iPr:t7<~8hzizizAalZsЕ7>U(A (㒏?U.} mmmmq333ve ]c){^~ ^ac}#v;b&1u:H#O,YYY(ypsWAśoV G܏Ѕ.D(PܡCq0 1 1 O>.ox.{.{~~~ No]Ya n`1`sss!r^y`͢E7޵z{Qq@IQIQId,X \wt ;?tNx\q!)S\-B8[ȣȣ0 pjW-EKaq' KⒸ8%N<(xQt:O'b ^ N/ ebXƯ`P1T m6O:PN:;_5h#ڈ6e^@2n[eee"Y$"tN:'TjTQFPt[6ҭK.@Y,P}KWlEEE*zUz UmUmUmiq}}}nnnk-4?4?4uxt< +V4SA*((%%%ᰊUɽÜ>wsp#Co W\q}V^z w*LU*S{zGX?~`}8p&Ld,W[\ M 6.m7*oTbbbƱj#v=?n8pR٥24Zi&M}>e2_#G$\\\S t!WՀlllʆ-5 j@0k|.FhYYYpkȭ!__@bnbnb.N 8 Z}V&M.\}RP#FvlսVZAVOVO B|\\pq~Z&Lj74hlp/'pI^'n޲e [oi]Ӻ¨ V[i,TTRJoyyy X=zbxr xxهg000cccٞg{<<<_"~|PB ]w)߁|” S.L/b(.]dDY"dTɨQ@q[q[q?Yg***ړkOAxnp/^PY&LfAL˘1-OG>b/뫯{Y'?*tСB~Ƈ337~]okw 1~G;+wV,}O}u_]b켱QGB/DDž3|BkkkW/^^=!t:Cv0m6LܪUs 7 o@!tStStSJoNԬYQ6m z'ӭЭЭXcB̹sSܑ#sG Z}Mȹs)5k"73737SEE Q4hX0!WWWȏ͏͏HV$+ Rg(UpZ/K!r=c1!['D)Sۓ'o;Jw({]λwYm6[_nnBשש QܰaqC!JKKuuu+&"wTQBϯ__]{]{]{!41M9wsBPPP !5#_n\s}1AߌBay 1c܌q3 qjũV~5TMy1y1y1B 3D!D;Nf E )DӅȳʳʳĸĸX >>>'D™3Wo}!ԱXuT~\e?_УGA!ԏՏՏȋʋʋBVg Q^^.D%555PU*T !9֚֚BvIɹs' QQQ!Da\a\aB +V0LՅ W PG#(W8pb. QA!(܏(V:t_^s2dntBgo&hU8pT2eL>iiiB 7ސ{B/|BrQBjتaBL2y!B\x㕎eș3)G 櫛 8pq@!oZi&!j|5Bٺg랭B,ZKHOW?]]qPjo1D -nvӢEO"c@ƀ'ybcc]ytѕ8WJv" 1lT7\ArB|!BLVt[MoK-Vb:$uH!UVeX!I$O[etjL1(].JyJ V鋧/.^{MU/ O|>G'!>SO ?%CI?P[-!r t7"00PЁC ˫W//!===ZoNAA_W兘VeZiUHLLzowqq\^{Bh=B;XEt]RQ*JENǝbЅA].?w]'y:k!- Z$Ĭ泚j.DV\V\VӕykEX^ejKZLLLC>}^(^_x_8FaQ@1 4_r;aO"""Hv#$^HxBN9n6ByP4?h~wc9F%F%F%0fXpvqvqv^Pv bX+;<<gs8;-Gie/[ & LoF3Ѱ/|_p-w}i;xxs?::::5tj(XUdUUNFFF```AAAv:}2,F6\6\6_{H:t" F  s.Ϲ<2Yyg坕SO?F7#@{^0J2J2Jiݦu 4~IcX0dC`%PGWGWGVVVPí[ 70gvt+Vح,?}7֛gaacy0r:t _]wnnnZpT8*ߧa)_j_7.M؛7`L1 AdH%JCeSSSa77߄&M"v C}t;eOϞ== gzv(8hKKK ZcVi[?P$J8p |^{QQQ촲@&MΛ lS6$$$CQ\Q\Q={5kO>]t)9pTSN (z*z*zB镦WNQNQNQHP$(,X\hy> 5kr={{ +3~gSmN`]ɺ;Y]"E^ ;bT1())AJ+UyUYkf-X|eW _-_-_z.rPhGȪU/ZZZ@dxdxd8D_}һwIR6sc)uԝ~ Be>/ܲs-M7yC"c^α4iVS87sCaeV׎];}}}$5hk\]]]]] k;v ]W-v[춀(++bbb(F(F(FwÝp"L*E000444M&EE]ugGyv%K>)Q)Q)Q1cbGH]2ue K;zwս{U(((SOA+S(% $$յ444AAA*OXcy4i|pϥ8s\2>J;ϔϔ@QllleyLf2΀fff7h4Y>2/f^̼I'=)S:CW!Q£GPpti0fpTUUAg՞U{|>{/{/{/PF)Qo ;#3jk+Xu+60m`@"1ְ)|Sp\ɹ3 \>p]]]R[h].Zəəə|mϷzzz h?~<<<4:} sss0lV٬2Ep} nnnXXXNcŭ[ÿfJ+FYd]:(\8ppYԒ %J&A>}_'O^@vvnݠZZZϥ1՘jL!sm̵/CiI'eiҖAfsI`7߀I&'ĸĸ 7n0NNN`jj FFF`0`HPE"THS)Ҡmqe@[[[@!a܇PdXdXdE_}Q)S8 s s sA)˔e:uf~Hlllx 8p<l>} fͮ]{Tz+,,,aFgt?,dVɬY5kPW8,:|)S$$$b2L-TɩSrLrLrL EދPжmA[].w;ẘ̊@gCww7Ⱦ}-T U(R 1:`ln0ad 7lo޴ &-MZ6M* 9E?X#d,Xr 9n9n9n^^^ WWWy#F捄«W !Db>t*J`ggM.]r4ieØG[ -[> }7߇ m5jŏ?>vI"2gNϜm;;;cVXZB*qԦ6&4 eD6]hyΌ?3xX hA(#}zk3TlP:?t~ هew*_~O,골Ϣ888 4^xAw)8 }K~P+xWǍ;~$@u׺I'aI̒%1h Œ~3N9wZoRJ}6(}/^O?a?j9Ns;>>>N+H$o;S5pkV93$}iҧN%+[`/li喖+{Wl!LBLBLBV"H޼wpϽx^yo ުTDDDOX0a><{d歘b hԹ3Uru`&H$\nvڟiVZk!Iғ''yFoԆw`OJA*;D"R~T>SC?1c c*twMɠA%h磝vc㎍;6mkݶ6(JR}H${B)eJů>}r]}+2K2K2K`eʜ9p_tFӍC;T>%߽w^_W ǖ[vlL,?bX)%oT2a݅u]rjB+pPӡJ$ɻ락I$s.]»ÝwY N'y[tuuY.E,=Cqww~D"%wwwhѸEaoP\\t75d[cf ?r0[xV"H>GCzpWÅ^X mYfI^de2Y o&:::¼k +FWwJD"x222zyI8pŮ^w:ɫ O O Os#FB9ra/H$߮xCCzQ؟?w.mlw:U\\ ?DC4޾z9sdH1cX\kVi%- 5X -[.p;ʁV[,1SL3h }(:Rt}hpz齧 A)RM3f6TX*,V"Q-ZF5???˷/߾|.6bS0[hl!XD[D[D8ywK'U'U'UptGbvˡӽ2f8 ߸}vI&NH >>>N)Hބifx!J\*PP^A="狜/%%%tuuajԐ!ЧJ*},9ޛGՏ~l#xQ޾zjLLLwOѫa^yu (}K$ec c c }7R|H{ wZDukխUT[?_WnRnRn#GyyySK~}9tաW^↊*B={ݗKK.-[no>BM7-d>wZDOnܪU3h+;?{; ɐe2d0_4,iX/lll}|tttg>;<>}bD1cAPE;D"yN~v?Agg'lqy0,lXذ0}ۭ [a+`χO?Y9r>g7T)SvO=}t|5j00vȩS#' "V"g*\^p9djDFZ~GGGP:? R?H 8Ċ!00 2}4hys0J5J5JF2L'{cF4Qⶊ*´jO ZWk]ӽ9R+Vo 1a#ƏJc*$ͤ(a6m.`Xi@4D3}_>###!q;wRokү%䓯пQԅ>%}J}}} _7u`5j }|uRoUWu_U ̈́/ >r#}{ H ~p:u>|k0#e V")S |0ᄇBi?AӹAT{*UN@HHСF-##)Rō7ZVXy`j~S#}TQGAɔ)'arr ,.Y\w?ODBpn`諒^.]rBΡCAUAUAUAi%EGGLƘ1_aS}Kup_}TD*"V=Z3 RMTMTMѡCG7Z. j(\^h^h^(l:䦓p!?hbce-H$ŦŦ0I?Nyؾ}APP?N__t}& On? ;<3OZ?d2rJ$D?]hv!LNNBa||pΐ:+uV,g:t)DUU˄؎c;.\W^{.U]Ts [onݪD"7qUUUp^}^}^ ;vY f3K,9+qDG^g9Y'bO 4,<xp$HȑXs;ý:܃qu,Bw$$Dn:IUVWY]e5߯0b#@UUGE}QT e;?jܪqA4D $/HuÃr=(&GM:]t$D ?)VjZOOO ɺd]tttʶ1P̡C10V[f9wsfX~! ڠCB‹/澘 [3fn̈́ *L0A߭$H$wҔӔӔ.[]|s(_zn/EO?W#6Mbᇇ~yyy F>`$ܯxn%D"]H<<<o,`ʂ)Pv۵nNe?]7nt]q"G\Wٯ>CJm7HZ8i[K"˴6 l-Z^x~ m$G:BccSq8+Bϱ? [&oM5kb;ݻC*(?&M[eZ6 [Pn[C"WWWCFqFqF1}>jeɲdY pdddڲkˮ-ATEFg(ˢ/M[`f&~]D'3(3(3e>5550a\0b 93g8XXX@>}1lٴ3e߼@d#d#d#@UU%\`"'=iBM7YdAmm-|sCj5j(dee~K/=S=ӡwr9oFGBgg'hiib49́)LaƻC*2]]]=? k;-[2d}+W`/x^y "UH̻w{=z S$L_)m/:"8ԳSϠpzPſ0w7w7wǺz ’’’TS-N#n9^}E_0CQG҃K.A͌7!7?7?7< xGGG\>|r7o u:8xࡃ |I%.R ccƌ[R2dHHII^zm ~O~Z*8zaWӯ_M0b2dvJ L.6] KO?-D(0ws*U.ҵJ*]9sW+ uuu"^ x\|]|]|!ezPSSGJƪƪ*0.5.5.ғ'KOB`=_3Ϝ.p*lff}3ՙLaꆩnHHHЭҭҭddd}_="1'1'1G `BI:P!vZ!Z"K6l ʽ+ܫ4dddo!>Q 1mcF}z}GoIL^1JiREVo[-ɨQ'wqGІiôaN/H$T%?p0TJR)A@[=oѷoG߆An;D"H7R/Z_G?PߡC{c.\Aօ aP,VK=6$DH7of_PKե}ھiBATATA9rBg#H$ 9n31c6k8pbzн{A8pנm`aa-e-H$HEލy<<Zĉ8'ںj몭146464/3dgNx|ﳔH$ߕT!"Ev *O|}}惚j> O'>[D"H}ސ 3fi[oidzm赡;s̹3!"$"$"jS>iDfHObbbbb"^{{IդjRM E||<~3W}NPjQ"042424K$7SENp[0w$e0&=1=@d]*wM>A>Pkw^xAݥ ܌܌PAF¬f4'h¥ n'K3ϼ]ӺuM]ZwiE߭ H$'D˩SL1wCIUlݕW^.kO@BTh-Z ''@cX^k3/g^<ȼy1"xUU.vX˭r޶{mdP?~fLj=zG"{d2Ȑkwokkj]uXb ߻/(SR',&8&8&/|`bbAAA@DUК$f>p+gTרQ]E/}3Vg΀&FM[[[[E"H$k3gFM|7 T+-8u0`fh֑H$ɻF*^ ^|J4ҨJb\*3EUwz[G"e$f$<{ v$ $).).) չũԩԩT477V{[mEQEQEQn%Dt?~ a"hR5QnFy=z㎎;:LLLKoD"}s `}gHzC£V>Z >}.\w(mۺ7tB px}AМ9@DV9t P[U[ ;";LxE2eԃl޸zD͌733S3S3S8|"TyK$?TDDD0c0`8:;:;:;Uî] B~/_I'N;D"HE*^QL1;\ef̖;}'e*p˃%z^N'HoR%@޴ia3I/**v?~TYf՚ %%{ yyyǥ D! raȅN'Ho7"o|7;;$ `i҂z8pa9sSo444`k N'HO,;;D*OsX%VUP1bxp}^Ȱΰΰw{C !q%\}H^>z,@,;b̍ jlllꏳ.]$?xjZ[,/',kY2$듬O<{555 /XBCC!g-˖e@GGRM R/^%DQ" c@@@ߙ$R;<<<<<<@'N5Mo4LMM!$$Dߩހ4Hþj ||' t=J{mRk˯-sv{Zi >:с\s?rH?;~v UVXeSuiߧ}B %0%,/۽\{8`+sR={0^zM5 on˷|QSFMC:t pg@n_|Hwx|;w !!!={ /b*K .9p?O?8$Hֱu@>#-^WDΒeT999pW}jM5tꪫ?7LΘ19H%7.jKԖ-<8xp` PDZcGhɳ&Řc^OO<= 88!V[zֳsssjXհa:vujHߒ%}  8 ۾o>9sGGG64d@1mc4x2ɬ'a!4i@S___!!!9!L3pj멭b֋!++ 2FeD@JJ dRY)m|ưҪK.Ao[~[`Aqb=*AUm0iXӰ&7o֮[nmsssyU- d}K%_Oğ? ФK.friRI?;fw)  쭄o|sݺqƭ`f̂^{])S@XX64zhH+L+L+~s7o ʅʅʅ=w{v;v.T_W}]uPηo9_011K/]tlNٜ9wݭvx\Vl[mEwͿk y;,vX <{y뷯]]]~Ӟ K%T?RH#s9蠱wc3gL000+t`]0`- cPB `2d4h@MM EtGvOAή]9V[]nuߎ};;ZZZ7F}8ߝ+W.^ %I"gϸ'UTqU|}z}*L0dh̽;ٛ7,Yhxmo蕣W^@G(iVҬ}0!{Bl`q4٨f \sa8VqX9s '>1ȵr\ ΠܠܠM>+WA:ui姕VF+VQQQ.w6l8@ ύ>76J M2d6l3 O>>> fb6hJ4%S7S7S7<@__rBrBrB{Q/ ԋzQ/!hNhNh~~~~7| }>GzkFW+FQ 3f>F0PMYMYM 6|`4^xm\{K"]p8RNJ>:01L 3(H R+EEE q6ܩ|-η8<(w(w(wGxj<5z[׽aYtE?<ưƦjn OT>vYBKK nݐ*l6H8.qhkkÙg枙 px :?t2dIh"EXoM;5F@lw9\\\NNN"E^ Uի*]~wPPFA p !gzУe=Z•W^ bOŞQQQmHِ!N49DHV-Xi5}}} kjԬ@': r4i3kgqX\lP")Dɯ?|Q5=kz(;_On?wnsddd  n7}EѨ5jZQQ4d1D Ec;c;c;Q4n7n7n7ωd2LhҘ4&(`QWբh:n:n:.Xq8V O(%d Y{x὇)S CT| 111P>|hPhڴiӦM}mڷFmh=B;QQQ +nܓܓAׇl`0ȱc#!lpኇ+{oH$Z|țɛ;D*~O{? VZ*Lb7wJh]кu(itXx,<aGSsE%E%E%pѭ#xM&p2e* G/`!XOi~Aє)GpqVk:?$.ddd{tetp-Z kMMso*R z=cbXJ(УG0aЀ@yS*ZU^ ^ ^ Pkz鵦CpApAps7H$L cBƄ w%sqt>tv۰枛{nB@Y4w_fz Jɕ+L+V0t{6;mvS)grB,G#m6IF@SUSUSTͩS   i2ep=sDRHEË ~s߭ۚo3fo~sseﺽ8pحcAӈM#ܼrxxxТB --mh @ARARAN;`J0%UVrC -7囗o^ ܞs{+q$><p48KeLi5'꣨>?PbjTwYxg(?_$NIbTq¥ (3G%ߨhLi:댯C`oooT!C܇5kCA ^/;D"st[m)3IŀuO=YxmN@Q$ iPҠA`ddnsֱuNռM6ixZC^y@2$+r][0"jD]I[EEEs^jz) lijN'H^ 6\4`3͝I"?xO 5k!TB͝쨽롆vUgW0Ltq8l;^^^oߩ<| pJ##=p/@gp˔KKKK>hA̝ #8x[mH<#u{m-)S<ZZZg0a/H^(nV `ҲI"s"s(B Bw "ޞ4C_̏7#nF sH$/WK]K [ݳж^z֓';sSؒ%c عععoؿaTe;w=iVo V9)GrwwwA0jaB /_i4@5,M&Kd1KpX8 O>G#555Y,_r' ^ /m6r+Jf`![""",>n 7 TK^^^^q/...)S~;>'.^.^.^gN5(J%PLTLTLr>J$0 0 }/@Tj?sߜ\W^uE{J?r(@ +xVSvX&,Et}?K͗LT&4yyw*JRʠ2 m.s2Yb$$$AWWdn,1KTM&UeeePiS(SRjB  (].JyyyPWWr-+ 111Fڍ qqq`QۢEmP+36t:[-8r:t dMdMdM@^S^S^Odzы^`d&(G9+`F-LN&'0\1\1\c#c#c#055C! %K'O @XY,VBG!y|P\\\uuu%J`/ RT͡C79s"x[n#u6Y/^T"}J:O?Y΃w\Pz/޲вaʯ-@ۗG]vPC%7oBohe K\^`v~&6ﳜ} ?`o Gҗ>U} (B˅lzse\\ݹ3?ݻ-lJWEr .hcL!]'r#yl|EY78{,责ӎN0΃m $ 6m5W\YOݞ=u///8t+,Y>p0^cT~~~ ,OY={z}7$LX^B/8^xtW]Mw}AYEYEYܝzeޞzCTObleOi(yqe8;; N,8掝;vXPZ(-&IS$N333rUV[A$A-ZVeS˦տWb3f BosEMMM(Q2d4wiRpiXTlQK_144ŏ~!6*6*6 aP;wpoPWWP*]r{M"y9YCYCYC?n8ԧ>sϭ?*UΫ QUDUSN !C:t:O< *eWʮ t;ݻRu|t|ƥNNCsssgOev`eŠG~k?J+Κ;kƒ>> `'xfff[nɻmmm NL^]^]^݃݃a쌱3΀ə3'gBbdbdb$L1}pG#[Mɽ{`¥ {+?.999uuu.qqq! n7/ˠd:hI$ 0K;333`p08xģWWuL]&pƱn`k}7}7}7S1zO'heZV qJW]]PvUv^O2888FgXͰa%8EqK-N;)龜999( sԹ玞;*7DQvW;ӎӎӎŽ[^sNQ̜9!sӕˊˊ 7@W8pZ$sι:(^W~GXu:Vt|(n҆K.~q_ť喖[ZNN(:!4448hx"QW333w]Q4 v~9sGDqC+=S_~uUQm4(q8ҀK.blNlNlΫԟ?EQTR}27` 5BAZZU;}7\zժ0}ӧBˢE-@Uץܩrxk[c,gY΂3f ಺b)f•W^ v?lS2/- 5j&݀W_EgJn*xW}QT_R}I%ʆ+ ̶߰?tڽj0:pt@%%% ß];z@v9r)E N>ե 䃐 Wh^lll gxM&^w ޅ;;;:K~֎":4thP͓͓{{k]oC.]¡rʝ*wNC; 4oz'NP_U_U_}K׎,귨! /=Ve&@SgSgSgЖӖӖ6m~lj yrp߉~'#?C?=)4۰núPYevvv1XZZBIV[}n:gu8=sz 8Uqȧ1˧.| K{-X `5k;v +V˟_^+Vz-(P.\ӢN:```TTT*< 4n۸m㶐q%Jֻ[_>xh=3\ ̄r˵..ֿXb}2 j=3z}aަym_h~wWv_}? Յjj.ԨRJ*pω>'fff{{{Az`z`z TQ)TTT ""h (׸\r~} @BYXqqq\j}҆ K-;[vr(rOAqѸł '3'3'7o>|\v}iׯQ40h`@~hG)))P(P(dp28.?S4{A!&&zpjکo/0q|:8 4O4O4O_5_!arɐ>IO @Mo mLژ1BBBX1gŜs@#GPdQdQduWЌՌՌNmt9U.s~~~CPi[ӶohըqvWҔJS*M64nEMI&'MӇO>}ΩΩΩ {bPlB}U.3]f̄6O3}f>O}§?x)bSX[[C빭綞 ^zi+\m~PˣG-vGghSЦM,lԲQ0ɼ&ZgY̋ .ˡdu2etK櫛!PB 3gπ\'ߏ(d@;;Pǩq`YͲϖUU(B! nA_S_S_k;<ȱϱϱoRI&BޭzKž{VY B>zM5G.BqNŝ};vWFI `IXOm_aP>qffZʹ tS)tn?SzQ&L嵟SN8%<곫)|Spذkî ޸{I~\{8W B zzz1mcF8r x=z^m{+WgvO[;^w^EO+3ٙLFotӯ.g:Ԯ c1GO{'N2@VRVRV]w }A&V75\YLg'8ɛ ꥛W:P@PqDG@O>hG󡕱KHHdӆL2mtVuVuVW'_ \2棛uAĕ+W xQE׏_`[#D$E$E$:O+]WS_S_S:NJ*@jՒO>41-ƴ*+++++Jb%gCct<1yV?~c ׅ T Lڙ3uN/_={:SkSkSkS3f\QsEBNu;}w %|>>>p} ׃zzz 0ѼҫWI)))Pgfufv_=z7 fͬWSE-j8ZTj1c ].])))@9Xl,6qC}hLc.OpB757575/} 'ZhAl$6n`#bGgsXXX!d<0?|~p>K_12w?=㽟=C I[oTH^!z 1 p?ay(?jڷ_qK:t(uuu`vm^8ܖs[`6m>{﹂"G9mv;v YlgA7+YMbŮM7$WL\LMM!{\|%Jx0sAqFqFq+GW 6` {߃O_?}TSO5ol`yw!>C|89JJJV盞o w Cy>^·7׆ ]BfKo`nvwq:ꘫcwIob&k&MSL{.f3`X?h ..|||}mggg sVk AAAP0`fLpLpLp/K?T?T?/G_ ,Y􃘃1cBV}Zi;쨳j᪆3*gT(6,mXx1^_8_|5!ncƸkkk~~?JSTvQȣ#<ʫ* N SxuW{\ҡߪMI6妖ZBa heʠR[.E,,-u^]!Cf̆;ԾS6^xaHv! =t:pujN N Nm=_GSSSN; \s ϕs!hѸ8qL8O} 9sTTTPVV̆; 5 5 5 sr`S)2f^ͼ &k,4CE000&LO?t:(++CT.Q]uTש`1b't)6xb X^nygFhQEookH K څk];wÒ%aK@aPXRK5xkVc;=y >2|Dq8,,,@O'p_/EXQ %KƗIɶɶ`TY$$$tq8]X7nbݤEփUVW ީީY:Vd+AV]V]VG] :tADgG%z^PTSNAGV C h_ѾbF?1nкAk|wJZe `/ڋ"q8VVVŃrrrX}`Px_>ЍӍӍv,ځuEA=F=F=tf| )x=Y)kxxxGYӲeMM7&nAHnHnH.X]fu tV:+888fff."@ Մj6}mt000x ~n?c3 MlN<,YDV;w/լGΓ'9O^5(kP X5tUCAt:$OaZ߆aaa'BT!033-*DIWūAMզ 7tttrk9;;;AwYVfR\)EYgdi4(YT&XYYx].^CSCSCS].`t6:E `śoXhe fͰ>_O >#G‹W@jZbYŲ y<>},VaM?M?M?PTTQwmm,u\pfљEgO~{==ٽn `徕V ^:Ay@<_|||@MѦәϟ9sv[oy_y_K^d{M@WW\e.addd_OJJ RWH]EQEQEQ  ~r_DN;{=kݠkkk]uy<{F5k,nnn1ML~P %pA \N+V8oLo;PJ+ޟp^y>LW3)MJ@x7Qe8r#F 0kDx"9U_R}{w ~rPCu:@w}[En < OͽW^?]t}~i5j:6$ٙV[n033˩S-BG5|.]@LŘ1!?q.CO=vۭ,{0Rڿ gTFF*sg:--!\\G}\/x_`u?>LO2=_xH\ .@[aw5v׀ чCжQFmAP&AMEc0QDw}SMI.,Yس0h8q8tʷ.ߺ|kJb'W92a)(22ZVr͝T+v^yi%Hl6-|͟lmxxx5zY#8ԖS[ԻSNq\A M/4^;x{{ǃlllDzzzAvypuLLLo4~z?~}iU?z_ NEܭ^L$-ϠňN=8`h\[C̬Y3a|2Cn~$듬OFp=zpppٞ=gC.57TsV[n`gmgmgm*)s6PhiRHNN͆w-ZBّ!^Nz M*4ФUW]/9ܝyeM̚^^pQ;[YTp?o|PuQE**ە`oM&JZ:5z|l6CF.] Vĭ[p_+WH~j)l5 jAՃo,,߱|J*vvv %<%<%|'_ÓOj< `ddnnnP{DG@]vuuPס {8WXc(QU>򩹳EG3f\x»'$s7K+VVVO,>ר%]=zvuHHHW_b'N9r\$$$(ߤ|M ી+N8o({6l7@S!bŌQ7nF]HpKpKpx>k52e |PsW]5ww~΂,c?xx .s4۴my1<Xwb>^L9s8r`o{Š+Wl;2W,t?C\:oPQG9A_ [+Vl-x^yudTɨQhhhT:Quk~'k]׺`sl;vri ++ aw?XD>H\-WA=G=G=TTTy瑐x6lYHMMo?ې}y߃8O'={ggg,P{mԩRJ %Xs :~6芣+F,_#S <pF'9ll2W̭2*(hQ"٥geBQj%>T}R4JiIIIѐ >Y}Mݛ7Af-Y.*bھ}kpssO\?q>wspwwIN&]w.X]2L+ӂO'+H)eJ Å  ABЉNk4KXŇ`c0Ly`J5Ro7Ń>V}5kσz Aނ{ rss!D։PҹsIg0: gi'xxxoC߆ s6mXeYeYeQ:Eo䃒$.=\zl*/s1/;xx@^ümn#I/0@"Ly\lr @fN,:Xܰ񲗥%%xn !JZ*3SfffzzzqjRt.4E6`Ā+!Dl(lPؠ)>S|f*Y1Y1Y1Z/^j=7PTT/w/w/whPAmRϔ)?.]`V eKF4L0$yݼXQWmoL4&Oog/uѺ@= yymԲ4$%<| P'N&˶Q x~|79@<9@΅ } PKP攙CKCKCK?mNv8$?nwX}**3Lh1z@S6Mm̝N, uXw.Zh"PUU-]H%v%d Y?k?%V]#]w*}%1YLAx,<||| 0L5w:+ÉGkPPP///(˔Ӂt0wx*xrd?oo4w&*111`aa2&7I$CNcܙ$eO'œ , @DDܩ$q2ƁW]^u͝F"H^e#iii-;ϢѹѹPu[;D">L`hhb@6G6G6ܩ$XR{IH$f*i"M$)3T|*>ELddd̝Jg=:{4mlF،H$黤;? t$M=nve)000y]y]y]B ͝Neμy GXhZֲ$ x@T(`sg+L Ƌb<C!Iuc%Lh~-2w*RQAٹ0[- B+ qhc4_L~y7򖦺H$Pv t1]L/] (J^3ِ5k~W1cSI$L 2 ,̝Fg)PdU*k('/'/'7w*ttȽ{Lb8XcCI^/V5S8(˽{/sHʺooX 1w&I)(1JE_E_E_ d%oSM:;uv 6Jܩ$γg3W^3w&I)x3Ⱦ}%ܡ:CWH_k˨Q+; up-de͝IRv Qtح:WD_B %sjq9rxXܶmqLߚ5} 5kڠ6e2D/0右ررTsTsTs---D"yſwMwv ; 4w?/;/;/; [.l|}}kLгjϪ=BȫWaO=P9r|xHMM: $ ^ox"xE H؝;a7\|ɌOf|2o>he/| ,*YTsÈ3#Ό8gF1-bZEO=Y.^.^.^ _,_,_ 9-rZ䴀Q=zB!CSGOk+6M4eD!].a^Mz;~=PWWԇ?D-O/?SSSax9Uׯ~r,Y!Y!Y!YP{ok=dcf9p@PkX[LlFGH%TstIYzF<mn8Y]eKe-…E]X/_j> 4 Bddd8uԍS>|RƥKO'!sb̉0CEE,bq=z)?i5j$4i0_`N'?y TRJ+hhh͊5+&&&AH^!k*gU΂g͞5{ N}pSh#ڈ6@ $8H$HHH(r!ehЖPa~g ?[Btyp0(zPhx|'߆/xg;kY ux*txj<5 o(o(o??,[l(*Hz@t͝IRv B0F#ˣG/Xr+aᑇG}Ck)>)>)>ХSN]:6{ozjzjz 6m4rz#`&~=]$l6Yr~/K`]ٺue,,,kq8M+G9q׸e.s)!0€nG<$$^LxnlF(,,!L@S 4 m۷mǛ7oS7nN~Ǜ DDDq'5,Pybr\L \ WA*l{!0(0(06 4d~+,^,76]wPW+7avK~ w%+YIj=IO& `dd m6Oٟ?2d@ozѡCa0'ja5Ѓ`Y2DbL2a0C;j8 v ={&L-xKsC цlnFl~Iwoyf9$/o ?X’?М(3O>}* Bޢ 컳\qq )) UrT)))Zܵk1\Hr!Ɵ? A>}2$d>} c c cR3R3R3 C Y1bfE1ctG88܃s /zwݭw>r#{7.(Q|mmm~CS}J&.`xM7!N؝;8qHkxsycl...ީީ UV][u- >*;;;jcQ_rԗ`3f >};L3 `@߁q-Z5(*)*)*3Vg΀Vk}&\ dž n鞦{CI ?*?*?fffs9j3Gz_"H'A ?)cꎩ;`pP3fth*WR|=߆zh36Sͽ^)}Sg?h#hW<(H 9696 ;[Uf.kZ0|M`R`#66*XU`i 5JJJs{e 5l9vvvkqMv޵l0Ss@^,/餹SA̠A3a]v!Eӽ}w`=ztsH$JdH. 47w&k6|S)LHS$^fZh-ZӚK?IIISP\W\W\7w*D(G?sg`0^ 0T{xUl`^!ܯrbbbsH$2SȲdY,EɢdQ`z}skSM6ԽԽԽ``_m:(Srly͖՟.K *={b\#OG+Wү@ `jj > } gcƜ[;F23efLp~-...ܩ$Yk. ALd3IN/Ńh)Z٦٦f<2 |}}w yyyA}@Ǯv Jb%;4,xaӇM\p[na{y 2@h,Y(wީzPpC/mSڦM~ : N]Dg>t}-Nr'sga0U N7K. K5ykVؕ+}W:8t0no&3g?#q8G=7zn &ܚp vow?84h>,g?F_4 &Ibڱ{n7mmmu]Rw l~p%8N{: R+B: ??|EITF*_Ev-[t3D"fefG?֫}}}Ԥ&5%gKΖԤԤTHSu|ց??&&&T"kkk_5_5wvX6FM4X pA 8p>|7/H)9@BVM7 +'+gleW+6pgPŪbU0^{;:~,X8\8z腣0ydeexpu%MMZLjhh`leWٻcc Nz H(J(J(o[!%;j}@#1w&Iٻ 3f5͝JkmNۜW{>7o!! @pͮvVvVv ӆi@D?s/ŷo߂̭[3B@7D"\`}A0  k̝Jd,XǍǍǡ¢ *MD"(sW_Y~]K];IKKC퇂]vcDƒϫ<1J-/^fW ```W}͝J5kx7nV:+ܩ$ɯsAn `8f8fL2WX`=FXWFM-M-M-/+~T^QyE+H~V' @vPvܙ$e1@Vw]wSSSs¦M!p1-bZĴFnTAYY% %KDΊZZ + gΟ9 :>>*W ׭oGS:EOUUU!y]S|OUϫWϑ#=Gnݶ4? "wX~gE/>'>'`eU ~-Z^PH!P;v 7|ok9 iا-x>Z `g].w xxf}+s-B er+++;՟Os\(Z\*dȨQNF: !!!.]j;ЯүүUUUp2eAՆV N69m'''pNvNvN```mU۪6].Bv @?HE*U*txH<yyy`gogog&&& n7AWOWOW7(nyyyPмyAs7 o<{< b6[Ztj,Yroߔ O֬ZjMq333 :u BOܟD{EӆN}?/x;Z''^:@|(>0T0ThTŌ~JC* 9?@HC1Q1g%OC-ËŅIor3 ١flڔ¿̍hJ^`1bD>vPWPPPj=D" x͓o|C!<[ڢj-JA*ޟrrrX9X9X9pG#1w';q8OrrrPbWbWbb*Bؘ1c!Ft2[ l R6Hp ` X`^Jʞ9| \ {yEyErTTaWPB%|m(^>zew} O>?$3>ܩ~;S?S?S?\p-_P)~P}EW@á 6 ~|  cM7@щ!"'"'"ތz3M^^^ު{ 5jUTYPeȯɯɯ7gNޏ|?BAsg{ߊ `n N~@9Y9}lpo1ƈ#`ffvYMYMYMseццգVZ};?v>TVuXaвz-C5\6m۴dޭ{F?~ _a<c=u zK!C,t % ͝V_ŧOkڿ#`nOFg Mew{Waì 6̂yO=͸*Ua]u(vQ"viإaXO'Rh)4^OKX`nn< = = NpMp&G!M//xr @i< &f^ Ek `c1ؘ/Oa/7œsΩ [oQtL L L @;A;A;ċEoW8Az>{;Ȫʪʪ l!!!{K˿@Msg0aE"H+ț˛2@ Ge CCC999ڃm;v`⬉&'Oܟv###!:(:(:պW^-0|Magg'Dj 455!MOõ6_ NݢEw!NT:}}~X1쪼ʰ- < .]TrVͭ ߽w!}W]>K}.aٱgǞ/K Zjkkk[W@܌UgUgUgDh"42eBW2mHڐ!S['l~n=__B:66Z>|jʸ'41>c|xXw5{aןa2j=Z֨5BģG+%WJD_{Eq3nMϦJB U^A ""EH* !"Uz/$@lʶzQ{9x69sf~wgRbbb+`}|@C!9ֲpwX2xe0 I$](tL?&?4~$}> t_|۝;o7 \ ^_!Zĵkg poȽX:X:X:<ܟ5k}]}]}]011b!;1o<ã:< |pp" I`^o>{qt6jZ Ʒoccc0l4l4l^U^VVV077kZ`z(-Ƿr< ,;ۡCo _˼˼ EX=oκκZi5՘g%x$GQrc}c}c}077JҫTh*4>x?#0o,ԪZj0`Lp6m '''DG744|JlDUJ(isOLO|QS<͞P WNr'':Nt9sL~333"Dވy)xY5jfՄ÷:j(۶l۲mZrj0~l{}D{/{0j¨ &}SM_r6riPij)eJP8pBصo׾] _ R5AsSsSsVFZ 'ʝ(wm޷yP:/h]к5\]]ARIaO=Qge^Zj!ُ4@ k5vlرa$WJ\ \c.2LF4?8l#&GL8TS |NIbee:~8\n~ۯCM!ghМEkϿ9|h0Á8:|3|e InS4JiKG,tD6l###ƿnƿH#TaCÆ3"!*"*"*Le*CjԾ}ah{?Xcjbbb%|`-[ae3̈́OZةSc DA:#΀fff/`lglglF7 cccɑ1lS)22vQ@~J~J~ T%U +WMsMsM"ELv+V>79_:l߼}͐SO?AvAvAvhWiWiWAĕ+W ̷2߂Co}S3'hhh<nMݚB1lj"AM{4_.r!;;fo7obJ\/Jz*<펿=.{њGkxu ^]TSti4ȨQ#GGGڛ޼&l 1 u^JW`_]*y}#s9>\7\7\7 ۤpi8T]1wh`yy8 p': IcƂ,[-ˆ! CBOOfffmiK[XS)x 4h$֬ZjMrrrc 9s@ās͡K?~.ps͵7…  C6ˏ.?((( zb0baB~7n8k56HGd* k뿶 ԼSNM9e䔑SxxxYwgݝqUoW@yTj\2]2]27 ; v\/SIARBY{ ɐY,[-HI$tU ѲѲ {SM~ru @Z!V4E"MY,CYtdkdkdk.#k(k(kR d!YHdpK/ K.."4NC:Q(kȇɇɇ4L& yyy3 Hi4$w]r0JIRi݃O>M9VX9AAAJz.n~--- -, ˻lEY07575,M]^tG K%<|곪ςyCVYA~F~F~Ji%NNN^j/% I@ u:<#FB .&U*I@~@~@~a]]] 5HM@j.5?wwwqv888 &NM s?aN9?"""555xM&m{ޯ" R%en|pLLL.{]@vvvvv6dϞ=C8SL]yyDGABBqi3)S84@81vҥKK~@y@ 1aFTE"UyTN*'_ HCeX-V PP*=MiʣQ???(ۣlKKKdMlZj 8#KQ~8r.+]VBXnaݠUvV0#jFԌ(p6:*U sz=`X ӏяXrh!Ēħr vaÿ_,Y8xE<8h43>3NnŊNunƿ{Pjx~܎,v ]&,e) Ԧ6پ1i 7i@Pղ}.(9s#KRK,(=׺dо}CUëDEE #rFx*kXMV၇$SӦ Ю^z>}M}E*ÃaQvC떯 Fo̽3\h4`|-(VThkhkhkh 5BЎӎӎ@@@(ɋ`_ξ}9H04w;q`nnW?+++lb'''nj78rOOݼyZN WG_; 77wiz'kcƮͳo㢍6.v b,1 |U*_[¬Κ e>33D%*ٺJAK^#Fztn'նmIc>cw+&&&Y1L:~8ù΁6tq@7]ә`TU.Ixvu(*S2J}pwwiiiЩt*4iTkPA qK-0gᜅsB|kQ 'r-*/]t 9[- o֣&U}Tg},7Lnn{3e$7Hn:x/8"D<8p:tevpN=zںzœ?'OwPcŎ4JSoOh6X["7>U>ǛCCCgꝭwYsssCAP{@:ԪSkN?o?o?opss~G~u ||營~~8q^7nz]=;[o}P{5;#߯~Kv[4: b秿 mT(D9B ==Z^^uR?f}6Y@ׁo/s8K% 3/̄?RK:.K)R.*Vr ោ WJ_/^"{P8 =/SZb-X0~j)d4h$NI7\xs!$z(\t2,Yj{ծV.]deeb^:| `ӂM  __lk k T}G~y@,K>3{c\ f<{"⻽n/h&j&j&¨3Ό:c몞```Z>k=O2rH!ϝ;y}O+V o)o)oO;!ϊ;3xM{`?/ػ7@A5a `:h: X1 ]Lm8?/JPB )hS@}=@%.1Km[m[%k|M&_uAY,P&M..&Rs5CS!ha 1cUUU"GMrr1Z^NJ6@iV ,  hG{\p+9Pxw‚ QQw '~!$?@H~] >C_L_r^ V(X...W벢&If/8NƝ; ~Y(T/o!ǐcckckck0 E/_n? օ [Cq~@@@Jn*`G !!ve%e%e%puu={;x,,, E"a'<\>8=m}0y\ #m7 `J0%߳7ٛ8 sPݢEx;{; /la ˼;q {_}7,悚͞o|?*~Tn=VX rA$ n?}#F EAR?Zɵk===o몞SSSjv˷[o?D>} ϊpoڽ5C 1'ϓ~=4'sϹ>כ^U ϊPlSlSlG***r]`Yg͇=#zF@fjԦ6m]  UUUprrM&Mf몞GnqfH :tЩKk. ,fٺJAyNlv6;A'Oꟻ;`3>9f˛iI%,T*+ϻ GCynm&%%{n֚ZktJ:e*A[7|.]3g6zӛ޶+W><̰a75 jsJ+ٺJAD ?$NN^OE͇Y/zyq*zf虡gAL$ BpuuC5C5C50Ocgf3ϛ:΢ .RAo#o8`ee{{{LMMa{yx>|'Ou +o^sz LɦdS2...xغ8zzzV_C\J\J\ Ll7vgX[A"}nALWC>K_eCCC 6!6!6~ )`}!PTzA4ilp2e4<0<0<0@QDٰ}bbb}P^]^]^ OH={.췳~vu~2ce 20e` hZi%AE%x RRRVd+Ͽ+W /nһ 4 l0֣# Dx uk7akV~;Ae>,a!onܼOg#w=ӦM6m4o8:]te[ F>}A ((SPoσj=Px#7bA^W^W^֣! 1v9rPr/?gv0ƔSj@ţV< _-ث~Au!m4r\#2hnns_u /_rE9E9E941 TUU7an܆0Y?Y?Y|7n>}QhAA_ܺ~gž {&%Ka_}UK-K-K-(t-t-tJR+¦M!J@*jϪ=;N8 ӋM/7MSOm>9^VzF *ʢzAB<CRS:O oX `xt ,>;sKZ. ?98Û{97~A6=xE9Eo,}mNV'~á)pݺݺ:Xz~mWgWgWg[ZA(D|||Ntj8)x5dgg?HF2`䀑Fld'`ɵZrm{A7*0(8fcAvxn|[ aV?~<uuE/zAފy+ -- ,--mkA1zD M4d9s8%%%pl嶗^np \Ǹqo{`W{/2]`wֽAJqcxFgv?(++Q? (,,fGm= "_$5HMļļ^ͽ w]uq\uxδ9L(2L_Oѧ+)WRtӅ>q}zfyuuuUoVYRM K2d,(((Fj# I7ou{ 7h H*髤mz1矞z>\\\рXl,{Ye N Ä>5b QA0dQ(Y밮únBv`e&GmrԾ}S +]Vtvvv(Vʿ뗭_~zS&44oS---?:4l)R>la' ?YBzVXZZq}NP[[ a^y=Z2je%%%%Xcnnn1>1>1>зRJ}+_%J[;Aw7uuu (S~pu8Ww^4*hTQF})ĵk222`GwV Z5h:DuHE[o߭[*20d`@ N5j:APvPvP68f8f8fuuu6j3gi* ȂaCՌU3QPPJAáTz;ށ;wF_ ~-w߁A-ZACEEE[5AqDxRf̘=z*VᏥFR#XNZNZN>SτbmX Nݝ;uf!R^J`mkmkm!ֲֲ'|?y-Z@rTrTr,[<7xP!BA ''~~~PѡCEVJ+>X KOJ +ְ摟{H RCpDy} *R p6m>T*x`|`|`DDDP;NT1bREpo "!"!"e<(UJR|;v%%%+!CPFWFWFg% 9Ws|YgYZյkU[W' OF\xR,Xl]  3" B)$  B" B)$  B" B)$  B"ER{$d@PU #U@Zk=5QGxmfo vkحmZizl뱭6uoAᏉN9}$:$:$:Zk-tս*T \:y[y[y[hxنg b~C>Z>Z>:pp~}}員QFuյu ׈ ڻwm ߮~]^d)YAL||UUW犗/)^v"E7~A"cReThZך^2/#UqzC-bjAɈ'Ω;ХB ]hrɍ&CзA}k*AɈ~lyyyYvmhֺYfZĵkЬQF#Gϲϲ$w]rI-%5J(  3l 6H "&iIP[[  +WEF(%(YRd l}`9_eU /Wd_}}} (f+f+fjjj8[-P Vݭ[u\s 8}GP2֣+  ̰̰ ?}xA- X±cAAA $L2(S~?sPUTUTU <KKK48UqT;w(]]] /Kc1@VxVxV8 0XbCPtPtF Оўў͹s7~~~4kkkaaa2(**G:uipKzw0Hȳl[-AEa`kk puw=zvvvg~AЦMA s@ ѠQ(}@aQXPTT@@@S7Hp4i >fWͮ A ezudJí֥֥֥6mZX(c$K*T.H2-eHURU_4|)ToSM6md[pssuA[yfXXXnn613fߛ}oC u:X#TWUWUWAա~-@MjRTBQrQrQ2l{ͶpAvAvA^zi(XG[G[GC *Ԫ7>N8dI$Y;# #3^Cهm] ws4wd8qտWUUU8V2dD{_}aͻk].ҷҷCsu?*{ OO@[oLk3 8ugLLLu7^<湐 vvvPa]uC[W QD܊}+f9h =ڃ_r~ Ƀl] W=k /x8T*JD}Aԓgɜ9/~ב1ck[mE:u6ڸ o&? ³pdGCahszR_Q_Q_ 5j•cW]9:b?~PvRvRvfffp0a:۰oþ `mm wm{-<փZ<ٻf7oѫG ˔e2^;}}}tR:)`}SM%Kƥ e&C; {읳wKi鏓 l.EEEΑ;G ^3fw?w?0qlllϵk?2f\ k\q999Sc1W_~e8WWWjު Wf_}e6@[oA#FxخmNAXXaz9}uAβe9 f@̀|0`AKKK?ntF8ܺs֫^*>>s'N[n 5RRR Wz^pnj]KKK`EEEp-Z̵vnnn@ RK].uZRkЋ^3r\qPy՛1c) <; oƿ&BMP#Sl{{(++ȬȬHX*aUlpLwLwL'O!!!8QDU` w;XcuW_)} ,jQZEEEhFjFjFoGfGE|d 6}wcn}py v!}AHRgφVTXQ K.;2SeO=Uzzz6tsMH4?i>X?tXW_~Eߝ;7C9+Oa>}צ^ y***] v5Aw]`6e>e}BQbQbQ"VVVtN:'p‰UX7[7[739r*W lg;A#7M A?b)F1;bv<$X[Z[Z[>|jZմi@_vfg:렯xUUǴǴ x7S s'Ns=ҏ_ڤ0)L Y,U OA]OOOWr^y̳ͳͳή /x/܍Fw#L+V2 /Y_(Q @3f V G^_BG=K}K}KG%`H+Gߍnt01<"w0 h1B{uչhG` мG"ՖjKAZ/?|s=>N; _;|ճVZ=fjXXX_\/(**K+V. A^U y$}$$$1c Fh|4(iP [|||8886 lsgΆC2eA)t LLL044ބԥKSBO|R0X 555===ATT\\\ yJ)={d@ R_PBAH I I vCXrXrX21d~u4`iR2 ̃2<ֲ`Z`Z`ZI'aaaj_վ*K%KKKa.\=q={>|4.^xE e+*hZi@=P=P=֝A~::: rɭcǜn<ǥK0! <8qqq~:tiq3f\s΅:)SJ'(TdCs!bq7olڳÙ;h}y鿃Ny:Aκu9 M&OCO ?% ̼̼Lpvvvvvÿjׯ]v}(7rCgm 5H y ‹f:әΠWUz@É!iB҄ po꽩Bɂ'd{|YPWWWWW^սhs!Rgm,T* A\\?R#d'e'e'A:/΃eee X/[/[/!@Rb8i4N}*T)U*rj+ddd@NpNpN0_ӿ {:#tGs s sm"Aez v Ѕ.> g>>C+C+C+(** C*UViZAog o4w5w5wZѵk`hlhlh UUU ##BRH &II`aaڕڕڕk&]]]666...Ǖ+Wsss 1cw>h 4 9/s^`7nxgm}0AՋ!k'k'k'0L4L4LS9S9S9022i[ עE]u]_w_bŮAVAVAV߰ PtPtPtPVVDDD Xbm= BiUuתÒo|§>NA/jL2|EA#AE#  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$  B" B)$oeM6Fi_¤0) *T^ $zm AA$/l]bbb;w/dh3Z~;H=z"Mh7PQQ?T-EK&&&ٺ7 D c?c?c???>++ ;&;&;[n9% k;  go(++CK]K]K8;;hE+`.s t jPՠplñ ںzAAkDxhhhOj,㷫qƝwrbʉZA#`n܀B /vUWZ_XQ(uՂ ׈ŊŊħOPQQyxh03l]  <D 4hC#F }z 7< Bu dl]2/S:6ul   *U~|PWWηu d{kkkC1ŘbLKexòòàv'N؝[o--^xbJV*ٺ߳W^z NA>;hz7޶z`;[ ( HIIQG,7us>wA_[_[_t8@7 ipuE ܿayTUuW]0dҐIC&yw-ZSTJҢ.[WxEYEYEYpꕫW5ݚnMԨ@EZZZD`';iAO B)$  B" B)$  B" B)$  B/lZS8sqbuȟ?t t t fӛMo6jjj[W4K/}1b4I?~U /60QQc}p\pÅ>+}V,7vyc!gLΘ1.KXRoA δδbbbQqԀM 4 >vcYo?0AgЁ{=zWZZcccnt7OÖÖ`3444eeeC͡PK`+444oT `~ [AEhz]زy-!qruRޜ9{3H_J_J_BbNbNb|=9_ρ!Czzz,\Y@}B}B}zUW033u6XxL1ZkaAy=`}חԦMSB/x nuïBk_}nM6f͈gLgLgLػwcq;vYGCAxѽ0>qpcB5ה^Swލ{7~~~NNNPPPor?~ Á!nG܎>_mVooo 67.L0$z}}}m۲ _|e1#a+>^1BK)/&g Z,mRH65m*̏7?Z*nU Rh)A^t/Lz}###f. ZJ-<_$ dxY̝6wiPC:; c&<<<(]R#uzKwށkړkO xU*'zO,e)Ker7NA bE,zdqD%*h /&T-ZT4:NK.UT ppp w+ k666(Zܵ+vڑk sAh$I6^sz LMMˡѵF]1ƌ3 11333!󿆼!yC@A}X}X})c )S 2 e $IHpW:\ιstMuMuMAwNwNwGCAxѽ07)SRK'p| .\&jt-P,V,V,ɧOC[ vpAgMaIDATxe|Tgי8  )A*hq+EZ(RJ $!O  N]'39m$ t>2rpΜsIAwAA+ fh3}$HHHHh D;0k:t.T;VXc`>||}AtH!;w@OORRRuK-AYFYFY&h}0666g6h0a(HGQ}Ax}t{`r/Å 2?'S'S'S?jʯ*T_`U[Ғ};vm8r6l lhņPW[W[W -=[z+^x]A>>zuuu@ؓ'uO*zzz >7ememem:u6,BT!(Qx#PnUnUn 5k ftѰ7aoxI']}z=:u] 魁%|M7oooa0u:tvB{ 5Vk@~:82IL7ߓ{= Zk(x:u UVZ%ЮҮҮ{M5@)t ǫ4ѸG4T* ] ‡XUUw{p|BEU_^ x5_~q4>tgНAFՇ*W  R,% $i7Nj'8s!-- n7lQۣ6ԳgSZk {q/}P}xՇW2^eS*]rW k`Z7 ͼ7L{1nnnWM^5I@&XXXoν9%%%z<6ylU:W\LϘ1=)))PdXdXdXb% !!{zrTU &~&~&~p"""`.] | ZOk=  aQ¢EaUªUc;<z}^߀zV] B)s @{z齧ztѭG7B֒%YKp 7 S/L0kt9s7SnN9V{#.'O8Zk000 2=@2 G(FQo ;0ʆ ) K.t?0xk׾/A M M BaO=C"D fA͂Ao= XKK wr}pi';#333t[~Q\$p XT`Q_:~ ՕJuI'}r~AڣGiGx㏎?,@y{zA'A؂c+ί(((_s>'q'N`t^H[4m)hy偖pѵGA!-2L*3 333 /܇Ç:|v;v ^sx́jӫM6]߳"VTTw; Mٛ O>'}NBÔ) S@%xE`nggg#G~6`\ʸq)H^8y1EEE 7+ܬƷnv>v>vmNPTWTWTg?=O¯_ _;6 <Ю[nIII$O^>|wYpgN;ɣG' s'|x;7^U{ctqD`ȼy#Hߗ/}zp5jh޸ya`ȁPҿ Ώy /w9rP-ZNυ969696p4hH8[lz-!L2 J%sչ\ӵGXXX)Sާt,,,==[[[ !!!o27>J~𳆟ҼҼ D}mԷtnҹ xxxBڄ i<S/Bfjy' |4ѮGӓNO:-*{)S6lM7T_} .[}l444_<,u^<~p{Y^$cI,qxAq,.9]rr`d`d`,0l° m淙frԐ!QC޾^=U=U=Usssd+ 2)\rA,,,eYUUdgRYYYA~w*R)pj©'''aYePvo[o ... C'N{#F]4vEؿc033w:]tow57jn7xB]Ot==#zFVZjU fͪ'Ɲwb,߶|m0g4jШA*o!C,D~"?w oKS7F3k0b1ݮE!͐f; Byf) clek ǢZZZ@5QJsMsMsWWWZ}A{VVVBŋ/V...Rgޅ{]g5|Vž= {/Fb$i4EȎȎȆ{ O8=LFKp5yg杙w 9'9'9fb XtbDXEXEXyWzAo};bVŬY?O=a#&1ccB `ү~+>3gXOH3'̙3`kí 6y"7( ]AOϧ$;g:t ].lll *_|ev A\jqՠO+; zvٵgWhyݖwHБ#AP|σ HI#is-ZS)}P>|bDݾvKs㣏Bj5g-?ktZkܭܭܭA|2 QA@AQ(m19y\DP^"/Ʋe-Z=({P Хti 9INogX2 ;7X*, 8w܉saw888}O §k`:t@-v$<i@ZdM6-la DeavJv ;:NrrrIcX+] 4y< tx]q`ҵK./1g՞U{VAڗi_}IA|2 L@@^5}US,,,!sCBg|O⾋2eT˨]]] nnnpt1G@X:au`<ֽ{D3pBq 55555*=cUxV!vxN];uԵy/| ͞6{)Xj`)H @jSM6Aŵ^ ֮֮֮Ut+ӭL70?e~N\:*W`GYtdc3f_,b9TTuPARF)ۣ(,MY,--azi^~귡[̇2e˔-Sz{ C$ i4\^*xURJ]*uIߓ+yEhLcI$TA .0\. \,xQb;oTMhBf7*J fƛwk߭}F2\4JT;e?ьfKX;9|w?/ ?GWRRE5j껬S-U-U-tttpYe $/L^PJ=ȇa}A(>%L$2+mVڬ47 6gl؜c&3.L3ʌ*3 q:*~Yˊ(%8|3\wߥ~PeW]Uv}^j/SN-Ӈ,)KʂP(t/t/tPPPXg]u}`o07en趶nk{n`Yʲe)}UiUZ___֩֩$InܠY|f&MFPPPw vy[Õ;TP)S?[l3x9ԗSc 0uYSgfMhW^u{2.p-;wk}?іF[m+WXCK-!k~w18>>uW:. (w =0|L>/_BBB r*aJ^%CAaqW۞n{^:{%y_a? y>PzU{:>^9?:=k~81(5R%KPcu:={{N9nKݖ  O>_7n|%6Jl7o߄{aA'NlʪU)Ut5k|~GKۥлwCp>}(2 xUWa=5:jthף/tvLZ2i_~qpʥ*@罞z^6ymюvA~("Z&k ȯG~w>=mSUsTQۢۢ[>l%vy&{ Zye2G*yQQQQQQ۾nO?]k>teXaPR2e<zx+\̻w1\kr5jPA岗^uCuCuC})R4UTٟ?>>>Pc@5Tz*= ؿ ^}=Xxo㽍kfgh}BGώ=|(QG~<ꁫMBK.eZ)S š^ lǖ-[W&^MO5j> J}=}/|px"8L3m&M0h蠡B +Tpm˵-׶@ u>ud$$$xq %: 4Zjm`kkYARQlQlQ,_Kx-Q8q?nM&ˡ\hcFY5FseE,f,e3FOx<)˪ o<6ylXYGegOz=칰ž un׹8=vzKfdAyg=!QޣGprAtXtXt}Nq:ŁY*fU Zzj3hgN)xӪO>J.}mPUU݅s 87 =4Pppp>}zC՟\g `=9 {7mmm+W'۞l{ zaFvm$\jp G=x \r!njlPA͠ܗ,%j Z|7KKK B#<}O/HݥRwPPZku~?{_b~ %K`v{N;k ]]]xyy~wjjj4x{{Ckͮ5m l bo`lup'w~_} :NS^ƻx&M$7^%J|}]Γ;Of/^?u:c?o*T}c|eW Gˣ'ϟ<=v{@:]#<Z[lm [ n㿏+W 'O;<z.]VVV.^XWy6RFQ-+++6XЕҕҕ_C Wc_ uuu!C 3l2dI |x KQQQGGGW_!<}f e̗['Nn\$0C}O뿩+v(n0a`P۠Ami.Mޛ7|'Cύ=7=.A{WT?~sss:8TPCi9*UF2RF?/&͔fJ3Avewޮ W[3#ym浅a'Ni>}gu? 9Hϯ~3$4Jh o"W UCVGzU߯aaa*/ױG#oL1j.044, |:>\9xp#_V^9{l0l8p wd_@dKRDX! LA$& |DA>I $AOh` 'I40A$ I LA$& |DA>I $AOh` 'I40A$ I LA$dddcC ;N\\\:ґPԨQQ#U+h 5C(T4hh3L9y*Aw;$/N^6_|yepppVb[vڽj36cHWU߳=ݵv]w gq9rӛOo>3l;`;;ۭ[mBy^A=h}ux`N:k묭nRIm}Ago:=(Pơÿy ^:꼪*cjS  ڞj{-[$.]Jgc?X}A~?es\:>$IjTiXӰ o`iMkZUWHR ퟶ)XzcF)A||g!Fdw j. T: q-Y4h5ZhQddd@C!JJ*S9^򒗠 :[*J 'k`)Rʼn'BEQu@8c%)AJ̯2 G4 횷k4i8J$30BBBO5,kXt> |R>v\YgagLNNN;ľ}RT)ԯ^z ߔo7KpxE< },X F7`4Zzk%! |:> +/n~q iٛ D&|r.\ʹ|T>*E"J&`s]t-ӵ .uRpg(F}  QXXgφ՛VoZ\6vmH/ҋظaaa 6ڐjpuW^Gc9sHgxs7W_ 0x?ښښhhЬ4 ha0m Xss3AzOOO|\pv@[xg!l^ؼy'zk`ʝ+whhh@Wî]Ņ¿SE^@Q]Guk=XXX; |:$uH8w4h ?`Pʴi)S}Oǫ{N9?8p`x;PC CY|uW{>~,Y8=o`777:u@kp~ Դi]Zz 5 /8"\u֥[ |*J 2^y0`@r%w}kQעuv }}}N'PJ+XWkͻ6>s7iU  <7<^x>9|rd}A(y%.VXb5P=T=T=.lQ8vp:ԧS[oA@@@AJN7S7~ <3 XgO}=jղꗫ_T %є)GSAYrRI-'̿?kWkWkW7~@TÙ3; B+Ww_}u7 Y>d`dndnd2OL@L@L\d}4[Sڷok_***㳎:>KߩA{70m6O X'N+~ q q qp3f4PVVwL3;t!O/G_t {?鍧7ހqK&`Rr>rdffBQŢEA"]@Q~EԽսսAw@w@w:u :t½{ B}}=5r ***RfJk RLJ1`W_A2UH2@;K;K; OOO5k mH[Juss˃Z7kݬu S6L0ep( %/*JtnٹePѤIl\ѝННj7#nF\>s30⌊3*?}?AW]sν:*/s2o n*lOޞ=j[+Xfo wTQpoScO=OW<]t˘1/_{|q8쾳`jé 6 '|Osss`A=$ÃCv'm,xQG.HY,4440115P6 liҞ= 3gK],u\ʹs)_Pi>|_Iے%mN5j8AnRnRn[[[iii(EEE5>k,,,nD߈7оl¾ j'A(.uؒ%c <|0쀳΂kV-#tۇATTł&C]]]]]]H<;y6thСAp(PH}" u:C:թb@j#)Miv{ gBBB=?J+<<< xN9#v1a;vyAzSLAZ)V9昃$IAmƒ.?gͨQV[uׁ׾_R?O# ҪJ*AU]U]U֭_~z ӟ簹psB|F͇/ 4P70o t}Xan > ^{ _MֻZjz;BԒ%QK`pE]^1c<*XW` E6mǍc/^@BB2>{8롓OO?y$jSZc?~ *jU ,.[\ e~,cA}e_x1ŔSֲ[n-8 :wrgpvLo޲/azpɡ'N8 VQVQVQ%}A_7016cl@?~< sPΐU%JV t*T)e˲29dr8iN(@%Ւj{ы^>>> QQQpvgCA`^ϼy=n ՐjH5~?Bz!\\\so߿*3 gܼXcevC字^^A()mF: N9QD jͷ6BΚ59k@3R3R3R_;/,&JXt3v7n ,;Yvfn$9INU گ_iCθLe` [gA➊{>p-ϗP|)R2L93̔3`T֨Qْۮ BI2Lt&:`g~:ĪbUڢv-juM5a냭>+W@Ae{ZXj!o/|{[7pzȈΈΈ)Sccc.'''W{_}i }I_yrмм@ѡCE;6vl  4_v4 `aaV[m.롯 PZjQGA ¥⛧ua_XUjW]mGA_޻&116Yda2-dZԉ]' ȍ̍̍#FXXXзCn"?iii0N;AI&՛>O}<}A>Ŷsss m7gPy%ɳg'Cߘ1}cwgN'P}5-K,<*{T ﲿ d:uP}q|`KhvJT:K0kRפ.f.'bŘpȹ#كg F-w:ASb t$I08ip$8}7!B ?:y;w444=J` 7} d9z/֧&ov쾰?^'-NZ333hݲvJA>xMNAyGyGyNkNkNk=8888`ȥ!\LLL}A50HHHd7n'rI{Z>/x t% ԘScN9`i ; 魁g=*{h QDcƏ^{y=P6P6P6w:A{3d0` v𷃿o?< yt:^}W1lcU.TPE\.Oŭz\q|vgî]ˬ/nnn Bf6_/,RUu[[[p읳w;\G}w:AOFR,NY g/x6d.\-5Z QFQFQF,,,s89]N >œA, m m muA5kp`3i̤1RL2e喕[V )hş- :w :DumH[СwAaTS!00VZM7d0ٻٻ; }t{`列#^9+rVϾ}3(2Cн{ai햶sOsOsO}AgL 2*zV +];tttXcN%}+^x:ܝwмr+E"uwgii î:*:u2 ^}e[}AП+ Hے%m ԙZgjN5Hn jVY-it)hkk; ‡ѝN?plƱ T\!Xߩ>g Nw}A>=EۋCh@h@h4 h$O,bbll އ{?7oߨt G\\\ UHU@-4ڢTg[myj쩱qwA7N'P>5QvFNPF+;wPn 1LAJGdgYv{-74nh e2C>>TSa PPPޞ{{ N'Pr> eA)ϭ[?Wߩ>~gvy&C@r@N$}A(~]{4јGc*T?ddkdkd òeˆ6mCCC {セPϤI=0,oXްS}:\\\ SN:U]avAeN|4 ,UvVbˋ-/@ 6(TUV[ ӻOw*A4سgcςHW+N;v;էbjG 1cb; hؽ{Akζm;;է鑦G:SL3sfw7xxx#xG ALLLA(Nzo`l%[W_=~swtX: ^?z#<tӱp&7;&kɰ?d"7Dn[[[p\ѹ"x7lq RRRI֓'Y|M7Ayy@> zo` .$\_I}]z_;ߏ / 5kAr@a0V~߭aiii0.#UUUHM&P( PcŎ;!2/2/2 6+lO?=0ȭVr+}ϊ {TG#`eee]XvS}uyr`9r`8ЪCoWI^;IwM7$HHH888?~><6m}z]k7m)'8gϢ!44R.L]nnn`+0\`pzr=8{$H.K[. ^yUlw7n<~砞{$c7ok׮#G􇼩yS C?hɃ&fK̖-w/&Mjð+~XÊyQEjjߊ„ .Lڎk;-YYYÁ|~sl|`VVfCujש g4x+}oRFJ{sau0^n#mL;M;M; ^}9Xpm#MVZMj5-Z[һJ* }ʗ*_ J+u=h4}(DvQ~GyH M M .]z4T* ϊ?L*P~=zz ,,,/ʿtﱝn;v:xn !%!%!/ B ri9?PZZ xy<v[ ru\|1AۿP)JQ K%ۿ֏~i@Zכf3co}5ppp5>k||m8PoZjUGVYuŀ]q5i ՠAW`oހТN:-@ǗI]$u(XW`;wF7nIIIAԦMQ ! ! !2r2r2r×_>gxv2keʬo6f#صki.F]'{uw`vn5w]s|7(((/[)d5jL|3ķy`FgԆ'W\yrEA|Cc/Aa=€f4A7n1c Chdhdh$7roO B!`ҠAK(ӼL2͡& 7 Lo1lllE"E.CY>fLD:!N@R!B@gYjjj5X&X&X&6mV`jV`ʺu+`~8Y9Y9YqsSS0_bbb888̶m5 1scLpaۼR*TH>~p*Wo |$>SSSa΅9\f vڟG0뮯7X~̷o7{1ŀ`DW_Ag+aP>!ĸ~qAUUr4Aw >X{b퉵}3ZgV[Coo/pwU |=0888' :'T =!{Bolk/68s4NA_^U6ڴj]4id-o; >X}81$''kiҮ](z(z(zC9>_|-}k-q1A5e˂vvv9[~l._ gϞ={@٬YgNE%=Oz5 :P[7uyw2d L;2<뻯B*J? vث:꼪`jbjbj 7VX=bh"E2T+[lſ8Xe hhhl*ʦ)~S&[oAU5Kk :w111Ou<X6lnB#B#B# cl؎`n.h>#Sç4[OS-T ZEuɫ{ͺ7YfM5=W\sF.]3o̾1(]6l4\rp%oʾ)mK‹ /`:u;iwn(ZTh>?ɗ/CCag΂Pz}CA֓[On --ZZ'$OH.[x_* v jcv/g|! +̮08q*VVVPj_U w^h~GAoޠءءeˤI9s 7o|Pʱc)G7z222tk?{A2>{ȿ'TȩSᯬ.|ʔ+SL93 g@CcJ` y hQ~PY,*SN;oMkZCΜ99s )) -9qqqu[mo`q8m]5 eI&Y ťW_7CAalؤIhFS q8y=jw$H2 t#Ar$7%uɠzkyusdo[Jo*LMMW]Y]%'aOj;v(4iSe x Akkk $IړN o4ww?[o吹4siR_ ~ZZZa6Lu +dץ p[܂ 6p|yY.r/r/r9GsrB e9->->-^d9o]޺u,!r,g'e'e'rqd900PUTT=ɂ Ȳ,ZLy<Y|d?ϸ>52m3m3maf^1bz@wtߡt !Ă .gN ˇw‡bnndddɮɮ,TAA50Te666.WZ4liNk8K|V>+%Ax%fffHS)o-V aeʆs:!tB_~NOY5riʁqjL.WЗ*5ԨRriسp= _ Y} %Ƶk V:+W6_r}=SAVg)Sob %R"R"R"vBۅ.SXXԱcQ5o tKt |JJe}mַ`gg2M=45[l]5wkkku5_kaaa}cRb ,;/;/;,{[2^i /@DN iӐN;7+YJ8wܝswZI50llcǺ>VU\Vq4ݴw0C!ϐoᄑmVYnxǛ?x#}cP,Y8jʫvvv.SdϬY9;3wf̄;[lt>:GltuuALLLUOMMM l.]2cw= k,cbb 73737,REW~QuYuYuXy,Lcz}uK-]Nf9gdd@^A70<<uF | HR JRԾߓtG#݁nt`9r\:دc!yH1 c@s%抾S 1(= u:fJ343hfLe Z.k ٶfڷk߮}>֛Zoj.]KwZA5DP^T^T^>5u}a홵g֞p;pS}S}S 9g[BBao`z?~[QӢEME&ML迶k#X|c7PاOaVqeƕ}>x+(//WC^ y5n*o*o* U9rVP\rAWˮ]-999,]-]-]AyRyRy/NuJ +@yHyHy,ppxw[;N:ȵrmPTT888x}''s;w@}ipVۭ6^d{ zI\N +&!!FVRacƨQP^{0;﬿.:"貸.!VdZ}4i !GQλ N;y/ k6 A<${Kn}K9r:4\~upm@ռyWu90u WpvvP~Bl)AJSL1Qj@VV[ :EuGCݱΚ;k뎯;bnQnQnQYj|Vj1xPNPNPNwтa@]]]{`6lٜǟz )lv8 }վj_c;>>>+1x9TUU!؟b۫n N;tPd+,~Y28upsPSNe:Awo 5,װʹin\ږw5Ir9sPj*:u+|".տTR}w C*T 7m~0h0`U CWۧN;[\#\#\#@'A{ 5GrɅFzQ}!~;{ĝwN܁N^:y K;v. ㎌;2ԛ_o~S)gxxZk/9{`hY|%GhF3(ߠ| `؆ammB ,賠+:Vt)P}쟇.1y%-IY`ިQ{l7n2Ϸo?7foDU 0TXR!)ۦl@QDG:%Nv_,g{)R`aa6Wl\"""055Nx{@$DPi4SoSoSo055WV^#G|!{a셠ъъGAAA+ pppsϓ^fϝ=w\NH'julfim AɃԲRJ-+ &xds;a۩m70y(g044wjAx?žfhZЖ֖֖11bI&&8t9-?>Py_,"o7ob!Ї>sQEFW1c6:uA_r r,'37xPz(=*QJ9]ȸq!]vi%o侑`䂑 F.RJ*wWԻwQoHNNɆCJdh郦`OKX?r#!Xa5Ax? w2ٺٺ٠Ujw~mBe{дѴѴƑ#I{&|\qPM(ttuu8*hhh뀮qt~EaEaEa===P\\ pE"eˮlll6Y6Y6YسgcO8q tPwPwPZn-uvvvۜ'OJ*ABvBvB1.]x;c_}=`_6kSyR^ p @hZ2k+T8p\r˅.0>a|xHNLNLNC;t-~b 6w|ySOy7ݜgz rL˙gʞ){,\[rmɵ%w|wş܁r9999*sEEEkXÚ߮ |:v2B]ZK;7n@)r.\ʹSNSƧOرcc,,, UU=5{jTH><}8dڕ W2\͢E1G|2%(++ӫO> &&&`զMW;6v,ܫp½ `w}Mj7L3o ro :u[o}1켸΋HHHG#G@dFdFdۼyyypwCY璓 뷯O?Ok=>{* 0\=bbb_r{AQ~MYMYMYx6ٜgs GJp;J+aN))) Yw籡Pjp֧ZC͐!7;̾ ?_EcpO@dȺu^&b?hüy0yh!٥٥ٽ}W_k7ݸjvٱfG @ĝ]n- ::}[j߾yʚ5+ \:trqQEEu QG!kN֜9`n444IY&]*r$I=0{`S C5.ָ]+Vtnݒ%Cʑ#b8qW'N^(ߥ|]tKR.IcL1= yyy\r> f9rt TiQEPj嫾]-wqvk֌[aCw Nu;TFڍis.\́'|~??<<<(Wگ<lW{` L.M-BRaRaR_,E(OyʿƪT'I% ʁr 3/g^m3\rA^!W}^ziDZ,f1gq3GQ$FiGZ -a cHf011Ɂ~EAѡCE`ӷOז-_[/RRR-7 d;a &|˿4E"M؂؂X GADDDDD(q8йtn@R +mU4hVfʛLd"!@Vh}H>.}\"WաhBф ug,XE{E{E{ ,ӻhтTG#i4D O(SٟR;wqJc<^TiPZN8f6:tm\4h~?o?E"io?'IaR(f*f*fB-_|{0Zk`jj /4I$MUqRZ){o•9eXZZBs5;g&l3f6665<[ ZeVAKy6I'#G$1wsM 6k~d PjaB#XrKogs::8:8:O?1c?6~ ;>#$H óg}CN!jՔaaa)Q)Q)Qfff >>>-  lٌV.Z]֓'"~z555z _Pb{`l]2v\ן\r ky彖ЩSQ"011uuu}9km rM\r(&i :ЯC?v+V:::qus2dE5E5E57/_2~%Po]uցooo&txYgw%Jgϼ91mc~1G;w&4?Xc Az3>w3fPE"Waz饧;w @֥KYq>ԵkSW[gn2v-ۥۥe8.~@n_|i%z$$$3:g4Ow>wAȨQ% Ww^M7ߤKMj?PKUKUKщщщ.]j;h `lR٤ T[qoŽ)ﯤNozꥫdyɇ'eJҼi'ߟ|/V|\QQ!OOOZidХХE5j~*r&3ο֜eȲ,ʲ,nrweY=T=T=T///dV)Y _.|-K~^ey{5הeTkt‡8qY2˰/dE^w*AkJlq ;"wD )SRR ǰ~ùv m -[ ?F ?? on"KAXXvW]uwUXeM5]`ӵO>e_}YW*x"ٱfǚ~j{t0Y*ό*U6 C =7ܩrʝ*pl۱mǶ %u=^ׇCWۮ]mڥj]w:AkJY8Y8Y8bbbM/^/ӠL2 ^z5k:|!055Zkݯu&ԜPsBMc;v (PJ*I% miҴҶJ*Aa͆5 6X7nl޼~k.oЯ{C6~mg=~E2lyW_i?L9焞pt9G'~O@PPP)~ @X&/t-NCW_ut~J'''Vf[!99Ź4S)@qIqIq AΕs\0nt:;|y-Z5?4ǓGˣ`1bgYϲ%|ߟs9QQQ4$VMXbƜ9 ~ZССZ*.E/`g[7nݸu^{yo;*vS -Mw9BޥK{ ; k`&wL܁ +<^}=wDj"5&.\R6lJn(Z7nƛ^ln0ws_':W8CakG &#\r˵]wi8q\v-k%꽪 IEؽ{i9͡oA@n@n@.dFeFeF;7w 3g87zC=ƃrrrS B(-+X~c Q|۔)oϫW455!9<9<9TUUӡye`}uPTFIӤi EP0``@_,~is͙6fff :T;~7UTqvvv\ǹs㫎xxXL}Eq.mAQbW+c=5hD{/" ]tv7y\既fEu gsf3sXcaTQUGU b=z5?$ΧO;O̠)RХ xxxq`M5=jq _~a{UͫS § X*NU qL1PXX{6 U*Cڹڹ[/oPp3gEKPSYSYS b&MnC*|W;>}ʯ |=Ph Yg}SŧOCMM )~Sӟ%o!o!oԺR O8?L3tmwL>?QgFxz齧JQ*w$,3ytx㽎Mg46n ގގްvb[7o&m3fMG!tOtu:] I$ gp2S\R> *ÓO> 111PV[nASC/^`oo4rs ΁3g@ !((b~5WPY,T5keu0DG#O^޽0r飦e^˼A{>X3 R.O]??<^U}UUn&MP۪Vg, l -[z@6P6PVcccՆ#G@AADh"E8ٛ7go9s,@unݠ曚ojeˆB/_O^qz!%(%(%&͙4gMHRjܫq,9`mgmgmFYj$ĭ[b7+,W@2eU_`V٬Ye055 f*aaa h'j'j'EQ ** c@VSVSVipE=Wiiii5={@{{;[[[A|a|a|!dffBшE#4ih]냙##ön; KF-F j888 .\J쫳4hߠ}lﳽς#G M֛7<\Ԯ]Q|QPSS ]I30]RW FIFIFI`|U(5ԬR캲ʮ 56k| %%ۿVޤISO '*8`Mw2fͨ ;od 7jި9ȜdN2.ɩI$PVVBYPd d-Z rwyjՆDž CE.])H @V6N;:uFKN ;V[A~eʠ'I ; /,?|據O#GP԰aQCMwWڨڨk' X/ў=G3l. '{j[@mmm5K)mAڂl+W c֌Y3f ~Zi Y,>| _9ls\s7hvA#?:8\5sUkkk .0:u%¿_/`lh͆wz]fwtw 'N#<:|||EMJtZAfz{ZjUmkmkmk42hjjjm,3>s&ޜxsM}7Aw N+Y#/;0oƼfn-Z4=_GO=yvvv0lFVitQrIDATJAaA*CAi:՗K[շï:[߷oIb&0Y9Y9Y) ?0m-BM6 7000MrLO2/_#NG &<zݻwo;Zw }i5VҽK.݃w&C}S_J еkC:::5Vn[]XvaYNNNtXAO#w,6Yln0;w(&Mʛt%GuH#TWWWh2ɘ&c`J)ݧtK)`jѪE*_|S}rrr?y'68mp>@^AIIE(,?&Met),yᒇ`UӪUMM|}:^|{m[naڈi#K/g;{'*,*,* v}nw!뇬jlتNy[me`ǭv܂[È #6uSle2[MA>YZlݳuOah,(ԂR```锟Nyy9Z[Anc;a2 _bŬ&&&‘#Gҁ8tGVVa}̣3< =z:tZA/!ЍC7OOO0L}0P)Rp`Mr{=zk+6|`shf̺5h: 數 ~7 ::GΏ t.AnҺI&A3ajj \Zpi锂 s y=tO= }sNЕt?~ )tttyݛwO.A?Sb ={`NpSvSvS[n}Dߊ} 4pϬȧȧ?8XkYeg۟{L&L02AT-`8wvͼͼ`[m}$$$?8QD| Q>ŽSH!x[fdu _7Y:f6M4atmԵQF?&w}6oۼmɞɞm?nq\o{ǫz*G R׆/ `Xa`4htټfo k\A-yC>5Aď)YX&cޏpl걩Ǧ«i~Yg˻/ᄐ)GaRI&i ?瞞{(((aYgMKc)#̘̘Xh`5lj ~5xZW^z5p‰m~Z`GWGPSS샱6 " " "g|V[mo@Z5[ _;YuR.K]`gΰa:u\IϤg\Gw <~ axM7S2N20a6 fΝ `y?&*bbbv v vj8o iiiﷷns::hu ܼܼ~nTŨQOn>pWw_qE_azA/sL1E1E1tӥNX_ e/Zo]]]Hj(ufי]PWWgXp• !mpǎ;Ё {){){ i>i>i>peW=X-PR|1#?7߾= |Y׳j^RJ*wn޹yFUUaTttt}Z={Ȋ#+VZ=k -p\Ź 4i^M —)`J+կT{neWˮW~ɯ_k"Ek:V׭nnnJQg!S/_f?PE"UG<UV[UXXXEFi2 CG!b]fff`hhZwh݁f7֚N- ^B̘11c" ^2x%&Mvb]ź5( FotN- Վg*f^?<^xcx⭊gHv=zuMAj X4DFZ2e8'Owz׃ Z6h|=aN -`'?p2TPaB tR:)(mԷQFТ\r-ʁb>!44TG!f!Up5r+tUe+WP C aI%T)=*xAM %H Rكg +wbމ&MdHuuu'OkA_]3b'7ozX?/$${;vֵ[n]^zjx"{"{"Q |"E pG@XX#y<=ֶ[ntqKAA4} _/,_X"NE8ZUjUՇ+G#gxЮ_~/? k=4 |z_M=;ddd@Y&eM>^гJ*=@{- ,xM —)`GcMB*#ӕtۑnG.9]r:,+{{Cj X!!! >555k*U.\Jӽ"Pr}5,R+R+R \.q]WvHvHv:w=L{0UWÝw#2A/`w2dށĨĨ(p_}ҾK.w]u}kYzx롦{K XRNRNRHk5i3fCmO= v6 7\-la{OOOOO׃Q:Fu*TLd&2 >x=6zl]ŻwAc`A||GCGCGC_S^ -A+Jh(r(r(rnN9 z$Hkh }&L<EQEQEQ`߾gx4B ?"?"?1CJ*,ANp兖Zlll iOӞ=nHݐ!pJ+Akk+&&&={ҦMI` ]Xx`ZkvڽjA eLΛ79Yg"""pW@qVqVqr\.x/^ =moN7n:=w參+wlJٔ)[_n}5XTnQ g**U4^{tG 7W\}Ϣ |XL1k`lmlmlT\֯ cƦM!C'@Z*-j:рG ((kYײ;w +:%tJ.*ĝ;w!oHސ!C'~_yFb ?UTS`mm ,YT_}k l `X(gQ]1m۔zzzp% ̰a=aUUMV50{k-Ol?z(Q yyyǭ[MMMۗ7K"$x)))G2jRI&0܄s~mk;8|'A+ݕj:o$H"H;Ҏ?9sNiiikY,dPY(ȶȶȶ-hA_]t}?BNJ'  po,[`v KK%+++tttpo4x3ܠܠ ȫW'/2_dHө>=g=dɞ=aiҴijjj Lf7@WWϧW۫!-- 6uiS'PWW3;8\re(P8pD]uT)RO(IC\q 6PTUU,}X0I*(SP$4NiX/$^H IYg-)/S^JRYY$7oL2]2]2]$)<<\%xuՒ%I '47JR~F~F~$%mHڐA/&_L(IEuՕ$Fz#Ioyo$)VvZ Mh~,vvvp?e,XY>|f@̺u1`WolllMAs_Lz,dffBo|SFL?CZZZ03Cޔ){r?d9V)ASMVQQc_ʪU:0}Cqq1-[;wHLVVN; &Lt*A 9 *{lr'Nhݯu@^iҚNSRRO{O{O{ jV%J60l`@i߻uօ[`J 9ks欅$u:I YMd57foޘAqq1pyV:tZi7Ō@GGkkk41gRϤp?\M͛"E !NܝhM={³&? puo4*iT\~pJ?p¡ ^^^K:,u1c@~aUW뽮 Ύ8;X`cfffi7vہjզA NUr58kpYg N&;MEgYtb`$Im9rШJ*~nAUU^zu 5,jFFF`j:K11bbD\0p!cjҳgKO8}75HkLk UUU*GqNU7o Ft[=zl /"""5YQ. ~RHZ'NlٺAwTݩ -- 27"d666;\]zuեP|aBО=Y{AB%y7deeځyyyC}ytuu[o}Yg;v&)Qu:^Ti4B -͖͖q7]wϝp e.ZktҵJׂW^z&XO` k;34?h~PsGF%)SzefNt/mڷaв~-ÒK,Y?<|8qP[[ zEWrrr?%ʟ? NJ'III L?iPI'qQQQN)܁sx5FP W^{U+V/ǻ~[)A&JR 7o 6l4بTǢCN99$z|4ki,;9u'u'u'5f+khAJlSUUυy'N>}4JpE8x>}M7dXmݶu FTg3ؐcC G,B-.%UxQ"())zk:ȧɧɧAk#Gͦ6 ZȽ#܃gQϢg+VJ+=EyEyEyM Czzz0PjwT'׏~zK-j묮DFFžGHHHKMc*#0III(..Y5Y5Y5M>5eee8wL+PPTPTP< Oo$HLf2SG#‡(#woSLlt(S? \__CbĶm]tj_ #;FvQ12=LFmM>5} } } XtzEЫny5j~zZ ?jv׼[ EEE頪 yyyśo^@ϱ? /8D,Yօ [Ϯ< D]u^jzo߆3CA@A@ABqfqfq&PTt ľ2b܋0ЌC3Aߎ};j_ C}111v)o@VtVtV4re2(++",;b<};餓裏>ȋblll0kh/6m:]]] ?2-[638 Nh§Qb|||9Ȼɻɻi(`_êU B v7 ۯZJk/^hЂv<==A+`=zls2RK.`tF0zi% 1b0 @YQYQYA#vvvHCPUP|L(,_X5k2N;M=AgJ::f\qeS5<\'pggg@YY'?ww}|6志寡ععHa0#enC>(qyƁ rK-xM7= `r>еѵѵRH!EUUU K^.8qncH28e0<7yn^Exep{`rv[5j.PPP@neZhQ [b!zzm"XdՓUOcxPjT|bŋ/V5kx!N`:puWgȴi# 87878~ìvWn|i ypmеA͏7? h?J* \s(;씲SytttF [-[-ۿ{7,oXްk;k;k;k_ zzzU+044ߗPG!O'ϓ+WƯ!GJ)yJ%nrmA)A)A)pFAYYTUVZ0ƈ#jFA/P/P/Ov#GaQWFheeepnƹ 83&M`@H}4)-wrpҵJ*xGZjաC];t&NM||\A*hH-`Rh)EQ.x\q|iϧ6m۠PU*TA}y}y}9/(^Pn܈vvvΐ_5j~Upuu,,,oHKK[l?% K0 z+H~*y,zR %%%J+ .\.-\Z@7C-Z YUYUYU`ؠoc%K,-¤I x!{!{!ߝw0o $I(~-k_j⫠]Nv9@tri4A 4SgSgSg(#/#/#kkkXxUtұJG8W\so.:\p ̬̬̬ mh7ox QFAUiLp gmyr>.] Xc <4BZZ).S\ܻwsa[m巕Cws\\ir _;---yzAnhnhn!2dvXր9BŇATTh/(F<9HQҨ8w8{z쫲‰'柘fUͪUTnPY,Rd)Beg9* {PVPVPVmDEI$\G]{uuuu߯~X[[ Y,R k׎E1bŀ^f/]wY4VREz!Q^FЌf4:ґ8!qB0iӼ'888-! Wտ-oy' (P/yKޯ(L0@i4N'˅ /o>>>:t<}m޷90y?̃V:XNm 7of/uw]P`QG ss7S{O=c:v(nVzkI_԰԰0xH6XXXk.Da⡉&Vέ[•+ !}~5KS AAAd9e9e98.q\8ؽe[%K0v[ʂ܂܂\( !v]unnn q.]7tbҐ:5ujTx*U לUۣn㱏> =t[>|n UT9S >|:w!ͯH ޚ{k_r=v;jPhPhPhQ:Euz7웰o¾kC?K©S `^0hكfCӵO>PE#FAkf ;;;|'1(1(16\cs HR5*<|4_~z333 l6lo_3gX?ȏʏʏXFcC\ 7o| +'+'+&&&Pfniz~z~z~ o(o(o.?tm봭Ӷכ7̜͜͜az齦y;Hf$3A'NnܠaKÖ`kko,ΒMv2 e(C")=X_ְZj W_jmڤ '''Lڙ3i0`瀝vz},{fG͎ x=eO=][o =bd1o߶?;;;lllo~2zzz0$xH`X{7GK-?a pǓ'O4TSS~$5:db/Fk:+QGݵ}wM^xŊoM#FJR/"I!Bƅ)SKR+$)QHF!}CIJz#$HR;$)-&-&-Fﺿ.IPf(32S$Η;_Se|xIz { { nRIR%a݇u֕'|zR$);;;;;ϏBq o侑FJR*6(Iwݟ$)mlش;HRiiϏm36gϪ?l>$уFIR֏Y?f~~~_HtG#x _ y37gn\l$RU*.]fXPjZө\aaa`bbeeedT?~P)R:tAuCs0U6U6UA5jՀ?>9|r85 jr fN9i&9v؝c ?.?.? B߇~/;3AFǣ?(ywݝp!O111DDD'Xk]u@-Huu5{ !emڔ>M}4[+˕B~5`UW뽮 Ύ8;X`cfff}髲*;!n݈1bŏB%AN9߿ݽ+++yzNJj<9_4h~ccc?BÓ$0ad4иB 0vA5k痞_F7n6؍c7 7n2Pz}׃@TT0` [c{O{O{Op p p =CUeW]]Iv%aUêH&M+6ش"xyyAȖ-![@)ՔjBee%T/^Pu\չ TR A N3BgbU؏ W 9H(M&J0Zjh)4Ki (F8Q1FyNoo\rlB nio'P(@zo}!,//ä6LjϹ>>> Aj&5x_!E@AAǀvҫK. dړ? b|_?|d %%o1 ,;_w ? :$vHeĕ㏫Af̶mAMM ̧O5 %%%|2+!;+;+; >wC@vOvOv222 bf̊ן_~72^P:@7 dMdMdMZԢЉNtJSwhq@q@qAPkGqB dGdGdG#03lmڰ50 PxkVPd*2?Eҥt)d'd'd'xwq0!nG80Xk`-n^yueו]WBev t3I_yLϘ1=FFF(|JLn=z`jj o6f+W6l`O6(mP7o G#G"D;|nnnŏeJ;TwP=z>kooz]uo. 7l0prsrsr&Û o2\ov ^{/u{]SSS )Sf̆GD>|? 3*fTkׂE UWp2d,d,X&M /ڧڧÛWo^yɐ5kZW=4{(XZZBR)R[BLIÍ;"v@ħO!QRFUFW;xuՍW7 YƳg7joӮO> ^^^oooBstU]G)|JL!S20n6l84Ji_qu8e2N ^kxll?^uzubkܯqƁ z; Z?hNt?Dw4J3hJW*]tYgaߓ'.]N̜̜888~ë)&&&cccVVV7Aow;6m&L64m6klج.e]ʺ=_0`~|[m* TUUA%o^z{AׅA'F'F'描%ӆk8ܗ/w_ֶֶ֠ S6O|_m<,5_j[oo=>}*ܸy捛 {${${ /r+\|qPpcFx4ݰv y4xA5V5V5|||@tR:Q)R@wdݏpoEa^;|wnlH!͠၆\n—)`V?Yd^+U__7o@@@??<|0pa@xd!\ɼy%7_XXX{={j:v:t Jm68?s~ ʌ,3Hh;춳>p|+5kFLfUUm컸⾋p&@f]umunֹY&h:W?m%$$t'0!`Tl]ZPjA)(}}txK0e2Y vvvnnnxʩʩW G=z.J\opu؛7coVҭ[ 8q/|9>c`3xW_\g<2eK. K`|3o̼19s[+Vl-(S.\ 4N;_G~M?RX)ኆ+M6.Klﳽ#ry"tbӅ> <<<Y1"]w {20A5A5Aإإإ拙ޠA{ʼn'^gΟ!!,fAEy })**ھ)S4r[-ȖʖʖH~Rpy8GyPXX Y,i^U4hJPg3ՙ1h=z ^jlsY=zf^7nxr].ӧOnC &4o]]]???Q| l)I[&m3gwi o:B뫭 b*Tx-a_\v?~l )|kFFFN'S &L}_}n0acCdž<(;ԲS{++˯,; v zkyiyiyiM'0̆gBz!ADlƳfӆO>m?g3FFFC6ui}jKR@HH \B|+PԢEQ ;w,T7t:JI߼xՖW[b.VeUXV:Lu F6mV;vCCC 85vj]`|=0hoޠ=hMך5]>9́|e2_ Y#Fd 27@z*U ~v.j]:777|0að8>v|eh떯[./_7775} III.XWb]jGՎ- ؗJ^/^8{qbx4GSsB {z齧CfzŅ^\mۢy!g`P0`bD`2 K .ddP L3{=RO ej}?N;Y;Y; ȬȬ ?-~ g syAnanan!d;}233!fͬ8qb222RtK899À5S P*Tr\(E)Ji, ?0ZCń }оSN;9qM>T`ƒpBϐ!=CݫvڽZڃ]]]T"ΉժU*m\\\wj6-$E'E'EC)S L֙3 ɇ%SOJd2{i{]uP.T.T.6mۀ1}clllcǠRIП?Kk7['~as\M5A{`:V*ZUddd׸Jޱc{æcm:o&M#uG0aÀ]B̊/7{ǥK7ncccЀ|  iulߦMV׭ zL179orQ+,%]Rq_}_ө*g\θq[k[n }߷>)S87K;{A 4WX_RRRJ!jC|cAHH~2'sp)t)t)2N+&}#wܻww ;v;\өwUUUҕKW.]y[m`so |8Ç> w3f̈́r5Hk}}uuu`.]mශ`-kR 4V?{F)S*O?=T_x≇_~qf=rH^6z-̽7{d|MƋ%ŸjF`l٪U%KӔӔӔ k'k'kt_QWV^Yye% 7奔/_6t5jUiA(I;mi֦D}}~*@ N:: +)OA=B=B=mRyTJ;XsA=^zU''|ŋ=A(=)%%dɞ~ʼnQ FgK- ]>w]Fw>}u^ݽ{u갫îw|k5jjjjMANnjJO 7No88e|1/_\¡TRJw.\ʹs.e]ʺHZ+[&M֛dffppp5:u0 ,j"ePA]+lZ6j+{W t+Vto |:b7 > )'n./Yr$'[o pD5j.xbrW3f^Zn 7VkXaķo_{̷e--()) T_ -?yuyuyupqq+m+m+mH(P6,a{rDN iBu<ց 7@;Q;Q;7;xK^j(A4GOLRyAˤI/{',O3f̘555v]A>_}b={ A5PwPAuA,G#tZACeee Aχ(`X!r0hŃ~&כ\or*[oy1`!Ќf4 |FDĒ`@ar ZG4h2?oߚPi44Oi4}t #dB 666`eeHF2n{ C 3rۿ܆/־XhA4GOپg;;;555z0ˆ c׎];vEEE1kQ(`HެYy+WP)RNА+Bo}N;w.ԸPB 74}Ԃ qIP%Tm߂cN?nt4ְ[n!{ClP_V_V_[䒫^AtDD^y0`\0^aPPP 2=L6pw]PTTF% 'OjΫA^)Rqrȡ<@a럯9(^QkjAG_U_T}QZl9L` vXTV[ w;NY:o+jv٩&Bd!M ‡8>)S2@ZVZVZs2Za~6z}pG[[VM ‡#+j999vvXUؚck'8v8dy%3ՙLM ?' G2e=n{83JsyW7n +N8"79nr'P;N5AO,^Խ{йsCY,dNUNW9]4L?N[ ;v"L(P0Aӽ!Q>Ȇ #mmm!(C!kkk3č1pkÎ ;6Ezt?ۣoBCQGUUؐؐXwwwbbb}k,<7|n=7znI%;3g@XXUaaaq^Ž s\1ƐCm۠zzz [.[.[III(iQҢ$xې!oCM6}!sC JC!RK>|..H]@gOQ>e2F N999Nk _mSM6T*gSu9rɹs|eΗ "Eڋu_K,9&LM܇Gtnt'O=P*3gtOx}җ/ )Cʐ`up^{ّgG mj=I{~X®] e= z@X"pE }ޚ>{=(zW|||Mp嚕kV= [o}1ګګk:YYY恱%x8q8sLȎ̎̎W_ ,sMl1b0 =`xM5׀A@zkCUPEZ4lJ+}94H"'9Nۚ5mkB 7\R/K/ݾ=c*ڲj˪pnɹ%疀={((()))*V ui~2'h.5K>{RcScScmޖ'NOh:qvywݙwQѣGEq)@k47B $@VJ+ [/[/[z y/~wsf6:xu:S)l3f J*]t-z땮W` ְk;^{A<$}+Vo+L sB,G#^*0}-[RcA?O?O?Oө>;?;?;?f/|#ٿf t&LЁ1:urty"D Xap!?VYtJAJ21RVLYgͤIG?,dʒ)8+qV,M$JJJ}S}S}S0H0H0HtϏza c'<<r|xP)ynR;HX*a{C>MPؤIa044tOJJ z豢 }CPHPH߯nzp:u28 s0 }Cֻw[k?~,`V-'ZNeeeHKKσ1Wc@TUVDDDZ/k%QwP٩TvbM>Z>Z>hw 9sUWÍ7x \`ȑ$@O>asE.XV,+7odV2xL1wvg\7nxmZ(ԮR4w~s%MARmq`t9`4t_YCYCYChnnGGGpcÍ 7 j|K-ͷ'̳HHlllHHHipJS@E*RMMMРР7 PZj z]u{^Z+xyxyxyȂoJSTJg*0>>NhУ(g(g(g믮urցz >~`y:gt蜁VsZi5/Cxxx+jih^y Jg`ee,;XvCѥKE@/X/X/t[m ߴCѨQGa FN 3t'hՊVP^qb0Ag&MN)§ &qMYR%B 5F<at<7xn\xg㝍w tJA>QD0n8p8::¬K.ͺQE +WCwwS 17eu5[M v/` >4miRX:!㗌_2~tJA>Q9 r;w4F# 0=~zxH].ⲋ›o濙锂 |Q9s @9s+WN% vk kמ [n񺅦S OByeʚN%U- [n&KKK0o8lj: (`QP]bbbAS ^^^|37];XyI%^{B _ إإkҕXZZZTSNA>]t}.kf̮9yM" _ZZZ lY,4JPЩ~ȡC#aSMp2d%o/EKR4-(ZPc>㢸v,#UQ,Ш޻Kر5*+.bX/^\͢.ggǙ=sF߽]ĥ u/u/u/yɼd^ K%JHHH@CP O O OX=kճ ]λweXa],W+˅AAz:u`Ȼ!h;mememe'lO;He mmmPM&Lf;S?3`l?N8N2;e"їM,`qsd&2dJy|fdȜ 4~ M6l6۫A ylHe'qQrBO777 `бtK9sV`gߝ}w3^.{ܻx⽋p&LHK_|eoՐ I.&]2eˀ9())AAXXAYYt+t+t+@6N6N6dQ(YH $0i4h$>M1b6 Nw:V]1(q80\`p01(& V`%@7 hmm:::%xxx!DT>!O yTpÃZj=׊׊_uW555 LLL;wo!p93rf@EEܚvkڭix)Amk߯}FM5iv;v؍7g`&`].E>5~YsYsYsٿgA1M1M1~˓/O< zzzH#@aޅa䎑;FTTT(T"DBK , b7%wYLf7A-͖f9;aEoZi5{l|)ϧ@垖{ Ì 3G&&&YrV߽$L2c9PT*ܺrk1ǬɏO~|#rnʹ)p/mX۰!lgtW@DA5 jccc-SN=:G /S/S/SIII???({ղW!22A!XMe6䃒JC[nmNrEM[6m-?HXXs\0""ݢ=v͕6W@ge}FUUaf79'rN@ئMay} W¯_ a0I\'lO؞۞=o \w94iS,,,vحح V6[m'''!t`Ё65h(G(G(GK/mk,Xc㏍?6444Eެެ 9s.\rrO7n03Cii)L}8ԇ0cBfDT7Pyl展 3`gg\ 0€  pk0g̜1scv SS)$** atctct)E!sds B:` & < ~cJ(D@ 4 n ; iO z􆘍1c6jnỮu+3(gP%Xd!{ғ JBwqxt!M4uA)ΐ;wjosXof FyrIh$I0,kŲ/oh)b---As9Fjl˙(8 Q5jD Bq%@VV4D#UUUAOOtH]Ӗ֖֖mEmEmE)jGYY444@{J{J{ t'u'u'AI$ dffBAFjtG:p6*lTB]PtCuCuCA;A;A;(g1c`~&۽vk-?J/!!!pavC!e,c?f~2+C!j~"Eh 8|8p0d-Zcum6j¥O]6?曛onQErȖdK%U5jTU8dw2cPǠt^ym?6FliҎ/bLt3c 9-sZ\r@r@rr\ɹRK3Fg!CbAHT$6-[gY;v||| D׊]׹/]5552e`333-[@!CC.`6IDATc'nTYf`פI_;xགྷkf{i>|sx92so?j 5v*[H#֩֩Aέ[iҠ000=!>!>!> }ۧ.hkkC]?s+-[,ٺg랭ޓH|$>~Ye헁guءcB~_7ƾƾƾ3}g΢ mB[P[-aPAAYfRG:B,]t҅5}I&UT Xրtt7;w23&gL% uJ]\2~?r!$i4Ile@G: z2~:u(v...}} @qGqGq: ?l?؜9ks]]]ē6m @fffff&vr;nmں5HKKq303030oooXXXf"EC ?e4iNuuu?& ut(벯ARFx_} De"hjjI3o,w0a$B5ל_t?ae. III`jejej&M000赢׊^+@HQ7d;*V*T>?34ӴO>PֻwYo~~z~z~:0 ,jG!y@!!::F.d~}}}7 '~[m%?Ze2tE\r^iJSZߩ@hG;\\\kkE3 ;Nlll...2 eʀ<Є&4趇 0˥_咬@x <Ҏ.EKZN\\\q [vl]]] \>py~S) h@ѥddd={b~1G?|8`p%N'ʿ gKїE<[>pG]JWx:lΖ?0\'(?3kkk`9r8HZ5G/}aY-Zox666r$H@7~.~~~@}S? )vW\qll_$neemBڄ v߶ݷd Es >`3~i0& L)4N;0:rtHXbb\7np_3~*Us!*V'999A7@3V3V (Qh#y~P(P(gdededeaՕUWV]|GGZH-PxUÓQOF=:s﷯(((y5jՀ'러N\=qU(7ZjuAAAxpݽw݃cyAF!$$rvx,X1uuuddd'g+x^ryىىِ+˕΃ZkA!y#Gf_/^~fejrG-wggg rJESߤI}ǒ%r~$.I\ N%sC݄ wrU+W/_# pà^^^ e^)xS:VX?OE6K}.Z׵k O#>ܞs{w9c LKIUIU8033'矜ra0zZi qJ\}4>'''8y.\&]pv':Ntuqq444ȪU5*Xݵku:t yGS#S#S#(X>| xt@] TrPA4i0l٠3t+V \Kp-5 k03g ΀QGF'Pq%Q6G;\5k-T*̈2#ʌ7[7[7[0(cPƠ̯7;$wS ›koϊʊʊgǟVZ6nٸecAۋar6lYA8";";"ǃ B*U*joC 7Tɿ M6Y:2(Ar r rS?L̙3p'‰'v! %h9Ydɓ%a0V+BԧOJOyUW=aXa퇵'۞l{MߩDx O2 0 0 FMBՌW?^FFFFFF`~1022[k[k[kЩt* əjgTUU!E1(cP X4}i:888CRrRrR2H_"_Qf=hϸq?+\WpUW;Sy7kaU/W&,j|tOM,`Bal 6m7r2r2r'O}itJw݆ wC+m[Tn8u8"""~ᒔ$2uLHRd6?l~|} xzzBEԋQPB U/@٦em ,Y޳LLL#} Z0\xm<汾ӊ*p^8444ނ{ A ]Zvi?σX$E~~~4i߹o2K+A q\X[{mpÁssK%nNr\yyyJH>2}$ w8m;6ԂtE"]Z_j}5 {2 Zgl MoS͂͂͂atqPa`쓳O> OٟB]P'gLș3vXakTkTkT)SZ4iӲ%r}S"]ÕW&_  s9>OSuD'1Ƅ zFP7n@](Rp <NYRϔϔ#G2he 8q#\uו^PAKC. y嚗-J(MUǜ888gY~&잺{ Fwm4TUUԁA6m^T0`F iz)(Qf`ږi[m>'}N>ObJV+Yd5HKHKHKe}e}e}]5њh ULVX|c W^a8={" 22޲h·o߾}ŝ;ٱٱٱ՛VoZ wwH%oh޵y]giҞкc뎭;RKm/eSxyyAwV uuOh_%H}!CEϓ:u֪[cRh۰mö ~6m">!;3;3;~iӖ-AWWo_}}hnn.ZT&y?CA>7y`KMMMO%-JZtPeU`hh6'lN؜***PPPttto B@P( 0n~:@ ?l ..U?W\uQF%AqHqHqꬨ ]vڥd2K_XN=\=\="##!KH.pYg#4ߤP?~Db5jӋE'C2kȬ!7o h߬}NWGGGãGяZkeopá*.p5s5s5XXX3G#oOߞGF OK>-$<ː-[n7R{PK-@W,UMKӢE,`nnn9n 2h }},8#qF x4G^x PURURU+ﯼJ,UTMsPӡCIC`̠A30,n=Pؼyas'={ޭye۷߾ܒܒ@XXJ+>w~`غuc($ XaF$w>7 9sV1c;K|pg###^zqkpK%9sx{鷧!d`PPP`>|\(R¥ ]fw XVVV`جYcPLQLQLL$IF  <1x2 4 MhohohoW#PQQy{B*W2@FvFvF6C3g t^PxB0aômq⩊*ǚ5k`& ++E$3-oZO5j ^{w:Ǣ.P 37܄CU>T7ovy.l6lxCB~=!]Jv>>}|xHY.eDhN"G9 sB{{;hkkSo(@ OxT2"Y>t ,2 ʥr)(f(f(fyyy/6_l7o`S)&&&ݷ_HO ߵլ*DW :vM\D 6 <2<2<x 5^s;_QN괠;;;]4J+\\\M&555 ddd@~N~N~3.aaa ϓ@z@z@zAzCzCzUEbH,`#G,s̅rw:ѡCGN.;]^zlllV$wWH9Us %< ;R%TIp;KJ.) C4 {&G,\"Qq"NH~tG`kkk H 'RaUffu⯟L3? vZ viۥmg0`Ml7YiE" OĸqgM7 ^@VF;ݗ#''.] \pLr4 m][ɭVN+>&;O,^nz0[SoAvy򠩼\>CuCxPAUacƸqիWWqPAXaE"ѧ$}bqRVPFPFP(((;CVV.ܻpBX*xU0k:g\pD&b V/ rO'\tӥNNU%&&⚋k. O^?y$LN>9:p=kFiE"?I v4n_}vxRI'a}wJ*y***;wN)I,`X8qą;w2:׹z8.ԋԋTĩSpx݇wCۨQm; ;H$*K0Xn =zݣ76mxyY}e(QVy\ 'ǜsr 86.躠pD_ xUo\qygS>ppp<3xf0ʙ3 窡Zjݪu~G~wZHTL:Xc-́m9Fߩ>>]]]8w܅s`||~Z?-L39Ws"s 0=3cǬ׿^zpvٽg³Z?kt_ΐ!9C`À 6 { [l [o59jrTiE"DQipKqKqK;8 XXXFOoS% Yf͚5 |-|-| F =;H$g`LEuZ6`#&;L@RRR~S)섻vfff fJ&.H1j\ո* ]=tೃC'zzz"2=dzV]wu_㓎O`؁as{s{s{}]H%.Jxxxϯ><۟N: t~;fw юvc+{TTTvY9Y9Y9%~Kx%| Lz>PٲeeK`5Y)HXSQQi㦍6Nl m m AZ_Z_Zw}k_[ !H;sa6mq8j~֛Zoj c돭/rNd}-Ho"Sk2d5;\oߚ醿Κ;k_38;揙?fx*U8ɜdN2[oaӎM;6Z!Bj@>}AQUQUQUGM$z *T~бcC/\ Tm6 U6TPnչUVi4y}|*l&>};4^xYe ** H$qG1UUW^AGG;TS`_o5knWj0s2iˤ- {;wM&Y 5_|Q(D3>τ>:rȡ#K[/ʿ(`/w8YpdXֳgYŚĚĚ@n= @@OaGÎ?T2Li< 0Q$3τ٧goվUVAO>!!!O<tQVVuo׽]nȹ W=QsJϕccc ʡʡʡ>*"L<e~ = ..bp^_{u'N֝ uB0F;F;F[t?BgR5K,UjUUV%h:霦se^ʽ{)0kXװ{/9w.\ i5ՐV&Ml0?n~86m:T*444׀T7nRJ4,ѰDCK%H$8 csz*AYd5,kXְ-tܲܲܲ@PPG,\"8>u||<`vۡ*.%\JlllSD"џ'^BBMQNQNQ›5oּY 7,(oۻ.;H$q%/LV^V^VdeeeӗM_UҪUIİİDXigDψ zI H$01bŌ666'~SO>:\r*{jNSH$yr: V[-[l]n/O]ѻwEFQiTH$>}!jB5ڇڇC*}U+\\\ygzgzgԖS[Nm 9^s}tmtmtm;H$5}!r9-$nLܘ-w?~eSgL`Y v2e H$'q|!"*GT 2_*"@,`P!TM`s͟}Wyyy̭3 O?Yd9lږkPXrae}H% g.88SSSq?~OO+<lݔ)TKUKUwd"L)7*7*7 <`pwjjjJ}.C١e  3ppp}=H%>S'nnnp=z޵|3O<5D1=Ydȟ?-SD/X>Sů5fkրHU%VX'LOfQ͢ZZZ9={@)?vvv ?w*!^BLmiٖfcVY=foSI3'l  ͜͜`ԸQF }ԟ1cCЈCkү O>z wY'57kn,X<εk9ׂ;oLG2_|m 0 |/DOI<».^zS8q3^x1$L<VkWkWk!fnܚN? q q qp+Vڭ4(,,3Fd,Yn-ZAJɕ~UW7z3 XE,WWWžu{YpRH=/_;ɏϏϏ#>lڳiOp,XƱL]L]L]_6pyxT}SM7`TǨQ1^J[F[F[6mHgggZVdή]n̻ ... vvvP1bHVj" U{W]5سs=;逦(ըTRd㒍K6cccxq!yx_XcŎ;***cccB )lޚ5{+Ȼɻɻni1i1i1mmm 0e2 ddd QޣG m (>wg&> > >mNԘ1Sc tvҰvJ[Ve\\\arU'WԀԀT8^x`^yuӑ#OCУGA`L=gs5j9s @ѿqIUvP;m)SjԆ;4b%VKX}/kY^/i'wߍQRGgaނv.۹ 64`CHNN)SrO? VgUUyVX^c bn艾bD]u[ͷߙw666N   FeW]Q2gf,ޛ_1b~̞=3{ =z,~CAuO!C<@nfnfn&nѺEдuM[www(DPUU\!W7o@p|SO>ԐRCJ ;6Zڴii})~0!TvRd@YS}XI'tԥԥԥ`پeu;opW4)]!|B8BBB%$H|B)A2 OOOnnA|M?);Rv@[ٷ mp[F%J9s I^&%K^}d㯃*T `X&c tNҌҌҌ #1#1# b b b@zIzIz n\quоооG=p̽2@t@t@t({+{+{CިQy kP֠A G`5^k/?^" gBi4P*V.]l;էgͼy7;s̱3!!!n_}v&oOX.,Caa!W\ _}eCy BePBm!nnnHF20ht#rt9WU*T 3F9vX0I2I2IA9rD~㑎G:R2J7tTwTwTi `L`h*/ 3h (,,DH]'}N#m>GjTjTj$$$A<[-̔̔L=<@$7 g"VUq[mapWUfCKK D\q+|ÌF3h>:"ѿx 3ìf0 jh>}S555{ջWCHlHlH,L6k]˻w-}DxVB?sOߩhhh轪ޫ὆ރ'N>.(b+2L!SFFFp'2hk֠-t=Z hV.Zh%sYgyyyP\R\R\wOkХC]:@9]t+ ܩvڝjNkkk!,(,(,TcUcUcJ$*^ @effQIF%Dߩ>ccc.]P 0,iXҰ$Y&~wNqSN ng΂͹s7#lV#FZM M M 0b8]pt,JX(qqqi(Z"D(dn"{G uuuP_ ̖-5[!6 KMM8880n\ݸS}~Y㯅Y f0&&&5\pz8;,ۮrI/'Az띯wIÓ'뗮_ΰ⃋¡r*}w8}8p4xxx5׬^׻]vzv١QQQtH ?$8u:>:>n;6ڒkKлл|$O$O$O="X KaX3=gzN}Ʒo Kl.g֣[n fs昉g"?JXLa¨Q 0bXŰS{9993VXư⊋+BFFFFFSD.b+r7n } } }T";;;v)kA$ A t=zu}VLʝ; @zGzGzGߩDYUbU&:Ntvvv6m@[{+( ʙ35g*())䆾SRӥKaLȘ1!PV[o|h|5A,G#&IM$Q( #GvJW_EA0b#C`f`f`&}{ѷd:ӊD э֍֍mmm0\ap0Yw:_%C̿1X"gEd^z1 0o8pCDśxVhM&ZЖՖՖ;;;}}lG}˧/n9@g)yʢu{u{u{qǹ^D%bF[_[_[G#[[[;S)SL29?anb+C݌w䔓SNNO>;"~AAAߕߕw*ѧu1kƬPS)6C iO~SƗ_n?et3ѿX1ۯۯ JOyRpppX&iMdIYwv5oׄu=_[wx&7v B$%%J B'vbLWOWOWpZj%d(2 }B$gѠAmmm@/zKߡDnnn'(Q,XXkUUVɯɯ %bF*\,Y@ K%;S}/^=tۭodddK/t8RRR||)---`g˝-wAAASI$mT ^̽{ >Mo4:^u]w[yn幕p.\ڹ4\r˥pE".7%%%1bVŬlu:[ Fk;&\rA\\Xb;"-- n7n݀1cǸCe]uYgYrf +~/:a>}6W>_AdPdPdՏW2L9i B B BH$i40la°4i8AQQ L1lf3AG͏ 4 A䀪!TV*+``yyy"XYY2em`ɾ}'p(P¡Xg$Q(IGM/b+n$HyRHCE3Q3Q3Ld&2TUV[9}`gg]uץpXF4 d$#)%-x b:tw=z'3q_}A4yyy迉PfRHRR_o={lw};XUlU^6m=W{m)m)m)Xox1\9=Z8G~?5eee4Xױc]T*S),GҫҫҫqsF4 #G.g]κ_|n5p(Pء0B m!bp-Z5w-$MhE-Zg}z6-[ӍەoW] "E΋͎6; Fw X/nl̬̬̬wNw-[ᾆN 8AVZuky?a;k}732ddd@Qz;6Km]tҽJE3fpvvv9X̶m1Wɯvkح!x\ ̫W7??efp%8Z(;`w僁~CW+ƂKӗ/\RW)8,vX.z]fnfnfn;whnb;X~c`;vTvvvQGMAj ,> 8t#ְnq:7un*ď%~Eg]t((H1l|24~YgŠ +-[`,Yp[NiE---vvvPyTى;G~Gm6)))g֘o7A 'pap9yâsN˝쳋Y.fn {2⿋.X5j3ДҔҔ 1aV?^{ {r 7 0.m`=Y%bF" "VܺusƆЈF4Җ86qlXjզ+6-mZ@x~%L2k\>>/7=(h}sH'tF Pxrf=p{% =I{DtKtKtKjAՂ!˒%/u'u'u_WYYY''NN,I6%m * B֢EY!A IBƮ]!AVP;vBmAȺu? L(P0A!}I% k!;););IGď!)))P`V`V`&3gV  y B{AEE寏k!},m6YۻZk}UVZ@A(|S  N䂠~~~'].AAPG,8 ΂'oAPWWI ' BJ~YoAX.x] )S0GT.* $N<[ APPP4F# GaUǏÕ+aWBR"R"R"AMMM!ZkEbTQ-azzG #PاOaA(|] τg³>^iii ’K&.({t{t{t]џ#b`V& LPB(!(N;$uO=Y D9Bߩ\YYYق0jѨE ?\ 6 6 6_I [l  [!zZ;vhmARyH!]2eAgp}nv SCN 9%w}w- ;v0YGf T˩S-W\3;OZ?~j-Cg 1t Hr#E~Dˉ-ao~?Vn.jjjK: BnV);.︼ ZjիU0>Om|2gϬ>3bʶmwcrw/ (Ux}` Ѝntm6J `t"fu E;#ETpO3KT2E2E20cfw;!**A?/^ˬWI/I/I/0nl;]YYH!:թcf $$릘bZddd7o:5tj5h^9p[ lll?lTZ֪AUKUKU L7?I<+;%?K~䂢L?x8\s-@__t ~JJJ#FFFW_~9v(Pdwewew!~^y`%]i_i_i_ )SCOOTv*;ſ \9tЕCs:tiH҅t - - -KA._44%%r.]^^^2geJ0iӰ'$s[/^l=066U*KY,U C~~mqP( 9r<EYEYEY?$B¡CDAs&LpJvJvJ'O\@A`A`A ^~z`&_| ֽ[nĿիVZޮV[A&qAܜ9qs ~C i#Gv}mW(++\\\p^ٽ2CS666hG;ځ68Lq0rx& dnd9Y(=J011m-m-m-%3Jf@|J|J| @yI_Z|ttt888^kwjgΪ(**Bfnfnf.X޲ey yU>+}VG{A-[N@ZZQajPwtu?Oo͡ %cY0ky]viۥݤZjM.U\T1l:mh>ųg;wܱs}0?ޱc{ +,r=*CDw~jSä*LnʹwbqK.PG%z@\ݸqu~o~3|sz);'";Gv lزa t|mǷbqG1WqƥCͱRaJ\u[puuru* *\pP/T/T/VխCg N:y$|znL"K/86mu3f-+ ѭG݂mj&PNVNVN͏6?,!Kؚnj=ڳ`Ata=3/-t_nu@vM5m5b+!TNR6mGh(5J,ZR<+mmP,YuYuYuyŞɌ&3̀[N<9@P]½{ BPzA`ѕEW]ÛCmݷuXi4ViVϲe? ݴݴ m~`G,+ ^>fpl^y JBݜnnnxzz]w-/_qƵ n5Vc;;(]л7lVv[ ú:+ȼe2o}JIII:ЮCaظaㆍ1'bN*Ϋ:3%Z߄Da" 揘?b:t<8PPPAwe wjX9kkk,Eihh`뷛nvXoZh=pIrIrIu7u7jwjwjw,D]u `χ2x{נԍR7J(((ѭFݠ;&]tm$[%[%[=*a-kY :TsEaAt5TXS"DԉBG}~a?|:Vr_Ͽ?>8tnZi&jWC N/zOQIIIA)I)I) }eІ6cq⎁/}HHH@%8>|L>]}Cͯ(xG3aϰa?V!B<hi͞1VG 999ۇ>\j<]w B =^;x -[8 A'Ɓ0~aLLLdd`cc _(_(_$H"GGGnnn +y:[i Șڛڛڃkkk.}   B *t+W8: iiiCU~U`ЙCg;K,Si$ G>}l iYiYiYNJMMυV Z1}kï ߜ7ghN#Q/#Wuk0v4v4vkAׂ:gdaJYgCڛ7ioo ԫWS풉no! G(((voڽiw8l͡xN|Bu^Wү_I6ژjc`vv/,B]O(`t =ZhS}z2:dt+쾲;|p0#Ï@MM 1c8Fi& '#pN9 9'r@=\=\=\>~aeʄfԚQ &Mj ~UUu-ZA wuZA<i\>$tI?H]N)R8N7:t#;'wN.ȪU# /|rpttuZA<>Qzy'[|o}2r2r2r`ӰM6 g 2dub։L_&VG`fvAvbvbv"\\\:Շ+W[׷o]H4 i̞;{( |H'© .6l؀*UHtGAA][Bn  "D@o{~[0`t肮 K'uvSNNxNxN8laɰeĖ[FJ (?(\1'C>qУs=:W_ u4u4u4PQ^E=]EGEGEGA~ ɮɮɺN)!N!~fylOz<| ohhh]HRiۋao׿۪o {10s1s1suZA q 3өqƝq?~]ש>U*vLٙW;v.ݻtW^exQS >SwB_[llŠĪ~ϡ1~#봮ӺN,iY2qmĵנ|M71iN+A}*YTd\ڹs־Z &Lt_={`fǙgv7 nߛ~o /\2p 'H\{m-]tRP]Q]Q]).竜r"kWNN69l3g4ڤk0؆c t= )DDDDc_;;;n68/q^"EEE; p豣ǎB-TNH'ÓOB҉AEIqRV!Crhhh%,mYR׳&.BBB5kzW_ACC{G5j3gH?_А!CaXaЮVZjѓ!df̐Ϋ:GYeaRI`aaYADikkJ>+}`nܨQ;wwo_hYhYh ]wt}F`x_ٜ9gao E"HQ:Gu 7BdNm!CڇgM3w]uhwݙvgkӮM6͗zO d&3ajj ޿z' O0VZjE+h,YtI%Q.A~N0*߫|VyZˏ/?8*U> H Gďwߙgn?84848.q] fϷh zꉪC$ _LLL//a} }&IIIhs9Z<3A ӄY&BS xuտ޿T Hp.\̹8z:tgELEPJTV[ul1]?~6,*䢒p3fLxzǡD J4ӯL2 ݷvZx2 E/^m-~Cu]5_gC^C:R<Ӛ0}mӷA1_| PwU{CPfPfPf"WuN9Y$4d`PTY__G+‡L0/o7nLI<Ǒab0xc(;f  k/k/kQ1D^o.px3K×/g7nP7n|x tZOCKZUmUUU\rʕJ|*e— _&o9 ΩΩκN+§D0/ю׎׎7jިy90XZii {M5;wujA> .ϻ<ZVjZjtP:(al،E_l-vǜ&)ɚɚJ+AU^Wy KlvG ~}zQGyx7.=h{ >)|Q 1LSҧOOYYYPM6erB -'{ gz*2Yeew 1LS"E,}~%JWJU%Zbk9ns ~\ 2Q?鸧㞎RJ* Lw6q^y=̬3:`ˮ]/ya慙Yg垕hA&18/_ڿ={fMO2=GYM&BN \s yJП ?Q?$qXa*W\׾tjzvYfGm`{UUU]φ $VwzwGf.37xlnϖ>[ a0a`oo$?$dtR٥Ke055w}.Y˳-֌[S׳#¿I0wkb‹ /&@-T `;) -~Yv )TکS6m~[piSq/_oC 6Ox>s8qn d&:'tӰqKKK~_PdPdP$l9ؖcp^W{O?Y[n YÍ=760o$VL(~LM3g anSykx὆saͥ5\ĵkB @o%N{/e_ʾy*ĵk2f| O}*@YeYeY%ub׉]`jhjhj=lгDDD999hUUV`\̸q1r\mVYf5^V{YefjWծS/J0.a`9`?~`tHE*kz)l4hn^yfplڱwkdҏtD0HۥvmovTQitytѺNyi9,Һޭ[{\rp%y6wܵs̜93s`˹/a,2e Zkv.\9lkֲ-GGGBVͬY5!fW~_(SL2Qg.ڟ?(|`IDATk?<˃L^3(}!PCkkkvvvN:W^=xu:u1cTGHT5*2.e\ ;7vn Sևą kE׊1#zzz;@NNN0᷈&U ck=6xt 'N:,sss0cc={\gxf ,_8v߱~puu _#KΔ);!\sP®] ;]9uhzjkpttYgCغua?{: RRRN+'q_-[6 l4W:@a0P@=+WnVABل e}7z'N: |\)D$M8pl5[ ȿ!yw]hQEa||z:o8<_ȿ/"(`Hi4b2KpYeS}B1iP}_} '''CQQO9r^a7uououoH4L4L4)QJuJ܈&SHHȿޮJ*u)m5jnj7? `ȃN 'ν:\e\>|ryH<+yHߑ5Nk iii:qujPũTqWWWމމޠQŨb׋_R:tLZgO0y{Jd`j]Yk5.e]ʺ[Vx||u"pYO~;v={,X=C w~g8+ܻr08fpc}5TʩS V~ە.] `kրpKW/z6]L ''4k5k5kEˋN0q2q2q?Zk[k[kaW\K/m:\FJt+ ڔkS ת_~Pw~:\vsavv$IX]v.(j+j+j 5jNJ'\3fr lmm{a>CP rF4 =(zD^rKx_Կc1阮+ Ŀ,<,<,>>`ll4U\s̻3μ 1110/}^tH I I XXX@GGww7oB_H;v$d}uנz߃Cvɘ'cW%^xUrn8:::g{;fw?WE ')SܡO/_CCCuJYfd0+bVĬȮ]1"}딂˝;+wOCCC LY?e\׹s]yd摙G N)(`yփ~~~7ho^שX&ca#4ld/___|}S # g.#5#5#5 XE"Vש:cPAMoZ~]_w}]8v0`hkk: 2g.CF`fofofhy|Q:Q>s+++`pj]>4VY 'Xr7777~qc2#dr2f1n8)G!|Z,d!9PRm趡]>Tххpb艡' F' @āpYvYvY{Ao=t^Ԉ#ϔ+JP`APRRu*C );Sv•W^)[]vfvfv&A173%ՖjKAm6QB+ħArrr7npi{^IW?>heʠVz+(O'sL0 U*H@6S6S6Sס] )-)-) L:t0T U~}U`kekyFף>}~zԻ#8*TtJЕ+WV[\m Ǧzl*Ll9Ėő/|qKKK\6lp–- [ ~|g!ohмu$HȬY1"dxexexA&E{)RAڃi ##2wd999999P +@)͔xq# SӧOoe˼ڣk ]^wyu=z^ vG펂F7^o yPA Wү_l6-dggC^y!d~~~ Pu: ARKjI  +<dI&p"$ @pV8a`R`8pt016161f _ `wύvp Px(<ԥC0ALf2hhh@s!9 9 9lSlSlSTTT ( ( (f͚FW]i4(++Tif +3g~WFVFC&x@だlll ,,,PUUY,CZZZPXJa~Nt+V 7o AAA Aȟ?;6BɬY'!mDۈ AV=>{<łBO"""0ed8=vzG8pw:.U]C?~AI **?Sm6f{nUѫ"f[mNss ́ppp{0bŤ XXZsÐ}#F x7ݸw 33B-ocƾ0hhР!mO]Jvz'>}h,,, {&{&{I r!TSUSUS!si̥u#F 58k0O6{m3S)"K knܬ\\\aaa٭[g(W\rq`kgkgkrgYד3]]] 3]ft-^[@m9/^=8stF`[Ͷm_ߑ#Gq+>:,tXKS.f盝ov[:o0hɠ%aaagásR΁g6nyLLLbŮ wuJ-[(5ԸRqS)@n![8WIklll OxDDD@'!$$/_ v'N؝J*UT <==999]]]fG׉S)|||\9h5mmm ##˲˲@5 000N~Cz ͞7{9eee*hL4&PʕrN?}q'O(xxx,T* 'IϓD)N:kڻk⻋.㗃eee$TNX9Zj1((1ļ| _O~_ {i2wl(o jP`)rss!Or>{cX˓.O< U7UTSex.][vo kWzk^bbb)|3Qa=ܠܠ П?M(D(ӣL2= tJҐ,Y30g|hohohoEEEx6lk֯ e,c ' }\>3|fLx7w#!uP~%*Uv&4Yiggg!uF"cEƊ (Xα#|}__fgBʈ+!cs9VW^ x5ӻR)E6?;wvop5u5u5;;ٻol.\B2C2C2O.a]ºi6y]Pŷo_(^xAII A7d2_/b)`:t頢uZm}QHY eJ{* nQF X~qExVYgXa0 3]׉;***(_`/l" ޥ{] p}}gMM45bŜ9hhh=/L0ꔮSNi0v ca G'4EΥ ideeeeeA!-- rnȹ7pcٗ/{vY]]]AAAޚ5{+ 4l6l!!!p횷kg]~*'UNmM6 Fy~yz}Iܓ'qt-O[:nu UlVG=C >>> /ݿtM?~4֔ZSjMu&֙X?FןF& l;v[l&yMS&OW<_|E8#QTFQвl˲-˂7XQ(`E(  P=S=S=P:Eɬe2kp}p===&L6Kьf;L6L6 -SL]a~lYe͖RRR%;\3HU*R -Z H>SlL1`nbš K0i '111{.Bkxl8';';'CL~1˴˴@TB1cD&)Oy 꼪l-[4&jrVڭ[ f6utf XPTڜnsih|7I'p8pXʳ+˯˯ɉ&'.] z0}L#M#M#!mv춿a>'I=мy 5kfW*JAi4VHeXXX h@_ciğ 8)FFFPǻwo&&&[nU dؓA3f̈́UTPݝݝu[hnܢ9d576dJ)RlF ((4kG5ЉNt*?WtDՓY,@<ҒmmmSE~ *H)R HݥRwuuuV[Am`@r+@Aгг|FaT'pÐv0E΋*jUԪ(hti>0ِfC}O=O<$ĂL1b2tmN7>uSϜs!88455ݾ/DTQ*86ؠc#G^ŨQ#H5+d̨Q,}{K ˛.v5jUR KK^6[Hm<9,Ґq"D ?~ uNB #ĠtttӢ列69mr+x" ::<<^{Cn=!vJ)6mB[HR'Ei} >|rR9+|V,0119s;A:$A} /3/3/cqQ;?=gL0?UOOOlx݆w9ss/3,YTXo~...`hhXݒ'K,yϦ=l Z.   t=OO?o7v0ߏ/?߮;t1bzF >|TEMEMEM033׃i#F)S={fff`ff)!)!)!`0`|̳̳̃Z[ |iOi;v-,۶l۲mСA@5N8 kצo 5 1hӳgO]=k5Ӛi$$$ǯ===i}k¸ sdɢ?L`U۪Um]8w1h4f3777b! /<?AM&8PPPwwwdd]({d:u *T6 VFYy%y%y%k0!dxgxgx&$D%D%DA VvY fff0ܼrAW *wܩ?{".̙B'~AE?ϟ?'X b1 (/'^ s΍;7wz:sY粠u0l43XmhC!g{`e畝WvRc `5ր;CH!O\b‹SSS(lh435353}7YgힵzO=t?~>b|9s.OZ?iSO|ye~(CC/^Jj%drTΩS9xzݧwijPXXZj]5x] q O f$Il0hdcѸnvȈ̈̈7O;; ,hŔ5\ka]ںui`jj VfVfVfpwCwA};<\э^x}5~r\w-fffc>s,vY*:333u؏+Ⱦ}% dKeKeKzYdUrYe!zTQS@,K%s`5jsss;JWqO=g\ϸq|||viG /^m6PHSfff{_#o;%(T2}WT3fRMl;v2())d.KﵣDddd_emSa \r>RkW u8/ӾL2Pʭ[)7жҶҶ:ґ?OӒaf7aՏW?Qef@^(/)Mi~~ďxۇlll{ߡ/7^n 6|pr˹/˳/Ͼ3μ: ʾ.k;O<G0FO=a4}ۈk"E&M:::&q;vyYga]SwMĴĴ4777OHHˀ؀؀XXvye)>>>ە!C5k::EuZ?{yCv!Btrɐhhh!=CzדCuu5dffB2$i+V.I]@2E,!?:?:?V[X*Tb)Hޒ%y J $IxlyR=S=S=!R}YAuu5/_<j 5%%%\\\č7|\9[slq6mV۬ =(=(=f;v v.]zAۙ!dɔP{=nH1M1M1SYNA{{;XXXEEoOߞBCCa}!!!(1Ĥ***e͗5_VPm(((3o&_<|[mp%_S?~ (N+N+N';0(Zv@zQأGa __חCCXEf2<+xi4菝Y&MxÆo8 SSS`Q#N}'}'}'~\q!دcw>|@W]͡Ftѐs=zuq AlZȪ#̡C3B m m -xxx@i <j5T4hRfΰa q:u)SQϣGrmi@Z#-GZ7|||> 0*,XI&==\O ZRuI%`lblbl_ 2/2/2Z,j"s΁: dXɰ0ঃ yyyСb*III"dnܖ :0èz:pY;FwS;w& hhh@ڽ{i@-EúFk/4R?JTTO۟ r6&nr_EA#GHҐGC y$IW2d^x6$;3̸3ԪI&Hҝwߙ/I gnqF;'IGv$%Uɪ|5_H000$ihhHҋI/&$IFuh$/~⒔<}Z5:X#I:ؖc[$).2.2.R{$-6[lL&YLd!I Z'u:C7ho I>}$ejZ&IcǦ^r9/[x$:W5kɹ%=JzT*J%1;bvLMM *Jϭ[C&W^=z(lm&?oWidH:;u6Κ5; Nj'...@jHjHj L6.J] NNNKR.I0]0o`? тc:u`Ygg.{ Tm VsL15ǀE预5֬Z mIے۵n׺4kܬqƿ$$$#XvfٙegZk rpz?^QL^7^t#k\׸_JG84fӛK~H\#k׺Ns ?>xLLLF,vWd^QQQR)RJ%+8VZyz띯!""zi=y͛7컳BfLfLf o 90^{}AVVVVVZtmѵEWp+Vڭ4ԦSNufW(ӧL2}jl Y*EgEgEg=Cpvsw݅vsVkNk:e2XQ Ki'N@XzXzX:\/~W/_$I֓u3fPovfyyyG|8qb[bl%ߠ~ 53jfv5U4U4U nԻyyy -[e[e[e[HuHuHuCzwЇ>`jj zj=y)R LU* l5 ǬY+ZN__R˦M- 7̮]7G_)Sn܆A 㷏>[o+W,@e>}Š +*E\aDn{OUMhBPQQs s s'''U3&({*{*{_$ ]w%mKڂ[m F-]0ۏ}O=oxaxxx'v/< y0"G,r~pa#QzDPv`فe~v`cc23Lף@r!qkĭ6m\x*U(c1rP Q Q 6C妕Vn UnWt-ZRRRt=(`/d~98q<潙f0t5t5tu:GQQQ}>|y o^yZDj!!!2VAZZ5(k.\4K\,qlll@ QPQ(y7y7y7ԇN"(//ԇ .[շo!jRAtv vQE;+vV,HOOԇ5WjwhhhL2M4,S)lD~Q1_| 36sv\\\>SjCQQ|TQM z#FWWW0dxdxdx@ww7}A___&sM+7+7+7lnܲ962md 3\; wPPP0jհ+?={ 2L+ӂ)ȿ# O,< ڶڶڶٯٯ .###777jjj'dddCCCJ=z2g<*;uՉD?\8XXX5kCߥK(ѳD=\e2Wqqq z랸CEN6;mpppxẇ~ǚ'N3L3L3 `НCwsi<zٮg;035353w W!H֑#iiii9i9i9+WB/P=R=R=lPnP`\`\` ~[-Z@JZI W?k']  31c84?*zUV&Y9rf+W`jj fififi`dɦVF77x]8~Ӯr*6j̪7ެzN%Jδi;aVNOC[lԳyyyGОXz m6$T KR:0a W|PB 2 IaR+k#k#k`;@vSvSvd2W+d29e +%+%+x&#aGŽ­ . {]qysx|Ƿᇖ?%X߱c}d %Pb q QM...`aa'O:O~<9z}pkh{퉶']vڵ#g#g#ޟ  ɨQy3/g^Gr\-$)֯Zú몮  >)))r(s%I'0u4Wrq/B 5*u:R Upjǩv懚j s6̅ŻZ zw _8~UU9W\|κN%Y'9s0㣏0Q(`"Expx#DGDGDU?xpdGƃooo{TQGooo5Rse2w]&N! TY,UF r&aH^N'_o*2lRVNY .x>|uVq&!ggg9sztx ubro0!{x{ (Wb ^^^PCee82>Q8s.\ :u`;( dZgZgZ:ݧu_Wٛfo ._4h >; =4Z. EƼyaVY=g +p~˾_:+On>pJ}J}J ǚkz)5kZ޻{o(((uZAw#0oa4h;菉bŴiEk LЃosp%Jpķ'=`D>oLG읰w p#FtϯXֵkYW>ڶk۠嚖kZaڇ tV>l kϯ=6m#GN*;K9d&^{[/n"5]kק_uZAS¿ꯂ Mū^ i}u_SS8VYg .ZP.A+++LX0`4A -[tIvp7[ny/^8J(]ttV> LW#O< qjՆCv 1]]]tKJIJIJ2X>e} t`[Mn% Sl_پ~C*ͳg5ς36éb*52bżyy544]m7(}} (7Lq2E׳+6}]>oe$I!r_ ܇#<8ھk.XUlUUŠϻ?NΝ;i4E())|ZRki;;섯2%5KjʭʭʭUA/ 5IL/|v 5tPxtG7iӂE_~vgǻ^IW;Oæ[nmp=kXmh[nͺ56mn\zz驧R3K M0A&6LlS\Lqn: Moz$c~9HX"r\-{ݾwzwݩw'[-={ڙ3ig5A@0A,Y4hSM7e(QУ,[4hI$m?&w?ץ[X ^y`mm ;w8, KDtJP* h A X>6uaSh:鄦E{'攛Sn~LI2-r[$8aq׷WTTM7].&_LYᗈ&|PW4^ ;%wJ]vu U:VX#N8/T_r% VD\ Ùd&xxxAEUZMMM u=+ qQ&II%|KfÛ of͒%2@ @@@s'r|!`ll PXcAr5/U:UTT|PA`ĠA]^_" QҶԶԶfTSaN@)m6m)SF gSϦ W&9Lr[[p +A|||2hjj&ui4Jc]>v9 1Ɛ-n! |w`ǩh޹޹޹`ccmmmPΰa9C(YdtV(`G|,|,|,`ӵO>mYg8v]uiլujAQ{s7W%*SSSbbbbm(VtUp>u^B0wW?:TU GGG6k4ѸF@)EԍSAj%ZAcf̀}c%!N! y;v@dȊº **LcӠ h ,X86n;v1b0LA#Q10b (lQ5.k`VY f7 !RH&4A%q&|- [.\2w1b{\jTF *C [VB 5/jSں E ?PPPAyS d YIYIYIXklHRTZ6k٬%p3Ax(`G%}fnԺe,{QEqsִYfMJ[М4 L$)I PSSE΋ c1ԳgQdeea]ujrelؖ su=yL<_|u vgZҒ7ހ^Oz=azz4]4]4]͂6 ,$$$]ϊ |D>*OB> U*sZ'N* +*ZSkkk=E\(|rMsMsMM*7/^^kRI&wk]c8[÷TAYϋ(`G!olؾ***J2sԸSN;0&kL֘,8TPC5ZZZ]ϖ |D> b + + +0h>|T X-ƿf8vcW@ ^H/t=kiL(Hz" JW(]tPf*3N_aʉ+'N_;} xN)&Qޛ{v=]J*=&dMȚgz]w54_j| CRfRfR&={Hש]Le7nR|S|S|uxN*ܭp]\irɕb.SwN9MMbEF -/[^Zmkjj‰'N:4ܞ~{poŽV@Xza k|pY{w@wLEZr\.SJL)1Eשrm,rn9Zk}a[mŷU^{.Nr; " " "~}i#F,e%Zʉ+'ޯ gs?~ 3C!$Kޗ-[,=: H9r6,4n<dddt)nSܦ8T8\pðuNWH>|0 TQ9llluihh@ʚ5)k '8'8'fz FQRT*rouuuP{=`oonTQۘۘۀFn#y㷼-DVYvn۹m6hֿYf7JƮ]C&jƏ?!GCBg#Fd˒-Keee.8E;E;EP)))!sCP|Z5PhдӴӴ9/r^^kz!QGP[[  ^#0λw9*c~f;v-ܹsΝ;{o(;säjMp:G_'N~ TĩSpGA';O<4oqʇ%QK_^ma6m$$$/n㻍!fx -Z.|kqB &81S^{<*yT(83/aUW݆mFki%^ٓ'gÜsN9[o:W \VXZab6lt&|Nj'fPֳgYO]\NqӃOO?6TPeC(**uʟ3lv2Cy%畜Ci}Rש9ŷR| ;s̱o_ʨQ+ //(dR&Aljljl*)qĝ,Yl3hɃ& iKҖ-y;vmH2(e7Q FAY!U«Wa&dBb`b`b db^gggt-Z5H["m$uIR)%ŧŧC~t~t~4///7߼M&ꍮ7h*T& DGGCN9!wTQ10c`@HHHBBBttt+Wfcw1 ;w" 3@/\/\/\שyG8iobbb`K/`KŐaaa)))0`Cmemem%+WL?xcM@Sz7n݄d$`dZfiYWM&UaF~7;0J0J0JY ӡN:444W,Yֳ,tRwRwRIE&a ޠ\\\.÷@S!BDGGCɋ!w}auVCGu}ѪѪѠwW]V{OԧM&HA}K/YzZiT ,hf;v1ƔSG6>"}D:5rk>xc]ϒG`hт&M|(=ҟZm'N맮T7U7U7!`RIz*TKoA?A?A?2L'''zϕ(`%Zjj;0w`@(Q£SfVaRI Np.]h ˒%/ls2,޻x0EEEgG\S%B ᗈ&|P-[6n6n6n`4h'x$$$F5g(ݯt`ws=N) QJoo/8UrT U:ՇϨQ5j0T9T9T _ban~(P!]u1cJǔX)V_h(`ALL RSSa@NQ.V.V.0ccc`n_WNY$_j~PPP7p|v۱x㝏w›7o!qh Cxo-hii*ԫRp/C̸q1RHl(`A "E knܮS}SSS4kڬix2' òeC !*!*! }=q_v\reXcUSCBnbm0LrϽ{n/g䋒/J‚! ,y8¿L0აy'NF|:2,,,˯Krߗp;._1l_پK'OQpSN=; 2gn999=={zt)Sn`|ipPݡ:T_y|`97&V>ˇ׷^z} N:axt{ @`z[;o}}}~cV"E-&B΅ 9b:u\:սW^݃dhl9TOWv_ S{O=7TTTf˛-o9!9!9!N)|DtJP{]4`zXe:6pi!qVY0/`^< uJs# S8u: K*,FFFN%:ôO;_ys͙7tR\&:Xlll0niX\222I'tL?l{  @ Bp-RšݵC!h,$Jvw~nox|[.-gNә9sƪЪ ΦN) Ĥ ՅB5yyySI~+֫WØ c.K6yyAdzdzHO"0I+WƯ@uNuNuԩ$bχ>sX۱#,踠ゎO^:F*`1ELS@LU:R)y/o~yƵk-|ܬvjN)T&_AfffN%P222PCmmm,lp r.] 9xa0hfkk@ N$&>>>ˠlllbT?PK%ԂfunFr  C=8oC__vvvzo$ILkkk@MMԩ$:ꔫS&/l28܋s/`jj c񇩾S}«SN:eT$&UpfMPPPcccS*mv)gp{EAw[lNٜ_?;P;0N/XHLbRc4|||Lixex{{3ujB*`ҟ֟֟Up\MFWIZ! 3<N?=_>RAǁ缩BbjRkQ+jEH*$Y, 84ph}V_Dh8l8l8 ?ʦ I1c M+0 !CB8z艣'lG<7:=^^^KO,=c&8f"p{ зַַCz% 3)3)3 <<<ܬ8M& sߣߣ ((UŪbXb=,eoޖ /g΂F6A1D1D1{{{ L`GCzL"Bf!K/yF}6QA7Y7Y7sϙ>m¶ &Ĥ9f07cn\i5Od$e$e$ATQ-s/Zh@յUV] kܮ1ut\nu ...5kVVV Äa   |yHMM BWq_}I& >>>0k>|.ՕՕAT:}/*f1f1f1vؙzT|RԱǚkC</!bw׋ +&+&+XbMڛ7in/Au׭_9~Be0fY`===!="="=;wU;T;;;@%喔[UUU޻?t QbRfW̮]!!?pJH+ 6p|ddd2a˄-gn6æƛoj mj٦&8ʆ+BҀK ]bm?[z~⚋k.^{} )^S{ TU> PT* .vBiLcSG(T*j ,׾}]B-jQ7'N3!)4)4)nnnDO#:2 n~ahnhnhnmzw4zIYljtuu^{ElL٘͂͂NjPSG===.ֻX.]Wî] Cn% MH;N?ϥ '<3Ƚ{#emuuuӞp~GbNMSMSMS?+~lr&pr}'AG!IK#G]p2W@'O%K>o'g3!dbĐ0-jZԴ(84CS!PT)Skr /7\*\4PF(%J.~]. _,bL>ip畞Wzⷓ Ĥ,C-C-Cp@PpU᪢WWWabbſVϬY=VV[Y ^}[xxᭇ`mڜ9>-}Z4H4z]/Xm|9\-ZpZVۙ3mg'8p>|[5jG9͑oG} 4 o"o"oUͫ w]|7d*U_~иi4n +_000 6PnC9r+!_J~?m~8_|!z޸={of.ԘWc^y(tQPhwݩv{ Xtf _i|wy{o=۸o㾍j2+Hڜ9iwREEEv*T >˽{-G+Voooٝgw'pJؖ-a w߱>ԯYfiuuuFh\GGGvSnVSϧO==c{ 4if O?",}!B899Yvg /+w5xWB /TPoZipI$v'B5u5u55tmVY]ϻw=m6l4|B?yɽ{ n,[÷o雧ozyImۮ$ž(rl.\ZZZ0Y΅ _0+0IVVV"9r Ox4>VRR111 K fB$! 2a@DC1o@m dXdXdXKA UثWW-Z\ ^ /ߋAA/_48%K< Xpb pǹ6یnUޫW?OF1Q 30c:iD BGEj 5x\q!bċ>> < O7<y.#F9b$Xϰa=㿷cggoy!: >SdZVs0.]0 ͅp;&4vXȏȏ3ڟ$NM8ַYf}HR-lٞ&VXybe_~ 4Yd}Hٛ7e^}=X h4l (.(.(.nxaaaPXDa X2u%Sp |WPNh;Xٱ#z064646DĄmmmDqx-gv})횴kҮ(Xx`၅:'uNQTOSOSOE,imڦŤI{(VVVbKK(&6IlD6m,b"klilil)?a~Q̹s?(bRfRfR(D1uע0yaBQL L L Em6R)iń bcDQwVwVwV&-LZ(Im$ŜM9r6WbOEѸڸڸZ+++D1sa̅~~~%Ij&8i'Q ՄjB5>\s(ۺn뺢+uW.QԽֽֽEcccQ4*JR c c cEјhL4&aaa(I-(n(jjjbʸq)DpXa _~(՞՞Պ/_|KQ\}EQ3[3[3[Zw(J2KuFEBBBQԫ*Ju t t DbaŠ(n[qʫ+DE[%/kkkEG~.+ W(|q(.REB߃>N}ZGd!w=|ׇ$& V+A]] >58k07333+@s\p;E/z~(Q=pV8+}ok1d5j0IL*][tm }| )NMzVzx݇wP>|~|@ oW8"@:]}BԻw[OPVZ5jvkۭm z3 ؼyc]>vX+làɃ& 5׸_>6`ľNwEX__>}rccc5kj 1z/^*t-Qza j, =(⛋p鷧Bzի'oy2RK.?^LL e.ÙgJ) &aSM sv>~^ӽ{MMћ7aaaHLbR?[qRۥ6$4Nh@n ^e{U'5Nj4E" F. -[%\f3P+ 5xXyXyXv!lG؎ ?&?&?V2e96 ˒eɲ@ rAdM6FS):(((|||dq8--- dBePPTT>}@!55oݿuVo_џ +V* d2L&f;ՕՕJh(^{H*T,ĝ;w?@SSdggăM((ͨ5EME*`S}N!sz{%UWLLL ...> [V kU֪UB?-ٝtC! E,1;`O?wWO<)z͊%J& I] UJP]~tIu BovXE].@*5IMkk +&SON&a 7śoR oVZQjE)p\q[v~ ))3=0GS_E Gcc`?y<?='s ##ZՊV[osV*Ux-m6@۪۪ۿ]Y_Y_Y_044`xUUWAu:A W_9|0c܏!f"lu:[ttt@[-\\\w[0o!h{k{k{Cܕ+Y/^}ûFkfk![B~AAA @S:PǫW+ö>㐯W+@NT'B/Ey>>> yv*ZjMSBSBSh%)S@ɧ%| ]]];wT0a>|())aPB ?Pfśo,^/7/) / @y> ,PTT :"t-~0渚jBIyIyI9m6r_)D_}]wuU07h94uhE^ {RK/Uk|VJ R?;~vlHؐ!atxYge:nݢ.^<<}mnݦ ׵k_ׄ)(&K|OVX}`uQ_'׾(зoC_Q|(}JEAރyhΣ9bfFfFfFQ{׺\r( 4Kwe%9999998qlQ|鑓(OL>[[[ Q|(NݝԣQ+~o|{FLJW9s=fכ]pRwK/j 7ݑݑ1|8;w@SN;%@ @ WN''h%=R{B_ѾѾѾp]8x4h V#+?r5,W>)p w w IIIe@*P;GK%777#G2@t- rt& iJӔ 7 r-[>}~_AoSyep?t&( 3洚jN+n^yMryH>niiiѰΪ:V @LW+!;<;<;T^*/8vs Fg#x1 O:t> V3fZ+K+K+K(vةb@ Tʨ24W+A(w;lll4m n7(]تUa+йu5jZ#OOOB~>} <</N_ ov?$Nޝ2:.amܴnZ7-TJX){Z%j:pW| kp_eeeŋE6`ohF^ {-5,j:J([wVVVbbb-X j=6pd YJK444VVVppp S0Ŷ%K´sM;iii0ܺsB 68+.K*`kJ•+ N2b pʧ+7s}:[,Lj?tGSSILz-Ë^|+7uOGa퓵O>GðE [}yطž5uZ?4Ceeen^9\ztѥGЇ>1ua˯/6660wܡs[[G?t&[V[ounM5DȪU#K111Y2ԴiSb pILK:-UϪU= ڗ/ v^ya't+]Mo,]Vvcʎ); ^l財ˠ^Bz < LV$K)))qL1__JoI$6|mZ63lf&&&Üsv Y BICK$T$k5֨[.VqZ~:ϰааaff޿z͌of|iiiN+2I֔.㻌V.[oM㓓Zmh_ |nm6cǪGGG:DI$UW*쯲ccc`\qƵpB8aꔦ k]ֺu~~~dΓ9OTXRaN)o$( /Fh袡???B (kQۣGAzw`ށ`ӪUOSH~I>;3z+o2&`KS *T0<@OVZkeU_r4 j4d>}fɇIZluI + p@A_kͯ5pps͍77!<btm}fqfpx*i0xiLV"sHL{гC=akͭ5քSכ:NWUWUW;@?Xzկs{0%vKLV"sI$¼¼.O(|v^yqEQؤbMDK]w߉.IKjcZQDQk}ޫޫ+{$I޽{[/nVQ4 :GK"Hg`OAc4pyEY;g?ퟯz*xM7]~G?l4h ޯ™gU2dVe6lzSOi?=4l` Sʔ2Dq *~U*X`ႅ j]vc1ǘc41 x/Bޅ y]]])uSԅi-F6pdCr\!f]~vyإb`J$I>)%{Y',,\Xn?EK-nnnܸp h}{?q;v퀅UV]X%K~^ /!밯þ~ &M.L}$I>)2jkka77߄E3X4ʩʩʩ~%KtQ(w ko/fff놛(I$ '| ^/(޻x⽋z](ZDXDXDbp\p\pܯs){Qt\Ϲ^d_Fn#-[bTQM}4$u* E"6 luvzWkX__g&QߣGA~E~E~deeaETTTOOOm~|iM.5 8pj-RpzD !Pc1;6lzݬw333p|Ĝ9sϫ><YRfIPE^E^Ev_}m5(**z/%' L"dddrJ)---'$O(Nh$4֍[7nm{{{ bL7?4C" ]ssߧO}BN ho7".O$07}n9tyko.Ojւ+AWqqqSK$lRH~:ԡK-Z 3l0ؾwϾ>'m6uxI& Eطlcddd/Ml4,j`ll *۫,ȣhSD I$﮿#J.պToWzkMW]w[o徕`eee꽑H&!!!ãGa~ǯoO>y:\f}^{ye0111^I$oRH<- [*09&M W:_u={2dwR"{ DYYYCIǡr*xk50䮓\{m! ɆdSD"0?OOO!!!p}o /)ln { CCCSD 0?^5*ME6?]rI+ v^ {&MH~xN<'W^zu|=B.qx:uzkXea]@4Es跬߲~@1N1N1GE"Hg`/( 'O>>>^0崗^ƒj? vo۽m7)SXGE"HL";wDq8Z ;Xomm-L)>cWRuK-UAZZH &ȶm#B U>]Kgz>+|V7Go]G]G]GS%Ĵ&#JN;Ax&<9< L7n>"""aô 6L<<|||S3J(11_;wjH|=:FFF@aJ jPԠA:-tZ40L3L3L3IL"yO܈sԡRJDDDSu.'\N-%6JlkVYfř:$NM87Yd}Hٛ7eooGl555T~*?\p!>n066[]ou&M4yd777MAAA>[),daѥ;hhhННН_btC!`H4$dӒMK6gJl/_78@7W7W7߆  )))Ȼw#h׮]v`FQiqMZ{kϻ5L6L6LxxxT2 r yyy08 N {=A<"1kH#ԃבVH[ynA7oW_5uL6ڔkؒcKw+߭|=Y"e7nf?V+AEEtɺd]2/lWڮ] o߿}?u~^x9(m^ڼ9ԋ[/<==!a{7oZߟ+< jvEٺf뚭*UC%!tv٠{=zԣ֢h >Z(8TtPUnVYeӻ'lq,&XLC;.s>}l VVVO@+M4^zUAmm-?DL-Z,[  VXaePL\K-},vٷ˾cmvM-///#x{{{{{í[2ָָ/vqppp///())jjjGᗖ+MiJ"ReTPQQ7 U~J~J~ doeoeo'N8@&d$nnnbbb/_$HE{E{E{!OSC,M&eeepttmۼP\(.2 P(G9ʙz:D}cq-F[7SO&x d2,^xV-ZZ5S|9r Մrꎂrrr0}wDI{툈+x5b%/l~%XJTB K]__RF)!CPiJS+MZVo 8ǁB )|/G3 (1J2&me+[!6/6/6<{oP۽{mn㻍* /_$?0uJ}FT`}zHtNtNtݞv{ M[[[k!o^޼V&_2%hiiAޠAy4_},XY454545 tNw2dI4:r]B/_VVVϖϖφ7޼z /ϳSGNkH`W_AAnAnA.888K*snҹI&Ιz:R|!Wj^cT>000VVVNk¢΋:/ I7n&4aa cK}.8[l (ܦrKŗ/mmm6:(ϙ3@1P 888W?0fff{EE$''C-ZAgYCRIA}D}D}wAxM7@q8B@N BV oaBss3D*#J6m]jwpqwīWE-i[Ҷ6`~X޶my[ /&b )dޛl=4`ҀI5kN)))7VXEw'NRcJ)5˳ƚk³7<{럭Yl?30'.X|b E"D}J,,[Tn=6)S ``v:$''Cf5 /4Q|l&%,NX:sԩLǼySu} }Uj_ N.8 uFW Q Q ѧG}Vy\ 93ё|lKOދ{/DMƷf|Sx+lW4xOc%%% &T>SMR 䓶$vIXp3ϠWx^NWWW]¥Ǘ_z PI[I[IkꔒOt QI)=Rz@7ޔzcT/E"T =< k* ;,vXOn?#zZi 䓤Q}@]]?7nr[-tԭSNN?vXVbY {M?(FAiA\\ԡ$T$$bbbj}`gcgcgcTmpڧOm :]nFSnݒv/ Ob>3g@i!002d86m[0l0l0li;vB#G111iӞCIA Մ(sHk!J>I!!! / y@>>>VZ]huTUUa㺍6444hf+|1 B_{e?8uSG---BBBazz>?σs!G\`^`^`^SŔ/fIW_ gJ)}4<΃;`b2PRRނ|,,-,->·]Hg`OR v9`}}SBԦMSahА!;6ۜnƝƝƝ{&p r r Vl 11괨ӢN 7o<Pf@9sFgm۲7_3g}vZTiQE8q#\ν{9"~1GSߟt&$^n/6 N`QE 9)XS455ݡ㚎k:((٨0 o.v 'x0nl;k5e{e{e{ W^{cN :PRR1cÍ7^x^zex0V5V5Vҕ/ LIx<9899|Bo_ŏ'Ϟ<{,<`y ?~0lԨQSjnc/@~Ӫ-iIKs9`wA{;Ommm*3I>I2e\;v:?_تUca 'lf.;X:oTTT@6\6\6nVOHHHiyAJFJFJF\WUm)R^/{i7n݀T0?b~Ziox킷 /$/$/oԣ'0'XXX 222eN={ L4eӔMpgÆcm8o4hwhʡLn3TN*'uFQ#>;XUfU{z5լABF k/nve4:|}}mۤIAan|0i%'%^Nz0nܸqc= _UI`I%TK ,1Ft N)XIg`OJ~R`o7؃_pJ/r_S/M4d|}dڒiKAYMR 䓢NV'AaU؂SI\vv SN98 b m,Ni::c#0'E]L]L] Ai4S:'v _Oz`w9;k tӦN)XH$<'{O÷,K$P].Mi6Axb`ܙqgƝ=<{:T30'ER*0bVŬ :SSSI' 58R,4_h^.yST$̴̴4zi%(&+&+&:QRRaщE't)%5I>)Ye{6l0F#1u*opR8){5ׄX__/׿\)%I>)#G-v: pp avpsρJ,ҳONST`;v0S|K\4! -V[Y+g9uō/nrrrCK(g<eeeP-Q-QI7qV 9Ls7NH:ox7w#I%<)ȎˎˎCI*=Z{rM,7v;`78/ M#F4CCC666=\sڵlײ]Kp>|O N'FQhh4 h#?qqq1XW+^AAAUUU,,,TUUABBe*>>I> 餓$80Џ~3u8ɟM1_1_1*S@%c%c%#~mp䑓GN7|aaa~C?h;!Z|j)Sl'HY{Gq:Vu x 4Jm(h ̠̠ ?~0 N :0K/ARR k%N~bbb̐2C u,Axu{!!!PnꂪE"_m6D߅* U@ڬYi666jmVPSS444PQQO_Icۏm?=徇6im@\n\n\.F!FF|=zuefeŲbYpz vQƣG\nr?q}Zzh顥ֳ[n___.5]jԄ5;\Zvoٽew8w>|l龥pնWB nZ 0! $$$555GE*aU [=z ,Yֳ{}'wZZZ]wDJTYf͎",'vYbg Hz0!xn>B666Bes\[ԍ; 㔨K%`iإ lγNVW?!Յ.t.]\yc捙篝vvwt}GC&6ȿ_k&XNj9d>ϟӠAa8|K/A-{3_K,A8*L_7+ Ќf4_n@!PhG;nJ(5owM(үW77on޼^; a0$v Zʵk^{~lcBeZ{8SwO=._=c{w`|.sce=Vnnn [n? =K,ݳ4hhhVhm6ZRRR$$$6m`Rۥ`]p]u--m[TTTtuJׁC&<ATT,Zl eXuYeNn;򺧺ԈS#ҫJs<Y7nd],L& `0WJ ͅBsyft  X[[ðö`zb} ݕ rmrmrmS[Om6 l3kk{+VZ>l3УB =n~`Ko3f4|Y˒_ewewewp:iP{z鵧CKK ԬPB Pipî]QZWk]*o Xc ՗V_Z})<xF 5d(쓲O%%%^{]o}ov5kׄO>]vu066{yCUWU^["DlZjÀ3} ՅB5<x:&]qGPxⵊC-)Svp/^ܽ8|;9wrE?wjܩ9 {* =z|$L2( .* ,'YNuWg\rKWx,Y0ьW^zU ;܇6۸ v,Pf(3|ǷoBCCXv`فa0dJĕ+0T8$Aa*Un`[: ҾK. bvWRJe*-2W?%D'ŦM PTTf6j=hMmjLcL+')')' ..\ 666@zK@@콠lf̲Wʯ_)xAAiSځPB(!dȐyyys9œ0?Ip~+ `ooϙQG2RV[U*s0;cv 8%9%9%wC h rw.ibĦ TpT8* ..*\2g3™FpN8wf߅_htFAeAeeee)K>Y,N*:Tdd_8#$kkk(! r|r|r|LӥllldI& Gq@iYrG#>@a0Ap7|_gr?{n02 :Xݱcw͇5kr׀ėK%b?{000 @W_~YUfU[n*zU.***sI>)VNYH(P:a7 }6X8[l@x޸޸_} lmm!>>h '@/ǃ.VSBx=Π: ---)S*TQ3`5{000B{`ooz^W  <*x9Ws\f2`6AUUz_/ʀaaa2ws_}0Y3Y3Y~t BPcscscs'=F`cc|aas\Xmb5x~Peɗ%_Bf ]wߵ?8_t|Ç/os͐/_j?tttv%D'E+ p6:PP'M7}}ﻂvAqո9gfgfgfͅ +0f嘕cV_*IFFjݩuw4h d2o9c?l -Ң \qƕ ߈o[=znвI&-} - ?Lapd`w߁"YHa'Nbbb=$$$BHV!,,,O?P|_ MtMtMt,,,Y^en/^-.[ TܩS<(yP pRť M2xxx"JG( λw9+aW®f!ېm6Y5jfѨG]yv;fw 77F6tdS8[l!??ʽ-[hpE:㠽yw(z]>}^4 QI#tG(dlƼf̛?v.R˥K-c {;뗮_~)u} ΞΞΞg0kl/J+PaQE뷮ߺ~ QQQ_όY,cSrx5ռWS;5,jy2_~(ߢ|-Re]S5E hСA`珆/x c c cLV? CZLz^¼y \:tri:u+8NޜT$$#VGzV!`P@}žb_\"""`]uՃ#: BCCAp7'yb899s!cDƈ0u0W8sA_W_W_2,2,2,RХKA*U+ ˻w-zT/t_c}u w $.8+`Fތy~9vfڙigxu?YO*1/c^-[ h=z7W5ָ[N 4\t[t[t[Yg=vS"E (R,X<ʓ0uxWJ+&Mܛ@ -+ދRT7lllsb>3}f̄}6lJL+7n9-sZ@q%ƕ.9L6_G~4;680փ[CuByw ]ֻwYvډk'ܸܸdoeoepO,oMޚ5VVV+W׶m_BaU+^x"/ lllA"n@ttttt4ğ?ry[n5|xp~"k٭egYϲ)SP'QnGw>sIA^^ԣfv cFgK-}z8SO>;??mS())fz/9DG􁴐{E> -|!|g_~%XudՉ~Q(EFF’%KRaecvv ~?d˸q 1cjjj`,o,o,{{{@,,, /)/)/ M2PQQm6v2'N8aJX  =]oX߰$/Tz{=ar8?999\NsnnܺPcK-5@ɻ% ދT|*>lll_x Capapa0h5tpXa1>v}-[^*zUkלmmm 3*gT$HCWd&poֽYf^S{M382w_nP7b鋥/{VY+;0O9$O fZʹq4hQ5*kd6lRnN ^.{ +Wʯ JJJj}Z50jUjT0Gi `|Zuuu_ٱcgh3f"9fs rrrfU*k }v<)0!mWmWmW0l° àV[MAǃ:`뽭ރ;wܽuqN;4ZZZ@:t耮t+e2j`-kY Pu:ːg=(ݕJw`;mrWWyGI +:밮<1}bB#C#C%$I|G.\ φ<l 0t kkk?2.d&!~^z}^{^xE^YaĖ-[ fuO=aiO=ߑ#}G"8?(ʘ1+W7]tukC-r7goΆCCԞ=S!(=(=(k4i�!~3Ϭ>{ < NKRǤIatFpA^Pab㉍'6-[Hq 5׸ܳgytLAd0z‰'VX &L*dddrj˩-g_Ǥ̢H7T^a{P:txp8v,XS{^Ny9XobrQ={fL6tZ]BSO9†oXjDal1MIaI%͗49'rN ^Ǽy4$#0!~G -6ZlgO=yЩ>߃'O}*:(B}W;#G1t7O}>VÅ_&M2$$$jJ)KBO0Zhh!Zk]u0INR|M7ԥC~[-lnv?CEv:؁t Vm <x ;w0~?PtҕJ[8xqaՑUGVs 㪎 5W(am%O<lVجY#NGuOO- ףGWگ_i!::{zoyᚇě!&<<<nm61cN:ݟ-j aϳ=L5Z˧.:={NwXWg]uu'?9 7x}pF gqg]%#0!^6o3zW ..M̛7r555˝L0m!x8qGUUYpgǪU+U?:99婪}}}>}4oʧ+T?L^pmZUnr{x᪺jja }Ԅ}ro@Fg1c*FY9s@SOl'd0S&NM`d k笝v\|0jcA2. }Ԅ}R`BF{nﹽ69:no_N QC9s:4bgmC?Di7nkK/rJ9S-ZBҹev}Qg`BFMݛ7jռy^/;SL3o걫Ǯy9C樐={Zwh⢉%|eWPQF( H U\qǰҚJk*snnn@_TMN}"@dv{=S V}U߀zR=4ϑ/2 a@/.lݐ!h[޸z# |s+@fj\kpPZ===f;?zaA-[?eOy)0!ccc8{a/'S K-Z.%*\syة۩۩7?7?7?ܳr=ԖS[N???j֫-SN:s.Q QI Q<γнyݛC~v~v~6mBlBlBlqXaPŦMtttq{#! QAuwqlDZ02d|[nͺ5eEˊHqwEP 6h `mfmfm~uN3;4^e ar Q"n 6/}G0l۰möAM6y,E#GTbRPrH!%:EL%%DQDI=؃P}>4t(! !(BKR`B!%)0!ŒBbI L!D$&XBQ,I !(BKR`B!%)0!Œ5+<?}>FcT]'&/}RXqƕaeʠAp49hJZkݯ%"KDCx[I Qb)ЃRQ6 HJJ~M5tuu!:2:2:do̫WUvVիW^ z^Ayy9)jb+;)0!05D QC 00Ҵi4-ӵO>] $m6WR{/?%deep*P6nsHv3&XoZtk C$I N6SkNK/- ~IE^45CP3 /$/$/?]Sv?CN9#;w2@eeJh)D6P VdrгC=aݓwON[:mnn8CWO_^ν{Ï~#-[T:c_~$KX|J8t6ltV&xtQ4OáI\&q,f1 , , ,G?=wfޙytMCI5`;W Ϸ>|+2jeLʛ7)kL1m>q&LA?m?m?xGL"x`Z`Z`ZVVY.ͻ4gTϨ!_`~?!E@!a֥KY=*z@#T>-J(ݢ4={:.シ^>{WOO{{{(dw ;}g,,,gKi2Sl5oD':Lg‹ /BNlNlN,< ~,u:gݫ4)ӤLؿ` @ ӆ &VB )u[ %/_{{N8uǫǟC>} Vĭ[p톷F} jƂ !!!J.ymC%a(R`Ba⮸I$<~-X20Yfdf @[^6yem۲7hzhzhzH`%,S)ˀ e(EhF3~\ W |g<P9s[[[:tЦTRmJ dI')^x$ wBcMcMc ;ޯ{}Yg5hFkFkFÐCV YW^uz<:ȣ#1cjTV/`]˻u4`>V۟8iq$W{\q;|u:p93L1u:K 999222jsQ(} N^:r>K8|``wYP@%pyE L4h@aWV_> 300f>\OoooU{W]pm:^x5|W'N+;)0V*SЧD#zؽ~a6мE[fffӾЅ.pΥ:v-jUUW 3hϠ=`Ҷ!/ՊbM LUҞ=M{ +転/<`FTQuDUV%JS{zRI)Xx!G0"`D(VέSFno Ir!o\޸q0S+KqS.O˜/s={<@؂a tyD&2iEq!&0Dߊ} b /aB %&iӜ峭"êU 0zAaQE6md[6661tZQ%DQ4/h^"##!((u-ƴb h*i*i*:"""`iV 7f vvvN))0Q,΋:hJ#x?~"L<2(U*S*yg䝰ࢃB~a䁑Fm<:(*D :-tLLL9^ScN95VUXUaU5+r ,-- 8Փx3_j~ QIQIQIQGAAC;M&L6:x&Q$Bxeayeߗ}_€.IKSCFDFDFH"=wO!RFJ!11y6йtn`=.Vi`w5[Kd.mG]UB]]/Xt҅K!#$#$#?^hv'N;eS{OB@e@3B3B3_AXAXA,2_df}4Yꮺ=3g|ag#G2!C.\txuoŒ 3*@ٜ9g}fᙅg~~~-t/^ 5CE" TSbbbZ?hXaE*Rﯾ~dʓ)O /S)eRew0 nS*O yv킰ZajAUUs1۱Xmb5q2fN $@_;|w1|vSM> }B?666C\N\N\xx၇>XXg?7~ˍ_ ? ? ?Ztm 666v'''sss[an}nnnE/|*ݭt]pJ) OzR=GQ4ȿUěa &pb艡'SO>7os;O2?ijg¦3l:R;vol K*,\r? apO9 |0$u:8H#ma>(w]PRRs +rWM;;vxxx8xmKr.ɰ7jo(l`XXX@JӔ)M}>98r8q:tݳvZH;v80( JC_|>>>,Z[h ^zڪڪZpx2쾷{]]]ӻOB7oY}7NN;|lP6lBhdȺ5SO?U50kƱƱ0. djm 'Ǟ{r,ly)7~ )'0gle,O;qǍo!,I^$\\D&&^|&溛n„ !o`hb@<sss84}Ygccc>p,0Ya!eXlo-7ZJO,M,M,MhJ*J,N:FQjyyyƀ.]^=ҨQo`dF0e?~;VԧOSBNٜ9e!TtRpT{T{T q=`źu`8$:$:$B?8 L/Bӄ O!6?6?6|u3_꣪%N8Y*XT`=7{nK.q4-5-5-AMPԿ Ը^z0x4c83̟ hoNVR`⵪rʍ*7Ζ;[l9ȍʍʍzAtЁzS^򒗠)aJEQWϭMmjzN8V@)jʯ^;ԅ 2@lNlNlXXXõq]iѢ5FQc@Quuu1lPC-1[lڮڮڮuz;w4(~jo=V7V7.] :Au; ƯH!&^7l|Ƅ q8Mfu`x,YϿuKuKuKbaŠ78np`sϡrʽ+mEmEmE>}2$hMZSПџџK Tm6tx]<''';w@ITDH/H/H//_Ba%@OOtuu_nnn-|[mŵk=>{|6A}6UUUG~0`aBRKTRKvGGG;{s傕 V.#ZèQBO~2mŞx#*WSO=?HN*T8^kQZk RcK-5Xc]CCj"vۭ;bk֎ jY&DDD\o...pc׍]7vYf]p޽zAfi#GsΡ;B|  pf晙gf8)Еԕԕ~+&W@:ݕ+w%K2@;w@3D3D3nM5քWy{{C~k[-TY_e}ݬvW뺴ҮKⶊ*nUWu_O8>գ+L}?&3gCB a) ꟪ Ƽ3fL )[6mٴenп^zA-涘7~Fv[===M&E={ZӚ֠P[-pK- ՄjBooA ZN-NS@YTV RZ)F.Ba*Ud$hhhZ^-'xrH9rGS)Qm6sO'Э֭֭6͠kA3O3O30 3PSSIqR/jZJDiNWooom6NJ? B444,,,NRK8iq$s|TJU mh|b0Zj᪅&?6컲J0?i~\G#n{AxXxXxtqH!ٿg0m|ӊM.! *B_ L?qpWׁ_~6rn>}(XbŊ%zKh3"fD t5^]##0Q$]Hv.] yyy0g财o : ,N~N~N~0ΰ;TS 퓓 >ӇNN: ,d! VWR`❐+bVK7M7M7&כ\F 55e?Be옫\*M6ن%D &XBQ,I !(BKR`B!%)0!ŒBbI L!D$&XBQ,I !(BKR`B!%)0!ŒBbI L!D$&XBQ,I QP@'*U@+pssPPPJ J JXXXCo!Q.pa҅I&ۏoc@S:jn spΆ !,(DdlMBi]i]iZUjdLLL΁;b& ^7K L"777jtѹ<==#GN-aH QXYYA'@ZZߗkթUVeHN-ag`BAsH$DM,Y|x0if̤ a29s&42idweC°(,[AAA`1bXhQEe%N)a%DN}rBe@TU:ݿS/ x8011G֫[n Nְ5`thYe}&M'R`hݣuA 0#0#0Lt&:;AqPc'NYYY NթE14e2 vqrI(IIJnp!& fff;/:o ,e) ;w)&SLYq6tawӻ Fm(yf:E!XBQ,I !(BKR`B!%)0!ŒF/ğ2eK{RK]J+y$*#`9r-ZU ;v ={@l`l`l Ll3 2wmͷ5: 4hݸu֍<<< ?7| σnGvG <6yl999[oO>M4^]z7~ ȷ˷˷%yK@gi}Z ;~E{{PL2ˀ:K4ho QTLߑ\mz `e21jz'< }GFN9i$t]?O/O/O/p-Z؜9as\*s%P)yκu;khl46`ddWï_ g]zv e>:Ksss%?.1TWi\q^{v3ͷ۫0005YMV䥡ϊ &P•p%x#꿃`3$REk}w}w}wp=z m:ܦp&LHgwq`fmfmf vP;@tS &I3'͜4&MJi#H,H!`/{ c?PZZ-`FTS)Հ缡ϊ ex26el@ј1G!nZݴ A-[6,h;h;h;@5k wO=pu_8 \cy,ԙZgj7on_3/f J22grg΂I΃[[[v+VQ(}dffBn\n\nd=X*V]vו5jxᩆ(}Q"Ⱦ}92yj /_j4YUܫWcCdž;!wBDDD( NB:PSN:CCCrxI'a՝Ww^6Z?-1aƄf@&nMܠ݀v 0t*BbI L!D$&XBQ,I !(BKR`B!%)0!Œx76A}>U")d \2 Fmd2_N0lR٤2LJ2 E/:I>&} -4̇K/UT7n dPm#& 7sBAƏ?fJd:GVUkh*U̬Y3ЩFBBQ,ɧB!;ue+.zTXtcreate-datex3205054 142226020B# c}.zTXtmodify-datex3205054 1425266020AIENDB`source/configuration/global/options/rsconf1_maxopenfiles.rst0000664000175000017500000000210413223143453023516 0ustar rgerrger$MaxOpenFiles ------------- **Available Since:** 4.3.0 **Type:** global configuration parameter **Default:** *operating system default* **Description:** Set the maximum number of files that the rsyslog process can have open at any given time. Note that this includes open tcp sockets, so this setting is the upper limit for the number of open TCP connections as well. If you expect a large number of concurrent connections, it is suggested that the number is set to the max number connected plus 1000. Please note that each dynafile also requires up to 100 open file handles. The setting is similar to running "ulimit -n number-of-files". Please note that depending on permissions and operating system configuration, the setrlimit() request issued by rsyslog may fail, in which case the previous limit is kept in effect. Rsyslog will emit a warning message in this case. **Sample:** ``$MaxOpenFiles 2000`` **Bugs:** For some reason, this settings seems not to work on all platforms. If you experience problems, please let us know so that we can (hopefully) narrow down the issue. source/configuration/global/options/rsconf1_failonchownfailure.rst0000664000175000017500000000117113223143453024706 0ustar rgerrger$FailOnChownFailure ------------------- **Type:** global configuration parameter **Default:** on **Description:** This option modifies behaviour of dynaFile creation. If different owners or groups are specified for new files or directories and rsyslogd fails to set these new owners or groups, it will log an error and NOT write to the file in question if that option is set to "on". If it is set to "off", the error will be ignored and processing continues. Keep in mind, that the files in this case may be (in)accessible by people who should not have permission. The default is "on". **Sample:** ``$FailOnChownFailure off`` source/configuration/global/options/rsconf1_modload.rst0000664000175000017500000000150613223143453022450 0ustar rgerrger$ModLoad -------- **Type:** global configuration parameter **Default:** **Description:** Dynamically loads a plug-in into rsyslog's address space and activates it. The plug-in must obey the rsyslog module API. Currently, only MySQL and Postgres output modules are available as a plugins, but users may create their own. A plug-in must be loaded BEFORE any configuration file lines that reference it. Modules must be present in the system default destination for rsyslog modules. You can also set the directory via the `$ModDir `_ parameter. If a full path name is specified, the module is loaded from that path. The default module directory is ignored in that case. **Sample:** ``$ModLoad ommysql # load MySQL functionality $ModLoad /rsyslog/modules/ompgsql.so # load the postgres module via absolute path`` source/configuration/global/options/rsconf1_resetconfigvariables.rst0000664000175000017500000000066313223143453025235 0ustar rgerrger$ResetConfigVariables --------------------- **Type:** global configuration parameter **Default:** **Description:** Resets all configuration variables to their default value. Any settings made will not be applied to configuration lines following the $ResetConfigVariables. This is a good method to make sure no side-effects exists from previous parameters. This parameter has no parameters. **Sample:** ``$ResetConfigVariables`` source/configuration/global/options/rsconf1_debugprintcfsyslinehandlerlist.rst0000664000175000017500000000052413223143453027345 0ustar rgerrger$DebugPrintCFSyslineHandlerList ------------------------------- **Type:** global configuration parameter **Default:** on **Description:** Specifies whether or not the configuration file sysline handler list should be written to the debug log. Possible values: on/off. Default is on. Does not affect operation if debugging is disabled. source/configuration/global/options/rsconf1_debugprinttemplatelist.rst0000664000175000017500000000045213223143453025623 0ustar rgerrger$DebugPrintTemplateList ----------------------- **Type:** global configuration parameter **Default:** on **Description:** Specifies whether or not the template list should be written to the debug log. Possible values: on/off. Default is on. Does not affect operation if debugging is disabled.. source/configuration/global/index.rst0000664000175000017500000002061513224651466017025 0ustar rgerrgerLegacy Global Configuration Statements ====================================== Global configuration statements, as their name implies, usually affect some global features. However, some also affect main queues, which are "global" to a ruleset. True Global Directives ---------------------- .. toctree:: :glob: options/rsconf1_abortonuncleanconfig options/rsconf1_debugprintcfsyslinehandlerlist options/rsconf1_debugprintmodulelist options/rsconf1_debugprinttemplatelist options/rsconf1_failonchownfailure options/rsconf1_generateconfiggraph options/rsconf1_includeconfig options/rsconf1_mainmsgqueuesize options/rsconf1_maxopenfiles options/rsconf1_moddir options/rsconf1_modload options/rsconf1_umask options/rsconf1_resetconfigvariables - **$MaxMessageSize** , default 8k - allows to specify maximum supported message size (both for sending and receiving). The default should be sufficient for almost all cases. Do not set this below 1k, as it would cause interoperability problems with other syslog implementations. **Important:** In order for this directive to work correctly, it **must** be placed right at the top of ``rsyslog.conf`` (before any input is defined). Change the setting to e.g. 32768 if you would like to support large message sizes for IHE (32k is the current maximum needed for IHE). I was initially tempted to set the default to 32k, but there is a some memory footprint with the current implementation in rsyslog. If you intend to receive Windows Event Log data (e.g. via `EventReporter `_), you might want to increase this number to an even higher value, as event log messages can be very lengthy ("$MaxMessageSize 64k" is not a bad idea). Note: testing showed that 4k seems to be the typical maximum for **UDP** based syslog. This is an IP stack restriction. Not always ... but very often. If you go beyond that value, be sure to test that rsyslogd actually does what you think it should do ;) It is highly suggested to use a TCP based transport instead of UDP (plain TCP syslog, RELP). This resolves the UDP stack size restrictions. Note that 2k, is the smallest size that must be supported in order to be compliant to the upcoming new syslog RFC series. - **$LocalHostName** [name] - this directive permits to overwrite the system hostname with the one specified in the directive. If the directive is given multiple times, all but the last one will be ignored. Please note that startup error messages may be issued with the real hostname. This is by design and not a bug (but one may argue if the design should be changed ;)). Available since 4.7.4+, 5.7.3+, 6.1.3+. - **$LogRSyslogStatusMessages** [**on**/off] - If set to on (the default), rsyslog emits message on startup and shutdown as well as when it is HUPed. This information might be needed by some log analyzers. If set to off, no such status messages are logged, what may be useful for other scenarios. [available since 4.7.0 and 5.3.0] - **$DefaultRuleset** [name] - changes the default ruleset for unbound inputs to the provided *name* (the default default ruleset is named "RSYSLOG\_DefaultRuleset"). It is advised to also read our paper on :doc:`using multiple rule sets in rsyslog <../../concepts/multi_ruleset>`. - **$DefaultNetstreamDriver** , the default :doc:`network stream driver <../../concepts/netstrm_drvr>` to use. Defaults to ptcp. - **$DefaultNetstreamDriverCAFile** - **$DefaultNetstreamDriverCertFile** - **$DefaultNetstreamDriverKeyFile** - **$RepeatedMsgContainsOriginalMsg** [on/**off**] - "last message repeated n times" messages, if generated, have a different format that contains the message that is being repeated. Note that only the first "n" characters are included, with n to be at least 80 characters, most probably more (this may change from version to version, thus no specific limit is given). The bottom line is that n is large enough to get a good idea which message was repeated but it is not necessarily large enough for the whole message. (Introduced with 4.1.5). Once set, it affects all following actions. - **$OptimizeForUniprocessor** - This directive is no longer supported. While present in versions prior to 8.32.0, the directive had no effect for many years. Attempts to use the directive now results in a warning. - **$PreserveFQDN** [on/**off**) - if set to off (legacy default to remain compatible to sysklogd), the domain part from a name that is within the same domain as the receiving system is stripped. If set to on, full names are always used. - **$WorkDirectory** (directory for spool and other work files. Do **not** use trailing slashes) - `$PrivDropToGroup `_ - `$PrivDropToGroupID `_ - `$PrivDropToUser `_ - `$PrivDropToUserID `_ - **$Sleep** - puts the rsyslog main thread to sleep for the specified number of seconds immediately when the directive is encountered. You should have a good reason for using this directive! - **$LocalHostIPIF** - (available since 5.9.6) - if provided, the IP of the specified interface (e.g. "eth0") shall be used as fromhost-ip for locall-originating messages. If this directive is not given OR the interface cannot be found (or has no IP address), the default of "127.0.0.1" is used. Note that this directive can be given only once. Trying to reset will result in an error message and the new value will be ignored. Please note that modules must have support for obtaining the local IP address set via this directive. While this is the case for rsyslog-provided modules, it may not always be the case for contributed plugins. **Important:** This directive shall be placed **right at the top of rsyslog.conf**. Otherwise, if error messages are triggered before this directive is processed, rsyslog will fix the local host IP to "127.0.0.1", what than can not be reset. - **$ErrorMessagesToStderr** [**on**\ \|off] - direct rsyslogd error message to stderr (in addition to other targets) - **$SpaceLFOnReceive** [on/**off**] - instructs rsyslogd to replace LF with spaces during message reception (sysklogd compatibility aid). This is applied at the beginning of the parser stage and cannot be overridden (neither at the input nor parser level). Consequently, it affects all inputs and parsers. main queue specific Directives ------------------------------ Note that these directives modify ruleset main message queues. This includes the default ruleset's main message queue, the one that is always present. To do this, specify directives outside of a ruleset definition. To understand queue parameters, read :doc:`queues in rsyslog <../../concepts/queues>`. - **$MainMsgQueueCheckpointInterval** - **$MainMsgQueueDequeueBatchSize** [default 32] - **$MainMsgQueueDequeueSlowdown** [number is timeout in *micro*\ seconds (1000000us is 1sec!), default 0 (no delay). Simple rate-limiting!] - **$MainMsgQueueDiscardMark** [default 98% of queue size] - **$MainMsgQueueDiscardSeverity** [either a textual or numerical severity! default 4 (warning)] - **$MainMsgQueueFileName** - **$MainMsgQueueHighWaterMark** [default 90% of queue size] - **$MainMsgQueueImmediateShutdown** [on/**off**] - **$MainMsgQueueLowWaterMark** [default 70% of queue size] - **$MainMsgQueueMaxFileSize** , default 1m - **$MainMsgQueueTimeoutActionCompletion** [number is timeout in ms (1000ms is 1sec!), default 1000, 0 means immediate!] - **$MainMsgQueueTimeoutEnqueue** [number is timeout in ms (1000ms is 1sec!), default 2000, 0 means discard immediately] - **$MainMsgQueueTimeoutShutdown** [number is timeout in ms (1000ms is 1sec!), default 0 (indefinite)] - **$MainMsgQueueWorkerTimeoutThreadShutdown** [number is timeout in ms (1000ms is 1sec!), default 60000 (1 minute)] - **$MainMsgQueueType** [**FixedArray**/LinkedList/Direct/Disk] - **$MainMsgQueueSaveOnShutdown**  [on/**off**] - **$MainMsgQueueWorkerThreads** , num worker threads, default 2, recommended 1 - **$MainMsgQueueWorkerThreadMinumumMessages** , default queue size/number of workers source/configuration/ipv6.rst0000664000175000017500000000522713223143453015333 0ustar rgerrgerNotes on IPv6 Handling in Rsyslog ================================= **Rsyslog fully\* supports sending and receiving syslog messages via both IPv4 and IPv6.** IPv6 is natively supported for both UDP and TCP. However, there are some options that control handling of IPv6 operations. I thought it is is a good idea to elaborate a little about them, so that you can probably find your way somewhat easier. First of all, you can restrict rsyslog to using IPv4 or IPv6 addresses only by specifying the -4 or -6 command line option (now guess which one does what...). If you do not provide any command line option, rsyslog uses IPv4 and IPv6 addresses concurrently. In practice, that means the listener binds to both addresses (provided they are configured). When sending syslog messages, rsyslog uses IPv4 addresses when the receiver can be reached via IPv4 and IPv6 addresses if it can be reached via IPv6. If it can be reached on either IPv4 and v6, rsyslog leaves the choice to the socket layer. The important point to know is that it uses whatever connectivity is available to reach the destination. **There is one subtle difference between UDP and TCP.** With the new IPv4/v6 ignorant code, rsyslog has potentially different ways to reach destinations. The socket layer returns all of these paths in a sorted array. For TCP, rsyslog loops through this array until a successful TCP connect can be made. If that happens, the other addresses are ignored and messages are sent via the successfully-connected socket. For UDP, there is no such definite success indicator. Sure, the socket layer may detect some errors, but it may not notice other errors (due to the unreliable nature of UDP). By default, the UDP sender also tries one entry after the other in the sorted array of destination addresses. When a send fails, the next address is tried. When the send function finally succeeds, rsyslogd assumes the UDP packet has reached its final destination. However, if rsyslogd is started with the "-A" (capital A!) was given on the command line, rsyslogd will continue to send messages until the end of the destination address array is reached. This may result in duplicate messages, but it also provides some additional reliability in case a message could not be received. You need to be sure about the implications before applying this option. In general, it is NOT recommended to use the -A option. **\***\ rsyslog does not support RFC 3195 over IPv6. The reason is that the RFC 3195 library, `liblogging `_, supports IPv4, only. Currently, there are no plans to update either rsyslog to another RFC 3195 stack or update liblogging. There is simply no demand for 3195 solutions. source/configuration/property_replacer.rst0000664000175000017500000003570213223143030020200 0ustar rgerrgerThe Property Replacer ===================== **The property replacer is a core component in rsyslogd's** `string template system `_. A syslog message has a number of well-defined properties. Each of this properties can be accessed **and** manipulated by the property replacer. With it, it is easy to use only part of a property value or manipulate the value, e.g. by converting all characters to lower case. Accessing Properties -------------------- Syslog message properties are used inside templates. They are accessed by putting them between percent signs. Properties can be modified by the property replacer. The full syntax is as follows: :: %property:fromChar:toChar:options% Available Properties ^^^^^^^^^^^^^^^^^^^^ The property replacer can use all :doc:`rsyslog properties `. Character Positions ^^^^^^^^^^^^^^^^^^^^ **FromChar** and **toChar** are used to build substrings. They specify the offset within the string that should be copied. Offset counting starts at 1, so if you need to obtain the first 2 characters of the message text, you can use this syntax: "%msg:1:2%". If you do not whish to specify from and to, but you want to specify options, you still need to include the colons. For example, if you would like to convert the full message text to lower case, use "%msg:::lowercase%". If you would like to extract from a position until the end of the string, you can place a dollar-sign ("$") in toChar (e.g. %msg:10:$%, which will extract from position 10 to the end of the string). There is also support for **regular expressions**. To use them, you need to place a "R" into FromChar. This tells rsyslog that a regular expression instead of position-based extraction is desired. The actual regular expression must then be provided in toChar. The regular expression **must** be followed by the string "--end". It denotes the end of the regular expression and will not become part of it. If you are using regular expressions, the property replacer will return the part of the property text that matches the regular expression. An example for a property replacer sequence with a regular expression is: "%msg:R:.\*Sev:. \\(.\*\\) \\[.\*--end%" It is possible to specify some parametes after the "R". These are comma-separated. They are: R,,,<:doc:`nomatch `\ >, regexp-type is either "BRE" for Posix basic regular expressions or "ERE" for extended ones. The string must be given in upper case. The default is "BRE" to be consistent with earlier versions of rsyslog that did not support ERE. The submatch identifies the submatch to be used with the result. A single digit is supported. Match 0 is the full match, while 1 to 9 are the acutal submatches. The match-number identifies which match to use, if the expression occurs more than once inside the string. Please note that the first match is number 0, the second 1 and so on. Up to 10 matches (up to number 9) are supported. Please note that it would be more natural to have the match-number in front of submatch, but this would break backward-compatibility. So the match-number must be specified after "nomatch". :doc:`nomatch ` specifies what should be used in case no match is found. The following is a sample of an ERE expression that takes the first submatch from the message string and replaces the expression with the full field if no match is found: :: %msg:R,ERE,1,FIELD:for (vlan[0-9]\*):--end% and this takes the first submatch of the second match of said expression: :: %msg:R,ERE,1,FIELD,1:for (vlan[0-9]\*):--end% **Please note: there is also a** `rsyslog regular expression checker/generator `_ **online tool available.** With that tool, you can check your regular expressions and also generate a valid property replacer sequence. Usage of this tool is recommended. Depending on the version offered, the tool may not cover all subleties that can be done with the property replacer. It concentrates on the most often used cases. So it is still useful to hand-craft expressions for demanding environments. **Also, extraction can be done based on so-called "fields"**. To do so, place a "F" into FromChar. A field in its current definition is anything that is delimited by a delimiter character. The delimiter by default is TAB (US-ASCII value 9). However, if can be changed to any other US-ASCII character by specifying a comma and the **decimal** US-ASCII value of the delimiter immediately after the "F". For example, to use comma (",") as a delimiter, use this field specifier: "F,44".  If your syslog data is delimited, this is a quicker way to extract than via regular expressions (actually, a *much* quicker way). Field counting starts at 1. Field zero is accepted, but will always lead to a "field not found" error. The same happens if a field number higher than the number of fields in the property is requested. The field number must be placed in the "ToChar" parameter. An example where the 3rd field (delimited by TAB) from the msg property is extracted is as follows: "%msg:F:3%". The same example with semicolon as delimiter is "%msg:F,59:3%". The use of fields does not permit to select substrings, what is rather unfortunate. To solve this issue, starting with 6.3.9, fromPos and toPos can be specified for strings as well. However, the syntax is quite ugly, but it was the only way to integrate this functonality into the already-existing system. To do so, use ",fromPos" and ",toPos" during field extraction. Let's assume you want to extract the substring from position 5 to 9 in the previous example. Then, the syntax is as follows: "%msg:F,59,5:3,9%". As you can see, "F,59" means field-mode, with semicolon delimiter and ",5" means starting at position 5. Then "3,9" means field 3 and string extraction to position 9. Please note that the special characters "F" and "R" are case-sensitive. Only upper case works, lower case will return an error. There are no white spaces permitted inside the sequence (that will lead to error messages and will NOT provide the intended result). Each occurence of the field delimiter starts a new field. However, if you add a plus sign ("+") after the field delimiter, multiple delimiters, one immediately after the others, are treated as separate fields. This can be useful in cases where the syslog message contains such sequences. A frequent case may be with code that is written as follows: ```` :: int n, m; ... syslog(LOG_ERR, "%d test %6d", n, m); This will result into things like this in syslog messages: "1 test      2", "1 test     23", "1 test  234567" As you can see, the fields are delimited by space characters, but their exact number is unknown. They can properly be extracted as follows: :: "%msg:F,32:2%" to "%msg:F,32+:2%". This feature was suggested by Zhuang Yuyao and implemented by him. It is modeled after perl compatible regular expressions. Property Options ^^^^^^^^^^^^^^^^ **Property options** are case-insensitive. Currently, the following options are defined: **uppercase** convert property to uppercase only **lowercase** convert property text to lowercase only **fixed-width** changes behaviour of toChar so that it pads the source string with spaces up to the value of toChar if the source string is shorter. *This feature was introduced in rsyslog 8.13.0* **json** encode the value so that it can be used inside a JSON field. This means that several characters (according to the JSON spec) are being escaped, for example US-ASCII LF is replaced by "\\n". The json option cannot be used together with either jsonf or csv options. **jsonf**\[:outname\] (available in 6.3.9+) This signifies that the property should be expressed as a JSON field. That means not only the property is written, but rather a complete JSON field in the format ``"fieldname"="value"`` where "fieldname" is given in the *outname* property (or the property name if none was assigned) and value is the end result of property replacer operation. Note that value supports all property replacer options, like substrings, case converson and the like. Values are properly JSON-escaped, however field names are (currently) not, so it is expected that proper field names are configured. The jsonf option cannot be used together with either json or csv options. For more information you can read `this article from Rainer's blog `_. **csv** formats the resulting field (after all modifications) in CSV format as specified in `RFC 4180 `_. Rsyslog will always use double quotes. Note that in order to have full CSV-formatted text, you need to define a proper template. An example is this one: $template csvline,"%syslogtag:::csv%,%msg:::csv%" Most importantly, you need to provide the commas between the fields inside the template. *This feature was introduced in rsyslog 4.1.6.* **drop-last-lf** The last LF in the message (if any), is dropped. Especially useful for PIX. **date-utc** convert data to UTC prior to outputing it (available since 8.18.0) **date-mysql** format as mysql date **date-rfc3164** format as RFC 3164 date **date-rfc3164-buggyday** similar to date-rfc3164, but emulates a common coding error: RFC 3164 demands that a space is written for single-digit days. With this option, a zero is written instead. This format seems to be used by syslog-ng and the date-rfc3164-buggyday option can be used in migration scenarios where otherwise lots of scripts would need to be adjusted. It is recommended *not* to use this option when forwarding to remote hosts - they may treat the date as invalid (especially when parsing strictly according to RFC 3164). *This feature was introduced in rsyslog 4.6.2 and v4 versions above and 5.5.3 and all versions above.* **date-rfc3339** format as RFC 3339 date **date-unixtimestamp** Format as a unix timestamp (seconds since epoch) **date-year** just the year part (4-digit) of a timestamp **date-month** just the month part (2-digit) of a timestamp **date-day** just the day part (2-digit) of a timestamp **date-hour** just the hour part (2-digit, 24-hour clock) of a timestamp **date-minute** just the minute part (2-digit) of a timestamp **date-second** just the second part (2-digit) of a timestamp **date-subseconds** just the subseconds of a timestamp (always 0 for a low precision timestamp) **date-tzoffshour** just the timezone offset hour part (2-digit) of a timestamp **date-tzoffsmin** just the timezone offset minute part (2-digit) of a timestamp. Note that this is usually 0, but there are some time zones that have offsets which are not hourly-granular. If so, this is the minute offset. **date-tzoffsdirection** just the timezone offset direction part of a timestamp. This specifies if the offsets needs to be added ("+") or subtracted ("-") to the timestamp in order to get UTC. **date-ordinal** returns the ordinal for the given day, e.g. it is 2 for January, 2nd **date-week** returns the week number **date-wday** just the weekday number of the timstamp. This is a single digit, with 0=Sunday, 1=Monday, ..., 6=Saturday. **date-wdayname** just the abbreviated english name of the weekday (e.g. "Mon", "Sat") of the timestamp. **escape-cc** replace control characters (ASCII value 127 and values less then 32) with an escape sequence. The sequence is "#" where charval is the 3-digit decimal value of the control character. For example, a tabulator would be replaced by "#009". Note: using this option requires that `$EscapeControlCharactersOnReceive `_ is set to off. **space-cc** replace control characters by spaces Note: using this option requires that `$EscapeControlCharactersOnReceive `_ is set to off. **drop-cc** drop control characters - the resulting string will neither contain control characters, escape sequences nor any other replacement character like space. Note: using this option requires that `$EscapeControlCharactersOnReceive `_ is set to off. **compressspace** compresses multiple spaces (US-ASCII SP character) inside the string to a single one. This compression happens at a very late stage in processing. Most importantly, it happens after substring extraction, so the **FromChar** and **ToChar** positions are **NOT** affected by this option. (available since v8.18.0) **sp-if-no-1st-sp** This option looks scary and should probably not be used by a user. For any field given, it returns either a single space character or no character at all. Field content is never returned. A space is returned if (and only if) the first character of the field's content is NOT a space. This option is kind of a hack to solve a problem rooted in RFC 3164: 3164 specifies no delimiter between the syslog tag sequence and the actual message text. Almost all implementation in fact delimit the two by a space. As of RFC 3164, this space is part of the message text itself. This leads to a problem when building the message (e.g. when writing to disk or forwarding). Should a delimiting space be included if the message does not start with one? If not, the tag is immediately followed by another non-space character, which can lead some log parsers to misinterpret what is the tag and what the message. The problem finally surfaced when the klog module was restructured and the tag correctly written. It exists with other message sources, too. The solution was the introduction of this special property replacer option. Now, the default template can contain a conditional space, which exists only if the message does not start with one. While this does not solve all issues, it should work good enough in the far majority of all cases. If you read this text and have no idea of what it is talking about - relax: this is a good indication you will never need this option. Simply forget about it ;) **secpath-drop** Drops slashes inside the field (e.g. "a/b" becomes "ab"). Useful for secure pathname generation (with dynafiles). **secpath-replace** Replace slashes inside the field by an underscore. (e.g. "a/b" becomes "a\_b"). Useful for secure pathname generation (with dynafiles). To use multiple options, simply place them one after each other with a comma delimiting them. For example "escape-cc,sp-if-no-1st-sp". If you use conflicting options together, the last one will override the previous one. For example, using "escape-cc,drop-cc" will use drop-cc and "drop-cc,escape-cc" will use escape-cc mode. Further Links ------------- - Article on ":doc:`Recording the Priority of Syslog Messages <../tutorials/recording_pri>`" (describes use of templates to record severity and facility of a message) - `Configuration file syntax `_, this is where you actually use the property replacer. .. toctree:: :maxdepth: 2 nomatch source/configuration/action/0000775000175000017500000000000013223143453015164 5ustar rgerrgersource/configuration/action/rsconf1_filegroup.rst0000664000175000017500000000064413223143453021351 0ustar rgerrger$FileGroup ---------- **Type:** global configuration parameter **Default:** **Description:** Set the group for dynaFiles newly created. Please note that this setting does not affect the group of files already existing. The parameter is a group name, for which the groupid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. **Sample:** ``$FileGroup loggroup`` source/configuration/action/rsconf1_actionresumeinterval.rst0000664000175000017500000000151313223143453023614 0ustar rgerrger$ActionResumeInterval --------------------- **Type:** global configuration parameter **Default:** 30 **Description:** Sets the ActionResumeInterval for all following actions. The interval provided is always in seconds. Thus, multiply by 60 if you need minutes and 3,600 if you need hours (not recommended). When an action is suspended (e.g. destination can not be connected), the action is resumed for the configured interval. Thereafter, it is retried. If multiple retries fail, the interval is automatically extended. This is to prevent excessive resource use for retries. After each 10 retries, the interval is extended by itself. To be precise, the actual interval is (numRetries / 10 + 1) \* $ActionResumeInterval. so after the 10th try, it by default is 60 and after the 100th try it is 330. **Sample:** $ActionResumeInterval 30 source/configuration/action/rsconf1_dynafilecachesize.rst0000664000175000017500000000272113223143453023025 0ustar rgerrger$DynaFileCacheSize ------------------ **Type:** global configuration parameter **Default:** 10 **Description:** This parameter specifies the maximum size of the cache for dynamically-generated file names. Selector lines with dynamic files names ('?' indicator) support writing to multiple files with a single selector line. This setting specifies how many open file handles should be cached. If, for example, the file name is generated with the hostname in it and you have 100 different hosts, a cache size of 100 would ensure that files are opened once and then stay open. This can be a great way to increase performance. If the cache size is lower than the number of different files, the least recently used one is discarded (and the file closed). The hardcoded maximum is 10,000 - a value that we assume should already be very extreme. Please note that if you expect to run with a very large number of files, you probably need to reconfigure the kernel to support such a large number. In practice, we do NOT recommend to use a cache of more than 1,000 entries. The cache lookup would probably require more time than the open and close operations. The minimum value is 1. Numbers are always in decimal. Leading zeros should be avoided (in some later version, they may be mis-interpreted as being octal). Multiple parameters may be given. They are applied to selector lines based on order of appearance. **Sample:** ``$DynaFileCacheSize 100    # a cache of 100 files at most`` source/configuration/action/rsconf1_filecreatemode.rst0000664000175000017500000000252013223143453022320 0ustar rgerrger$FileCreateMode --------------- **Type:** global configuration parameter **Default:** 0644 **Description:** The $FileCreateMode parameter allows to specify the creation mode with which rsyslogd creates new files. If not specified, the value 0644 is used (which retains backward-compatibility with earlier releases). The value given must always be a 4-digit octal number, with the initial digit being zero. Please note that the actual permission depend on rsyslogd's process umask. If in doubt, use "$umask 0000" right at the beginning of the configuration file to remove any restrictions. $FileCreateMode may be specified multiple times. If so, it specifies the creation mode for all selector lines that follow until the next $FileCreateMode parameter. Order of lines is vitally important. **Sample:** ``$FileCreateMode 0600`` This sample lets rsyslog create files with read and write access only for the users it runs under. The following sample is deemed to be a complete rsyslog.conf: ``$umask 0000 # make sure nothing interferes with the following definitions *.* /var/log/file-with-0644-default $FileCreateMode 0600 *.* /var/log/file-with-0600 $FileCreateMode 0644 *.* /var/log/file-with-0644`` As you can see, open modes depend on position in the config file. Note the first line, which is created with the hardcoded default creation mode. source/configuration/action/rsconf1_dirgroup.rst0000664000175000017500000000065413223143453021211 0ustar rgerrger$DirGroup --------- **Type:** global configuration parameter **Default:** **Description:** Set the group for directories newly created. Please note that this setting does not affect the group of directories already existing. The parameter is a group name, for which the groupid is obtained by rsyslogd on during startup processing. Interim changes to the user mapping are not detected. **Sample:** ``$DirGroup loggroup`` source/configuration/action/rsconf1_fileowner.rst0000664000175000017500000000064613223143453021351 0ustar rgerrger$FileOwner ---------- **Type:** global configuration parameter **Default:** **Description:** Set the file owner for dynaFiles newly created. Please note that this setting does not affect the owner of files already existing. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. **Sample:** ``$FileOwner loguser`` source/configuration/action/rsconf1_gssmode.rst0000664000175000017500000000062213223143453021012 0ustar rgerrger$GssMode -------- **Type:** global configuration parameter **Default:** encryption **Provided by:** *omgssapi* **Description:** Specifies GSS-API mode to use, which can be "**integrity**\ " - clients are authenticated and messages are checked for integrity, "**encryption**\ " - same as "integrity", but messages are also encrypted if both sides support it. **Sample:** ``$GssMode Encryption`` source/configuration/action/rsconf1_dirowner.rst0000664000175000017500000000065313223143453021206 0ustar rgerrger$DirOwner --------- **Type:** global configuration parameter **Default:** **Description:** Set the file owner for directories newly created. Please note that this setting does not affect the owner of directories already existing. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. **Sample:** ``$DirOwner loguser`` source/configuration/action/rsconf1_gssforwardservicename.rst0000664000175000017500000000062113223143453023753 0ustar rgerrger$GssForwardServiceName ---------------------- **Type:** global configuration parameter **Default:** host **Provided by:** *omgssapi* **Description:** Specifies the service name used by the client when forwarding GSS-API wrapped messages. The GSS-API service names are constructed by appending '@' and a hostname following "@@" in each selector. **Sample:** ``$GssForwardServiceName rsyslog`` source/configuration/action/index.rst0000664000175000017500000002350513223143030017021 0ustar rgerrgerLegacy Action-Specific Configuration Statements =============================================== Statements modify the next action(s) that is/are defined **via legacy syntax** after the respective statement. Actions defined via the action() object are **not** affected by the legacy statements listed here. Use the action() object properties instead. Generic action configuration Statements --------------------------------------- These statements can be used with all types of actions. .. toctree:: :glob: *action* *rsconf1_repeatedmsgreduction* - **$ActionName** - used primarily for documentation, e.g. when generating a configuration graph. Available sice 4.3.1. - **$ActionExecOnlyOnceEveryInterval** - execute action only if the last execute is at last seconds in the past (more info in `ommail `_, but may be used with any action). To disable this setting, use value 0. - **$ActionExecOnlyEveryNthTime** - If configured, the next action will only be executed every n-th time. For example, if configured to 3, the first two messages that go into the action will be dropped, the 3rd will actually cause the action to execute, the 4th and 5th will be dropped, the 6th executed under the action, ... and so on. Note: this setting is automatically re-set when the actual action is defined. - **$ActionExecOnlyEveryNthTimeTimeout** - has a meaning only if $ActionExecOnlyEveryNthTime is also configured for the same action. If so, the timeout setting specifies after which period the counting of "previous actions" expires and a new action count is begun. Specify 0 (the default) to disable timeouts. *Why is this option needed?* Consider this case: a message comes in at, eg., 10am. That's count 1. Then, nothing happens for the next 10 hours. At 8pm, the next one occurs. That's count 2. Another 5 hours later, the next message occurs, bringing the total count to 3. Thus, this message now triggers the rule. The question is if this is desired behavior? Or should the rule only be triggered if the messages occur within an e.g. 20 minute window? If the later is the case, you need a $ActionExecOnlyEveryNthTimeTimeout 1200 This directive will timeout previous messages seen if they are older than 20 minutes. In the example above, the count would now be always 1 and consequently no rule would ever be triggered. - **$ActionResumeRetryCount** [default 0, -1 means eternal] - **$ActionWriteAllMarkMessages** [on/**off**]- [available since 5.1.5] - normally, mark messages are written to actions only if the action was not recently executed (by default, recently means within the past 20 minutes). If this setting is switched to "on", mark messages are always sent to actions, no matter how recently they have been executed. In this mode, mark messages can be used as a kind of heartbeat. Note that this option auto-resets to "off", so if you intend to use it with multiple actions, it must be specified in front off **all** selector lines that should provide this functionality. omfile-specific Configuration Statements ---------------------------------------- These statements are specific to omfile-based actions. .. toctree:: :glob: *omfile* *dir* *file* - **$CreateDirs** [**on**/off] - create directories on an as-needed basis - **$ActionFileDefaultTemplate** [templateName] - sets a new default template for file actions - **$ActionFileEnableSync [on/off]** - enables file syncing capability of omfile - **$OMFileAsyncWriting** [on/**off**], if turned on, the files will be written in asynchronous mode via a separate thread. In that case, double buffers will be used so that one buffer can be filled while the other buffer is being written. Note that in order to enable $OMFileFlushInterval, $OMFileAsyncWriting must be set to "on". Otherwise, the flush interval will be ignored. Also note that when $OMFileFlushOnTXEnd is "on" but $OMFileAsyncWriting is off, output will only be written when the buffer is full. This may take several hours, or even require a rsyslog shutdown. However, a buffer flush can be forced in that case by sending rsyslogd a HUP signal. - **$OMFileZipLevel** 0..9 [default 0] - if greater 0, turns on gzip compression of the output file. The higher the number, the better the compression, but also the more CPU is required for zipping. - **$OMFileIOBufferSize** , default 4k, size of the buffer used to writing output data. The larger the buffer, the potentially better performance is. The default of 4k is quite conservative, it is useful to go up to 64k, and 128K if you used gzip compression (then, even higher sizes may make sense) - **$OMFileFlushOnTXEnd** <[**on**/off]>, default on. Omfile has the capability to write output using a buffered writer. Disk writes are only done when the buffer is full. So if an error happens during that write, data is potentially lost. In cases where this is unacceptable, set $OMFileFlushOnTXEnd to on. Then, data is written at the end of each transaction (for pre-v5 this means after **each** log message) and the usual error recovery thus can handle write errors without data loss. Note that this option severely reduces the effect of zip compression and should be switched to off for that use case. Note that the default -on- is primarily an aid to preserve the traditional syslogd behaviour. omfwd-specific Configuration Statements --------------------------------------- These statements are specific to omfwd-based actions. - **$ActionForwardDefaultTemplate** [templateName] - sets a new default template for UDP and plain TCP forwarding action - **$ActionSendResendLastMsgOnReconnect** <[on/**off**]> specifies if the last message is to be resend when a connecition breaks and has been reconnected. May increase reliability, but comes at the risk of message duplication. - **$ActionSendStreamDriver** just like $DefaultNetstreamDriver, but for the specific action - **$ActionSendStreamDriverMode** , default 0, mode to use with the stream driver (driver-specific) - **$ActionSendStreamDriverAuthMode** ,  authentication mode to use with the stream driver. Note that this directive requires TLS netstream drivers. For all others, it will be ignored. (driver-specific) - **$ActionSendStreamDriverPermittedPeer** ,  accepted fingerprint (SHA1) or name of remote peer. Note that this directive requires TLS netstream drivers. For all others, it will be ignored. (driver-specific) - directive may go away! - **$ActionSendTCPRebindInterval** nbr- [available since 4.5.1] - instructs the TCP send action to close and re-open the connection to the remote host every nbr of messages sent. Zero, the default, means that no such processing is done. This directive is useful for use with load-balancers. Note that there is some performance overhead associated with it, so it is advisable to not too often "rebind" the connection (what "too often" actually means depends on your configuration, a rule of thumb is that it should be not be much more often than once per second). - **$ActionSendUDPRebindInterval** nbr- [available since 4.3.2] - instructs the UDP send action to rebind the send socket every nbr of messages sent. Zero, the default, means that no rebind is done. This directive is useful for use with load-balancers. omgssapi-specific Configuration Statements ------------------------------------------ These statements are specific to omgssapi actions. .. toctree:: :glob: *gss* action-queue specific Configuration Statements ---------------------------------------------- The following statements specify parameters for the action queue. To understand queue parameters, read :doc:`queues in rsyslog <../../concepts/queues>`. Action queue parameters usually affect the next action and auto-reset to defaults thereafter. Most importantly, this means that when a "real" (non-direct) queue type is defined, this affects the immediately following action, only. The next and all other actions will be in "direct" mode (no real queue) if not explicitely specified otherwise. - **$ActionQueueCheckpointInterval** - **$ActionQueueDequeueBatchSize** [default 128] - **$ActionQueueDequeueSlowdown** [number is timeout in *micro*\ seconds (1000000us is 1sec!), default 0 (no delay). Simple rate-limiting!] - **$ActionQueueDiscardMark** [default 80% of queue size] - **$ActionQueueDiscardSeverity** [\*numerical\* severity! default 8 (nothing discarded)] - **$ActionQueueFileName** - **$ActionQueueHighWaterMark** [default 90% of queue size] - **$ActionQueueImmediateShutdown** [on/**off**] - **$ActionQueueSize** - **$ActionQueueLowWaterMark** [default 70% of queue size] - **$ActionQueueMaxFileSize** , default 1m - **$ActionQueueTimeoutActionCompletion** [number is timeout in ms (1000ms is 1sec!), default 1000, 0 means immediate!] - **$ActionQueueTimeoutEnqueue** [number is timeout in ms (1000ms is 1sec!), default 2000, 0 means discard immediately] - **$ActionQueueTimeoutShutdown** [number is timeout in ms (1000ms is 1sec!), default 0 (indefinite)] - **$ActionQueueWorkerTimeoutThreadShutdown** [number is timeout in ms (1000ms is 1sec!), default 60000 (1 minute)] - **$ActionQueueType** [FixedArray/LinkedList/**Direct**/Disk] - **$ActionQueueSaveOnShutdown**  [on/**off**] - **$ActionQueueWorkerThreads** , num worker threads, default 1, recommended 1 - $ActionQueueWorkerThreadMinumumMessages , default 100 - **$ActionGSSForwardDefaultTemplate** [templateName] - sets a new default template for GSS-API forwarding action source/configuration/action/rsconf1_actionexeconlywhenpreviousissuspended.rst0000664000175000017500000000362413223143453027330 0ustar rgerrger$ActionExecOnlyWhenPreviousIsSuspended -------------------------------------- **Type:** global configuration parameter **Default:** off **Description:** This parameter allows to specify if actions should always be executed ("off," the default) or only if the previous action is suspended ("on"). This parameter works hand-in-hand with the multiple actions per selector feature. It can be used, for example, to create rules that automatically switch destination servers or databases to a (set of) backup(s), if the primary server fails. Note that this feature depends on proper implementation of the suspend feature in the output module. All built-in output modules properly support it (most importantly the database write and the syslog message forwarder). This selector processes all messages it receives (\*.\*). It tries to forward every message to primary-syslog.example.com (via tcp). If it can not reach that server, it tries secondary-1-syslog.example.com, if that fails too, it tries secondary-2-syslog.example.com. If neither of these servers can be connected, the data is stored in /var/log/localbuffer. Please note that the secondaries and the local log buffer are only used if the one before them does not work. So ideally, /var/log/localbuffer will never receive a message. If one of the servers resumes operation, it automatically takes over processing again. We strongly advise not to use repeated line reduction together with ActionExecOnlyWhenPreviousIsSuspended. It may lead to "interesting" and undesired results (but you can try it if you like). **Sample:** \*.\* @@primary-syslog.example.com $ActionExecOnlyWhenPreviousIsSuspended on & @@secondary-1-syslog.example.com # & is used to have more than one action for & @@secondary-2-syslog.example.com # the same selector - the mult-action feature & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off # to re-set it for the next selector source/configuration/action/rsconf1_omfileforcechown.rst0000664000175000017500000000457613223143453022716 0ustar rgerrger$omfileForceChown ----------------- **Type:** global configuration parameter **Parameter Values:** boolean (on/off, yes/no) **Available:** 4.7.0+, 5.3.0-5.8.x, **NOT** available in 5.9.x or higher **Note: this parameter has been removed and is no longer available. The documentation is currently being retained for historical reaons.** Expect it to go away at some later stage as well. **Default:** off **Description:** Forces rsyslogd to change the ownership for output files that already exist. Please note that this tries to fix a potential problem that exists outside the scope of rsyslog. Actually, it tries to fix invalid ownership/permission settings set by the original file creator. Rsyslog changes the ownership during initial execution with root privileges. When a privelege drop is configured, privileges are dropped after the file owner ship is changed. Not that this currently is a limitation in rsyslog's privilege drop code, which is on the TODO list to be removed. See Caveats section below for the important implications. **Caveats:** This parameter tries to fix a problem that actually is outside the scope of rsyslog. As such, there are a couple of restrictions and situations in which it will not work. **Users are strongly encouraged to fix their system instead of turning this parameter on** - it should only be used as a last resort. At least in the following scenario, this parameter will fail expectedly: It does not address the situation that someone changes the ownership \*after\* rsyslogd has started. Let's, for example, consider a log rotation script. - rsyslog is started - ownership is changed - privileges dropped - log rotation (lr) script starts - lr removes files - lr creates new files with root:adm (or whatever else) - lr HUPs rsyslogd - rsyslogd closes files - rsyslogd tries to open files - rsyslogd tries to change ownership --> fail as we are non-root now - file open fails Please note that once the privilege drop code is refactored, this parameter will no longer work, because then privileges will be dropped before any action is performed, and thus we will no longer be able to chown files that do not belong to the user rsyslogd is configured to run under. So **expect the parameter to go away**. It will not be removed in version 4, but may disappear at any time for any version greater than 4. **Sample:** ``$FileOwner loguser $omfileForceChown on`` source/configuration/action/rsconf1_repeatedmsgreduction.rst0000664000175000017500000000420113223143453023563 0ustar rgerrger$RepeatedMsgReduction --------------------- **Type:** global configuration parameter **Default:** off Description ^^^^^^^^^^^ This parameter models old sysklogd legacy. **Note that many people, including the rsyslog authors, consider this to be a misfeature.** See *Discussion* below to learn why. This parameter specifies whether or not repeated messages should be reduced (this is the "Last line repeated n times" feature). If set to *on*, repeated messages are reduced. If kept at *off*, every message is logged. In very early versions of rsyslog, this was controlled by the *-e* command line option. What is a repeated message ^^^^^^^^^^^^^^^^^^^^^^^^^^ For a message to be classified as repeated, the following properties must be **identical**: * msg * hostname * procid * appname Note that rate-limiters are usually applied to specific input sources or processes. So first and foremost the input source must be the same to classify a messages as a duplicated. You may want to check out `testing rsyslog ratelimiting `_ for some extra information on the per-process ratelimiting. Discussion ^^^^^^^^^^ * Very old versions of rsyslog did not have the ability to include the repeated message itself within the repeat message. * Versions before 7.3.2 applied repeat message reduction to the output side. This had some implications: - they did not account for the actual message origin, so two processes emitting an equally-looking messsage triggered the repeated message reduction code - repeat message processing could be set on a per-action basis, which has switched to per-input basis for 7.3.2 and above * While turning this feature on can save some space in logs, most log analysis tools need to see the repeated messages, they can't handle the "last message repeated" format. * This is a feature that worked decades ago when logs were small and reviewed by a human, it fails badly on high volume logs processed by tools. Sample ^^^^^^ This turns on repeated message reduction (**not** recommended): :: $RepeatedMsgReduction on    # do not log repeated messages source/configuration/templates.rst0000664000175000017500000006164313223143453016451 0ustar rgerrgerTemplates ========= Templates are a key feature of rsyslog. They allow to specify any format a user might want. They are also used for dynamic file name generation. Every output in rsyslog uses templates - this holds true for files, user messages and so on. The database writer expects its template to be a proper SQL statement - so this is highly customizable too. You might ask how does all of this work when no templates at all are specified. Good question ;). The answer is simple, though. Templates are compatible with the stock syslogd formats which are hardcoded into rsyslogd. So if no template is specified, we use one of those hardcoded templates. Search for "template\_" in rsconf.c and you will find the hardcoded ones. Templates are specified by template() statements. They can also be specified via $template legacy statements. **Note: key elements of templates are rsyslog properties.** See the :doc:`rsyslog properties reference ` for a list of which are available. Template processing ------------------- Due to lack of standardization regarding logs formats, when a template is specified it's supposed to include HEADER, as defined in `RFC5424 `_ It's very important to have this in mind, and also how to understand how `rsyslog parsing `_ works For example, if MSG field is set to "this:is a message" and no HOSTNAME, neither TAG are specified, outgoing parser will split the message as: :: TAG:this: MSG:is a message The template() statement ------------------------ The template() statement is used to define templates. Note that it is a **static** statement, that means all templates are defined when rsyslog reads the config file. As such, templates are not affected by if-statements or config nesting. The basic structure of the template statement is as follows: :: template(parameters) In addition to this simpler syntax, list templates (to be described below) support an extended syntax: :: template(parameters) { list-descriptions } Each template has a parameter **name**, which specifies the template name, and a parameter **type**, which specifies the template type. The name parameter must be unique, and behaviour is unpredictable if it is not. The **type** parameter specifies different template types. Different types simply enable different ways to specify the template content. The template type **does not** affect what an (output) plugin can do with it. So use the type that best fits your needs (from a config writing point of view!). The following types are available: - list - subtree - string - plugin The various types are described below. list ~~~~ In this case, the template is generated by a list of constant and variable statements. These follow the template spec in curly braces. This type is also primarily meant for use with structure-aware outputs, like ommongodb. However, it also works perfectly with text-based outputs. We recommend to use this mode if more complex property substitutions need to be done. In that case, the list-based template syntax is much clearer than the simple string-based one. The list template contains the template header (with **type="list"**) and is followed by **constant** and **property** statements, given in curly braces to signify the template statement they belong to. As the name says, **constant** statements describe constant text and **property** describes property access. There are many options to **property**, described further below. Most of these options are used to extract only partial property contents or to modify the text obtained (like to change its case to upper or lower case, only). To grasp the idea, an actual sample is: :: template(name="tpl1" type="list") { constant(value="Syslog MSG is: '") property(name="msg") constant(value="', ") property(name="timereported" dateFormat="rfc3339" caseConversion="lower") constant(value="\n") } This sample is probably primarily targeted at the usual file-based output. constant statement ^^^^^^^^^^^^^^^^^^ This provides a way to specify constant text. The text is used literally. It is primarily intended for text-based output, so that some constant text can be included. For example, if a complex template is built for file output, one usually needs to finish it by a newline, which can be introduced by a constant statement. Here is an actual sample of that use case from the rsylsog testbench: :: template(name="outfmt" type="list") { property(name="$!usr!msgnum") constant(value="\n") } The following escape sequences are recognized inside the constant text: - \\\\ - single backslash - \\n - LF - \\ooo - (three octal digits) - represents character with this numerical value (e.g. \\101 equals "A"). Note that three octal digits must be given (in contrast to some languages, where between one and three are valid). While we support octal notation, we recommend to use hex notation as this is better known. - \\xhh - (where h is a hex digit) - represents character with this numerical value (e.g. \\x41 equals "A"). Note that two hexadecimal digits must be given (in contrast to some languages where one or two are valid). - ... some others ... list needs to be extended Note: if an unsupported character follows a backslash, this is treated as an error. Behaviour is unpredictable in this case. To aid usage of the same template both for text-based outputs and structured ones, constant text without an "outname" parameter will be ignored when creating the name/value tree for structured outputs. So if you want to supply some constant text e.g. to mongodb, you must include an outname, as can be seen here: :: template(name="outfmt" type="list") { property(name="$!usr!msgnum") constant(value="\n" outname="IWantThisInMyDB") } The "constant" statement supports the following parameters: - value - the constant value to use - outname - output field name (for structured outputs) property statement ^^^^^^^^^^^^^^^^^^ This statement is used to include property text. It can access all properties. Also, options permit to specify picking only part of a property or modifying it. It supports the following parameters: - name - the name of the property to access - outname - output field name (for structured outputs) - dateformat - date format to use (only for date-related properties) - date.inUTC - date shall be shown in UTC (please note that this requires a bit more performance due to the necessary conversions) Available since 8.18.0. - caseconversion - permits to convert case of the text. Supported values are "lower" and "upper" - controlcharacters - specifies how to handle control characters. Supported values are "escape", which escapes them, "space", which replaces them by a single space, and "drop", which simply removes them from the string. - securepath - used for creating pathnames suitable for use in dynafile templates - format - specify format on a field basis. Supported values are: - "`csv `_\ " for use when csv-data is generated - "`json `_\ " which formats proper json content (but without a field header) - "`jsonf `_\ " which formats as a complete json field - "`jsonr `_\ " which avoids double escaping the value but makes it safe for a json field - "`jsonfr `_\ " which is the combination of "jsonf" and "jsonr". - position.from - obtain substring starting from this position (1 is the first position) - position.to - obtain substring up to this position - position.relativeToEnd - the from and to position is relative to the end of the string instead of the usual start of string. (available since rsyslog v7.3.10) - fixedwidth - changes behaviour of position.to so that it pads the source string with spaces up to the value of position.to if the source string is shorter. "on" or "off" (default) (available since rsyslog v8.13.0) - compressspace - compresses multiple spaces (US-ASCII SP character) inside the string to a single one. This compression happens at a very late stage in processing. Most importantly, it happens after substring extraction, so the **position.from** and **position.to** positions are **NOT** affected by this option. (available since v8.18.0). - field.number - obtain this field match - field.delimiter - decimal value of delimiter character for field extraction - regex.expression - expression to use - regex.type - either ERE or BRE - regex.nomatchmode - what to do if we have no match - regex.match - match to use - regex.submatch - submatch to use - droplastlf - drop a trailing LF, if it is present - mandatory - signifies a field as mandatory. If set to "on", this field will always be present in data passed to structured outputs, even if it is empty. If "off" (the default) empty fields will not be passed to structured outputs. This is especially useful for outputs that support dynamic schemas (like ommongodb). - spifno1stsp - expert options for RFC3164 template processing subtree ~~~~~~~ Available since rsyslog 7.1.4 In this case, the template is generated based on a complete (CEE) subtree. This type of template is most useful for outputs that know how to process hierarchical structure, like ommongodb. With that type, the parameter **subtree** must be specified, which tells which subtree to use. For example template(name="tpl1" type="subtree" subtree="$!") includes all CEE data, while template(name="tpl2" type="subtree" subtree="$!usr!tpl2") includes only the subtree starting at $!usr!tpl2. The core idea when using this type of template is that the actual data is prefabricated via set and unset script statements, and the resulting structure is then used inside the template. This method MUST be used if a complete subtree needs to be placed *directly* into the object's root. With all other template types, only subcontainers can be generated. Note that subtree type can also be used with text-based outputs, like omfile. HOWEVER, you do not have any capability to specify constant text, and as such cannot include line breaks. As a consequence, using this template type for text outputs is usually only useful for debugging or very special cases (e.g. where the text is interpreted by a JSON parser later on). Use case ^^^^^^^^ A typical use case is to first create a custom subtree and then include it into the template, like in this small example: :: set $!usr!tpl2!msg = $msg; set $!usr!tpl2!dataflow = field($msg, 58, 2); template(name="tpl2" type="subtree" subtree="$!usr!tpl2") Here, we assume that $msg contains various fields, and the data from a field is to be extracted and stored - together with the message - as field content. string ~~~~~~ This closely resembles the legacy template statement. It has a mandatory parameter **string**, which holds the template string to be applied. A template string is a mix of constant text and replacement variables (see property replacer). These variables are taken from message or other dynamic content when the final string to be passed to a plugin is generated. String-based templates are a great way to specify textual content, especially if no complex manipulation to properties is necessary. This is a sample for a string-based template: :: template(name="tpl3" type="string" string="%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" ) The text between percent signs ('%') is interpreted by the rsyslog :doc:`property replacer `. In a nutshell, it contains the property to use as well as options for formatting and further processing. This is very similar to what the ``property`` object in list templates does (it actually is just a different language to express most of the same things). Everything outside of the percent signs is constant text. In the above case, we have mostly spaces between the property values. At the end of the string, an escape sequence is used. Escape sequences permit to specify nonprintable characters. They work very similar to escape sequences in C and many other languages. They are initiated by the backslash characters and followed by one or more characters that specify the actual character. For example \\7 is the US-ASCII BEL character and \\n is a newline. The set is similar to what C and perl support, but a bit more limited. plugin ~~~~~~ In this case, the template is generated by a plugin (which is then called a "strgen" or "string generator"). The format is fixed as it is coded. While this is inflexible, it provides superior performance, and is often used for that reason (not that "regular" templates are slow - but in very demanding environments that "last bit" can make a difference). Refer to the plugin's documentation for further details. For this type, the parameter **plugin** must be specified and must contain the name of the plugin as it identifies itself. Note that the plugin must be loaded prior to being used inside a template. Config example: ``template(name="tpl4" type="plugin" plugin="mystrgen")`` options ~~~~~~~ The part is optional. It carries options influencing the template as a whole and is a part of the template parameters. See details below. Be sure NOT to mistake template options with property options - the latter ones are processed by the property replacer and apply to a SINGLE property, only (and not the whole template). Template options are case-insensitive. Currently defined are: **option.sql** - format the string suitable for a SQL statement in MySQL format. This will replace single quotes ("'") and the backslash character by their backslash-escaped counterpart ("\\'" and "\\\\") inside each field. Please note that in MySQL configuration, the ``NO_BACKSLASH_ESCAPES`` mode must be turned off for this format to work (this is the default). **option.stdsql** - format the string suitable for a SQL statement that is to be sent to a standards-compliant sql server. This will replace single quotes ("'") by two single quotes ("''") inside each field. You must use stdsql together with MySQL if in MySQL configuration the ``NO_BACKSLASH_ESCAPES`` is turned on. **option.json** - format the string suitable for a json statement. This will replace single quotes ("'") by two single quotes ("''") inside each field. **option.casesensitive** - treat property name references as case sensitive. The default is "off", where all property name references are first converted to lowercase during template definition. With this option turned "on", property names are looked up as defined in the template. Use this option if you have JSON (``$!*``), local (``!.*``), or global (``$!\\*``) properties which contain uppercase letters. The normal Rsyslog properties are case-insensitive, so this option is not needed for properly referencing those properties. Use of the options **option.sql**, **option.stdsql**, and **option.json** are mutually exclusive. Using more than one at the same time can cause unpredictable behaviour. Either the **sql** or **stdsql** option **must** be specified when a template is used for writing to a database, otherwise injection might occur. Please note that due to the unfortunate fact that several vendors have violated the sql standard and introduced their own escape methods, it is impossible to have a single option doing all the work.  So you yourself must make sure you are using the right format. **If you choose the wrong one, you are still vulnerable to sql injection.** Please note that the database writer *checks* that the sql option is present in the template. If it is not present, the write database action is disabled. This is to guard you against accidentally forgetting it and then becoming vulnerable to SQL injection. The sql option can also be useful with files - especially if you want to import them into a database on another machine for performance reasons. However, do NOT use it if you do not have a real need for it - among others, it takes some toll on the processing time. Not much, but on a really busy system you might notice it. The default template for the write to database action has the sql option set. As we currently support only MySQL and the sql option matches the default MySQL configuration, this is a good choice. However, if you have turned on ``NO_BACKSLASH_ESCAPES`` in your MySQL config, you need to supply a template with the stdsql option. Otherwise you will become vulnerable to SQL injection. :: template (name="TraditionalFormat" type="string" string="%timegenerated% %HOSTNAME% %syslogtag%%msg%\\n" Examples ~~~~~~~~ Standard Template for Writing to Files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :: template(name="FileFormat" type="list") { property(name="timestamp" dateFormat="rfc3339") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag") property(name="msg" spifno1stsp="on" ) property(name="msg" droplastlf="on" ) constant(value="\n") } The equivalent string template looks like this: :: template(name="FileFormat" type="string" string= "%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" ) Note that the template string itself must be on a single line. Standard Template for Forwarding to a Remote Host (RFC3164 mode) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :: template(name="ForwardFormat" type="list") { constant(value="<") property(name="pri") constant(value=">") property(name="timestamp" dateFormat="rfc3339") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag" position.from="1" position.to="32") property(name="msg" spifno1stsp="on" ) property(name="msg") } The equivalent string template looks like this: :: template(name="forwardFormat" type="string" string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%" ) Note that the template string itself must be on a single line. Standard Template for writing to the MySQL database ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :: template(name="StdSQLformat" type="list" option.sql="on") { constant(value="insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag)") constant(value=" values ('") property(name="msg") constant(value="', ") property(name="syslogfacility") constant(value=", '") property(name="hostname") constant(value="', ") property(name="syslogpriority") constant(value=", '") property(name="timereported" dateFormat="mysql") constant(value="', '") property(name="timegenerated" dateFormat="mysql") constant(value="', ") property(name="iut") constant(value=", '") property(name="syslogtag") constant(value="')") } The equivalent string template looks like this: :: template(name="stdSQLformat" type="string" option.sql="on" string="insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')" ) Note that the template string itself must be on a single line. Creating Dynamic File Names for omfile ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Templates can be used to generate actions with dynamic file names. For example, if you would like to split syslog messages from different hosts to different files (one per host), you can define the following template: :: template (name="DynFile" type="string" string="/var/log/system-%HOSTNAME%.log") Legacy example: :: $template DynFile,"/var/log/system-%HOSTNAME%.log" This template can then be used when defining an action. It will result in something like "/var/log/system-localhost.log" legacy format ------------- In pre v6-versions of rsyslog, you need to use the ``$template`` statement to configure templates. They provide the equivalent to string- and plugin-based templates. The legacy syntax continuous to work in v7, however we recommend to avoid legacy format for newly written config files. Legacy and current config statements can coexist within the same config file. The general format is :: $template name,param[,options] where "name" is the template name and "param" is a single parameter that specifies template content. The optional "options" part is used to set template options. string ~~~~~~ The parameter is the same string that with the current-style format you specify in the **string** parameter, for example: :: $template strtpl,"PRI: %pri%, MSG: %msg%\n" Note that list templates are not available in legacy format, so you need to use complex property replacer constructs to do complex things. plugin ~~~~~~ This is equivalent to the "plugin"-type template directive. Here, the parameter is the plugin name, with an equal sign prepended. An example is: :: $template plugintpl,=myplugin Reserved Template Names ----------------------- Template names beginning with "RSYSLOG\_" are reserved for rsyslog use. Do NOT use them if, otherwise you may receive a conflict in the future (and quite unpredictable behaviour). There is a small set of pre-defined templates that you can use without the need to define it: - **RSYSLOG\_TraditionalFileFormat** - the "old style" default log file format with low-precision timestamps - **RSYSLOG\_FileFormat** - a modern-style logfile format similar to TraditionalFileFormat, both with high-precision timestamps and timezone information - **RSYSLOG\_TraditionalForwardFormat** - the traditional forwarding format with low-precision timestamps. Most useful if you send messages to other syslogd's or rsyslogd below version 3.12.5. - **RSYSLOG\_SysklogdFileFormat** - sysklogd compatible log file format. If used with options: ``$SpaceLFOnReceive on``, ``$EscapeControlCharactersOnReceive off``, ``$DropTrailingLFOnReception off``, the log format will conform to sysklogd log format. - **RSYSLOG\_ForwardFormat** - a new high-precision forwarding format very similar to the traditional one, but with high-precision timestamps and timezone information. Recommended to be used when sending messages to rsyslog 3.12.5 or above. - **RSYSLOG\_SyslogProtocol23Format** - the format specified in IETF's internet-draft ietf-syslog-protocol-23, which is very close to the actual syslog standard `RFC5424 `_ (we couldn't update this template as things were in production for quite some time when RFC5424 was finally approved). This format includes several improvements. You may use this format with all relatively recent versions of rsyslog or syslogd. - **RSYSLOG\_DebugFormat** - a special format used for troubleshooting property problems. This format is meant to be written to a log file. Do **not** use for production or remote forwarding. Legacy String-based Template Samples ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section provides some default templates in legacy format, as used in rsyslog previous to version 6. Note that this format is still supported, so there is no hard need to upgrade existing configurations. However, it is strongly recommended that the legacy constructs are not used when crafting new templates. Note that each $template statement is on a **single** line, but probably broken across several lines for display purposes by your browsers. Lines are separated by empty lines. Keep in mind, that line breaks are important in legacy format. :: $template FileFormat,"%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" $template TraditionalFileFormat,"%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" $template ForwardFormat,"<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%" $template TraditionalForwardFormat,"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%" $template StdSQLFormat,"insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')",SQL`` See Also -------- - `How to bind a template `_ - `Adding the BOM to a message `_ - `How to separate log files by host name of the sending device `_ source/configuration/conf_formats.rst0000664000175000017500000001044413223143453017124 0ustar rgerrgerConfiguration Formats ===================== Rsyslog has evolved over several decades. For this reason it supports three different configuration formats ("languages"): - |FmtBasicName| - previously known as the :doc:`sysklogd ` format, this is the format best used to express basic things, such as where the statement fits on a single line. It stems back to the original syslog.conf format, in use now for several decades. The most common use case is matching on facility/severity and writing matching messages to a log file. - |FmtAdvancedName| - previously known as the ``RainerScript`` format, this format was first available in rsyslog v6 and is the current, best and most precise format for non-trivial use cases where more than one line is needed. Prior to v8, there was a performance impact when using this format that encouraged use of the |FmtBasicName| format for best results. Current versions of rsyslog do not suffer from this (historical) performance impact. This new style format is specifically targeted towards more advanced use cases like forwarding to remote hosts that might be partially offline. - |FmtObsoleteName| - previously known simply as the ``legacy`` format, this format is exactly what its name implies: it is obsolete and should not be used when writing new configurations. It was created in the early days (up to rsyslog version 5) where we expected that rsyslog would extend sysklogd just mildly. Consequently, it was primarily aimed at small additions to the original sysklogd format. Practice has shown that it was notoriously hard to use for more advanced use cases, and thus we replaced it with the |FmtAdvancedName| format. In essence, everything that needs to be written on a single line that starts with a dollar sign is legacy format. Users of this format are encouraged to migrate to the |FmtBasicName| or |FmtAdvancedName| formats. Which Format should I Use? ~~~~~~~~~~~~~~~~~~~~~~~~~~ While rsyslog supports all three formats concurrently, you are **strongly** encouraged to avoid using the |FmtObsoleteName| format. Instead, you should use the |FmtBasicName| format for basic configurations and the |FmtAdvancedName| format for anything else. While it is an older format, the |FmtBasicName| format is still suggested for configurations that mostly consist of simple statements. The classic example is writing to files (or forwarding) via priority. In |FmtBasicName| format, this looks like: :: mail.info /var/log/mail.log mail.err @@server.example.net This is hard to beat in simplicity, still being taught in courses and a lot of people know this syntax. It is perfectly fine to use these constructs even in newly written config files. Note that many distributions use this format in their default rsyslog.conf, so you will likely find it in existing configurations. **For anything more advanced, use** the |FmtAdvancedName| format. Advantages are: - fine control over rsyslog operations via advanced parameters - easy to follow block structure - easy to write - safe for use with include files To continue with the above example, the |FmtAdvancedName| format is preferrable if you want to make sure that an offline remote destination will not slow down local log file writing. In that case, forwarding is done via: :: mail.err action(type="omfwd" protocol="tcp" queue.type="linkedList") As can be seen by this example, the |FmtAdvancedName| format permits specifing additional parameters to fine tune the behavior, whereas the |FmtBasicName| format does not provide this level of control. **Do not use** |FmtObsoleteName| **format. It will make your life miserable.** It is primarily supported in order to not break existing configurations. Whatever you can do with the |FmtObsoleteName| format, you can also do with the |FmtAdvancedName| format. The opposite is not true: Many newer features cannot be turned on via the |FmtObsoleteName| format. The |FmtObsoleteName| format is hard to understand and hard to get right. As you may inherit a rsyslog configuration that makes use of it, this documentation gives you some clues of what the obsolete statements do. For full details, obtain a `v5 version of the rsyslog documentation `_ (yes, this format is dead since 2010!). source/configuration/actions.rst0000664000175000017500000006322113225116777016120 0ustar rgerrgerActions ======= .. index:: ! action .. _cfgobj_input: The Action object describe what is to be done with a message. They are implemented via :doc:`output modules `. The action object has different parameters: - those that apply to all actions and are action specific. These are documented below. - parameters for the action queue. While they also apply to all parameters, they are queue-specific, not action-specific (they are the same that are used in rulesets, for example). The are documented separately under :doc:`queue parameters <../rainerscript/queue_parameters>`. - action-specific parameters. These are specific to a certain type of actions. They are documented by the :doc:`output modules` in question. General Action Parameters ------------------------- Note: parameter names are case-insensitive. - **name** word This names the action. The name is used for statistics gathering and documentation. If no name is given, one is dynamically generated based on the occurence of this action inside the rsyslog configuration. Actions are sequentially numbered from 1 to n. - **type** string Mandatory parameter for every action. The name of the module that should be used. - **action.writeAllMarkMessages** *on*/off This setting tells if mark messages are always written ("on", the default) or only if the action was not recently executed ("off"). By default, recently means within the past 20 minutes. If this setting is "on", mark messages are always sent to actions, no matter how recently they have been executed. In this mode, mark messages can be used as a kind of heartbeat. This mode also enables faster processing inside the rule engine. So it should be set to "off" only when there is a good reason to do so. - **action.execOnlyEveryNthTime** integer If configured, the next action will only be executed every n-th time. For example, if configured to 3, the first two messages that go into the action will be dropped, the 3rd will actually cause the action to execute, the 4th and 5th will be dropped, the 6th executed under the action, ... and so on. - **action.execOnlyEveryNthTimeout** integer Has a meaning only if Action.ExecOnlyEveryNthTime is also configured for the same action. If so, the timeout setting specifies after which period the counting of "previous actions" expires and a new action count is begun. Specify 0 (the default) to disable timeouts. Why is this option needed? Consider this case: a message comes in at, eg., 10am. That's count 1. Then, nothing happens for the next 10 hours. At 8pm, the next one occurs. That's count 2. Another 5 hours later, the next message occurs, bringing the total count to 3. Thus, this message now triggers the rule. The question is if this is desired behavior? Or should the rule only be triggered if the messages occur within an e.g. 20 minute window? If the later is the case, you need a Action.ExecOnlyEveryNthTimeTimeout="1200" This directive will timeout previous messages seen if they are older than 20 minutes. In the example above, the count would now be always 1 and consequently no rule would ever be triggered. - **action.errorfile** string .. versionadded:: 8.32.0 When an action is executed, some messages may permanently fail. Depending on configuration, this could for example be caused by an offline target or exceptionally non-numerical data inside a numerical database field. If action.errorfile is specified, those messages are written to the specified file. If it is not specified (the default), messages are silently discarded. The error file format is JSON. It contains the failed messages as provided to the action in question, the action name as well as the rsyslog status code roughly explaining why it failed. - **action.execOnlyOnceEveryInterval** integer Execute action only if the last execute is at last seconds in the past (more info in ommail, but may be used with any action) - **action.execOnlyWhenPreviousIsSuspended** on/off This directive allows to specify if actions should always be executed ("off," the default) or only if the previous action is suspended ("on"). This directive works hand-in-hand with the multiple actions per selector feature. It can be used, for example, to create rules that automatically switch destination servers or databases to a (set of) backup(s), if the primary server fails. Note that this feature depends on proper implementation of the suspend feature in the output module. All built-in output modules properly support it (most importantly the database write and the syslog message forwarder). Note, however, that a failed action may not immediately be detected. For more information, see the `rsyslog execOnlyWhenPreviousIsSpuspended preciseness `_ FAQ article. - **action.repeatedmsgcontainsoriginalmsg** on/off "last message repeated n times" messages, if generated, have a different format that contains the message that is being repeated. Note that only the first "n" characters are included, with n to be at least 80 characters, most probably more (this may change from version to version, thus no specific limit is given). The bottom line is that n is large enough to get a good idea which message was repeated but it is not necessarily large enough for the whole message. (Introduced with 4.1.5). - **action.resumeRetryCount** integer [default 0, -1 means eternal] Sets how often an action is retried before it is considered to have failed. Failed actions discard messages. - **action.resumeInterval** integer Sets the ActionResumeInterval for the action. The interval provided is always in seconds. Thus, multiply by 60 if you need minutes and 3,600 if you need hours (not recommended). When an action is suspended (e.g. destination can not be connected), the action is resumed for the configured interval. Thereafter, it is retried. If multiple retries fail, the interval is automatically extended. This is to prevent excessive resource use for retries. After each 10 retries, the interval is extended by itself. To be precise, the actual interval is (numRetries / 10 + 1) \* Action.ResumeInterval. so after the 10th try, it by default is 60 and after the 100th try it is 330. - **action.reportSuspension** on/off Configures rsyslog to report suspension and reactivation of the action. This is useful to note which actions have problems (e.g. connecting to a remote system) and when. The default for this setting is the equally-named global parameter. - **action.reportSuspensionContinuation** on/off Configures rsyslog to report continuation of action suspension. This emits new messages whenever an action is to be retried, but continues to fail. If set to "on", *action.reportSuspension* is also automatically set to "on". The default for this setting is the equally-named global parameter. - **action.copyMsg** on/*off* Configures action to *copy* the message if *on*. Defaults to *off* (which is how actions have worked traditionally), which causes queue to refer to the original message object, with reference-counting. (Introduced with 8.10.0). Useful Links ------------ - Rainer's blog posting on the performance of `main and action queue worker threads `_ Legacy Format ------------- .. _legacy-action-order: **Be warned that legacy action format is hard to get right. It is recommended to use RainerScript-Style action format whenever possible!** A key problem with legacy format is that a single action is defined via multiple configurations lines, which may be spread all across rsyslog.conf. Even the definition of multiple actions may be intermixed (often not intentional!). If legacy actions format needs to be used (e.g. some modules may not yet implement the RainerScript format), it is strongly recommended to place all configuration statements pertaining to a single action closely together. Please also note that legacy action parameters **do not** affect RainerScript action objects. So if you define for example: :: $actionResumeRetryCount 10 action(type="omfwd" target="server1.example.net") @@server2.example.net server1's "action.resumeRetryCount" parameter is **not** set, instead server2's is! A goal of the new RainerScript action format was to avoid confusion which parameters are actually used. As such, it would be counter-productive to honor legacy action parameters inside a RainerScript definition. As result, both types of action definitions are strictly (and nicely) separated from each other. The bottom line is that if RainerScript actions are used, one does not need to care about which legacy action parameters may (still...) be in effect. Note that not all modules necessarily support legacy action format. Especially newer modules are recommended to NOT support it. Legacy Description ~~~~~~~~~~~~~~~~~~ Templates can be used with many actions. If used, the specified template is used to generate the message content (instead of the default template). To specify a template, write a semicolon after the action value immediately followed by the template name. Beware: templates MUST be defined BEFORE they are used. It is OK to define some templates, then use them in selector lines, define more templates and use use them in the following selector lines. But it is NOT permitted to use a template in a selector line that is above its definition. If you do this, the action will be ignored. **You can have multiple actions for a single selector** (or more precisely a single filter of such a selector line). Each action must be on its own line and the line must start with an ampersand ('&') character and have no filters. An example would be :: *.=crit :omusrmsg:rger & root & /var/log/critmsgs These three lines send critical messages to the user rger and root and also store them in /var/log/critmsgs. **Using multiple actions per selector is** convenient and also **offers a performance benefit**. As the filter needs to be evaluated only once, there is less computation required to process the directive compared to the otherwise-equal config directives below: :: *.=crit :omusrmsg:rger *.=crit root *.=crit /var/log/critmsgs Regular File ~~~~~~~~~~~~ Typically messages are logged to real files. The file usually is specified by full pathname, beginning with a slash "/". Starting with version 4.6.2 and 5.4.1 (previous v5 version do NOT support this) relative file names can also be specified. To do so, these must begin with a dot. For example, use "./file-in-current-dir.log" to specify a file in the current directory. Please note that rsyslogd usually changes its working directory to the root, so relative file names must be tested with care (they were introduced primarily as a debugging vehicle, but may have useful other applications as well). You may prefix each entry with the minus "-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. If your system is connected to a reliable UPS and you receive lots of log data (e.g. firewall logs), it might be a very good idea to turn of syncing by specifying the "-" in front of the file name. **The filename can be either static**\ (always the same) or **dynamic** (different based on message received). The later is useful if you would automatically split messages into different files based on some message criteria. For example, dynamic file name selectors allow you to split messages into different files based on the host that sent them. With dynamic file names, everything is automatic and you do not need any filters. It works via the template system. First, you define a template for the file name. An example can be seen above in the description of template. We will use the "DynFile" template defined there. Dynamic filenames are indicated by specifying a questions mark "?" instead of a slash, followed by the template name. Thus, the selector line for our dynamic file name would look as follows: ``*.* ?DynFile`` That's all you need to do. Rsyslog will now automatically generate file names for you and store the right messages into the right files. Please note that the minus sign also works with dynamic file name selectors. Thus, to avoid syncing, you may use ``*.* -?DynFile`` And of course you can use templates to specify the output format: ``*.* ?DynFile;MyTemplate`` **A word of caution:** rsyslog creates files as needed. So if a new host is using your syslog server, rsyslog will automatically create a new file for it. **Creating directories is also supported**. For example you can use the hostname as directory and the program name as file name: ``$template DynFile,"/var/log/%HOSTNAME%/%programname%.log"`` Named Pipes ~~~~~~~~~~~ This version of rsyslogd(8) has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipe symbol ("\|'') to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo(1) command before rsyslogd(8) is started. Terminal and Console ~~~~~~~~~~~~~~~~~~~~ If the file you specified is a tty, special tty-handling is done, same with /dev/console. Remote Machine ~~~~~~~~~~~~~~ Rsyslogd provides full remote logging, i.e. is able to send messages to a remote host running rsyslogd(8) and to receive messages from remote hosts. Using this feature you're able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs. To forward messages to another host, prepend the hostname with the at sign ("@"). A single at sign means that messages will be forwarded via UDP protocol (the standard for syslog). If you prepend two at signs ("@@"), the messages will be transmitted via TCP. Please note that plain TCP based syslog is not officially standardized, but most major syslogds support it (e.g. syslog-ng or `WinSyslog `_). The forwarding action indicator (at-sign) can be followed by one or more options. If they are given, they must be immediately (without a space) following the final at sign and be enclosed in parenthesis. The individual options must be separated by commas. The following options are right now defined: **z** Enable zlib-compression for the message. The is the compression level. It can be 1 (lowest gain, lowest CPU overhead) to 9 (maximum compression, highest CPU overhead). The level can also be 0, which means "no compression". If given, the "z" option is ignored. So this does not make an awful lot of sense. There is hardly a difference between level 1 and 9 for typical syslog messages. You can expect a compression gain between 0% and 30% for typical messages. Very chatty messages may compress up to 50%, but this is seldom seen with typically traffic. Please note that rsyslogd checks the compression gain. Messages with 60 bytes or less will never be compressed. This is because compression gain is pretty unlikely and we prefer to save CPU cycles. Messages over that size are always compressed. However, it is checked if there is a gain in compression and only if there is, the compressed message is transmitted. Otherwise, the uncompressed messages is transmitted. This saves the receiver CPU cycles for decompression. It also prevents small message to actually become larger in compressed form. **Please note that when a TCP transport is used, compression will also turn on syslog-transport-tls framing. See the "o" option for important information on the implications.** Compressed messages are automatically detected and decompressed by the receiver. There is nothing that needs to be configured on the receiver side. **o** **This option is experimental. Use at your own risk and only if you know why you need it! If in doubt, do NOT turn it on.** This option is only valid for plain TCP based transports. It selects a different framing based on IETF internet draft syslog-transport-tls-06. This framing offers some benefits over traditional LF-based framing. However, the standardization effort is not yet complete. There may be changes in upcoming versions of this standard. Rsyslog will be kept in line with the standard. There is some chance that upcoming changes will be incompatible to the current specification. In this case, all systems using -transport-tls framing must be upgraded. There will be no effort made to retain compatibility between different versions of rsyslog. The primary reason for that is that it seems technically impossible to provide compatibility between some of those changes. So you should take this note very serious. It is not something we do not \*like\* to do (and may change our mind if enough people beg...), it is something we most probably \*can not\* do for technical reasons (aka: you can beg as much as you like, it won't change anything...). The most important implication is that compressed syslog messages via TCP must be considered with care. Unfortunately, it is technically impossible to transfer compressed records over traditional syslog plain tcp transports, so you are left with two evil choices... The hostname may be followed by a colon and the destination port. The following is an example selector line with forwarding: \*.\*    @@(o,z9)192.168.0.1:1470 In this example, messages are forwarded via plain TCP with experimental framing and maximum compression to the host 192.168.0.1 at port 1470. \*.\* @192.168.0.1 In the example above, messages are forwarded via UDP to the machine 192.168.0.1, the destination port defaults to 514. Messages will not be compressed. Note that IPv6 addresses contain colons. So if an IPv6 address is specified in the hostname part, rsyslogd could not detect where the IP address ends and where the port starts. There is a syntax extension to support this: put squary brackets around the address (e.g. "[2001::1]"). Square brackets also work with real host names and IPv4 addresses, too. A valid sample to send messages to the IPv6 host 2001::1 at port 515 is as follows: \*.\* @[2001::1]:515 This works with TCP, too. **Note to sysklogd users:** sysklogd does **not** support RFC 3164 format, which is the default forwarding template in rsyslog. As such, you will experience duplicate hostnames if rsyslog is the sender and sysklogd is the receiver. The fix is simple: you need to use a different template. Use that one: $template sysklogd,"<%PRI%>%TIMESTAMP% %syslogtag%%msg%\\"" \*.\* @192.168.0.1;sysklogd List of Users ~~~~~~~~~~~~~ Usually critical messages are also directed to "root'' on that machine. You can specify a list of users that shall get the message by simply writing ":omusrmsg: followed by the login name. For example, the send messages to root, use ":omusrmsg:root". You may specify more than one user by separating them with commas (",''). Do not repeat the ":omusrmsg:" prefix in this case. For example, to send data to users root and rger, use ":omusrmsg:root,rger" (do not use ":omusrmsg:root,:omusrmsg:rger", this is invalid). If they're logged in they get the message. Everyone logged on ~~~~~~~~~~~~~~~~~~ Emergency messages often go to all users currently online to notify them that something strange is happening with the system. To specify this wall(1)-feature use an asterisk as the user message destination(":omusrmsg:\*''). Call Plugin ~~~~~~~~~~~ This is a generic way to call an output plugin. The plugin must support this functionality. Actual parameters depend on the module, so see the module's doc on what to supply. The general syntax is as follows: :modname:params;template Currently, the ommysql database output module supports this syntax (in addtion to the ">" syntax it traditionally supported). For ommysql, the module name is "ommysql" and the params are the traditional ones. The ;template part is not module specific, it is generic rsyslog functionality available to all modules. As an example, the ommysql module may be called as follows: :ommysql:dbhost,dbname,dbuser,dbpassword;dbtemplate For details, please see the "Database Table" section of this documentation. Note: as of this writing, the ":modname:" part is hardcoded into the module. So the name to use is not necessarily the name the module's plugin file is called. Database Table ~~~~~~~~~~~~~~ This allows logging of the message to a database table. Currently, only MySQL databases are supported. However, other database drivers will most probably be developed as plugins. By default, a `MonitorWare `_-compatible schema is required for this to work. You can create that schema with the createDB.SQL file that came with the rsyslog package. You can also use any other schema of your liking - you just need to define a proper template and assign this template to the action. The database writer is called by specifying a greater-then sign (">") in front of the database connect information. Immediately after that sign the database host name must be given, a comma, the database name, another comma, the database user, a comma and then the user's password. If a specific template is to be used, a semicolon followed by the template name can follow the connect information. This is as follows: >dbhost,dbname,dbuser,dbpassword;dbtemplate **Important: to use the database functionality, the MySQL output module must be loaded in the config file** BEFORE the first database table action is used. This is done by placing the :: $ModLoad ommysql directive some place above the first use of the database write (we recommend doing at the the beginning of the config file). Discard / Stop ~~~~~~~~~~~~~~ If the discard action is carried out, the received message is immediately discarded. No further processing of it occurs. Discard has primarily been added to filter out messages before carrying on any further processing. For obvious reasons, the results of "discard" are depending on where in the configuration file it is being used. Please note that once a message has been discarded there is no way to retrieve it in later configuration file lines. Discard can be highly effective if you want to filter out some annoying messages that otherwise would fill your log files. To do that, place the discard actions early in your log files. This often plays well with property-based filters, giving you great freedom in specifying what you do not want. Discard is just the word "stop" with no further parameters: stop For example, \*.\*   stop discards everything (ok, you can achive the same by not running rsyslogd at all...). Note that in legacy configuration the tilde character "~" can also be used instead of the word "stop". Output Channel ~~~~~~~~~~~~~~ Binds an output channel definition (see there for details) to this action. Output channel actions must start with a $-sign, e.g. if you would like to bind your output channel definition "mychannel" to the action, use "$mychannel". Output channels support template definitions like all all other actions. Shell Execute ~~~~~~~~~~~~~ **NOTE: This action is only supported for backwards compatibility. For new configs, use** :doc:`omprog ` **instead. It provides a more solid and secure solution with higher performance.** This executes a program in a subshell. The program is passed the template-generated message as the only command line parameter. Rsyslog waits until the program terminates and only then continues to run. ^program-to-execute;template The program-to-execute can be any valid executable. It receives the template string as a single parameter (argv[1]). **WARNING:** The Shell Execute action was added to serve an urgent need. While it is considered reasonable save when used with some thinking, its implications must be considered. The current implementation uses a system() call to execute the command. This is not the best way to do it (and will hopefully changed in further releases). Also, proper escaping of special characters is done to prevent command injection. However, attackers always find smart ways to circumvent escaping, so we can not say if the escaping applied will really safe you from all hassles. Lastly, rsyslog will wait until the shell command terminates. Thus, a program error in it (e.g. an infinite loop) can actually disable rsyslog. Even without that, during the programs run-time no messages are processed by rsyslog. As the IP stacks buffers are quickly overflowed, this bears an increased risk of message loss. You must be aware of these implications. Even though they are severe, there are several cases where the "shell execute" action is very useful. This is the reason why we have included it in its current form. To mitigate its risks, always a) test your program thoroughly, b) make sure its runtime is as short as possible (if it requires a longer run-time, you might want to spawn your own sub-shell asynchronously), c) apply proper firewalling so that only known senders can send syslog messages to rsyslog. Point c) is especially important: if rsyslog is accepting message from any hosts, chances are much higher that an attacker might try to exploit the "shell execute" action. Template Name ~~~~~~~~~~~~~ Every ACTION can be followed by a template name. If so, that template is used for message formatting. If no name is given, a hard-coded default template is used for the action. There can only be one template name for each given action. The default template is specific to each action. For a description of what a template is and what you can do with it, see the :doc:`template` documentation. source/configuration/lookup_tables.rst0000664000175000017500000001660113223143030017277 0ustar rgerrgerLookup Tables ============= Lookup tables are a powerful construct to obtain *class* information based on message content. It works on top of a data-file which maps key (to be looked up) to value (the result of lookup). The idea is to use a message properties (or derivatives of it) as an index into a table which then returns another value. For example, $fromhost-ip could be used as an index, with the table value representing the type of server or the department or remote office it is located in. This can be emulated using if and else-if stack, but implementing it as a dedicated component allows ``lookup`` to be made fast. The lookup tables itself exists in a separate data file (one per table). This file is loaded on Rsyslog startup and when a reload is requested. There are different types of lookup tables (identified by "type" field in json data-file). Types ^^^^^ string ------ The key to be looked up is an arbitrary string. **Match criterion**: The key must be exactly equal to index from one of the entries. array ----- The value to be looked up is an integer number from a consecutive set. The set does not need to start at zero or one, but there must be no number missing. So, for example ``5,6,7,8,9`` would be a valid set of index values, while ``1,2,4,5`` would not be (due to missing ``3``). **Match criterion**: Looked-up number(key) must be exactly equal to index from one of the entries. sparseArray ----------- The value to be looked up is an integer value, but there may be gaps inside the set of values (usually there are large gaps). A typical use case would be the matching of IPv4 address information. **Match criterion**: A match happens on the first index that is less than or equal to the looked-up key. Note that index integer numbers are represented by unsigned 32 bits. Lookup Table File Format ^^^^^^^^^^^^^^^^^^^^^^^^ Lookup table files contain a single JSON object. This object consists of a header and a table part. **Header** The header is the top-level json. It has parameters "version", "nomatch", and "type". Parameters: **version** : Version of table-definition format (so improvements in the future can be managed in a backward compatible way). **nomatch** : Value to be returned for a lookup when match fails. **type** <*string*, *array* or *sparseArray*, default: *string*> : Type of lookup-table (controls how matches are performed). **Table** This must be an array of elements, even if only a single value exists (for obvious reasons, we do not expect this to occur often). Each array element must contain two fields "index" and "value". This is a sample of how an ip-to-office mapping may look like: :: { "version" : 1, "nomatch" : "unk", "type" : "string", "table" : [ {"index" : "10.0.1.1", "value" : "A" }, {"index" : "10.0.1.2", "value" : "A" }, {"index" : "10.0.1.3", "value" : "A" }, {"index" : "10.0.2.1", "value" : "B" }, {"index" : "10.0.2.2", "value" : "B" }, {"index" : "10.0.2.3", "value" : "B" }]} Note: In the example above, if a different IP comes in, the value "unk" is returned thanks to the nomatch parameter in the first line. Lookup tables can be accessed via the ``lookup()`` built-in function. A common usage pattern is to set a local variable to the lookup result and later use that variable in templates. Lookup-table configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^ Lookup-table configuration involves a **two part setup** (definition and usage(lookup)), with an optional third part, which allows reloading table using internal trigger. lookup_table(name="" file=""...) (object) --------------------------------------------------------------- **Defines** the table(identified by the table-name) and allows user to set some properties that control behavior of the table. :: lookup_table(name="msg_per_host") Parameters: **name** : Name of the table. **file** : Path to external json database file. **reloadOnHUP** : Whether or not table should be reloaded when process receives HUP signal. A definition setting all the parameters looks like: :: lookup_table(name="host_bu" file="/var/lib/host_billing_unit_mapping.json" reloadOnHUP="on") lookup("
", ) (function) ------------------------------------ **Looks up** and returns the value that is associated with the given key (passed as ) in lookup table identified by table-name. If no match is found (according to table-type matching-criteria specified above), the "nomatch" string is returned (or an empty string if it is not defined). Parameters: **name** : Name of the table. **expr** : Key to be looked up. A ``lookup`` call looks like: :: set $.bu = lookup("host_bu", $hostname); if ($.bu == "unknown") then { .... } Some examples of different match/no-match scenarios: **string table**: :: { "nomatch" : "none", "type" : "string", "table":[ {"index" : "foo", "value" : "bar" }, {"index" : "baz", "value" : "quux" }]} Match/no-Match behaviour: ====== ============== key return ====== ============== foo bar baz quux corge none ====== ============== **array table**: :: { "nomatch" : "nothing", "type" : "array", "table":[ {"index" : 9, "value" : "foo" }, {"index" : 10, "value" : "bar" }, {"index" : 11, "value" : "baz" }]} Match/no-Match behaviour: ====== ============== key return ====== ============== 9 foo 11 baz 15 nothing 0 nothing ====== ============== **sparseArray table**: :: { "nomatch" : "no_num", "type" : "sparseArray", "table":[ {"index" : "9", "value" : "foo" }, {"index" : "11", "value" : "baz" }]} Match/no-Match behaviour: ====== ============== key return ====== ============== 8 no_num 9 foo 10 foo 11 baz 12 baz 100 baz ====== ============== reload_lookup_table("
", "") (statement) ---------------------------------------------------------- **Reloads** lookup table identified by given table name **asynchronously** (by internal trigger, as opposed to HUP). This statement isn't always useful. It needs to be used only when lookup-table-reload needs to be triggered in response to a message. Messages will continue to be processed while table is asynchronously reloaded. Note: For performance reasons, message that triggers reload should be accepted only from a trusted source. Parameters: **name** : Name of the table. **stub value** : Value to stub the table in-case reload-attempt fails. A ``reload_lookup_table`` invocation looks like: :: if ($.do_reload == "y") then { reload_lookup_table("host_bu", "unknown") } Implementation Details ^^^^^^^^^^^^^^^^^^^^^^ The lookup table functionality is implemented via efficient algorithms. The string and sparseArray lookup have O(log(n)) time complexity, while array lookup is O(1). To preserve space and, more important, increase cache hit performance, equal data values are only stored once, no matter how often a lookup index points to them. source/configuration/rsyslog_statistic_counter.rst0000664000175000017500000001144213223143030021762 0ustar rgerrgerrsyslog statistic counter ========================= Rsyslog supports statistic counters via the :doc:`impstats ` module. It is important to know that impstats and friends only provides an infrastructure where core components and plugins can register statistics counter. This FAQ entry tries to describe all counters available, but please keep in mind that there may exist that we do not know about. When interpreting rsyslog statistics, please keep in mind that statistics records are processed as regular syslog messages. As such, the statistics messages themselves increment counters when they are emitted via the regular syslog stream, which is the default (and so counters keep slowly increasing even if there is absolutely no other traffic). Also keep in mind that a busy rsyslog system is very dynamic. Most importantly, this means that the counters may not be 100% consistent, but some slight differences may exist. Avoiding such inconsistencies would be possible only at the price of a very tight locking discipline, which would cause serious performance bottlenecks. Thus, this is not done. Finally, though extremely unlikely, some counters may experience an overflow and restart at 0 for that reasons. However, most counters are 64-bit, so this is extremely unlikely. Those which are not 64 bit are typically taken from some internal data structure that uses lower bits for performance reasons and guards against overflow. The listing starts with the core component or plugin that creates the counters and than specifies various counters that exist for the sub-entities. The listing below is extended as new counters are added. Some counters probably do not exist in older releases of rsyslog. Queue ----- For each queue inside the system its own set of statistics counters is created. If there are multiple action (or main) queues, this can become a rather lengthy list. The stats record begins with the queue name (e.g. "main Q" for the main queue; ruleset queues have the name of the ruleset they are associated to, action queues the name of the action). - **size** - currently active messages in queue - **enqueued** - total number of messages enqueued into this queue since startup - **maxsize** - maximum number of active messages the queue ever held - **full** - number of times the queue was actually full and could not accept additional messages - **discarded.full** - number of messages discarded because the queue was full - **discarded.nf** - number of messages discarded because the queue was nearly full. Starting at this point, messages of lower-than-configured severity are discarded to save space for higher severity ones. Actions ------- - **processed** - total number of messages processed by this action. This includes those messages that failed actual execution (so it is a total count of messages ever seen, but not necessarily successfully processed) - **failed** - total number of messages that failed during processing. These are actually lost if they have not been processed by some other action. Most importantly in a failover chain the messages are flagged as "failed" in the failing actions even though they are forwarded to the failover action (the failover action’s "processed" count should equal to failing actions "fail" count in this scenario)a - **suspended** - (7.5.8+) – total number of times this action suspended itself. Note that this counts the number of times the action transitioned from active to suspended state. The counter is no indication of how long the action was suspended or how often it was retried. This is intentional, as the counter as it currently is permits to tell how often the action ran into a failure condition. - **suspended.duration** - (7.5.8+) – the total number of seconds this action was disabled. Note that the second count is incremented as soon as the action is suspended for another interval. As such, the time may be higher than it should be at the reporting point of time. If the pstats interval is shorter than the suspension timeout, the same suspended.duration value may be reported for successive pstats outputs. For a long-running system, this is considered a minimal difference. In general, note that this setting is not totally accurate, especially when running with multiple worker threads. In rsyslog v8, this is the total suspended time for all worker instances of this action. - **resumed** - (7.5.8+) – total number of times this action resumed itself. A resumption occurs after the action has detected that a failure condition does no longer exist. Plugins ------- :doc:`imuxsock ` :doc:`imudp ` :doc:`imtcp ` :doc:`imptcp ` :doc:`imrelp ` :doc:`impstats ` :doc:`omfile ` :doc:`omelasticsearch ` source/configuration/parser.rst0000664000175000017500000000547513223143453015750 0ustar rgerrgerParser ====== .. index:: ! parser .. _cfgobj_input: The ``parser`` object, as its name suggests, describes message parsers. Message parsers have a standard parser name, which can be used by simply loading the parser module. Only when specific parameters need to be set the parser object is needed. In that case, it is used to define a new parser name (aka "parser definition") which configures this name to use the parser module with set parameters. This is important as the ruleset() object does not support to set parser parameters. Instead, if parameters are needed, a proper parser name must be defined using the parser() object. A parser name defined via the parser() object can be used whereever a parser name can occur. Note that not all message parser modules are supported in the parser() object. The reason is that many do not have any user-selectable parameters and as such, there is no point in issuing a parser() object for them. The parser object has different parameters: - those that apply to all parser and are generally available for all of them. These are documented below. - parser-specific parameters. These are specific to a certain parser module. They are documented by the :doc:`parser module ` in question. General Parser Parameters ------------------------- Note: parameter names are case-insensitive. .. function:: name *Mandatory* This names the parser. Names starting with "rsyslog." are reserved for rsyslog use and must not be used. It is suggested to replace "rsyslog." with "custom." and keep the rest of the name descriptive. However, this is not enforced and just good practice. .. function:: type *Mandatory* The ```` is a string identifying the parser module as given it each module's documentation. Do not mistake the parser module name with its default parser name. For example, the :doc:`Cisco IOS message parser module ` parser module name is "pmciscoios", whereas it's default parser name is "rsyslog.pmciscoios". Samples ------- The following example creates a custom parser definition and uses it within a ruleset: :: module(load="pmciscoios") parser(name="custom.pmciscoios.with_origin" type="pmciscoios") ruleset(name="myRuleset" parser="custom.pmciscoios.with_origin") { ... do something here ... } The following example uses multiple parsers within a ruleset without a parser object (the order is important): :: module(load="pmaixforwardedfrom") module(load="pmlastmsg") ruleset(name="myRuleset" parser=["rsyslog.lastline","rsyslog.aixforwardedfrom","rsyslog.rfc5424","rsyslog.rfc3164"]) { ... do something here ... } A more elaborate example can also be found in the :doc:`Cisco IOS message parser module ` documentation. source/configuration/properties.rst0000664000175000017500000002363513223143030016635 0ustar rgerrgerrsyslog Properties ================== Data items in rsyslog are called "properties". They can have different origin. The most important ones are those that stem from received messages. But there are also others. Whenever you want to access data items, you need to access the respective property. Properties are used in - :doc:`templates ` - conditional statements The property name is case-insensitive (prior to 3.17.0, they were case-sensitive). Message Properties ------------------ These are extracted by rsyslog parsers from the original message. All message properties start with a letter. The following message properties exist: **msg** the MSG part of the message (aka "the message" ;)) **rawmsg** the message "as is". Should be useful for debugging and also if a message should be forwarded totally unaltered. Please notice *EscapecontrolCharactersOnReceive* is enabled by default, so it may be different from what was received in the socket. **rawmsg-after-pri** Almost the same as **rawmsg**, but the syslog PRI is removed. If no PRI was present, **rawmsg-after-pri** is identical to **rawmsg**. Note that the syslog PRI is header field that contains information on syslog facility and severity. It is enclosed in greater-than and less-than characters, e.g. "<191>". This field is often not written to log files, but usually needs to be present for the receiver to properly classify the message. There are some rare cases where one wants the raw message, but not the PRI. You can use this property to obtain that. In general, you should know that you need this format, otherwise stay away from the property. **hostname** hostname from the message **source** alias for HOSTNAME **fromhost** hostname of the system the message was received from (in a relay chain, this is the system immediately in front of us and not necessarily the original sender). This is a DNS-resolved name, except if that is not possible or DNS resolution has been disabled. **fromhost-ip** The same as fromhost, but always as an IP address. Local inputs (like imklog) use 127.0.0.1 in this property. **syslogtag** TAG from the message **programname** the "static" part of the tag, as defined by BSD syslogd. For example, when TAG is "named[12345]", programname is "named". Precisely, the programname is terminated by either (whichever occurs first): - end of tag - nonprintable character - ':' - '[' - '/' The above definition has been taken from the FreeBSD syslogd sources. Please note that some applications include slashes in the static part of the tag, e.g. "app/foo[1234]". In this case, programname is "app". If they store an absolute path name like in "/app/foo[1234]", programname will become empty (""). If you need to actually store slashes as part of the programname, you can use the global option global(parser.permitSlashInProgramName="on") to permit this. Then, a syslogtag of "/app/foo[1234]" will result in programname being "/app/foo". Note: this option is available starting at rsyslogd version 8.25.0. **pri** PRI part of the message - undecoded (single value) **pri-text** the PRI part of the message in a textual form with the numerical PRI appended in brackes (e.g. "local0.err<133>") **iut** the monitorware InfoUnitType - used when talking to a `MonitorWare `_ backend (also for `Adiscon LogAnalyzer `_) **syslogfacility** the facility from the message - in numerical form **syslogfacility-text** the facility from the message - in text form **syslogseverity** severity from the message - in numerical form **syslogseverity-text** severity from the message - in text form **syslogpriority** an alias for syslogseverity - included for historical reasons (be careful: it still is the severity, not PRI!) **syslogpriority-text** an alias for syslogseverity-text **timegenerated** timestamp when the message was RECEIVED. Always in high resolution **timereported** timestamp from the message. Resolution depends on what was provided in the message (in most cases, only seconds) **timestamp** alias for timereported **protocol-version** The contents of the PROTCOL-VERSION field from IETF draft draft-ietf-syslog-protcol **structured-data** The contents of the STRUCTURED-DATA field from IETF draft draft-ietf-syslog-protocol **app-name** The contents of the APP-NAME field from IETF draft draft-ietf-syslog-protocol **procid** The contents of the PROCID field from IETF draft draft-ietf-syslog-protocol **msgid** The contents of the MSGID field from IETF draft draft-ietf-syslog-protocol **inputname** The name of the input module that generated the message (e.g. "imuxsock", "imudp"). Note that not all modules necessarily provide this property. If not provided, it is an empty string. Also note that the input module may provide any value of its liking. Most importantly, it is **not** necessarily the module input name. Internal sources can also provide inputnames. Currently, "rsyslogd" is defined as inputname for messages internally generated by rsyslogd, for example startup and shutdown and error messages. This property is considered useful when trying to filter messages based on where they originated - e.g. locally generated messages ("rsyslogd", "imuxsock", "imklog") should go to a different place than messages generated somewhere else. **jsonmesg** *Available since rsyslog 8.3.0* The whole message object as JSON representation. Note that the JSON string will *not* include an LF and it will contain *all other message properties* specified here as respective JSON containers. It also includes all message variables in the "$!" subtree (this may be null if none are present). This property is primarily meant as an interface to other systems and tools that want access to the full property set (namely external plugins). Note that it contains the same data items potentially multiple times. For example, parts of the syslog tag will by contained in the rawmsg, syslogtag, and programname properties. As such, this property has some additional overhead. Thus, it is suggested to be used only when there is actual need for it. System Properties ----------------- These properties are provided by the rsyslog core engine. They are **not** related to the message. All system properties start with a dollar-sign. Special care needs to be taken in regard to time-related system variables: * ``timereported`` contains the timestamp that is contained within the message header. Ideally, it resembles the time when the message was created at the original sender. Depending on how long the message was in the relay chain, this can be quite old. * ``timegenerated`` contains the timestamp when the message was received by the local system. Here "received" actually means the point in time when the message was handed over from the OS to rsyslog's reception buffers, but before any actual processing takes place. This also means a message is "received" before it is placed into any queue. Note that depending on the input, some minimal processing like extraction of the actual message content from the receive buffer can happen. If multiple messages are received via the same receive buffer (a common scenario for example with TCP-based syslog), they bear the same ``timegenerated`` stamp because they actually were received at the same time. * ``$now`` is **not** from the message. It is the system time when the message is being **processed**. There is always a small difference between ``timegenerated`` and ``$now`` because processing always happens after reception. If the message is sitting inside a queue on the local system, the time difference between the two can be some seconds (e.g. due to a message burst and in-memory queueing) up to several hours in extreme cases where a message is sitting inside a disk queue (e.g. due to a database outage). The ``timereported`` property is usually older than ``timegenerated``, but may be totally different due to differences in time and time zone configuration between systems. The following system properties exist: **$bom** The UTF-8 encoded Unicode byte-order mask (BOM). This may be useful in templates for RFC5424 support, when the character set is know to be Unicode. **$myhostname** The name of the current host as it knows itself (probably useful for filtering in a generic way) Time-Related System Properties .............................. All of these system properties exist in a local time variant (e.g. \$now) and a variant that emits UTC (e.g. \$now-utc). The UTC variant is always available by appending "-utc". Note that within a single template, only the localtime or UTC variant should be used. While it is possible to mix both variants within a single template, it is **not** guaranteed that they will provide exactly the same time. The technical reason is that rsyslog needs to re-query system time when the variant is changed. Because of this, we strongly recommend not mixing both variants in the same template. Note that use in different templates will generate a consistent timestamp within each template. However, as $now always provides local system time at time of using it, time may advance and consequently different templates may have different time stamp. To avoid this, use *timegenerated* instead. **$now** The current date stamp in the format YYYY-MM-DD **$year** The current year (4-digit) **$month** The current month (2-digit) **$day** The current day of the month (2-digit) **$hour** The current hour in military (24 hour) time (2-digit) **$hhour** The current half hour we are in. From minute 0 to 29, this is always 0 while from 30 to 59 it is always 1. **$qhour** The current quarter hour we are in. Much like $HHOUR, but values range from 0 to 3 (for the four quarter hours that are in each hour) **$minute** The current minute (2-digit) source/configuration/basic_structure.rst0000664000175000017500000002155513223143453017652 0ustar rgerrgerBasic Structure =============== This section describes how rsyslog configuration basically works. Think of rsyslog as a big logging and event processing toolset. It can be considered a framework with some basic processing that is fixed in the way data flows, but is highly customizable in the details of this message flow. During configuration, this customization is done by defining and customizing the rsyslog objects. Quick overview of message flow and objects ------------------------------------------ Messages enter rsyslog with the help of input modules. Then, they are passed to a ruleset, where rules are conditionally applied. When a rule matches, the message is transferred to an action, which then does something to the message, e.g. writes it to a file, database or forwards it to a remote host. Processing Principles --------------------- - inputs submit received messages to rulesets * if the ruleset is not specifically bound, the default ruleset is used - by default, there is one ruleset (RSYSLOG_DefaultRuleset) - additional rulesets can be user-defined - each ruleset contains zero or more rules * while it is permitted to have zero rules inside a ruleset, this obviously makes no sense - a rule consists of a filter and an action list - filters provide yes/no decisions and thus control-of-flow capability - if a filter "matches" (filter says "yes"), the corresponding action list is executed. If it does not match, nothing special happens - rules are evaluated in sequence from the first to the last rule **inside** the given ruleset. No rules from unrelated rulesets are ever executed. - all rules are **always** fully evaluated, no matter if a filter matches or not (so we do **not** stop at the first match). If message processing shall stop, the "discard" action (represented by the tilde character or the stop command) must explicitly be executed. If discard is executed, message processing immediately stops, without evaluating any further rules. - an action list contains one or many actions - inside an action list no further filters are possible - to have more than one action inside a list, the ampersand character must be placed in the position of the filter, and this must immediately follow the previous action - actions consist of the action call itself (e.g. ":omusrmsg:") as well as all action-defining configuration statements ($Action... directives) - if legacy format is used (see below), $Action... directives **must** be specified in front of the action they are intended to configure - some config directives automatically refer to their previous values after being applied, others not. See the respective doc for details. Be warned that this is currently not always properly documented. - in general, rsyslog v5 is heavily outdated and its native config language is a pain. The rsyslog project strongly recommends using at least version 7, where these problems are solved and configuration is much easier. - legacy configuration statements (those starting with $) do **not** affect RainerScript objects (e.g. actions). Configuration File ------------------ Upon startup, rsyslog reads its configuration from the ``rsyslog.conf`` file by default. This file may contain references to include other config files. A different "root" configuration file can be specified via the ``-f `` rsyslogd command line option. This is usually done within some init script or similar facility. Statement Types --------------- Rsyslog supports three different types of configuration statements concurrently: - **sysklogd** - this is the plain old format, taught everywhere and still pretty useful for simple use cases. Note that some constructs are no longer supported because they are incompatible with newer features. These are mentioned in the compatibility docs. - **legacy rsyslog** - these are statements that begin with a dollar sign. They set some (case-insensitive) configuration parameters and modify e.g. the way actions operate. This is the only format supported in pre-v6 versions of rsyslog. It is still fully supported in v6 and above. Note that some plugins and features may still only be available through legacy format (because plugins need to be explicitly upgraded to use the new style format, and this hasn't happened to all plugins). - **RainerScript** - the new style format. This is the best and most precise format to be used for more complex cases. As with the legacy format, RainerScript parameters are also case-insensitive. The rest of this page assumes RainerScript based rsyslog.conf. The rsyslog.conf files consists of statements. For old style (sysklogd & legacy rsyslog), lines do matter. For new style (RainerScript) line spacing is irrelevant. Most importantly, this means with new style actions and all other objects can split across lines as users want to. Recommended use of Statement Types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In general it is recommended to use RainerScript type statements, as these provide clean and easy to read control-of-flow as well as no doubt about which parameters are active. They also have no side-effects with include files, which can be a major obstacle with legacy rsyslog statements. For very simple things sysklogd statement types are still suggested, especially if the full config consists of such simple things. The classical sample is writing to files (or forwarding) via priority. In sysklogd, this looks like: :: mail.info /var/log/mail.log mail.err @server.example.net This is hard to beat in simplicity, still being taught in courses and a lot of people know this syntax. It is perfectly fine to use these constructs even in newly written config files. **As a rule of thumb, RainerScript config statements should be used when** - configuration parameters are required (e.g. the ``Action...`` type of legacy statements) - more elaborate control-of-flow is required (e.g. when multiple actions must be nested under the same condition) It is usually **not** recommended to use rsyslog legacy config format (those directives starting with a dollar sign). However, a few settings and modules have not yet been converted to RainerScript. In those cases, the legacy syntax must be used. Comments -------- There are two types of comments: - **#-Comments** - start with a hash sign (#) and run to the end of the line - **C-style Comments** - start with /\* and end with \*/, just like in the C programming language. They can be used to comment out multiple lines at once. Comment nesting is not supported, but #-Comments can be contained inside a C-style comment. Processing Order ---------------- Directives are processed from the top of rsyslog.conf to the bottom. Order matters. For example, if you stop processing of a message, obviously all statements after the stop statement are never evaluated. Flow Control Statements ~~~~~~~~~~~~~~~~~~~~~~~ Flow control is provided by: - :doc:`Control Structures <../rainerscript/control_structures>` - :doc:`Filter Conditions ` Data Manipulation Statements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Data manipulation is achieved by **set**, **unset** and **reset** statements which are :doc:`documented here in detail <../rainerscript/variable_property_types>`. Inputs ------ Every input requires an input module to be loaded and a listener defined for it. Full details can be found inside the :doc:`rsyslog modules ` documentation. Once loaded, inputs are defined via the **input()** object. Outputs ------- Outputs are also called "actions". A small set of actions is pre-loaded (like the output file writer, which is used in almost every rsyslog.conf), others must be loaded just like inputs. An action is invoked via the **action(type="type" ...)** object. Type is mandatory and must contain the name of the plugin to be called (e.g. "omfile" or "ommongodb"). Other parameters may be present. Their type and use depends on the output plugin in question. Rulesets and Rules ------------------ Rulesets and rules form the basis of rsyslog processing. In short, a rule is a way how rsyslog shall process a specific message. Usually, there is a type of filter (if-statement) in front of the rule. Complex nesting of rules is possible, much like in a programming language. Rulesets are containers for rules. A single ruleset can contain many rules. In the programming language analogy, one may think of a ruleset like being a program. A ruleset can be "bound" (assigned) to a specific input. In the analogy, this means that when a message comes in via that input, the "program" (ruleset) bound to it will be executed (but not any other!). There is detailed documentation available for :doc:`rsyslog rulesets <../concepts/multi_ruleset>`. For quick reference, rulesets are defined as follows: :: ruleset(name="rulesetname") { action(type="omfile" file="/path/to/file") action(type="..." ...) /* and so on... */ } source/configuration/index.rst0000664000175000017500000000315413223143453015553 0ustar rgerrgerConfiguration ============= **Rsyslogd is configured via the rsyslog.conf file**, typically found in ``/etc``. By default, rsyslogd reads the file ``/etc/rsyslog.conf``. This can be changed by a command line option. Note that **configurations can be built interactively** via the online `rsyslog configuration builder `_ tool. .. toctree:: :maxdepth: 2 conf_formats sysklogd_format basic_structure templates properties property_replacer filters ../rainerscript/index actions input parser timezone examples index_directives rsyslog_statistic_counter modules/index output_channels droppriv ipv6 cryprov_gcry dyn_stats lookup_tables `Configuration file examples can be found in the rsyslog wiki `_. Also keep the `rsyslog config snippets `_ on your mind. These are ready-to-use real building blocks for rsyslog configuration. There is also one sample file provided together with the documentation set. If you do not like to read, be sure to have at least a quick look at :download:`rsyslog-example.conf `. While rsyslogd contains enhancements over standard syslogd, efforts have been made to keep the configuration file as compatible as possible. While, for obvious reasons, :doc:`enhanced features <../features>` require a different config file syntax, rsyslogd should be able to work with a standard syslog.conf file. This is especially useful while you are migrating from syslogd to rsyslogd. source/configuration/timezone.rst0000664000175000017500000000426013223143453016275 0ustar rgerrgertimezone ======== .. index:: ! timezone .. _cfgobj_input: The ``timezone`` object, as its name suggests, describes timezones. Currently, they are used by message parser modules to interpret timestamps that contain timezone information via a timezone string (but not an offset, e.g. "CET" but not "-01:00"). The object describes an UTC offset for a given timezone ID. Each timestamp object adds the zone definition to a global table with timezone information. Duplicate IDs are forbidden, but the same offset may be used with multiple IDs. As with other configuration objects, parameters for this object are case-insensitive. Parameters ---------- .. function:: id *Mandatory* This identifies the timezone. Note that this id must match the zone name as reported within the timestamps. Different devices and vendors use different, often non-standard, names and so it is important to use the actual ids that messages contain. For multiple devices, this may mean that you may need to include multiple definitions, each one with a different id, for the same time zone. For example, it is seen that some devices report "CEST" for central European daylight savings time while others report "METDST" for it. .. function:: offset <[+/-]>: *Mandatory* This defines the timezone offset over UTC. It must always be 6 characters and start with a "+" (east of UTC) or "-" (west uf UTC) followed by a two-digit hour offset, a colon and a two-digit minute offset. Hour offsets can be in the range from zero to twelve, minute offsets in the range from zero to 59. Any other format is invalid. Sample ------ The following sample defines UTC time. From rsyslog PoV, it doesn't matter if a plus or minus offset prefix is used. For consistency, plus is suggested. :: timezone(id="UTC" offset="+00:00") The next sample defines some common timezones: :: timezone(id="CET" offset="+01:00") timezone(id="CEST" offset="+02:00") timezone(id="METDST" offset="+02:00") # duplicate to support differnt formats timezone(id="EST" offset="-05:00") timezone(id="EDT" offset="-04:00") timezone(id="PST" offset="-08:00") timezone(id="PDT" offset="-07:00") source/configuration/filters.rst0000664000175000017500000003145113223143453016115 0ustar rgerrgerFilter Conditions ================= Rsyslog offers four different types "filter conditions": - "traditional" severity and facility based selectors - property-based filters - expression-based filters - BSD-style blocks (not upward compatible) Selectors --------- **Selectors are the traditional way of filtering syslog messages.** They have been kept in rsyslog with their original syntax, because it is well-known, highly effective and also needed for compatibility with stock syslogd configuration files. If you just need to filter based on priority and facility, you should do this with selector lines. They are **not** second-class citizens in rsyslog and offer the best performance for this job. The selector field itself again consists of two parts, a facility and a priority, separated by a period (".''). Both parts are case insensitive and can also be specified as decimal numbers, but don't do that, you have been warned. Both facilities and priorities are described in syslog(3). The names mentioned below correspond to the similar LOG\_-values in /usr/include/syslog.h. The facility is one of the following keywords: auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7. The keyword security should not be used anymore and mark is only for internal use and therefore should not be used in applications. Anyway, you may want to specify and redirect these messages here. The facility specifies the subsystem that produced the message, i.e. all mail programs log with the mail facility (LOG\_MAIL) if they log using syslog. The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg). The keywords error, warn and panic are deprecated and should not be used anymore. The priority defines the severity of the message. The behavior of the original BSD syslogd is that all messages of the specified priority and higher are logged according to the given action. Rsyslogd behaves the same, but has some extensions. In addition to the above mentioned names the rsyslogd(8) understands the following extensions: An asterisk ("\*'') stands for all facilities or all priorities, depending on where it is used (before or after the period). The keyword none stands for no priority of the given facility. You can specify multiple facilities with the same priority pattern in one statement using the comma (",'') operator. You may specify as much facilities as you want. Remember that only the facility part from such a statement is taken, a priority part would be skipped. Multiple selectors may be specified for a single action using the semicolon (";'') separator. Remember that each selector in the selector field is capable to overwrite the preceding ones. Using this behavior you can exclude some priorities from the pattern. Rsyslogd has a syntax extension to the original BSD source, that makes its use more intuitively. You may precede every priority with an equals sign ("='') to specify only this single priority and not any of the above. You may also (both is valid, too) precede the priority with an exclamation mark ("!'') to ignore all that priorities, either exact this one or this and any higher priority. If you use both extensions than the exclamation mark must occur before the equals sign, just use it intuitively. Property-Based Filters ---------------------- Property-based filters are unique to rsyslogd. They allow to filter on any property, like HOSTNAME, syslogtag and msg. A list of all currently-supported properties can be found in the :doc:`property replacer documentation ` (but keep in mind that only the properties, not the replacer is supported). With this filter, each properties can be checked against a specified value, using a specified compare operation. A property-based filter must start with a colon **in column 1**. This tells rsyslogd that it is the new filter type. The colon must be followed by the property name, a comma, the name of the compare operation to carry out, another comma and then the value to compare against. This value must be quoted. There can be spaces and tabs between the commas. Property names and compare operations are case-sensitive, so "msg" works, while "MSG" is an invalid property name. In brief, the syntax is as follows: ``:property, [!]compare-operation, "value"`` Compare-Operations ~~~~~~~~~~~~~~~~~~ The following **compare-operations** are currently supported: **contains** Checks if the string provided in value is contained in the property. There must be an exact match, wildcards are not supported. **isequal** Compares the "value" string provided and the property contents. These two values must be exactly equal to match. The difference to contains is that contains searches for the value anywhere inside the property value, whereas all characters must be identical for isequal. As such, isequal is most useful for fields like syslogtag or FROMHOST, where you probably know the exact contents. **startswith** Checks if the value is found exactly at the beginning of the property value. For example, if you search for "val" with ``:msg, startswith, "val"`` it will be a match if msg contains "values are in this message" but it won't match if the msg contains "There are values in this message" (in the later case, *"contains"* would match). Please note that "startswith" is by far faster than regular expressions. So even once they are implemented, it can make very much sense (performance-wise) to use "startswith". **regex** Compares the property against the provided POSIX BRE regular expression. **ereregex** Compares the property against the provided POSIX ERE regular expression. You can use the bang-character (!) immediately in front of a compare-operation, the outcome of this operation is negated. For example, if msg contains "This is an informative message", the following sample would not match: ``:msg, contains, "error"`` but this one matches: ``:msg, !contains, "error"`` Using negation can be useful if you would like to do some generic processing but exclude some specific events. You can use the discard action in conjunction with that. A sample would be: :: *.* /var/log/allmsgs-including-informational.log :msg, contains, "informational"  ~ *.* /var/log/allmsgs-but-informational.log Do not overlook the tilde in line 2! In this sample, all messages are written to the file allmsgs-including-informational.log. Then, all messages containing the string "informational" are discarded. That means the config file lines below the "discard line" (number 2 in our sample) will not be applied to this message. Then, all remaining lines will also be written to the file allmsgs-but-informational.log. Value Part ~~~~~~~~~~ **Value** is a quoted string. It supports some escape sequences: \\" - the quote character (e.g. "String with \\"Quotes\\"") \\\\ - the backslash character (e.g. "C:\\\\tmp") Escape sequences always start with a backslash. Additional escape sequences might be added in the future. Backslash characters **must** be escaped. Any other sequence then those outlined above is invalid and may lead to unpredictable results. Probably, "msg" is the most prominent use case of property based filters. It is the actual message text. If you would like to filter based on some message content (e.g. the presence of a specific code), this can be done easily by: ``:msg, contains, "ID-4711"`` This filter will match when the message contains the string "ID-4711". Please note that the comparison is case-sensitive, so it would not match if "id-4711" would be contained in the message. ``:msg, regex, "fatal .* error"`` This filter uses a POSIX regular expression. It matches when the string contains the words "fatal" and "error" with anything in between (e.g. "fatal net error" and "fatal lib error" but not "fatal error" as two spaces are required by the regular expression!). Getting property-based filters right can sometimes be challenging. In order to help you do it with as minimal effort as possible, rsyslogd spits out debug information for all property-based filters during their evaluation. To enable this, run rsyslogd in foreground and specify the "-d" option. Boolean operations inside property based filters (like 'message contains "ID17" or message contains "ID18"') are currently not supported (except for "not" as outlined above). Please note that while it is possible to query facility and severity via property-based filters, it is far more advisable to use classic selectors (see above) for those cases. Expression-Based Filters ------------------------ Expression based filters allow filtering on arbitrary complex expressions, which can include boolean, arithmetic and string operations. Expression filters will evolve into a full configuration scripting language. Unfortunately, their syntax will slightly change during that process. So if you use them now, you need to be prepared to change your configuration files some time later. However, we try to implement the scripting facility as soon as possible (also in respect to stage work needed). So the window of exposure is probably not too long. Expression based filters are indicated by the keyword "if" in column 1 of a new line. They have this format: :: if expr then action-part-of-selector-line "if" and "then" are fixed keywords that mus be present. "expr" is a (potentially quite complex) expression. So the :doc:`expression documentation <../rainerscript/expressions>` for details. "action-part-of-selector-line" is an action, just as you know it (e.g. "/var/log/logfile" to write to that file). BSD-style Blocks ---------------- **Note:** rsyslog v7+ does no longer support BSD-style blocks for technical reasons. So it is strongly recommended **not** to use them. Rsyslogd supports BSD-style blocks inside rsyslog.conf. Each block of lines is separated from the previous block by a program or hostname specification. A block will only log messages corresponding to the most recent program and hostname specifications given. Thus, a block which selects ‘ppp’ as the program, directly followed by a block that selects messages from the hostname ‘dialhost’, then the second block will only log messages from the ppp program on dialhost. A program specification is a line beginning with ‘!prog’ and the following blocks will be associated with calls to syslog from that specific program. A program specification for ‘foo’ will also match any message logged by the kernel with the prefix ‘foo: ’. Alternatively, a program specification ‘-foo’ causes the following blocks to be applied to messages from any program but the one specified. A hostname specification of the form ‘+hostname’ and the following blocks will be applied to messages received from the specified hostname. Alternatively, a hostname specification ‘-hostname’ causes the following blocks to be applied to messages from any host but the one specified. If the hostname is given as ‘@’, the local hostname will be used. (NOT YET IMPLEMENTED) A program or hostname specification may be reset by giving the program or hostname as ‘\*’. Please note that the "#!prog", "#+hostname" and "#-hostname" syntax available in BSD syslogd is not supported by rsyslogd. By default, no hostname or program is set. Examples -------- :: *.* /var/log/file1 # the traditional way if $msg contains 'error' then /var/log/errlog # the expression-based way Right now, you need to specify numerical values if you would like to check for facilities and severity. These can be found in :rfc:`5424`. If you don't like that, you can of course also use the textual property - just be sure to use the right one. As expression support is enhanced, this will change. For example, if you would like to filter on message that have facility local0, start with "DEVNAME" and have either "error1" or "error0" in their message content, you could use the following filter: :: if $syslogfacility-text == 'local0' and $msg startswith 'DEVNAME' and ($msg contains 'error1' or $msg contains 'error0') then /var/log/somelog Please note that the above must all be on one line! And if you would like to store all messages except those that contain "error1" or "error0", you just need to add a "not": :: if $syslogfacility-text == 'local0' and $msg startswith 'DEVNAME' and not ($msg contains 'error1' or $msg contains 'error0') then /var/log/somelog If you would like to do case-insensitive comparisons, use "contains\_i" instead of "contains" and "startswith\_i" instead of "startswith". Note that regular expressions are currently NOT supported in expression-based filters. These will be added later when function support is added to the expression engine (the reason is that regular expressions will be a separate loadable module, which requires some more prequisites before it can be implemented). source/configuration/cryprov_gcry.rst0000664000175000017500000000625013223143010017161 0ustar rgerrgerlibgcrypt Log Crypto Provider (gcry) ==================================== **Crypto Provider Name:**    gcry **Author:** Rainer Gerhards **Supported Since:** since 7.3.10 **Description**: Provides encryption support to rsyslog. **Configuration Parameters**: Crypto providers are loaded by omfile, when the provider is selected in its "cry.providerName" parameter. Parameters for the provider are given in the omfile action instance line. This provider creates an encryption information file with the same base name but the extension ".encinfo" for each log file (both for fixed-name files as well as dynafiles). Both files together form a set. So you need to archive both in order to prove integrity. - **cry.algo** The algorithm (cipher) to be used for encryption. The default algorithm is "AES128". Currently, the following Algorithms are supported: - 3DES - CAST5 - BLOWFISH - AES128 - AES192 - AES256 - TWOFISH - TWOFISH128 - ARCFOUR - DES - SERPENT128 - SERPENT192 - SERPENT256 - RFC2268\_40 - SEED - CAMELLIA128 - CAMELLIA192 - CAMELLIA256 The actual availability of an algorithms depends on which ones are compiled into libgcrypt. Note that some versions of libgcrypt simply abort the process (rsyslogd in this case!) if a supported algorithm is select but not available due to libgcrypt build settings. There is nothing rsyslog can do against this. So in order to avoid production downtime, always check carefully when you change the algorithm. - **cry.mode** The encryption mode to be used. Default ist Cipher Block Chaining (CBC). Note that not all encryption modes can be used together with all algorithms. Currently, the following modes are supported: - ECB - CFB - CBC - STREAM - OFB - CTR - AESWRAP - **cry.key** TESTING AID, NOT FOR PRODUCTION USE. This uses the KEY specified inside rsyslog.conf. This is the actual key, and as such this mode is highly insecure. However, it can be useful for intial testing steps. This option may be removed in the future. - **cry.keyfile** Reads the key from the specified file. The file must contain the key, only, no headers or other meta information. Keyfiles can be generated via the rscrytool utility. - **cry.keyprogram** If given, the key is provided by a so-called "key program". This program is executed and must return the key (as well as some meta information) via stdout. The core idea of key programs is that using this interface the user can implement as complex (and secure) method to obtain keys as desired, all without the need to make modifications to rsyslog. **Caveats/Known Bugs:** - currently none known **Samples:** This encrypts a log file. Default parameters are used, they key is provided via a keyfile. :: action(type="omfile" file="/var/log/somelog" cry.provider="gcry" cry.keyfile="/secured/path/to/keyfile") Note that the keyfile can be generated via the rscrytool utility (see its documentation for how to actually do that). source/configuration/output_channels.rst0000664000175000017500000000643213223143453017661 0ustar rgerrgerOutput Channels --------------- Output Channels are a new concept first introduced in rsyslog 0.9.0. **As of this writing, it is most likely that they will be replaced by something different in the future.** So if you use them, be prepared to change you configuration file syntax when you upgrade to a later release. The idea behind output channel definitions is that it shall provide an umbrella for any type of output that the user might want. In essence, this is the "file" part of selector lines (and this is why we are not sure output channel syntax will stay after the next review). There is a difference, though: selector channels both have filter conditions (currently facility and severity) as well as the output destination. they can only be used to write to files - not pipes, ttys or whatever Output channels define the output definition, only. As of this build, else. If we stick with output channels, this will change over time. In concept, an output channel includes everything needed to know about an output actions. In practice, the current implementation only carries a filename, a maximum file size and a command to be issued when this file size is reached. More things might be present in future version, which might also change the syntax of the directive. Output channels are defined via an $outchannel directive. It's syntax is as follows: $outchannel name,file-name,max-size,action-on-max-size name is the name of the output channel (not the file), file-name is the file name to be written to, max-size the maximum allowed size and action-on-max-size a command to be issued when the max size is reached. This command always has exactly one parameter. The binary is that part of action-on-max-size before the first space, its parameter is everything behind that space. Please note that max-size is queried BEFORE writing the log message to the file. So be sure to set this limit reasonably low so that any message might fit. For the current release, setting it 1k lower than you expected is helpful. The max-size must always be specified in bytes - there are no special symbols (like 1k, 1m,...) at this point of development. Keep in mind that $outchannel just defines a channel with "name". It does not activate it. To do so, you must use a selector line (see below). That selector line includes the channel name plus an $ sign in front of it. A sample might be: \*.\* :omfile:$mychannel In its current form, output channels primarily provide the ability to size-limit an output file. To do so, specify a maximum size. When this size is reached, rsyslogd will execute the action-on-max-size command and then reopen the file and retry. The command should be something like a `log rotation script `_ or a similar thing. If there is no action-on-max-size command or the command did not resolve the situation, the file is closed and never reopened by rsyslogd (except, of course, by huping it). This logic was integrated when we first experienced severe issues with files larger 2gb, which could lead to rsyslogd dumping core. In such cases, it is more appropriate to stop writing to a single file. Meanwhile, rsyslogd has been fixed to support files larger 2gb, but obviously only on file systems and operating system versions that do so. So it can still make sense to enforce a 2gb file size limit. source/configuration/modules/0000775000175000017500000000000013224663364015370 5ustar rgerrgersource/configuration/modules/idx_input.rst0000664000175000017500000000040513223143010020100 0ustar rgerrgerInput Modules ------------- Input modules are used to gather messages from various sources. They interface to message generators. They are generally defined via the :doc:`input <../input>` configuration object. .. toctree:: :glob: :maxdepth: 1 im* source/configuration/modules/pmrfc3164.rst0000664000175000017500000000566713223143453017554 0ustar rgerrgerpmrfc3164: Parse RFC3164-formatted messages =========================================== Author: Rainer Gerhards This parser module is for parsing messages according to the traditional/legacy syslog standard :rfc:`3164` It is part of the default parser chain. The parser can also be customized to allow the parsing of specific formats, if they occur. Parser Parameters ----------------- Note: parameter names are case-insensitive. .. function:: permit.squareBracketsInHostname **Default**: off This setting tells the parser that hostnames that are enclosed by brackets should omit the brackets. .. function:: permit.slashesInHostname **Default**: off Available since: 8.20.0 This setting tells the parser that hostnames may contain slashes. This is useful when messages e.g. from a syslog-ng releay chain are received. Syslog-ng puts the various relay hosts via slashes into the hostname field. .. function:: permit.AtSignsInHostname **Default**: off Available since: 8.25.0 This setting tells the parser that hostnames may contain at-signs. This is useful when messages are relayed from a syslog-ng server in rfc3164 format. The hostname field sent by syslog-ng may be prefixed by the source name followed by an at-sign character. .. function:: force.tagEndingByColon **Default**: off Available since: 8.25.0 This setting tells the parser that tag need to be ending by colon to be valid. In others case, the tag is set to dash ("-") without changing message. .. function:: remove.msgFirstSpace **Default**: off Available since: 8.25.0 rfc3164 tell message is directly after tag including first white space. This option tell to remove the first white space in message just after reading. It make rfc3164 & rfc5424 syslog messages working in a better way. .. function:: detect.YearAfterTimestamp **Default**: off Some devices send syslog messages in a format that is similar to RFC3164, but they also attach the year to the timestamp (which is not compliant to the RFC). With regular parsing, the year would be recognized to be the hostname and the hostname would become the syslogtag. This setting should prevent this. It is also limited to years between 2000 and 2099, so hostnames with numbers as their name can still be recognized correctly. But everything in this range will be detected as a year. Example ------- We assume a scenario where some of the devices send malformed RFC3164 messages. The parser module will automatically detect the malformed sections and parse them accordingly. :: module(load="imtcp") input(type="imtcp" port="514" ruleset="customparser") parser(name="custom.rfc3164" type="pmrfc3164" permit.squareBracketsInHostname="on" detect.YearAfterTimestamp="on") ruleset(name="customparser" parser="custom.rfc3164") { ... do processing here ... } source/configuration/modules/omjournal.rst0000664000175000017500000000222013223143453020113 0ustar rgerrgeromjournal: Systemd Journal Output ================================== **Module Name:    omjournal** **Author:**\ Rainer Gerhards **Description**: This module provides native support for logging to the systemd journal. **Action Parameters**: Note: parameter names are case-insensitive. - **template** Template to use when submitting messages. By default, rsyslog will use the incoming %msg% as the MESSAGE field of the journald entry, and include the syslog tag and priority. You can override the default formatting of the message, and include custom fields with a template. Complex fields in the template (eg. json entries) will be added to the journal as json text. Other fields will be coerced to strings. Journald requires that you include a template parameter named MESSAGE. **Sample:** The following sample writes all syslog messages to the journal with a custom EVENT_TYPE field. :: module(load="omjournal") template(name="journal" type="list") { constant(value="Something happened" outname="MESSAGE") property(name="$!event-type" outname="EVENT_TYPE") } action(type="omjournal" template="journal") source/configuration/modules/pmnormalize.rst0000664000175000017500000000475313223143453020457 0ustar rgerrgerLog Message Normalization Parser Module (pmnormalize) ===================================================== **Module Name:    pmnormalize** **Available since:** 8.27.0 **Author:** Pascal Withopf **Description**: This parser normalizes messages with the specified rules and populates the properties for further use. Action Parameters ~~~~~~~~~~~~~~~~~ Note: parameter names are case-insensitive. .. function:: rulebase Specifies which rulebase file is to use. If there are multiple pmnormalize instances, each one can use a different file. However, a single instance can use only a single file. This parameter or **rule** MUST be given, because normalization can only happen based on a rulebase. It is recommended that an absolute path name is given. Information on how to create the rulebase can be found in the `liblognorm manual `_. .. function:: rule Contains an array of strings which will be put together as the rulebase. This parameter or **rulebase** MUST be given, because normalization can only happen based on a rulebase. .. function:: undefinedpropertyerror **Default: off** With this parameter an error message is controlled, which will be put out every time pmnormalize can't normalize a message. See Also ~~~~~~~~ Caveats/Known Bugs ~~~~~~~~~~~~~~~~~~ None known at this time. Example ~~~~~~~ **Sample 1:** In this sample messages are received via imtcp. Then they are normalized with the given rulebase and written to a file. :: module(load="imtcp") module(load="pmnormalize") input(type="imtcp" port="13514" ruleset="ruleset") parser(name="custom.pmnormalize" type="pmnormalize" rulebase="/tmp/rules.rulebase") ruleset(name="ruleset" parser="custom.pmnormalize") { action(type="omfile" file="/tmp/output") } **Sample 2:** In this sample messages are received via imtcp. Then they are normalized with the given rule array. After that they are written in a file. :: module(load="imtcp") module(load="pmnormalize") input(type="imtcp" port="10514" ruleset="outp") parser(name="custom.pmnormalize" type="pmnormalize" rule=[ "rule=:<%pri:number%> %fromhost-ip:ipv4% %hostname:word% %syslogtag:char-to:\\x3a%: %msg:rest%", "rule=:<%pri:number%> %hostname:word% %fromhost-ip:ipv4% %syslogtag:char-to:\\x3a%: %msg:rest%"]) ruleset(name="outp" parser="custom.pmnormalize") { action(type="omfile" File="/tmp/output") } source/configuration/modules/imgssapi.rst0000664000175000017500000000315313223143453017727 0ustar rgerrgerimgssapi: GSSAPI Syslog Input Module ==================================== Provides the ability to receive syslog messages from the network protected via Kerberos 5 encryption and authentication. This module also accept plain tcp syslog messages on the same port if configured to do so. If you need just plain tcp, use :doc:`imtcp ` instead. Note: This is a contributed module, which is not supported by the rsyslog team. We recommend to use RFC5425 TLS-protected syslog instead. **Author:**\ varmojfekoj .. toctree:: :maxdepth: 1 gssapi Configuration Parameters ------------------------ Note: parameter names are case-insensitive. .. function:: $InputGSSServerRun Starts a GSSAPI server on selected port - note that this runs independently from the TCP server. .. function:: $InputGSSServerServiceName The service name to use for the GSS server. .. function:: $InputGSSServerPermitPlainTCP on\|off Permits the server to receive plain tcp syslog (without GSS) on the same port .. function:: $InputGSSServerMaxSessions Sets the maximum number of sessions supported .. function:: $InputGSSServerKeepAlive on\|off *Requires: 8.5.0 or above* *Default: off* Enables or disable keep-alive handling. Caveats/Known Bugs ------------------ - module always binds to all interfaces - only a single listener can be bound Example ------- This sets up a GSS server on port 1514 that also permits to receive plain tcp syslog messages (on the same port): :: $ModLoad imgssapi # needs to be done just once $InputGSSServerRun 1514 $InputGSSServerPermitPlainTCP on source/configuration/modules/mmcount.rst0000664000175000017500000000312213223143453017571 0ustar rgerrgermmcount ======= **Module Name:    mmcount** **Author:**\ Bala.FA **Status:**\ Non project-supported module - contact author or rsyslog mailing list for questions **Available since**: 7.5.0 **Description**: :: mmcount: message modification plugin which counts messages This module provides the capability to count log messages by severity or json property of given app-name. The count value is added into the log message as json property named 'mmcount' Example usage of the module in the configuration file module(load="mmcount") # count each severity of appname gluster action(type="mmcount" appname="gluster") # count each value of gf_code of appname gluster action(type="mmcount" appname="glusterd" key="!gf_code") # count value 9999 of gf_code of appname gluster action(type="mmcount" appname="glusterfsd" key="!gf_code" value="9999") # send email for every 50th mmcount if $app-name == 'glusterfsd' and $!mmcount <> 0 and $!mmcount % 50 == 0 then { $ActionMailSMTPServer smtp.example.com $ActionMailFrom rsyslog@example.com $ActionMailTo glusteradmin@example.com $template mailSubject,"50th message of gf_code=9999 on %hostname%" $template mailBody,"RSYSLOG Alert\r\nmsg='%msg%'" $ActionMailSubject mailSubject $ActionExecOnlyOnceEveryInterval 30 :ommail:;RSYSLOG_SyslogProtocol23Format } source/configuration/modules/omkafka.rst0000664000175000017500000001377613223143453017540 0ustar rgerrgeromkafka: write to Apache Kafka ============================== =========================== =========================================================================== **Module Name:** **omkafka** **Author:** `Rainer Gerhards `_ **Available since:** v8.7.0 =========================== =========================================================================== The omkafka plug-in implements an Apache Kafka producer, permitting rsyslog to write data to Kafka. Configuration Parameters ------------------------ Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. Currently none. Action Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. Note that omkafka supports some *Array*-type parameters. While the parameter name can only be set once, it is possible to set multiple values with that single parameter. For example, to select "snappy" compression, you can use :: action(type="omkafka" topic="mytopic" confParam="compression.codec=snappy") which is equivalent to :: action(type="omkafka" topic="mytopic" confParam=["compression.codec=snappy"]) To specify multiple values, just use the bracket notation and create a comma-delimited list of values as shown here: :: action(type="omkafka" topic="mytopic" confParam=["compression.codec=snappy", "socket.timeout.ms=5", "socket.keepalive.enable=true"] ) .. function:: broker [brokers] *Type:* Array *Default: "localhost:9092"* Specifies the broker(s) to use. .. function:: topic [topicName] *Mandatory* Specifies the topic to produce to. .. function:: key [key] *Default: none* Kafka key to be used for all messages. .. function:: dynatopic [boolean] *Default: off* If set, the topic parameter becomes a template for which topic to produce messages to. The cache is cleared on HUP. .. function:: dynatopic.cachesize [positiveInteger] *Default: 50* If set, defines the number of topics that will be kept in the dynatopic cache. .. function:: partitions.auto [boolean] *Default: off* librdkafka provides an automatic partitioning function that will evenly split the produced messages into all partitions configured for that topic. To use, set partitions.auto="on". This is instead of specifying the number of partitions on the producer side, where it would be easier to change the kafka configuration on the cluster for number of partitions/topic vs on every machine talking to Kafka via rsyslog. If set, it will override any other partitioning scheme configured. .. function:: partitions.number [positiveInteger] *Default: none* If set, specifies how many partitions exists **and** activates load-balancing among them. Messages are distributed more or less evenly between the partitions. Note that the number specified must be correct. Otherwise, some errors may occur or some partitions may never receive data. .. function:: partitions.useFixed [positiveInteger] *Default: none* If set, specifies the partition to which data is produced. All data goes to this partition, no other partition is ever involved for this action. .. function:: errorFile [filename] *Default: none* If set, messages that could not be sent and caused an error messages are written to the file specified. This file is in JSON format, with a single record being written for each message in error. The entry contains the full message, as well as Kafka error number and reason string. The idea behind the error file is that the admin can periodically run a script that reads the error file and reacts on it. Note that the error file is kept open from when the first error occured up until rsyslog is terminated or received a HUP signal. .. function:: confParam [parameter] *Type:* Array *Default: none* Permits to specify Kafka options. Rather than offering a myriad of config settings to match the Kafka parameters, we provide this setting here as a vehicle to set any Kafka parameter. This has the big advantage that Kafka parameters that come up in new releases can immediately be used. Note that we use librdkafka for the Kafka connection, so the parameters are actually those that librdkafka supports. As of our understanding, this is a superset of the native Kafka parameters. .. function:: topicConfParam [parameter] *Type:* Array *Default: none* In essence the same as *confParam*, but for the Kafka topic. .. function:: template [templateName] *Default: template set via "template" module parameter* Sets the template to be used for this action. .. function:: closeTimeout [positiveInteger] *Default: 2000* Sets the time to wait in ms (milliseconds) for draining messages submitted to kafka-handle (provided by librdkafka) before closing it. The maximum value of closeTimeout used across all omkafka action instances is used as librdkafka unload-timeout while unloading the module (for shutdown, for instance). .. function:: resubmitOnFailure [boolean] *Default: off* *Available since: 8.28.0* If enabled, failed messages will be resubmit automatically when kafka is able to send messages again. To prevent message loss, this option should be enabled. .. function:: keepFailedMessages [boolean] *Default: off* *Available since: 8.28.0* If enabled, failed messages will be saved and loaded on shutdown/startup and resend after startup if the kafka server is able to receive messages again. This setting requires resubmitOnFailure to be enabled as well. .. function:: failedMsgFile [filename] *Default: none* *Available since: 8.28.0* Filename where the failed messages should be stored into. Needs to be set when keepFailedMessages is enabled, otherwise failed messages won't be saved. Caveats/Known Bugs ------------------ - currently none Example ------- To be added, see intro to action parameters. source/configuration/modules/gssapi.png0000664000175000017500000010546612704114446017372 0ustar rgerrgerPNG  IHDRi[0#sBITO IDATxy\w?O!SVQQTZO<(RW\vbGj=^ŵjh뱞-Q;b`~|vg$$!^χ$g>a1 C@o6 w0ȝFJNNxmyy;ux<>/H?r՟?koo߶mۨTs  CCC_@޾}{ɒ%ǏӧOQQQFFF߾}8y̙Ν;^l;9[$''#F;yH$Rm\YYٻwCBΟ?rD"1˾A0l7))&NNBpܹ'N ]xqѢE `-;e„ !!!Gݲk׮R*##ҽ{f LQ&Lp6b w6͛׿N8ѣ[oG5K`z}SN1cg={?oٲeȑxV!w5kg͚USS3w\P*BSRR>kرwY*?~<--ԩSfri,[a޼y9={xO0-Nh>;@SAVLZOh<̍`T20 Y1; y FD;ejp@ FNhi233۴icZNNN&߸`0 Nn'N7ocX~~@ HIIݻwl^dͳ-Lȝ`޽ۧOBHjj*gܱcGϞ= w١CP8`,Ӓq999&''Ӆ===;vxƍM6yzz޼yc777[nqㆎhKJJ"##bEJ%!lƌ...b&p Ҷm$Ixxw}'HΝ;ot]͗_~gϞK.m?55U..^6DRڵk`WT(s̉,//ϟ;we4#Q(2`ٜ Xvvvۍ76l@dggd B8C6q_J1wTvVm0+rܹ۷ȑ#tyfffPPP\\ӧϟ?⢺VjjQ *++bgϼ !III"ѣGAAA=4hL&m9;;믡%%%cknnѢE)))b8;;GsPUiQ @|GOQQQ@@@]]]MMM׮]$IRRkFQ*[lپ};86nH[)Jy<d; HDwtttttkkk5΄B-f҅jS3T4ȝLS.YgϞ/^`ڞ={vرڵ 111.]8pݻwL`&//&ݽӧO۶mKce'g`ipr5%b뒚ڧO2I=z4**Ν; UPl޼6 aaa˗/J֭khƎnnSL /.++S*n , r'X+;߿ 44taaaEEEqqq!!!]vի`%%%6mrww\wJ//]/..ooocOOOPY!n Q))z}ҭY!vN00w&6hp0wA4{S$1EZU 4B4ZJ3aCȝ 233_y啊 omѿq!aA^xV@lq^pAU MR4 ?b&q'X7B'RRH+tj UOڵkӦMofmmӳg4ץ{n___H4|R__3fwR[E}vYmG : jN%gNV*ɓ'^^^ L&=vXUUUzzϟ?/******8R(׮]KOOʺ{Nffffee%$$;ݻ# ;1>ۿ>ZK.gdd5kׯDAJJJ۶mtٳgBaFF!axJՕ!a4`8HhG6TՍrb/۴i /ӅTk*j7˚;kڲAv!??"ԊSmtOtq;`Fȝ6úV\pVܷo_ii?0 Q)I4iNB'}VS%g1bDrrrIIɤIf͚E'7MTA>{Lj8wJw ڎ@3C4L``__ڨV$H:j3gۋba\\\\kxjLvZ#qu@3C41%Vc+t>x@[˦(٘ tj_M]]===vߺΟ?? @"p>gK0`@@@@Nt?N_.k!4'YS-4\נ<kc~\ 4vQ^,pN"3 FtLn‰;Kj3q!c`#V'/// @uӵk@KsA"XoooYj.]-@ci;^kE^(w2ị1в侮s);h,˯e@cBm4[ZZZppi~Nz7ݽ"##>|(339999::ݻjY!ݺuٳj'u=Z777''' \*\\\&L#<ĉ!!!bxȐ!gΜ145NgDNm~1cƨ.a+g,/߿>իW_xmVb3fLLLrwtyJJʟ{l<<<8[^|y„ ,()) 4hP[xGYp rL&[bŕ+W:B kչ75f]ID"4w$TUUĸDGGә5qj6S-n: Zz뭽{rYTsgKJILLܹss֬Ycccӳg}R666'N|qN0!,,[x3f߿gΜrٲeׯuppXhQxxurʝ;w6ھ7nl0x#5} z4}5t4k/mVZT*WZ5h <<<|ԩEEEk׮eߺua\VK*.ZHPTWW3 3k֬Ȳ8a"##'MTZZŋ7or6S!Hjkki02LZjP[Yʕ+Jڵk۷ofzt^z_a3gtܹm۶֭sssfΜɨ{G}4l0sV7S*m۶MNN?SWW1]v)ʜ Beee<%˗t-啝]VV񢢢lRYYɆ-ryyyI8b jvBƎ{_oझ9s߿auuu%%%ǙΏoZXXضm[BHNNNff+;?,I_(rŋ+W >C;;\\.KKK4KWr6S*22O>uVXXkQ2umڴDGU*cǎ6vvv޼yMuXQQqɣGzyyyyy䓕+WSw;v};Eծ]lmm#UK.EEEZ“X&6h͚5駟Fも+Vm۶A}LL͛ !TRRgϞݮ];:l׮ݜ9sӶ*rrrT ֭% :[lqqq駟^#!C=z/H$nnn۶m;t>~#NNJ~_T3W p႟_mcǎ>}Ç?iӦ;ܡ57q\旞ު'!k׮7n(((={^M<7B)ʣG6Xʣȑ#'N8|0^NwyСCuuu)))ƍSkP^^~HՅQQQ.\^qqǏ,T˹fkX-e$YUvvv> =z>x`vv6-LbŊSΚ5aO8񫯾WVV8qٳgtՕ+WFDD?+--~RRҋ/MsΉ'Zߟ;H+YVUU9;;Pٷ2_pATWVVOXΝΝ;w({{{[]OObUUU|&kص@U wZhΩAu:t;$$l9LD"HNh$\/JAM؂l˼+oseq'ĉkBsos@%NK¸Xb,aI@=+d9Wk8YָӢRf j,+wR5D5;-j-ƝRr^@e=+diNM1̫NZK!iN2N`iWk)$-Pcg,j-'_A'5[`i-N$-Pcq: Ɲ<b!i3NkZKa jv*I 44wTk ܁!sJt4B7w,96lq `zY̙3[ __UVB7lK/_턳=QfgZv?k׮{R裏ݫgϞ nӦMHHHFFƭ[^}6m7==)pxc4 ]pt?̙3ϟ??|/_0̒%K\\\9ٳ7o~7mry6m;Fwiݺu{Ќ [[0swwwmoow^`_￿k{4h6446''ch=ٚTnҭXQ{M6/_f|b?۷o3*aq6W^xٺ{P%9)))MHH`,YK.{z9Ä/o|~mmtà 1 /~ך#Gjjj_ŋ!C}iiD"Qm9cƌ &d277A-6Ç9yR erttK uuunnn35$PNև}} }D[{HrĈG>zw={0 ݷlllt; IDAT0o0}bN>&ѣG@6sww;wO{MSL9p@v EDD=uLnlmm\ҩS']ta-鳩r'ʉDe˖-Z~СJ255ѣGW_M(0~1cϘ1c͟|㝝ܢ7nܘ5kֵk9qqq^t[^Ν;m۶m۶51O;ʚ5k|||6o{u}Μ9suu]tinn_5;((}>[TSYYT*ueD{uq˖-&<8$s#` y14$OL:-`Sssϝ 'ƝZqONxI[:L;1+ਯ yhjmڴ1c7ntqqqww7c MdN|'N7oA+6҂[NEEʕ+SRRK0NXnnn %%wަ3fi{s?Y">6OrK@kq>}BRSSUsgYYW,ۄ;wvЁN󛕕Ey7kkk={9bbbjjnN:Hݾ}3!vsttڴiӧ~;k1"!!Ajl%%%b}ѢE4%KѣG;99;99g]рnwƍ=z]2eJ#~c̄%CMqt!ںuX,bF,w֍422rҤI/^y&0.\(..V(3gΤ322MKR___z֬YeeeaaaqqqjjnN h"BQ]]]\\oݺ0\.OKK{X,f@(rf :ujeeeQQQppڵk >}zUUT*  j;fW4UV)UV 4eTO0Nh!t!ٳg~~ &O.999kmۖi(|7 TUUoҥ6A)))۴i ƃ :z(0[l lnn177.?{l```EE r'g]рIKKsqqipY)l1 X"D"=zԵkѣG>}Z"ܼy"Jy<* "hȐ! n`[TTŋ_~Y"H$ÇߛŅvrr:yCCBB_Ny>L9|iӴ5Sݢ7}۱cBTjccӮ];W-89Zx 6'~u01%{k׮?a=z5X'-]__BdR m۶7;; rT{6b/h"(%%E"p6c)//wӅz;9R 8##qg })++` ˆŋ)[n):WWWByfEPaWёd:˻t꺚SAM~~3gjjjb1 NGӧOښQNNNcǎ]|yuuT*]z)SB1c/_^SS#6lؠ]89j/zf^!Ƃ[ `9S5w*55>~PPڏϟƍ7Ņxxx?~:Ǯݒ]v-]߿{Æ S]Wms!!!:RWW~ɓ'uo~Jw3j޽111^^^SL#ٳwqwwYpajjjVVVpp0L89nįZ55nv~R,0w^pA56C˸qrrrllLJRR|wՂ`w"q7۷o>}zclllu떛zI&U+$uT@73^//A&;w1̞=M6QQQ~"l ϝxJUUU5gff6֩N\0Z3[AM܉¸0ȝ1&w-fw܉u@+glœ|f alL X)c-X,wwwת  lܹ3[ϙ}PN|` `(N;q¸0ȝ*dff:99Ycmڴ1V1 FM4ݻwXCv9rdff~ܹCz{{VTTyfffPPPMMMʀyp0P󨮮^h޽{Ν{k>޽;!~1k^z%Lf(1 \N*־꫄:Cx3f߿gΜɮURR)-ZT*ƍsrr LNNֶQw١CP8`,:|۷{zzvƍ6my&G]dzwi&%-޽W$͟?_TP84˲ȝµkN"|W ׫w9tP]]]nnnJJʸqEGGo7nذa]#Rk8mŋP( ̙Y^^?we˖ussJ׿9BdcǎUUU>\s ŵkӳ޽s١qбkօX|;爽HK/嚭Z -飭ٳg.\{^{I9dȐK޿?//o…JEEEeeX,~왷7!$))iѢE򈈈{Զ: 55uԨQ#""Tﹲ{"ѣGAAA=4hL&D999ڵ#\pa„ ;vń%sssilΝ[xS4rvko^S=0oȑgΜqtt4iꀏ2s߿_T*x/>!cǎ97mH4dȐJmu@ D{{{GGGGGGveccC'!חprr:yCCBB_D[xll:t Cvͺ w@k̙.HJJ}PB{}}}^^}ӶmB<<<agggsnsu\o߾ҟ٧><<gϞBwwDDDB֯_{oVs ЩS $-!al̮Y¸$P3*33>ԼASRR|{TO0FjE.]ZC|MnrssW^=i$sG2ʝt4)+&WRR2{삂6mDEE}推e¸]wNh1td) LVPP0{lv9=KWBΟ??~k񉊊:~xNN X\ɓTvZmfffVVVBBBTTɓ' !D&]z5<<\M(ʣG+-qSk5o޼*ݽB>ãfp#0Lī`cJ:̙3__7n0 !O322!eee ä sssi_~YsEPal>ϾDnnnmVVVtttN!{NKK3haUU]^^]tіݻS5j+ҷb5;;[.k;nJKKWZJeذacŋuuujB`l0P9r^hNͫٙ@kDҕ谩V.ɡҟvi݄%KnaQQы/^~e0 ɓ''&&;611&sE@ 'Mt+VSDlv> &رC[W "6666Vp3 B0 :pW*گT*e{V]ǏݿMvvvr\.ivyO޺u+,,L)gg͛7oڴs ]0={5˫:jr'pwYɉMܶmmP( u?䓕+Wz3K.o"+&&f<OsP(ΝܱcG:w^YYI˝҅|>?hMPKwrD09l߉ҕF5[hZINhȝQϝjON(] :p%X V s# FRȝfd`YXYlz~- Lyy{{ ¡C.,omm'͛gڞ9E:uw\.޽ٳ<:V|wss))){g^zI&5Y]cظsҥvvv111 4k.???GGG//M6eW5K7)00099S­wӧ!$55UwܱcGϞ= ?~Ftehֹ5hulsk.l9gh9y5Qe2YllcǪӇN],#Rk8vOm۶I$N";w7޽;g_~={.]DKttUsk^栭>>>~6mڴIHHtjS+**|>[rٳD_ٳg~~ &O-f͚~}VtUmYUϽֶ Pr2mƔZEQ= Juu.]khF |AAA6mVvUtT*xlَ;n-** ڵkuuD"IJJR XTnٲeE_Y 6~q=Ղ5be `B]ef}_`#F$''L4i֬Y]`-9M_Ӄ\./ry``'Orf={… /_lA :g.4zA=@3Sc~aeeW_}`w6l@  ðeW?sXs aaa˗/Xn\RSSGUSSSVV-GFEE>}[V.{=l0n9w\+'wSVVVpppqqkՅ2lgbɉV%ʢEJխ_i~-1ݻKJJ<<<HkSzڧOޣ=x@#@iֹ5^kqCΝ;9}P}MG%hmI|fDOXTnh`>[q'٘p4'NKõYwEh:ƍUBm̠tbN?6f̘+WOjՎލgiB} akfBW\޽X, իWusNqq Hӑ0 <?N8, rgΜyС"0Fߪl̺,^kmш҄zt ٵk .x{{+ʭ[N::ٳgʔ)CEE!$33W^#G,[l O/^5j`ĈZ`AS ՁH:s1y& lcǎ]v]p3H9umm50`I)'n.]tOJJ2d}-JGMRdzDʔ:Jc6hʕ;w6lϷ}76nܨ{Ф$В4UlW҄ TOh {ɓ'{.++ӧŋuϟ?oܤRieeeDD,66ɓ'666ӦM[v烂TGz*..~믿nZiiin $Œf;W^yܹs<طoߑ#GT]ӗ.]By"ЇaSNr\&͜93..nZ|BHeeӧsrrVX1aBHuui)+VL:u֬YIUUgo߾NΥm`iB 43۪Uh#ꪫ !RƦ]vG[R"H$Ç7&z)mNNNJJJb`iB͊cJe}}=!D*վ9ѵD"i߾}zz:!ã}ˆ2ѧC?nZ{="XZ^I[iB";wJAB-kP(mƮZrٳgYrɓ'޽*W\y뭷XKV$T3W_!!!l{m51 gឝ;wnܸX(N8/ :޹sg7o$;W^Yp!rB\t?joo .Xoxiii:^ !ҥKmmm{dIt]tw (AFoO~AATO0rƌtR>jM7'O4=̝&;9CK4ȝФxV/233y*7ʘ Ä޾} fff9s;w4w8V&333((Ƞ_@2{Ġ J҈Mcƌ1bEz ӘZ cƝ &$Tω(ryΙq7 aCcǎ={;tXBj~I$*t\}v__3fhnW^ ,eee3fpqqofj׿ݻ}}}E"GR3O?wa[1"!!AΝ;;t   Ŷod`)J7ng5r׮]~~~^^^6m"\'=۶nw nIIɸqhdOm=hEn9s><٩yy뭷cO9-K3~8BY%%%b}ѢEVBUDW ^u3h O< EfffVVuV\\Cj'OHRZQu蚚lL`4W-6Bqڵw~.x{{{yy͛7J#i~z _ĉ5jj*lYv=N>}׮]@Gb>-aryZZ0f͊,++ xVR*V4h]=""bڴiUUUEEE  t-ZP(ٺuX,bF,w͈Q?--M"e2ڡ4iRii/n޼[Z=}T,]+(( r\jSN,** ^v-0aaaӧOJ!v@4.\(..V(3g7nf X?>VA3s͚5+))Q]thygddBWݨ7|0LUU]^^]~.][QQsrri!mRR/0Lii鯿Z__7lذy5x$9efРAGef˖-w?%%m۶:'aŋuuu ,//oӦMBB\.K2a\\\;{,=uT}}}Ϟ=/\0ydc4ι޽{:uaQF1{Bhںeuj6c|xҥ<==UcP=zJ8 l7Zri<4HlVU.V;vlvBCC 666&ЩQxʕ+'*B!krssUԨjJe^^C33Ӓw3ZBHddѣG)cbb.]4pwӞ70~gQFyyy߿ˋV4bĈ䒒I&͚5Z'ˣo }zhm#Ë<}ӧOoݺVhQ<77]^k nҥKg!g3v }Ӷmj+c'}JKKgk R`RSu:zzj>}BaDDŋʔJ[z_5</..Z&;?i*--]f=sFKH$Ç>}zxx80BsuuU(7o2 wv)''޽{;}@ wK/8??̙3555bamXP( [|yuuT*]n\tmLx;v֭ۜ9s|MH9#\g!g3iر[z)SPձ]=OtU(lN:h^^Ԟݵk-9tGEoooc4WG ԩSPPвe! bܹ;vtvvtTY3Z~ԩS9g\\\HHH׮]{;0K^Oj6xw a***xxx899lݺUmѣG €;wuׯ߳gn޼9zh FOj%˧M&%Ɍ3uy$u0 !ښ#JE"=Y 0o=۷o RvcccE"X,ffŊBcǎt+aW<=Ù;u?ڣ?5ow̌=ܝ;wڵkWWWg@LFk`*˸qrrr )zpTkiT=ƈ~'4YfyzzFk|;To>}$N, -L& ߹sg}7꛶LjO@ 1bġCL3kЪ$%% 2q%Q9۬=zd*:jrnj֭]jjE1uwy4,Kۇ&%% h隺~'N=ˢBr[2,66رcUUUÇW]]K:wV=r!$::.??~qilU!**NM{zjxxjh9d(r< ť6k׮MLLtiԩ[eZrgZZZnnݻw>@GR>@>nt@`ggRXܣGv]}N~/pttXf D0lggv PssܼyP(\bѣGzԩ2dj MD"mHH>пggg:<BJ-[}0 wD ׮]O?ɓ:⺺j6!!! @$ 2`CCBB_N[ysV$Ijn)Hhlz; !'O֌ZZ hyyX,g:p˗/%; !& -;EeI$J?rV<9qV vQSGQ+Jhp:ʀܩgYTȑ#_|ҏ:*P.JqVLS4Z"g1[ͣ`Q\֕+W6f -wѻ=zBD2eʔ?^a۷oך9 Fփ<{lv~WCjU*9kyRFe(ihNbhpVh}Ŝ̂~,g0 ִ;njtRNƍZNKQ=P9S >ABk' h0hVs!X1Nf4ml333jjj+7S:C/0wĵk>{L,o۶mZWӄ}D"DӦMj^xQu"T7}=z5j,YΠ J3miiN81~x7q/2F~gttT*`VVV>yfڴiePPPEEZ׃KKKܒϚ5-YWWx{{{Z%%%l dgg;::hj*fff!/O_WTTѷϟΪ*;;;v۷tmN޽EQe." Zj$fwYv23C܊ ]zߴ3rڙk3wzyyݻWcB*++xaaH]DMM{aa!wAr'F}vڨ(| ___cOĸR̂qL&D7n^vO?ͭh4nnn]vol5J6 Dbbڼy e˖nݺ .XsҤIY} Vʹ(V{8waPQYO6^!R­i'~Jjii)))oݻwj p;E58Q &Zt:V8q"gLJJ֭[븸3gח9Wh/"= [TTwUTTDފ]v .x5j3o>鹒,YgJOO?~XXH$eobgaD/DoVl'N:.##EĜO(5R"K;vs222-[vڵ]3ANdVdЩ w]YTTmܸqoF'-  wB`VAVYY' 0x^{:pVw8ǠSqw0 *:m m `U3uՙ!wXK%-OlYYY/¥Kl5>|w߽|X,6loѷo_V^^^xxT*miiܽ{7ŶlHX>[!**_~-:.$$DxN9{U\>bĈ͛7Xx 6p˗?m{L<#GL8b⡙_Ͱdɒ!C\z__fw}N Hjjjjjj&N8w\~;&?rׯ_~*Jp3g<3 .,..>|СCSތ駟.ZhӦMZbʕgϞ`>1:|Ϡӥ+DST?WTT$&&E566vr*C 4x)_/thx"]`DsqK+W]RJ޽;[k>H$gΜnS1}ZVVV@@w 7-^x޼yg~WLLLW^l22vM6㊉ٹs'_7oy衇9"1 l~ҧK%%%_}U:HIIRյ'NܴiӪU'MĭX^^^XX8hР{ӦMW6lرch .ܲe޽{W\]hSSӁ}Q͟~u:݋/o̙3x7|$33^~4߿tѣGIIIsYt`xnz'MGk`FE?_8]mIf&++ߟh <1 sرFܡ?ɠ`A~iBs +'Yr1RZQpeUUU \~]$t|j !jZgR4;;;(( # ˹&FNw)6Ço7nܸ`\bؠƍ~~~+((`d2 ӭ[7:"gL`wXO"H|}} !zY40$$NгgR"T0((Ց#GOvV<0/MhN!B~Dcs\$F![YD" !>>>>>>N#hZww)SDm۶ֲaK$V{ď>hʕvU裏~iXL4iG}o֬Y|իW/ 2 Ju.]B Z4sYBvET?ܹCW{eccٳgG-! 49,HV4&xyy455}焐&$$p'ݺu-[uXSSsС:t/7ɓ322$¿QQQ6~&𼽽 bP2QXe?NW;g˞􋏏ONN+++Yf #T[%7n[J|!С9 *'9%XZ6 ŋׯ_0ѣG|.]_^RKuuu0rw}Wp0 jZ]\\ܵkO>N\aŋ_nӧ766mݺ5((ݻc ꫯ8 3w9[ {;wnppX,:ujjj**w-;8zh_p V:4x"r鹸 K+WMv!CƎ7֭[qʕΝϛ7d2?k׮l9s>{Ly{{vm #G/WZ5{lX<|1444//O0<77#F8p`bGٿ%b8~ : gkV8EDDy>+ݫjMd??06l3WaC8pam۶%$$NfCQQm?vXDDmwssc#9q> dffv҅|`;#;w!?rJ0۷b1w.)]6m0Fڷo90 SZZP(d2X,V(RTP\pyFFƓO>}9s 4b&==駟f&&&/X 7nlz}}}}}}e2?~Nbg`!wxxxL NrRʜYXiiiWfeeeohhؼys޽q b:~nT r<33ϯAp2ﻹwjwcc?bٳg[ZZ233ys7}A f%J.]ZUUE)..>}4m} 0@0xlT$2c18_5..ͭc)fdd,[ڵkқi';ر#99ڵkt[TTf͚ISEEEhhhDDUee?_RR啔kuH,8gKp q[8g `N<\e:ĉϞ=k(BKq$X v<ٟ[/6cάY_YY!!\gm̝8mkB͟6l0a޽>H;yJ$1c߿C8w⋰C#F$Ԇd!/mߵkWhh\.?>2v&%g**,,… ]-iQ Çgddf8gY ]6~xh{ݛRQQ`=`V{BFn:Bȉ'$ چ^駟rrr\[oLPPPPQQpBVoܸqW^_QQQRRϿdbu,!"""++˜ap޵Elٲ%114wqww,bPӊ[–xᇹ3 0WTWW3 ߠ]0xas ˘07n5>_vrVO*zBL&;tCBBbbbΟ?_VVz $ !!!u=j5]F#ufҳgOZC"Bi.<A&X 9=rg(..zj7 u=''9f̘SNUVV&&&Ξ=[TzxxiZV[UUUVVFx7j&yzz655B4 wbݻwiM颢"ETܹsK.m Ncyf- >F<0 ܸ/bر>>>N9nܸ3gKbح[7:x.-HZ___QQnݺiӦq4V|dbu,ٳcǎ(H{b'øSak~gJJʧ~J,)i֣?^x!<<<&&OO޽{?bCkgdi> 2:Š222 t˞9t r;M8q="yyykhhAzz۷|M[^X8N;+NC9[˴kI5- qؿɝ N|GnΨ}ԩSwӷ~qqq2,""ԩS&ʯI5̈́ h/?*b 'lKN =Y!!!ollM?m;sΕ槟~裏L,W.&m h4ΝO 8WLuT1͡vͭo߾&lsN«aɯvd1bv777vq'NJ(g*isal1lii{u:]||ܹsMLjj.Fqssڵ+m b [a|͛IIIb8))V 3m;Ҙl˂cSRZZZJJJh{NS, :^!zT*\_]aCk;:~Im 8.;lN)#̀A'¸2;10W:Ɲ܉'NNOp&; N`z܉Nzb _0p&V}'8+N|iXo܉G%k>|L>kX5wb {;S͸p)t8kNDuw)f;1e܉ 0pbw!pnطC 81 :r'+pz3 l;mfq'ng=E-8 :s'4p}$8s {/K.^r':pK$8s {, b R+w-IpRew3pe;q0G}5c$8s ?Jpqv;YH`oONK=U`?p=N+.ήs'O' N'@`9@ąO9\.ȝ,)$N0''&w>p9RąO2$NH(Vh`N `?LpI>!qi;YH8U;qt$N0N LsIp_;w7𹓅 m q܉ mRΐ; 'n6pI>rH6Γ; 'X̩r'q̃ lW+$Nh''̝CsI>A't͝,O88%ќ|܉_'t8'ϝӵ!q@gpI>]'tȝ q@qI>] 't*ʝ5 q@gsߨ±Yq?߫qq'ѧS~% 0ǝFΤ7iW+\*WwR}: 頓Ƹn$HO$!qBgLsI qd 0s''1a VI>!ippAȝ==4scp;{& `ӐVpl;CbWp BfCό5a (_ T !k S!w¦O.ulRZYlZ=]aoRa |ȝD2q] t_}ռy,Tݶy[ԬZ*33ֱr!)V5Țv8ju``D"8p`v~ȑ'vlMMM f|A[`Ӑn׎pW7\2h B˗zƌ b鄐;wC*Bz)N'd2ݻwnܹJ?%%E_:HݱcGhh3!iiiaaa>>>[lٸq̙3ٹƌw^d*++LP(JŋiJh4&Ld2`wE޾}J pB~~~*O:c`ӵvύi"۷+ DP( Edd$}wʔ)UUU?30'O,//f͊c&77W"[F gϞ=eʔꚚTy+/^/^0VʺsBgD*jZd܅&$$>>99N >\*`hoFSSo1tV7 N և~ }64UKK#bĈV-++kll|F]UUŝRpq;%?}-:BO'B>iӦĐgϞ=KKK5[׮]ichhAZSS8n'//_~ \; = ;Swڵr=z7.///<<<**_~tNgiBp ;.?т愝y p [_ŋٳ_<{,NOOׯۗ_TN )=C֩ _5k;Wee)S R\xqSS'"""N:elܹGR4666??;>yyyر#((gϞ.\زeKPPPhh?̮ h2oٲE*]]BCCr󛚚nݺߡ `mˠkΜL?}pVVů,XLsss%ɭ[vTXXR_.J =\mmmYYYttuhɓMVWWWVV+JiW ɓz~֬Yqqq>[-77W$Ziݺuݻw_v-}=l0:W|||rrr]]F>|8ŋ hڬ,~`tɵfȐ!6l\wmO+sO8u)A.KsJO?vآErssCCC8㏳)G|W/ZާS[[P(޽BXx͛7'O wǏ/))xk9r$<3555555*KHHP(~ *B\TTD8~%K>̿ b5&vpx2gɮ;MgdVֳmƍ 0`@bb%K.\5k֬>ի| ۨhD"=BzYZZ*.8cݻ7ߤ)=|ڧ$\.'xzz:F'!$44dڼy e˖X~`b GjZp \szzuƚ:3H$3g{M_¸dSNѰ&MZbEzzzMM͚5kNJJlY-gz~֭&4iRtĉ+VHKKݴimWW\5jD"Q( [*RSSwYWWnݺiӦ .aVS: aB&&NTs{`zĉ̟ Lާhry@@z=m///0aT*ݻΝ;B޽{\R* IDAT747~nץcǎر{DEE]p"*]bzzz}}}ΝkVp&9N{9Bў222-[vڵ6BwXW^8]M)**ZfMbb#=N0}€k:"9[`}`'̝`_N8g `}'$uo` `Zm@0o?|סZ\Y;裏4hMMM/ /k\m+Il4&i_qM63fBΝT*SRR䫫g̘P(Onl2vׯ={6cٳGp.~ wt۷oOݽKp2每8pÇIOO?~ n^۳Mw}X,fq㆟9d(Jx'}||ϝ;'0+MglMܹCQI.T*Mf?iӦ1 3jԨ}K0*۳M@@^LSDi~J&l$3ԩS!}~|@kצkGQQVjUUUeee4/̠)S|7wܹxb||s[`Na+Pk4+Pu4***;FZ}цOOOA !tq 5%%%-]YT*N} 0]glll޽x~8cbb1= >^VsdãG2D"|,---6mz衇<<} ì^:<<ѣ;qD=VXAg9y$!pBvvc=Oз.\tႂtzSјa~Z͆tRO?ݻ?~H͛T*낂]vyzzٳ[tto޼8pСÇƖ'\@-p9B繍AgΜa[ۧP(ZZZ?ɓ'[wsstZÃMo ,]Ns:/ b핕bx޽p?~'B;OwwwKaZ:觞zjĈO<}=r? ƍBhKdd$}rơC>w!aTTAlׯ_oll1bA{vvvSS TWWC[G_T*?sBX,>~˗Ϝ9sܹ[> , |ݻwNLI2cV;(r6 2O0iA 4hɒ%9s;#H c>"##=<<~x={߿;|AvX|YvAgΜի;K!wZѣuVQQqx 88W_]xqKKȑ#._f]+?q}B7!D. fϞO?)ʗ_~W^J%%%7nܘ1cJJ pw}w*;-P(Ν;}vF#ˇ!֮]ۭ[[K}3gNmݺsƌ #GܼyY[wX[[Dy/_^TT/imK/s۶m)))E\x ; pD/ NZ0 r'e;, `N wX2ȝl.N|LɃoIENDB`source/configuration/modules/omudpspoof.rst0000664000175000017500000001314313223143453020306 0ustar rgerrgeromudpspoof: UDP spoofing output module ====================================== **Module Name:    omstdout** **Author:** David Lang and Rainer Gerhards **Available Since**: 5.1.3 **Description**: This module is similar to the regular UDP forwarder, but permits to spoof the sender address. Also, it enables to circle through a number of source ports. Module Parameters ----------------- Note: parameter names are case-insensitive. - **template** This setting instructs omudpspoof to use a template different from the default template for all of its actions that do not have a template specified explicitely. Action Parameters ----------------- Note: parameter names are case-insensitive. - **target** or Host that the messages shall be sent to. - **port** Remote port that the messages shall be sent to. Default is 514. - **sourcetemplate** This is the name of the template that contains a numerical IP address that is to be used as the source system IP address. While it may often be a constant value, it can be generated as usual via the property replacer, as long as it is a valid IPv4 address. If not specified, the build-in default template RSYSLOG\_omudpspoofDfltSourceTpl is used. This template is defined as follows: $template RSYSLOG\_omudpspoofDfltSourceTpl,"%fromhost-ip%" So in essence, the default template spoofs the address of the system the message was received from. This is considered the most important use case. - **sourceport.start** - **sourceport.end** Specify the start and end value for circling the source ports. Start must be less than or equal to the end value. Defaults are 32000 and 42000. - **template** This setting instructs omudpspoof to use a template different from the default template for all of its actions that do not have a template specified explicitely. - **mtu** Maximum packet length to send, default is 1500. Legacy Configuration Directives ------------------------------- - **$ActionOMOMUDPSpoofSourceNameTemplate** This is the name of the template that contains a numerical IP address that is to be used as the source system IP address. While it may often be a constant value, it can be generated as usual via the property replacer, as long as it is a valid IPv4 address. If not specified, the build-in default template RSYSLOG\_omudpspoofDfltSourceTpl is used. This template is defined as follows: $template RSYSLOG\_omudpspoofDfltSourceTpl,"%fromhost-ip%" So in essence, the default template spoofs the address of the system the message was received from. This is considered the most important use case. - **$ActionOMUDPSpoofTargetHost** Host that the messages shall be sent to. - **$ActionOMUDPSpoofTargetPort** Remote port that the messages shall be sent to. - **$ActionOMUDPSpoofDefaultTemplate** This setting instructs omudpspoof to use a template different from the default template for all of its actions that do not have a template specified explicitely. - **$ActionOMUDPSpoofSourcePortStart** Specifies the start value for circeling the source ports. Must be less than or equal to the end value. Default is 32000. - **$ActionOMUDPSpoofSourcePortEnd** Specifies the ending value for circeling the source ports. Must be less than or equal to the start value. Default is 42000. Caveats/Known Bugs ------------------ - **IPv6** is currently not supported. If you need this capability, please let us know via the rsyslog mailing list. - Throughput is MUCH smaller than when using omfwd module. Sample ------ Forward the message to 192.168.1.1, using original source and port between 10000 and 19999. :: Action ( type="omudpspoof" target="192.168.1.1" sourceport.start="10000" sourceport.end="19999" ) Forward the message to 192.168.1.1, using source address 192.168.111.111 and default ports. :: Module ( load="omudpspoof" ) Template ( name="spoofaddr" type="string" string="192.168.111.111" ) Action ( type="omudpspoof" target="192.168.1.1" sourcetemplate="spoofaddr" ) Legacy Sample ------------- The following sample forwards all syslog messages in standard form to the remote server server.example.com. The original sender's address is used. We do not care about the source port. This example is considered the typical use case for omudpspoof. :: $ModLoad omudpspoof $ActionOMUDPSpoofTargetHost server.example.com *.*      :omudpspoof: The following sample forwards all syslog messages in unmodified form to the remote server server.example.com. The sender address 192.0.2.1 with fixed source port 514 is used. :: $ModLoad omudpspoof $template spoofaddr,"192.0.2.1" $template spooftemplate,"%rawmsg%" $ActionOMUDPSpoofSourceNameTemplate spoofaddr $ActionOMUDPSpoofTargetHost server.example.com $ActionOMUDPSpoofSourcePortStart 514 $ActionOMUDPSpoofSourcePortEnd 514 *.*      :omudpspoof:;spooftemplate The following sample is similar to the previous, but uses as many defaults as possible. In that sample, a source port in the range 32000..42000 is used. The message is formatted according to rsyslog's canned default forwarding format. Note that if any parameters have been changed, the previously set defaults will be used! :: $ModLoad omudpspoof $template spoofaddr,"192.0.2.1" $ActionOMUDPSpoofSourceNameTemplate spoofaddr $ActionOMUDPSpoofTargetHost server.example.com *.*      :omudpspoof: source/configuration/modules/mmfields.rst0000664000175000017500000000713013223143453017712 0ustar rgerrgerFields Extraction Module (mmfields) =================================== **Module Name:    mmfields** **Author:**\ Rainer Gerhards **Available since**: 7.5.1 **Description**: The mmfield module permits to extract fields. It is an alternate to using the property replacer field extraction capabilities. In contrast to the property replacer, all fields are extracted as once and stored inside the structured data part (more precisely: they become Lumberjack [JSON] properties). Using this module is of special advantage if a field-based log format is to be processed, like for example CEF **and** either a large number of fields is needed or a specific field is used multiple times inside filters. In these scenarios, mmfields potentially offers better performance than the property replacer of the RainerScript field extraction method. The reason is that mmfields extracts all fields as one big sweep, whereas the other methods extract fields individually, which requires multiple passes through the same data. On the other hand, adding field content to the rsyslog property dictionary also has some overhead, so for high-performance use cases it is suggested to do some performance testing before finally deciding which method to use. This is most important if only a smaller subset of the fields is actually needed. In any case, mmfields provides a very handy and easy to use way to parse structured data into a it's individual data items. Again, a primary use case was support for CEF (Common Event Format), which is made extremely easy to do with this module. This module is implemented via the action interface. Thus it can be conditionally used depending on some prerequisites.   **Module Configuration Parameters**: Note: parameter names are case-insensitive. Currently none.   **Action Configuration Parameters**: Note: parameter names are case-insensitive. - **separator** - separatorChar (default ',') This is the character used to separate fields. Currently, only a single character is permitted, while the RainerScript method permits to specify multi-character separator strings. For CEF, this is not required. If there is actual need to support multi-character separator strings, support can relatively easy be added. It is suggested to request it on the rsyslog mailing list, together with the use case - we intend to add functionality only if there is a real use case behind the request (in the past we too-often implemented things that actually never got used). The fields are named f\ *nbr*, where *nbr* is the field number starting with one and being incremented for each field. - **jsonRoot** - path (default "!") This parameters specifies into which json path the extracted fields shall be written. The default is to use the json root object itself. **Caveats/Known Bugs:** - Currently none. **Samples:** This is a very simple use case where each message is parsed. The default separator character of comma is being used. :: module(load="mmfields") template(name="ftpl" type=string string="%$!%\\n") action(type="mmfields") action(type="omfile" file="/path/to/logfile" template="ftpl") The following sample is similar to the previous one, but this time the colon is used as separator and data is written into the "$!mmfields" json path. :: module(load="mmfields") template(name="ftpl" type=string string="%$!%\\n") action(type="mmfields" separator=":" jsonRoot="!mmfields") action(type="omfile" file="/path/to/logfile" template="ftpl") source/configuration/modules/pmrfc5424.rst0000664000175000017500000000020712704114446017541 0ustar rgerrgerpmrfc5424: Parse RFC5424-formatted messages =========================================== This is the new Syslog Standard. :rfc:`5424` source/configuration/modules/pmrfc3164sd.rst0000664000175000017500000000040012704114446020062 0ustar rgerrgerpmrfc3164sd: Parse RFC5424 structured data inside RFC3164 messages ================================================================== A contributed module for supporting RFC5424 structured data inside RFC3164 messages (not supported by the rsyslog team) source/configuration/modules/impstats.rst0000664000175000017500000002650513223143453017765 0ustar rgerrgerimpstats: Generate Periodic Statistics of Internal Counters =========================================================== **Author:**\ Rainer Gerhards This module provides periodic output of rsyslog internal counters. The set of available counters will be output as a set of syslog messages. This output is periodic, with the interval being configurable (default is 5 minutes). Be sure that your configuration records the counter messages (default is syslog.=info). Besides logging to the regular syslog stream, the module can also be configured to write statistics data into a (local) file. When logging to the regular syslog stream, impstats records are emitted just like regular log messages. As such, counters increase when processing these messages. This must be taken into consideration when testing and troubleshooting. Note that loading this module has some impact on rsyslog performance. Depending on settings, this impact may be noticeable for high-load environments, but in general the overhead is pretty light. **Note that there is a** `rsyslog statistics online analyzer `_ **available.** It can be given a impstats-generated file and will return problems it detects. Note that the analyzer cannot replace a human in getting things right, but it is expected to be a good aid in starting to understand and gain information from the pstats logs. The rsyslog website has an overview of available `rsyslog statistic counters `_. When browsing this page, please be sure to take note of which rsyslog version is required to provide a specific counter. Counters are continuously being added, and older versions do not support everything. Configuration Parameters ------------------------ The configuration parameters for this module are designed for tailoring the method and process for outputting the rsyslog statistics to file. Module Configuration Parameters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. This module supports module parameters, only. .. function:: interval\ [seconds] *Default 300 [5minutes]* Sets the interval, in **seconds** at which messages are generated. Please note that the actual interval may be a bit longer. We do not try to be precise and so the interval is actually a sleep period which is entered after generating all messages. So the actual interval is what is configured here plus the actual time required to generate messages. In general, the difference should not really matter. .. function:: facility\ [facility number] The numerical syslog facility code to be used for generated messages. Default is 5 (syslog). This is useful for filtering messages. .. function:: severity\ [severity number] The numerical syslog severity code to be used for generated messages. Default is 6 (info).This is useful for filtering messages. .. function:: resetCounters\ off/on *Defaults to off* When set to "on", counters are automatically reset after they are emitted. In that case, the contain only deltas to the last value emitted. When set to "off", counters always accumulate their values. Note that in auto-reset mode not all counters can be reset. Some counters (like queue size) are directly obtained from internal object and cannot be modified. Also, auto-resetting introduces some additional slight inaccuracies due to the multi-threaded nature of rsyslog and the fact that for performance reasons it cannot serialize access to counter variables. As an alternative to auto-reset mode, you can use rsyslog's statistics manipulation scripts to create delta values from the regular statistic logs. This is the suggested method if deltas are not necessarily needed in real-time. .. function:: format\ json/json-elasticsearch/cee/legacy *Defaults to legacy* Specifies the format of emitted stats messages. The default of "legacy" is compatible with pre v6-rsyslog. The other options provide support for structured formats (note the "cee" is actually "project lumberjack" logging). The json-elasticsearch format supports the broken ElasticSearch JSON implementation. ES 2.0 no longer supports valid JSON and disallows dots inside names. The "json-elasticsearch" format option replaces those dots by the bang ("!") character. So "discarded.full" becomes "discarded!full". This option is available starting with 8.16.0. .. function:: log.syslog\ on/off *Defaults to on* This is a boolean setting specifying if data should be sent to the usual syslog stream. This is useful if custom formatting or more elaborate processing is desired. However, output is placed under the same restrictions as regular syslog data, especially in regard to the queue position (stats data may sit for an extended period of time in queues if they are full). .. function:: log.file\ [file name] If specified, statistics data is written to the specified file. For robustness, this should be a local file. The file format cannot be customized, it consists of a date header, followed by a colon, followed by the actual statistics record, all on one line. Only very limited error handling is done, so if things go wrong stats records will probably be lost. Logging to file an be a useful alternative if for some reasons (e.g. full queues) the regular syslog stream method shall not be used solely. Note that turning on file logging does NOT turn off syslog logging. If that is desired log.syslog="off" must be explicitly set. .. function:: Ruleset [ruleset] Binds the listener to a specific :doc:`ruleset <../../concepts/multi_ruleset>`. .. function:: bracketing\ off/on *Default: off* *Requires v8.4.1 or above* This is a utility setting for folks who post-process impstats logs and would like to know the begin and end of a block of statistics. When "bracketing" is set to "on", impstats issues a "BEGIN" message before the first counter is issued, then all counter values are issued, and then an "END" message follows. As such, if and only if messages are kept in sequence, a block of stats counts can easily be identified by those BEGIN and END messages. **Note well:** in general, sequence of syslog messages is **not** strict and is not ordered in sequence of message generation. There are various occasion that can cause message reordering, some examples are: * using multiple threads * using UDP forwarding * using relay systems, especially with buffering enabled * using disk-assisted queues This is not a problem with rsyslog, but rather the way a concurrent world works. For strict order, a specific order predicate (e.g. a sufficiently fine-grained timestamp) must be used. As such, BEGIN and END records may actually indicate the begin and end of a block of statistics - or they may *not*. Any order is possible in theory. So the bracketing option does not in all cases work as expected. This is the reason why it is turned off by default. *However*, bracketing may still be useful for many use cases. First and foremost, while there are many scenarios in which messages become reordered, in practice it happens relatively seldom. So most of the time the statistics records will come in as expected and actually will be bracketed by the BEGIN and END messages. Consequently, if an application can handle occasional out-of-order delivery (e.g. by graceful degradation), bracketing may actually be a great solution. It is, however, very important to know and handle out of order delivery. For most real-world deployments, a good way to handle it is to ignore unexpected records and use the previous values for ones missing in the current block. To guard against two or more blocks being mixed, it may also be a good idea to never reset a value to a lower bound, except when that lower bound is seen consistently (which happens due to a restart). Note that such lower bound logic requires *resetCounters* to be set to off. Statistic Counter ----------------- The impstats plugin gathers some internal :doc:`statistics <../rsyslog_statistic_counter>`. They have different names depending on the actual statistics. Obviously, they do not relate to the plugin itself but rather to a broader object – most notably the rsyslog process itself. The "resource-usage" counter maintains process statistics. They base on the getrusage() system call. The counters are named like getrusage returned data members. So for details, looking them up in "man getrusage" is highly recommended, especially as value may be different depending on the platform. A getrusage() call is done immediately before the counter is emitted. The following individual counters are maintained: - **utime** - this is the user time in microseconds (thus the timeval structure combined) - **stime** - again, time given in microseconds - **maxrss** - **minflt** - **majflt** - **inblock** - **outblock** - **nvcsw** - **nivcsw** - **openfiles** number of file handles used by rsyslog; includes actual files, sockets and others Legacy Configuration Parameters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. A limited set of parameters can also be set via the legacy configuration syntax. Note that this is intended as an upward compatibility layer, so newer features are intentionally **not** available via legacy directives. - $PStatInterval - same as the "interval" parameter. - $PStatFacility - same as the "facility" parameter. - $PStatSeverity - same as the "severity" parameter. - $PStatJSON (rsyslog v6.3.8+ only) If set to on, stats messages are emitted as structured cee-enhanced syslog. If set to off, legacy format is used (which is compatible with pre v6-rsyslog). Caveats/Known Bugs ------------------ - This module MUST be loaded right at the top of rsyslog.conf, otherwise stats may not get turned on in all places. Example ------- This activates the module and records messages to /var/log/rsyslog-stats in 10 minute intervals: :: module(load="impstats" interval="600" severity="7") # to actually gather the data: syslog.=debug /var/log/rsyslog-stats In the next sample, the default interval of 5 minutes is used. However, this time stats data is NOT emitted to the syslog stream but to a local file instead. :: module(load="impstats" interval="600" severity="7" log.syslog="off" /* need to turn log stream logging off! */ log.file="/path/to/local/stats.log") And finally, we log to both the regular syslog log stream as well as a file. Within the log stream, we forward the data records to another server: :: module(load="impstats" interval="600" severity="7" log.file="/path/to/local/stats.log") syslog.=debug @central.example.net Legacy Sample ------------- This activates the module and records messages to /var/log/rsyslog-stats in 10 minute intervals: :: $ModLoad impstats $PStatInterval 600 $PStatSeverity 7 syslog.=debug /var/log/rsyslog-stats See Also -------- - `rsyslog statistics counter `_ - `impstats delayed or lost `_ - cause and cure source/configuration/modules/idx_library.rst0000664000175000017500000000054713223143030020416 0ustar rgerrgerLibrary Modules =============== Library modules provide dynamically loadable functionality for parts of rsyslog, most often for other loadable modules. They can not be user-configured and are loaded automatically by some components. They are just mentioned so that error messages that point to library modules can be understood. No module list is provided. source/configuration/modules/imtcp.rst0000664000175000017500000002633713223143453017240 0ustar rgerrgerimtcp: TCP Syslog Input Module ============================== Provides the ability to receive syslog messages via TCP. Encryption is natively provided by selecting the approprioate network stream driver and can also be provided by using `stunnel `_ (an alternative is the use the `imgssapi `_ module). **Author:**\ Rainer Gerhards Configuration Parameters ------------------------ Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: AddtlFrameDelimiter This directive permits to specify an additional frame delimiter for Multiple receivers may be configured by specifying $InputTCPServerRun multiple times. This is available since version 4.3.1, earlier versions do NOT support it. .. function:: DisableLFDelimiter on/off *Default is off* Industry-strandard plain text tcp syslog uses the LF to delimit syslog frames. However, some users brought up the case that it may be useful to define a different delimiter and totally disable LF as a delimiter (the use case named were multi-line messages). This mode is non-standard and will probably come with a lot of problems. However, as there is need for it and it is relatively easy to support, we do so. Be sure to turn this setting to "on" only if you exactly know what you are doing. You may run into all sorts of troubles, so be prepared to wrangle with that! .. function:: maxFrameSize *Default: 200000; Max: 200000000* When in octet counted mode, the frame size is given at the beginning of the message. With this parameter the max size this frame can have is specified and when the frame gets to large the mode is switched to octet stuffing. The max value this parameter can have was specified because otherwise the integer could become negative and this would result in a Segmentation Fault. .. function:: NotifyOnConnectionClose on/off *Default is off* Instructs imtcp to emit a message if the remote peer closes a connection. **Important:** This directive is global to all listeners and must be given right after loading imtcp, otherwise it may have no effect. .. function:: KeepAlive on/off *Default is off* enable of disable keep-alive packets at the tcp socket layer. The default is to disable them. .. function:: KeepAlive.Probes The number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Interval The interval between subsequential keepalive probes, regardless of what the connection has exchanged in the meantime. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Time The interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: FlowControl on/off *Default is on* This setting specifies whether some message flow control shall be exercised on the related TCP input. If set to on, messages are handled as "light delayable", which means the sender is throttled a bit when the queue becomes near-full. This is done in order to preserve some queue space for inputs that can not throttle (like UDP), but it may have some undesired effect in some configurations. Still, we consider this as a useful setting and thus it is the default. To turn the handling off, simply configure that explicitely. .. function:: MaxListeners *Default is 20* Sets the maximum number of listeners (server ports) supported. This must be set before the first $InputTCPServerRun directive. .. function:: MaxSessions *Default is 200* Sets the maximum number of sessions supported. This must be set before the first $InputTCPServerRun directive .. function:: StreamDriver.Name Selects :doc:`network stream driver <../../concepts/netstrm_drvr>` for all inputs using this module. .. function:: StreamDriver.Mode Sets the driver mode for the currently selected :doc:`network stream driver <../../concepts/netstrm_drvr>`. is driver specific. .. function:: StreamDriver.AuthMode Sets permitted peer IDs. Only these peers are able to connect to the listener. semantics depend on the currently selected AuthMode and :doc:`network stream driver <../../concepts/netstrm_drvr>`. PermittedPeers may not be set in anonymous modes. .. function:: PermittedPeer Sets permitted peer IDs. Only these peers are able to connect to the listener. semantics depend on the currently selected AuthMode and :doc:`network stream driver <../../concepts/netstrm_drvr>`. PermittedPeer may not be set in anonymous modes. PermittedPeer may be set either to a single peer or an array of peers either of type IP or name, depending on the tls certificate. Single peer: PermittedPeer="127.0.0.1" Array of peers: PermittedPeer=["test1.example.net","10.1.2.3","test2.example.net","..."] .. function:: discardTruncatedMsg on/off *Default is off* Normally when a message is truncated in octet stuffing mode the part that is cut off is processed as the next message. When this parameter is activated, the part that is cut off after a truncation is discarded and not processed. .. function:: gnutlsPriorityString *Default is NULL* *Available since 8.29.0* The GnuTLS priority strings specify the TLS session's handshake algorithms and options. These strings are intended as a user-specified override of the library defaults. If this parameter is NULL, the default settings are used. More information about priority Strings `here `_. Input Parameters ^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: Port Starts a TCP server on selected port .. function:: address *Default: all interfaces* On multi-homed machines, specifies to which local address the listerner should be bound. .. function:: Name Sets a name for the inputname property. If no name is set "imtcp" is used by default. Setting a name is not strictly necessary, but can be useful to apply filtering based on which input the message was received from. .. function:: Ruleset Binds the listener to a specific :doc:`ruleset <../../concepts/multi_ruleset>`. .. function:: SupportOctetCountedFraming on/off *Default is on* If set to "on", the legacy octed-counted framing (similar to RFC5425 framing) is activated. This should be left unchanged until you know very well what you do. It may be useful to turn it off, if you know this framing is not used and some senders emit multi-line messages into the message stream. .. function:: RateLimit.Interval [number] Specifies the rate-limiting interval in seconds. Default value is 0, which turns off rate limiting. Set it to a number of seconds (5 recommended) to activate rate-limiting. .. function:: RateLimit.Burst [number] Specifies the rate-limiting burst in number of messages. Default is 10,000. Statistic Counter ----------------- This plugin maintains :doc:`statistics <../rsyslog_statistic_counter>` for each listener. The statistic is named after the given input name (or "imtcp" if none is configured), followed by the listener port in parenthesis. For example, the counter for a listener on port 514 with no set name is called "imtcp(514)". The following properties are maintained for each listener: - **submitted** - total number of messages submitted for processing since startup Caveats/Known Bugs ------------------ - module always binds to all interfaces - can not be loaded together with `imgssapi `_ (which includes the functionality of imtcp) See also -------- - `rsyslog video tutorial on how to store remote messages in a separate file `_ (for legacy syntax, but you get the idea). Example ------- This sets up a TCP server on port 514 and permits it to accept up to 500 connections: :: module(load="imtcp" MaxSessions="500") input(type="imtcp" port="514") Note that the global parameters (here: max sessions) need to be set when the module is loaded. Otherwise, the parameters will not apply. Legacy Configuration Directives ------------------------------- .. function:: $InputTCPServerAddtlFrameDelimiter equivalent to: AddtlFrameDelimiter .. function:: $InputTCPServerDisableLFDelimiter on/off equivalent to: DisableLFDelimiter .. function:: $InputTCPServerNotifyOnConnectionClose on/off equivalent to: NotifyOnConnectionClose .. function:: $InputTCPServerKeepAlive** equivalent to: KeepAlive .. function:: $InputTCPServerKeepAlive\_probes Equivalent to: KeepAlive.Probes .. function:: $InputTCPServerKeepAlive\_intvl Equivalent to: KeepAlive.Interval .. function:: $InputTCPServerKeepAlive\_time Equivalent to: KeepAlive.Time .. function:: $InputTCPServerRun equivalent to: Port .. function:: $InputTCPFlowControl on/off equivalent to: FlowControl .. function:: $InputTCPMaxListeners equivalent to: MaxListeners .. function:: $InputTCPMaxSessions equivalent to: MaxSessions .. function:: $InputTCPServerStreamDriverMode equivalent to: StreamDriver.Mode .. function:: $InputTCPServerInputName equivalent to: Name .. function:: $InputTCPServerStreamDriverAuthMode equivalent to: StreamDriver.AuthMode .. function:: $InputTCPServerStreamDriverPermittedPeer equivalent to: PermittedPeer. .. function:: $InputTCPServerBindRuleset equivalent to: Ruleset. .. function:: $InputTCPSupportOctetCountedFraming on/off equivalent to: SupportOctetCountedFraming Caveats/Known Bugs ------------------ - module always binds to all interfaces - can not be loaded together with `imgssapi `_ (which includes the functionality of imtcp) - increasing MaxSessions and MaxListeners doesn't change MaxOpenFiles, consider increasing this global configuration parameter too (on Linux check the actual value for running process by in /proc/PID/limits; default limit on Linux is 1024) Example ------- This sets up a TCP server on port 514 and permits it to accept up to 500 connections: :: $ModLoad imtcp # needs to be done just once $InputTCPMaxSessions 500 $InputTCPServerRun 514 Note that the parameters (here: max sessions) need to be set **before** the listener is activated. Otherwise, the parameters will not apply. source/configuration/modules/ompgsql.rst0000664000175000017500000001073013223143453017574 0ustar rgerrger.. index:: ! ompgsql PostgreSQL Database Output Module (ompgsql) =========================================== ================ ========================================================================== **Module Name:** ompgsql **Author:** `Rainer Gerhards `__ and `Dan Molik `__ **Available:** 8.32+ ================ ========================================================================== **Description**: This module provides native support for logging to PostgreSQL databases. It's an alternative (with potentially superior performance) to the more generic `omlibdbi `_ module. Input parameters **************** Note: configuration parameter names are case-insensitive. .. function:: server **Default**: none **Required**: true The hostname or address of the PostgreSQL server. .. function:: port, serverport **Default**: 5432 (PostgreSQL default) The IP port of the PostgreSQL server. .. function:: db **Default**: none **Required** true The multi-tenant database name to `INSERT` rows into. .. function:: user, uid **Default**: postgres The username to connect to the PostgreSQL server with. .. function:: pass, pwd **Default**: postgres The password to connect to the PostgreSQL server with. .. function:: template **Default**: none **Required**: false The template name to use to `INSERT` rows into the database with. Valid SQL syntax is required, as the module does not perform any insertion statement checking. Examples ******** A Basic Example using the internal PostgreSQL template:: # load module module(load="ompgsql") action(type="ompgsql" server="localhost" user="rsyslog" pass="test1234" db="syslog") A Templated example:: template(name="sql-syslog" type="list" option.sql="on") { constant(value="INSERT INTO SystemEvents (message, timereported) values ('") property(name="msg") constant(value="','") property(name="timereported" dateformat="pgsql" date.inUTC="on") constant(value="')") } # load module module(load="ompgsql") action(type="ompgsql" server="localhost" user="rsyslog" pass="test1234" db="syslog" template="sql-syslog" ) An action queue and templated example:: template(name="sql-syslog" type="list" option.sql="on") { constant(value="INSERT INTO SystemEvents (message, timereported) values ('") property(name="msg") constant(value="','") property(name="timereported" dateformat="pgsql" date.inUTC="on") constant(value="')") } # load module module(load="ompgsql") action(type="ompgsql" server="localhost" user="rsyslog" pass="test1234" db="syslog" template="sql-syslog" queue.size="10000" queue.type="linkedList" queue.workerthreads="5" queue.workerthreadMinimumMessages="500" queue.timeoutWorkerthreadShutdown="1000" queue.timeoutEnqueue="10000") Building ******** To compile Rsyslog with PostgreSQL support you will need to: * install *libpq* and *libpq-dev* packages, check your package manager for the correct name. * set *--enable-pgsql* switch on configure. Legacy ****** **Action parameters** Note: parameter names are case-insensitive. **:ompgsql:database-server,database-name,database-userid,database-password** All parameters should be filled in for a successful connect. Note rsyslog contains a canned default template to write to the Postgres database. This template is: :: $template StdPgSQLFmt,"insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-pgsql%', '%timegenerated:::date-pgsql%', %iut%, '%syslogtag%')",STDSQL As you can see, the template is an actual SQL statement. Note the **STDSQL** option: it tells the template processor that the template is used for SQL processing, thus quote characters are quoted to prevent security issues. You can not assign a template without **STDSQL** to a PostgreSQL output action. If you would like to change fields contents or add or delete your own fields, you can simply do so by modifying the schema (if required) and creating your own custom template: :: $template mytemplate,"insert into SystemEvents (Message) values ('%msg%')",STDSQL :ompgsql:database-server,database-name,database-userid,database-password;mytemplate source/configuration/modules/idx_parser.rst0000664000175000017500000000062212704114446020254 0ustar rgerrgerParser Modules -------------- Parser modules are used to parse message content, once the message has been received. They can be used to process custom message formats or invalidly formatted messages. For details, please see the :doc:`rsyslog message parser documentation <../../concepts/messageparser>`. The current modules are currently provided as part of rsyslog: .. toctree:: :glob: pm* source/configuration/modules/mmanon.rst0000664000175000017500000002403413223143453017401 0ustar rgerrgerIP Address Anonymization Module (mmanon) ======================================== **Module Name**: mmanon **Author:** Rainer Gerhards **Available since**: 7.3.7 **Description**: The mmanon module permits to anonymize IP addresses. It is a message modification module that actually changes the IP address inside the message, so after calling mmanon, the original message can no longer be obtained. Note that anonymization will break digital signatures on the message, if they exist. Please note that log files can also be anonymized via `SLFA `_ after they have been created. *How are IP-Addresses defined?* We assume that an IPv4 address consists of four octets in dotted notation, where each of the octets has a value between 0 and 255, inclusively. An IPv6 is defined by being bewtween zero and eight hex values between 0 and ffff. These are separated by ':'. Leading zeros in blocks can be omitted and blocks full of zeros can be abbreviated by using '::'. However, this can ony happen once in an IP address. An IPv6 address with embedded IPv4 is an IPv6 address where the last two blocks have been replaced by an IPv4 address. (see also: RFC4291, 2.2.3)  **Module Configuration Parameters**: Note: parameter names are case-insensitive. Currently none.   **Action Confguration Parameters**: Note: parameter names are case-insensitive. Parameters starting with 'IPv4.' will configure IPv4 anonymization, while 'IPv6.' parameters do the same for IPv6 anonymization. - **ipv4.enable** - default "on" Allows to enable or disable the anonymization of IPv4 addresses. - **ipv4.mode** - default "zero" There exist the "simple", "random", "random-consitent", and "zero" modes. In simple mode, only octets as whole can be anonymized and the length of the message is never changed. This means that when the last three octets of the address 10.1.12.123 are anonymized, the result will be 10.0.00.000. This means that the length of the original octets is still visible and may be used to draw some privacy-evasive conclusions. This mode is slightly faster than the other modes, and this may matter in high throughput environments. The modes "random" and "random-consistent" are very similar, in that they both anonymize ip-addresses by randomizing the last bits (any number) of a given address. However, while "random" mode assigns a new random ip-address for every address in a message, "random-consitent" will assign the same randomized address to every instance of the same original address. The default "zero" mode will do full anonymization of any number of bits and it will also normalize the address, so that no information about the original IP address is available. So in the above example, 10.1.12.123 would be anonymized to 10.0.0.0. - **ipv4.bits** - default "16" This sets the number of bits that should be anonymized (bits are from the right, so lower bits are anonymized first). This setting permits to save network information while still anonymizing user-specific data. The more bits you discard, the better the anonymization obviously is. The default of 16 bits reflects what German data privacy rules consider as being sufficinetly anonymized. We assume, this can also be used as a rough but conservative guideline for other countries. Note: when in simple mode, only bits on a byte boundary can be specified. As such, any value other than 8, 16, 24 or 32 is invalid. If an invalid value is given, it is rounded to the next byte boundary (so we favor stronger anonymization in that case). For example, a bit value of 12 will become 16 in simple mode (an error message is also emitted). - **ipv4.replaceChar** - default "x" In simple mode, this sets the character that the to-be-anonymized part of the IP address is to be overwritten with. In any other mode the parameter is ignored if set. - **ipv6.enable** - default "on" Allows to enable or disable the anonymization of IPv6 addresses. - **ipv6.anonmode** - default "zero" This defines the mode, in which IPv6 addresses will be anonymized. There exist the "random", "random-consitent", and "zero" modes. The modes "random" and "random-consistent" are very similar, in that they both anonymize ip-addresses by randomizing the last bits (any number) of a given address. However, while "random" mode assigns a new random ip-address for every address in a message, "random-consitent" will assign the same randomized address to every instance of the same original address. The default "zero" mode will do full anonymization of any number of bits and it will also normalize the address, so that no information about the original IP address is available. Also note that an anonymmized IPv6 address will be normalized, meaning there will be no abbreviations, leading zeros will **not** be displayed, and capital letters in the hex numerals will be lowercase. - **ipv6.bits** - default "96" This sets the number of bits that should be anonymized (bits are from the right, so lower bits are anonymized first). This setting permits to save network information while still anonymizing user-specific data. The more bits you discard, the better the anonymization obviously is. The default of 96 bits reflects what German data privacy rules consider as being sufficinetly anonymized. We assume, this can also be used as a rough but conservative guideline for other countries. - **embeddedipv4.enable** - default "on" Allows to enable or disable the anonymization of IPv6 addresses with embedded IPv4. - **embeddedipv4.anonmode** - default "zero" This defines the mode, in which IPv6 addresses will be anonymized. There exist the "random", "random-consitent", and "zero" modes. The modes "random" and "random-consistent" are very similar, in that they both anonymize ip-addresses by randomizing the last bits (any number) of a given address. However, while "random" mode assigns a new random ip-address for every address in a message, "random-consitent" will assign the same randomized address to every instance of the same original address. The default "zero" mode will do full anonymization of any number of bits and it will also normalize the address, so that no information about the original IP address is available. Also note that an anonymmized IPv6 address will be normalized, meaning there will be no abbreviations, leading zeros will **not** be displayed, and capital letters in the hex numerals will be lowercase. - **embeddedipv4.bits** - default "96" This sets the number of bits that should be anonymized (bits are from the right, so lower bits are anonymized first). This setting permits to save network information while still anonymizing user-specific data. The more bits you discard, the better the anonymization obviously is. The default of 96 bits reflects what German data privacy rules consider as being sufficinetly anonymized. We assume, this can also be used as a rough but conservative guideline for other countries. **See Also** - `Howto anonymize messages that go to specific files `_ **Caveats/Known Bugs:** - will **not** anonymize addresses in the header **Samples:** In this snippet, we write one file without anonymization and another one with the message anonymized. Note that once mmanon has run, access to the original message is no longer possible (execept if stored in user variables before anonymization). :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon" ipv6.enable="off") action(type="omfile" file="/path/to/anon.log") This next snippet is almost identical to the first one, but here we anonymize the full IPv4 address. Note that by modifying the number of bits, you can anonymize different parts of the address. Keep in mind that in simple mode (used here), the bit values must match IP address bytes, so for IPv4 only the values 8, 16, 24 and 32 are valid. Also, in this example the replacement is done via asterisks instead of lower-case "x"-letters. Also keep in mind that "replacementChar" can only be set in simple mode. :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon" ipv4.bits="32" ipv4.mode="simple" replacementChar="\*" ipv6.enable="off") action(type="omfile" file="/path/to/anon.log") The next snippet is also based on the first one, but anonymizes an "odd" number of bits, 12. The value of 12 is used by some folks as a compromise between keeping privacy and still permiting to gain some more in-depth insight from log files. Note that anonymizing 12 bits may be insufficient to fulfill legal requirements (if such exist). :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon" ipv4.bits="12" ipv6.enable="off") action(type="omfile" file="/path/to/anon.log") You can also anonymize IPv4 and IPv6 in one go using a configuration like this. :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon" ipv4.bits="12" ipv6.bits="128" ipv6.anonmode="random") action(type="omfile" file="/path/to/anon.log") It is also possible to use the default configuration for both types of anonymization. This will result in IPv4 addresses being anonymized in zero mode anonymizing 16 bits. IPv6 addresses will also be anonymized in zero mode anonymizing 96 bits. :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon") action(type="omfile" file="/path/to/anon.log") Another option is to only anonymize IPv6 addresses. When doing this you have to disable IPv4 aonymization. This example will lead to only IPv6 addresses anonymized (using the random-consistent mode). :: module(load="mmanon") action(type="omfile" file="/path/to/non-anon.log") action(type="mmanon" ipv4.enable="off" ipv6.anonmode="random-consistent") action(type="omfile" file="/path/to/anon.log") source/configuration/modules/idx_output.rst0000664000175000017500000000052713223143030020310 0ustar rgerrgerOutput Modules -------------- Output modules process messages. With them, message formats can be transformed and messages be transmitted to various different targets. They are generally defined via :doc:`action <../actions>` configuration objects. .. toctree:: :glob: :maxdepth: 1 om* sigprov_gt sigprov_ksi sigprov_ksi12 source/configuration/modules/imjournal.rst0000664000175000017500000001562713223143453020124 0ustar rgerrgerimjournal: Systemd Journal Input Module ======================================= **Module Name:** imjournal **Author:** Milan Bartos (This module is **not** project-supported) **Available since**: 7.3.11 **Description**: Provides the ability to import structured log messages from systemd journal to syslog. Note that this module reads the journal database, what is considered a relativly performance-intense operation. As such, the performance of a configuration utilizing this module may be notably slower than when using `imuxsock `_. The journal provides imuxsock with a copy of all "classical" syslog messages, however, it does not provide structured data. Only if that structured data is needed, imjournal must be used. Otherwise, imjournal may simply be replaced by imuxsock, and we highly suggest doing so. We suggest to check out our short presentation on `rsyslog journal integration `_ to learn more details of anticipated use cases. **Warning:** Some versions of systemd journal have problems with database corruption, which leads to the journal to return the same data endlessly in a tight loop. This results in massive message duplication inside rsyslog probably resulting in a denial-of-service when the system ressouces get exhausted. This can be somewhat mitigated by using proper rate-limiters, but even then there are spikes of old data which are endlessly repeated. By default, ratelimiting is activated and permits to process 20,000 messages within 10 minutes, what should be well enough for most use cases. If insufficient, use the parameters described below to adjust the permitted volume. **It is strongly recommended to use this plugin only if there is hard need to do so.** **Configuration Parameters**: **Module Parameters** Note: parameter names are case-insensitive. - **PersistStateInterval** number-of-messages This is a global setting. It specifies how often should the journal state be persisted. The persists happens after each *number-of-messages*. This option is useful for rsyslog to start reding from the last journal message it read. - **StateFile** /path/to/file This is a global setting. It specifies where the state file for persisting journal state is located. If a full path name is given (starting with "/"), that path is used. Otherwise the given name is created inside the working directory. - **ratelimit.interval** seconds (default: 600) Specifies the interval in seconds onto which rate-limiting is to be applied. If more than ratelimit.burst messages are read during that interval, further messages up to the end of the interval are discarded. The number of messages discarded is emitted at the end of the interval (if there were any discards). Setting this to value zero turns off ratelimiting. Note that it is **not recommended to turn of ratelimiting**, except that you know for sure journal database entries will never be corrupted. Without ratelimiting, a corrupted systemd journal database may cause a kind of denial of service (we are stressing this point as multiple users have reported us such problems with the journal database - information current as of June 2013). - **ratelimit.burst** messages (default: 20000) Specifies the maximum number of messages that can be emitted within the ratelimit.interval interval. For futher information, see description there. - **IgnorePreviousMessages** [**off**/on] This option specifies whether imjournal should ignore messages currently in journal and read only new messages. This option is only used when there is no StateFile to avoid message loss. - **DefaultSeverity** Some messages comming from journald don't have the SYSLOG_PRIORITY field. These are typically the messages logged through journald's native API. This option specifies the default severity for these messages. Can be given either as a name or a number. Defaults to 'notice'. - **DefaultFacility** Some messages comming from journald don't have the SYSLOG_FACILITY field. These are typically the messages logged through journald's native API. This option specifies the default facility for these messages. Can be given either as a name or a number. Defaults to 'user'. - **usepidfromsystem** [**off**/on] Retrieves the trusted systemd parameter, _PID, instead of the user systemd parameter, SYSLOG_PID, which is the default. This option override the "usepid" option. This is now deprecated. It is better to use usepid="syslog" instead. - **usepid** [**both**/syslog/system] Sets the PID source from journal. *syslog* *imjournal* retrieves SYSLOG_PID from journal as PID number. *system* *imjournal* retrieves _PID from journal as PID number. *both* *imjournal* trying to retrieve SYSLOG_PID first. When it is not available, it is also trying to retrive _PID. When none of them is available, message is parsed without PID number. - **IgnoreNonValidStatefile** [**on**/off] When a corrupted statefile is read imjournal ignores the statefile and continues with logging from the beginning of the journal (from its end if IgnorePreviousMessages is on). After PersistStateInterval or when rsyslog is stopped invalid statefile is overwritten with a new valid cursor. **Caveats/Known Bugs:** - As stated above, a corrupted systemd journal database can cause major problems, depending on what the corruption results in. This is beyond the control of the rsyslog team. - imjournal does not check if messages received actually originated from rsyslog itself (via omjournal or other means). Depending on configuration, this can also lead to a loop. With imuxsock, this problem does not exist. **Build Requirements:** Development headers for systemd, version >= 197. **Sample:** The following example shows pulling structured imjournal messages and saving them into /var/log/ceelog. :: module(load="imjournal" PersistStateInterval="100" StateFile="/path/to/file") #load imjournal module module(load="mmjsonparse") #load mmjsonparse module for structured logs template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n" ) #template for messages action(type="mmjsonparse") action(type="omfile" file="/var/log/ceelog" template="CEETemplate") **Legacy Configuration Parameters**: Note: parameter names are case-insensitive. - **$imjournalPersistStateInterval** Equivalent to: PersistStateInterval - **$imjournalStateFile** Equivalent to: StateFile - **$imjournalRatelimitInterval** Equivalent to: ratelimit.interval - **$imjournalRatelimitBurst** Equivalent to: ratelimit.burst - **$ImjournalIgnorePreviousMessages** Equivalent to: ignorePreviousMessages - **$ImjournalDefaultSeverity** Equivalent to: DefaultSeverity - **$ImjournalDefaultFacility** Equivalent to: DefaultFacility source/configuration/modules/imrelp.rst0000664000175000017500000002231713223143453017406 0ustar rgerrgerimrelp: RELP Input Module ========================= **Module Name:    imrelp** **Author: Rainer Gerhards** Provides the ability to receive syslog messages via the reliable RELP protocol. This module requires `librelp `__ to be present on the system. From the user's point of view, imrelp works much like imtcp or imgssapi, except that no message loss can occur. Please note that with the currently supported relp protocol version, a minor message duplication may occur if a network connection between the relp client and relp server breaks after the client could successfully send some messages but the server could not acknowledge them. The window of opportunity is very slim, but in theory this is possible. Future versions of RELP will prevent this. Please also note that rsyslogd may lose a few messages if rsyslog is shutdown while a network connection to the server is broken and could not yet be recovered. Future version of RELP support in rsyslog will prevent that. Please note that both scenarios also exists with plain tcp syslog. RELP, even with the small nits outlined above, is a much more reliable solution than plain tcp syslog and so it is highly suggested to use RELP instead of plain tcp. Clients send messages to the RELP server via omrelp. Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: Ruleset (requires v7.5.0+) Binds the specified ruleset to **all** RELP listeners. This can be overridden at the instance level. Input Parameters ^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: Port Starts a RELP server on selected port .. function:: Name Sets a name for the inputname property of this listener. If no name is set, "imrelp" is used by default. Setting a name is not strictly necessary, but can be useful to apply filtering based on which input the message was received from. .. function:: Ruleset Binds specified ruleset to this listener. This overrides the module-level Ruleset parameter. .. function:: MaxDataSize *Default is value of* :doc:`global(maxMessageSize) <../../rainerscript/global>` *parameter* Sets the max message size (in bytes) that can be received. Any messages above this size will be rejected causing the relp client to reconnect and retry. .. function:: tls on/off *Default is off* If set to "on", the RELP connection will be encrypted by TLS, so that the data is protected against observers. Please note that both the client and the server must have set TLS to either "on" or "off". Other combinations lead to unpredictable results. *Attention when using GnuTLS 2.10.x or older* Versions older than GnuTLS 2.10.x may cause a crash (Segfault) under certain circumstances. Most likely when an imrelp inputs and an omrelp output is configured. The crash may happen when you are receiving/sending messages at the same time. Upgrade to a newer version like GnuTLS 2.12.21 to solve the problem. .. function:: tls.compression on/off *Default is off* The controls if the TLS stream should be compressed (zipped). While this increases CPU use, the network bandwidth should be reduced. Note that typical text-based log records usually compress rather well. .. function:: tls.dhbits This setting controls how many bits are used for Diffie-Hellman key generation. If not set, the librelp default is used. For secrity reasons, at least 1024 bits should be used. Please note that the number of bits must be supported by GnuTLS. If an invalid number is given, rsyslog will report an error when the listener is started. We do this to be transparent to changes/upgrades in GnuTLS (to check at config processing time, we would need to hardcode the supported bits and keep them in sync with GnuTLS - this is even impossible when custom GnuTLS changes are made...). .. function:: tls.permittedPeer Peer Places access restrictions on this listener. Only peers which have been listed in this parameter may connect. The validation bases on the certificate the remote peer presents. The *peer* parameter lists permitted certificate fingerprints. Note that it is an array parameter, so either a single or multiple fingerprints can be listed. When a non-permitted peer connects, the refusal is logged together with it's fingerprint. So if the administrator knows this was a valid request, he can simple add the fingerprint by copy and paste from the logfile to rsyslog.conf. To specify multiple fingerprints, just enclose them in braces like this: :: tls.permittedPeer=["SHA1:...1", "SHA1:....2"] To specify just a single peer, you can either specify the string directly or enclose it in braces. .. function:: tls.authMode Sets the mode used for mutual authentication. Supported values are either "*fingerprint*\ " or "*name"*. Fingerprint mode basically is what SSH does. It does not require a full PKI to be present, instead self-signed certs can be used on all peers. Even if a CA certificate is given, the validity of the peer cert is NOT verified against it. Only the certificate fingerprint counts. In "name" mode, certificate validation happens. Here, the matching is done against the certificate's subjectAltName and, as a fallback, the subject common name. If the certificate contains multiple names, a match on any one of these names is considered good and permits the peer to talk to rsyslog. .. function:: tls.prioritystring This parameter permits to specify the so-called "priority string" to GnuTLS. This string gives complete control over all crypto parameters, including compression setting. For this reason, when the prioritystring is specified, the "tls.compression" parameter has no effect and is ignored. Full information about how to construct a priority string can be found in the GnuTLS manual. At the time of this writing, this information was contained in `section 6.10 of the GnuTLS manual `_. **Note: this is an expert parameter.** Do not use if you do not exactly know what you are doing. .. function:: KeepAlive on/off enable of disable keep-alive packets at the tcp socket layer. The default is to disable them. .. function:: KeepAlive.Probes *Default is 0* The number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Interval *Default is 0* The interval between subsequent keepalive probes, regardless of what the connection has exchanged in the meantime. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Time *Default is 0* The interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. Statistic Counter ----------------- This plugin maintains :doc:`statistics <../rsyslog_statistic_counter>` for each listener. The statistic by default is named "imrelp" , followed by the listener port in parenthesis. For example, the counter for a listener on port 514 is called "imprelp(514)". If the input is given a name, that input name is used instead of "imrelp". This counter is available starting rsyslog 7.5.1 The following properties are maintained for each listener: - **submitted** - total number of messages submitted for processing since startup Caveats/Known Bugs ------------------ - see description - To obtain the remote system's IP address, you need to have at least librelp 1.0.0 installed. Versions below it return the hostname instead of the IP address. Sample ------ This sets up a RELP server on port 20514 with a max message size of 10,000 bytes. :: module(load="imrelp") # needs to be done just once input(type="imrelp" port="20514" maxDataSize="10k") Legacy Configuration Parameters ------------------------------- Note: parameter names are case-insensitive. - InputRELPServerBindRuleset (available in 6.3.6+) equivalent to: RuleSet - InputRELPServerRun equivalent to: Port Caveats/Known Bugs ------------------ - To obtain the remote system's IP address, you need to have at least librelp 1.0.0 installed. Versions below it return the hostname instead of the IP address. - Contrary to other inputs, the ruleset can only be bound to all listeners, not specific ones. This issue is resolved in the non-Legacy configuration format. Legacy Sample ------------- This sets up a RELP server on port 20514. :: $ModLoad imrelp # needs to be done just once $InputRELPServerRun 20514 source/configuration/modules/pmciscoios.rst0000664000175000017500000001201013223143453020253 0ustar rgerrgerpmciscoios ========== Author: Rainer Gerhards Available since: 8.3.4+ This is a parser that understands Cisco IOS "syslog" format. Note that this format is quite different from RFC syslog format, and so the default parser chain cannot deal with it. Note that due to large differences in IOS logging format, pmciscoios may currently not be able to handle all possible format variations. Nevertheless, it should be fairly easy to adapt it to additional requirements. So be sure to ask if you run into problems with format issues. Note that if your Cisco system emits timezone information in a supported format, rsyslog will pick it up. In order to apply proper timezone offsets, the timezone ids (e.g. "EST") must be configured via the :doc:`timezone object <../timezone>`. Note if the clock on the Cisco device has not been set and cannot be verified the Cisco will prepend the timestamp field with an asterisk (*). If the clock has gone out of sync with its configured NTP server the timestamp field will be prepended with a dot (.). In both of these cases parsing the timestamp would fail, therefore any preceding asterisks (*) or dots (.) are ignored. This may lead to "incorrect" timestamps being logged. Parser Parameters ----------------- Note: parameter names are case-insensitive. .. function:: present.origin **Default**: off This setting tell the parser if the origin field is present inside the message. Due to the nature of Cisco's logging format, the parser cannot sufficiently correctly deduce if the origin field is present or not (at least not with reasonable performance). As such, the parser must be provided with that information. If the origin is present, its value is stored inside the HOSTNAME message property. .. function:: present.xr **Default**: off If syslog is recviced from an IOSXR device the syslog format will usually start with the RSP/LC/etc that produced the log, then the timestamp. It will also contain an additional syslog tag before the standard Cisco %TAG, this tag references the process that produced the log. In order to use this Cisco IOS parser module with XR format messages both of these additional fields must be ignored. Example ------- We assume a scenario where we have some devices configured to emit origin information whereas some others do not. In order to differentiate between the two classes, rsyslog accepts input on different ports, one per class. For each port, an input() object is defined, which binds the port to a ruleset that uses the appropriately-configured parser. Except for the different parsers, processing shall be identical for both classes. In our first example we do this via a common ruleset which carries out the actual processing: :: module(load="imtcp") module(load="pmciscoios") input(type="imtcp" port="10514" ruleset="withoutOrigin") input(type="imtcp" port="10515" ruleset="withOrigin") ruleset(name="common") { ... do processing here ... } ruleset(name="withoutOrigin" parser="rsyslog.ciscoios") { /* this ruleset uses the default parser which was * created during module load */ call common } parser(name="custom.ciscoios.withOrigin" type="pmciscoios" present.origin="on") ruleset(name="withOrigin" parser="custom.ciscoios.withOrigin") { /* this ruleset uses the parser defined immediately above */ call common } The example configuration above is a good solution. However, it is possible to do the same thing in a somewhat condensed way, but if and only if the date stamp immediately follows the origin. In that case, the parser has a chance to detect if the origin is present or not. The key point here is to make sure the parser checking for the origin is given before the default one, in which case the first on will detect it does not match an pass on to the next one inside the parser chain. However, this comes at the expense of additional runtime overhead. The example below is **not** good practice -- it is given as a purely educational sample to show some fine details of how parser definitions interact. In this case, we can use a single listener. :: module(load="imtcp") module(load="pmciscoios") input(type="imtcp" port="10514" ruleset="ciscoBoth") parser(name="custom.ciscoios.withOrigin" type="pmciscoios" present.origin="on") ruleset(name="ciscoBoth" parser=["custom.ciscoios.withOrigin", "rsyslog.ciscoios"]) { ... do processing here ... } The following sample demonstrates how to handle Cisco IOS and IOSXR formats :: module(load="imudp") module(load="pmciscoios") input(type="imudp" port="10514" ruleset="ios") input(type="imudp" port="10515" ruleset="iosxr") ruleset(name="common") { ... do processing here ... } ruleset(name="ios" parser="rsyslog.ciscoios") { call common } parser(name="custom.ciscoios.withXr" type="pmciscoios" present.xr="on") ruleset(name="iosxr" parser="custom.ciscoios.withXr"] { call common } source/configuration/modules/mmrm1stspace.rst0000664000175000017500000000131613223143453020526 0ustar rgerrgermmrm1stspace: First Space Modification Module ============================================= **Author:** Pascal Withopf In rfc3164 the msg begins at the first letter after the tag. It is often the case that this is a unnecessary space. This module removes this first character if it is a space. Configuration Parameters ------------------------ Note: parameter names are case-insensitive. Currently none. Examples -------- This example receives messages over imtcp and modifies them, before sending them to a file. :: module(load="imtcp") module(load="mmrm1stspace") input(type="imtcp" port="13514") action(type="mmrm1stspace") action(type="omfile" file="output.log") source/configuration/modules/imfile.rst0000664000175000017500000005647713223463364017407 0ustar rgerrgerimfile: Text File Input Module ============================== .. index:: ! imfile =========================== =========================================================================== **Module Name:**  **imfile** **Author:** `Rainer Gerhards `_ =========================== =========================================================================== This module provides the ability to convert any standard text file into a syslog message. A standard text file is a file consisting of printable characters with lines being delimited by LF. The file is read line-by-line and any line read is passed to rsyslog's rule engine. The rule engine applies filter conditions and selects which actions needs to be carried out. Empty lines are **not** processed, as they would result in empty syslog records. They are simply ignored. As new lines are written they are taken from the file and processed. Depending on the selected mode, this happens via inotify or based on a polling interval. Especially in polling mode, file reading doesn't happen immediately. But there are also slight delays (due to process scheduling and internal processing) in inotify mode. The file monitor supports file rotation. To fully work, rsyslogd must run while the file is rotated. Then, any remaining lines from the old file are read and processed and when done with that, the new file is being processed from the beginning. If rsyslogd is stopped during rotation, the new file is read, but any not-yet-reported lines from the previous file can no longer be obtained. When rsyslogd is stopped while monitoring a text file, it records the last processed location and continues to work from there upon restart. So no data is lost during a restart (except, as noted above, if the file is rotated just in this very moment). See Also ........ * presentation on `using wildcards with imfile `_ Metadata ........ The imfile module supports message metadata. It supports the following data items: - filename Name of the file where the message originated from. This is most useful when using wildcards inside file monitors, because it then is the only way to know which file the message originated from. The value can be accessed using the %$!metadata!filename% property. - fileoffset Offset of the file in bytes at the time the message was read. The offset reported is from the **start** of the line. This information can be useful when recreating multi-line files that may have been accessed or transmitted non-sequentially. The value can be accessed using the %$!metadata!fileoffset% property. Metadata is only present if enabled. By default it is enabled for input() statements that contain wildcards. For all others, it is disabled by default. It can explicitly be turned on or off via the *addMetadata* input() parameter, which always overrides the default. State Files ........... Rsyslog must keep track of which parts of the monitored file are already processed. This is done in so-called "state files" that are created in the rsyslog working directory and are read on startup to resume monitoring after a shutdown. The location of the rsyslog working directory is configurable via the ``global(workDirectory)`` |FmtAdvancedName| format parameter. **Note**: The ``PersistStateInterval`` parameter must be set, otherwise state files will NOT be created. To avoid problems with duplicate state files, rsyslog automatically generates state file names according to the following scheme: - the string "imfile-state:" is added before the actual file name, which includes the full path - the full name is prepended after that string, but all occurrences of "/" are replaced by "-" to facilitate handling of these files As a concrete example, consider file ``/var/log/applog`` is being monitored. The corresponding state file will be named ``imfile-state:-var-log-applog``. Note that it is possible to set a fixed state file name via the deprecated ``stateFile`` parameter. It is suggested to avoid this, as the user must take care of name clashes. Most importantly, if "stateFile" is set for file monitors with wildcards, the **same** state file is used for all occurrences of these files. In short, this will usually not work and cause confusion. Upon startup, rsyslog tries to detect these cases and emit warning messages. However, the detection simply checks for the presence of "*" and as such it will not cover more complex cases. Note that when the ``global(workDirectory)`` |FmtAdvancedName| format parameter is not set or set to a non-writable location, the state file **will not be generated**. In those cases, the file content will always be completely re-sent by imfile, because the module does not know that it already processed parts of that file. Module Parameters ----------------- Note: parameter names are case-insensitive. .. index:: single: imfile; mode .. function:: mode ["inotify"/"polling"/"fen"] *Default: "inotify"* *Available since: 8.1.5* This specifies if imfile is shall run in inotify ("inotify") or polling ("polling") mode. Traditionally, imfile used polling mode, which is much more resource-intense (and slower) than inotify mode. It is suggested that users turn on "polling" mode only if they experience strange problems in inotify mode. In theory, there should never be a reason to enable "polling" mode and later versions will most probably remove it. Note: if a legacy "$ModLoad" statement is used, the default is *polling*. This default was kept to prevent problems with old configurations. It might change in the future. *Available since: 8.32.0* On Solaris, the FEN API is used instead of INOTIFY. You can set the mode to fen or inotify (which is automatically mapped to fen on Solaris OS). Please note that the FEN is limited compared to INOTIFY. Deep wildcard matches may not work because of the API limits for now. .. index:: single: imfile; readtimeout .. function:: readTimeout [seconds] *Default: 0 (no timeout)* *Available since: 8.23.0* This sets the default value for input *timeout* parameters. See there for exact meaning. .. index:: single: imfile; timeoutGranularity .. function:: timeoutGranularity [seconds] *Default: 1* *Available since: 8.23.0* This sets the interval in which multi-line-read timeouts are checked. The interval is specified in seconds. Note that this establishes a lower limit on the length of the timeout. For example, if a timeoutGranularity of 60 seconds is selected and a readTimeout value of 10 seconds is used, the timeout is nevertheless only checked every 60 seconds (if there is no other activity in imfile). This means that the readTimeout is also only checked every 60 seconds, which in turn means a timeout can occur only after 60 seconds. Note that timeGranularity has some performance implication. The more frequently timeout processing is triggered, the more processing time is needed. This effect should be negligible, except if a very large number of files is being monitored. .. index:: single: imfile; sortFiles .. function:: sortFiles [on/off] *Default: off* *Available since: 8.32.0* If this parameter is set to on, the files will be processed in sorted order, else not. However, due to the inherent asynchronicity of the whole operations involved in tracking files, it is not possible to guarantee this sorted order, as it also depends on operation mode and OS timing. .. index:: single: imfile; PollingInterval .. function:: PollingInterval seconds *Default: 10* This setting specifies how often files are to be polled for new data. For obvious reasons, it has effect only if imfile is running in polling mode. The time specified is in seconds. During each polling interval, all files are processed in a round-robin fashion. A short poll interval provides more rapid message forwarding, but requires more system resources. While it is possible, we strongly recommend not to set the polling interval to 0 seconds. That will make rsyslogd become a CPU hog, taking up considerable resources. It is supported, however, for the few very unusual situations where this level may be needed. Even if you need quick response, 1 seconds should be well enough. Please note that imfile keeps reading files as long as there is any data in them. So a "polling sleep" will only happen when nothing is left to be processed. **We recommend to use inotify mode.** Input Parameters ---------------- Note: parameter names are case-insensitive. .. index:: single: imfile; File .. function:: File [/path/to/file] **(Required Parameter)** The file being monitored. So far, this must be an absolute name (no macros or templates). Note that wildcards are supported at the file name level (see **WildCards** below for more details). .. index:: single: imfile; Tag .. function:: Tag [tag:] **(Required Parameter)** The tag to be used for messages that originate from this file. If you would like to see the colon after the tag, you need to specify it here (like 'tag="myTagValue:"'). .. index:: single: imfile; Facility .. function:: Facility [facility] The syslog facility to be assigned to lines read. Can be specified in textual form (e.g. "local0", "local1", ...) or as numbers (e.g. 16 for "local0"). Textual form is suggested. Default  is "local0". .. index:: single: imfile; Severity .. function:: Severity [syslogSeverity] The syslog severity to be assigned to lines read. Can be specified in textual form (e.g. "info", "warning", ...) or as numbers (e.g. 6 for "info"). Textual form is suggested. Default is "notice". .. index:: single: imfile; PersistStateInterval .. function:: PersistStateInterval [lines] Specifies how often the state file shall be written when processing the input file. The **default** value is 0, which means a new state file is only written when the monitored files is being closed (end of rsyslogd execution). Any other value n means that the state file is written every time n file lines have been processed. This setting can be used to guard against message duplication due to fatal errors (like power fail). Note that this setting affects imfile performance, especially when set to a low value. Frequently writing the state file is very time consuming. **Note: If this parameter is not set, state files are not created.** .. index:: single: imfile; startmsg.regex .. function:: startmsg.regex [POSIX ERE regex] This permits the processing of multi-line messages. When set, a messages is terminated when the next one begins, and ``startmsg.regex`` contains the regex that identifies the start of a message. As this parameter is using regular expressions, it is more flexible than ``readMode`` but at the cost of lower performance. Note that ``readMode`` and ``startmsg.regex`` cannot both be defined for the same input. This parameter is available since rsyslog v8.10.0. .. index:: single: imfile; readTimeout .. function:: readTimeout [seconds] *Default: 0 (no timeout)* *Available since: 8.23.0* This can be used with *startmsg.regex* (but not *readMode*). If specified, partial multi-line reads are timed out after the specified timeout interval. That means the current message fragment is being processed and the next message fragment arriving is treated as a completely new message. The typical use case for this parameter is a file that is infrequently being written. In such cases, the next message arrives relatively late, maybe hours later. Specifying a readTimeout will ensure that those "last messages" are emitted in a timely manner. In this use case, the "partial" messages being processed are actually full messages, so everything is fully correct. To guard against accidential too-early emission of a (partial) message, the timeout should be sufficiently large (5 to 10 seconds or more recommended). Specifying a value of zero turns off timeout processing. Also note the relationship to the *timeoutGranularity* global parameter, which sets the lower bound of *readTimeout*. Setting timeout vaues slightly increases processing time requirements; the effect should only be visible of a very large number of files is being monitored. .. index:: single: imfile; readMode .. function:: readMode [mode] This provides support for processing some standard types of multiline messages. It is less flexible than ``startmsg.regex`` but offers higher performance than regex processing. Note that ``readMode`` and ``startmsg.regex`` cannot both be defined for the same input. The value can range from 0-2 and determines the multiline detection method. 0 - (**default**) line based (each line is a new message) 1 - paragraph (There is a blank line between log messages) 2 - indented (new log messages start at the beginning of a line. If a line starts with a space or tab "\t" it is part of the log message before it) .. index:: single: imfile; escapeLF .. function:: escapeLF [on/off] (requires v7.5.3+) This is only meaningful if multi-line messages are to be processed. LF characters embedded into syslog messages cause a lot of trouble, as most tools and even the legacy syslog TCP protocol do not expect these. If set to "on", this option avoid this trouble by properly escaping LF characters to the 4-byte sequence "#012". This is consistent with other rsyslog control character escaping. By default, escaping is turned on. If you turn it off, make sure you test very carefully with all associated tools. Please note that if you intend to use plain TCP syslog with embedded LF characters, you need to enable octet-counted framing. For more details, see Rainer's blog posting on imfile LF escaping. .. index:: single: imfile; MaxLinesAtOnce .. function:: MaxLinesAtOnce [number] This is a legacy setting that only is supported in *polling* mode. In *inotify* mode, it is fixed at 0 and all attempts to configure a different value will be ignored, but will generate an error message. Please note that future versions of imfile may not support this parameter at all. So it is suggested to not use it. In *polling* mode, if set to 0, each file will be fully processed and then processing switches to the next file. If it is set to any other value, a maximum of [number] lines is processed in sequence for each file, and then the file is switched. This provides a kind of mutiplexing the load of multiple files and probably leads to a more natural distribution of events when multiple busy files are monitored. For *polling* mode, the **default** is 10240. .. index:: single: imfile; MaxSubmitAtOnce .. function:: MaxSubmitAtOnce [number] This is an expert option. It can be used to set the maximum input batch size that imfile can generate. The **default** is 1024, which is suitable for a wide range of applications. Be sure to understand rsyslog message batch processing before you modify this option. If you do not know what this doc here talks about, this is a good indication that you should NOT modify the default. .. index:: single: imfile; deleteStateOnFileDelete .. function:: deleteStateOnFileDelete [on/off] (requires v8.5.0+) **Default: on** This parameter controls if state files are deleted if their associated main file is deleted. Usually, this is a good idea, because otherwise problems would occur if a new file with the same name is created. In that case, imfile would pick up reading from the last position in the **deleted** file, which usually is not what you want. However, there is one situation where not deleting associated state file makes sense: this is the case if a monitored file is modified with an editor (like vi or gedit). Most editors write out modifications by deleting the old file and creating a new now. If the state file would be deleted in that case, all of the file would be reprocessed, something that's probably not intended in most case. As a side-note, it is strongly suggested *not* to modify monitored files with editors. In any case, in such a situation, it makes sense to disable state file deletion. That also applies to similar use cases. In general, this parameter should only by set if the users knows exactly why this is required. .. index:: single: imfile; Ruleset .. function:: Ruleset Binds the listener to a specific :doc:`ruleset <../../concepts/multi_ruleset>`. .. function:: addMetadata [on/off] **Default: see intro section on Metadata** This is used to turn on or off the addition of metadata to the message object. .. function:: addCeeTag [on/off] **Default: off** This is used to turn on or off the addition of the "@cee:" cookie to the message object. .. index:: single: imfile; reopenOnTruncate .. function:: reopenOnTruncate [on/off] (requires v8.16.0+) **Default: off** This is an **experimental** feature that tells rsyslog to reopen input file when it was truncated (inode unchanged but file size on disk is less than current offset in memory). .. index:: single: imfile; trimLineOverBytes .. function:: trimLineOverBytes [number] (requires v8.17.0+) **Default: 0** This is used to tell rsyslog to truncate the line which length is greater than specified bytes. If it is positive number, rsyslog truncate the line at specified bytes. Default value of 'trimLineOverBytes' is 0, means never truncate line. This option can be used when ``readMode`` is 0 or 2. .. index:: single: imfile; freshStartTail .. function:: freshStartTail [on/off] (requires v8.18.0+) **Default: off** This is used to tell rsyslog to seek to the end/tail of input files (discard old logs) **at its first start(freshStart)** and process only new log messages. When deploy rsyslog to a large number of servers, we may only care about new log messages generated after the deployment. set **freshstartTail** to **on** will discard old logs. Otherwise, there may be vast useless message burst on the remote central log receiver .. index:: single: imfile; discardTruncatedMsg .. function:: discardTruncatedMsg *Default: off* When messages are too long they are truncated and the following part is processed as a new message. When this parameter is turned on the truncated part is not processed but discarded. .. index:: single: imfile; msgDiscardingError .. function:: msgDiscardingError *Default: on* Upon truncation an error is given. When this parameter is turned off, no error will be shown upon truncation. WildCards --------- **Before Version: 8.25.0** Wildcards are only supported in the filename part, not in directory names. * /var/log/\*.log **works**. * * /var/log/\*/syslog.log does **not work**. * **Since Version: 8.25.0** Wildcards are supported in filename and paths which means these samples will work: * /var/log/\*.log **works**. * * /var/log/\*/syslog.log **works**. * * /var/log/\*/\*.log **works**. * All matching files in all matching subfolders will work. Note that this may decrease performance in imfile depending on how many directories and files are being watched dynamically. Caveats/Known Bugs ------------------ * currently, wildcards are only supported in inotify mode * read modes other than "0" currently seem to have issues in inotify mode Configuration Example --------------------- The following sample monitors two files. If you need just one, remove the second one. If you need more, add them according to the sample ;). This code must be placed in /etc/rsyslog.conf (or wherever your distro puts rsyslog's config files). Note that only commands actually needed need to be specified. The second file uses less commands and uses defaults instead. :: module(load="imfile" PollingInterval="10") #needs to be done just once # File 1 input(type="imfile" File="/path/to/file1" Tag="tag1" Severity="error" Facility="local7") # File 2 input(type="imfile" File="/path/to/file2" Tag="tag2") # ... and so on ... # |FmtObsoleteName| Configuration ------------------------------- Note: in order to preserve compatibility with previous versions, the LF escaping in multi-line messages is turned off for legacy-configured file monitors (the "escapeLF" input parameter). Because this can cause serious problems, it is highly suggested that new deployments use the new :ref:`input() ` configuration object and keep LF escaping turned on. |FmtObsoleteDescription| ^^^^^^^^^^^^^^^^^^^^^^^^ .. index:: single: imfile; $InputFileName .. function:: $InputFileName /path/to/file equivalent to "file" .. index:: single: imfile; $InputFileTag .. function:: $InputFileTag tag: equivalent to: "tag" you would like to see the colon after the tag, you need to specify it here (as shown above). .. index:: single: imfile; $InputFileStateFile .. function:: $InputFileStateFile name-of-state-file equivalent to: "StateFile" .. index:: single: imfile; $InputFileFacility .. function:: $InputFileFacility facility equivalent to: "Facility" .. index:: single: imfile; $InputFileSeverity .. function:: $InputFileSeverity severity equivalent to: "Severity" .. index:: single: imfile; $InputRunFileMonitor .. function:: $InputRunFileMonitor This **activates** the current monitor. It has no parameters. If you forget this directive, no file monitoring will take place. .. index:: single: imfile; $InputFilePollInterval .. function:: $InputFilePollInterval seconds equivalent to: "PollingInterval" .. index:: single: imfile; $InputFilePersistStateInterval .. function:: $InputFilePersistStateInterval lines equivalent to: "PersistStateInterval" .. index:: single: imfile; $InputFileReadMode .. function:: $InputFileReadMode mode equivalent to: "ReadMode" .. index:: single: imfile; $InputFileMaxLinesAtOnce .. function:: $InputFileMaxLinesAtOnce number equivalent to: "MaxLinesAtOnce" .. index:: single: imfile; $InputFileBindRuleset .. function:: $InputFileBindRuleset ruleset Equivalent to: Ruleset |FmtObsoleteName| Example ^^^^^^^^^^^^^^^^^^^^^^^^^ The following sample monitors two files. If you need just one, remove the second one. If you need more, add them according to the sample ;). Note that only non-default parameters actually needed need to be specified. The second file uses less directives and uses defaults instead. :: $ModLoad imfile # needs to be done just once # File 1 $InputFileName /path/to/file1 $InputFileTag tag1: $InputFileStateFile stat-file1 $InputFileSeverity error $InputFileFacility local7 $InputRunFileMonitor # File 2 $InputFileName /path/to/file2 $InputFileTag tag2: $InputFileStateFile stat-file2 $InputRunFileMonitor # ... and so on ... # check for new lines every 10 seconds $InputFilePollInterval 10 Deprecated parameters ..................... **Note:** While these parameters are still accepted, they should no longer be used for newly created configurations. .. function:: stateFile [name-of-state-file] **Default: unset** This is the name of this file's state file. This parameter should usually **not** be used. Check the section on "State Files" above for more details. source/configuration/modules/idx_stringgen.rst0000664000175000017500000000415113223143453020756 0ustar rgerrgerString Generator Modules ======================== String generator modules are used, as the name implies, to generate strings based on the message content. They are currently tightly coupled with the template system. Their primary use is to speed up template processing by providing a native C interface to template generation. These modules exist since 5.5.6. To get an idea of the potential speedup, the default file format, when generated by a string generator, provides a roughly 5% speedup. For more complex strings, especially those that include multiple regular expressions, the speedup may be considerably higher. String generator modules are written to a quite simple interface. However, a word of caution is due: they access the rsyslog message object via a low-level interface. That interface is not guaranteed yet to stay stable. So it may be necessary to modify string generator modules if the interface changes. Obviously, we will not do that without good reason, but it may happen. Rsyslog comes with a set of core, build-in string generators, which are used to provide those default templates that we consider to be time-critical: - smfile - the default rsyslog file format - smfwd - the default rsyslog (network) forwarding format - smtradfile - the traditional syslog file format - smfwd - the traditional syslog (network) forwarding format Note that when you replace these defaults with some custom strings, you will loose some performance (around 5%). For typical systems, this is not really relevant. But for a high-performance systems, it may be very relevant. To solve that issue, create a new string generator module for your custom format, starting out from one of the default generators provided. If you can not do this yourself, you may want to contact `Adiscon `_ as we offer custom development of string generators at a very low price. Note that string generator modules can be dynamically loaded. However, the default ones provided are so important that they are build right into the executable. But this does not need to be done that way (and it is straightforward to do it dynamic). source/configuration/modules/module_workflow.png0000664000175000017500000003463512704114446021322 0ustar rgerrgerPNG  IHDR^NAsBITO pHYs IDATxi\S׺3D@@TuUWmjjUbέQPElUy C¾99)섀MK*kk0 +- , , , , , u^ڳgϮ]u]xX^$IXXXXXXMMM͛w^N M nݺovĉ.]zٙ3g6mڤ{?͛7\5wwwX|Ç˾tɓ'͙3'** A ::D2lذ[n};wlA$ܼ#P DCGgkk+X8;;?~ʕ+#Fh@S\z011 ?PGG'77=K͆huuuM/^A={_~!Xh8DCGgmm=vEvyffff.]۹6`ݻ0**СC^MNN0a!WK 7AepB=l۶mٲegg]tyYf䓘sssν{n3dȐ &~ hV\~##ӧOWɭ~L!$44T%;|2?oQᝂhn߾mbbBUx>Oپ} w DXN `AnH)X:*XhRKTK Qr锪` /R,} h)U,hDC{cZtJU hho[:*XJB4Y:*X@4?mNt VVVVyy9@+-))iܸq\WA!>ttt 7A4 P D@4 D@4 D@4 D@4 D@4 D@4 DC{HIIxTTTx<P~jkkݻG֭(hh?눈@W+**-,,̂hΝ;wnhhhmmuVysqqfffӧO/**=sssgcŋ/2 ͛k<}H$bߟv̘13gά,,,6ltD FC}}CCC-[Fiׯ_xOoS0 SPP_~-k+Wa !ݞ:u(o8)DC{FÑ#G>|( >$}ԩSG6222d)6:ujȐ!:u211166{~!n%(B4i4TWWIi"WPP o555֭bmǏr ݳYC4d?ÇX.]իWdBHVVVbbbmm gm@OO/'''44>XzuUUUQQі-[ hhoիWH@ЧO@0rHz,P__7XXXGEE9rn˖-wڴi-..9swȉ'.]J/p(Y{G!YYYׯ"P WZZmdd4`q]Pظp] h,Ǎwq]h2D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 D@4 aZ6 jbŊÆ cM+Vgdda j@WWѣ7ouTooQFp]ZJMMMHH7\uy۶m\mشi!k׮?c}}=K. 2)++"heUWWϞ= P=P(E"|W\\WĽ GYYYݻw֖@p_R.]zH\zy#GN4@ ۿΝ;OrA1mm0BȆ F3` D"...DNNN\n޼9x`kY\[qqq޽ J!$$$p]A.O\] )))<O,pP/_RQQallҥ\t?A)SD@4CBȑ#./jkkݻG֭1b=eu- rBvLgԩS]I#""G}T[[Ke6bffflltHuDDD~~~&&&/^J?~˵kdmTC***-,,̂ bH7 :2D\4lll$&&~{u߾}?isҞ={\OO>:9s;vL,geeD"//FҮ_.+00Ĥ… R' .))|˗/W\?}[˵]۔)S\\\btbO`үsrrK7nӓD"~ĉnݺ5VmvƏl2 пƢ5մׯ_xO֊4??qݾ}[q7lH~.](8Pvvv {{,,((("""55566^Nlooh,_&;aX=޽{}] ~p@! Ce4h!~__ .ȶ=geeIǢhl y5D7o(>@ZuA.Dڵk!={ԩSxxD"yiΝ;B222M__nnii9vUVUVVұ ھfZ͛iy5HYXX.]>2???99YAabP[[[:{hwބׯƍܣG}Btuu8`bbGўݺu[pA̚K 8W^MۣbM>} n:YRRbiiIOU*AVdd@ ӧ@ 9r7olhhprrVWRR!o5ϗ_~IYlׅ ` רQLMMSSSOkQDF rL8gkQ.]z䉹q] V^*r}}O*y[仉aCaaajEf̘Q]]-=N:|\YC3>}"H&Ou9QNNG^^? {{850{lb dUWWO:5//oȑ\*YC3gÇ޽+H$qqq9`<>{W^ϕzzzř$$$ 4 A)^^^Fڳg;>ߜ]fggwҥ>}p][Xd7>>8#___ l\WmZ,!!atP(1c}uؓ'O9sa}} 6,YDK Ö́hhq҅vvv666VVV-}kǤJuuu,XzjczIII Xu7dȐ7oү Ǝ;eooo»Ѡ"(;;;//Mzɓ'?u6ښUކm:t(=gΜ9sDEEq] h,C`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`vrՃr]fϞ=fez"]! G7n\= '--rs]Krttܽ{w;jԨy|jaٲe>>>qqqͦAB򸮥 nb߮]>Yt@4+kkCq]E ʹ|rKKݻw7ue``:vIi6pBaѢE>>>III e.j6 (hPuuu;v`}ٳmt4t@4b}}%K<s̡ڿ0/ՀEΝ\"޽{KJJx<ɓ*HVVqO?4::̙3GF4 \v믿&9ޞ@mۯZJA@P^^hP_j8׏6J ܖjĉ;L6~s j#,,rڵ2ڂ)Dژ?0ϟ'cʠ*:::֭#[NGGmv 5mi! 8^"2g!Ϟ=vgNII-i ! 8B0ePΝ;gddK["##BP(tss;ӧg̘A_ڱcիjB]$B'NؿܺuKVSN۷ѣGt8H! ,XN!?Jߍ5rݻw !TnO n^BB_||m͕H$ dddٳatQ90̑#G?}40= ʛ>}͛H$M ڴxo%-I[[[[DSN6aDr]K$***;oڍ7FM2 lٲ}=ydСF aLMM]Nކeee-M ` iI|>_^_/gT(--MvzzzVUUB.\sx<!aW f}lZ2Gh)DC+DGGZYY=zF-//6lX gnn.mlllmmuT5ҭ[7ozA>lťСCߗabccg̘@;v߾}_|08p ^^^?ݻ7-bffomm-pC%2 ۡ`vMֆ5iv-D.]+VHKKk7_=k֬JBȼy&N8e===ݻ^}DFF._<,,uǴꢤdĈNNN&M⺖Ta0JL>B֨Qm&|||wpkΝ;u{T ѠHmm]}[n)`=zDGG_tr:#Fܾ}_~ϟ?0a›7oT Ak׮#{]~W^O< H$\WԱ_E[tJ nܸ</**o߾\Abb寿fXZ N)B"| k֬aoonJ2}}͛7ݛSקK<<<شO5Q uuuՊEPʯR ?"""!=zwCBf͚=-O߳g0t UuJK&NG5QJ.P]o˫7O\ע^xa``߿ߺ=p UUUoS]:ejjG5QJ.j2W)r/^; ZRn.\m۶={s]N hkkHe.bkn c-]6pBH``fצfϞMIHH`6|N{"0Lll,!$66Vvl5Qzzzk!]Ew.})V]3gΔ6ŏh_~"&gllllllff흙پ5K[***[et?v-P(v˗kGxxxrrr߾}L={V(nٲ~}>۶m5jGIIŋ<|piȦرcB0))I:{C ]7c 77W!4IDAT7333iKzzzmqĢh~+x^__0̫WΝ̞fmi z{.m'[[f;BBB!7nlŶ\khe?..v.{0@Ν:uZp!]o>@`ff6}"QQQ;wvz֭t?fffAAAUUU6(}0dDDDB??? ŋ\v66țM) 7B%%%s/Úmll\RR{nd[[OѿԹsRRR^x>,**J$yyy%%%ʕ+nt9s;vL,geeM*qҮ_@ .:tEo:annnRt.\ %>Q__ȑ \zl_>VLWW?~X(ѓ?H$211!Xbܹ۷oomSgΜIII R\\nddddd_/Ydƍʼn"pŊҏ*j:arrr+NIȁCvttl|^qqqnڴ)==]"444TTTH_>V;vX|y~6n陓0;0L}}}mYEDDnEiKiooO[LYlJ[[&///55UQ@4EMMͳgsWXX8}#Gx{{]zuȑ=}}}}}}kkk7m4ŝ.]x8ggg;99/h쉊 z޻X-$//oС{mEb;B@OO/'''44[VVVzzQtuuMLLwҥ;w477رcW__M8,--ǎjժȪ0zm_f́*++7oLٳSN+Vc] :Y^A<<&&*:7o6 .]DcKKKccc'' R+yyy>>><$$;ٙ^OٳǁXgSz󫯾RЧы,<6EyyX,.((ܹ3娱C޼y3..>>\Y KK/'/%gΜYVV\Pwv_} |}}/1e˖%%%Y[[@E8]]TUUIkеkcǎ544p]\Aߖ?33@pRYUތ&NڣGy#0 dee=}4666&&ݶCBBn`&:::***11Q]KKk„ m`$;;D?ްaH(,,޽|=`|TC4@yyyiii/|||ψ|>А>xʓ <@&$\`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h`h| h?۷o .ꆆ4Çߺu*8vx YtUpŋ۷oONN2eJhP?w%999q]KڵKTϿoݧZsιs^zL: OMM !ZڜX,ѣG7uս{w9PrrrFuwʤA]=zp]EL:wMՍ: QRwt@4?߹sMš5PTTdmmcǎаdwwm۶qRX\ȦSN'NҥKrrɓqR XZZeggGߗ})44RKKk޼y\BGG'//_~:H$-- .\v Ѡv5eʔTىCCC֭[ !U?>11B]x{{A}Q:eطowfB4]vBRSSh n:BȺuy**hP([^Ӗf)_AmH'.\ ~SU~!ٳgٳgȖ״E NJJJ!o޼!2NΝ322dHP( Ο?3fЗvرzjyZ`P(twwD' $S\\aZ@0ԴLit8@ -+xhK5C8dgg,jK[ťСC3gΔabcc ! Æ #;80}~ŋBe7ltCҒbccQ\Za?#...;;;/////^6^jmmݞikkwsoy#۶mۨQ,,,Wf̘qu333y[7jkk>|>o޼H$S8uhkkWX Xz!Clmmoܸt;vyxx4( /_tZ{ݻ-<נ<8\C <o9|pCC!sγgvqqylmm-,,Zw,v***rssbbb*..w}7zhklC%%%#Fprr4i׵ CCkhhXl!DGG'44455:ݻwKgӧOP;AIg 8 )WUU̙3n񂂂222֬Y`;`…999aaaǏwww)u 8;;?~޽;EuP+W'O  =C /++w7oޜ0a{{ׯWVVN<# [___KT "$$ƍvvvW^ݻ7 ##Ǐ~LJh mtJsA##xKKKQ3</::Y(y`ǡyf777:%}}}tÃlڧњC º:(}(k+A)K5>!ڱZXXB;u-j^HNNnN ߳g0t UuJK&NG5QJ.P]o ˫$wB<<<ZNJmuJKLMMY(&JEP6Tf}[B4(**200x7oWUUյkWBȉ'ZF&&&BF k/2 SYY)7uCfÇ#G\z5ݴرcՓ&MRIIs}}}B4˗/ !}Qgk׮5k744\lٔ)S֮]KIIIxbҩqtt4mppp}Qmm7-)00022~VB??? ŋ\vMvF54"88,((HA>Dp8zΝ>(DÿBlllueO$o===bٴܹsiiiϞ=KIIo[9s;vL,geeD":}hiiiׯ_hbbRXXx…C+UpppIIIff/^|I5ckkKނz~M;XYY 544444믗,YBoh[[[WW3gΤ=)..NJJJOO722222cmܸ811Q$VX1m4%+--E" !dŊsݾ}9T2OFl>h333#KPv faa!moxB}BPPPDDDjjjlll}}޾X5(?VNN0[1 #;<0ʏ_譩^_|cǎ%~8ZEE$Ql'''E.]Zy#!!!={tqqIII=geeՋEvhy5ҥ D W !/^TS9:urV3W={B,Xϯjbbr[?{aN:mذA,xbDO<{W*++ ܖ/_d)޹sQJرc+**X+VϜ9@RPCSN ;y$!W^fِA8qbLLڵk|#]ֳgOBnTTaz[n .4h wvv&7ٹ?44TX ⨨O>FGGg̙_ !!!!\|y>}mllBBB載}?{xxxг$XΝyϥl_***j=))) o3ՙ˗FWvԩΞ=u-իWׯ_?~<׵@!ۛu!"66V,{zzbp@$%%O~Kuuush1vѢE Vo߾ ֛8ì/.\ٟԦ*** bcc}||.ZSiӦeddp]Z \P_54oZK͟?ݻw?蝗0khLKK+**_~iiicƌ"Q__`!f Oww[[ۓ'Oi*..6m˗utt_v|AnnW_}bG"8pݺuqrApڥo]jjj.GR4hPQQEjyw]rebb"! 4ťG666ԇߕ=ԩSΝstt\~3YEjѠOnܸ1**JD͍~եOx2eʗ_~B[@4L]]ݹs޽{'8j<===mm]yzzr]@ .UIENDB`source/configuration/modules/imkafka.rst0000664000175000017500000000554113223143453017521 0ustar rgerrgerimkafka: read from Apache Kafka =============================== =========================== ======================================================= **Module Name:** **imkafka** **Author:** Pascal Withopf **Available since:** v8.27.0 =========================== ======================================================= The imkafka plug-in implements an Apache Kafka consumer, permitting rsyslog to receive data from Kafka. Configuration Parameters ------------------------ Note that imkafka supports some *Array*-type parameters. While the parameter name can only be set once, it is possible to set multiple values with that single parameter. For example, to select a broker, you can use :: input(type="imkafka" topic="mytopic" broker="localhost:9092" consumergroup="default") which is equivalent to :: input(type="imkafka" topic="mytopic" broker=["localhost:9092"] consumergroup="default") To specify multiple values, just use the bracket notation and create a comma-delimited list of values as shown here: :: input(type="imkafka" topic="mytopic" broker=["localhost:9092", "localhost:9093", "localhost:9094"] ) Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. Currently none. Action Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: broker *Default: "localhost:9092"* Specifies the broker(s) to use. .. function:: topic *Mandatory* *Default: none* Specifies the topic to produce to. .. function:: confParam *Default: none* Permits to specify Kafka options. Rather than offering a myriad of config settings to match the Kafka parameters, we provide this setting here as a vehicle to set any Kafka parameter. This has the big advantage that Kafka parameters that come up in new releases can immediately be used. Note that we use librdkafka for the Kafka connection, so the parameters are actually those that librdkafka supports. As of our understanding, this is a superset of the native Kafka parameters. .. function:: consumergroup *Default none* With this parameter the group.id for the consumer is set. All consumers sharing the same group.id belong to the same group. .. function:: ruleset *Default: none* Specifies the ruleset to be used. Caveats/Known Bugs ------------------ - currently none Example ------- **Sample 1:** In this sample a consumer for the topic static is created and will forward the messages to the omfile action. :: module(load="imkafka") input(type="imkafka" topic="static" broker="localhost:9092" consumergroup="default" ruleset="pRuleset") ruleset(name="pRuleset") { action(type="omfile" file="path/to/file") } source/configuration/modules/imsolaris.rst0000664000175000017500000000217713223143453020122 0ustar rgerrgerimsolaris: Solaris Input Module =============================== Reads local Solaris log messages including the kernel log. This module is specifically tailored for Solaris. Under Solaris, there is no special kernel input device. Instead, both kernel messages as well as messages emitted via syslog() are received from a single source. This module obeys the Solaris door() mechanism to detect a running syslogd instance. As such, only one can be active at one time. If it detects another active instance at startup, the module disables itself, but rsyslog will continue to run. **Author:** \ Rainer Gerhards Configuration Parameters ------------------------ Note: parameter names are case-insensitive. | functions:: $IMSolarisLogSocketName This is the name of the log socket (stream) to read. If not given, /dev/log is read. Caveats/Known Bugs ------------------ None currently known. For obvious reasons, works on Solaris, only (and compilation will most probably fail on any other platform). Examples -------- The following sample pulls messages from the default log source :: $ModLoad imsolaris source/configuration/modules/mmsequence.rst0000664000175000017500000001014713223143453020256 0ustar rgerrgerNumber generator and counter module (mmsequence) ================================================ **Module Name:    mmsequence** **Author:**\ Pavel Levshin **Status:**\ Non project-supported module - contact author or rsyslog mailing list for questions **This module is deprecated** in v8 and solely provided for backward compatibility reasons. It was written as a work-around for missing global variable support in v7. Global variables are available in v8, and at some point in time this module will entirely be removed. **Do not use this module for newly crafted config files.** Use global variables instead. **Available since**: 7.5.6 **Description**: This module generates numeric sequences of different kinds. It can be used to count messages up to a limit and to number them. It can generate random numbers in a given range. This module is implemented via the output module interface, so it is called just as an action. The number generated is stored in a variable.   **Action Parameters**: Note: parameter names are case-insensitive. - **mode** "random" or "instance" or "key" Specifies mode of the action. In "random" mode, the module generates uniformly distributed integer numbers in a range defined by "from" and "to". In "instance" mode, which is default, the action produces a counter in range [from, to). This counter is specific to this action instance. In "key" mode, the counter can be shared between multiple instances. This counter is identified by a name, which is defined with "key" parameter. - **from** [non-negative integer], default "0" Starting value for counters and lower margin for random generator. - **to** [positive integer], default "INT\_MAX" Upper margin for all sequences. Note that this margin is not inclusive. When next value for a counter is equal or greater than this parameter, the counter resets to the starting value. - **step** [non-negative integer], default "1" Increment for counters. If step is "0", it can be used to fetch current value without modification. The latter not applies to "random" mode. This is useful in "key" mode or to get constant values in "instance" mode. - **key** [word], default "" Name of the global counter which is used in this action. - **var** [word], default "$!mmsequence" Name of the variable where the number will be stored. Should start with "$". **Sample**: :: # load balance Ruleset( name="logd" queue.workerthreads="5" ){ Action( type="mmsequence" mode="instance" from="0" to="2" var="$.seq" ) if $.seq == "0" then { Action( type="mmnormalize" userawmsg="on" rulebase="/etc/rsyslog.d/rules.rb" ) } else { Action( type="mmnormalize" userawmsg="on" rulebase="/etc/rsyslog.d/rules.rb" ) } # output logic here } # generate random numbers action( type="mmsequence" mode="random" to="100" var="$!rndz" ) # count from 0 to 99 action( type="mmsequence" mode="instance" to="100" var="$!cnt1" ) # the same as before but the counter is global action( type="mmsequence" mode="key" key="key1" to="100" var="$!cnt2" ) # count specific messages but place the counter in every message if $msg contains "txt" then action( type="mmsequence" mode="key" to="100" var="$!cnt3" ) else action( type="mmsequence" mode="key" to="100" step="0" var="$!cnt3" key="" ) **Legacy Configuration Parameters**: Note: parameter names are case-insensitive. Not supported. source/configuration/modules/omfile.rst0000664000175000017500000005162413223143453017374 0ustar rgerrgeromfile: File Output Module ========================== =========================== =========================================================================== **Module Name:** **omfile** **Author:** `Rainer Gerhards `_ =========================== =========================================================================== The omfile plug-in provides the core functionality of writing messages to files residing inside the local file system (which may actually be remote if methods like NFS are used). Both files named with static names as well files with names based on message content are supported by this module. Configuration Parameters ------------------------ Omfile is a built-in module that does not need to be loaded. In order to specify module parameters, use :: module(load="builtin:omfile" ...parameters...) Note that legacy parameters **do not** affect new-style RainerScript configuration objects. See :doc:`basic configuration structure doc <../basic_structure>` to learn about different configuration languages in use by rsyslog. Note: parameter names are case-insensitive. General Notes ^^^^^^^^^^^^^ As can be seen in the parameters below, owner and groups can be set either by name or by direct id (uid, gid). While using a name is more convenient, using the id is more robust. There may be some situations where the OS is not able to do the name-to-id resolution, and these cases the owner information will be set to the process default. This seems to be uncommon and depends on the authentication provider and service start order. In general, using names is fine. Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: template [templateName] *Default: RSYSLOG_FileFormat* Set the default template to be used if an action is not configured to use a specific template. .. function:: dirCreateMode [octalNumber] *Default: 0700* Sets the default dirCreateMode to be used for an action if no explicit one is specified. .. function:: fileCreateMode [default 0644] [octalNumber] *Default: 0644* Sets the default fileCreateMode to be used for an action if no explicit one is specified. .. function:: fileOwner [userName] *Default: process user* Sets the default fileOwner to be used for an action if no explicit one is specified. .. function:: fileOwnerNum [uid] *Default: process user* Sets the default fileOwnerNum to be used for an action if no explicit one is specified. .. function:: fileGroup [groupName] *Default: process user's primary group* Sets the default fileGroup to be used for an action if no explicit one is specified. .. function:: fileGroupNum [gid] *Default: process user's primary group* Sets the default fileGroupNum to be used for an action if no explicit one is specified. .. function:: dirOwner [userName] *Default: process user* Sets the default dirOwner to be used for an action if no explicit one is specified. .. function:: dirOwnerNum [uid] *Default: process user* Sets the default dirOwnerNum to be used for an action if no explicit one is specified. .. function:: dirGroup [groupName] *Default: process user's primary group* Sets the default dirGroup to be used for an action if no explicit one is specified. .. function:: dirGroupNum [gid] *Default: process user's primary group* Sets the default dirGroupNum to be used for an action if no explicit one is specified.   Action Parameters ^^^^^^^^^^^^^^^^^ Note that **one** of the parameters *file* or *dynaFile* must be specified. This selects whether a static or dynamic file (name) shall be written to. .. function:: file [fileName] *Default: none* This creates a static file output, always writing into the same file. If the file already exists, new data is appended to it. Existing data is not truncated. If the file does not already exist, it is created. Files are kept open as long as rsyslogd is active. This conflicts with external log file rotation. In order to close a file after rotation, send rsyslogd a HUP signal after the file has been rotated away. Either file or dynaFile can be used, but not both. If both are given, dynaFile will be used. .. function:: dynaFile [templateName] *Default: none* For each message, the file name is generated based on the given template. Then, this file is opened. As with the *file* property, data is appended if the file already exists. If the file does not exist, a new file is created. The template given in "templateName" is just a regular :doc:`rsyslog template <../templates>`, so all you have full control over how to format the file name. Either file or dynaFile can be used, but not both. If both are given, dynaFile will be used. A cache of recent files is kept. Note that this cache can consume quite some memory (especially if large buffer sizes are used). Files are kept open as long as they stay inside the cache. Files are removed from the cache when a HUP signal is sent, the *closeTimeout* occurs, or the cache runs out of space, in which case the least recently used entry is evicted. .. function:: template [templateName] *Default: template set via "template" module parameter* Sets the template to be used for this action. .. function:: closeTimeout [minutes] *Default: for static files: 0; for dynamic files: 10* *Available since: 8.3.3* Specifies after how many minutes of inactivity a file is automatically closed. Note that this functionality is implemented based on the :doc:`janitor process <../../concepts/janitor>`. See its doc to understand why and how janitor-based times are approximate. .. function:: dynaFileCacheSize [size] *Default: 10* Applies only if dynamic filenames are used. Specifies the number of DynaFiles that will be kept open. Note that this is a per-action value, so if you have multiple dynafile actions, each of them have their individual caches (which means the numbers sum up). Ideally, the cache size exactly matches the need. You can use :doc:`impstats ` to tune this value. Note that a too-low cache size can be a very considerable performance bottleneck. .. function:: zipLevel [level] *Default: 0* if greater 0, turns on gzip compression of the output file. The higher the number, the better the compression, but also the more CPU is required for zipping. .. function:: veryRobustZip [switch] *Default: off* *Available since: 7.3.0* if *zipLevel* is greater 0, then this setting controls if extra headers are written to make the resulting file extra hardened against malfunction. If set to off, data appended to previously unclean closed files may not be accessible without extra tools. Note that this risk is usually expected to be bearable, and thus "off" is the default mode. The extra headers considerably degrade compression, files with this option set to "on" may be four to five times as large as files processed in "off" mode. .. function:: flushInterval [interval] *Default: 1* Defines, in seconds, the interval after which unwritten data is flushed. .. function:: asyncWriting [switch] *Default: off* if turned on, the files will be written in asynchronous mode via a separate thread. In that case, double buffers will be used so that one buffer can be filled while the other buffer is being written. Note that in order to enable FlushInterval, AsyncWriting must be set to "on". Otherwise, the flush interval will be ignored. .. function:: flushOnTXEnd [switch] *Default: on* Omfile has the capability to write output using a buffered writer. Disk writes are only done when the buffer is full. So if an error happens during that write, data is potentially lost. Bear in mind that the buffer may become full only after several hours or a rsyslog shutdown (however a buffer flush can still be forced by sending rsyslogd a HUP signal). In cases where this is unacceptable, set FlushOnTXEnd to "on". Then, data is written at the end of each transaction (for pre-v5 this means after each log message) and the usual error recovery thus can handle write errors without data loss. Note that this option severely reduces the effect of zip compression and should be switched to "off" for that use case. Also note that the default -on- is primarily an aid to preserve the traditional syslogd behaviour. .. function:: ioBufferSize [size] *Default: 4 KiB* size of the buffer used to writing output data. The larger the buffer, the potentially better performance is. The default of 4k is quite conservative, it is useful to go up to 64k, and 128K if you used gzip compression (then, even higher sizes may make sense) .. function:: dirOwner [userName] *Default: system default* Set the file owner for directories newly created. Please note that this setting does not affect the owner of directories already existing. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. .. function:: dirOwnerNum [uid] *Default: system default* *Available since: 7.5.8, 8.1.4* Set the file owner for directories newly created. Please note that this setting does not affect the owner of directories already existing. The parameter is a numerical ID, which is used regardless of whether the user actually exists. This can be useful if the user mapping is not available to rsyslog during startup. .. function:: dirGroup [groupName] *Default: system default* Set the group for directories newly created. Please note that this setting does not affect the group of directories already existing. The parameter is a group name, for which the groupid is obtained by rsyslogd on during startup processing. Interim changes to the user mapping are not detected. .. function:: dirGroupNum [gid] *Default: system default* Set the group for directories newly created. Please note that this setting does not affect the group of directories already existing. The parameter is a numerical ID, which is used regardless of whether the group actually exists. This can be useful if the group mapping is not available to rsyslog during startup. .. function:: fileOwner [userName] *Default: system default* Set the file owner for files newly created. Please note that this setting does not affect the owner of files already existing. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are *not* detected. .. function:: fileOwnerNum [uid] *Default: system default* *Available since: 7.5.8, 8.1.4* Set the file owner for files newly created. Please note that this setting does not affect the owner of files already existing. The parameter is a numerical ID, which which is used regardless of whether the user actually exists. This can be useful if the user mapping is not available to rsyslog during startup. .. function:: fileGroup [groupName] *Default: system default* Set the group for files newly created. Please note that this setting does not affect the group of files already existing. The parameter is a group name, for which the groupid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. .. function:: fileGroupNum [gid] *Default: system default* *Available since: 7.5.8, 8.1.4* Set the group for files newly created. Please note that this setting does not affect the group of files already existing. The parameter is a numerical ID, which is used regardless of whether the group actually exists. This can be useful if the group mapping is not available to rsyslog during startup. .. function:: fileCreateMode [octalNumber] *Default: equally-named module parameter* The FileCreateMode directive allows to specify the creation mode with which rsyslogd creates new files. If not specified, the value 0644 is used (which retains backward-compatibility with earlier releases). The value given must always be a 4-digit octal number, with the initial digit being zero. Please note that the actual permission depend on rsyslogd's process umask. If in doubt, use "$umask 0000" right at the beginning of the configuration file to remove any restrictions. .. function:: dirCreateMode [octalNumber] *Default: equally-named module parameter* This is the same as FileCreateMode, but for directories automatically generated. .. function:: failOnChOwnFailure [switch] *Default: on* This option modifies behaviour of file creation. If different owners or groups are specified for new files or directories and rsyslogd fails to set these new owners or groups, it will log an error and NOT write to the file in question if that option is set to "on". If it is set to "off", the error will be ignored and processing continues. Keep in mind, that the files in this case may be (in)accessible by people who should not have permission. The default is "on". .. function:: createDirs [switch] *Default: on* create directories on an as-needed basis .. function:: sync [switch] *Default: off* enables file syncing capability of omfile. When enabled, rsyslog does a sync to the data file as well as the directory it resides after processing each batch. There currently is no way to sync only after each n-th batch. Enabling sync causes a severe performance hit. Actually, it slows omfile so much down, that the probability of loosing messages **increases**. In short, you should enable syncing only if you know exactly what you do, and fully understand how the rest of the engine works, and have tuned the rest of the engine to lossless operations. .. function:: sig.provider [providerName] *Default: no signature provider* Selects a signature provider for log signing. By selecting a provider, the signature feature is turned on. Currently there is one signature provider available: ":doc:`ksi_ls12 `". Previous signature providers ":doc:`gt `" and ":doc:`ksi `" are depricated. .. function:: cry.provider [providerName] *Default: no crypto provider* Selects a crypto provider for log encryption. By selecting a provider, the encryption feature is turned on. Currently, there only is one provider called ":doc:`gcry <../cryprov_gcry>`". Statistic Counter ----------------- This plugin maintains :doc:`statistics <../rsyslog_statistic_counter>` for each dynafile cache. Dynafile cache performance is critical for overall system performance, so reviewing these counters on a busy system (especially one experiencing performance problems) is advisable. The statistic is named "dynafile cache", followed by the template name used for this dynafile action. The following properties are maintained for each dynafile: - **request** - total number of requests made to obtain a dynafile - **level0** - requests for the current active file, so no real cache lookup needed to be done. These are extremely good. - **missed** - cache misses, where the required file did not reside in cache. Even with a perfect cache, there will be at least one miss per file. That happens when the file is being accessed for the first time and brought into cache. So "missed" will always be at least as large as the number of different files processed. - **evicted** - the number of times a file needed to be evicted from the cache as it ran out of space. These can simply happen when date-based files are used, and the previous date files are being removed from the cache as time progresses. It is better, though, to set an appropriate "closeTimeout" (counter described below), so that files are removed from the cache after they become no longer accessed. It is bad if active files need to be evicted from the cache. This is a very costly operation as an evict requires to close the file (thus a full flush, no matter of its buffer state) and a later access requires a re-open – and the eviction of another file, as the cache obviously has run out of free entries. If this happens frequently, it can severely affect performance. So a high eviction rate is a sign that the dynafile cache size should be increased. If it is already very high, it is recommended to re-think about the design of the file store, at least if the eviction process causes real performance problems. - **maxused** - the maximum number of cache entries ever used. This can be used to trim the cache down to a value that’s actually useful but does not waste resources. Note that when date-based files are used and rsyslog is run for an extended period of time, the cache gradually fills up to the max configured value as older files are migrated out of it. This will make "maxused" questionable after some time. Frequently enough purging the cache can prevent this (usually, once a day is sufficient). - **closetimeouts** - available since 8.3.3 – tells how often a file was closed due to timeout settings ("closeTimeout" action parameter). These are cases where dynafiles or static files have been closed by rsyslog due to inactivity. Note that if no "closeTimeout" is specified for the action, this counter always is zero. A high or low number in itself doesn’t mean anything good or bad. It totally depends on the use case, so no general advise can be given. Caveats/Known Bugs ------------------ - people often report problems that dynafiles are not properly created. The common cause for this problem is SELinux rules, which do not permit the create of those files (check generated file names and pathes!). The same happens for generic permission issues (this is often a problem under Ubuntu where permissions are dropped by default) - One needs to be careful with log rotation if signatures and/or encryption are being used. These create side-files, which form a set and must be kept together. For signatures, the ".sigstate" file must NOT be rotated away if signature chains are to be build across multiple files. This is because .sigstate contains just global information for the whole file set. However, all other files need to be rotated together. The proper sequence is to #. move all files inside the file set #. only AFTER this is completely done, HUP rsyslog This sequence will ensure that all files inside the set are atomically closed and in sync. HUPing only after a subset of files have been moved results in inconsistencies and will most probably render the file set unusable. Example ------- The following command writes all syslog messages into a file. :: action(type="omfile" dirCreateMode="0700" FileCreateMode="0644" File="/var/log/messages") Legacy Configuration Parameters ------------------------------- Note: parameter names are case-insensitive. Note that the legacy configuration parameters do **not** affect new-style action definitions via the action() object. This is by design. To set default for action() objects, use module parameters in the :: module(load="builtin:omfile" ...) object. Read about :ref:`the importance of order in legacy configuration` to understand how to use these configuration parameters. **Legacy parameters should NOT be used when writing new configuration files.** - **$DynaFileCacheSize** equivalent to the "dynaFileCacheSize" parameter - **$OMFileZipLevel** equivalent to the "zipLevel" parameter - **$OMFileFlushInterval** equivalent to the "flushInterval" parameter - **$OMFileASyncWriting** equivalent to the "asyncWriting" parameter - **$OMFileFlushOnTXEnd** equivalent to the "flushOnTXEnd" parameter - **$OMFileIOBufferSize** equivalent to the "IOBufferSize" parameter - **$DirOwner** equivalent to the "dirOwner" parameter - **$DirGroup** equivalent to the "dirGroup" parameter - **$FileOwner** equivalent to the "fileOwner" parameter - **$FileGroup** equivalent to the "fileGroup" parameter - **$DirCreateMode** equivalent to the "dirCreateMode" parameter - **$FileCreateMode** equivalent to the "fileCreateMode" parameter - **$FailOnCHOwnFailure** equivalent to the "failOnChOwnFailure" parameter - **$F$OMFileForceCHOwn** equivalent to the "ForceChOwn" parameter - **$CreateDirs** equivalent to the "createDirs" parameter - **$ActionFileEnableSync** equivalent to the "enableSync" parameter - **$ActionFileDefaultTemplate** equivalent to the "template" module parameter - **$ResetConfigVariables** Resets all configuration variables to their default value. Legacy Sample ^^^^^^^^^^^^^ The following command writes all syslog messages into a file. :: $DirCreateMode 0700 $FileCreateMode 0644 *.* /var/log/messages source/configuration/modules/mmpstrucdata.rst0000664000175000017500000000731313224663364020632 0ustar rgerrgerRFC5424 structured data parsing module (mmpstrucdata) ===================================================== **Module Name:** mmpstrucdata **Author:** Rainer Gerhards **Available since**: 7.5.4 **Description**: The mmpstrucdata parses the structured data of `RFC5424 `_ into the message json variable tree. The data parsed, if available, is stored under "jsonRoot!rfc5424-sd!...". Please note that only RFC5424 messages will be processed. The difference of RFC5424 is in the message layout: the SYSLOG-MSG part only contains the structured-data part instead of the normal message part. Further down you can find a example of a structured-data part. **Module Configuration Parameters**: Note: parameter names are case-insensitive. Currently none.   **Action Confguration Parameters**: Note: parameter names are case-insensitive. - **jsonRoot** - default "!" Specifies into which json container the data shall be parsed to. - **sd_name.lowercase** - default "on" Available: rsyslog 8.32.0 and above Specifies if sd names (SDID) shall be lowercased. If set to "on", this is the case, if "off" than not. The default of "on" is used because that was the traditional mode of operations. It it generally advised to change the parameter to "off" if not otherwise required. **See Also** - `Howto anonymize messages that go to specific files `_ **Caveats/Known Bugs:** - this module is currently experimental; feedback is appreciated - property names are treated case-insensitive in rsyslog. As such, RFC5424 names are treated case-insensitive as well. If such names only differ in case (what is not recommended anyways), problems will occur. - structured data with duplicate SD-IDs and SD-PARAMS is not properly processed **Samples:** Below you can find a structured data part of a random message which has three parameters. :: [exampleSDID@32473 iut="3" eventSource="Application"eventID="1011"] In this snippet, we parse the message and emit all json variable to a file with the message anonymized. Note that once mmpstrucdata has run, access to the original message is no longer possible (execept if stored in user variables before anonymization). :: module(load="mmpstrucdata") action(type="mmpstrucdata") template(name="jsondump" type="string" string="%msg%: %$!%\\n") action(type="omfile" file="/path/to/log" template="jsondump") **A more practical one:** Take this example message (inspired by RFC5424 sample;)): ``<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][id@2 test="tast"] BOM'su root' failed for lonvick on /dev/pts/8`` We apply this configuration: :: module(load="mmpstrucdata") action(type="mmpstrucdata") template(name="sample2" type="string" string="ALL: %$!%\\nSD: %$!RFC5424-SD%\\nIUT:%$!rfc5424-sd!exampleSDID@32473!iut%\\nRAWMSG: %rawmsg%\\n\\n") action(type="omfile" file="/path/to/log" template="sample2") This will output: ``ALL: { "rfc5424-sd": { "examplesdid@32473": { "iut": "3", "eventsource": "Application", "eventid": "1011" }, "id@2": { "test": "tast" } } } SD: { "examplesdid@32473": { "iut": "3", "eventsource": "Application", "eventid": "1011" }, "id@2": { "test": "tast" } } IUT:3 RAWMSG: <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][id@2 test="tast"] BOM'su root' failed for lonvick on /dev/pts/8`` As you can seem, you can address each of the individual items. Note that the case of the RFC5424 parameter names has been converted to lower case. source/configuration/modules/pmlastmsg.rst0000664000175000017500000000436313223143453020126 0ustar rgerrgerpmlastmsg: last message repeated n times ======================================== **Module Name:    pmlastmsg** **Module Type:    parser module** **Author:**\ Rainer Gerhards **Available Since**: 5.5.6 **Description**: Some syslogds are known to emit severily malformed messages with content "last message repeated n times". These messages can mess up message reception, as they lead to wrong interpretation with the standard RFC3164 parser. Rather than trying to fix this issue in pmrfc3164, we have created a new parser module specifically for these messages. The reason is that some processing overhead is involved in processing these messages (they must be recognized) and we would not like to place this toll on every user but only on those actually in need of the feature. Note that the performance toll is not large -- but if you expect a very high message rate with tenthousands of messages per second, you will notice a difference. This module should be loaded first inside :doc:`rsyslog's parser chain `. It processes all those messages that contain a PRI, then none or some spaces and then the exact text (case-insensitive) "last message repeated n times" where n must be an integer. All other messages are left untouched. **Configuration Parameters**: Note: parameter names are case-insensitive. There do not currently exist any configuration parameters for this module. **Examples:** This example is the typical use case, where some systems emit malformed "repeated msg" messages. Other than that, the default :rfc:`5424` and :rfc:`3164` parsers should be used. Note that when a parser is specified, the default parser chain is removed, so we need to specify all three parsers. We use this together with the default ruleset. :: $ModLoad pmlastmsg # This parser is not a built-in module. # Note that parsers are tried in the order they appear in # rsyslog.conf, so put pmlastmsg first. $RulesetParser rsyslog.lastline # As we have removed the default parser chain, we need to add the # default parsers as well. $RulesetParser rsyslog.rfc5424 $RulesetParser rsyslog.rfc3164 # Here come the typical rules, like... \*.\* /path/to/file.log **Caveats/Known Bugs:** currently none source/configuration/modules/omsnmp.rst0000664000175000017500000001264013223143453017425 0ustar rgerrgeromsnmp: SNMP Trap Output Module =============================== **Module Name:** omsnmp **Author:** Andre Lorbach **Description**: Provides the ability to send syslog messages as an SNMPv1 & v2c traps. By default, SNMPv2c is preferred. The syslog message is wrapped into a OCTED STRING variable. This module uses the `NET-SNMP `_ library. In order to compile this module, you will need to have the `NET-SNMP `_ developer (headers) package installed.   **Action Line:** %omsnmp% without any further parameters.   **Configuration parameters**: Note: configuration parameter names are case-insensitive. - **$actionsnmptransport**\ (This parameter is optional, the default value is "udp") Defines the transport type you wish to use. Technically we can support all transport types which are supported by NET-SNMP. To name a few possible values: udp, tcp, udp6, tcp6, icmp, icmp6 ... Example: ``$actionsnmptransport udp`` - **$actionsnmptarget** This can be a hostname or ip address, and is our snmp target host. This parameter is required, if the snmptarget is not defined, nothing will be send. Example: ``$actionsnmptarget server.domain.xxx`` - **$actionsnmptargetport** (This parameter is optional, the default value is "162") The port which will be used, common values are port 162 or 161. Example: ``$actionsnmptargetport 162`` - **$actionsnmpversion** (This parameter is optional, the default value is "1") There can only be two choices for this parameter for now. 0 means SNMPv1 will be used. 1 means SNMPv2c will be used. Any other value will default to 1. Example: ``$actionsnmpversion 1`` - **$actionsnmpcommunity** (This parameter is optional, the default value is "public") This sets the used SNMP Community. Example: ``$actionsnmpcommunity public`` - **$actionsnmptrapoid** (This parameter is optional, the default value is "1.3.6.1.4.1.19406.1.2.1" which means "ADISCON-MONITORWARE-MIB::syslogtrap") This configuration parameter is used for **SNMPv2** only. This is the OID which defines the trap-type, or notifcation-type rsyslog uses to send the trap. In order to decode this OID, you will need to have the ADISCON-MONITORWARE-MIB and ADISCON-MIB mibs installed on the receiver side. Downloads of these mib files can be found here: `http://www.adiscon.org/download/ADISCON-MIB.txt `_ `http://www.adiscon.org/download/ADISCON-MONITORWARE-MIB.txt `_ Thanks to the net-snmp mailinglist for the help and the recommendations ;). Example: ``$actionsnmptrapoid 1.3.6.1.4.1.19406.1.2.1`` If you have this MIBS installed, you can also configured with the OID Name: ``$actionsnmptrapoid ADISCON-MONITORWARE-MIB::syslogtrap`` - **$actionsnmpsyslogmessageoid** (This parameter is optional, the default value is "1.3.6.1.4.1.19406.1.1.2.1" which means "ADISCON-MONITORWARE-MIB::syslogMsg") This OID will be used as a variable, type "OCTET STRING". This variable will contain up to 255 characters of the original syslog message including syslog header. It is recommend to use the default OID. In order to decode this OID, you will need to have the ADISCON-MONITORWARE-MIB and ADISCON-MIB mibs installed on the receiver side. To download these custom mibs, see the description of **$actionsnmptrapoid.** Example: ``$actionsnmpsyslogmessageoid 1.3.6.1.4.1.19406.1.1.2.1`` If you have this MIBS installed, you can also configured with the OID Name: ``$actionsnmpsyslogmessageoid`` ADISCON-MONITORWARE-MIB::syslogMsg - **$actionsnmpenterpriseoid** (This parameter is optional, the default value is "1.3.6.1.4.1.3.1.1" which means "enterprises.cmu.1.1") Customize this value if needed. I recommend to use the default value unless you require to use a different OID. This configuration parameter is used for **SNMPv1** only. It has no effect if **SNMPv2** is used. Example: ``$actionsnmpenterpriseoid 1.3.6.1.4.1.3.1.1`` - **$actionsnmpspecifictype** (This parameter is optional, the default value is "0") This is the specific trap number. This configuration parameter is used for **SNMPv1** only. It has no effect if **SNMPv2** is used. Example: ``$actionsnmpspecifictype 0`` - **$actionsnmptraptype** (This parameter is optional, the default value is "6" which means SNMP\_TRAP\_ENTERPRISESPECIFIC) There are only 7 Possible trap types defined which can be used here. These trap types are: :: 0 = SNMP_TRAP_COLDSTART 1 = SNMP_TRAP_WARMSTART 2 = SNMP_TRAP_LINKDOWN 3 = SNMP_TRAP_LINKUP 4 = SNMP_TRAP_AUTHFAIL 5 = SNMP_TRAP_EGPNEIGHBORLOSS 6 = SNMP_TRAP_ENTERPRISESPECIFIC Any other value will default to 6 automatically. This configuration parameter is used for **SNMPv1** only. It has no effect if **SNMPv2** is used. Example: ``$actionsnmptraptype 6``   **Caveats/Known Bugs:** - In order to decode the custom OIDs, you will need to have the adiscon mibs installed. **Sample:** The following commands send every message as a snmp trap. :: $ModLoad omsnmp $actionsnmptransport udp $actionsnmptarget localhost $actionsnmptargetport 162 $actionsnmpversion 1 $actionsnmpcommunity public *.* :omsnmp: source/configuration/modules/omuxsock.rst0000664000175000017500000000224413223143453017763 0ustar rgerrgeromuxsock: Unix sockets Output Module ==================================== **Module Name:    omuxsock** **Available since**: 4.7.3, 5.5.7 **Author:**\ Rainer Gerhards **Description**: This module supports sending syslog messages to local Unix sockets. Thus it provided a fast message-passing interface between different rsyslog instances. The counterpart to omuxsock is `imuxsock `_. Note that the template used together with omuxsock must be suitable to be processed by the receiver. **Configuration Parameters**: Note: parameter names are case-insensitive. - **$OMUxSockSocket** Name of the socket to send data to. This has no default and **must** be set. - **$OMUxSockDefaultTemplate** This can be used to override the default template to be used together with omuxsock. This is primarily useful if there are many forwarding actions and each of them should use the same template. **Caveats/Known Bugs:** Currently, only datagram sockets are supported. **Sample:** The following sample writes all messages to the "/tmp/socksample" socket. :: $ModLoad omuxsock $OMUxSockSocket /tmp/socksample *.* :omuxsock: source/configuration/modules/mmnormalize.rst0000664000175000017500000001266613223143453020456 0ustar rgerrgerLog Message Normalization Module (mmnormalize) ============================================== **Module Name:    mmnormalize** **Available since:** 6.1.2+ **Author:** Rainer Gerhards **Description**: This module provides the capability to normalize log messages via `liblognorm `_. Thanks to liblognorm, unstructured text, like usually found in log messages, can very quickly be parsed and put into a normal form. This is done so quickly, that it should be possible to normalize events in realtime. This module is implemented via the output module interface. This means that mmnormalize should be called just like an action. After it has been called, the normalized message properties are available and can be accessed. These properties are called the "CEE/lumberjack" properties, because liblognorm creates a format that is inspired by the CEE/lumberjack approach. **Please note:** CEE/lumberjack properties are different from regular properties. They have always "$!" prepended to the property name given in the rulebase. Such a property needs to be called with **%$!propertyname%**. Note that mmnormalize should only be called once on each message. Behaviour is undefined if multiple calls to mmnormalize happen for the same message. Module Parameters ~~~~~~~~~~~~~~~~~ Note: parameter names are case-insensitive. .. function:: allow_regex **Default**: off Specifies if regex field-type should be allowed. Regex field-type has significantly higher computational overhead compared to other fields, so it should be avoided when another field-type can achieve the desired effect. Needs to be "on" for regex field-type to work. Action Parameters ~~~~~~~~~~~~~~~~~ Note: parameter names are case-insensitive. .. function:: ruleBase Specifies which rulebase file is to use. If there are multiple mmnormalize instances, each one can use a different file. However, a single instance can use only a single file. This parameter or **rule** MUST be given, because normalization can only happen based on a rulebase. It is recommended that an absolute path name is given. Information on how to create the rulebase can be found in the `liblognorm manual `_. .. function:: rule *(Available since: 8.26.0)* Contains an array of strings which will be put together as the rulebase. This parameter or **rulebase** MUST be given, because normalization can only happen based on a rulebase. .. function:: useRawMsg **Default**: off Specifies if the raw message should be used for normalization (on) or just the MSG part of the message (off). .. function:: path **Default**: $! Specifies the JSON path under which parsed elements should be placed. By default, all parsed properties are merged into root of message properties. You can place them under a subtree, instead. You can place them in local variables, also, by setting path="$.". .. function:: variable *(Available since: 8.5.1)* Specifies if a variable insteed of property 'msg' should be used for normalization. A varible can be property, local variable, json-path etc. Please note that **useRawMsg** overrides this parameter, so if **useRawMsg** is set, **variable** will be ignored and raw message will be used. Legacy Configuration Parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note: parameter names are case-insensitive. - $mmnormalizeRuleBase - equivalent to the "ruleBase" parameter. - $mmnormalizeUseRawMsg - equivalent to the "useRawMsg" parameter. See Also ~~~~~~~~ - `First steps for mmnormalize `_ - `Log normalization and special characters `_ - `Log normalization and the leading space `_ - `Using mmnormalize effectively with Adiscon LogAnalyzer `_ Caveats/Known Bugs ~~~~~~~~~~~~~~~~~~ None known at this time. Example ~~~~~~~ **Sample 1:** In this sample messages are received via imtcp. Then they are normalized with the given rulebase. After that they are written in a file. :: module(load="mmnormalize") module(load="imtcp") input(type="imtcp" port="10514" ruleset="outp") ruleset(name="outp") { action(type="mmnormalize" rulebase="/tmp/rules.rulebase") action(type="omfile" File="/tmp/output") } **Sample 2:** In this sample messages are received via imtcp. Then they are normalized based on the given rules. The strings from **rule** are put together and are equal to a rulebase with the same content. :: module(load="mmnormalize") module(load="imtcp") input(type="imtcp" port="10514" ruleset="outp") ruleset(name="outp") { action(type="mmnormalize" rule=["rule=:%host:word% %tag:char-to:\\x3a%: no longer listening on %ip:ipv4%#%port:number%", "rule=:%host:word% %ip:ipv4% user was logged out"]) action(type="omfile" File="/tmp/output") } **Sample 3:** This activates the module and applies normalization to all messages: :: module(load="mmnormalize") action(type="mmnormalize" ruleBase="/path/to/rulebase.rb") The same in legacy format: :: $ModLoad mmnormalize $mmnormalizeRuleBase /path/to/rulebase.rb *.* :mmnormalize: source/configuration/modules/gssapi.rst0000664000175000017500000000343513223143453017404 0ustar rgerrgerGSSAPI module support in rsyslog v3 =================================== What is it good for. - client-serverauthentication - Log messages encryption Requirements. - Kerberos infrastructure - rsyslog, rsyslog-gssapi Configuration. Let's assume there are 3 machines in kerberos Realm: - the first is running KDC (Kerberos Authentication Service and Key Distribution Center), - the second is a client sending its logs to the server, - the third is receiver, gathering all logs. 1. KDC: - Kerberos database must be properly set-up on KDC machine first. Use kadmin/kadmin.local to do that. Two principals need to be add in our case: #. sender@REALM.ORG - client must have ticket for pricipal sender - REALM.ORG is kerberos Realm #. host/receiver.mydomain.com@REALM.ORG - service principal - Use ktadd to export service principal and transfer it to /etc/krb5.keytab on receiver 2. CLIENT: - set-up rsyslog, in /etc/rsyslog.conf - $ModLoad omgssapi - load output gss module - $GSSForwardServiceName otherThanHost - set the name of service principal, "host" is the default one - \*.\* :omgssapi:receiver.mydomain.com - action line, forward logs to receiver - kinit root - get the TGT ticket - service rsyslog start 3. SERVER: - set-up rsyslog, in /etc/rsyslog.conf - $ModLoad `imgssapi `_ - load input gss module - $InputGSSServerServiceName otherThanHost - set the name of service principal, "host" is the default one - $InputGSSServerPermitPlainTCP on - accept GSS and TCP connections (not authenticated senders), off by default - $InputGSSServerRun 514 - run server on port - service rsyslog start The picture demonstrate how things work. .. figure:: gssapi.png :align: center :alt: rsyslog gssapi support rsyslog gssapi support source/configuration/modules/omusrmsg.rst0000664000175000017500000000116113223143453017764 0ustar rgerrgeromusrmsg: notify users ====================== **Module Name:    omusrmsg** **Author:**\ Rainer Gerhards **Description**: This module permits to send log messages to the user terminal.   **Module Parameters**: Note: parameter names are case-insensitive. none   **Action Parameters**: Note: parameter names are case-insensitive. - **users** the name of the users to send data to. - **template** template to user for the message. **Caveats/Known Bugs:** - None. **Sample:** The following command writes emergency messages to all users:: action(type="omusrmsg" users="*") source/configuration/modules/sigprov_ksi12.rst0000664000175000017500000001126113223143453020614 0ustar rgerrgerKeyless Signature Infrastructure Provider (rsyslog-ksi-ls12) ============================================================ **Module Name: rsyslog-ksi-ls12** **Available Since:** 8.27 **Author:** Guardtime & Adiscon Description ########### The ``rsyslog-ksi-ls12`` module enables record level log signing with Guardtime KSI blockchain. KSI keyless signatures provide long-term log integrity and prove the time of log records cryptographically using independent verification. Main features of the ``rsyslog-ksi-ls12`` module are: * Automated online signing of file output log. * Efficient block-based signing with record-level verification. * Log records removal detection. For best results use the ``rsyslog-ksi-ls12`` module together with Guardtime ``logksi`` tool, which will become handy in: * Signing recovery. * Extension of KSI signatures inside the log signature file. * Verification of the log using log signatures. * Extraction of record-level signatures. * Integration of log signature files (necessary when signing in async mode). Getting Started ############### To get started with log signing: - Sign up to the Guardtime tryout service to be able to connect to KSI blockchain: `guardtime.com/technology/blockchain-developers `_ - Install the ``libksi`` library (v3.13 or later) from Guardtime repository either for RHEL/CentOS 6 ``_ or RHEL/CentOS 7 ``_ - Install the ``rsyslog-ksi-ls12`` module (same version as rsyslog) from Adiscon repository. - Install the accompanying ``logksi`` tool (v1.0 or later) from Guardtime repository either for RHEL/CentOS 6 ``_ or RHEL/CentOS 7 ``_ Currently the log signing is only supported by the file output module, thus the action type must be ``omfile``. To activate signing, add the following parameters to the action of interest in your rsyslog configuration file: Mandatory parameters (no default value defined): Note: parameter names are case-insensitive. - **sig.provider** specifies the signature provider; in case of ``rsyslog-ksi-ls12`` package this is ``"ksi_ls12"``. - **sig.block.levelLimit** defines the maximum level of the root of the local aggregation tree per one block. - **sig.aggregator.url** defines the endpoint of the KSI signing service in KSI Gateway. Supported URI schemes are: - *http://* - *ksi+http://* - *ksi+tcp://* - **sig.aggregator.user** specifies the login name for the KSI signing service. - **sig.aggregator.key** specifies the key for the login name. Optional parameters (if not defined, default value is used): Note: parameter names are case-insensitive. - **sig.syncmode** defines the signing mode: ``"sync"`` (default) or ``"async"``. - **sig.hashFunction** defines the hash function to be used for hashing, default is ``"SHA2-256"``. Other SHA-2, as well as RIPEMED-160 functions are supported. - **sig.block.timeLimit** defines the maximum duration of one block in seconds. Default value ``"0"`` indicates that no time limit is set. - **sig.keepTreeHashes** turns on/off the storing of the hashes that were used as leaves for building the Merkle tree, default is ``"off"``. - **sig.keepRecordHashes** turns on/off the storing of the hashes of the log records, default is ``"on"``. The log signature file, which stores the KSI signatures and information about the signed blocks, appears in the same directory as the log file itself; it is named ``.logsig``. Sample ###### To sign the logs in ``/var/log/secure`` with KSI: :: # The authpriv file has restricted access and is signed with KSI authpriv.* action(type="omfile" file="/var/log/secure" sig.provider="ksi_ls12" sig.syncmode="sync" sig.hashFunction="SHA2-256" sig.block.levelLimit="8" sig.block.timeLimit="0" sig.aggregator.url= "http://tryout.guardtime.net:8080/gt-signingservice" sig.aggregator.user="rsmith" sig.aggregator.key="secret" sig.keepTreeHashes="off" sig.keepRecordHashes="on") Note that all parameter values must be between quotation marks! See Also ######## To better understand the log signing mechanism and the module's possibilities it is advised to consult with: - `KSI Rsyslog Integration User Guide `_ - `KSI Developer Guide `_ Access for both of these documents requires Guardtime tryout service credentials, available from ``_ source/configuration/modules/omhttpfs.rst0000664000175000017500000000343513223143453017762 0ustar rgerrgeromhttpfs: Hadoop HTTPFS Output Module ===================================== =========================== =========================================================================== **Module Name:** **omhttpfs** **Available Since:** **8.10.0** **Author:** `sskaje `_ =========================== =========================================================================== This module is an alternative to omhdfs via `Hadoop HDFS over HTTP `_. **Dependencies** * libcurl **Configure** :: ./configure --enable-omhttpfs **Config options** Legacy config **NOT** supported. Note: parameter names are case-insensitive. - **host** HttpFS server host. Default: *127.0.0.1* - **port** HttpFS server port. Default: *14000* - **user** HttpFS auth user. Default: *hdfs* - **https** \ Turn on if your HttpFS runs on HTTPS. Default: *off* - **file** File to write, or a template name. - **isdynfile** \ Turn this on if your **file** is a template name. See examples below. - **template** Format your message when writing to **file**. Default: *RSYSLOG_FileFormat* **Examples** :: module(load="omhttpfs") template(name="hdfs_tmp_file" type="string" string="/tmp/%$YEAR%/test.log") template(name="hdfs_tmp_filecontent" type="string" string="%$YEAR%-%$MONTH%-%$DAY% %MSG% ==\n") local4.* action(type="omhttpfs" host="10.1.1.161" port="14000" https="off" file="hdfs_tmp_file" isDynFile="on") local5.* action(type="omhttpfs" host="10.1.1.161" port="14000" https="off" file="hdfs_tmp_file" isDynFile="on" template="hdfs_tmp_filecontent") source/configuration/modules/omhiredis.rst0000664000175000017500000000667213223143453020107 0ustar rgerrgeromhiredis: Redis Output Module ============================== **Module Name:** omhiredis **Original Author:** Brian Knox **Description** This module provides native support for writing to Redis, using the hiredis client library. **Action Parameters** Note: parameter names are case-insensitive. - **server** Name or address of the Redis server - **serverport** Port of the Redis server if the server is not listening on the default port. - **serverpassword** Password to support authenticated redis database server to push messages across networks and datacenters. Parameter is optional if not provided AUTH command wont be sent to the server. - **mode** Mode to run the output action in: "queue" or "publish". If not supplied, the original "template" mode is used. Note due to a config parsing bug in 8.13, explicitly setting this to "template" mode will result in a config parsing error. - **template** Template is required if using "template" mode. - **key** Key is required if using "publish" or "queue" mode. - **userpush** if set to on, use RPUSH instead of LPUSH, if not set or off, use LPUSH. **Examples** *Mode: template* In "template" mode, the string constructed by the template is sent to Redis as a command. Note this mode has problems with strings with spaces in them - full message won't work correctly. In this mode, the template argument is required, and the key argument is meaningless. :: module(load="omhiredis") template( name="program_count_tmpl" type="string" string="HINCRBY progcount %programname% 1") action( name="count_programs" server="my-redis-server.example.com" serverport="6379" type="omhiredis" mode="template" template="program_count_tmpl") Here's an example redis-cli session where we HGETALL the counts: :: > redis-cli 127.0.0.1:6379> HGETALL progcount 1) "rsyslogd" 2) "35" 3) "rsyslogd-pstats" 4) "4302" *Mode: queue* In "queue" mode, the syslog message is pushed into a Redis list at "key", using the LPUSH command. If a template is not supplied, the plugin will default to the RSYSLOG_ForwardFormat template. :: module(load="omhiredis") action( name="push_redis" server="my-redis-server.example.com" serverport="6379" type="omhiredis" mode="queue" key="my_queue") Here's an example redis-cli session where we RPOP from the queue: :: > redis-cli 127.0.0.1:6379> RPOP my_queue "<46>2015-09-17T10:54:50.080252-04:00 myhost rsyslogd: [origin software=\"rsyslogd\" swVersion=\"8.13.0.master\" x-pid=\"6452\" x-info=\"http://www.rsyslog.com\"] start" 127.0.0.1:6379> *Mode: publish* In "publish" mode, the syslog message is published to a Redis topic set by "key". If a template is not supplied, the plugin will default to the RSYSLOG_ForwardFormat template. :: module(load="omhiredis") action( name="publish_redis" server="my-redis-server.example.com" serverport="6379" type="omhiredis" mode="publish" key="my_channel") Here's an example redis-cli session where we SUBSCRIBE to the topic: :: > redis-cli 127.0.0.1:6379> subscribe my_channel Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "my_channel" 3) (integer) 1 1) "message" 2) "my_channel" 3) "<46>2015-09-17T10:55:44.486416-04:00 myhost rsyslogd-pstats: {\"name\":\"imuxsock\",\"origin\":\"imuxsock\",\"submitted\":0,\"ratelimit.discarded\":0,\"ratelimit.numratelimiters\":0}" source/configuration/modules/omstdout.rst0000664000175000017500000000235013223143453017767 0ustar rgerrgeromstdout: stdout output module (testbench tool) =============================================== **Module Name:    omstdout** **Author:**\ Rainer Gerhards **Available Since**: 4.1.6 **Description**: This module writes any messages that are passed to it to stdout. It was developed for the rsyslog test suite. However, there may (limited) exist some other usages. Please note we do not put too much effort on the quality of this module as we do not expect it to be used in real deployments. If you do, please drop us a note so that we can enhance its priority! **Configuration parameters**: Note: configuration directive names are case-insensitive. - **$ActionOMStdoutArrayInterface** [on\|**off** This setting instructs omstdout to use the alternate array based method of parameter passing. If used, the values will be output with commas between the values but no other padding bytes. This is a test aid for the alternate calling interface. - **$ActionOMStdoutEnsureLFEnding** [**on**\ \|off Makes sure that each message is written with a terminating LF. This is needed for the automatted tests. If the message contains a trailing LF, none is added. **Caveats/Known Bugs:** Currently none known. source/configuration/modules/omamqp1.rst0000664000175000017500000002635013223143453017472 0ustar rgerrgeromamqp1: AMQP 1.0 Messaging Output Module ========================================= =========================== =========================================================================== **Module Name:** **omamqp1** **Available Since:** **8.17.0** **Original Author:** Ken Giusti =========================== =========================================================================== **Description** This module provides the ability to send logging via an AMQP 1.0 compliant message bus. It puts the log messages into an AMQP message and sends the message to a destination on the bus. **Dependencies** * `libqpid-proton `_ **Configure** :: ./configure --enable-omamqp1 **Message Format** Messages sent from this module to the message bus contain an AMQP List in the message body. This list contains one or more log messages as AMQP String types. Each string entry is a single log message. The list is ordered such that the oldest log appears at the front of the list (e.g. list index 0), whilst the most recent log is at the end of the list. **Interoperability** The output plugin has been tested against the following messaging systems: * `QPID C++ Message Broker `_ * `QPID Dispatch Message Router `_ **Action Parameters** Note: parameter names are case-insensitive. - **host** *(Required)* The address of the message bus in *host[:port]* format. The port defaults to 5672 if absent. Examples: *"localhost"*, *"127.0.0.1:9999"*, *"bus.someplace.org"* - **target** *(Required)* The destination for the generated messages. This can be the name of a queue or topic. On some messages buses it may be necessary to create this target manually. Example: *"amq.topic"* - **username** *(Optional)* Used by SASL to authenticate with the message bus. - **password** *(Optional)* Used by SASL to authenticate with the message bus. - **template** *(Optional)* Format for the log messages. Default: *RSYSLOG_FileFormat* - **idleTimeout** *(Optional)* The idle timeout in seconds. This enables connection heartbeats and is used to detect a failed connection to the message bus. Set to zero to disable. Default: *0* - **reconnectDelay** *(Optional)* The time in seconds this module will delay before attempting to re-established a failed connection to the message bus. Default: *5* - **maxRetries** *(Optional)* The number of times an undeliverable message is re-sent to the message bus before it is dropped. This is unrelated to rsyslog's action.resumeRetryCount. Once the connection to the message bus is active this module is ready to receive log messages from rsyslog (i.e. the module has 'resumed'). Even though the connection is active, any particular message may be rejected by the message bus (e.g. 'unrouteable'). The module will retry (e.g. 'suspend') for up to *maxRetries* attempts before discarding the message as undeliverable. Setting this to zero disables the limit and unrouteable messages will be retried as long as the connection stays up. You probably do not want that to happen. Default: *10* - **disableSASL** *(Optional)* Setting this to a non-zero value will disable SASL negotiation. Only necessary if the message bus does not offer SASL support. **TODO** - Add support for SSL connections. **Examples** This example shows a minimal configuration. The module will attempt to connect to a QPID broker at *broker.amqp.org*. Messages are sent to the *amq.topic* topic, which exists on the broker by default: :: module(load="omamqp1") action(type="omamqp1" host="broker.amqp.org" target="amq.topic") This example forces rsyslogd to authenticate with the message bus. The message bus must be provisioned such that user *joe* is allowed to send to the message bus. All messages are sent to *log-queue*. It is assumed that *log-queue* has already been provisioned: :: module(load="omamqp1") action(type="omamqp1" host="bus.amqp.org" target="log-queue" username="joe" password="trustno1") ------------------------------------------------- **Notes on use with the QPID C++ broker (qpidd)** ------------------------------------------------- *Note well*: These notes assume use of version 0.34 of the QPID C++ broker. Previous versions may not be fully compatible. To use the Apache QPID C++ broker **qpidd** as the message bus, a version of qpidd that supports the AMQP 1.0 protocol must be used. Since qpidd can be packaged without AMQP 1.0 support you should verify AMQP 1.0 has been enabled by checking for AMQP 1.0 related options in the qpidd help text. For example: :: qpidd --help ... AMQP 1.0 Options: --domain DOMAIN Domain of this broker --queue-patterns PATTERN Pattern for on-demand queues --topic-patterns PATTERN Pattern for on-demand topics If no AMQP 1.0 related options appear in the help output then your instance of qpidd does not support AMQP 1.0 and cannot be used with this output module. The destination for message (target) *must* be created before log messages arrive. This can be done using the qpid-config tool. Example: :: qpid-config add queue rsyslogd Alternatively the target can be created on demand by configuring a queue-pattern (or topic-pattern) that matches the target. To do this, add a *queue-patterns* or *topic_patterns* configuration directive to the qpidd configuration file /etc/qpid/qpidd.conf. For example to have qpidd automatically create a queue named *rsyslogd* add the following to the qpidd configuration file: :: queue-patterns=rsyslogd or, if a topic behavior is desired instead of a queue: :: topic-patterns=rsyslogd These dynamic targets are auto-delete and will be destroyed once there are no longer any subscribers or queue-bound messages. Versions of qpidd <= 0.34 also need to have the SASL service name set to *"amqp"* if SASL authentication is used. Add this to the qpidd.conf file: :: sasl-service-name=amqp ---------------------------------------------------------- **Notes on use with the QPID Dispatch Router (qdrouterd)** ---------------------------------------------------------- *Note well*: These notes assume use of version 0.5 of the QPID Dispatch Router **qdrouterd**. Previous versions may not be fully compatible. The default qdrouterd configuration does not have SASL authentication turned on. If SASL authentication is required you must configure SASL in the qdrouter configuration file /etc/qpid-dispatch/qdrouterd.conf First create a SASL configuration file for qdrouterd. This configuration file is usually /etc/sasl2/qdrouterd.conf, but its default location may vary depending on your platform's configuration. This document assumes you understand how to properly configure Cyrus SASL. Here is an example qdrouterd SASL configuration file that allows the client to use either the **DIGEST-MD5** or **PLAIN** authentication mechanisims and specifies the path to the SASL user credentials database: :: pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /var/lib/qdrouterd/qdrouterd.sasldb mech_list: DIGEST-MD5 PLAIN Once a SASL configuration file has been set up for qdrouterd the path to the directory holding the configuration file and the name of the configuration file itself **without the '.conf' suffix** must be added to the /etc/qpid-dispatch/qdrouterd.conf configuration file. This is done by adding *saslConfigPath* and *saslConfigName* to the *container* section of the configuration file. For example, assuming the file /etc/sasl2/qdrouterd.conf holds the qdrouterd SASL configuration: :: container { workerThreads: 4 containerName: Qpid.Dispatch.Router.A saslConfigPath: /etc/sasl2 saslConfigName: qdrouterd } In addition the address used by the omamqp1 module to connect to qdrouterd must have SASL authentication turned on. This is done by adding the *authenticatePeer* attribute set to 'yes' to the corresponding *listener* entry: :: listener { addr: 0.0.0.0 port: amqp authenticatePeer: yes } This should complete the SASL setup needed by qdrouterd. The target address used as the destination for the log messages must be picked with care. qdrouterd uses the prefix of the target address to determine the forwarding pattern used for messages sent to that target address. Addresses starting with the prefix *queue* are distributed to only one message receiver. If there are multiple message consumers listening to that target address only one listener will receive the message - mimicking the behavior of a queue with competing subscribers. For example: *queue/rsyslogd* If a multicast pattern is desired - where all active listeners receive their own copy of the message - the target address prefix *multicast* may be used. For example: *multicast/rsyslogd* Note well: if there are no active receivers for the log messages the messages will be rejected by qdrouterd since the messages are undeliverable. In this case the omamqp1 module will return a **SUSPENDED** status to the rsyslogd main task. rsyslogd may then re-submit the rejected log messages to the module which will attempt to send them again. This retry option is configured via rsyslogd - it is not part of this module. Refer to the rsyslogd actions documentation. --------------------------------------------- **Using qdrouterd in combination with qpidd** --------------------------------------------- A qdrouterd-based message bus can use a broker as a message storage mechanism for those that require broker-based message services (such as a message store). This section explains how to configure qdrouterd and qpidd for this type of deployment. Please read the above notes for deploying qpidd and qdrouterd first. Each qdrouterd instance that is to connect the broker to the message bus must define a *connector* section in the qdrouterd.conf file. This connector contains the addressing information necessary to have the message bus set up a connection to the broker. For example, if a broker is available on host broker.host.com at port 5672: :: connector { name: mybroker role: on-demand addr: broker.host.com port: 5672 } In order to route messages to and from the broker, a static *link route* must be configured on qdrouterd. This link route contains a target address prefix and the name of the connector to use for forwarding matching messages. For example, to have qdrouterd forward messages that have a target address prefixed by "Broker" to the connector defined above, the following link pattern must be added to the qdrouterd.conf configuration: :: linkRoutePattern { prefix: /Broker/ connector: mybroker } A queue must then be created on the broker. The name of the queue must be prefixed by the same prefix specified in the linkRoutePattern entry. For example: :: $ qpid-config add queue Broker/rsyslogd Lastly use the name of the queue for the target address for the omamqp module action. For example, assuming qdrouterd is listening on local port 5672: :: action(type="omamqp1" host="localhost:5672" target="Broker/rsyslogd") source/configuration/modules/index.rst0000664000175000017500000000215713223143453017225 0ustar rgerrgerModules ======= Rsyslog has a modular design. This enables functionality to be dynamically loaded from modules, which may also be written by any third party. Rsyslog itself offers all non-core functionality as modules. Consequently, there is a growing number of modules. Here is the entry point to their documentation and what they do (list is currently not complete) Please note that each module provides (case-insensitive) configuration parameters, which are NOT necessarily being listed below. Also remember, that a modules configuration parameter (and functionality) is only available if it has been loaded. It is relatively easy to write a rsyslog module. If none of the provided modules solve your need, you may consider writing one or have one written for you by `Adiscon's professional services for rsyslog `_ (this often is a very cost-effective and efficient way of getting what you need). There exist different classes of loadable modules: .. toctree:: :maxdepth: 1 idx_output idx_input idx_parser idx_messagemod idx_stringgen idx_library workflow source/configuration/modules/ommail.rst0000664000175000017500000002700413223143453017372 0ustar rgerrgerommail: Mail Output Module ========================== .. index:: ! imudp =========================== =========================================================================== **Module Name:** **ommail** **Available Since:** **3.17.0** **Author:** `Rainer Gerhards `_ =========================== =========================================================================== This module supports sending syslog messages via mail. Each syslog message is sent via its own mail. Obviously, you will want to apply rigorous filtering, otherwise your mailbox (and mail server) will be heavily spammed. The ommail plugin is primarily meant for alerting users. As such, it is assumed that mails will only be sent in an extremely limited number of cases. Ommail uses up to two templates, one for the mail body and optionally one for the subject line. Note that the subject line can also be set to a constant text. If neither the subject nor the mail body is provided, a quite meaningless subject line is used and the mail body will be a syslog message just as if it were written to a file. It is expected that the users customizes both messages. In an effort to support cell phones (including SMS gateways), there is an option to turn off the body part at all. This is considered to be useful to send a short alert to a pager-like device. It is highly recommended to use the  :: action.execonlyonceeveryinterval="" parameter to limit the amount of mails that potentially be generated. With it, mails are sent at most in a interval. This may be your life safer. And remember that an hour has 3,600 seconds, so if you would like to receive mails at most once every two hours, include a :: action.execonlyonceeveryinterval="7200" in the action definition. Messages sent more frequently are simpy discarded. Configuration Parameters ------------------------ Configuration parameters are supported starting with v8.5.0. Earlier v7 and v8 versions did only support legacy parameters. Note: parameter names are case-insensitive. Action Parameters ^^^^^^^^^^^^^^^^^ .. function:: server *Mandatory* Name or IP address of the SMTP server to be used. Must currently be set. The default is 127.0.0.1, the SMTP server on the local machine. Obviously it is not good to expect one to be present on each machine, so this value should be specified. .. function:: port *Mandatory* Port number or name of the SMTP port to be used. The default is 25, the standard SMTP port. .. function:: mailfrom *Mandatory* The email address used as the senders address. .. function:: mailto *Mandatory* The recipient email address(es). Note that this is an array parameter. See samples below on how to specify multiple recipients. .. function:: subject.template *Default: none, but may be left out* The name of the template to be used as the mail subject. If you want to include some information from the message inside the template, you need to use *subject.template* with an appropriate template. If you just need a constant text, you can simply use *subject.text* instead, which doesn't require a template definition. .. function:: subject.text *Default: none, but may be left out* This is used to set a **constant** subject text. .. function:: body.enable *Default: on* Setting this to "off" permits to exclude the actual message body. This may be useful for pager-like devices or cell phone SMS messages. The default is "on", which is appropriate for allmost all cases. Turn it off only if you know exactly what you do! .. function:: template *Default: RSYSLOG_FileFormat* Template to be used for the mail body (if enabled). The *template.subject* and *template.text* parameters cannot be given together inside a single action definition. Use either one of them. If none is used, a more or less meaningless mail subject is generated (we don't tell you the exact text because that can change - if you want to have something specific, configure it!). Caveats/Known Bugs ------------------ The current ommail implementation supports SMTP-direct mode only. In that mode, the plugin talks to the mail server via SMTP protocol. No other process is involved. This mode offers best reliability as it is not depending on any external entity except the mail server. Mail server downtime is acceptable if the action is put onto its own action queue, so that it may wait for the SMTP server to come back online. However, the module implements only the bare SMTP essentials. Most importantly, it does not provide any authentication capabilities. So your mail server must be configured to accept incoming mail from ommail without any authentication needs (this may be change in the future as need arises, but you may also be referred to sendmail-mode). In theory, ommail should also offer a mode where it uses the sendmail utility to send its mail (sendmail-mode). This is somewhat less reliable (because we depend on an entity we do not have close control over - sendmail). It also requires dramatically more system ressources, as we need to load the external process (but that should be no problem given the expected infrequent number of calls into this plugin). The big advantage of sendmail mode is that it supports all the bells and whistles of a full-blown SMTP implementation and may even work for local delivery without a SMTP server being present. Sendmail mode will be implemented as need arises. So if you need it, please drop us a line (I nobody does, sendmail mode will probably never be implemented). Examples -------- The following example alerts the operator if the string "hard disk fatal failure" is present inside a syslog message. The mail server at mail.example.net is used and the subject shall be "disk problem on ". Note how \\r\\n is included inside the body text to create line breaks. A message is sent at most once every 6 hours (21600 seconds), any other messages are silently discarded (or, to be precise, not being forwarded - they are still being processed by the rest of the configuration file). :: module(load="ommail") template (name="mailBody" type="string" string="RSYSLOG Alert\\r\\nmsg='%msg%'") template (name="mailSubject" type="string" string="disk problem on %hostname%") if $msg contains "hard disk fatal failure" then { action(type="ommail" server="mail.example.net" port="25" mailfrom="rsyslog@example.net" mailto="operator@example.net" subject.template="mailSubject" action.execonlyonceeveryinterval="21600") } The following example is exactly like the first one, but it sends the mails to two different email addresses: :: module(load="ommail") template (name="mailBody" type="string" string="RSYSLOG Alert\\r\\nmsg='%msg%'") template (name="mailSubject" type="string" string="disk problem on %hostname%") if $msg contains "hard disk fatal failure" then { action(type="ommail" server="mail.example.net" port="25" mailfrom="rsyslog@example.net" mailto=["operator@example.net", "admin@example.net"] subject.template="mailSubject" action.execonlyonceeveryinterval="21600") } Note the array syntax to specify email addresses. Note that while rsyslog permits you to specify as many recipients as you like, your mail server may limit their number. It is usually a bad idea to use more than 50 recipients, and some servers may have lower limits. If you hit such a limit, you could either create additional actions or (recommended) create an email distribution list. The next example is again mostly equivalent to the previous one, but it uses a constant subject line, so no subject template is required: :: module(load="ommail") template (name="mailBody" type="string" string="RSYSLOG Alert\\r\\nmsg='%msg%'") if $msg contains "hard disk fatal failure" then { action(type="ommail" server="mail.example.net" port="25" mailfrom="rsyslog@example.net" mailto=["operator@example.net", "admin@example.net"] subject.text="rsyslog detected disk problem" action.execonlyonceeveryinterval="21600") } Legacy Configuration Parameters ------------------------------- Note that the legacy configuration parameters do **not** affect new-style action definitions via the action() object. This is by design. To set default for action() objects, use module parameters in the :: module(load="builtin:ommail" ...) object. Read about :ref:`the importance of order in legacy configuration` to understand how to use these configuration parameters. **Legacy parameters should NOT be used when writing new configuration files.** - $ActionMailSMTPServer equivalent to the *server* action parameter. - $ActionMailSMTPPort equivalent to the *port* action parameter. - $ActionMailFrom equivalent to the *mailfrom* action parameter. - $ActionMailTo mostly equivalent to the *mailto* action parameter. However, to specify multiple recpients, repeat this directive as often as needed. Note: **This directive must be specified for each new action and is automatically reset.** [Multiple recipients are supported for 3.21.2 and above.] - $ActionMailSubject equivalent to the *subject.template* action parameter. - $ActionMailEnableBody equivalent to the *body.enable* action parameter. Legacy Examples ^^^^^^^^^^^^^^^ The following sample alerts the operator if the string "hard disk fatal failure" is present inside a syslog message. The mail server at mail.example.net is used and the subject shall be "disk problem on ". Note how \\r\\n is included inside the body text to create line breaks. A message is sent at most once every 6 hours, any other messages are silently discarded (or, to be precise, not being forwarded - they are still being processed by the rest of the configuration file). :: $ModLoad ommail $ActionMailSMTPServer mail.example.net $ActionMailFrom rsyslog@example.net $ActionMailTo operator@example.net $template mailSubject,"disk problem on %hostname%" $template mailBody,"RSYSLOG Alert\\r\\nmsg='%msg%'" $ActionMailSubject mailSubject # make sure we receive a mail only once in six # hours (21,600 seconds ;)) $ActionExecOnlyOnceEveryInterval 21600 # the if ... then ... mailBody must be on one line! if $msg contains 'hard disk fatal failure' then :ommail:;mailBody # re-set interval so that other actions are not affected $ActionExecOnlyOnceEveryInterval 0 The sample below is the same, but sends mail to two recipients: :: $ModLoad ommail $ActionMailSMTPServer mail.example.net $ActionMailFrom rsyslog@example.net $ActionMailTo operator@example.net $ActionMailTo admin@example.net $template mailSubject,"disk problem on %hostname%" $template mailBody,"RSYSLOG Alert\\r\\nmsg='%msg%'" $ActionMailSubject mailSubject # make sure we receive a mail only once in six # hours (21,600 seconds ;)) $ActionExecOnlyOnceEveryInterval 21600 # the if ... then ... mailBody mus be on one line! if $msg contains 'hard disk fatal failure' then :ommail:;mailBody # re-set interval so that other actions are not affected $ActionExecOnlyOnceEveryInterval 0 A more advanced example plus a discussion on using the email feature inside a reliable system can be found in Rainer's blogpost "`Why is native email capability an advantage for a syslogd? `_\ " source/configuration/modules/mmjsonparse.rst0000664000175000017500000000630113223143453020447 0ustar rgerrgerJSON/CEE Structured Content Extraction Module (mmjsonparse) =========================================================== **Module Name:    mmjsonparse** **Available since:**\ 6.6.0+ **Author:**\ Rainer Gerhards **Description**: This module provides support for parsing structured log messages that follow the CEE/lumberjack spec. The so-called "CEE cookie" is checked and, if present, the JSON-encoded structured message content is parsed. The properties are then available as original message properties. As a convenience, mmjsonparse will produce a valid CEE/lumberjack log message if passed a message without the CEE cookie. A JSON structure will be created and the "msg" field will be the only field and it will contain the message. Note that in this case, mmjsonparse will nonetheless return that the JSON parsing has failed. The "CEE cookie" is the character squence "@cee:" which must prepend the actual JSON. Note that the JSON must be valid and MUST NOT be followed by any non-JSON message. If either of these conditions is not true, mmjsonparse will **not** parse the associated JSON. This is based on the cookie definition used in CEE/project lumberjack and is meant to aid against an erroneous detection of a message as being CEE where it is not. This also means that mmjsonparse currently is NOT a generic JSON parser that picks up JSON from whereever it may occur in the message. This is intentional, but future versions may support config parameters to relax the format requirements. Action Parameters ~~~~~~~~~~~~~~~~~ Note: parameter names are case-insensitive. .. function:: cookie **Default**: "@cee:" Permits to set the cookie that must be present in front of the JSON part of the message. Most importantly, this can be set to the empty string ("") in order to not require any cookie. In this case, leading spaces are permitted in front of the JSON. No non-whitespace characters are permitted after the JSON. If such is required, mmnormalize must be used. .. function:: useRawMsg **Default**: off Specifies if the raw message should be used for normalization (on) or just the MSG part of the message (off). .. function:: container **Default**: $! Specifies the JSON container (path) under which parsed elements should be placed. By default, all parsed properties are merged into root of message properties. You can place them under a subtree, instead. You can place them in local variables, also, by setting path="$.". Check parsing result ~~~~~~~~~~~~~~~~~~~~ You can check whether rsyslogd was able to successfully parse the message by reading the $parsesuccess variable : :: action(type="mmjsonparse") if $parsesuccess == "OK" then { action(type="omfile" File="/tmp/output") } else if $parsesuccess == "FAIL" then { action(type="omfile" File="/tmp/parsing_failure") } Example ~~~~~~~ This activates the module and applies normalization to all messages:: module(load="mmjsonparse") action(type="mmjsonparse") To permit parsing messages without cookie, use this action statement:: action(type="mmjsonparse" cookie="") The same in legacy format:: $ModLoad mmjsonparse *.* :mmjsonparse: source/configuration/modules/omlibdbi.rst0000664000175000017500000001240713223143453017676 0ustar rgerrgeromlibdbi: Generic Database Output Module ======================================== **Module Name:** omlibdbi **Author:** Rainer Gerhards **Description**: This modules supports a large number of database systems via `libdbi `_. Libdbi abstracts the database layer and provides drivers for many systems. Drivers are available via the `libdbi-drivers `_ project. As of this writing, the following drivers are available: - `Firebird/Interbase `_ - `FreeTDS `_ (provides access to `MS SQL Server `_ and `Sybase `_) - `MySQL `_ (also supported via the native ommysql plugin in rsyslog) - `PostgreSQL `_\ (also supported via the native ommysql plugin in rsyslog) - `SQLite/SQLite3 `_ The following drivers are in various stages of completion: - `Ingres `_ - `mSQL `_ - `Oracle `_ These drivers seem to be quite usable, at least from an rsyslog point of view. Libdbi provides a slim layer between rsyslog and the actual database engine. We have not yet done any performance testing (e.g. omlibdbi vs. ommysql) but honestly believe that the performance impact should be irrelevant, if at all measurable. Part of that assumption is that rsyslog just does the "insert" and most of the time is spent either in the database engine or rsyslog itself. It's hard to think of any considerable time spent in the libdbi abstraction layer. **Setup** In order for this plugin to work, you need to have libdbi, the libdbi driver for your database backend and the client software for your database backend installed. There are libdbi packages for many distributions. Please note that rsyslogd requires a quite recent version (0.8.3) of libdbi. It may work with older versions, but these need some special ./configure options to support being called from a dlopen()ed plugin (as omlibdbi is). So in short, you probably save you a lot of headache if you make sure you have at least libdbi version 0.8.3 on your system. **Configuration Parameters**: Note: configuration parameter names are case-insensitive. - **$ActionLibdbiDriverDirectory** /path/to/dbd/drivers This is a global setting. It points libdbi to its driver directory. Usually, you do not need to set it. If you installed libdbi-driver's at a non-standard location, you may need to specify the directory here. If you are unsure, do not use this configuration parameter. Usually, everything works just fine.\ - **$ActionLibdbiDriver** drivername Name of the dbidriver to use, see libdbi-drivers documentation. As a quick excerpt, at least those were available at the time of this writiting "mysql" (suggest to use ommysql instead), "firebird" (Firbird and InterBase), "ingres", "msql", "Oracle", "sqlite", "sqlite3", "freetds" (for Microsoft SQL and Sybase) and "pgsql" (suggest to use ompgsql instead). - **$ActionLibdbiHost** hostname The host to connect to. - **$ActionLibdbiUserName** user The user used to connect to the database. - **$ActionlibdbiPassword** That user's password. - **$ActionlibdbiDBName** db The database that shall be written to. - **selector line:** :omlibdbi:;template executes the recently configured omlibdbi action. The ;template part is optional. If no template is provided, a default template is used (which is currently optimized for MySQL - sorry, folks...) **Caveats/Known Bugs:** You must make sure that any templates used for omlibdbi properly escape strings. This is usually done by supplying the SQL (or STDSQL) option to the template. Omlibdbi rejects templates without this option for security reasons. However, omlibdbi does not detect if you used the right option for your backend. Future versions of rsyslog (with full expression  support) will provide advanced ways of handling this situation. So far, you must be careful. The default template provided by rsyslog is suitable for MySQL, but not necessarily for your database backend. Be careful! If you receive the rsyslog error message "libdbi or libdbi drivers not present on this system" you may either not have libdbi and its drivers installed or (very probably) the version is earlier than 0.8.3. In this case, you need to make sure you have at least 0.8.3 and the libdbi driver for your database backend present on your system. I do not have most of the database supported by omlibdbi in my lab. So it received limited cross-platform tests. If you run into troubles, be sure the let us know at `http://www.rsyslog.com `_. **Sample:** The following sample writes all syslog messages to the database "syslog\_db" on mysqlserver.example.com. The server is MySQL and being accessed under the account of "user" with password "pwd" (if you have empty passwords, just remove the $ActionLibdbiPassword line). :: $ModLoad omlibdbi $ActionLibdbiDriver mysql $ActionLibdbiHost mysqlserver.example.com $ActionLibdbiUserName user $ActionLibdbiPassword pwd $ActionLibdbiDBName syslog\_db \*.\* :omlibdbi: source/configuration/modules/sigprov_ksi.rst0000664000175000017500000000571213223143453020455 0ustar rgerrgerKeyless Signature Infrastructure Provider (ksi) =============================================== **Signature Provider Name: ksi** **Author:** Rainer Gerhards **Supported:** from 8.11.0 to 8.26.0 **Description**: Provides the ability to sign syslog messages via the GuardTime KSI signature services. **Configuration Parameters**: Note: parameter names are case-insensitive. Signature providers are loaded by omfile, when the provider is selected in its "sig.providerName" parameter. Parameters for the provider are given in the omfile action instance line. This provider creates a signature file with the same base name but the extension ".ksisig" for each log file (both for fixed-name files as well as dynafiles). Both files together form a set. So you need to archive both in order to prove integrity. - **sig.hashFunction** The following hash algorithms are currently supported: - SHA1 - SHA2-256 - RIPEMD-160 - SHA2-224 - SHA2-384 - SHA2-512 - RIPEMD-256 - SHA3-244 - SHA3-256 - SHA3-384 - SHA3-512 - SM3 - **sig.aggregator.uri** This provides the URL of the KSI Aggregator service provided by guardtime and looks like this: ksi+tcp://[ip/dnsname]:3332 - **sig.aggregator.user** Set your username provided by Guardtime here. - **sig.aggregator.key** Set your key provided by Guardtime here. - **sig.block.sizeLimit** The maximum number of records inside a single signature block. By default, there is no size limit, so the signature is only written on file closure. Note that a signature request typically takes between one and two seconds. So signing to frequently is probably not a good idea. - **sig.keepRecordHashes** Controls if record hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (65 bytes for each log record for SHA2-512 hashes, for example). - **sig.keepTreeHashes** Controls if tree (intermediate) hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (a bit mire than the amount sig.keepRecordHashes requries). Note that both Tree and Record hashes can be kept inside the signature file. **See Also** **Caveats/Known Bugs:** - currently none known **Samples:** This writes a log file with it's associated signature file. Default parameters are used. :: action(type="omfile" file="/var/log/somelog" sig.provider="ksi") In the next sample, we use the more secure SHA2-512 hash function, sign every 10,000 records and Tree and Record hashes are kept. :: action(type="omfile" file="/var/log/somelog" sig.provider="ksi" sig.hashfunction="SHA2-512" sig.block.sizelimit="10000" sig.keepTreeHashes="on" sig.keepRecordHashes="on") source/configuration/modules/ompipe.rst0000664000175000017500000000256213223143453017407 0ustar rgerrgerompipe: Pipe Output Module ========================== **Module Name:    ompipe** **Author:**\ Rainer Gerhards **Description**: The ompipe plug-in provides the core functionality for logging output to named pipes (fifos). It is a built-in module that does not need to be loaded. **Global Configuration Parameters:** Note: parameter names are case-insensitive. - Template: [templateName] sets a new default template for file actions. **Action specific Configuration Parameters:** Note: parameter names are case-insensitive. - Pipe: string a fifo or named pipe can be used as a destination for log messages. **Caveats/Known Bugs:** None **Sample:** The following command sends all syslog messages to a remote server via TCP port 10514. ::     Module (path="builtin:ompipe")     *.* action(type="ompipe" Pipe="NameofPipe") **Legacy Configuration Parameters:** rsyslog has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipe symbol ("|") to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo(1) command before rsyslogd is started. **Legacy Sample:** The following command sends all syslog messages to a remote server via TCP port 10514. ::     $ModLoad ompipe     *.* |/var/log/pipe source/configuration/modules/idx_messagemod.rst0000664000175000017500000000064313223143030021073 0ustar rgerrgerMessage Modification Modules ---------------------------- Message modification modules are used to change the content of messages being processed. They can be implemented using either the output module or the parser module interface. From the rsyslog core's point of view, they actually are output or parser modules, it is their implementation that makes them special. .. toctree:: :maxdepth: 1 :glob: mm* source/configuration/modules/omelasticsearch.rst0000664000175000017500000003071713223143453021267 0ustar rgerrgeromelasticsearch: Elasticsearch Output Module ============================================ **Module Name:    omelasticsearch** **Author:**\ Rainer Gerhards **Available since:**\ 6.4.0+ **Description**: This module provides native support for logging to `Elasticsearch `_. Action Parameters ----------------- Note: parameter names are case-insensitive. .. _server: - **server** [ ``http://`` | ``https://`` | ] <*hostname* | *ip*> [ ``:`` <*port*> ] An array of Elasticsearch servers in the specified format. If no scheme is specified, it will be chosen according to usehttps_. If no port is specified, serverport_ will be used. Defaults to "localhost". Requests to Elasticsearch will be load-balanced between all servers in round-robin fashion. :: Examples: server="localhost:9200" server=["elasticsearch1", "elasticsearch2"] .. _serverport: - **serverport** Default HTTP port to use to connect to Elasticsearch if none is specified on a server_. Defaults to 9200 .. _healthchecktimeout: - **healthchecktimeout** Specifies the number of milliseconds to wait for a successful health check on a server_. Before trying to submit events to Elasticsearch, rsyslog will execute an *HTTP HEAD* to ``/_cat/health`` and expect an *HTTP OK* within this timeframe. Defaults to 3500. *Note, the health check is verifying connectivity only, not the state of the Elasticsearch cluster.* .. _searchIndex: - **searchIndex** `Elasticsearch index `_ to send your logs to. Defaults to "system" .. _dynSearchIndex: - **dynSearchIndex**\ Whether the string provided for searchIndex_ should be taken as a `rsyslog template `_. Defaults to "off", which means the index name will be taken literally. Otherwise, it will look for a template with that name, and the resulting string will be the index name. For example, let's assume you define a template named "date-days" containing "%timereported:1:10:date-rfc3339%". Then, with dynSearchIndex="on", if you say searchIndex="date-days", each log will be sent to and index named after the first 10 characters of the timestamp, like "2013-03-22". .. _searchType: - **searchType** `Elasticsearch type `_ to send your index to. Defaults to "events" .. _dynSearchType: - **dynSearchType** Like dynSearchIndex_, it allows you to specify a `rsyslog template `_ for searchType_, instead of a static string. .. _pipelineName: - **pipelineName** The `ingest node `_ pipeline name to be inclued in the request. This allows pre processing of events bevor indexing them. By default, events are not send to a pipeline. .. _dynPipelineName: - **dynPipelineName** Like dynSearchIndex_, it allows you to specify a `rsyslog template `_ for pipelineName_, instead of a static string. .. _asyncrepl: - **asyncrepl**\ No longer supported as ElasticSearch no longer supports it. .. _usehttps: - **usehttps**\ Default scheme to use when sending events to Elasticsearch if none is specified on a server_. Good for when you have Elasticsearch behind Apache or something else that can add HTTPS. Note that if you have a self-signed certificate, you'd need to install it first. This is done by copying the certificate to a trusted path and then running *update-ca-certificates*. That trusted path is typically */usr/local/share/ca-certificates* but check the man page of *update-ca-certificates* for the default path of your distro .. _timeout: - **timeout** How long Elasticsearch will wait for a primary shard to be available for indexing your log before sending back an error. Defaults to "1m". .. _template: - **template** This is the JSON document that will be indexed in Elasticsearch. The resulting string needs to be a valid JSON, otherwise Elasticsearch will return an error. Defaults to: :: $template JSONDefault, "{\"message\":\"%msg:::json%\",\"fromhost\":\"%HOSTNAME:::json%\",\"facility\":\"%syslogfacility-text%\",\"priority\":\"%syslogpriority-text%\",\"timereported\":\"%timereported:::date-rfc3339%\",\"timegenerated\":\"%timegenerated:::date-rfc3339%\"}" Which will produce this sort of documents (pretty-printed here for readability): :: {     "message": " this is a test message",     "fromhost": "test-host",     "facility": "user",     "priority": "info",     "timereported": "2013-03-12T18:05:01.344864+02:00",     "timegenerated": "2013-03-12T18:05:01.344864+02:00" } .. _bulkmode: - **bulkmode**\ The default "off" setting means logs are shipped one by one. Each in its own HTTP request, using the `Index API `_. Set it to "on" and it will use Elasticsearch's `Bulk API `_ to send multiple logs in the same request. The maximum number of logs sent in a single bulk request depends on your maxbytes_ and queue settings - usually limited by the `dequeue batch size `_. More information about queues can be found `here `_. .. _maxbytes: - **maxbytes** *(since v8.23.0)* When shipping logs with bulkmode_ **on**, maxbytes specifies the maximum size of the request body sent to Elasticsearch. Logs are batched until either the buffer reaches maxbytes or the the `dequeue batch size `_ is reached. In order to ensure Elasticsearch does not reject requests due to content length, verify this value is set accoring to the `http.max_content_length `_ setting in Elasticsearch. Defaults to 100m. .. _parent: - **parent** Specifying a string here will index your logs with that string the parent ID of those logs. Please note that you need to define the `parent field `_ in your `mapping `_ for that to work. By default, logs are indexed without a parent. .. _dynParent: - **dynParent**\ Using the same parent for all the logs sent in the same action is quite unlikely. So you'd probably want to turn this "on" and specify a `rsyslog template `_ that will provide meaningful parent IDs for your logs. .. _uid: - **uid** If you have basic HTTP authentication deployed (eg through the `elasticsearch-basic plugin `_), you can specify your user-name here. .. _pwd: - **pwd** Password for basic authentication. .. _errorfile: - **errorfile** (optional) If specified, records failed in bulk mode are written to this file, including their error cause. Rsyslog itself does not process the file any more, but the idea behind that mechanism is that the user can create a script to periodically inspect the error file and react appropriately. As the complete request is included, it is possible to simply resubmit messages from that script. *Please note:* when rsyslog has problems connecting to elasticsearch, a general error is assumed and the submit is retried. However, if we receive negative responses during batch processing, we assume an error in the data itself (like a mandatory field is not filled in, a format error or something along those lines). Such errors cannot be solved by simpy resubmitting the record. As such, they are written to the error file so that the user (script) can examine them and act appropriately. Note that e.g. after search index reconfiguration (e.g. dropping the mandatory attribute) a resubmit may be succesful. Statistic Counter ----------------- This plugin maintains global :doc:`statistics <../rsyslog_statistic_counter>`, which accumulate all action instances. The statistic is named "omelasticsearch". Parameters are: - **submitted** - number of messages submitted for processing (with both success and error result) - **fail.httprequests** - the number of times a http request failed. Note that a single http request may be used to submit multiple messages, so this number may be (much) lower than fail.http. - **fail.http** - number of message failures due to connection like-problems (things like remote server down, broken link etc) - **fail.es** - number of failures due to elasticsearch error reply; Note that this counter does NOT count the number of failed messages but the number of times a failure occured (a potentially much smaller number). Counting messages would be quite performance-intense and is thus not done. **The fail.httprequests and fail.http counters reflect only failures that omelasticsearch detected.** Once it detects problems, it (usually, depends on circumstances) tell the rsyslog core that it wants to be suspended until the situation clears (this is a requirement for rsyslog output modules). Once it is suspended, it does NOT receive any further messages. Depending on the user configuration, messages will be lost during this period. Those lost messages will NOT be counted by impstats (as it does not see them). Note that some previous (pre 7.4.5) versions of this plugin had different counters. These were experimental and confusing. The only ones really used were "submits", which were the number of successfully processed messages and "connfail" which were equivalent to "failed.http". Samples ------- The following sample does the following: - loads the omelasticsearch module - outputs all logs to Elasticsearch using the default settings :: module(load="omelasticsearch") *.* action(type="omelasticsearch") The following sample does the following: - loads the omelasticsearch module - defines a template that will make the JSON contain the following properties - RFC-3339 timestamp when the event was generated - the message part of the event - hostname of the system that generated the message - severity of the event, as a string - facility, as a string - the tag of the event - outputs to Elasticsearch with the following settings - host name of the server is myserver.local - port is 9200 - JSON docs will look as defined in the template above - index will be "test-index" - type will be "test-type" - activate bulk mode. For that to work effectively, we use an in-memory queue that can hold up to 5000 events. The maximum bulk size will be 300 - retry indefinitely if the HTTP request failed (eg: if the target server is down) :: module(load="omelasticsearch") template(name="testTemplate"          type="list"          option.json="on") {            constant(value="{")              constant(value="\"timestamp\":\"")      property(name="timereported" dateFormat="rfc3339")              constant(value="\",\"message\":\"")     property(name="msg")              constant(value="\",\"host\":\"")        property(name="hostname")              constant(value="\",\"severity\":\"")    property(name="syslogseverity-text")              constant(value="\",\"facility\":\"")    property(name="syslogfacility-text")              constant(value="\",\"syslogtag\":\"")   property(name="syslogtag")            constant(value="\"}")          } action(type="omelasticsearch"        server="myserver.local"        serverport="9200"        template="testTemplate"        searchIndex="test-index"        searchType="test-type"        bulkmode="on"        maxbytes="100m"        queue.type="linkedlist"        queue.size="5000"        queue.dequeuebatchsize="300"        action.resumeretrycount="-1") source/configuration/modules/omruleset.rst0000664000175000017500000001476713223143453020147 0ustar rgerrgeromruleset: ruleset output/including module ========================================== **Module Name:    omruleset** **Author:**\ Rainer Gerhards **Available Since**: 5.3.4 **Deprecated in**: 7.2.0+ **Deprecation note** This module exists only for backwards-compatibility reasons. **Do no longer use it in new configurations.** It has been replaced by the much more efficient `"call" RainerScript statement `_. The "call" statement supports everything omruleset does, but in an easier to use way. **Description**: This is a very special "output" module. It permits to pass a message object to another rule set. While this is a very simple action, it enables very complex configurations, e.g. it supports high-speed "and" conditions, sending data to the same file in a non-racy way, include-ruleset functionality as well as some high-performance optimizations (in case the rule sets have the necessary queue definitions). While it leads to a lot of power, this output module offers seamingly easy functionaltiy. The complexity (and capablities) arise from how everthing can be combined. With this module, a message can be sent to processing to another ruleset. This is somewhat similar to a "#include" in the C programming language. However, one needs to keep on the mind that a ruleset can contain its own queue and that a queue can run in various modes. Note that if no queue is defined in the ruleset, the message is enqueued into the main message queue. This most often is not optimal and means that message processing may be severely defered. Also note that when the ruleset's target queue is full and no free space can be aquired within the usual timeout, the message object may actually be lost. This is an extreme scenario, but users building an audit-grade system need to know this restriction. For regular installations, it should not really be relevant. **At minimum, be sure you understand the** :doc:`$RulesetCreateMainQueue <../ruleset/rsconf1_rulesetcreatemainqueue>` **directive as well as the importance of statement order in rsyslog.conf before using omruleset!** **Recommended Use:** - create rulesets specifically for omruleset - create these rulesets with their own main queue - decent queueing parameters (sizes, threads, etc) should be used for the ruleset main queue. If in doubt, use the same parameters as for the overall main queue. - if you use multiple levels of ruleset nesting, double check for endless loops - the rsyslog engine does not detect these **Configuration Parameters**: Note: parameter names are case-insensitive. - **$ActionOmrulesetRulesetName** ruleset-to-submit-to This directive specifies the name of the ruleset that the message provided to omruleset should be submitted to. This ruleset must already have been defined. Note that the directive is automatically reset after each :omruleset: action and there is no default. This is done to prevent accidential loops in ruleset definition, what can happen very quickly. The :omruleset: action will NOT be honored if no ruleset name has been defined. As usual, the ruleset name must be specified in front of the action that it modifies. **Examples:** This example creates a ruleset for a write-to-file action. The idea here is that the same file is written based on multiple filters, problems occur if the file is used together with a buffer. That is because file buffers are action-specific, and so some partial buffers would be written. With omruleset, we create a single action inside its own ruleset and then pass all messages to it whenever we need to do so. Of course, such a simple situation could also be solved by a more complex filter, but the method used here can also be utilized in more complex scenarios (e.g. with multiple listeners). The example tries to keep it simple. Note that we create a ruleset-specific main queue (for simplicity with the default main queue parameters) in order to avoid re-queueing messages back into the main queue. :: $ModLoad omruleset # define ruleset for commonly written file $RuleSet CommonAction $RulesetCreateMainQueue on *.* /path/to/file.log #switch back to default ruleset $ruleset RSYSLOG_DefaultRuleset # begin first action # note that we must first specify which ruleset to use for omruleset: $ActionOmrulesetRulesetName CommonAction mail.info :omruleset: # end first action # begin second action # note that we must first specify which ruleset to use for omruleset: $ActionOmrulesetRulesetName CommonAction :FROMHOST, isequal, "myhost.example.com" :omruleset: #end second action # of course, we can have "regular" actions alongside :omrulset: actions *.* /path/to/general-message-file.log The next example is used to creat a high-performance nested and filter condition. Here, it is first checked if the message contains a string "error". If so, the message is forwarded to another ruleset which then applies some filters. The advantage of this is that we can use high-performance filters where we otherwise would need to use the (much slower) expression-based filters. Also, this enables pipeline processing, in that second ruleset is executed in parallel to the first one. :: $ModLoad omruleset # define "second" ruleset $RuleSet nested $RulesetCreateMainQueue on # again, we use our own queue mail.* /path/to/mailerr.log kernel.* /path/to/kernelerr.log auth.* /path/to/autherr.log #switch back to default ruleset $ruleset RSYSLOG_DefaultRuleset # begin first action - here we filter on "error" # note that we must first specify which ruleset to use for omruleset: $ActionOmrulesetRulesetName nested :msg, contains, "error" :omruleset: #end first action # begin second action - as an example we can do anything else in # this processing. Note that these actions are processed concurrently # to the ruleset "nested" :FROMHOST, isequal, "myhost.example.com" /path/to/host.log #end second action # of course, we can have "regular" actions alongside :omrulset: actions *.* /path/to/general-message-file.log **Caveats/Known Bugs:** The current configuration file language is not really adequate for a complex construct like omruleset. Unfortunately, more important work is currently preventing me from redoing the config language. So use extreme care when nesting rulesets and be sure to test-run your config before putting it into production, ensuring you have a suffciently large probe of the traffic run over it. If problems arise, the `rsyslog debug log `_ is your friend. source/configuration/modules/imudp.rst0000664000175000017500000003527013223143453017236 0ustar rgerrgerimudp: UDP Syslog Input Module ============================== .. index:: ! imudp =========================== =========================================================================== **Module Name:**  **imudp** **Author:** `Rainer Gerhards `_ =========================== =========================================================================== Provides the ability to receive syslog messages via UDP. Multiple receivers may be configured by specifying multiple input statements. Note that in order to enable UDP reception, Firewall rules probably need to be modified as well. Also, SELinux may need additional rules. Configuration Parameters ------------------------ Note: parameter names are case-insensitive. .. index:: imudp; module parameters Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. .. function:: TimeRequery *Default: 2* This is a performance optimization. Getting the system time is very costly. With this setting, imudp can be instructed to obtain the precise time only once every n-times. This logic is only activated if messages come in at a very fast rate, so doing less frequent time calls should usually be acceptable. The default value is two, because we have seen that even without optimization the kernel often returns twice the identical time. You can set this value as high as you like, but do so at your own risk. The higher the value, the less precise the timestamp. **Note:** the timeRequery is done based on executed system calls (**not** messages received). So when batch sizes are used, multiple messages are received with one system call. All of these messages always receive the same timestamp, as they are effectively received at the same time. When there is very high traffic and successive system calls immediately return the next batch of messages, the time requery logic kicks in, which means that by default time is only queried for every second batch. Again, this should not cause a too-much deviation as it requires messages to come in very rapidly. However, we advise not to set the "timeRequery" parameter to a large value (larger than 10) if input batches are used. .. function:: SchedulingPolicy *Default: unset* Can be used the set the scheduler priority, if the necessary functionality is provided by the platform. Most useful to select "fifo" for real-time processing under Linux (and thus reduce chance of packet loss). .. function:: SchedulingPriority *Default: unset* Scheduling priority to use. .. function:: batchSize *Default: 32* This parameter is only meaningful if the system support recvmmsg() (newer Linux OSs do this). The parameter is silently ignored if the system does not support it. If supported, it sets the maximum number of UDP messages that can be obtained with a single OS call. For systems with high UDP traffic, a relatively high batch size can reduce system overhead and improve performance. However, this parameter should not be overdone. For each buffer, max message size bytes are statically required. Also, a too-high number leads to reduced efficiency, as some structures need to be completely initialized before the OS call is done. We would suggest to not set it above a value of 128, except if experimental results show that this is useful. .. function:: threads *Available since: 7.5.5* *Default: 1* Number of worker threads to process incoming messages. These threads are utilized to pull data off the network. On a busy system, additional threads (but not more than there are CPUs/Cores) can help improving performance and avoiding message loss. Note that with too many threads, performance can suffer. There is a hard upper limit on the number of threads that can be defined. Currently, this limit is set to 32. It may increase in the future when massive multicore processors become available. .. index:: imudp; input parameters Input Parameters ^^^^^^^^^^^^^^^^ ..index:: imudp; address (input parameter) .. function:: Address *Default: \** Local IP address (or name) the UDP server should bind to. Use \"*" to bind to all of the machine's addresses. .. index:: single: imudp; port (input parameter) .. function:: Port *Default: 514* Specifies the port the server shall listen to.. Either a single port can be specified or an array of ports. If multiple ports are specified, a listener will be automatically started for each port. Thus, no additional inputs need to be configured. Single port: Port="514" Array of ports: Port=["514","515","10514","..."] .. function:: ipfreebind *Available since: 8.18.0* *Default: 2* Manages the IP_FREEBIND option on the UDP socket, which allows binding it to an IP address that is nonlocal or not (yet) associated to any network interface. The parameter accepts the following values: - 0 - does not enable the IP_FREEBIND option on the UDP socket. If the *bind()* call fails because of *EADDRNOTAVAIL* error, socket initialization fails. - 1 - silently enables the IP_FREEBIND socket option if it is required to successfully bind the socket to a nonlocal address. - 2 - enables the IP_FREEBIND socket option and warns when it is used to successfully bind the socket to a nonlocal address. .. function:: Device *Default: none* Bind socket to given device (e.g., eth0) For Linux with VRF support, the Device option can be used to specify the VRF for the Address. .. function:: Ruleset *Default: RSYSLOG_DefaultRuleset* Binds the listener to a specific :doc:`ruleset <../../concepts/multi_ruleset>`. .. function:: RateLimit.Interval [number] *Available since: 7.3.1* *Default: 0* The rate-limiting interval in seconds. Value 0 turns off rate limiting. Set it to a number of seconds (5 recommended) to activate rate-limiting. .. function:: RateLimit.Burst [number] *Available since: 7.3.1* *Default: 10000* Specifies the rate-limiting burst in number of messages. .. function:: name [name] *Available since: 8.3.3* *Default: imudp* specifies the value of the inputname property. In older versions, this was always "imudp" for all listeners, which still is the default. Starting with 7.3.9 it can be set to different values for each listener. Note that when a single input statement defines multipe listner ports, the inputname will be the same for all of them. If you want to differentiate in that case, use "name.appendPort" to make them unique. Note that the "name" parameter can be an empty string. In that case, the corresponding inputname property will obviously also be the empty string. This is primarily meant to be used together with "name.appendPort" to set the inputname equal to the port. .. function:: InputName [name] *Available since: 7.3.9* **Deprecated** This provides the same functionality as "name". It is the historical parameter name and should not be used in new configurations. It is scheduled to be removed some time in the future. .. function:: name.appendPort [on/off] *Available since: 7.3.9* *Default: off* Appends the port the the inputname property. Note that when no "name" is specified, the default of "imudp" is used and the port is appended to that default. So, for example, a listner port of 514 in that case will lead to an inputname of "imudp514". The ability to append a port is most useful when multiple ports are defined for a single input and each of the inputnames shall be unique. Note that there currently is no differentiation between IPv4/v6 listeners on the same port. .. function:: InputName.AppendPort [on/off] *Available since: 7.3.9* **Deprecated** This provides the same functionality as "name.appendPort". It is the historical parameter name and should not be used in new configurations. It is scheduled to be removed some time in the future. .. function:: defaultTZ *Default: unset* This is an **experimental** parameter; details may change at any time and it may also be discoutinued without any early warning. Permits to set a default timezone for this listener. This is useful when working with legacy syslog (RFC3164 et al) residing in different timezones. If set it will be used as timezone for all messages **that do not contain timezone info**. Currently, the format **must** be "+/-hh:mm", e.g. "-05:00", "+01:30". Other formats, including TZ names (like EST) are NOT yet supported. Note that consequently no daylight saving settings are evaluated when working with timezones. If an invalid format is used, "interesting" things can happen, among them malformed timestamps and rsyslogd segfaults. This will obviously be changed at the time this feature becomes non-experimental. .. function:: rcvbufSize [size] *Available since: 7.5.3* *Default: unset* *Maximum Value: 1G* This request a socket receive buffer of specific size from the operating system. It is an expert parameter, which should only be changed for a good reason. Note that setting this parameter disables Linux auto-tuning, which usually works pretty well. The default value is 0, which means "keep the OS buffer size unchanged". This is a size value. So in addition to pure integer values, sizes like "256k", "1m" and the like can be specified. Note that setting very large sizes may require root or other special privileges. Also note that the OS may slightly adjust the value or shrink it to a system-set max value if the user is not sufficiently privileged. Technically, this parameter will result in a setsockopt() call with SO\_RCVBUF (and SO\_RCVBUFFORCE if it is available). Statistic Counter ----------------- This plugin maintains :doc:`statistics <../rsyslog_statistic_counter>` for each listener and for each worker thread. The listener statistic is named starting with "imudp", followed followed by the listener IP, a colon and port in parenthesis. For example, the counter for a listener on port 514 (on all IPs) with no set name is called "imudp(\*:514)". If an "inputname" is defined for a listener, that inputname is used instead of "imudp" as statistic name. For example, if the inputname is set to "myudpinut", that corresponding statistic name in above case would be "myudpinput(\*:514)". This has been introduced in 7.5.3. The following properties are maintained for each listener: - **submitted** - total number of messages submitted for processing since startup The worker thread (in short: worker) statistic is named "imudp(wX)" where "X" is the worker thread ID, which is an monotonically increasing integer starting at 0. This means the first worker will have the name "imudp(w0″), the second "imudp(w1)" and so on. Note that workers are all equal. It doesn’t really matter which worker processes which messages, so the actual worker ID is not of much concern. More interesting is to check how the load is spread between the worker. Also note that there is no fixed worker-to-listener relationship: all workers process messages from all listeners. Note: worker thread statistics are available starting with rsyslog 7.5.5. The following properties are maintained for each worker thread: - **called.recvmmsg** - number of recvmmsg() OS calls done - **called.recvmsg** - number of recvmsg() OS calls done - **msgs.received** - number of actual messages received See Also -------- - `rsyslog video tutorial on how to store remote messages in a separate file `_. - Description of `rsyslog statistic counters `_. This also describes all imudp counters. Caveats/Known Bugs ------------------ - Scheduling parameters are set **after** privileges have been dropped. In most cases, this means that setting them will not be possible after privilege drop. This may be worked around by using a sufficiently-privileged user account. Samples ------- This sets up an UPD server on port 514: :: module(load="imudp") # needs to be done just once input(type="imudp" port="514") This sets up a UDP server on port 514 bound to device eth0: :: module(load="imudp") # needs to be done just once input(type="imudp" port="514" device="eth0") The following sample is mostly equivalent to the first one, but request a larger rcvuf size. Note that 1m most probably will not be honored by the OS until the user is sufficiently privileged. :: module(load="imudp") # needs to be done just once input(type="imudp" port="514" rcvbufSize="1m") In the next example, we set up three listeners at ports 10514, 10515 and 10516 and assign a listner name of "udp" to it, followed by the port number: :: module(load="imudp") input(type="imudp" port=["10514","10515","10516"] inputname="udp" inputname.appendPort="on") The next example is almost equal to the previous one, but now the inputname property will just be set to the port number. So if a message was received on port 10515, the input name will be "10515" in this example whereas it was "udp10515" in the previous one. Note that to do that we set the inputname to the empty string. :: module(load="imudp") input(type="imudp" port=["10514","10515","10516"] inputname="" inputname.appendPort="on") Legacy Configuration Directives ------------------------------- Legacy configuration parameters should **not** be used when crafting new configuration files. It is easy to get things wrong with them. ====================================== ==================== ======================= Directive Equivalent Parameter Requires ====================================== ==================== ======================= $UDPServerTimeRequery *TimeRequery* $IMUDPSchedulingPolicy *SchedulingPolicy* 4.7.4+, 5.7.3+, 6.1.3+ $IMUDPSchedulingPriority *SchedulingPriority* 4.7.4+, 5.7.3+, 6.1.3+ $UDPServerAddress Address $UDPServerRun Port $InputUDPServerBindRuleset Ruleset 5.3.2+ ====================================== ==================== ======================= Note: module parameters are given in *italics*. All others are input parameters. Multiple receivers may be configured by specifying $UDPServerRun multiple times. Legacy Sample ^^^^^^^^^^^^^ This sets up an UDP server on port 514: :: $ModLoad imudp # needs to be done just once $UDPServerRun 514 source/configuration/modules/imuxsock.rst0000664000175000017500000005265213223143453017765 0ustar rgerrgerimuxsock: Unix Socket Input *************************** =========================== =========================================================================== **Module Name:**  **imuxsock** **Author:** `Rainer Gerhards `_ =========================== =========================================================================== Purpose ======= This module provides the ability to accept syslog messages from applications running on the local system via Unix sockets. Most importantly, this is the mechanism by which the :manpage:`syslog(3)` call delivers syslog messages to rsyslogd. Notable Features ================ - :ref:`rate-limiting-label` - :ref:`trusted-properties-label` - :ref:`flow-control-label` - :ref:`application-timestamps-label` - :ref:`systemd-details-label` Configuration Parameters ======================== .. note:: Parameter names are case-insensitive. Global Parameters ----------------- .. warning:: When running under systemd, **many "sysSock." parameters are ignored**. See parameter descriptions and the :ref:`systemd-details-label` section for details. - **SysSock.IgnoreTimestamp** [**on**/off] Ignore timestamps included in the messages, applies to messages received via the system log socket. - **SysSock.IgnoreOwnMessages** [**on**/off] (available since 7.3.7) Ignores messages that originated from the same instance of rsyslogd. There usually is no reason to receive messages from ourselves. This setting is vital when writing messages to the Linux journal. See :doc:`omjournal ` module documentation for a more in-depth description. - **SysSock.Use** (imuxsock) [**on**/off] - Listen on the default local log socket (``/dev/log``) or, if provided, use the log socket value assigned to the ``SysSock.Name`` parameter instead of the default. This is most useful if you run multiple instances of rsyslogd where only one shall handle the system log socket. Unless disabled by the ``SysSock.Unlink`` setting, this socket is created upon rsyslog startup and deleted upon shutdown, according to traditional syslogd behavior. The behavior of this parameter is different for systemd systems. For those systems, ``SysSock.Use`` still needs to be enabled, but the value of ``SysSock.Name`` is ignored and the socket provided by systemd is used instead. If this parameter is *not* enabled, then imuxsock will only be of use if a custom input is configured. See the :ref:`systemd-details-label` section for details. - **SysSock.Name** - specifies an alternate log socket to be used instead of the default system log socket, traditionally ``/dev/log``. Unless disabled by the ``SysSock.Unlink`` setting, this socket is created upon rsyslog startup and deleted upon shutdown, according to traditional syslogd behavior. The behavior of this parameter is different for systemd systems. See the the :ref:`systemd-details-label` section for details. - **SysSock.FlowControl** [on/**off**] - specifies if flow control should be applied to the system log socket. - **SysSock.UsePIDFromSystem** [on/**off**] - specifies if the pid being logged shall be obtained from the log socket itself. If so, the TAG part of the message is rewritten. It is recommended to turn this option on, but the default is "off" to keep compatible with earlier versions of rsyslog. - **SysSock.RateLimit.Interval** [number] - specifies the rate-limiting interval in seconds. Default value is 0, which turns off rate limiting. Set it to a number of seconds (5 recommended) to activate rate-limiting. The default of 0 has been chosen as people experienced problems with this feature activated by default. Now it needs an explicit opt-in by setting this parameter. - **SysSock.RateLimit.Burst** [number] - specifies the rate-limiting burst in number of messages. Default is 200. - **SysSock.RateLimit.Severity** [numerical severity] - specifies the severity of messages that shall be rate-limited. - **SysSock.UseSysTimeStamp** [**on**/off] the same as the input parameter ``UseSysTimeStamp``, but for the system log socket. See description there. - **SysSock.Annotate** turn on annotation/trusted properties for the system log socket. - **SysSock.ParseTrusted** if Annotation is turned on, create JSON/lumberjack properties out of the trusted properties (which can be accessed via RainerScript JSON Variables, e.g. ``$!pid``) instead of adding them to the message. - **SysSock.Unlink** <**on**/off> (available since 7.3.9) if turned on (default), the system socket is unlinked and re-created when opened and also unlinked when finally closed. Note that this setting has no effect when running under systemd control (because systemd handles the socket). - **sysSock.useSpecialParser** (available since 8.9.0) The equivalent of the ``useSpecialParser`` input parameter for the system socket. - **sysSock.parseHostname** (available since 8.9.0) The equivalent of the ``parseHostname`` input parameter for the system socket. Input Parameters ---------------- - **ruleset** [name] Binds specified ruleset to this input. If not set, the default ruleset is bound. (available since 8.17.0) - **IgnoreTimestamp** [**on**/off] Ignore timestamps included in messages received from the input being defined. - **IgnoreOwnMessages** [**on**/off] (available since 7.3.7) Ignore messages that originated from the same instance of rsyslogd. There usually is no reason to receive messages from ourselves. This setting is vital when writing messages to the Linux journal. See :doc:`omjournal ` module documentation for a more in-depth description. - **FlowControl** [on/**off**] - specifies if flow control should be applied to the input being defined. - **RateLimit.Interval** [number] - specifies the rate-limiting interval in seconds. Default value is 0, which turns off rate limiting. Set it to a number of seconds (5 recommended) to activate rate-limiting. The default of 0 has been chosen as people experienced problems with this feature activated by default. Now it needs an explicit opt-in by setting this parameter. - **RateLimit.Burst** [number] - specifies the rate-limiting burst in number of messages. Default is 200. - **RateLimit.Severity** [numerical severity] - specifies the severity of messages that shall be rate-limited. - **UsePIDFromSystem** [on/**off**] - specifies if the pid being logged shall be obtained from the log socket itself. If so, the TAG part of the message is rewritten. It is recommended to turn this option on, but the default is "off" to keep compatible with earlier versions of rsyslog. - **UseSysTimeStamp** [**on**/off] instructs imuxsock to obtain message time from the system (via control messages) instead of using time recorded inside the message. This may be most useful in combination with systemd. Note: this option was introduced with version 5.9.1. Due to the usefulness of it, we decided to enable it by default. As such, 5.9.1 and above behave slightly different than previous versions. However, we do not see how this could negatively affect existing environments. - **CreatePath** [on/**off**] - create directories in the socket path if they do not already exist. They are created with 0755 permissions with the owner being the process under which rsyslogd runs. The default is not to create directories. Keep in mind, though, that rsyslogd always creates the socket itself if it does not exist (just not the directories by default). This option is primarily considered useful for defining additional sockets that reside on non-permanent file systems. As rsyslogd probably starts up before the daemons that create these sockets, it is a vehicle to enable rsyslogd to listen to those sockets even though their directories do not yet exist. - **Socket** adds additional unix socket, default none -- former -a option - **HostName** permits to override the hostname that shall be used inside messages taken from the input that is being defined. - **Annotate** turn on annotation/trusted properties for the input that is being defined. - **ParseTrusted** equivalent to the ``SysSock.ParseTrusted`` module parameter, but applies to the input that is being defined. - **Unlink** <**on**/off> (available since 7.3.9) if turned on (default), the socket is unlinked and re-created when opened and also unlinked when finally closed. Set it to off if you handle socket creation yourself. Note that handling socket creation oneself has the advantage that a limited amount of messages may be queued by the OS if rsyslog is not running. - **useSpecialParser** <**on**/off> (available since 8.9.0) If turned on (the default and the way it was up until 8.8.0) a special parser is used that parses the format that is usually used on the system log socket (the one :manpage:`syslog(3)` creates). If set to "off", the regular parser chain is used, in which case the format on the log socket can be arbitrary. Note that when the special parser is used, rsyslog is able to inject a more precise timestamp into the message (it is obtained from the log socket). If the regular parser chain is used, this is not possible. - **parseHostname** (available since 8.9.0) Normally, the local log sockets do *not* contain hostnames. With this directive, the parser chain can be instructed to not expect them (setting "off", the default). If set to on, parsers will expect hostnames just like in regular formats. Note: this option only has an effect if ``useSpecialParsers`` is set to "off". .. _rate-limiting-label: Input rate limiting =================== .. versionadded:: 5.7.1 rsyslog supports (optional) input rate limiting to guard against the problems of a wild running logging process. If more than ``SysSock.RateLimit.Interval`` \* ``SysSock.RateLimit.Burst`` log messages are emitted from the same process, those messages with ``SysSock.RateLimit.Severity`` or lower will be dropped. It is not possible to recover anything about these messages, but imuxsock will tell you how many it has dropped once the interval has expired AND the next message is logged. Rate-limiting depends on ``SCM\_CREDENTIALS``. If the platform does not support this socket option, rate limiting is turned off. If multiple sockets are configured, rate limiting works independently on each of them (that should be what you usually expect). The same functionality is available for additional log sockets, in which case the config statements just use the prefix RateLimit... but otherwise works exactly the same. When working with severities, please keep in mind that higher severity numbers mean lower severity and configure things accordingly. To turn off rate limiting, set the interval to zero. .. _trusted-properties-label: Trusted (syslog) properties =========================== .. versionadded:: 5.9.4 rsyslog can annotate messages from system log sockets (via imuxsock) with so-called `Trusted syslog properties `_, (or just "Trusted Properties" for short). These are message properties not provided by the logging client application itself, but rather obtained from the system. As such, they can not be faked by the user application and are trusted in this sense. This feature is based on a similar idea introduced in systemd. This feature requires a recent enough Linux Kernel and access to the ``/proc`` file system. In other words, this may not work on all platforms and may not work fully when privileges are dropped (depending on how they are dropped). Note that trusted properties can be very useful, but also typically cause the message to grow rather large. Also, the format of log messages is changed by adding the trusted properties at the end. For these reasons, the feature is **not enabled by default**. If you want to use it, you must turn it on (via ``SysSock.Annotate`` and ``Annotate``). .. _flow-control-label: Flow-control of Unix log sockets ================================ If processing queues fill up, the unix socket reader is blocked for a short while to help prevent overrunning the queues. If the queues are overrun, this may cause excessive disk-io and impact performance. While turning on flow control for many systems does not hurt, it `can` lead to a very unresponsive system and as such is disabled by default. This means that log records are placed as quickly as possible into the processing queues. If you would like to have flow control, you need to enable it via the ``SysSock.FlowControl`` and ``FlowControl`` config directives. Just make sure you have thought about the implications and have tested the change on a non-production system first. .. _application-timestamps-label: Control over application timestamps =================================== Application timestamps are ignored by default. This is needed, as some programs (e.g. sshd) log with inconsistent timezone information, what messes up the local logs (which by default don't even contain time zone information). This seems to be consistent with what sysklogd has done for many years. Alternate behaviour may be desirable if gateway-like processes send messages via the local log slot. In that case, it can be enabled via the ``SysSock.IgnoreTimestamp`` and ``IgnoreTimestamp`` config directives. .. _systemd-details-label: Coexistence with systemd ======================== Rsyslog should by default be configured for systemd support on all platforms that usually run systemd (which means most Linux distributions, but not, for example, Solaris). Rsyslog is able to coexist with systemd with minimal changes on the part of the local system administrator. While the ``systemd journal`` now assumes full control of the the local ``/dev/log`` system log socket, systemd provides access to logging data via the ``/run/systemd/journal/syslog`` log socket. This log socket is provided by the ``syslog.socket`` file that is shipped with systemd. .. versionadded:: 8.32.0 rsyslog emits an informational message noting the system log socket provided by systemd. The imuxsock module can still be used in this setup and provides superior performance over :doc:`imjournal `, the alternative journal input module. .. note:: It must be noted, however, that the journal tends to drop messages when it becomes busy instead of forwarding them to the system log socket. This is because the journal uses an async log socket interface for forwarding instead of the traditional synchronous one. Handling of sockets ------------------- What follows is a brief description of the process rsyslog takes to determine what system socket to use, which sockets rsyslog should listen on, whether the sockets should be created and how rsyslog should handle the sockets when shutting down. Step 1: Select name of system socket ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. If the user has not explicitly chosen to set ``SysSock.Use="off"`` then the default listener socket (aka, "system log socket" or simply "system socket") name is set to ``/dev/log``. Otherwise, if the user `has` explicitly set ``SysSock.Use="off"``, then rsyslog will not listen on ``/dev/log`` OR any socket defined by the ``SysSock.Name`` parameter and the rest of this section does not apply. #. If the user has specified ``sysSock.Name="/path/to/custom/socket"`` (and not explicitly set ``SysSock.Use="off"``), then the default listener socket name is overwritten with ``/path/to/custom/socket``. #. Otherwise, if rsyslog is running under systemd AND ``/run/systemd/journal/syslog`` exists, (AND the user has not explicitly set ``SysSock.Use="off"``) then the default listener socket name is overwritten with ``/run/systemd/journal/syslog``. Step 2: Listen on specified sockets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: This is true for all sockets, be it system socket or not. But if ``SysSock.Use="off"``, the system socket will not be listened on. rsyslog evaluates the list of sockets it has been asked to activate: - the system log socket (if still enabled after completion of the last section) - any custom inputs defined by the user and then checks to see if it has been passed in via systemd (name is checked). If it was passed in via systemd, the socket is used as-is (e.g., not recreated upon rsyslog startup), otherwise if not passed in via systemd the log socket is unlinked, created and opened. Step 3: Shutdown log sockets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: This is true for all sockets, be it system socket or not. Upon shutdown, rsyslog processes each socket it is listening on and evaluates it. If the socket was originally passed in via systemd (name is checked), then rsyslog does nothing with the socket (systemd maintains the socket). If the socket was `not` passed in via systemd AND the configuration permits rsyslog to do so (the default setting), rsyslog will unlink/remove the log socket. If not permitted to do so (the user specified otherwise), then rsyslog will not unlink the log socket and will leave that cleanup step to the user or application that created the socket to remove it. Statistic Counter ================= This plugin maintains a global :doc:`statistics <../rsyslog_statistic_counter>` with the following properties: - **submitted** - total number of messages submitted for processing since startup - **ratelimit.discarded** - number of messages discarded due to rate limiting - **ratelimit.numratelimiters** - number of currently active rate limiters (smal data structures used for the rate limiting logic) See Also ======== - `What are "trusted properties"? `_ - `Why does imuxsock not work on Solaris? `_ - `Writing syslog Daemons Which Cooperate Nicely With systemd `_ Caveats/Known Bugs ================== - There is a compile-time limit of 50 concurrent sockets. If you need more, you need to change the array size in ``imuxsock.c``. - When running under systemd, **many "sysSock." parameters are ignored**. See parameter descriptions and the :ref:`systemd-details-label` section for details. - On systems where systemd is used this module is often not loaded by default. See the :ref:`systemd-details-label` section for details. - Application timestamps are ignored by default. See the :ref:`application-timestamps-label` section for details. .. todolist:: Examples ======== Minimum setup ------------- The following sample is the minimum setup required to accept syslog messages from applications running on the local system. .. code-block:: none module(load="imuxsock") This only needs to be done once. Enable flow control ------------------- .. code-block:: none :emphasize-lines: 2 module(load="imuxsock" # needs to be done just once SysSock.FlowControl="on") # enable flow control (use if needed) Enable trusted properties ------------------------- As noted in the :ref:`trusted-properties-label` section, trusted properties are disabled by default. If you want to use them, you must turn the feature on via ``SysSock.Annotate`` for the system log socket and ``Annotate`` for inputs. Append to end of message ~~~~~~~~~~~~~~~~~~~~~~~~ The following sample is used to activate message annotation and thus trusted properties on the system log socket. These trusted properties are appended to the end of each message. .. code-block:: none :emphasize-lines: 2 module(load="imuxsock" # needs to be done just once SysSock.Annotate="on") Store in JSON message properties ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following sample is similiar to the first one, but enables parsing of trusted properties, which places the results into JSON/lumberjack variables. .. code-block:: none :emphasize-lines: 2 module(load="imuxsock" SysSock.Annotate="on" SysSock.ParseTrusted="on") Read log data from jails ------------------------ The following sample is a configuration where rsyslogd pulls logs from two jails, and assigns different hostnames to each of the jails: .. code-block:: none :emphasize-lines: 3,4,5 module(load="imuxsock") # needs to be done just once input(type="imuxsock" HostName="jail1.example.net" Socket="/jail/1/dev/log") input(type="imuxsock" HostName="jail2.example.net" Socket="/jail/2/dev/log") Read from socket on temporary file system ----------------------------------------- The following sample is a configuration where rsyslogd reads the openssh log messages via a separate socket, but this socket is created on a temporary file system. As rsyslogd starts up before the sshd daemon, it needs to create the socket directories, because it otherwise can not open the socket and thus not listen to openssh messages. .. code-block:: none :emphasize-lines: 3,4 module(load="imuxsock") # needs to be done just once input(type="imuxsock" Socket="/var/run/sshd/dev/log" CreatePath="on") Disable rate limiting --------------------- The following sample is used to turn off input rate limiting on the system log socket. .. code-block:: none :emphasize-lines: 2 module(load="imuxsock" # needs to be done just once SysSock.RateLimit.Interval="0") # turn off rate limiting source/configuration/modules/omprog.rst0000664000175000017500000001122513223143453017415 0ustar rgerrgeromprog: Program integration Output module ========================================= **Module Name:    omprog** **Available since**: 4.3.0 **Author:**\ Rainer Gerhards **Description**: This module permits to integrate arbitrary external programs into rsyslog's logging. It is similar to the "execute program (^)" action, but offers better security and much higher performance. While "execute program (^)" can be a useful tool for executing programs if rare events occur, omprog can be used to provide massive amounts of log data to a program. Executes the configured program and feeds log messages to that binary via stdin. The binary is free to do whatever it wants with the supplied data. If the program terminates, it is re-started. If rsyslog terminates, the program's stdin will see EOF. The program must then terminate. The message format passed to the program can, as usual, be modified by defining rsyslog templates. Note that each time an omprog action is defined, the corresponding program is invoked. A single instance is **not** being re-used. There are arguments pro and con for re-using existing binaries. For the time being, it simply is not done. In the future, we may add an option for such pooling, provided that some demand for that is voiced. You can also mimic the same effect by defining multiple rulesets and including them. Note that in order to execute the given program, rsyslog needs to have sufficient permissions on the binary file. This is especially true if not running as root. Also, keep in mind that default SELinux policies most probably do not permit rsyslogd to execute arbitrary binaries. As such, permissions must be appropriately added. Note that SELinux restrictions also apply if rsyslogd runs under root. To check if a problem is SELinux-related, you can temporarily disable SELinux and retry. If it then works, you know for sure you have a SELinux issue. Starting with 8.4.0, rsyslogd emits an error message via the ``syslog()`` API call when there is a problem executing the binary. This can be extremely valuable in troubleshooting. For those technically savy: when we execute a binary, we need to fork, and we do not have full access to rsyslog's usual error-reporting capabilities after the fork. As the actual execution must happen after the fork, we cannot use the default error logger to emit the error message. As such, we use ``syslog()``. In most cases, there is no real difference between both methods. However, if you run multiple rsyslog instances, the messae shows up in that instance that processes the default log socket, which may be different from the one where the error occured. Also, if you redirected the log destination, that redirection may not work as expected.   **Module Parameters**: Note: parameter names are case-insensitive. - **Template**\ [templateName] sets a new default template for file actions.   **Action Parameters**: Note: parameter names are case-insensitive. - **binary** Mostly equivalent to the "binary" action parameter, but must contain the binary name only. In legacy config, it is **not possible** to specify command line parameters. - **hup.signal** [v8.9.0+] Specifies which signal, if any, is to be forwarded to the executed program. Currently, HUP, USR1, USR2, INT, and TERM are supported. If unset, no signal is sent on HUP. This is the default and what pre 8.9.0 versions did. - **signalOnClose** [switch] [v8.23.0+] *Default: off* Signal the child process when worker-instance is stopped or Rsyslog is about to shutdown. To signal shutdown, SIGTERM is issued to child and Rsyslog reaps the process before proceeding. No signal is issued if this switch is set to 'off' (default). The child-process can still detect shutdown because 'read' from stdin would EOF. However its possible to have process-leak due to careless error-handling around read. Rsyslog won't try to reap the child process in this case. Additionaly, this controls the following **GNU/Linux specific behavior**: If 'on', Rsyslog waits for upto 5 seconds for child process to terminate after issuing SIGTERM, after which a SIGKILL is issued ensuring child-death. This ensures even an unresponsive child is reaped before shutdown. **Caveats/Known Bugs:** - None. **Sample:** The following command writes all syslog messages into a file. :: module(load="omprog") action(type="omprog" binary="/pathto/omprog.py --parm1=\"value 1\" --parm2=\"value2\"" template="RSYSLOG_TraditionalFileFormat") **Legacy Configuration Directives**: - **$ActionOMProgBinary** The binary program to be executed. **Caveats/Known Bugs:** Currently none known. source/configuration/modules/mmsnmptrapd.rst0000664000175000017500000001053513223143453020457 0ustar rgerrgermmsnmptrapd message modification module ======================================= **Module Name:** mmsnmptrapd **Author:** Rainer Gerhards (custom-created) **Multi-Ruleset Support:** since 5.8.1 **Description**: This module uses a specific configuration of snmptrapd's tag values to obtain information of the original source system and the severity present inside the original SNMP trap. It then replaces these fields inside the syslog message. Let's look at an example. Essentially, SNMPTT will invoke something like this: :: logger -t snmptrapd/warning/realhost Host 003c.abcd.ffff in vlan 17 is flapping between port Gi4/1 and port Gi3/2 This message modification module will change the tag (removing the additional information), hostname and severity (not shown in example), so the log entry will look as follows: :: 2011-04-21T16:43:09.101633+02:00 realhost snmptrapd: Host 003c.abcd.ffff in vlan 122 is flapping between port Gi4/1 and port Gi3/2 The following logic is applied to all message being processed: #. The module checks incoming syslog entries. If their TAG field starts with "snmptrapd/" (configurable), they are modified, otherwise not. If the are modified, this happens as follows: #. It will derive the hostname from the tag field which has format snmptrapd/severity/hostname #. It should derive the severity from the tag field which has format snmptrapd/severity/hostname. A configurable mapping table will be used to drive a new severity value from that severity string. If no mapping has been defined, the original severity is not changed. #. It replaces the "FromHost" value with the derived value from step 2 #. It replaces the "Severity" value with the derived value from step 3 Note that the placement of this module inside the configuration is important. All actions before this modules is called will work on the unmodified message. All messages after it's call will work on the modified message. Please also note that there is some extra power in case it is required: as this module is implemented via the output module interface, a filter can be used (actually must be used) in order to tell when it is called. Usually, the catch-all filter (\*.\*) is used, but more specific filters are fully supported. So it is possible to define different parameters for this module depending on different filters. It is also possible to just run messages from one remote system through this module, with the help of filters or multiple rulesets and ruleset bindings. In short words, all capabilities rsyslog offers to control output modules are also available to mmsnmptrapd. **Configuration Parameters**: Note: parameter names are case-insensitive. - **$mmsnmptrapdTag** [tagname] tells the module which start string inside the tag to look for. The default is "snmptrapd". Note that a slash is automatically added to this tag when it comes to matching incoming messages. It MUST not be given, except if two slashes are required for whatever reasons (so "tag/" results in a check for "tag//" at the start of the tag field). - **$mmsnmptrapdSeverityMapping** [severitymap] This specifies the severity mapping table. It needs to be specified as a list. Note that due to the current config system **no whitespace** is supported inside the list, so be sure not to use any whitespace inside it. The list is constructed of Severtiy-Name/Severity-Value pairs, delimited by comma. Severity-Name is a case-sensitive string, e.g. "warning" and an associated numerical value (e.g. 4). Possible values are in the rage 0..7 and are defined in RFC5424, table 2. The given sample would be specified as "warning/4". If multiple instances of mmsnmptrapd are used, each instance uses the most recently defined $mmsnmptrapdSeverityMapping before itself. **Caveats/Known Bugs:** - currently none known **Example:** This enables to rewrite messages from snmptrapd and configures error and warning severities. The default tag is used. :: $ModLoad mmsnmptrapd # needs to be done just once # ... other module loads and listener setup ... *.* /path/to/file/with/orignalMessage # this file receives unmodified messages $mmsnmptrapdSeverityMapping warning/4,error/3 *.* :mmsnmptrapd: # now message is modified *.* /path/to/file/with/modifiedMessage # this file receives modified messages # ... rest of config ... source/configuration/modules/omfwd.rst0000664000175000017500000003753413223143453017241 0ustar rgerrgeromfwd: syslog Forwarding Output Module ====================================== **Module Name:**  **omfwd** **Author:** Rainer Gerhards The omfwd plug-in provides the core functionality of traditional message forwarding via UDP and plain TCP. It is a built-in module that does not need to be loaded.   **Note: this documentation describes features present in v7+ of rsyslog. If you use an older version, scroll down to "legacy parameters".** If you prefer, you can also `obtain a specific version of the rsyslog documentation `_.   Module Parameters ----------------- Note: parameter names are case-insensitive. - **Template** [templateName] sets a non-standard default template for this module.   Action Parameters ----------------- Note: parameter names are case-insensitive. - **Target** string Name or IP-Address of the system that shall receive messages. Any resolvable name is fine. - **Port** Name or numerical value of port to use when connecting to target. - **Protocol** udp/tcp [default udp] Type of protocol to use for forwarding. Note that \`\`tcp'' means both legacy plain tcp syslog as well as RFC5425-based TCL-encrypted syslog. Which one is selected depends on the protocol drivers set before the action commend. Note that as of 6.3.6, there is no way to specify this within the action itself. - **NetworkNamespace** [default none] Name of a network namespace as in /var/run/netns/ to use for forwarding. If the setns() system call is not available on the system (e.g. BSD kernel, linux kernel before v2.6.24) the given namespace will be ignored. - **Device** [default none] Bind socket to given device (e.g., eth0) For Linux with VRF support, the Device option can be used to specify the VRF for the Target address. - **TCP\_Framing** "traditional" or "octet-counted" [default traditional] Framing-Mode to be for forwarding. This affects only TCP-based protocols. It is ignored for UDP. In protocol engineering, "framing" means how multiple messages over the same connection are separated. Usually, this is transparent to users. Unfortunately, the early syslog protocol evolved, and so there are cases where users need to specify the framing. The traditional framing is nontransparent. With it, messages are end when a LF (aka "line break", "return") is encountered, and the next message starts immediately after the LF. If multi-line messages are received, these are essentially broken up into multiple message, usually with all but the first message segment being incorrectly formatted. The octet-counting framing solves this issue. With it, each message is prefixed with the actual message length, so that a receivers knows exactly where the message ends. Multi-line messages cause no problem here. This mode is very close to the method described in RFC5425 for TLS-enabled syslog. Unfortunately, only few syslogd implementations support octet-counted framing. As such, the traditional framing is set as default, even though it has defects. If it is known that the receiver supports octet-counted framing, it is suggested to use that framing mode. - **TCP\_FrameDelimiter** [default 10] Sets a custom frame delimiter for TCP transmission when running TCP\_Framing in "traditional" mode. The delimiter has to be a number between 0 and 255 (representing the ASCII-code of said character). The default value for this parameter is 10, representing a '\\n'. When using Graylog, the parameter must be set to 0. - **ZipLevel** 0..9 [default 0] Compression level for messages. Up until rsyslog 7.5.1, this was the only compression setting that rsyslog understood. Starting with 7.5.1, we have different compression modes. All of them are affected by the ziplevel. If, however, no mode is explicitely set, setting ziplevel also turns on "single" compression mode, so pre 7.5.1 configuration will continue to work as expected. The compression level is specified via the usual factor of 0 to 9, with 9 being the strongest compression (taking up most processing time) and 0 being no compression at all (taking up no extra processing time). - **maxErrorMessages** depricated in 8.29.0, do not use This was used to do some very rough "rate limiting" in versions prioer to 8.29.0 and actually stemed back to when there were no real rate-limiting capabilities in rsyslog core. Starting with 8.29.0 this setting is ignored and the rsyslog internal message rate limiter is used instead. - **compression.mode** *mode* *mode* is one of "none", "single", or "stream:always". The default is "none", in which no compression happens at all. In "single" compression mode, Rsyslog implements a proprietary capability to zip transmitted messages. That compression happens on a message-per-message basis. As such, there is a performance gain only for larger messages. Before compressing a message, rsyslog checks if there is some gain by compression. If so, the message is sent compressed. If not, it is sent uncompressed. As such, it is totally valid that compressed and uncompressed messages are intermixed within a conversation. In "stream:always" compression mode the full stream is being compressed. This also uses non-standard protocol and is compatible only with receives that have the same abilities. This mode offers potentially very high compression ratios. With typical syslog messages, it can be as high as 95+% compression (so only one twentieth of data is actually transmitted!). Note that this mode introduces extra latency, as data is only sent when the compressor emits new compressed data. For typical syslog messages, this can mean that some hundered messages may be held in local buffers before they are actually sent. This mode has been introduced in 7.5.1. **Note: currently only imptcp supports receiving stream-compressed data.** - **compression.stream.flushOnTXEnd** *[**on**/off*] (requires 7.5.3+) This setting affects stream compression mode, only. If enabled (the default), the compression buffer will by emptied at the end of a rsyslog batch. If set to "off", end of batch will not affect compression at all. While setting it to "off" can potentially greatly improve compression ratio, it will also introduce severe delay between when a message is being processed by rsyslog and actually sent out to the network. We have seen cases where for several thousand message not a single byte was sent. This is good in the sense that it can happen only if we have a great compression ratio. This is most probably a very good mode for busy machines which will process several thousand messages per second and te resulting short delay will not pose any problems. However, the default is more conservative, while it works more "naturally" with even low message traffic. Even in flush mode, notable compression should be achivable (but we do not yet have practice reports on actual compression ratios). - **RebindInterval** integer Permits to specify an interval at which the current connection is broken and re-established. This setting is primarily an aid to load balancers. After the configured number of messages has been transmitted, the current connection is terminated and a new one started. Note that this setting applies to both TCP and UDP traffic. For UDP, the new \`\`connection'' uses a different source port (ports are cycled and not reused too frequently). This usually is perceived as a \`\`new connection'' by load balancers, which in turn forward messages to another physical target system. - **KeepAlive** *[**on**/off*] Enable or disable keep-alive packets at the tcp socket layer. The default is to disable them. - **KeepAlive.Probes** integer The number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. - **KeepAlive.Interval** integer The interval between subsequential keepalive probes, regardless of what the connection has exchanged in the meantime. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. - **KeepAlive.Time** integer The interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. - **StreamDriver** string Set the file owner for directories newly created. Please note that this setting does not affect the owner of directories already existing. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. - **StreamDriverMode** integer [default 0] mode to use with the stream driver (driver-specific) - **StreamDriverAuthMode** string authentication mode to use with the stream driver. Note that this parameter requires TLS netstream drivers. For all others, it will be ignored. (driver-specific). - **StreamDriverPermittedPeers** string accepted fingerprint (SHA1) or name of remote peer. Note that this parameter requires TLS netstream drivers. For all others, it will be ignored. (driver-specific) - **ResendLastMSGOnReconnect** on/off Permits to resend the last message when a connection is reconnected. This setting affects TCP-based syslog, only. It is most useful for traditional, plain TCP syslog. Using this protocol, it is not always possible to know which messages were successfully transmitted to the receiver when a connection breaks. In many cases, the last message sent is lost. By switching this setting to "yes", rsyslog will always retransmit the last message when a connection is reestablished. This reduces potential message loss, but comes at the price that some messages may be duplicated (what usually is more acceptable). Please note that busy systems probably loose more than a single message in such cases. This is caused by an `inherant unreliability in plain tcp syslog `_ and there is no way rsyslog could prevent this from happening (if you read the detail description, be sure to follow the link to the follow-up posting). In order to prevent these problems, we recommend the use of :doc:`omrelp `. - **udp.sendToAll** Boolean [on/off] **Default:** off When sending UDP messages, there are potentially multiple paths to the target destination. By default, rsyslogd only sends to the first target it can successfully send to. If this option is set to "on", messages are sent to all targets. This may improve reliability, but may also cause message duplication. This option should be enabled only if it is fully understood. Note: this option replaces the former -A command line option. In contrast to the -A option, this option must be set once per input() definition. - **udp.sendDelay Integer** **Default:** 0 **Available since:** 8.7.0 This is an **expert option**, do only use it if you know very well why you are using it! This options permits to introduce a small delay after *each* send operation. The integer specifies the delay in microseconds. This option can be used in cases where too-quick sending of UDP messages causes message loss (UDP is permitted to drop packets if e.g. a device runs out of buffers). Usually, you do not want this delay. The parameter was introduced in order to support some testbench tests. Be sure to think twice before you use it in producetion. - **gnutlsPriorityString** string **Default:** NULL **Available since:** 8.29.0 The GnuTLS priority strings specify the TLS session's handshake algorithms and options. These strings are intended as a user-specified override of the library defaults. If this parameter is NULL, the default settings are used. More information about priority Strings `here `_. See Also -------- - `Encrypted Disk Queues `_ Caveats/Known Bugs ------------------ Currently none. Sample ------ The following command sends all syslog messages to a remote server via TCP port 10514. :: action(type="omfwd" Target="192.168.2.11" Port="10514" Protocol="tcp" Device="eth0") In case the system in use has multiple (maybe virtual) network interfaces network namespaces come in handy, each with its own routing table. To be able to distribute syslogs to remote servers in different namespaces specify them as separate actions. :: action(type="omfwd" Target="192.168.1.13" Port="10514" Protocol="tcp" NetworkNamespace="ns_eth0.0") action(type="omfwd" Target="192.168.2.24" Port="10514" Protocol="tcp" NetworkNamespace="ns_eth0.1") action(type="omfwd" Target="192.168.3.38" Port="10514" Protocol="tcp" NetworkNamespace="ns_eth0.2") Legacy Configuration Parameters ------------------------------- Note: parameter names are case-insensitive. - **$ActionForwardDefaultTemplateName**\ string [templatename] sets a new default template for UDP and plain TCP forwarding action - **$ActionSendTCPRebindInterval**\ integer instructs the TCP send action to close and re-open the connection to the remote host every nbr of messages sent. Zero, the default, means that no such processing is done. This parameter is useful for use with load-balancers. Note that there is some performance overhead associated with it, so it is advisable to not too often "rebind" the connection (what "too often" actually means depends on your configuration, a rule of thumb is that it should be not be much more often than once per second). - **$ActionSendUDPRebindInterval**\ integer instructs the UDP send action to rebind the send socket every nbr of messages sent. Zero, the default, means that no rebind is done. This parameter is useful for use with load-balancers. - **$ActionSendStreamDriver**\ just like $DefaultNetstreamDriver, but for the specific action - **$ActionSendStreamDriverMode**\ [default 0] mode to use with the stream driver (driver-specific) - **$ActionSendStreamDriverAuthMode**\ authentication mode to use with the stream driver. Note that this parameter requires TLS netstream drivers. For all others, it will be ignored. (driver-specific)) - **$ActionSendStreamDriverPermittedPeers**\ accepted fingerprint (SHA1) or name of remote peer. Note that this parameter requires TLS netstream drivers. For all others, it will be ignored. (driver-specific) - **$ActionSendResendLastMsgOnReconnect**\ on/off [default off] specifies if the last message is to be resend when a connecition breaks and has been reconnected. May increase reliability, but comes at the risk of message duplication. - **$ResetConfigVariables** Resets all configuration variables to their default value. Any settings made will not be applied to configuration lines following the $ResetConfigVariables. This is a good method to make sure no side-effects exists from previous directives. This parameter has no parameters. Legacy Sample ------------- The following command sends all syslog messages to a remote server via TCP port 10514. :: $ModLoad omfwd *.* @@192.168.2.11:10514 source/configuration/modules/im3195.rst0000664000175000017500000000251313223143453017041 0ustar rgerrgerim3195: RFC3195 Input Module ============================ Receives syslog messages via RFC 3195. The RAW profile is fully implemented and the COOKED profile is provided in an experimental state. This module uses `liblogging `_ for the actual protocol handling. **Author:**\ Rainer Gerhards Parameters ------------------------ Note: parameter names are case-insensitive. .. function:: $Input3195ListenPort The port on which imklog listens for RFC 3195 messages. The default port is 601 (the IANA-assigned port) Caveats/Known Bugs ------------------ Due to no demand at all for RFC3195, we have converted rfc3195d to this input module, but we have NOT conducted any testing. Also, the module does not yet properly handle the recovery case. If someone intends to put this module into production, good testing should be conducted. It also is a good idea to notify the rsyslog project that you intend to use it in production. In this case, we'll probably give the module another cleanup. We don't do this now because so far it looks just like a big waste of time. Currently only a single listener can be defined. That one binds to all interfaces. Example ------- The following sample accepts syslog messages via RFC 3195 on port 1601. :: $ModLoad im3195 $Input3195ListenPort 1601 source/configuration/modules/ommysql.rst0000664000175000017500000000621013223143453017611 0ustar rgerrgerommysql: MySQL Database Output Module ===================================== **Module Name:** ommysql **Author:** Michael Meckelein (Initial Author) / Rainer Gerhards **Description**: This module provides native support for logging to MySQL databases. It offers superior performance over the more generic `omlibdbi `_ module. **Configuration parameters**: Note: configuration parameter names are case-insensitive. ommysql mostly uses the "old style" configuration, with almost everything on the action line itself. A few newer features are being migrated to the new style-config parameter configuration system. - **$ActionOmmysqlServerPort ** Permits to select a non-standard port for the MySQL server. The default is 0, which means the system default port is used. There is no need to specify this parameter unless you know the server is running on a non-standard listen port. - **$OmMySQLConfigFile ** Permits the selection of an optional MySQL Client Library configuration file (my.cnf) for extended configuration functionality. The use of this configuration parameter is necessary only if you have a non-standard environment or if fine-grained control over the database connection is desired. - **$OmMySQLConfigSection ** Permits the selection of the section within the configuration file specified by the **$OmMySQLConfigFile** parameter. This will likely only be used where the database administrator provides a single configuration file with multiple profiles. This configuration parameter is ignored unless **$OmMySQLConfigFile** is also used in the rsyslog configration file. If omitted, the MySQL Client Library default of "client" will be used. - Action parameters: **:ommysql:database-server,database-name,database-userid,database-password** All parameters should be filled in for a successful connect. Note rsyslog contains a canned default template to write to the MySQL database. It works on the MonitorWare schema. This template is: :: $template tpl,"insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')",SQL As you can see, the template is an actual SQL statement. Note the ",SQL" option: it tells the template processor that the template is used for SQL processing, thus quote characters are quoted to prevent security issues. You can not assign a template without ",SQL" to a MySQL output action. If you would like to change fields contents or add or delete your own fields, you can simply do so by modifying the schema (if required) and creating your own custom template. **Sample:** The following sample writes all syslog messages to the database "syslog\_db" on mysqlserver.example.com. The server is being accessed under the account of "user" with password "pwd". :: $ModLoad ommysql $ActionOmmysqlServerPort 1234 # use non-standard port \*.\*      :ommysql:mysqlserver.example.com,syslog\_db,user,pwd source/configuration/modules/mmexternal.rst0000664000175000017500000000350013223143453020263 0ustar rgerrgerSupport module for external message modification modules ======================================================== **Module Name:    mmexternal** **Available since**: 8.3.0 **Author:**\ Rainer Gerhards **Description**: This module permits to integrate external message modification plugins into rsyslog. For details on the interface specification, see rsyslog's source in the ./plugins/external/INTERFACE.md.   **Action Parameters**: Note: parameter names are case-insensitive. - **binary** The name of the external message modification plugin to be called. This can be a full path name. - **interface.input** This can either be "msg", "rawmsg" or "fulljson". In case of "fulljson", the message object is provided as a json object. Otherwise, the respective property is provided. This setting **must** match the external plugin's expectations. Check the external plugin documentation for what needs to be used. - **output** This is a debug aid. If set, this is a filename where the plugins output is logged. Note that the output is also being processed as usual by rsyslog. Setting this parameter thus gives insight into the internal processing that happens between plugin and rsyslog core. - **forcesingleinstance** This is an expert parameter, just like the equivalent *omprog* parameter. See the message modification plugin's documentation if it is needed. **Caveats/Known Bugs:** - None. **Sample:** The following config file snippet is used to write execute an external message modification module "mmexternal.py". Note that the path to the module is specified here. This is necessary if the module is not in the default search path. :: module (load="mmexternal") # needs to be done only once inside the config action(type="mmexternal" binary="/path/to/mmexternal.py") source/configuration/modules/workflow.rst0000664000175000017500000000233613223143030017756 0ustar rgerrgerWhere are the modules integrated into the Message Flow? ======================================================= Depending on their module type, modules may access and/or modify messages at various stages during rsyslog's processing. Note that only the "core type" (e.g. input, output) but not any type derived from it (message modification module) specifies when a module is called. The simplified workflow is as follows: .. figure:: module_workflow.png :align: center :alt: module_workflow As can be seen, messages are received by input modules, then passed to one or many parser modules, which generate the in-memory representation of the message and may also modify the message itself. The internal representation is passed to output modules, which may output a message and (with the interfaces introduced in v5) may also modify message object content. String generator modules are not included inside this picture, because they are not a required part of the workflow. If used, they operate "in front of" the output modules, because they are called during template generation. Note that the actual flow is much more complex and depends a lot on queue and filter settings. This graphic above is a high-level message flow diagram. source/configuration/modules/mmrfc5424addhmac.rst0000664000175000017500000000573313223143453021046 0ustar rgerrgermmrfc5424addhmac ================ **Module Name:    mmrfc5424addhmac** **Author:**\ Rainer Gerhards **Available since**: 7.5.6 **Description**: This module adds a hmac to RFC5424 structured data if not already present. This is a custom module and uses openssl as requested by the sponsor. This works exclusively for RFC5424 formatted messages; all others are ignored. If both `mmpstrucdata `_ and mmrfc5424addhmac are to be used, the recommended calling sequence is #. mmrfc5424addhmac #. mmpstrucdata with that sequence, the generated hash will become available for mmpstrucdata.   **Module Configuration Parameters**: Note: parameter names are case-insensitive. Currently none.   **Action Confguration Parameters**: Note: parameter names are case-insensitive. - **key** The "key" (string) to be used to generate the hmac. - **hashfunction** An openssl hash function name for the function to be used. This is passed on to openssl, so see the openssl list of supported function names. - **sd\_id** The RFC5424 structured data ID to be used by this module. This is the SD-ID that will be added. Note that nothing is added if this SD-ID is already present. **Verification method** rsyslog does not contain any tools to verify a log file (this was not part of the custom project). So you need to write your own verifier. When writing the verifier, keep in mind that the log file contains messages with the hash SD-ID included. For obvious reasons, this SD-ID was not present when the hash was created. So before the actual verification is done, this SD-ID must be removed, and the remaining (original) message be verified. Also, it is important to note that the output template must write the exact same message format that was received. Otherwise, a verification failure will obviously occur - and must so, because the message content actually was altered. So in a more formal description, verification of a message m can be done as follows: #. let m' be m with the configured SD-ID removed (everything between []). Otherwise, m' must be an exact duplicate of m. #. call openssl's HMAC function as follows: ``HMAC(hashfunction, key, len(key), m', len(m'), hash, &hashlen);`` Where hashfunction and key are the configured values and hash is an output buffer for the hash. #. let h be the extracted hash value obtained from m within the relevant SD-ID. Be sure to convert the hex string back to the actual byte values. #. now compare hash and h under consideration of the sizes. If these values match the verification succeeds, otherwise the message was modified. If you neeed help implementing a verifier function or want to sponsor development of a verification tool, please simply email `sales@adiscon.com `_ for a quote. **See Also** - `How to add a HMAC to RFC5424 messages `_ **Caveats/Known Bugs:** - none source/configuration/modules/imklog.rst0000664000175000017500000000766313223143453017407 0ustar rgerrgerimklog: Kernel Log Input Module =============================== Reads messages from the kernel log and submits them to the syslog engine. **Author:**\ Rainer Gerhards Configuration Parameters ------------------------ Note: parameter names are case-insensitive. .. function:: $KLogInternalMsgFacility The facility which messages internally generated by imklog will have. imklog generates some messages of itself (e.g. on problems, startup and shutdown) and these do not stem from the kernel. Historically, under Linux, these too have "kern" facility. Thus, on Linux platforms the default is "kern" while on others it is "syslogd". You usually do not need to specify this configuration directive - it is included primarily for few limited cases where it is needed for good reason. Bottom line: if you don't have a good idea why you should use this setting, do not touch it. .. function:: $KLogPermitNonKernelFacility off At least under BSD the kernel log may contain entries with non-kernel facilities. This setting controls how those are handled. The default is "off", in which case these messages are ignored. Switch it to on to submit non-kernel messages to rsyslog processing. .. function:: $DebugPrintKernelSymbols on/off Linux only, ignored on other platforms (but may be specified). Defaults to off. .. function:: $klogLocalIPIF This directive is no longer supported. Instead, use the global $localHostIPIF directive instead. .. function:: $klogConsoleLogLevel Sets the console log level. If specified, only messages with up to the specified level are printed to the console. The default is -1, which means that the current settings are not modified. To get this behavior, do not specify $klogConsoleLogLevel in the configuration file. Note that this is a global parameter. Each time it is changed, the previous definition is re-set. The one activate will be that one that is active when imklog actually starts processing. In short words: do not specify this directive more than once! **Linux only**, ignored on other platforms (but may be specified) .. function:: $klogUseSyscallInterface on/off Linux only, ignored on other platforms (but may be specified). Defaults to off. .. function:: $klogSymbolsTwice on/off Linux only, ignored on other platforms (but may be specified). Defaults to off. .. function:: $klogParseKernelTimestamp on/off If enabled and the kernel creates a timestamp for its log messages, this timestamp will be parsed and converted into regular message time instead to use the receive time of the kernel message (as in 5.8.x and before). Default is 'off' to prevent parsing the kernel timestamp, because the clock used by the kernel to create the timestamps is not supposed to be as accurate as the monotonic clock required to convert it. Depending on the hardware and kernel, it can result in message time differences between kernel and system messages which occurred at same time. .. function:: $klogKeepKernelTimestamp on/off If enabled, this option causes to keep the [timestamp] provided by the kernel at the begin of in each message rather than to remove it, when it could be parsed and converted into local time for use as regular message time. Only used, when $klogParseKernelTimestamp is on. Caveats/Known Bugs ------------------ This is obviously platform specific and requires platform drivers. Currently, imklog functionality is available on Linux and BSD. This module is **not supported on Solaris** and not needed there. For Solaris kernel input, use :doc:`imsolaris `. Example ------- The following sample pulls messages from the kernel log. All parameters are left by default, which is usually a good idea. Please note that loading the plugin is sufficient to activate it. No directive is needed to start pulling kernel messages. :: $ModLoad imklog source/configuration/modules/imptcp.rst0000664000175000017500000003131213223143453017405 0ustar rgerrgerimptcp: Plain TCP Syslog ======================== Provides the ability to receive syslog messages via plain TCP syslog. This is a specialised input plugin tailored for high performance on Linux. It will probably not run on any other platform. Also, it does not provide TLS services. Encryption can be provided by using `stunnel `_. This module has no limit on the number of listeners and sessions that can be used. **Author:** Rainer Gerhards Error Messages -------------- When a message is to long it will be truncated and an error will show the remaining length of the message and the beginning of it. It will be easier to comprehend the truncation. Configuration Directives ------------------------ This plugin has config directives similar named as imtcp, but they all have **P**\ TCP in their name instead of just TCP. Note that only a subset of the parameters are supported. Module Parameters ^^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. These parameters can be used with the "module()" statement. They apply globaly to all inputs defined by the module. .. function:: Threads Number of helper worker threads to process incoming messages. These threads are utilized to pull data off the network. On a busy system, additional helper threads (but not more than there are CPUs/Cores) can help improving performance. The default value is two, which means there is a default thread count of three (the main input thread plus two helpers). No more than 16 threads can be set (if tried to, rsyslog always resorts to 16). .. function:: processOnPoller on/off *Defaults to on* Instructs imptcp to process messages on poller thread opportunistically. This leads to lower resource footprint(as poller thread doubles up as message-processing thread too). "On" works best when imptcp is handling low ingestion rates. At high throughput though, it causes polling delay(as poller spends time processing messages, which keeps connections in read-ready state longer than they need to be, filling socket-buffer, hence eventually applying backpressure). It defaults to allowing messages to be processed on poller (for backward compatibility). Input Parameters ^^^^^^^^^^^^^^^^ Note: parameter names are case-insensitive. These parameters can be used with the "input()" statement. They apply to the input they are specified with. .. function:: port *Mandatory* Select a port to listen on. It is an error to specify both `path` and `port`. .. function:: path A path on the filesystem for a unix domain socket. It is an error to specify both `path` and `port`. .. function:: discardTruncatedMsg *Default: off* When a message is split because it is to long the second part is normally processed as the next message. This can cause Problems. When this parameter is turned on the part of the message after the truncation will be discarded. .. function:: fileOwner [userName] *Default: system default* Set the file owner for the domain socket. The parameter is a user name, for which the userid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are *not* detected. .. function:: fileOwnerNum [uid] *Default: system default* Set the file owner for the domain socket. The parameter is a numerical ID, which which is used regardless of whether the user actually exists. This can be useful if the user mapping is not available to rsyslog during startup. .. function:: fileGroup [groupName] *Default: system default* Set the group for the domain socket. The parameter is a group name, for which the groupid is obtained by rsyslogd during startup processing. Interim changes to the user mapping are not detected. .. function:: fileGroupNum [gid] *Default: system default* Set the group for the domain socket. The parameter is a numerical ID, which is used regardless of whether the group actually exists. This can be useful if the group mapping is not available to rsyslog during startup. .. function:: fileCreateMode [octalNumber] *Default: 0644* Set the access permissions for the domain socket. The value given must always be a 4-digit octal number, with the initial digit being zero. Please note that the actual permission depend on rsyslogd's process umask. If in doubt, use "$umask 0000" right at the beginning of the configuration file to remove any restrictions. .. function:: failOnChOwnFailure [switch] *Default: on* rsyslog will not start if this is on and changing the file owner, group, or access permissions fails. Disable this to ignore these errors. .. function:: unlink on/off *Default: off* If a unix domain socket is being used this controls whether or not the socket is unlinked before listening and after closing. .. function:: name Sets a name for the inputname property. If no name is set "imptcp" is used by default. Setting a name is not strictly necessary, but can be useful to apply filtering based on which input the message was received from. Note that the name also shows up in :doc:`impstats ` logs. .. function:: ruleset Binds specified ruleset to this input. If not set, the default ruleset is bound. .. function:: maxFrameSize *Default: 200000; Max: 200000000* When in octet counted mode, the frame size is given at the beginning of the message. With this parameter the max size this frame can have is specified and when the frame gets to large the mode is switched to octet stuffing. The max value this parameter can have was specified because otherwise the integer could become negative and this would result in a Segmentation Fault. .. function:: address *Default: all interfaces* On multi-homed machines, specifies to which local address the listerner should be bound. .. function:: AddtlFrameDelimiter This directive permits to specify an additional frame delimiter for plain tcp syslog. The industry-standard specifies using the LF character as frame delimiter. Some vendors, notable Juniper in their NetScreen products, use an invalid frame delimiter, in Juniper's case the NUL character. This directive permits to specify the ASCII value of the delimiter in question. Please note that this does not guarantee that all wrong implementations can be cured with this directive. It is not even a sure fix with all versions of NetScreen, as I suggest the NUL character is the effect of a (common) coding error and thus will probably go away at some time in the future. But for the time being, the value 0 can probably be used to make rsyslog handle NetScreen's invalid syslog/tcp framing. For additional information, see this `forum thread `_. **If this doesn't work for you, please do not blame the rsyslog team. Instead file a bug report with Juniper!** Note that a similar, but worse, issue exists with Cisco's IOS implementation. They do not use any framing at all. This is confirmed from Cisco's side, but there seems to be very limited interest in fixing this issue. This directive **can not** fix the Cisco bug. That would require much more code changes, which I was unable to do so far. Full details can be found at the `Cisco tcp syslog anomaly `_ page. .. function:: SupportOctetCountedFraming on/off *Defaults to "on"* The legacy octed-counted framing (similar to RFC5425 framing) is activated. This is the default and should be left unchanged until you know very well what you do. It may be useful to turn it off, if you know this framing is not used and some senders emit multi-line messages into the message stream. .. function:: NotifyOnConnectionClose on/off *Defaults to off* instructs imptcp to emit a message if a remote peer closes the connection. .. function:: NotifyOnConnectionOpen on/off *Defaults to off* instructs imptcp to emit a message if a remote peer opens a connection. Hostname of the remote peer is given in the message. .. function:: KeepAlive on/off *Defaults to off* enable of disable keep-alive packets at the tcp socket layer. The default is to disable them. .. function:: KeepAlive.Probes The number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Interval The interval between subsequential keepalive probes, regardless of what the connection has exchanged in the meantime. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: KeepAlive.Time The interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further. The default, 0, means that the operating system defaults are used. This has only effect if keep-alive is enabled. The functionality may not be available on all platforms. .. function:: RateLimit.Interval [number] *Default is 0, which turns off rate limiting* Specifies the rate-limiting interval in seconds. Set it to a number of seconds (5 recommended) to activate rate-limiting. .. function:: RateLimit.Burst [number] *Default is 10,000* Specifies the rate-limiting burst in number of messages. .. function:: compression.mode [mode] *Default is none* This is the counterpart to the compression modes set in :doc:`omfwd `. Please see it's documentation for details. .. function:: flowControl *Default: on* Flow control is used to throttle the sender if the receiver queue is near-full preserving some space for input that can not be throttled. .. function:: multiLine *Default: off* Experimental parameter which caues rsyslog to recognise a new message only if the line feed is followed by a '<' or if there are no more characters. Statistic Counter ----------------- This plugin maintains :doc:`statistics <../rsyslog_statistic_counter>` for each listener. The statistic is named "imtcp" , followed by the bound address, listener port and IP version in parenthesis. For example, the counter for a listener on port 514, bound to all interfaces and listening on IPv6 is called "imptcp(\*/514/IPv6)". The following properties are maintained for each listener: - **submitted** - total number of messages submitted for processing since startup Caveats/Known Bugs ------------------ - module always binds to all interfaces Example ------- This sets up a TCP server on port 514: :: module(load="imptcp") # needs to be done just once input(type="imptcp" port="514") This creates a listener that listens on the local loopback interface, only. :: module(load="imptcp") # needs to be done just once input(type="imptcp" port="514" address="127.0.0.1") Create a unix domain socket: :: module(load="imptcp") # needs to be done just once input(type="imptcp" path="/tmp/unix.sock" unlink="on") Legacy Configuration Directives ------------------------------- .. function:: $InputPTCPServerAddtlFrameDelimiter Equivalent to: AddTLFrameDelimiter .. function:: $InputPTCPSupportOctetCountedFraming on/off Equivalent to: SupportOctetCountedFraming .. function:: $InputPTCPServerNotifyOnConnectionClose on/off Equivalent to: NotifyOnConnectionClose. .. function:: $InputPTCPServerKeepAlive Equivalent to: KeepAlive .. function:: $InputPTCPServerKeepAlive\_probes Equivalent to: KeepAlive.Probes .. function:: $InputPTCPServerKeepAlive\_intvl Equivalent to: KeepAlive.Interval .. function:: $InputPTCPServerKeepAlive\_time Equivalent to: KeepAlive.Time .. function:: $InputPTCPServerRun Equivalent to: Port .. function:: $InputPTCPServerInputName Equivalent to: Name .. function:: $InputPTCPServerBindRuleset Equivalent to: Ruleset .. function:: $InputPTCPServerHelperThreads Equivalent to: threads .. function:: $InputPTCPServerListenIP Equivalent to: Address Caveats/Known Bugs ------------------ - module always binds to all interfaces Example -------- This sets up a TCP server on port 514: :: $ModLoad imptcp # needs to be done just once $InputPTCPServerRun 514 source/configuration/modules/ommongodb.rst0000664000175000017500000000726213223143453020101 0ustar rgerrgerommongodb: MongoDB Output Module ================================ **Module Name:    ommongodb** **Author:**\ Rainer Gerhards **Description**: This module provides native support for logging to MongoDB. **Action Parameters**: Note: parameter names are case-insensitive. - **uristr** MongoDB connexion string, as defined by the MongoDB String URI Format (See: https://docs.mongodb.com/manual/reference/connection-string/). If uristr is defined, following directives will be ignored: server, serverport, uid, pwd. - **ssl_cert** Absolute path to the X509 certificate you want to use for TLS client authentication. This is optional. - **ssl_ca** Absolute path to the trusted X509 CA certificate that signed the mongoDB server certificate. This is optional. - **server** (deprecated, use "uristr" instead) Name or address of the MongoDB server - **serverport** (deprecated, use "uristr" instead) Permits to select a non-standard port for the MongoDB server. The default is 0, which means the system default port is used. There is no need to specify this parameter unless you know the server is running on a non-standard listen port. - **db** Database to use - **collection** Collection to use - **uid** (deprecated, use "uristr" instead) logon userid used to connect to server. Must have proper permissions. - **pwd** (decrecated, use "uristr" instead) the user's password - **template** Template to use when submitting messages. Note rsyslog contains a canned default template to write to the MongoDB. It will be used automatically if no other template is specified to be used. This template is: :: template(name="BSON" type="string" string="\\"sys\\" : \\"%hostname%\\", \\"time\\" : \\"%timereported:::rfc3339%\\", \\"time\_rcvd\\" : \\"%timegenerated:::rfc3339%\\", \\"msg\\" : \\"%msg%\\", \\"syslog\_fac\\" : \\"%syslogfacility%\\", \\"syslog\_server\\" : \\"%syslogseverity%\\", \\"syslog\_tag\\" : \\"%syslogtag%\\", \\"procid\\" : \\"%programname%\\", \\"pid\\" : \\"%procid%\\", \\"level\\" : \\"%syslogpriority-text%\\"") This creates the BSON document needed for MongoDB if no template is specified. The default schema is aligned to CEE and project lumberjack. As such, the field names are standard lumberjack field names, and **not** `rsyslog property names `_. When specifying templates, be sure to use rsyslog property names as given in the table. If you would like to use lumberjack-based field names inside MongoDB (which probably is useful depending on the use case), you need to select fields names based on the lumberjack schema. If you just want to use a subset of the fields, but with lumberjack names, you can look up the mapping in the default template. For example, the lumberjack field "level" contains the rsyslog property "syslogpriority-text". **Sample:** The following sample writes all syslog messages to the database "syslog" and into the collection "log" on mongoserver.example.com. The server is being accessed under the account of "user" with password "pwd". Please note that this syntax is deprecated by the "uristr" directive, as shown below. :: module(load="ommongodb") action(type="ommongodb" server="mongoserver.example.com" db="syslog" collection="log" uid="user" pwd="pwd") Another sample that uses the new "uristr" directives to connect to a TLS mongoDB server with TLS and client authentication. :: module(load="ommongodb") action(type="ommongodb" uristr="mongodb://vulture:9091,vulture2:9091/?replicaset=Vulture&ssl=true" ssl_cert="/var/db/mongodb/mongod.pem" ssl_ca="/var/db/mongodb/ca.pem" db="logs" collection="syslog") source/configuration/modules/pmnull.rst0000664000175000017500000000335413223143453017425 0ustar rgerrgerpmnull: Syslog Null Parser Module ================================= **Author**: Pascal Withopf When a message is received it is tried to match a set of parsers to get properties populated. This parser module sets all attributes to "" but rawmsg. There usually should be no need to use this module. It may be useful to process certain known-not-syslog messages. Parser Parameters ----------------- Note: parameter names are case-insensitive. .. function:: tag **Default**: Empty ("") This setting sets the tag value to the message. .. function:: syslogfacility **Default**: 1 This setting sets the syslog facility value. The default comes from the rfc3164 standard. .. function:: syslogseverity **Default**: 5 This setting sets the syslog severity value. The default comes from the rfc3164 standard. Example ------- In this example messages are received through imtcp on port 13514. The ruleset uses the parser pmnull which has the parameters tag, syslogfacility and syslogseverity given. :: module(load="imtcp") module(load="pmnull") input(type="imtcp" port="13514" ruleset="ruleset") parser(name="custom.pmnull" type="pmnull" tag="mytag" syslogfacility="3" syslogseverity="1") ruleset(name="ruleset" parser=["custom.pmnull", "rsyslog.pmnull"]) { action(type="omfile" file="rsyslog.out.log") } In this example the ruleset uses the parser pmnull with the default parameters because no specifics were given. :: module(load="imtcp") module(load="pmnull") input(type="imtcp" port="13514" ruleset="ruleset") parser(name="custom.pmnull" type="pmnull") ruleset(name="ruleset" parser="custom.pmnull") { action(type="omfile" file="rsyslog.out.log") } source/configuration/modules/omoracle.rst0000664000175000017500000001421713223143453017717 0ustar rgerrgeromoracle: Oracle Database Output Module ======================================= **Module Name:    omoracle** **Author:**\ Luis Fernando Muñoz Mejías - this module is currently orphaned, the original author does no longer support it. **Available since:**: 4.3.0, **does not work with recent rsyslog versions (v7 and up). Use** :doc:`omlibdbi ` **instead.** An upgrade to the new interfaces is needed. If you would like to contribute, please send us a patch or open a guithub pull request. **Status:**: contributed module, not maitained by rsyslog core authors **Description**: This module provides native support for logging to Oracle databases. It offers superior performance over the more generic `omlibdbi `_ module. It also includes a number of enhancements, most importantly prepared statements and batching, what provides a big performance improvement. Note that this module is maintained by its original author. If you need assistance with it, it is suggested to post questions to the `rsyslog mailing list `_. From the header comments of this module: :: This is an output module feeding directly to an Oracle database. It uses Oracle Call Interface, a propietary module provided by Oracle. Selector lines to be used are of this form: :omoracle:;TemplateName The module gets its configuration via rsyslog $... directives, namely: $OmoracleDBUser: user name to log in on the database. $OmoracleDBPassword: password to log in on the database. $OmoracleDB: connection string (an Oracle easy connect or a db name as specified by tnsnames.ora) $OmoracleBatchSize: Number of elements to send to the DB on each transaction. $OmoracleStatement: Statement to be prepared and executed in batches. Please note that Oracle's prepared statements have their placeholders as ':identifier', and this module uses the colon to guess how many placeholders there will be. All these directives are mandatory. The dbstring can be an Oracle easystring or a DB name, as present in the tnsnames.ora file. The form of the template is just a list of strings you want inserted to the DB, for instance: $template TestStmt,"%hostname%%msg%" Will provide the arguments to a statement like $OmoracleStatement \ insert into foo(hostname,message)values(:host,:message) Also note that identifiers to placeholders are arbitrary. You need to define the properties on the template in the correct order you want them passed to the statement! Some additional documentation contributed by Ronny Egner: :: REQUIREMENTS: -------------- - Oracle Instantclient 10g (NOT 11g) Base + Devel (if you´re on 64-bit linux you should choose the 64-bit libs!) - JDK 1.6 (not neccessary for oracle plugin but "make" didd not finsished successfully without it) - "oracle-instantclient-config" script (seems to shipped with instantclient 10g Release 1 but i was unable to find it for 10g Release 2 so here it is) ====================== /usr/local/bin/oracle-instantclient-config ===================== #!/bin/sh # # Oracle InstantClient SDK config file # Jean-Christophe Duberga - Bordeaux 2 University # # just adapt it to your environment incdirs="-I/usr/include/oracle/10.2.0.4/client64" libdirs="-L/usr/lib/oracle/10.2.0.4/client64/lib" usage="\ Usage: oracle-instantclient-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]" if test $# -eq 0; then echo "${usage}" 1>&2 exit 1 fi while test $# -gt 0; do case "$1" in -*=*) optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` ;; *) optarg= ;; esac case $1 in --prefix=*) prefix=$optarg if test $exec_prefix_set = no ; then exec_prefix=$optarg fi ;; --prefix) echo $prefix ;; --exec-prefix=*) exec_prefix=$optarg exec_prefix_set=yes ;; --exec-prefix) echo ${exec_prefix} ;; --version) echo ${version} ;; --cflags) echo ${incdirs} ;; --libs) echo $libdirs -lclntsh -lnnz10 -locci -lociei -locijdbc10 ;; --static-libs) echo "No static libs" 1>&2 exit 1 ;; *) echo "${usage}" 1>&2 exit 1 ;; esac shift done =============== END ============== COMPILING RSYSLOGD ------------------- ./configure --enable-oracle RUNNING ------- - make sure rsyslogd is able to locate the oracle libs (either via LD_LIBRARY_PATH or /etc/ld.so.conf) - set TNS_ADMIN to point to your tnsnames.ora - create a tnsnames.ora and test you are able to connect to the database - create user in oracle as shown in the following example: create user syslog identified by syslog default tablespace users quota unlimited on users; grant create session to syslog; create role syslog_role; grant syslog_role to syslog; grant create table to syslog_role; grant create sequence to syslog_role; - create tables as needed - configure rsyslog as shown in the following example $ModLoad omoracle $OmoracleDBUser syslog $OmoracleDBPassword syslog $OmoracleDB syslog $OmoracleBatchSize 1 $OmoracleBatchItemSize 4096 $OmoracleStatementTemplate OmoracleStatement $template OmoracleStatement,"insert into foo(hostname,message) values (:host,:message)" $template TestStmt,"%hostname%%msg%" *.* :omoracle:;TestStmt (you guess it: username = password = database = "syslog".... see $rsyslogd_source/plugins/omoracle/omoracle.c for me info) source/configuration/modules/sigprov_gt.rst0000664000175000017500000000611113223143453020273 0ustar rgerrgerGuardTime Log Signature Provider (gt) ===================================== **Signature Provider Name: gt** **Author:** Rainer Gerhards **Supported:** from 7.3.9 to 8.26.0 **Description**: Provides the ability to sign syslog messages via the GuardTime signature services. **Configuration Parameters**: Note: parameter names are case-insensitive. Signature providers are loaded by omfile, when the provider is selected in its "sig.providerName" parameter. Parameters for the provider are given in the omfile action instance line. This provider creates a signature file with the same base name but the extension ".gtsig" for each log file (both for fixed-name files as well as dynafiles). Both files together form a set. So you need to archive both in order to prove integrity. - **sig.hashFunction** The following hash algorithms are currently supported: - SHA1 - RIPEMD-160 - SHA2-224 - SHA2-256 - SHA2-384 - SHA2-512 - **sig.timestampService** This provides the URL of the timestamper service. If not selected, a default server is selected. This may not necessarily be a good one for your region. *Note:* If you need to supply user credentials, you can add them to the timestamper URL. If, for example, you have a user "user" with password "pass", you can do so as follows: http://user:pass@timestamper.example.net - **sig.block.sizeLimit** The maximum number of records inside a single signature block. By default, there is no size limit, so the signature is only written on file closure. Note that a signature request typically takes between one and two seconds. So signing to frequently is probably not a good idea. - **sig.keepRecordHashes** Controls if record hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (65 bytes for each log record for SHA2-512 hashes, for example). - **sig.keepTreeHashes** Controls if tree (intermediate) hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (a bit mire than the amount sig.keepRecordHashes requries). Note that both Tree and Record hashes can be kept inside the signature file. **See Also** - `How to sign log messages through signature provider Guardtime `_ **Caveats/Known Bugs:** - currently none known **Samples:** This writes a log file with it's associated signature file. Default parameters are used. :: action(type="omfile" file="/var/log/somelog" sig.provider="gt") In the next sample, we use the more secure SHA2-512 hash function, sign every 10,000 records and Tree and Record hashes are kept. :: action(type="omfile" file="/var/log/somelog" sig.provider="gt" sig.hashfunction="SHA2-512" sig.block.sizelimit="10000" sig.keepTreeHashes="on" sig.keepRecordHashes="on") source/configuration/modules/imkmsg.rst0000664000175000017500000000255013223143453017402 0ustar rgerrgerimkmsg: /dev/kmsg Log Input Module ================================== **Module Name:    imkmsg** **Authors:**\ Rainer Gerhards Milan Bartos **Description**: Reads messages from the /dev/kmsg structured kernel log and submits them to the syslog engine. The printk log buffer contains log records. These records are exported by /dev/kmsg device as structured data in the following format: "level,sequnum,timestamp;\\n" There could be continuation lines starting with space that contains key/value pairs. Log messages are parsed as necessary into rsyslog msg\_t structure. Continuation lines are parsed as json key/value pairs and added into rsyslog's message json representation. **Configuration Parameters**: Note: parameter names are case-insensitive. This module has no configuration directives. **Caveats/Known Bugs:** This module can't be used together with imklog module. When using one of them, make sure the other one is not enabled. This is Linux specific module and requires /dev/kmsg device with structured kernel logs. **Sample:** The following sample pulls messages from the /dev/kmsg log device. All parameters are left by default, which is usually a good idea. Please note that loading the plugin is sufficient to activate it. No directive is needed to start pulling messages. $ModLoad imkmsg source/configuration/modules/omhdfs.rst0000664000175000017500000000457713223143453017406 0ustar rgerrgeromhdfs: Hadoop Filesystem Output Module ======================================= **Module Name:    omhdfs** **Available since:**: 5.7.1 **Author:**\ Rainer Gerhards **Description**: This module supports writing message into files on Hadoop's HDFS file system. **Parameters**: Note: parameter names are case-insensitive. - **$OMHDFSFileName** [name] The name of the file to which the output data shall be written. - **$OMHDFSHost** [name] Name or IP address of the HDFS host to connect to. - **$OMHDFSPort** [name] Port on which to connect to the HDFS host. - **$OMHDFSDefaultTemplate** [name] Default template to be used when none is specified. This saves the work of specifying the same template ever and ever again. Of course, the default template can be overwritten via the usual method. **Caveats/Known Bugs:** Building omhdfs is a challenge because we could not yet find out how to integrate Java properly into the autotools build process. The issue is that HDFS is written in Java and libhdfs uses JNI to talk to it. That requires that various system-specific environment options and paths be set correctly. At this point, we leave this to the user. If someone knows how to do it better, please drop us a line! - In order to build, you need to set these environment variables BEFORE running ./configure: - JAVA\_INCLUDES - must have all include pathes that are needed to build JNI C programms, including the -I options necessary for gcc. An example is # export JAVA\_INCLUDES="-I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86\_64/include -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86\_64/include/linux" - JAVA\_LIBS - must have all library pathes that are needed to build JNI C programms, including the -l/-L options necessary for gcc. An example is # export export JAVA\_LIBS="-L/usr/java/jdk1.6.0\_21/jre/lib/amd64 -L/usr/java/jdk1.6.0\_21/jre/lib/amd64/server -ljava -ljvm -lverify" - As of HDFS architecture, you must make sure that all relevant environment variables (the usual Java stuff and HADOOP's home directory) are properly set. - As it looks, libhdfs makes Java throw exceptions to stdout. There is no known work-around for this (and it usually should not case any troubles. **Sample:** :: $ModLoad omhdfs $OMHDFSFileName /var/log/logfile \*.\* :omhdfs: source/configuration/modules/omrelp.rst0000664000175000017500000001570613223143453017420 0ustar rgerrgeromrelp: RELP Output Module ========================== **Module Name:    omrelp** **Author:**\ Rainer Gerhards **Description**: This module supports sending syslog messages over the reliable RELP protocol. For RELP's advantages over plain tcp syslog, please see the documentation for :doc:`imrelp ` (the server counterpart).  Setup Please note that `librelp `__ is required for imrelp (it provides the core relp protocol implementation). **Action Configuration Parameters**: This module supports RainerScript configuration starting with rsyslog 7.3.10. For older versions, legacy configuration directives must be used. Note: parameter names are case-insensitive. - **target** (mandatory) The target server to connect to. - **template** (not mandatory, default "RSYSLOG\_ForwardFormat") Defines the template to be used for the output. - **timeout** (not mandatory, default 90) Timeout for relp sessions. If set too low, valid sessions may be considered dead and tried to recover. - **conn.timeout** (not mandatory, default 10) Timeout for the socket connection. - **windowSize** (not mandatory, default 0) This is an **expert parameter**. It permits to override the RELP window size being used by the client. Changing the window size has both an effect on performance as well as potential message duplication in failure case. A larger window size means more performance, but also potentially more duplicated messages - and vice versa. The default 0 means that librelp's default window size is being used, which is considered a compromise between goals reached. For your information: at the time of this writing, the librelp default window size is 128 messages, but this may change at any time. Note that there is no equivalent server parameter, as the client proposes and manages the window size in RELP protocol. - **tls** (not mandatory, values "on","off", default "off") If set to "on", the RELP connection will be encrypted by TLS, so that the data is protected against observers. Please note that both the client and the server must have set TLS to either "on" or "off". Other combinations lead to unpredictable results. *Attention when using GnuTLS 2.10.x or older* Versions older than GnuTLS 2.10.x may cause a crash (Segfault) under certain circumstances. Most likely when an imrelp inputs and an omrelp output is configured. The crash may happen when you are receiving/sending messages at the same time. Upgrade to a newer version like GnuTLS 2.12.21 to solve the problem. - **tls.compression** (not mandatory, values "on","off", default "off") The controls if the TLS stream should be compressed (zipped). While this increases CPU use, the network bandwidth should be reduced. Note that typical text-based log records usually compress rather well. - **tls.permittedPeer** peer Places access restrictions on this forwarder. Only peers which have been listed in this parameter may be connected to. This guards against rouge servers and man-in-the-middle attacks. The validation bases on the certficate the remote peer presents. The *peer* parameter lists permitted certificate fingerprints. Note that it is an array parameter, so either a single or multiple fingerprints can be listed. When a non-permitted peer is connected to, the refusal is logged together with it's fingerprint. So if the administrator knows this was a valid request, he can simple add the fingerprint by copy and paste from the logfile to rsyslog.conf. It must be noted, though, that this situation should usually not happen after initial client setup and administrators should be alert in this case. Note that usually a single remote peer should be all that is ever needed. Support for multiple peers is primarily included in support of load balancing scenarios. If the connection goes to a specific server, only one specific certificate is ever expected (just like when connecting to a specific ssh server). To specify multiple fingerprints, just enclose them in braces like this: :: tls.permittedPeer=["SHA1:...1", "SHA1:....2"] To specify just a single peer, you can either specify the string directly or enclose it in braces. - **tls.authMode** mode Sets the mode used for mutual authentication. Supported values are either "*fingerprint*\ " or "*name"*. Fingerprint mode basically is what SSH does. It does not require a full PKI to be present, instead self-signed certs can be used on all peers. Even if a CA certificate is given, the validity of the peer cert is NOT verified against it. Only the certificate fingerprint counts. In "name" mode, certificate validation happens. Here, the matching is done against the certificate's subjectAltName and, as a fallback, the subject common name. If the certificate contains multiple names, a match on any one of these names is considered good and permits the peer to talk to rsyslog. - **tls.cacert** the CA certificate that can verify the machine certs - **tls.mycert** the machine public certiificate - **tls.myprivkey** the machine private key - **tls.prioritystring** (not mandatory, string) This parameter permits to specify the so-called "priority string" to GnuTLS. This string gives complete control over all crypto parameters, including compression setting. For this reason, when the prioritystring is specified, the "tls.compression" parameter has no effect and is ignored. Full information about how to construct a priority string can be found in the GnuTLS manual. At the time of this writing, this information was contained in `section 6.10 of the GnuTLS manual `__. **Note: this is an expert parameter.** Do not use if you do not exactly know what you are doing. - **localclientip** ip_address (not mandatory, string) omrelp uses ip_address as local client address while connecting to remote logserver. **Sample:** The following sample sends all messages to the central server "centralserv" at port 2514 (note that that server must run imrelp on port 2514). :: module(load="omrelp") action(type="omrelp" target="centralserv" port="2514") **Legacy Configuration Directives**: This module uses old-style action configuration to keep consistent with the forwarding rule. So far, no additional configuration directives can be specified. To send a message via RELP, use :: *.*  :omrelp::;