Done. On Sun, Dec 20, 2015 at 8:52 PM, singh.janmejay <[email protected]> wrote: > That is already the case. > > -- > Regards, > Janmejay > > PS: Please blame the typos in this mail on my phone's uncivilized soft > keyboard sporting it's not-so-smart-assist technology. > > > On Dec 19, 2015 9:46 PM, "David Lang" <[email protected]> wrote: >> >> remember that while the table is loading, there will be queries against it >> (from other worker threads is nothing else), and such queries should return >> the data from the old version of the table. >> >> David Lang >> >> On Sat, 19 Dec 2015, singh.janmejay wrote: >> >>> Date: Sat, 19 Dec 2015 20:43:41 +0530 >>> From: singh.janmejay <[email protected]> >>> Reply-To: rsyslog-users <[email protected]> >>> To: rsyslog-users <[email protected]> >>> Subject: Re: [rsyslog] rsyslog next release and lookup-tables >>> >>> Good point. I'll change it. It's not a big change, will do it whenever I >>> can find a few hours in the coming week. >>> >>> For clarity, we'll return to semantics proposed in original post. I'll >>> make >>> it async too. >>> >>> -- >>> Regards, >>> Janmejay >>> >>> PS: Please blame the typos in this mail on my phone's uncivilized soft >>> keyboard sporting it's not-so-smart-assist technology. >>> >>> On Dec 19, 2015 5:08 AM, "David Lang" <[email protected]> wrote: >>> >>>> I meant to respond to this, but may have forgotten to. >>>> >>>> The table load can be quite lengthy[1], so we wanted it to be >>>> asynchronous. The new two-part approach doesn't have that ability. >>>> >>>> I would have the load process generate a log message when it finishes >>>> saying if it succeeds or fails and you can then detect and take action >>>> on >>>> that. >>>> >>>> David Lang >>>> >>>> [1] the use case I was thinking of when I designed the sparse table type >>>> is geoip lookup, using a table such as the one provided by MaxMind (some >>>> for free, some at some costs), this can be a multi GB table that's being >>>> loaded, so we don't want to halt log processing while the table is >>>> loading >>>> >>>> >>>> On Fri, 18 Dec 2015, singh.janmejay wrote: >>>> >>>> Date: Fri, 18 Dec 2015 21:12:01 +0530 >>>>> >>>>> From: singh.janmejay <[email protected]> >>>>> Reply-To: rsyslog-users <[email protected]> >>>>> To: rsyslog-users <[email protected]> >>>>> Subject: Re: [rsyslog] rsyslog next release and lookup-tables >>>>> >>>>> This change is now in PR. >>>>> >>>>> There is a minor change. Actually stub_lookup_table_value statement >>>>> needs to know the lookup table as well, so it takes 2 arguments (not >>>>> 1). >>>>> So, the fragment would look like: >>>>> if (not reload_lookup_table("foo")) then { >>>>> stub_lookup_table_value("foo", "reload_failed") >>>>> } >>>>> >>>>> On Thu, Nov 26, 2015 at 8:16 PM, singh.janmejay >>>>> <[email protected]> wrote: >>>>> >>>>>> Resurrecting this thread for a discussing a deviation from old >>>>>> lookup_table proposal. >>>>>> >>>>>> The PR doesn't include load_lookup_table (a rainerscript statement >>>>>> that is supposed to reload lookup table). >>>>>> >>>>>> Original proposal link: http://www.rsyslog.com/doc/lookup_tables.html >>>>>> >>>>>> Im thinking of implementing it using a function >>>>>> reload_lookup_table(name) and a statement >>>>>> stub_lookup_table_value(value). >>>>>> >>>>>> It allows better composability and leaves room for better backward >>>>>> compatibility. >>>>>> >>>>>> Its possible to get the same effect as the load_lookup_table(...) gets >>>>>> in the proposed form using: >>>>>> >>>>>> if (not reload_lookup_table("foo")) then { >>>>>> stub_lookup_table_value("reload_failed") >>>>>> } >>>>>> >>>>>> However, it can be composed with other rainerscript controls. Eg. one >>>>>> can log failiures to reload table to a separate log-file, increment a >>>>>> metric which reports this failure, or send it to a remote destination. >>>>>> >>>>>> if (not reload_lookup_table("foo")) then { >>>>>> action(type="omfile"...) >>>>>> } >>>>>> >>>>>> Functionally, this is all that matters. >>>>>> >>>>>> Have a look at PR(comments) for details (backward compatibility issue >>>>>> etc). >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 3, 2015 at 7:37 PM, singh.janmejay >>>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Will cross-reference in the kill-feature PR. >>>>>>> >>>>>>> On Tue, Nov 3, 2015 at 7:37 PM, singh.janmejay < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Sorry for the delay. Here is the PR: >>>>>>>> https://github.com/rsyslog/rsyslog/pull/578 >>>>>>>> >>>>>>>> On Tue, Nov 3, 2015 at 6:02 PM, Rainer Gerhards >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>>> 2015-11-03 12:54 GMT+01:00 <[email protected]>: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> As far as I see, today is the release data of the next rsyslog >>>>>>>>>> version. >>>>>>>>>> I did not see any changes about the lookup diffs, Janmejay >>>>>>>>>> promised, >>>>>>>>>> so I'm quite nerverous that the new release will no longer contain >>>>>>>>>> the >>>>>>>>>> lookup-tables. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Please have a look here for status updates: >>>>>>>>> https://github.com/rsyslog/rsyslog/pull/544 >>>>>>>>> >>>>>>>>> In short: I won't remove it this release, as I have no longer been >>>>>>>>> tortured with CVEs and I think we can let it stand as is - NOT >>>>>>>>> officially existing - for a bit longer. I hope we can merge >>>>>>>>> something >>>>>>>>> solid into the december or january relaese. >>>>>>>>> >>>>>>>>> Rainer >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please do not remove it, as it works fine (after the last patch) >>>>>>>>>> and >>>>>>>>>> I (and possibly others) use it already in production. >>>>>>>>>> If it is needed I will help to document the functionality as it >>>>>>>>>> exists right now. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Christopher >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> I have never heared such a nonsense. >>>>>>>>>> Actually the number of applications that does not include features >>>>>>>>>> that are not official documented shoult be extremly limited. >>>>>>>>>> >>>>>>>>>> The functionality is really usefull and already in big landscapes >>>>>>>>>> productive. >>>>>>>>>> Please, please do NOT remove the lookup-table from the main >>>>>>>>>> branch. >>>>>>>>>> The functionaltiy works fine, I'm using this since march and I did >>>>>>>>>> not have any issue since the latest patch of janmejay. >>>>>>>>>> >>>>>>>>>> Even the "concept" is not fully implemented (e.g. smaller things >>>>>>>>>> like nomatch) the main part works fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My suggestion would be to document everything which is currently >>>>>>>>>> implemented and keep the "conceptual documentation" as it is. >>>>>>>>>> So the Maintainer should no longer have an issue with it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If the main issue it the time to document the already implemented >>>>>>>>>> features, I can create a patch. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Gesendet: Dienstag, 06. Oktober 2015 um 07:36 Uhr >>>>>>>>>>> >>>>>>>>>>> Von: "David Lang" <[email protected]> >>>>>>>>>>> An: rsyslog-users <[email protected]> >>>>>>>>>>> Betreff: Re: [rsyslog] Separation of actions based on log source >>>>>>>>>>> - >>>>>>>>>>> with good performance >>>>>>>>>>> >>>>>>>>>>> a CVE for something that requires manually enabling an >>>>>>>>>>> experimental >>>>>>>>>>> feature??? >>>>>>>>>>> >>>>>>>>>>> it would be one thing if a default config had the problem, or if >>>>>>>>>>> it >>>>>>>>>>> was >>>>>>>>>>> something entirely dependent on remote data. >>>>>>>>>>> >>>>>>>>>>> I would be very tempted to respond to the CVE with "don't enable >>>>>>>>>>> this incomplete >>>>>>>>>>> feature" as the solution. It's very common for incomplete >>>>>>>>>>> features >>>>>>>>>>> to be >>>>>>>>>>> included in released versions >>>>>>>>>>> >>>>>>>>>>> grumble, we have enough real bugs to worry about. >>>>>>>>>>> >>>>>>>>>>> David Lang >>>>>>>>>>> >>>>>>>>>>> On Tue, 6 Oct 2015, Rainer Gerhards wrote: >>>>>>>>>>> >>>>>>>>>>> > Date: Tue, 6 Oct 2015 07:15:31 +0200 >>>>>>>>>>> > From: Rainer Gerhards <[email protected]> >>>>>>>>>>> > Reply-To: rsyslog-users <[email protected]> >>>>>>>>>>> > To: rsyslog-users <[email protected]> >>>>>>>>>>> > Subject: Re: [rsyslog] Separation of actions based on log >>>>>>>>>>> > source >>>>>>>>>>> - with good >>>>>>>>>>> > performance >>>>>>>>>>> > >>>>>>>>>>> > Sorry, folks, good intent always seems to find someone who >>>>>>>>>>> > turns >>>>>>>>>>> it >>>>>>>>>>> > into negative. I was yesterday contacted by a distro maintainer >>>>>>>>>>> who >>>>>>>>>>> > wants to turn this bug in the officially non-existant lookup >>>>>>>>>>> > table >>>>>>>>>>> > feature into a CVE and insists that it is a vuln even after the >>>>>>>>>>> > argument that the feature never oficially existed. >>>>>>>>>>> > >>>>>>>>>>> > It looks like it was a bad idea to merge potentially useful yet >>>>>>>>>>> > incomplete code into the main branch (and documenting it to be >>>>>>>>>>> > not >>>>>>>>>>> > present). It looks like I need to re-think my stance on >>>>>>>>>>> experimental >>>>>>>>>>> > features. >>>>>>>>>>> > >>>>>>>>>>> > Anyhow, I really don't want to support the argument that >>>>>>>>>>> > something >>>>>>>>>>> > non-existing can be a CVE. As such, I will create a new >>>>>>>>>>> > master-insecure branch, which will be a clone of the current >>>>>>>>>>> master >>>>>>>>>>> > branch. Then I'll remove the lookup table code, so that the >>>>>>>>>>> > code >>>>>>>>>>> base >>>>>>>>>>> > matches the documentation. I really don't want to create a >>>>>>>>>>> > general >>>>>>>>>>> > principle here that we need to create CVEs (and patched) for >>>>>>>>>>> something >>>>>>>>>>> > that was just added as a convenience for a handful of folks who >>>>>>>>>>> were >>>>>>>>>>> > ready to take a risk. >>>>>>>>>>> > >>>>>>>>>>> > If there is sufficient interest, we can consider officially >>>>>>>>>>> > adding >>>>>>>>>>> > this feature to the January 8.15 release iff it is ready by >>>>>>>>>>> > then. >>>>>>>>>>> > @janmejay: please let me know if you would like to continue >>>>>>>>>>> > with >>>>>>>>>>> your >>>>>>>>>>> > work on lookup tables under this new situation. >>>>>>>>>>> > >>>>>>>>>>> > As soon as I have time, I'll check what else needs to be >>>>>>>>>>> > removed. >>>>>>>>>>> Not >>>>>>>>>>> > sure about the ./contributed branch, because the project cannot >>>>>>>>>>> > guarantee at all this is bug-free. It's documented to be so, >>>>>>>>>>> > but >>>>>>>>>>> if >>>>>>>>>>> > that is not sufficient, it should probably live only in the >>>>>>>>>>> > master-insecure branch. >>>>>>>>>>> > >>>>>>>>>>> > Rainer >>>>>>>>>>> > >>>>>>>>>>> > 2015-10-02 17:29 GMT+02:00 singh.janmejay < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >> As of now it returns empty string for no-match. I guess we >>>>>>>>>>> should go ahead >>>>>>>>>>> >> with it in its current form. We can add default value any time >>>>>>>>>>> later >>>>>>>>>>> >> without breaking compatibility(it'd default to ""). >>>>>>>>>>> >> >>>>>>>>>>> >> I'll add a test for multiple tables on Monday. >>>>>>>>>>> >> >>>>>>>>>>> >> On Fri, Oct 2, 2015, 7:16 PM <[email protected]> >>>>>>>>>>> >> wrote: >>>>>>>>>>> >> >>>>>>>>>>> >>> Hi, >>>>>>>>>>> >>> No, I didn't. I even didn't realize the patch. >>>>>>>>>>> >>> >>>>>>>>>>> >>> It seems to be exactly the related issue. So I don't expect >>>>>>>>>>> >>> any >>>>>>>>>>> further >>>>>>>>>>> >>> issues. >>>>>>>>>>> >>> I will use the new version on 2 systems. If there is any >>>>>>>>>>> >>> other >>>>>>>>>>> issue, I >>>>>>>>>>> >>> will let you know. >>>>>>>>>>> >>> Release data for next rsyslog version is quite far so enough >>>>>>>>>>> time to >>>>>>>>>>> >>> test... ;) >>>>>>>>>>> >>> >>>>>>>>>>> >>> The missing implementation of "nomatch" (default) entry as >>>>>>>>>>> described at >>>>>>>>>>> >>> http://www.rsyslog.com/doc/lookup_tables.html >>>>>>>>>>> >>> would from my opinion require changes: >>>>>>>>>>> >>> >>>>>>>>>>> >>> Arround line 132 of lookup.c file (save of value) >>>>>>>>>>> >>> Arround line 243 of lookup.c file (search in lookuptable >>>>>>>>>>> >>> fails, >>>>>>>>>>> so return >>>>>>>>>>> >>> nomatch value. >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> regards >>>>>>>>>>> >>> Chris >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> > Gesendet: Donnerstag, 01. Oktober 2015 um 16:57 Uhr >>>>>>>>>>> >>> > Von: "singh.janmejay" <[email protected]> >>>>>>>>>>> >>> > An: rsyslog-users <[email protected]> >>>>>>>>>>> >>> > Betreff: Re: [rsyslog] Separation of actions based on log >>>>>>>>>>> source - with >>>>>>>>>>> >>> good performance >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > Yes, if you build off master, that problem should go away >>>>>>>>>>> >>> > (if >>>>>>>>>>> it was due >>>>>>>>>>> >>> to >>>>>>>>>>> >>> > lookup-table). >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > On Thu, Oct 1, 2015, 7:00 PM Rainer Gerhards < >>>>>>>>>>> [email protected]> >>>>>>>>>>> >>> > wrote: >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > > 2015-10-01 15:14 GMT+02:00 singh.janmejay < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>> > > > If you can share output of all thread backtrace we can >>>>>>>>>>> confirm if >>>>>>>>>>> >>> this >>>>>>>>>>> >>> > > > is the cause. >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > let's first double-check: Christopher, did you use >>>>>>>>>>> yesterday evening's >>>>>>>>>>> >>> > > master branch? Because that contains a patch from >>>>>>>>>>> >>> > > Janmejay >>>>>>>>>>> that I >>>>>>>>>>> >>> > > think causes the problem for you. Or am I wrong, >>>>>>>>>>> >>> > > Janmejay? >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > Rainer >>>>>>>>>>> >>> > > > >>>>>>>>>>> >>> > > > On Thu, Oct 1, 2015 at 2:30 PM, < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>> > > >> Hi, >>>>>>>>>>> >>> > > >> Ups I was not detailed enough. >>>>>>>>>>> >>> > > >> The problem with rsyslog-die does not always occur. >>>>>>>>>>> >>> > > >> But >>>>>>>>>>> sometimes >>>>>>>>>>> >>> > > unexpectedly. >>>>>>>>>>> >>> > > >> In my environments the files grow or reduce sometimes, >>>>>>>>>>> so maybe this >>>>>>>>>>> >>> > > has something do with it (or the processing delay). >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> regards >>>>>>>>>>> >>> > > >> Chris >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> -----Ursprüngliche Nachricht----- >>>>>>>>>>> >>> > > >> Gesendet: Donnerstag, 01 Oktober 2015 um 10:57:37 Uhr >>>>>>>>>>> >>> > > >> Von: [email protected] >>>>>>>>>>> >>> > > >> An: "singh.janmejay" >>>>>>>>>>> >>> > > >> <[email protected]>,rsyslog-users >>>>>>>>>>> < >>>>>>>>>>> >>> > > [email protected]> >>>>>>>>>>> >>> > > >> Betreff: Re: [rsyslog] Separation of actions based on >>>>>>>>>>> log source - >>>>>>>>>>> >>> with >>>>>>>>>>> >>> > > good performance >>>>>>>>>>> >>> > > >> Hi, >>>>>>>>>>> >>> > > >> For my opinion it is really good to support >>>>>>>>>>> >>> > > >> looku-tables >>>>>>>>>>> official. >>>>>>>>>>> >>> > > >> Thanks for the work on the implementation David & >>>>>>>>>>> >>> > > >> Rainer. >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> I have some experiences using lookup-Tables with > >>>>>>>>>>> >>> > > >> 2500 >>>>>>>>>>> Entries. >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> There are 2 open issues: >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> 1. There is a bug when sending SIGHUP and reprocessing >>>>>>>>>>> big lists, >>>>>>>>>>> >>> which >>>>>>>>>>> >>> > > leads to die of rsyslogd. >>>>>>>>>>> >>> > > >> I spend some time to identify this bug, unfortunately >>>>>>>>>>> I'm still not >>>>>>>>>>> >>> > > able to find the exact reason. >>>>>>>>>>> >>> > > >> The problem seems to occur not directly after sending >>>>>>>>>>> SIGHUP, but >>>>>>>>>>> >>> > > later. Maybe this has something to do with Queues. >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> 2. The "default" Value is not implemented. This should >>>>>>>>>>> be mentioned >>>>>>>>>>> >>> in >>>>>>>>>>> >>> > > the documentation or implemented. >>>>>>>>>>> >>> > > >> I guess its quite less work, but I'm not sure how soon >>>>>>>>>>> >>> > > >> I >>>>>>>>>>> find the >>>>>>>>>>> >>> time >>>>>>>>>>> >>> > > to do all the things arround the pure developement... ;) >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> regards >>>>>>>>>>> >>> > > >> Chris >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> -----Ursprüngliche Nachricht----- >>>>>>>>>>> >>> > > >> Gesendet: Donnerstag, 01 Oktober 2015 um 09:41:26 Uhr >>>>>>>>>>> >>> > > >> Von: "singh.janmejay" <[email protected]> >>>>>>>>>>> >>> > > >> An: rsyslog-users <[email protected]> >>>>>>>>>>> >>> > > >> Betreff: Re: [rsyslog] Separation of actions based on >>>>>>>>>>> log source - >>>>>>>>>>> >>> with >>>>>>>>>>> >>> > > good performance >>>>>>>>>>> >>> > > >> OK, allow me a few days, I'll add one more test for >>>>>>>>>>> multiple tables. >>>>>>>>>>> >>> > > Will >>>>>>>>>>> >>> > > >> make the doc change after that. >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> -- >>>>>>>>>>> >>> > > >> Regards, >>>>>>>>>>> >>> > > >> Janmejay >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> PS: Please blame the typos in this mail on my phone's >>>>>>>>>>> uncivilized >>>>>>>>>>> >>> soft >>>>>>>>>>> >>> > > >> keyboard sporting it's not-so-smart-assist technology. >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >> On Oct 1, 2015 12:29 PM, "Rainer Gerhards" < >>>>>>>>>>> >>> [email protected]> >>>>>>>>>>> >>> > > wrote: >>>>>>>>>>> >>> > > >> >>>>>>>>>>> >>> > > >>> 2015-09-29 20:58 GMT+02:00 singh.janmejay < >>>>>>>>>>> >>> [email protected]>: >>>>>>>>>>> >>> > > >>> > Sweet, plan on playing with it tomorrow. >>>>>>>>>>> >>> > > >>> >>>>>>>>>>> >>> > > >>> If you have verified that the current functionality >>>>>>>>>>> works fine >>>>>>>>>>> >>> after >>>>>>>>>>> >>> > > >>> your patch, I wouldn't object if you modify the doc >>>>>>>>>>> >>> > > >>> to >>>>>>>>>>> tell the >>>>>>>>>>> >>> world >>>>>>>>>>> >>> > > >>> that this part of lookup tables is now officially >>>>>>>>>>> supported. we >>>>>>>>>>> >>> could >>>>>>>>>>> >>> > > >>> release with 8.14. I think what currently exists is >>>>>>>>>>> already pretty >>>>>>>>>>> >>> > > >>> useful and if we feel confident enough it works, we >>>>>>>>>>> should release >>>>>>>>>>> >>> it. >>>>>>>>>>> >>> > > >>> >>>>>>>>>>> >>> > > >>> Rainer >>>>>>>>>>> >>> > > >>> > >>>>>>>>>>> >>> > > >>> > -- >>>>>>>>>>> >>> > > >>> > Regards, >>>>>>>>>>> >>> > > >>> > Janmejay >>>>>>>>>>> >>> > > >>> > >>>>>>>>>>> >>> > > >>> > PS: Please blame the typos in this mail on my >>>>>>>>>>> >>> > > >>> > phone's >>>>>>>>>>> uncivilized >>>>>>>>>>> >>> > > soft >>>>>>>>>>> >>> > > >>> > keyboard sporting it's not-so-smart-assist >>>>>>>>>>> >>> > > >>> > technology. >>>>>>>>>>> >>> > > >>> > >>>>>>>>>>> >>> > > >>> > On Sep 30, 2015 12:16 AM, "Rainer Gerhards" < >>>>>>>>>>> >>> > > [email protected]> >>>>>>>>>>> >>> > > >>> > wrote: >>>>>>>>>>> >>> > > >>> > >>>>>>>>>>> >>> > > >>> >> It's a long time since I implemented what >>>>>>>>>>> >>> > > >>> >> currently >>>>>>>>>>> is there. It >>>>>>>>>>> >>> > > should >>>>>>>>>>> >>> > > >>> be >>>>>>>>>>> >>> > > >>> >> relatively solid with probably some minor >>>>>>>>>>> >>> > > >>> >> glitches. >>>>>>>>>>> It provides >>>>>>>>>>> >>> the >>>>>>>>>>> >>> > > code >>>>>>>>>>> >>> > > >>> >> functionality as far as I remember. >>>>>>>>>>> >>> > > >>> >> >>>>>>>>>>> >>> > > >>> >> Rainer >>>>>>>>>>> >>> > > >>> >> >>>>>>>>>>> >>> > > >>> >> Sent from phone, thus brief. >>>>>>>>>>> >>> > > >>> >> Am 29.09.2015 20:07 schrieb "singh.janmejay" < >>>>>>>>>>> >>> > > [email protected] >>>>>>>>>>> >>> > > >>> >: >>>>>>>>>>> >>> > > >>> >> >>>>>>>>>>> >>> > > >>> >> > Rainer/David, >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > Exactly how much of lookup_table functionality >>>>>>>>>>> >>> > > >>> >> > is >>>>>>>>>>> implemented? >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > What can I not do with it? (you mentioned >>>>>>>>>>> something about >>>>>>>>>>> >>> single >>>>>>>>>>> >>> > > table >>>>>>>>>>> >>> > > >>> >> > in this thread, can you please elaborate?). >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > On Tue, Mar 31, 2015 at 7:23 PM, Rainer Gerhards >>>>>>>>>>> >>> > > >>> >> > <[email protected]> wrote: >>>>>>>>>>> >>> > > >>> >> > > 2015-03-31 15:46 GMT+02:00 < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>> > > >>> >> > >> Hi, >>>>>>>>>>> >>> > > >>> >> > >> Do you have some experience how large >>>>>>>>>>> Lookup-tables can be >>>>>>>>>>> >>> > > until >>>>>>>>>>> >>> > > >>> there >>>>>>>>>>> >>> > > >>> >> > are "negative" effects? >>>>>>>>>>> >>> > > >>> >> > >> 2400 entries seems to work fine :) >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> >>> > > >>> >> > > IIRC the current partial implementation is >>>>>>>>>>> >>> > > >>> >> > > O(log >>>>>>>>>>> n), so no >>>>>>>>>>> >>> > > problem. >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> And another question, do I loose events, when >>>>>>>>>>> doing a kill >>>>>>>>>>> >>> -HUP >>>>>>>>>>> >>> > > >>> (for >>>>>>>>>>> >>> > > >>> >> > update of lookup-table)? >>>>>>>>>>> >>> > > >>> >> > >> (e.g. client threads are hard >>>>>>>>>>> >>> > > >>> >> > >> "terminated"...) >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> >>> > > >>> >> > > *should* not cause any issues. >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> >>> > > >>> >> > > Rainer >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> best regards >>>>>>>>>>> >>> > > >>> >> > >> Chris >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> Gesendet: Mittwoch, 25. März 2015 um 19:28 >>>>>>>>>>> >>> > > >>> >> > >> Uhr >>>>>>>>>>> >>> > > >>> >> > >> Von: "David Lang" <[email protected]> >>>>>>>>>>> >>> > > >>> >> > >> An: rsyslog-users <[email protected]> >>>>>>>>>>> >>> > > >>> >> > >> Betreff: Re: [rsyslog] Separation of actions >>>>>>>>>>> based on log >>>>>>>>>>> >>> > > source - >>>>>>>>>>> >>> > > >>> >> with >>>>>>>>>>> >>> > > >>> >> > good performance >>>>>>>>>>> >>> > > >>> >> > >> On Wed, 25 Mar 2015, [email protected] >>>>>>>>>>> wrote: > >>>>>>>>>>> >>> Hi, > >>>>>>>>>>> >>> > > I was >>>>>>>>>>> >>> > > >>> >> > doing some experiments with the lookup-table. > >>>>>>>>>>> Looks really >>>>>>>>>>> >>> nice >>>>>>>>>>> >>> > > and >>>>>>>>>>> >>> > > >>> the >>>>>>>>>>> >>> > > >>> >> > performance is promising. > (Unfortunately the >>>>>>>>>>> evaluation of >>>>>>>>>>> >>> > > "nomatch" >>>>>>>>>>> >>> > > >>> >> > attribute is currently not implemented...) > > >>>>>>>>>>> Never the >>>>>>>>>>> >>> less: > >>>>>>>>>>> >>> > > My >>>>>>>>>>> >>> > > >>> plan >>>>>>>>>>> >>> > > >>> >> > is, to do diffent actions based on the type of >>>>>>>>>>> host, mapped >>>>>>>>>>> >>> in the >>>>>>>>>>> >>> > > >>> >> > lookup-list. > For testing purposes, I use alway >>>>>>>>>>> omfile. > > >>>>>>>>>>> >>> > > >>> >> Unfortunately >>>>>>>>>>> >>> > > >>> >> > it does not work, to change the ruleset based on >>>>>>>>>>> the >>>>>>>>>>> >>> variable. > >>>>>>>>>>> >>> > > Is >>>>>>>>>>> >>> > > >>> there >>>>>>>>>>> >>> > > >>> >> > any other option or is there any mistake? for >>>>>>>>>>> omfile you can >>>>>>>>>>> >>> use >>>>>>>>>>> >>> > > the >>>>>>>>>>> >>> > > >>> >> > dynafile approach to use the return variable, >>>>>>>>>>> >>> > > >>> >> > for >>>>>>>>>>> remote >>>>>>>>>>> >>> things >>>>>>>>>>> >>> > > you >>>>>>>>>>> >>> > > >>> would >>>>>>>>>>> >>> > > >>> >> > need to do an if then else approach for >>>>>>>>>>> performance reasons >>>>>>>>>>> >>> many >>>>>>>>>>> >>> > > of >>>>>>>>>>> >>> > > >>> the >>>>>>>>>>> >>> > > >>> >> > fields in rsyslog do not accept variables. This >>>>>>>>>>> allows them >>>>>>>>>>> >>> to be >>>>>>>>>>> >>> > > >>> >> > computed/parsed once at startup rather than >>>>>>>>>>> >>> > > >>> >> > having >>>>>>>>>>> to be >>>>>>>>>>> >>> > > evaluated for >>>>>>>>>>> >>> > > >>> >> each >>>>>>>>>>> >>> > > >>> >> > log message. It's a bit of a hassle when you do >>>>>>>>>>> want to do >>>>>>>>>>> >>> > > something >>>>>>>>>>> >>> > > >>> >> > dynamic, but even in cases where you have some >>>>>>>>>>> dynamic >>>>>>>>>>> >>> things, you >>>>>>>>>>> >>> > > >>> tend >>>>>>>>>>> >>> > > >>> >> to >>>>>>>>>>> >>> > > >>> >> > have other static things that benefit from the >>>>>>>>>>> speedup. David >>>>>>>>>>> >>> > > Lang > >>>>>>>>>>> >>> > > >>> *** >>>>>>>>>>> >>> > > >>> >> > syslog.conf *** > >>>>>>>>>>> >>> > > >>> >> > lookup_table(name="lookuptable" >>>>>>>>>>> >>> > > >>> >> > file="/etc/rsyslog.lookup") > set $!dst = >>>>>>>>>>> >>> lookup("lookuptable", >>>>>>>>>>> >>> > > >>> >> > $fromhost-ip); > ruleset(name="typea"){ > >>>>>>>>>>> action(type="omfile" >>>>>>>>>>> >>> > > >>> >> > file="/var/log/file_typea.log") > } > >>>>>>>>>>> ruleset(name="typea"){ > >>>>>>>>>>> >>> > > >>> >> > action(type="omfile" >>>>>>>>>>> file="/var/log/file_typeb.log") > } > > # >>>>>>>>>>> >>> > > Change >>>>>>>>>>> >>> > > >>> set >>>>>>>>>>> >>> > > >>> >> > default ruleset, based on sourceip > >>>>>>>>>>> $DefaultRuleset $!dst > > >>>>>>>>>>> >>> > > >>> >> > module(load="imtcp" KeepAlive="on" >>>>>>>>>>> KeepAlive.Probes="1" >>>>>>>>>>> >>> > > >>> >> > KeepAlive.Interval="2" KeepAlive.Time="20") > >>>>>>>>>>> >>> input(type="imtcp" >>>>>>>>>>> >>> > > >>> >> > port="7714") > > *** lookup-table *** > { >>>>>>>>>>> "version":1, >>>>>>>>>>> >>> > > >>> "nomatch":"unk", >>>>>>>>>>> >>> > > >>> >> > "type":"string", > "table":[ >>>>>>>>>>> >>> > > >>> >> > {"index":"10.3.5.4", >>>>>>>>>>> >>> "value":"typea" >>>>>>>>>>> >>> > > }, > >>>>>>>>>>> >>> > > >>> >> > {"index":"10.2.2.1", "value":"typea" }, > >>>>>>>>>>> {"index":"10.0.2.2", >>>>>>>>>>> >>> > > >>> >> > "value":"typeb" }, > {"index":"10.2.2.3", >>>>>>>>>>> "value":"typeb" } > >>>>>>>>>>> >>> ] > >>>>>>>>>>> >>> > > } > >>>>>>>>>>> >>> > > >>> > > >>>>>>>>>>> >>> > > >>> >> > best regards > Chris > > > > Gesendet: >>>>>>>>>>> Dienstag, 24. März >>>>>>>>>>> >>> > > 2015 um >>>>>>>>>>> >>> > > >>> >> 17:14 >>>>>>>>>>> >>> > > >>> >> > Uhr > Von: [email protected] > An: >>>>>>>>>>> >>> > > [email protected] > >>>>>>>>>>> >>> > > >>> >> > Betreff: Re: [rsyslog] Separation of actions >>>>>>>>>>> >>> > > >>> >> > based >>>>>>>>>>> on log >>>>>>>>>>> >>> source - >>>>>>>>>>> >>> > > >>> with >>>>>>>>>>> >>> > > >>> >> > good performance > Hi David, > > Thanks sounds >>>>>>>>>>> great, I will >>>>>>>>>>> >>> try >>>>>>>>>>> >>> > > this >>>>>>>>>>> >>> > > >>> in >>>>>>>>>>> >>> > > >>> >> > the next days :) > > Chris > > > > Gesendet: >>>>>>>>>>> Montag, 23. >>>>>>>>>>> >>> März >>>>>>>>>>> >>> > > >>> 2015 um >>>>>>>>>>> >>> > > >>> >> > 17:44 Uhr > Von: "David Lang" > An: >>>>>>>>>>> >>> > > >>> >> > rsyslog-users >>>>>>>>>>> > Betreff: >>>>>>>>>>> >>> Re: >>>>>>>>>>> >>> > > >>> >> [rsyslog] >>>>>>>>>>> >>> > > >>> >> > Separation of actions based on log source - with >>>>>>>>>>> good >>>>>>>>>>> >>> performance >>>>>>>>>>> >>> > > > >>>>>>>>>>> >>> > > >>> This >>>>>>>>>>> >>> > > >>> >> is >>>>>>>>>>> >>> > > >>> >> > the sort of thing that the table lookup >>>>>>>>>>> functionality was >>>>>>>>>>> >>> designed >>>>>>>>>>> >>> > > >>> for. > >>>>>>>>>>> >>> > > >>> >> > It wasn't fully implemented to the design >>>>>>>>>>> >>> > > >>> >> > (funding >>>>>>>>>>> fell >>>>>>>>>>> >>> through), >>>>>>>>>>> >>> > > but >>>>>>>>>>> >>> > > >>> I >>>>>>>>>>> >>> > > >>> >> > think it works for a single table. > you could >>>>>>>>>>> >>> > > >>> >> > use >>>>>>>>>>> it to do >>>>>>>>>>> >>> the >>>>>>>>>>> >>> > > >>> mapping >>>>>>>>>>> >>> > > >>> >> > from your many hosts to a couple of values and >>>>>>>>>>> then have your >>>>>>>>>>> >>> > > test be >>>>>>>>>>> >>> > > >>> >> based >>>>>>>>>>> >>> > > >>> >> > on the resulting value. > > David Lang On Mon, >>>>>>>>>>> >>> > > >>> >> > 23 >>>>>>>>>>> Mar 2015 > >>>>>>>>>>> >>> > > [...] > >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> >>> > > >>> >> > >> _______________________________________________ >>>>>>>>>>> >>> > > >>> >> > >> rsyslog mailing list >>>>>>>>>>> >>> > > >>> >> > >> >>>>>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> >> > >> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> >> > >> What's up with rsyslog? Follow >>>>>>>>>>> >>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> >> > >> NOTE WELL: This is a PUBLIC mailing list, >>>>>>>>>>> >>> > > >>> >> > >> posts >>>>>>>>>>> are >>>>>>>>>>> >>> ARCHIVED >>>>>>>>>>> >>> > > by a >>>>>>>>>>> >>> > > >>> >> > myriad of sites beyond our control. PLEASE >>>>>>>>>>> UNSUBSCRIBE and DO >>>>>>>>>>> >>> NOT >>>>>>>>>>> >>> > > >>> POST if >>>>>>>>>>> >>> > > >>> >> > you DON'T LIKE THAT. >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> >>> > > >>> >> > > _______________________________________________ >>>>>>>>>>> >>> > > >>> >> > > rsyslog mailing list >>>>>>>>>>> >>> > > >>> >> > > >>>>>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> >> > > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> >> > > What's up with rsyslog? Follow >>>>>>>>>>> >>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> >> > > NOTE WELL: This is a PUBLIC mailing list, >>>>>>>>>>> >>> > > >>> >> > > posts >>>>>>>>>>> are >>>>>>>>>>> >>> ARCHIVED by >>>>>>>>>>> >>> > > a >>>>>>>>>>> >>> > > >>> >> myriad >>>>>>>>>>> >>> > > >>> >> > of sites beyond our control. PLEASE UNSUBSCRIBE >>>>>>>>>>> and DO NOT >>>>>>>>>>> >>> POST >>>>>>>>>>> >>> > > if you >>>>>>>>>>> >>> > > >>> >> > DON'T LIKE THAT. >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > -- >>>>>>>>>>> >>> > > >>> >> > Regards, >>>>>>>>>>> >>> > > >>> >> > Janmejay >>>>>>>>>>> >>> > > >>> >> > http://codehunk.wordpress.com >>>>>>>>>>> >>> > > >>> >> > _______________________________________________ >>>>>>>>>>> >>> > > >>> >> > rsyslog mailing list >>>>>>>>>>> >>> > > >>> >> > >>>>>>>>>>> >>> > > >>> >> > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> >> > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> >> > What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> >> > NOTE WELL: This is a PUBLIC mailing list, posts >>>>>>>>>>> are ARCHIVED >>>>>>>>>>> >>> by a >>>>>>>>>>> >>> > > >>> myriad >>>>>>>>>>> >>> > > >>> >> > of sites beyond our control. PLEASE UNSUBSCRIBE >>>>>>>>>>> and DO NOT >>>>>>>>>>> >>> POST >>>>>>>>>>> >>> > > if you >>>>>>>>>>> >>> > > >>> >> > DON'T LIKE THAT. >>>>>>>>>>> >>> > > >>> >> _______________________________________________ >>>>>>>>>>> >>> > > >>> >> rsyslog mailing list >>>>>>>>>>> >>> > > >>> >> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> >> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> >> What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> >> NOTE WELL: This is a PUBLIC mailing list, posts >>>>>>>>>>> >>> > > >>> >> are >>>>>>>>>>> ARCHIVED by >>>>>>>>>>> >>> a >>>>>>>>>>> >>> > > myriad >>>>>>>>>>> >>> > > >>> >> of sites beyond our control. PLEASE UNSUBSCRIBE >>>>>>>>>>> >>> > > >>> >> and >>>>>>>>>>> DO NOT POST >>>>>>>>>>> >>> if >>>>>>>>>>> >>> > > you >>>>>>>>>>> >>> > > >>> >> DON'T LIKE THAT. >>>>>>>>>>> >>> > > >>> > _______________________________________________ >>>>>>>>>>> >>> > > >>> > rsyslog mailing list >>>>>>>>>>> >>> > > >>> > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> > What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> > NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> > > myriad >>>>>>>>>>> >>> > > >>> of sites beyond our control. PLEASE UNSUBSCRIBE and >>>>>>>>>>> >>> > > >>> DO >>>>>>>>>>> NOT POST if >>>>>>>>>>> >>> you >>>>>>>>>>> >>> > > >>> DON'T LIKE THAT. >>>>>>>>>>> >>> > > >>> _______________________________________________ >>>>>>>>>>> >>> > > >>> rsyslog mailing list >>>>>>>>>>> >>> > > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >>> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >>> What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >>> NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> > > myriad >>>>>>>>>>> >>> > > >>> of sites beyond our control. PLEASE UNSUBSCRIBE and >>>>>>>>>>> >>> > > >>> DO >>>>>>>>>>> NOT POST if >>>>>>>>>>> >>> you >>>>>>>>>>> >>> > > >>> DON'T LIKE THAT. >>>>>>>>>>> >>> > > >> _______________________________________________ >>>>>>>>>>> >>> > > >> rsyslog mailing list >>>>>>>>>>> >>> > > >> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >> What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >> NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> > > myriad of sites beyond our control. PLEASE UNSUBSCRIBE >>>>>>>>>>> >>> > > and >>>>>>>>>>> DO NOT POST >>>>>>>>>>> >>> if >>>>>>>>>>> >>> > > you DON'T LIKE THAT. >>>>>>>>>>> >>> > > >> _______________________________________________ >>>>>>>>>>> >>> > > >> rsyslog mailing list >>>>>>>>>>> >>> > > >> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > >> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > >> What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > >> NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> > > myriad of sites beyond our control. PLEASE UNSUBSCRIBE >>>>>>>>>>> >>> > > and >>>>>>>>>>> DO NOT POST >>>>>>>>>>> >>> if >>>>>>>>>>> >>> > > you DON'T LIKE THAT. >>>>>>>>>>> >>> > > > >>>>>>>>>>> >>> > > > >>>>>>>>>>> >>> > > > >>>>>>>>>>> >>> > > > -- >>>>>>>>>>> >>> > > > Regards, >>>>>>>>>>> >>> > > > Janmejay >>>>>>>>>>> >>> > > > http://codehunk.wordpress.com >>>>>>>>>>> >>> > > > _______________________________________________ >>>>>>>>>>> >>> > > > rsyslog mailing list >>>>>>>>>>> >>> > > > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > > What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > > NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> myriad >>>>>>>>>>> >>> > > of sites beyond our control. PLEASE UNSUBSCRIBE and DO >>>>>>>>>>> >>> > > NOT >>>>>>>>>>> POST if you >>>>>>>>>>> >>> > > DON'T LIKE THAT. >>>>>>>>>>> >>> > > _______________________________________________ >>>>>>>>>>> >>> > > rsyslog mailing list >>>>>>>>>>> >>> > > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > > What's up with rsyslog? Follow >>>>>>>>>>> https://twitter.com/rgerhards >>>>>>>>>>> >>> > > NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> ARCHIVED by a >>>>>>>>>>> >>> myriad >>>>>>>>>>> >>> > > of sites beyond our control. PLEASE UNSUBSCRIBE and DO >>>>>>>>>>> >>> > > NOT >>>>>>>>>>> POST if you >>>>>>>>>>> >>> > > DON'T LIKE THAT. >>>>>>>>>>> >>> > _______________________________________________ >>>>>>>>>>> >>> > rsyslog mailing list >>>>>>>>>>> >>> > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> > What's up with rsyslog? Follow >>>>>>>>>>> >>> > https://twitter.com/rgerhards >>>>>>>>>>> >>> > NOTE WELL: This is a PUBLIC mailing list, posts are >>>>>>>>>>> >>> > ARCHIVED >>>>>>>>>>> by a myriad >>>>>>>>>>> >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>>>> >>> POST >>>>>>>>>>> if you >>>>>>>>>>> >>> DON'T LIKE THAT. >>>>>>>>>>> >>> _______________________________________________ >>>>>>>>>>> >>> rsyslog mailing list >>>>>>>>>>> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >>> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>>>> >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED >>>>>>>>>>> >>> by >>>>>>>>>>> a myriad >>>>>>>>>>> >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>>>> >>> POST >>>>>>>>>>> if you >>>>>>>>>>> >>> DON'T LIKE THAT. >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> >> rsyslog mailing list >>>>>>>>>>> >> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> >> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> >> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>>>> >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED >>>>>>>>>>> >> by >>>>>>>>>>> a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO >>>>>>>>>>> NOT POST if >>>>>>>>>>> you DON'T LIKE THAT. >>>>>>>>>>> > _______________________________________________ >>>>>>>>>>> > rsyslog mailing list >>>>>>>>>>> > http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> > http://www.rsyslog.com/professional-services/ >>>>>>>>>>> > What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>>>> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by >>>>>>>>>>> > a >>>>>>>>>>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>>>> POST if >>>>>>>>>>> you DON'T LIKE >>>>>>>>>>> THAT._______________________________________________ >>>>>>>>>>> rsyslog mailing list >>>>>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>>> http://www.rsyslog.com/professional-services/ >>>>>>>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a >>>>>>>>>>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>>>> POST if >>>>>>>>>>> you DON'T LIKE THAT. >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> rsyslog mailing list >>>>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>>> http://www.rsyslog.com/professional-services/ >>>>>>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a >>>>>>>>>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>>> POST if >>>>>>>>>> you DON'T LIKE THAT. >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> rsyslog mailing list >>>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>>> http://www.rsyslog.com/professional-services/ >>>>>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>>>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a >>>>>>>>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT >>>>>>>>> POST if >>>>>>>>> you DON'T LIKE THAT. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Janmejay >>>>>>>> http://codehunk.wordpress.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Janmejay >>>>>>> http://codehunk.wordpress.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Janmejay >>>>>> http://codehunk.wordpress.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Janmejay >>>>> http://codehunk.wordpress.com >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com/professional-services/ >>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a >>>>> myriad >>>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >>>>> DON'T LIKE THAT. >>>> >>>> >>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com/professional-services/ >>>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >>>> DON'T LIKE THAT. >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com/professional-services/ >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T >>> LIKE THAT. >> >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T >> LIKE THAT.
-- Regards, Janmejay http://codehunk.wordpress.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
