On Mon, January 4, 2016 6:02 pm, Galen Johnson wrote:
One more...I have some file tests that are testing for file ages and I want them to go yellow at one threshold, red later...I have rules similar to the following:
FILE %/localvolume/customer/.*/schedule/.*.xml$ yellow TYPE=FILEMTIME<2700 FILE %/localvolume/customer/.*/schedule/.*.xml$ red TYPE=FILE MTIME<3600
is there a more succinct way to put that in like:
FILE %/localvolume/customer/.*/schedule/.*.xml$ yellow TYPE=FILEMTIME<2700 red TYPE=FILE MTIME<3600?
I can't see anything helpful in the man pages or analysis.cfg file itself...the entire FILE section is confusing and somewhat contradictory. It would be nice if all the tests were consistent with regards to color...for example:
LOG filename match-pattern [COLOR=color] [IGNORE=ignore-pattern][TEXT=displaytext] vs FILE filename [color] [things to check] [TRACK]
Note there is no "color=" component for FILE (and others). I think this was actually causing a false positive with some of the tests that were set up to use "COLOR=YELLOW", for example (these went straight to red since that is the default non-green state).
FILE/DIR/PROC indeed have a different, positional, layout. I think a sensible strategy going forward might be to allow for tag= based matches throughout, and deprecating prior syntaxes over time. The parsing of it all is a little tricky due to the use of qualifiers in the code (once one is seen, the "per-type" rule processing ends), but the FILE/DIR checks should be easy.
Also, is there really a need for
DIR directory [color] [SIZE<maxsize] [SIZE>minsize] [TRACK]
since I'm pretty sure
FILE /path red TYPE=dir [SIZE<maxsize] [SIZE>minsize] [TRACK]
At the moment, directory data coming back only includes the size and it has a different format from the FILE responses, so it historically had a different format. It's also worth removing confusion about whether other checks would be useful for directory items (since they wouldn't).
That being said, there's an opportunity for improvement here, along with refactoring out some of the parsing code. Additionally, we can have logfetch begin returning more metadata about 'dir:' items rather than just size itself.
Both of these should be possible.
Regards, -jc