Hi folks, I talked with some people, and nobody is happy with removing this thing from rsyslog. Won't be possible to move it to separate plug-in?
On Monday 24 March 2008 10:25:55 pm Rainer Gerhards wrote: > Hi all, > > I now have a use case where the "last message..." prevents sources from > flooding syslog. But now on to a different use case: does someone > actually use this feature to reduce the size of files or network > traffic? Except, of course, in cases where there is a message flood due > to either attact or a misbehaving source (these need to be treated > differentely - I am right now after the *destination* message > compression...). > > Thanks, > Rainer > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Vrabec > > Sent: Tuesday, March 18, 2008 3:24 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Feedback requested "Last message > > logged n times"... > > > > On Tuesday 18 March 2008 02:11:15 pm Gerrard Geldenhuis wrote: > > > The only arguments for keeping the feature that I got on my > > > > lug was the > > > > > preservartion of disk/network IO. > > > > > > I think to prevent DOS attacks is a valid argument but as > > > > you said can > > > > > be easily circumvented by randomizing messages. > > > > I'm afraid it's not true in all cases. What if you do DOS > > attach not directly > > to do rsyslog, but via other daemon. In situation when you > > can't send message > > directly to syslog, but you can make some daemon generate > > message for you. > > This message would be probably always the same content. > > > > > To safeguard against dos attacks you could have a monitor > > > > that monitors > > > > > for extra ordinary amount of traffic and then generate a snmp trap. > > > Whether that should be a rsyslog plugin or part of other software is > > > open to debate. > > > > > > Regards > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:rsyslog- > > > > [EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > > > Sent: 18 March 2008 11:42 > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Feedback requested "Last message logged n > > > > > > times"... > > > > > > > Good discussion, thanks all :) ... some more points below ... > > > > > > > > > > I have asked the question on a local lug to get some more > > > > > > opinions. > > > > > > > I > > > > > > > > > > will post the results if any here. > > > > > > > > > > I did the same. :) > > > > > > > > > > The only arguments against removal I have received > > > > until now were: > > > > > 1. DoS (but nobody explained how) > > > > > > > > I think this is along the lines of making it easy to flood the log > > > > > > with > > > > > > > similar messages. If that's the case, I think it is a (too) weak > > > > argument because an attacker could easily include a random pattern > > > > inside the message. > > > > > > > > HOWEVER, the current logic indeed prevents flooding the > > > > log from equal > > > > > > messages, e.g. if a process runs wild. > > > > > > > > > 2. cleanness of logs (relative) > > > > > > > > > > I'm thinking about forwarding discussion to fedora-devel :) > > > > > > > > Excellent. > > > > > > > > Maybe there are also alternatives to the current > > > > behavior, something > > > > > in > > > > > > > between. Right now, the core engine does this, so the reduction > > > > capability is inherent to every action (except if an action > > > > > > specifically > > > > > > > forbids it, because it can not intelligently handle it - > > > > e.g. database > > > > > > writers). So it applies to forwarding, snmp, whatever, ... One > > > > alternative would be to remove it from the core engine and move it > > > > > > into > > > > > > > the *file write* output plugin (omfile). This has its > > > > subtleties, too, > > > > > > so I don't like to take that approach lightly. Plus, it than means > > > > > > that > > > > > > > the network may become spammed. I think one core requirement is to > > > > > > find > > > > > > > people who actually *intentionally* use this feature and > > > > ask for their > > > > > > reasoning. That will probably be the best way to tell us > > > > if its really > > > > > > needed. And, of course, we need to weigh the negative > > > > effects of it > > > > > > against these con-points. > > > > > > > > Rainer > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
