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. 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
