Summary: On my setup the ossec-logtest application does not show the
child decoder's name either.
To me this would appear to be an omission in the logtest program, but
I can't say for sure. Maybe a "child decoder" entry could be added to
the output.

Ramble: It appears that using the <use_own_name> option will allow
rules to fire on the child decoder's name. In my quick tests, I was
able to get the <extra_data> information in my test child decoder
through logtest, but it still appeared under the parent decoder's
name.
I was also able to write rules with the name of the child decoder
(again using the use_own_name) option, including using the extra_data
information. Without the use_own_name option these rules did not work.

On Tue, Sep 29, 2009 at 8:50 AM, dthfoo <[email protected]> wrote:
>
> Hey!
>
> I am trying to write a custom decoder for our checkpoint logs and am
> running into difficulty trying to get parent->child decoders working.
>
> I have ended up writing a test decoder as follows;
>
> <decoder name="test-syslog">
>  <prematch>^test</prematch>
> </decoder>
>
> <decoder name="test-syslog-remainder">
>  <parent>test-syslog</parent>
>  <use_own_name>true</use_own_name>
>  <prematch offset="after_parent">\.*</prematch>
> </decoder>
>
> Then I used "logtest" to test the following 2 inputs;
> "test"
> "test test"
>
> I expected that the first input would be matched to the parent decoder
> and the second input to the child. Instead I get the following;
>
> 2009/09/29 13:41:55 ossec-testrule: INFO: Started (pid: 31027).
> ossec-testrule: Type one log per line.
>
> test
>
>
> **Phase 1: Completed pre-decoding.
>       full event: 'test'
>       hostname: 'plukinfra1'
>       program_name: '(null)'
>       log: 'test'
>
> **Phase 2: Completed decoding.
>       decoder: 'test-syslog'
> test test
>
>
> **Phase 1: Completed pre-decoding.
>       full event: 'test test'
>       hostname: 'plukinfra1'
>       program_name: '(null)'
>       log: 'test test'
>
> **Phase 2: Completed decoding.
>       decoder: 'test-syslog'
>
>
> Is my thinking faulty or does the problem lie somewhere else?
>
> Cheers,
>
> Dan.
>

Reply via email to