On Thu, 24 Jun 2010, Rainer Gerhards wrote: > David, all > > I suggest you have a look at some good comment I received on comp.text.xml: > > http://groups.google.com/group/comp.text.xml/browse_thread/thread/f1b96d132e3 > fdd8e# > > It is post #8 by Peter Flynn.
I replied to him to understand his concerns. > Also, I replied there with some extra information (should be post #10, but > does not yet show up on Google Groups). replying to this as well (basically, can't the DTD/schema be created if needed by looking through all available modules?) Daivd Lang > Thanks, > Rainer > >> -----Original Message----- >> From: [email protected] [mailto:rsyslog- >> [email protected]] On Behalf Of [email protected] >> Sent: Tuesday, June 22, 2010 1:52 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- >> XML? >> >> On Mon, 21 Jun 2010, Rainer Gerhards wrote: >> >>> Original: http://www.rsyslog.com/download/new_rsyslog.conf >>> XML: http://www.rsyslog.com/download/xml_rsyslog.conf >>> >>> I wonder if there is any good argument AGAINST using XML as >> "described" in >>> the sample. If nobody brings up a good argument, I'll very possibly >> will try >>> to take the XML road and begin to look what that takes in detail. Of >> course, >>> it would be helpful as well if you could make yourself heard if you >> like XML >>> format ;). >> >> XML can be a good format or a horrible format depending on how it's >> used. >> >> poorly used it is horribly verbose with lots of strange characters and >> rules. >> >> My policy towards XML files is to do the following >> >> don't use generic tags with a 'type' atribute, use more specific tags >> for >> system defined elements. >> >> if something can only take an option once, that should be an attribute >> to >> a tag >> >> if something can happen multiple times, it is a separate element >> >> example: >> >> instead of >> >> <input type="imtcp"> >> <!-- params holds module-specific config parameters --> >> <params >> listen="10514" >> ruleset="remote10514" >> /> >> </input> >> >> do >> >> <imtcp listen="10514" ruleset="remote10514" /> >> >> >> instead of >> >> <action id="dynfile" type="omfile"> >> <template format="%msg%\n" /> >> <params filetemplate="dynGen" /> >> </action> >> >> >> do >> >> <dynafile format="%msg%\n" filetemplate="dynGen" /> >> >> >> doing this keeps the file concise and lets you use the parser and file >> definition to help you check the syntax. It's a lot easier to say "the >> tag >> imtcp requires an attribute 'listen' and 'ruleset'" then it is to say >> that >> "the tag input requires the attribute 'listen' and 'ruleset' if the >> attribute 'type'=imtcp" >> >> >> for formats you have to do something like you suggested >> >> <template id="dynGen" format="/var/log/%fromhost%.log" /> >> >> because the id is user generated and will be used elsewhere >> >> although it may be that you can make this optional, if it's only used >> once, let you define it in the attribute >> >> i.e. >> >> do either >> >> <template id="dynGen" format="/var/log/%fromhost%.log" /> >> . >> . >> <dynafile format="%msg%\n" filetemplateid="dynGen" /> >> >> or >> >> <dynafile format="%msg%\n" filetemplate="/var/log/%fromhost%.log" /> >> >> redoing the example config file this way gives me >> >> >> <rsyslog_conf version="1"> >> re-written example by David Lang >> >> <global >> emitstartupmessages="off" >> /> >> >> <module id="imtcp" >> binary="imtcp" >> maxlisten="512" >> /> >> >> <imtcp listen="10515" ruleset="remote10515" /> >> >> <ruleset id="remote10514"> >> <rule> >> <omfile file="/var/log/catchall" /> >> <action use="dynfile" /> <!-- use action defined elsewhere >> --> >> </rule> >> </ruleset> >> >> <template id="dynGen" format="/var/log/%fromhost%.log" /> >> >> <action id="dynfile" /> >> this is a "stand-alone" action, to be used in more than one rule >> <omfile format="%msg%\n" filetemplate="dynGen" /> >> </action> >> >> <ruleset id="remote10514"> >> <rule pri="mail.*" > >> <omfile file="/var/log/remote10514" /> >> <action use="dynfile" /> >> </rule> >> <rule pri="mail.*" execonlyonce="5sec"> >> <udpfwd target="192.168.1.2:514" /> >> </rule> >> <rule previousfailed="yes" > >> <udpfwd target="192.168.1.3:514" /> >> </rule> >> <rule expr="$severity == 'error' and $msg contains 'Link 2'" > >> <ommail server="192.168.1.3" >> from="[email protected]" >> to="[email protected]" >> subject="###error "detected"###" >> /> >> </rule> >> </ruleset> >> </rsyslog_conf> >> >> note that with this approach everything important is in a tag, as such >> you >> can allow arbatrary text to be in the file outside of tags and just >> ignore >> it. This allows such text to be used as comments. >> >> note that I broke up one rule into two because it seemed to have two >> filters on it (pri="mail.*" and execonlyonce="5sec") >> >> David Lang >> _______________________________________________ >> 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 > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
