On Mon, 16 Nov 2009, RB wrote:
On Mon, Nov 16, 2009 at 12:56, Rainer Gerhards <[email protected]> wrote:
I fail to see the interface you envision. Could you elaborate a bit? That
would be most useful.
Certainly. Some time ago, I expressed interest in writing a 'running
checksum' module but had run into issues with a lack of
state-maintenance in the output modules that helped my lack of time
drop the issue. At the time, you'd hinted at a 'filter' module API
that would (I presumed) fit somewhere between input and output and
eventually address that use case. Such a layer could perform message
modification, rate limiting, ACL enforcement, and so on. Perhaps this
has already been addressed, since I've not kept as close of tabs on
the development head as I'd like.
Ideally, I think it would be a very interesting step to be able to
'stack' syslog modules to define the path a given set of messages take
through the collector. Something akin to the Linux iptables concept,
where a basic high-speed framework is laid out with a well-defined
order and an API that enables administrators to elect how specific
run-time modules interact within the stack. That's less of a request
and more of a pipe dream, and is definitely influenced by the half
network security hat I wear.
hmm, the recent ability to have secondary queues would allow this to fit
in very nicely as a filter for what to do when moving messages between the
queues.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
