Yes, there does appear to be an issue... Regarding:
1- Match/sub-match starting with 0: This isn't a problem; it's documented,
etc., and I just missed it.
2- I'm putting this in place today, with the proper escaping.
4- This was just a learning point for me, not necessarily something to change.
3- Type conversions or modulus with big numbers:
This one is a bit more concerning. I just did a test with setting a string
variable to a large numeric string, followed by setting another variable to the
mod 5 of that number, and printed both out in a file:
...
template(
name="common1"
type="string"
string="%$!%_\n"
)
set $!msgid = "18446744072308350743";
set $!msgidmod = $!msgid % 5;
action(name="Act_File6"
type="omfile"
template="common1"
file="/syslogdata/testing/6.txt")
...
And this is the output I get:
{ "msgid": "18446744072308350743", "msgidmod": 2 }_
Which is incorrect to begin with. But, even more damning is when I increment
the string by 1 (making it 18446744072308350744) I get the same result:
{ "msgid": "18446744072308350744", "msgidmod": 2 }_
Or, if I then switch to mod 3, I get this, which is also wrong (it should be
zero):
{ "msgid": "18446744072308350744", "msgidmod": 1 }_
But, if I drop down into smaller numbers (255, 256, 257, 258), I get the
correct results. So, something is definitely not right when you get to larger
numbers. I'm not sure whether it's a problem with the string to number
conversion, or the modulus, or something else.
Thanks!
Robert
> Date: Fri, 25 Oct 2013 08:05:07 +0200
> From: [email protected]
> To: [email protected]
> Subject: Re: [rsyslog] Another approach to action load balancing
>
> On Fri, Oct 25, 2013 at 7:51 AM, Pavel Levshin <[email protected]> wrote:
>
> > 25.10.2013 9:30, Robert J. McIntyre:
> >
> > Probably the last email on this, I swear! :) I've had a chance to do a
> >> bunch of digging around, and here's some thoughts/notes on why this was so
> >> weird for me to get sorted out:
> >>
> >>
> >> 1. Match and sub-match for re_extract() start with 0, not 1, which
> >> is
> >> noted in the docs, but didn't register initially
> >>
> >
> > Match numbering had been not obvious to me, too. For submatch, it is
> > natural, as "0" is the whole match, and real submatches are numbered from 1!
>
>
> I think this was for consistency with the property replacer, but I won't
> even check as it is too late to change now. But I agree to your argument ;)
>
>
> >
> >
> > 2. Re_extract doesn't like the typical IP regex (eg.
> >> \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{**1,3}), it didn't seem to like the escape
> >> "\"
> >> characters, so I wound up having to use [0-9]{1,3} and so forth. It
> >> works,
> >> but not sure why the escaped characters didn't work. (Unless I needed to
> >> escape the escape characters because it's in a string, which makes my head
> >> hurt; hrrm.)
> >>
> >
> > re_extract is using POSIX Extended Regular Expressions, but escaped
> > symbols are a part of Perl-compatible Regular Expressions. Which is not
> > supported. It worth mentioning in the documentation.
> >
> >
> I think the reason is much simpler. \ is the escape within rsyslog strings
> (to do things like \n). So if you need a \ inside the regex (which is given
> inside the string), you need to escape that escape.
>
> In other words, "\d{1,3}" will lead to "d{1,3}" being passed to the regex
> processor, what you really wanted was "\\d{1,3}" (obviously, it's the same
> in all languages that use \ as escape - just think C for example).
>
>
> >
> >> 3. Cnum(), or the "type-less" conversion, (probably, can't check the
> >> sources) uses longs, which means that really long sequence/serial numbers
> >> from firewalls cause it to overload and do weird things which make modulus
> >> also weird.
> >>
> >
> > This should not be. Cnum is using 'long long'. Have you seen any signs of
> > a bug here?
> >
> >
> +1
>
> >
> >
> >> 4. Doing type-less comparisons leaves me wondering whether they're
> >> not
> >> evaluating properly, or whether the problem lies upstream when things
> >> don't
> >> work properly. The $.msgid == "2" vs. $.msgid == 2 thing left me
> >> uncertain
> >> what was correct for a while.
> >>
> >
> > Maybe this is much better in 7.5.
> >
> >
> No, and to be honest I think this is the same "problem" in all typeless
> languages. But I didn't want to introduced the "overhead" of a fully type
> languge. After all, it's still a config file format that's deemed to be
> somewhat flexible.
>
> Nevertheless suggestions are welcome. but note that we cannot break what
> works currently.
>
> Rainer
>
> >
> > --
> > Pavel Levshin
> >
> >
> > ______________________________**_________________
> > rsyslog mailing list
> > http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> > http://www.rsyslog.com/**professional-services/<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.
