Mailing List Archive

Hi
I personnally find it not very usefull to put it politely. I'd rather
have every message and every time stamp for the sake of acuracy and
precision then an attempt from the software to be intelligent.

And if you get the benefit of a code clean up then double thumbs up from
me.

Regards

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: 18 March 2008 10:05
> To: rsyslog-users
> Subject: [rsyslog] Feedback requested "Last message logged n times"...
>
> Hi all,
>
> once again, I am in need for feedback. In order to be
> backwards-compatible with sysklogd, rsyslogd supported the "last
message
> repeated n times" message compression feature. However, this feature
is
> prone to causing user trouble. Some even think that it is a design
flaw
> (see this discussion on the loganalysis mailing list, this posting is
> probably a good entry point into a lengthy thread:
>
http://www.loganalysis.org/pipermail/loganalysis/2008-January/000547.htm
> l ).
>
> >From the rsyslog core engine point of view, "last message repeated n
> times" is quite costly in terms of code complexity and even
performance.
> There is a -e command line switch to turn it off, which most users
seem
> to do (and those that don't do it often seem to run into troubles).
>
> I am very tempted to DROP this feature from future builds. That would
> result in a great code complexity reduction (really, it takes a lot of
> effort...) and probably also rid us of a standard trouble spot.
However,
> it also means that its compression features are no longer available.
>
> Question now: does anybody actually need this feature? If so, why is
it
> good?
>
> Please provide feedback.
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Gerrard Geldenhuis
> Sent: Tuesday, March 18, 2008 11:15 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Feedback requested "Last message logged n
> times"...
>
> Hi
> I personnally find it not very usefull to put it politely. I'd rather
> have every message and every time stamp for the sake of acuracy and
> precision then an attempt from the software to be intelligent.
>
> And if you get the benefit of a code clean up then double thumbs up
> from
> me.

It's actually a *big* cleanup, because in order to support that feature,
we need to have

A) some background tick processing to flush the "repeated message" every
few (30 or 60) seconds (it prevents rsyslogd from being tickles - think
powertop, green IT and all that)

B) requires rsyslogd to keep multiple message objects alive for an
extended period of time, because the message object is needed for
comparison when a new message comes in. Among others, this prevents some
advanced flow control options which would depend on message destruction
*when the message is done* and not *when the next message arrives*.

C) [estimate] almost half the code of the main action calling loop, and
most of the complexity, is related to "last message repeated n times"

D) it prevents future end-to-end ACK capabilities (e.g. message is only
acked after being written to DB)

E) requires additional synchronization slowing down parallel processing
(granted, just a little bit, but...)

F) requires a "duplicate message capability" (some more code)

G) ... and probably a few more spots ...

I should have added this information to the initial message, too. These
are *my* primary drivers for the idea to get rid of it ;)

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: 18 March 2008 10:24
> To: rsyslog-users
> Subject: Re: [rsyslog] Feedback requested "Last message logged n
times"...
>
>
> It's actually a *big* cleanup, because in order to support that
feature,
> we need to have
>

I have asked the question on a local lug to get some more opinions. I
will post the results if any here.

Regards

On Tuesday 18 March 2008 12:12:02 pm Gerrard Geldenhuis wrote:
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: 18 March 2008 10:24
> > To: rsyslog-users
> > Subject: Re: [rsyslog] Feedback requested "Last message logged n
>
> times"...
>
> > It's actually a *big* cleanup, because in order to support that
>
> feature,
>
> > we need to have
>
> 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)
2. cleanness of logs (relative)

I'm thinking about forwarding discussion to fedora-devel :)
>
> Regards
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

>
> Question now: does anybody actually need this feature? If so, why is
> it
> good?
>
> Please provide feedback.
Hi all,

i think it's a biest of the past, remember those days where every
byte, every bit was really valuable? i remember programing on my C64
with byte values, because they could hold 256 states and it was just
using one (!, today i have to smile) byte ...

Or the times i had my first 40 MB Harddrive in one of my first
PC's ... i guess compressing a message which is exactly the same but
only of the timestamp was virtually a lifesaver those days ...

as far as i can say, from the bottom of my heart: get rid of it! disc-
space is cheap, i *love* consistant logs, personally i can not think
of any answer that would justify today a) log-file inconsinstency b) a
known trouble-spot and c) such a future-development-stopper as this
code seems to be (after reading your problems with this piece of code.

again, from me: go for it

best
Raimund

>
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog

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

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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] 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

> The only arguments for keeping the feature that I got on my lug was
the
> preservartion of disk/network IO.

Did you get any "feeling" of how important this is being considered?

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

This may (m-a-y it's far too early) be part of the flow control logic or
an exception detector or a rate-limiting feature...

Even for non-DoS cases it might be interesting to know who is sending
most messages... mmmh... maybe this points into a direction on how to
solve the need that is behind "last message repeated n times". Probably
that need is not even fully understood... mmmhh. More thoughts are
appreciated ;)

Rainer

>
> > The only arguments for keeping the feature that I got on my lug was
> the
> > preservartion of disk/network IO.
>
> Did you get any "feeling" of how important this is being considered?

I think the general feeling is: "don't care" or not important at all but
then I did not get many replies.

>
> Even for non-DoS cases it might be interesting to know who is sending
> most messages... mmmh... maybe this points into a direction on how to
> solve the need that is behind "last message repeated n times".
Probably
> that need is not even fully understood... mmmhh. More thoughts are
> appreciated ;)

When I asked about which applications has caused these type of repeat
messages one culprit mentioned was the kernel.

Regards

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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] 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

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: rsyslog-bounces at lists.adiscon.com
> [mailto:rsyslog-bounces at lists.adiscon.com] 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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > bounces at lists.adiscon.com] 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
>

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: rsyslog-bounces at lists.adiscon.com
> > [mailto:rsyslog-bounces at lists.adiscon.com] 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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > > bounces at lists.adiscon.com] 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

Pluging... well, that depends on the use cases. I am trying to identify
the actual use cases, so far I found the one with flooding/attack. The
problem is that the current logic can not be moved to a plugin because
it is right at the most inner workings of the engine. If we can identify
the actual use cases, things will probably be much easier to work with.

For example, I currently think that I can build an optional interface
that enables flood-controlling inputs and reducing messages if some
condition is given there. Note, however, that this is different from
current logic, where the flood control only applies to some outputs,
because the output decides if it can work with the repeated lines.

The bottom line is that I think there are some valid use cases, we just
don't know about them. The current implementation/idea is soooo bad
because we don't know what we really need to do. So identifying the
actual use cases is the priority and then doing a good design that
covers them.

I'll probably follow advise from the loganalysis mailing list and change
the default to not do the "last message..." processing. Then, see who
complains and if nobody does drop the feature.

It would also be extremely useful to know *why* people are unhappy (uses
cases ;)), instead of just knowing they are... Can you shed some light
on that?

Thanks for all your help,
Rainer

> -----Original Message-----
> From: Peter Vrabec [mailto:pvrabec at redhat.com]
> Sent: Tuesday, March 25, 2008 10:47 AM
> To: rsyslog at lists.adiscon.com
> Cc: Rainer Gerhards
> Subject: Re: [rsyslog] Feedback requested "Last message logged n
> times"...
>
> 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: rsyslog-bounces at lists.adiscon.com
> > > [mailto:rsyslog-bounces at lists.adiscon.com] 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: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > > > > bounces at lists.adiscon.com] 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
>