> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Aaron Wiebe
> Sent: Tuesday, June 22, 2010 3:21 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Next Try ;) NEW rsyslog.conf format -- XML?
>
> On Tue, Jun 22, 2010 at 6:23 AM, Rainer Gerhards
> <[email protected]> wrote:
> > The sample is available at
> >
> > http://www.rsyslog.com/download/xml_params_rsyslog.conf
>
> I have to admit, having not viewed it in something with context
> highlighting, I am somewhat agreeing with David. This is where my
> aversion to XML comes out....
These were my initial concerns - as I said, I don't like XML config files ;)
> but it achieves the suggestions I put
> forward. A little bit of my own suggestion, based on what is already
> there... I would certainly prefer something like this:
>
I have to admit I like David's approach very much. It is clean, easy to read
and not more verbose than necessary.
>
> <?xml version="1.0"?>
> <!--DOCTYPE config SYSTEM "config-v00.dtd"-->
> <config application="rsyslog" version="1" YYYY-MM-DD="2010-06-21">
>
>
>
> <!---
> Define modules in their own scope with no module-specific tags,
> as they will define their tags at load time
> --->
> <modules>
> <path>/path/to/modules</path>
> <module id=imtcp />
> <module id=imudp />
> <module id=omruleset />
We need to have a capability to load modules from non-standard pathes (if for
nothing else, then at least to enable me to maintain a test suite). But that
could be done with something like
<module id=omruleset binary="/path/to/omtestingruleset"/>
> </modules>
>
> <!---
> Then configure the modules
> --->
> <modconf id="imtcp">
> <maxlisten>512</maxlisten>
> <maxsession>8192</maxsession>
> </modconf>
Wouldn't it be more natural to have to config together with the module def?
On the other hand, this could be handy from an app developer POV -- but also
from a user's POV?
>
>
> <!-- imtcp has registered itself as an input type, and has added
> accepted nodes to the input field -->
> <input type="imtcp" name="im10514">
> <listen>
> <port>10514</port>
> <bind>123.123.123.123</bind>
> </listen>
> <!--- inputs need a sink or output to direct their content
> to... also, inline comments should be permitted -->
> <!--- perhaps omruleset has registered "ruleset" as an
> acceptable sink type? --->
> <sink type="ruleset">remote10514</sink>
> </input>
>
> <input type="imtcp"><listen><port>10515</port></listen><sink
> type=ruleset>remote10515</sink></input>
>
> <sink type="ruleset">
> <rule>
> <!-- no filter specified -- all messages! -->
> <action type="omfile">
> <file>/var/log/catchall</file>
> <sync />
> </action>
> <action use="dynfile" /> <!-- use action
> defined elsewhere -->
> </rule>
> </sink>
>
>
> Granted - I go in a few different directions here, but I'm just
> brainstorming.
And that's appreciated!
> A few things:
> 1. Modules define types - the top levels should be
> module-independent... ie, no <ruleset> if omruleset is required for
> it.
> 2. I like the concept of a sink into which an input dumps its data -
> that was something you mentioned in an earlier post. I went with it,
> not because I think its the best term, but because it worked in this
> case.
I am still not convinced we absolutely need it, but I am open to explore the
need. We just need to keep on our mind that it adds both complexity and
(light) performance overhead.
Rainer
> Thoughts?
>
> -Aaron
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
