[syslog-ng] PatternDB program name pattern - invalid characters

[Evan Rempel]

On 01/18/2013 03:56 AM, Gergely Nagy wrote:
> Evan Rempel <erempel at uvic.ca> writes:
>
>> /tmp/mksysdb.4256.xml:12069: element rule: Schemas validity error :
>> Element 'rule', attribute 'class': [facet 'pattern'] The value '%ASA'
>> is not accepted by the pattern '[\-a-zA-Z0-9_\.]+'.
>>
>> I have been bitten once again by the limitation of the program name
>> pattern in the patterndb.
>>
>> Can this character set limitation just be removed?
>
> Personally, I'd just remove it. The restriction does not help syslog-ng,
> we'd be fine with any value whatsoever. But back in October when the
> dash was added to the regexp, Bazsi commented (in #203[1]) that to him,
> it makes sense to have a regexp, and not allow arbitrary strings.
>
>   [1]: https://bugzilla.balabit.com/show_bug.cgi?id=203#c2
>
> As a compromise, I can add % to the regexp aswell, and any other
> character you may find in cisco/symantec/vmware logs (just tell me which
> these are, I use neither of those products).
>
> In the long run though, I'd like to understand why a restriction is
> useful in this case, and if it turns out not to be, remove it
> altogether.
>
>> If you really want to keep it, can the valid set be made very
>> inclusive.
>
> What would you consider sufficiently inclusive? Would something like
> "[\-a-zA-Z0-9_\.%@!^/\+:]+" work? (%, @, !, ^, /, + and : added).


Can on other users chime in on how they use the "class" in the <rule ...> tag in the patterndb?

Personally I just copy the program name into this field. So any characters that are permissible in the program/ident
tag of a syslog message should be acceptable here. Since the program string really only has two restrictions, no space or colen
I would like to see all other characters accepted.

For instance, NetApp uses ident tags of the format [some:class:names] which is just brain dead, but that's what they do :-(
Cisco uses ident tags %CODE-NUMBER-NUMBER

There will be ident names used that I have no experience with either.

Does that give you some guidance.

In my build I patch this restriction to be  "[\-a-zA-Z0-9_\.~!@#$%\^*()/\+:\]\[]+"


-- 
Evan Rempel                                      erempel at uvic.ca
Senior Systems Administrator                        250.721.7691
Data Centre Services, University Systems, University of Victoria