time zones - probably revisited.
We run central log servers for our entire infrastructure.. This includes collecting, storing and archiving logs for hosts and applications that we do *not* administer. On a good day, admins for these other hosts are very cooperative and will change configuration as we instruct them (log line formats, time zone, proper host names etc.) Increasingly vendors are shipping VMware application images. You just boot the image and configure it via a GIU or web front end. There is no real login on the host for fine grained configuration. Even the VMware console is almost to this state. Anyhow, the problem I am running into is that these systems are not logging to our servers with consistent time-zone information. The time-zone info is in the syslog message, but syslog will not convert it by default. Enter the destination driver configuration directive of time-zone("+/-XX:YY") This is almost great :-( This means that I can convert the incoming time stamps to a specific time zone, but not automatically to the time zone that my syslog-ng server runs in. Where I live we observe daylight savings time (-07:00) and right now we are using standard time (-08:00). When the time zone changes (PST to PDT then back) I can not get syslog-ng to write the logs with a time zone that follows the PDT->PST->PDT changes. If there is a way to do this I would appreciate the info. I could't find it in the Guide or FAQ. If there isn't ... yet, does it sound reasonable that the time-zone() option be able to take an argument of "local" to allow converting the time zone information to match that of the host. Thanks.
/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? If you really want to keep it, can the valid set be made very inclusive. The reason I'm bumping into this is cisco logs, symatec endpoint logs and oracle VMWare appliance boxes. I'm sure there are others out there :-( Evan.
Evan Rempel <erempel@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). -- |8]
On 01/18/2013 03:56 AM, Gergely Nagy wrote:
Evan Rempel <erempel@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@uvic.ca Senior Systems Administrator 250.721.7691 Data Centre Services, University Systems, University of Victoria
participants (2)
-
Evan Rempel
-
Gergely Nagy