From david at lang.hm  Thu Dec  1 04:58:30 2011
From: david at lang.hm (david at lang.hm)
Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>


I'm happy to see this, I was just reading up on SCM_CREDENTIALS and 
thinking that it should be fairly easy to add these sorts of things to 
existing software.

are these values available as named properties when crafting a format 
string?

Also, while it will hurt existing parsers, this data needs to be at the 
beginning of the line, before any user generated input, so that it can't 
be faked.

because of existing parsers, this probably means that we need an option to 
deal with this, or possibly a couple of options

1. should rsyslog add this to the %msg% property when the line is read in 
by imsock, leaving logs from other sources alone?

having this would probaly make things wasy for many people, but defeats 
the value of the trusted properties as other sources could add text to the 
logs that looks like it is the trusted properties.

Rsyslog already has %inputname% to say where the log came from. this is 
seldom used, but if it is used, it would probably make sense to use these 
new properties the same way.

2. add an output format (or two, one for local, one for remote) that 
inserts these properties at the beginning of the line for every message, 
even if it comes from a source that doesn't provide the data so that user 
provided input cannot pretend to provide these fields. Yes, I know that 
users can create their own output format, but if Rsyslog defines one, it 
is far more likely that people will use it, and if they do Rsyslog can 
define a parser module that populates these fileds from an incomeing 
message over the network (while providing the appropriate value in 
%inputname% that says that the message came over the network and so the 
message could have been faked)

David Lang


  On Tue, 29 Nov 2011, Rainer Gerhards wrote:

> Date: Tue, 29 Nov 2011 13:05:40 +0100
> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
> 
> Hi all,
>
> I thought I'd buy in on one of journald's better ideas, here are the details:
>
> http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
>
> I will see that I can release today, but would like to merge into v6, if
> possible... Expect an announcement soon. I'd also like to know what you think
> about this feature.
>
> Thanks,
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From rgerhards at hq.adiscon.com  Thu Dec  1 08:33:49 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 1 Dec 2011 08:33:49 +0100
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281575@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Thursday, December 01, 2011 4:59 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] trusted (fields/properties) now also in rsyslog
> 
> 
> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
> thinking that it should be fairly easy to add these sorts of things to
> existing software.
> 
> are these values available as named properties when crafting a format
> string?

Kind of... you need to pull them of via a regex :( Of course, that's not the
real answer. It's important to know that this effort is experimental. I
wanted to get some feedback (thanks!). A final implementation will definitely
be different. But before doing that, I want to play a bit around (plus some
core changes are required to make it really decent, and there performance is
a big issue. This probably needs to be done ultimately in v6, as the core
there already uses the (CEE) field set.
 
> Also, while it will hurt existing parsers, this data needs to be at the
> beginning of the line, before any user generated input, so that it
> can't
> be faked.

Actually CEE & RFC5424 structured data is the correct solution.
Regardig faking: what really helps is if the emitter digitally signs the
message. Otherwise you can always fake. I hope to have some opportunity to
look into this soon. But as you probably know there is so much going on right
now...

> 
> because of existing parsers, this probably means that we need an option
> to
> deal with this, or possibly a couple of options

RFC5424 and CEE will take care oft hat

> 
> 1. should rsyslog add this to the %msg% property when the line is read
> in
> by imsock, leaving logs from other sources alone?
> 
> having this would probaly make things wasy for many people, but defeats
> the value of the trusted properties as other sources could add text to
> the
> logs that looks like it is the trusted properties.

If they are trusted, we must be sure that they are correct. So we can add
fields, yes, but only where we can not be sure they are not faked. So for
each input this needs to be checked individually. All network received logs
for that reason cannot be trusted (except for e.g. RFC5425 provided remote
host identity via cert). There is an awful lot to do in this regard. Journald
does offer vapourware in this regard, but no cryptographically sound
solution. It's more than sticking a few fields here and there (I know you
know ;)).

> 
> Rsyslog already has %inputname% to say where the log came from. this is
> seldom used, but if it is used, it would probably make sense to use
> these
> new properties the same way.
> 
> 2. add an output format (or two, one for local, one for remote) that
> inserts these properties at the beginning of the line for every
> message,
> even if it comes from a source that doesn't provide the data so that
> user
> provided input cannot pretend to provide these fields. Yes, I know that
> users can create their own output format, but if Rsyslog defines one,
> it
> is far more likely that people will use it, and if they do Rsyslog can
> define a parser module that populates these fileds from an incomeing
> message over the network (while providing the appropriate value in
> %inputname% that says that the message came over the network and so the
> message could have been faked)
> 

Again CEE and RFC5424...

Actually, I was tempted to add the functionality as RFC5424, but it's in it's
infancy and I would immediately have gotten the feedback "sure, some obscure
implementation of syslog provides this, but nobody uses that". So I stuck it
right in the message...

rg

> David Lang
> 
> 
>   On Tue, 29 Nov 2011, Rainer Gerhards wrote:
> 
> > Date: Tue, 29 Nov 2011 13:05:40 +0100
> > From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> > Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
> >
> > Hi all,
> >
> > I thought I'd buy in on one of journald's better ideas, here are the
> details:
> >
> > http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
> >
> > I will see that I can release today, but would like to merge into v6,
> if
> > possible... Expect an announcement soon. I'd also like to know what
> you think
> > about this feature.
> >
> > Thanks,
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From mike at hales.ws  Thu Dec  1 16:26:47 2011
From: mike at hales.ws (Michael Hale)
Date: Thu, 1 Dec 2011 10:26:47 -0500
Subject: [rsyslog] rsyslog 5.6.5 outchannel writing to deleted file
Message-ID: <CAGF8HbrEh0HqumM2nibqvj_nzS_iWdGYv7=foX0FSxFp0gvaUg@mail.gmail.com>

Hi, I have noticed that rsyslog is continuing to write to old inodes
after executing the action in my outchannel. It also writes to the new
file, and eventually I end up with the following in lsof:

rsyslogd   3181     syslog   18w      REG               8,16
971174829   11698187 /mnt/log/all
rsyslogd   3181     syslog   16w      REG               8,16
1074997249   11698190 /mnt/log/all (deleted)

Here is my rsyslog config:

$Template Normed, "%timereported:::date-rfc3339% %fromhost-ip%
%syslogfacility-text%.%syslogpriority-text% %syslogtag%
%structured-data% %hostname%%msg:::sp-if-no-1st-sp
%%msg%\n"
$OutChannel all,/mnt/log/all,1073741824,/usr/local/bin/logrotate /mnt/log/all

## Receive messages over relp
:inputname, isequal, "imrelp" $all;Normed
& @@localhost:9994;Normed
& ~

$ModLoad imrelp
$InputRELPServerRun 9996

# Syslog over TCP listeners
$ModLoad imtcp

## Listen on 9998 for messages.
$RuleSet imtcp
:inputname, isequal, "imtcp" $all;Normed
& @@localhost:9994;Normed
& ~

$InputTCPServerBindRuleset imtcp
$InputTCPMaxSessions 2000
$InputTCPServerRun 9998

## Listen on 9999 for messages.
$RuleSet imtcp
:inputname, isequal, "imtcp" $all;Normed
& @@localhost:9994;Normed
& ~

$InputTCPServerBindRuleset imtcp
$InputTCPMaxSessions 2000
$InputTCPServerRun 9999


Here is the logrotate script:

#!/bin/bash

log="$1"
keep="3"

/usr/bin/savelog -lpnc "$keep" -m 444 "$log"

From emmanuel.jooris at gmail.com  Fri Dec  2 08:12:29 2011
From: emmanuel.jooris at gmail.com (Emmanuel JOORIS)
Date: Fri, 02 Dec 2011 08:12:29 +0100
Subject: [rsyslog] Modifying the Severity with Property replacer
Message-ID: <1322809949.8376.5.camel@LinTaff>

Hello,
I need some help to customizing my rsyslog.
I have some logs that i want to change the severity
The original Severity is Notice
The Syslogtag is openvpn
The Message is XXXX_Home/89.XXX.XXX.XXX:XX345 MULTI: Learn:
192.168.XXX.2 -> XXXX_Parents/93.XXX.XXX.XXX:XX311

I wanti to change the severity of this type of message (the common is
"MULTI: Learn:")

Anyone can help me, i don't understand the syntax of the property
replacer and don't even know if this is possible.

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111202/b93958be/attachment.pgp>

From david at lang.hm  Fri Dec  2 16:25:21 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 2 Dec 2011 07:25:21 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281575@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA7281575@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112020712100.30627@asgard.lang.hm>

On Thu, 1 Dec 2011, Rainer Gerhards wrote:

>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>>
>>
>> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
>> thinking that it should be fairly easy to add these sorts of things to
>> existing software.
>>
>> are these values available as named properties when crafting a format
>> string?
>
> Kind of... you need to pull them of via a regex :( Of course, that's not the
> real answer. It's important to know that this effort is experimental. I
> wanted to get some feedback (thanks!). A final implementation will definitely
> be different. But before doing that, I want to play a bit around (plus some
> core changes are required to make it really decent, and there performance is
> a big issue. This probably needs to be done ultimately in v6, as the core
> there already uses the (CEE) field set.

that mkes it harder to deal with them, would it be relativly easy to make 
them be $! parameters or something (in v6 I guess)

>> Also, while it will hurt existing parsers, this data needs to be at the
>> beginning of the line, before any user generated input, so that it
>> can't
>> be faked.
>
> Actually CEE & RFC5424 structured data is the correct solution.
> Regardig faking: what really helps is if the emitter digitally signs the
> message. Otherwise you can always fake. I hope to have some opportunity to
> look into this soon. But as you probably know there is so much going on right
> now...

I was thinking of protection much milder than digital signatures (80-20 
rule)

if you have rsyslog configured to always put the trusted properties in 
front of any user supplied input (except for the hostname and syslog tag 
fields, which contain no spaces so they can't be mistaked for these 
properties) then it's impossible for user input to fake the tags and 
confuse you, with your current scheme of appending it to the message, you 
have to watch out for a similar contruct existing earlier in the message 
(and it's easier to find the first instance of something than the last 
instance)

>>
>> because of existing parsers, this probably means that we need an option
>> to
>> deal with this, or possibly a couple of options
>
> RFC5424 and CEE will take care oft hat
>
>>
>> 1. should rsyslog add this to the %msg% property when the line is read
>> in
>> by imsock, leaving logs from other sources alone?
>>
>> having this would probaly make things wasy for many people, but defeats
>> the value of the trusted properties as other sources could add text to
>> the
>> logs that looks like it is the trusted properties.
>
> If they are trusted, we must be sure that they are correct. So we can add
> fields, yes, but only where we can not be sure they are not faked. So for
> each input this needs to be checked individually. All network received logs
> for that reason cannot be trusted (except for e.g. RFC5425 provided remote
> host identity via cert). There is an awful lot to do in this regard. Journald
> does offer vapourware in this regard, but no cryptographically sound
> solution. It's more than sticking a few fields here and there (I know you
> know ;)).

again, yes and no, either you trust the remote sender or you don't. If you 
don't, then the fact that the remote sender signed something doesn't help 
you much, if you do then having the fields in place where they can't be 
confused with something that an application sent is pretty darn good (yes, 
it may be possible for the application to make a network connection and 
pretend to be rsyslog, that's something that you need transport layer 
security to protect, but that's still much cheaper than signing each 
message.

>>
>> Rsyslog already has %inputname% to say where the log came from. this is
>> seldom used, but if it is used, it would probably make sense to use
>> these
>> new properties the same way.
>>
>> 2. add an output format (or two, one for local, one for remote) that
>> inserts these properties at the beginning of the line for every
>> message,
>> even if it comes from a source that doesn't provide the data so that
>> user
>> provided input cannot pretend to provide these fields. Yes, I know that
>> users can create their own output format, but if Rsyslog defines one,
>> it
>> is far more likely that people will use it, and if they do Rsyslog can
>> define a parser module that populates these fileds from an incomeing
>> message over the network (while providing the appropriate value in
>> %inputname% that says that the message came over the network and so the
>> message could have been faked)
>>
>
> Again CEE and RFC5424...
>
> Actually, I was tempted to add the functionality as RFC5424, but it's in it's
> infancy and I would immediately have gotten the feedback "sure, some obscure
> implementation of syslog provides this, but nobody uses that". So I stuck it
> right in the message...

understood.

that's why I was thinking in terms of creating properties that could then 
be used in output format strings. that way you aren't dictating the 
format, just providing the information for the admin to use how they want.

David Lang
>
> rg
>
>> David Lang
>>
>>
>>   On Tue, 29 Nov 2011, Rainer Gerhards wrote:
>>
>>> Date: Tue, 29 Nov 2011 13:05:40 +0100
>>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
>>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
>>> To: rsyslog at lists.adiscon.com
>>> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
>>>
>>> Hi all,
>>>
>>> I thought I'd buy in on one of journald's better ideas, here are the
>> details:
>>>
>>> http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
>>>
>>> I will see that I can release today, but would like to merge into v6,
>> if
>>> possible... Expect an announcement soon. I'd also like to know what
>> you think
>>> about this feature.
>>>
>>> Thanks,
>>> Rainer
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From pchacin at inteleye.com  Fri Dec  2 19:52:11 2011
From: pchacin at inteleye.com (Pablo Chacin)
Date: Fri, 02 Dec 2011 19:52:11 +0100
Subject: [rsyslog] Two basic questions for using rsyslog in an application
Message-ID: <4ED91E5B.3050505@inteleye.com>

Hi all

I'm considering using rsyslog to transport messages from my application 
in reliable way.
This messages will collected on each machine by a local rsyslog 
component and delivered
to a remote rsyslog which will serve as a collector.

My  main questions now are:
1. Which is the most efficient and reliable way to send messages from 
the application to a
local rsyslog deamon running in the same machine. I need this to be in 
"real time", so
files are not an option.

2. haven't seen any input module supporting pipes or other form of IPC 
besides sockets.
Is this because a design limitation or just because no one has ever had 
this requirement
(I find this really hard to believe!)


3. Can I run the rsyslog service "embedded" in my application. That is, 
launch it from the
application? The idea is that running it a separate process will force 
me to monitor it which
may introduce more complexity in the design.

Thanks in advance



From david at lang.hm  Fri Dec  2 20:03:06 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 2 Dec 2011 11:03:06 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
Message-ID: <alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm>

one other thing that would be useful to get would be what cgroup the pid 
is in.

Since systemd starts each 'service' in it's own cgroup, with that 
information (and these things in a property), it would be possible to use 
a dynafile definition to log each service to a separate file.

David Lang

On Wed, 30 Nov 2011, david at lang.hm wrote:

> Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
> From: david at lang.hm
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: Re: [rsyslog] trusted (fields/properties) now also in rsyslog
> 
>
> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and thinking 
> that it should be fairly easy to add these sorts of things to existing 
> software.
>
> are these values available as named properties when crafting a format string?
>
> Also, while it will hurt existing parsers, this data needs to be at the 
> beginning of the line, before any user generated input, so that it can't be 
> faked.
>
> because of existing parsers, this probably means that we need an option to 
> deal with this, or possibly a couple of options
>
> 1. should rsyslog add this to the %msg% property when the line is read in by 
> imsock, leaving logs from other sources alone?
>
> having this would probaly make things wasy for many people, but defeats the 
> value of the trusted properties as other sources could add text to the logs 
> that looks like it is the trusted properties.
>
> Rsyslog already has %inputname% to say where the log came from. this is 
> seldom used, but if it is used, it would probably make sense to use these new 
> properties the same way.
>
> 2. add an output format (or two, one for local, one for remote) that inserts 
> these properties at the beginning of the line for every message, even if it 
> comes from a source that doesn't provide the data so that user provided input 
> cannot pretend to provide these fields. Yes, I know that users can create 
> their own output format, but if Rsyslog defines one, it is far more likely 
> that people will use it, and if they do Rsyslog can define a parser module 
> that populates these fileds from an incomeing message over the network (while 
> providing the appropriate value in %inputname% that says that the message 
> came over the network and so the message could have been faked)
>
> David Lang
>
>
> On Tue, 29 Nov 2011, Rainer Gerhards wrote:
>
>> Date: Tue, 29 Nov 2011 13:05:40 +0100
>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
>> To: rsyslog at lists.adiscon.com
>> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
>> 
>> Hi all,
>> 
>> I thought I'd buy in on one of journald's better ideas, here are the 
>> details:
>> 
>> http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
>> 
>> I will see that I can release today, but would like to merge into v6, if
>> possible... Expect an announcement soon. I'd also like to know what you 
>> think
>> about this feature.
>> 
>> Thanks,
>> Rainer
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> 
>

From rgerhards at hq.adiscon.com  Fri Dec  2 21:30:27 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 2 Dec 2011 21:30:27 +0100
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
	<alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Friday, December 02, 2011 8:03 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] trusted (fields/properties) now also in rsyslog
> 
> one other thing that would be useful to get would be what cgroup the
> pid
> is in.

It's actually not that hard to add additional properties (have a look at
imuxsock.c and you'll see).
> 
> Since systemd starts each 'service' in it's own cgroup, with that
> information (and these things in a property), it would be possible to
> use
> a dynafile definition to log each service to a separate file.
> 
I think it would make sense to see that these properties are available in the
engine at large, this means rsyslog v6 and a bit of work (but not too much).

However, from the discussion I have learned that folks seem to find
log-hash-chaining useful, albeit it's limited security. Thus I have begun to
write a tool that handles this. It's an experiment outside of rsyslog, but
could be moved into omfile once it is sufficient mature. In the mean time
omprog can be used to call the tool directly. I'd like to mature it to a
point where it is cryptographically sound. I have a working hash
writer/verifier in my lab, but so far without append mode. I think I'll focus
on this work first.

Rainer

> David Lang
> 
> On Wed, 30 Nov 2011, david at lang.hm wrote:
> 
> > Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
> > From: david at lang.hm
> > To: rsyslog-users <rsyslog at lists.adiscon.com>
> > Subject: Re: [rsyslog] trusted (fields/properties) now also in
> rsyslog
> >
> >
> > I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
> thinking
> > that it should be fairly easy to add these sorts of things to
> existing
> > software.
> >
> > are these values available as named properties when crafting a format
> string?
> >
> > Also, while it will hurt existing parsers, this data needs to be at
> the
> > beginning of the line, before any user generated input, so that it
> can't be
> > faked.
> >
> > because of existing parsers, this probably means that we need an
> option to
> > deal with this, or possibly a couple of options
> >
> > 1. should rsyslog add this to the %msg% property when the line is
> read in by
> > imsock, leaving logs from other sources alone?
> >
> > having this would probaly make things wasy for many people, but
> defeats the
> > value of the trusted properties as other sources could add text to
> the logs
> > that looks like it is the trusted properties.
> >
> > Rsyslog already has %inputname% to say where the log came from. this
> is
> > seldom used, but if it is used, it would probably make sense to use
> these new
> > properties the same way.
> >
> > 2. add an output format (or two, one for local, one for remote) that
> inserts
> > these properties at the beginning of the line for every message, even
> if it
> > comes from a source that doesn't provide the data so that user
> provided input
> > cannot pretend to provide these fields. Yes, I know that users can
> create
> > their own output format, but if Rsyslog defines one, it is far more
> likely
> > that people will use it, and if they do Rsyslog can define a parser
> module
> > that populates these fileds from an incomeing message over the
> network (while
> > providing the appropriate value in %inputname% that says that the
> message
> > came over the network and so the message could have been faked)
> >
> > David Lang
> >
> >
> > On Tue, 29 Nov 2011, Rainer Gerhards wrote:
> >
> >> Date: Tue, 29 Nov 2011 13:05:40 +0100
> >> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> >> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> >> To: rsyslog at lists.adiscon.com
> >> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
> >>
> >> Hi all,
> >>
> >> I thought I'd buy in on one of journald's better ideas, here are the
> >> details:
> >>
> >> http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
> >>
> >> I will see that I can release today, but would like to merge into
> v6, if
> >> possible... Expect an announcement soon. I'd also like to know what
> you
> >> think
> >> about this feature.
> >>
> >> Thanks,
> >> Rainer
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> http://www.rsyslog.com/professional-services/
> >>
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From david at lang.hm  Sat Dec  3 08:37:30 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 2 Dec 2011 23:37:30 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
	<alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm>

On Fri, 2 Dec 2011, Rainer Gerhards wrote:

>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>> Sent: Friday, December 02, 2011 8:03 PM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] trusted (fields/properties) now also in rsyslog
>>
>> one other thing that would be useful to get would be what cgroup the
>> pid
>> is in.
>
> It's actually not that hard to add additional properties (have a look at
> imuxsock.c and you'll see).
>>
>> Since systemd starts each 'service' in it's own cgroup, with that
>> information (and these things in a property), it would be possible to
>> use
>> a dynafile definition to log each service to a separate file.
>>
> I think it would make sense to see that these properties are available in the
> engine at large, this means rsyslog v6 and a bit of work (but not too much).
>
> However, from the discussion I have learned that folks seem to find
> log-hash-chaining useful, albeit it's limited security. Thus I have begun to
> write a tool that handles this. It's an experiment outside of rsyslog, but
> could be moved into omfile once it is sufficient mature. In the mean time
> omprog can be used to call the tool directly. I'd like to mature it to a
> point where it is cryptographically sound. I have a working hash
> writer/verifier in my lab, but so far without append mode. I think I'll focus
> on this work first.

this makes sense.

the hash creator should periodically (config option or command line 
option) write a log message that says what the most recent hash is so that 
the hash can be sent off somewhere else. I don't know how much info should 
be provided along with the hash (probably at least the timestamp, possibly 
the beginning of the line to make it easy to find)

as you pointed out, hashing by itself does no good, the hashes need to be 
sent elsewhere. rsyslog has the ability to send things elsewhere based on 
what they are, so a distictive log message that can easily be filtered to 
send out should do the job.

David Lang

> Rainer
>
>> David Lang
>>
>> On Wed, 30 Nov 2011, david at lang.hm wrote:
>>
>>> Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
>>> From: david at lang.hm
>>> To: rsyslog-users <rsyslog at lists.adiscon.com>
>>> Subject: Re: [rsyslog] trusted (fields/properties) now also in
>> rsyslog
>>>
>>>
>>> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
>> thinking
>>> that it should be fairly easy to add these sorts of things to
>> existing
>>> software.
>>>
>>> are these values available as named properties when crafting a format
>> string?
>>>
>>> Also, while it will hurt existing parsers, this data needs to be at
>> the
>>> beginning of the line, before any user generated input, so that it
>> can't be
>>> faked.
>>>
>>> because of existing parsers, this probably means that we need an
>> option to
>>> deal with this, or possibly a couple of options
>>>
>>> 1. should rsyslog add this to the %msg% property when the line is
>> read in by
>>> imsock, leaving logs from other sources alone?
>>>
>>> having this would probaly make things wasy for many people, but
>> defeats the
>>> value of the trusted properties as other sources could add text to
>> the logs
>>> that looks like it is the trusted properties.
>>>
>>> Rsyslog already has %inputname% to say where the log came from. this
>> is
>>> seldom used, but if it is used, it would probably make sense to use
>> these new
>>> properties the same way.
>>>
>>> 2. add an output format (or two, one for local, one for remote) that
>> inserts
>>> these properties at the beginning of the line for every message, even
>> if it
>>> comes from a source that doesn't provide the data so that user
>> provided input
>>> cannot pretend to provide these fields. Yes, I know that users can
>> create
>>> their own output format, but if Rsyslog defines one, it is far more
>> likely
>>> that people will use it, and if they do Rsyslog can define a parser
>> module
>>> that populates these fileds from an incomeing message over the
>> network (while
>>> providing the appropriate value in %inputname% that says that the
>> message
>>> came over the network and so the message could have been faked)
>>>
>>> David Lang
>>>
>>>
>>> On Tue, 29 Nov 2011, Rainer Gerhards wrote:
>>>
>>>> Date: Tue, 29 Nov 2011 13:05:40 +0100
>>>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
>>>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
>>>> To: rsyslog at lists.adiscon.com
>>>> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
>>>>
>>>> Hi all,
>>>>
>>>> I thought I'd buy in on one of journald's better ideas, here are the
>>>> details:
>>>>
>>>> http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html
>>>>
>>>> I will see that I can release today, but would like to merge into
>> v6, if
>>>> possible... Expect an announcement soon. I'd also like to know what
>> you
>>>> think
>>>> about this feature.
>>>>
>>>> Thanks,
>>>> Rainer
>>>> _______________________________________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>>> http://www.rsyslog.com/professional-services/
>>>>
>>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From david at lang.hm  Sat Dec  3 08:47:13 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 2 Dec 2011 23:47:13 -0800 (PST)
Subject: [rsyslog] calling DBAs. need help replicating 'journal feature'
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm>
	<alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112022337530.12746@asgard.lang.hm>

On Fri, 2 Dec 2011, Rainer Gerhards wrote:

>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>
> However, from the discussion I have learned that folks seem to find
> log-hash-chaining useful, albeit it's limited security. Thus I have begun to
> write a tool that handles this. It's an experiment outside of rsyslog, but
> could be moved into omfile once it is sufficient mature. In the mean time
> omprog can be used to call the tool directly. I'd like to mature it to a
> point where it is cryptographically sound. I have a working hash
> writer/verifier in my lab, but so far without append mode. I think I'll focus
> on this work first.

One other thing that would be useful, but requires DBA database SQL 
skills, would be to define the appropriate stored procedures, schema, etc 
to do the 'compression' (i.e. normalization) that the journal is claiming.

basically, rsyslog should invoke the SQL command 
normalized_insert("$timestamp","$hostname","$fromhost-ip","$programname","$msg")
and the database stored procedure should do the lookkup/addition work 
needed to replace hostname, fromhost-ip, programname with an int value (to 
be extended to additional values as we get trusted properties, etc in 
place)

I'm enough of a DBA to modify a working example to extend it to more 
fields, and to know that this is doable, but implementing it would take a 
significant amount of time for me and I strongly suspect that a good DBA 
could make this pretty trivial

ideally the command would be able to take multiple sets of log entries as 
a single transaction, but that's a further optimization after we get a 
single one added.

David Lang

From rgerhards at hq.adiscon.com  Sat Dec  3 15:33:41 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Sat, 3 Dec 2011 15:33:41 +0100
Subject: [rsyslog] calling DBAs. need help replicating 'journal feature'
In-Reply-To: <alpine.DEB.2.02.1112022337530.12746@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112022337530.12746@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815A3@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Saturday, December 03, 2011 8:47 AM
> To: rsyslog-users
> Subject: [rsyslog] calling DBAs. need help replicating 'journal
> feature'
> 
> On Fri, 2 Dec 2011, Rainer Gerhards wrote:
> 
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> >
> > However, from the discussion I have learned that folks seem to find
> > log-hash-chaining useful, albeit it's limited security. Thus I have
> begun to
> > write a tool that handles this. It's an experiment outside of
> rsyslog, but
> > could be moved into omfile once it is sufficient mature. In the mean
> time
> > omprog can be used to call the tool directly. I'd like to mature it
> to a
> > point where it is cryptographically sound. I have a working hash
> > writer/verifier in my lab, but so far without append mode. I think
> I'll focus
> > on this work first.
> 
> One other thing that would be useful, but requires DBA database SQL
> skills, would be to define the appropriate stored procedures, schema,
> etc
> to do the 'compression' (i.e. normalization) that the journal is
> claiming.
> 
> basically, rsyslog should invoke the SQL command
> normalized_insert("$timestamp","$hostname","$fromhost-
> ip","$programname","$msg")
> and the database stored procedure should do the lookkup/addition work
> needed to replace hostname, fromhost-ip, programname with an int value
> (to
> be extended to additional values as we get trusted properties, etc in
> place)
> 
> I'm enough of a DBA to modify a working example to extend it to more
> fields, and to know that this is doable, but implementing it would take
> a
> significant amount of time for me and I strongly suspect that a good
> DBA
> could make this pretty trivial
> 
> ideally the command would be able to take multiple sets of log entries
> as
> a single transaction, but that's a further optimization after we get a
> single one added.

Just as a side-note I would suggest to have a look at systems like MongoDB.
That's on my todo list and it seems to have quite some potential for log
files, especially if enriched by structured data (or CEE).

Rainer

From rgerhards at hq.adiscon.com  Sat Dec  3 15:44:36 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Sat, 3 Dec 2011 15:44:36 +0100
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>

> this makes sense.
> 
> the hash creator should periodically (config option or command line
> option) write a log message that says what the most recent hash is so
> that
> the hash can be sent off somewhere else. I don't know how much info
> should
> be provided along with the hash (probably at least the timestamp,
> possibly
> the beginning of the line to make it easy to find)

The way I intend to implement it actually is a bit different. First of all,
this for sure is not a defense line against attackers, you'll forward the
complete logs to another system (to prevent the attacker from deleting the
logs). With that said, I assume all we need to do is verify the correctness
of the log file. Let's talk about a concept I call a "(file) partition": this
is a set of n consecutive messages. Within each partition, you create the
hashes and chain them. When a partition is complete (n messages reached,
configurable), a partition signature record is written. That contains the
last hash used inside the partition and is signed with a trusted key (using
strong cryptography, can use PKI but must not). When you read the file, you
check the hashes and, each time you reach a partition boundary, verify the
partition as whole via the signature. This keeps overhead low and security
high, without the need to distribute specific hashes. Obviously, security can
only be guaranteed for complete partitions.

The tool I am writing will start with the hashes and then introduce the
signatures in a second step soon after. The file format will be simple and
documented (you need different record types: message itself, end partition,
probably open and close records). Using this scheme, it is also possible to
zip on a per-partition basis (rsyslog omfile already has this capability) and
also potentially possible to encrypt the result (but I do not intend to do
this in the first steps - maybe later).

Rainer
> 
> as you pointed out, hashing by itself does no good, the hashes need to
> be
> sent elsewhere. rsyslog has the ability to send things elsewhere based
> on
> what they are, so a distictive log message that can easily be filtered
> to
> send out should do the job.
> 
> David Lang
> 
> > Rainer
> >
> >> David Lang
> >>
> >> On Wed, 30 Nov 2011, david at lang.hm wrote:
> >>
> >>> Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
> >>> From: david at lang.hm
> >>> To: rsyslog-users <rsyslog at lists.adiscon.com>
> >>> Subject: Re: [rsyslog] trusted (fields/properties) now also in
> >> rsyslog
> >>>
> >>>
> >>> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
> >> thinking
> >>> that it should be fairly easy to add these sorts of things to
> >> existing
> >>> software.
> >>>
> >>> are these values available as named properties when crafting a
> format
> >> string?
> >>>
> >>> Also, while it will hurt existing parsers, this data needs to be at
> >> the
> >>> beginning of the line, before any user generated input, so that it
> >> can't be
> >>> faked.
> >>>
> >>> because of existing parsers, this probably means that we need an
> >> option to
> >>> deal with this, or possibly a couple of options
> >>>
> >>> 1. should rsyslog add this to the %msg% property when the line is
> >> read in by
> >>> imsock, leaving logs from other sources alone?
> >>>
> >>> having this would probaly make things wasy for many people, but
> >> defeats the
> >>> value of the trusted properties as other sources could add text to
> >> the logs
> >>> that looks like it is the trusted properties.
> >>>
> >>> Rsyslog already has %inputname% to say where the log came from.
> this
> >> is
> >>> seldom used, but if it is used, it would probably make sense to use
> >> these new
> >>> properties the same way.
> >>>
> >>> 2. add an output format (or two, one for local, one for remote)
> that
> >> inserts
> >>> these properties at the beginning of the line for every message,
> even
> >> if it
> >>> comes from a source that doesn't provide the data so that user
> >> provided input
> >>> cannot pretend to provide these fields. Yes, I know that users can
> >> create
> >>> their own output format, but if Rsyslog defines one, it is far more
> >> likely
> >>> that people will use it, and if they do Rsyslog can define a parser
> >> module
> >>> that populates these fileds from an incomeing message over the
> >> network (while
> >>> providing the appropriate value in %inputname% that says that the
> >> message
> >>> came over the network and so the message could have been faked)
> >>>
> >>> David Lang
> >>>
> >>>
> >>> On Tue, 29 Nov 2011, Rainer Gerhards wrote:
> >>>
> >>>> Date: Tue, 29 Nov 2011 13:05:40 +0100
> >>>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> >>>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> >>>> To: rsyslog at lists.adiscon.com
> >>>> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I thought I'd buy in on one of journald's better ideas, here are
> the
> >>>> details:
> >>>>
> >>>> http://blog.gerhards.net/2011/11/trusted-properties-in-
> rsyslog.html
> >>>>
> >>>> I will see that I can release today, but would like to merge into
> >> v6, if
> >>>> possible... Expect an announcement soon. I'd also like to know
> what
> >> you
> >>>> think
> >>>> about this feature.
> >>>>
> >>>> Thanks,
> >>>> Rainer
> >>>> _______________________________________________
> >>>> rsyslog mailing list
> >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >>>> http://www.rsyslog.com/professional-services/
> >>>>
> >>>
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> http://www.rsyslog.com/professional-services/
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From david at lang.hm  Sat Dec  3 15:53:09 2011
From: david at lang.hm (david at lang.hm)
Date: Sat, 3 Dec 2011 06:53:09 -0800 (PST)
Subject: [rsyslog] calling DBAs. need help replicating 'journal feature'
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72815A3@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112022337530.12746@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA72815A3@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112030644000.20148@asgard.lang.hm>


On Sat, 3 Dec 2011, Rainer Gerhards wrote:

>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>
> Just as a side-note I would suggest to have a look at systems like MongoDB.
> That's on my todo list and it seems to have quite some potential for log
> files, especially if enriched by structured data (or CEE).

I strongly suspect that either postgres with full-text indexing or hadoop 
(hdfs) would give the query performance that they are claiming for the 
journal, but they are correct in stating that some strings will be stored 
repeatedly (wasting space), so I was hoping to get someone to step up and 
help by writing the stored procedures that would be needed to get the same 
effect in a database.

David Lang

From david at lang.hm  Sat Dec  3 15:58:04 2011
From: david at lang.hm (david at lang.hm)
Date: Sat, 3 Dec 2011 06:58:04 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>

On Sat, 3 Dec 2011, Rainer Gerhards wrote:

>> this makes sense.
>>
>> the hash creator should periodically (config option or command line
>> option) write a log message that says what the most recent hash is so
>> that
>> the hash can be sent off somewhere else. I don't know how much info
>> should
>> be provided along with the hash (probably at least the timestamp,
>> possibly
>> the beginning of the line to make it easy to find)
>
> The way I intend to implement it actually is a bit different. First of all,
> this for sure is not a defense line against attackers, you'll forward the
> complete logs to another system (to prevent the attacker from deleting the
> logs). With that said, I assume all we need to do is verify the correctness
> of the log file. Let's talk about a concept I call a "(file) partition": this
> is a set of n consecutive messages. Within each partition, you create the
> hashes and chain them. When a partition is complete (n messages reached,
> configurable), a partition signature record is written. That contains the
> last hash used inside the partition and is signed with a trusted key (using
> strong cryptography, can use PKI but must not). When you read the file, you
> check the hashes and, each time you reach a partition boundary, verify the
> partition as whole via the signature. This keeps overhead low and security
> high, without the need to distribute specific hashes. Obviously, security can
> only be guaranteed for complete partitions.

This sounds like a good solution. Much more complete than the Jounral 
proposal.

One corner case to think of, when doing a shutdown or a HUP, you need to 
close out the partition before closing the file.

> The tool I am writing will start with the hashes and then introduce the
> signatures in a second step soon after. The file format will be simple and
> documented (you need different record types: message itself, end partition,
> probably open and close records). Using this scheme, it is also possible to
> zip on a per-partition basis (rsyslog omfile already has this capability) and
> also potentially possible to encrypt the result (but I do not intend to do
> this in the first steps - maybe later).

what flavors of zip does omfile support?.

David Lang


> Rainer
>>
>> as you pointed out, hashing by itself does no good, the hashes need to
>> be
>> sent elsewhere. rsyslog has the ability to send things elsewhere based
>> on
>> what they are, so a distictive log message that can easily be filtered
>> to
>> send out should do the job.
>>
>> David Lang
>>
>>> Rainer
>>>
>>>> David Lang
>>>>
>>>> On Wed, 30 Nov 2011, david at lang.hm wrote:
>>>>
>>>>> Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
>>>>> From: david at lang.hm
>>>>> To: rsyslog-users <rsyslog at lists.adiscon.com>
>>>>> Subject: Re: [rsyslog] trusted (fields/properties) now also in
>>>> rsyslog
>>>>>
>>>>>
>>>>> I'm happy to see this, I was just reading up on SCM_CREDENTIALS and
>>>> thinking
>>>>> that it should be fairly easy to add these sorts of things to
>>>> existing
>>>>> software.
>>>>>
>>>>> are these values available as named properties when crafting a
>> format
>>>> string?
>>>>>
>>>>> Also, while it will hurt existing parsers, this data needs to be at
>>>> the
>>>>> beginning of the line, before any user generated input, so that it
>>>> can't be
>>>>> faked.
>>>>>
>>>>> because of existing parsers, this probably means that we need an
>>>> option to
>>>>> deal with this, or possibly a couple of options
>>>>>
>>>>> 1. should rsyslog add this to the %msg% property when the line is
>>>> read in by
>>>>> imsock, leaving logs from other sources alone?
>>>>>
>>>>> having this would probaly make things wasy for many people, but
>>>> defeats the
>>>>> value of the trusted properties as other sources could add text to
>>>> the logs
>>>>> that looks like it is the trusted properties.
>>>>>
>>>>> Rsyslog already has %inputname% to say where the log came from.
>> this
>>>> is
>>>>> seldom used, but if it is used, it would probably make sense to use
>>>> these new
>>>>> properties the same way.
>>>>>
>>>>> 2. add an output format (or two, one for local, one for remote)
>> that
>>>> inserts
>>>>> these properties at the beginning of the line for every message,
>> even
>>>> if it
>>>>> comes from a source that doesn't provide the data so that user
>>>> provided input
>>>>> cannot pretend to provide these fields. Yes, I know that users can
>>>> create
>>>>> their own output format, but if Rsyslog defines one, it is far more
>>>> likely
>>>>> that people will use it, and if they do Rsyslog can define a parser
>>>> module
>>>>> that populates these fileds from an incomeing message over the
>>>> network (while
>>>>> providing the appropriate value in %inputname% that says that the
>>>> message
>>>>> came over the network and so the message could have been faked)
>>>>>
>>>>> David Lang
>>>>>
>>>>>
>>>>> On Tue, 29 Nov 2011, Rainer Gerhards wrote:
>>>>>
>>>>>> Date: Tue, 29 Nov 2011 13:05:40 +0100
>>>>>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
>>>>>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
>>>>>> To: rsyslog at lists.adiscon.com
>>>>>> Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I thought I'd buy in on one of journald's better ideas, here are
>> the
>>>>>> details:
>>>>>>
>>>>>> http://blog.gerhards.net/2011/11/trusted-properties-in-
>> rsyslog.html
>>>>>>
>>>>>> I will see that I can release today, but would like to merge into
>>>> v6, if
>>>>>> possible... Expect an announcement soon. I'd also like to know
>> what
>>>> you
>>>>>> think
>>>>>> about this feature.
>>>>>>
>>>>>> Thanks,
>>>>>> Rainer
>>>>>> _______________________________________________
>>>>>> rsyslog mailing list
>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>>>>> http://www.rsyslog.com/professional-services/
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>>> http://www.rsyslog.com/professional-services/
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From rgerhards at hq.adiscon.com  Sat Dec  3 16:07:31 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Sat, 3 Dec 2011 16:07:31 +0100
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815A7@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Saturday, December 03, 2011 3:58 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] trusted (fields/properties) now also in rsyslog
> 
> On Sat, 3 Dec 2011, Rainer Gerhards wrote:
> 
> >> this makes sense.
> >>
> >> the hash creator should periodically (config option or command line
> >> option) write a log message that says what the most recent hash is
> so
> >> that
> >> the hash can be sent off somewhere else. I don't know how much info
> >> should
> >> be provided along with the hash (probably at least the timestamp,
> >> possibly
> >> the beginning of the line to make it easy to find)
> >
> > The way I intend to implement it actually is a bit different. First
> of all,
> > this for sure is not a defense line against attackers, you'll forward
> the
> > complete logs to another system (to prevent the attacker from
> deleting the
> > logs). With that said, I assume all we need to do is verify the
> correctness
> > of the log file. Let's talk about a concept I call a "(file)
> partition": this
> > is a set of n consecutive messages. Within each partition, you create
> the
> > hashes and chain them. When a partition is complete (n messages
> reached,
> > configurable), a partition signature record is written. That contains
> the
> > last hash used inside the partition and is signed with a trusted key
> (using
> > strong cryptography, can use PKI but must not). When you read the
> file, you
> > check the hashes and, each time you reach a partition boundary,
> verify the
> > partition as whole via the signature. This keeps overhead low and
> security
> > high, without the need to distribute specific hashes. Obviously,
> security can
> > only be guaranteed for complete partitions.
> 
> This sounds like a good solution. Much more complete than the Jounral
> proposal.
> 
> One corner case to think of, when doing a shutdown or a HUP, you need
> to
> close out the partition before closing the file.

Yup, it'll do a premature close of the partition in that case (so more
precisely partions have *up to* n records, but may have fewer).

For the time being, keep on your mind that this is an external tool. I'll
tighter integrate this into rsyslogd once the initial experimentation phase
is over (but you can use omprog initially). The good thing about that
approach is that you can use that tool to protect all logs you have, no
matter if rsyslog touched them or not (e.g. Apache logs). You could even
secure the export of the journal [journalctl ... | logwriter] ;)

I intend to use a library for the main functionality, so integrating back
into rsyslog shouldn't be too hard. 

> > The tool I am writing will start with the hashes and then introduce
> the
> > signatures in a second step soon after. The file format will be
> simple and
> > documented (you need different record types: message itself, end
> partition,
> > probably open and close records). Using this scheme, it is also
> possible to
> > zip on a per-partition basis (rsyslog omfile already has this
> capability) and
> > also potentially possible to encrypt the result (but I do not intend
> to do
> > this in the first steps - maybe later).
> 
> what flavors of zip does omfile support?.

The usual zlib stuff, with the usual zip levels. So pretty basic stuff, but
still useful (especially if used with large block sizes). It's important to
note that that code uses partitions as well. So if something at the end of
the log really goes wrong, you can still read all the other partitions *with
normal tools* (in the source tree is also a tool that can read non-properly
closed files, but I dropped support for this as partitions worked well).

Rainer

> 
> David Lang
> 
> 
> > Rainer
> >>
> >> as you pointed out, hashing by itself does no good, the hashes need
> to
> >> be
> >> sent elsewhere. rsyslog has the ability to send things elsewhere
> based
> >> on
> >> what they are, so a distictive log message that can easily be
> filtered
> >> to
> >> send out should do the job.
> >>
> >> David Lang
> >>
> >>> Rainer
> >>>
> >>>> David Lang
> >>>>
> >>>> On Wed, 30 Nov 2011, david at lang.hm wrote:
> >>>>
> >>>>> Date: Wed, 30 Nov 2011 19:58:30 -0800 (PST)
> >>>>> From: david at lang.hm
> >>>>> To: rsyslog-users <rsyslog at lists.adiscon.com>
> >>>>> Subject: Re: [rsyslog] trusted (fields/properties) now also in
> >>>> rsyslog
> >>>>>
> >>>>>
> >>>>> I'm happy to see this, I was just reading up on SCM_CREDENTIALS
> and
> >>>> thinking
> >>>>> that it should be fairly easy to add these sorts of things to
> >>>> existing
> >>>>> software.
> >>>>>
> >>>>> are these values available as named properties when crafting a
> >> format
> >>>> string?
> >>>>>
> >>>>> Also, while it will hurt existing parsers, this data needs to be
> at
> >>>> the
> >>>>> beginning of the line, before any user generated input, so that
> it
> >>>> can't be
> >>>>> faked.
> >>>>>
> >>>>> because of existing parsers, this probably means that we need an
> >>>> option to
> >>>>> deal with this, or possibly a couple of options
> >>>>>
> >>>>> 1. should rsyslog add this to the %msg% property when the line is
> >>>> read in by
> >>>>> imsock, leaving logs from other sources alone?
> >>>>>
> >>>>> having this would probaly make things wasy for many people, but
> >>>> defeats the
> >>>>> value of the trusted properties as other sources could add text
> to
> >>>> the logs
> >>>>> that looks like it is the trusted properties.
> >>>>>
> >>>>> Rsyslog already has %inputname% to say where the log came from.
> >> this
> >>>> is
> >>>>> seldom used, but if it is used, it would probably make sense to
> use
> >>>> these new
> >>>>> properties the same way.
> >>>>>
> >>>>> 2. add an output format (or two, one for local, one for remote)
> >> that
> >>>> inserts
> >>>>> these properties at the beginning of the line for every message,
> >> even
> >>>> if it
> >>>>> comes from a source that doesn't provide the data so that user
> >>>> provided input
> >>>>> cannot pretend to provide these fields. Yes, I know that users
> can
> >>>> create
> >>>>> their own output format, but if Rsyslog defines one, it is far
> more
> >>>> likely
> >>>>> that people will use it, and if they do Rsyslog can define a
> parser
> >>>> module
> >>>>> that populates these fileds from an incomeing message over the
> >>>> network (while
> >>>>> providing the appropriate value in %inputname% that says that the
> >>>> message
> >>>>> came over the network and so the message could have been faked)
> >>>>>
> >>>>> David Lang
> >>>>>
> >>>>>
> >>>>> On Tue, 29 Nov 2011, Rainer Gerhards wrote:
> >>>>>
> >>>>>> Date: Tue, 29 Nov 2011 13:05:40 +0100
> >>>>>> From: Rainer Gerhards <rgerhards at hq.adiscon.com>
> >>>>>> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> >>>>>> To: rsyslog at lists.adiscon.com
> >>>>>> Subject: [rsyslog] trusted (fields/properties) now also in
> rsyslog
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I thought I'd buy in on one of journald's better ideas, here are
> >> the
> >>>>>> details:
> >>>>>>
> >>>>>> http://blog.gerhards.net/2011/11/trusted-properties-in-
> >> rsyslog.html
> >>>>>>
> >>>>>> I will see that I can release today, but would like to merge
> into
> >>>> v6, if
> >>>>>> possible... Expect an announcement soon. I'd also like to know
> >> what
> >>>> you
> >>>>>> think
> >>>>>> about this feature.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Rainer
> >>>>>> _______________________________________________
> >>>>>> rsyslog mailing list
> >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >>>>>> http://www.rsyslog.com/professional-services/
> >>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> rsyslog mailing list
> >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >>>> http://www.rsyslog.com/professional-services/
> >>> _______________________________________________
> >>> rsyslog mailing list
> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >>> http://www.rsyslog.com/professional-services/
> >>>
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> http://www.rsyslog.com/professional-services/
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From david at lang.hm  Sat Dec  3 16:33:18 2011
From: david at lang.hm (david at lang.hm)
Date: Sat, 3 Dec 2011 07:33:18 -0800 (PST)
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72815A7@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA72815A7@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112030731200.20148@asgard.lang.hm>

On Sat, 3 Dec 2011, Rainer Gerhards wrote:

>>> The tool I am writing will start with the hashes and then introduce
>> the
>>> signatures in a second step soon after. The file format will be
>> simple and
>>> documented (you need different record types: message itself, end
>> partition,
>>> probably open and close records). Using this scheme, it is also
>> possible to
>>> zip on a per-partition basis (rsyslog omfile already has this
>> capability) and
>>> also potentially possible to encrypt the result (but I do not intend
>> to do
>>> this in the first steps - maybe later).
>>
>> what flavors of zip does omfile support?.
>
> The usual zlib stuff, with the usual zip levels. So pretty basic stuff, but
> still useful (especially if used with large block sizes). It's important to
> note that that code uses partitions as well. So if something at the end of
> the log really goes wrong, you can still read all the other partitions *with
> normal tools* (in the source tree is also a tool that can read non-properly
> closed files, but I dropped support for this as partitions worked well).

Ok, so zip, but not gzip, bzip2, lzma, etc. that's what I was guessing, 
but I figured it woudln't hurt to ask.

David Lang

From rgerhards at hq.adiscon.com  Sat Dec  3 18:46:24 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Sat, 3 Dec 2011 18:46:24 +0100
Subject: [rsyslog] trusted (fields/properties) now also in rsyslog
In-Reply-To: <alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281549@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1111301928170.30627@asgard.lang.hm><alpine.DEB.2.02.1112021101210.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A1@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1112022333030.12746@asgard.lang.hm><9B6E2A8877C38245BFB15CC491A11DA72815A4@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112030654260.20148@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815A8@GRFEXC.intern.adiscon.com>

> > The way I intend to implement it actually is a bit different. First of
> > all, this for sure is not a defense line against attackers, you'll
> > forward the complete logs to another system (to prevent the attacker
> > from deleting the logs). With that said, I assume all we need to do is
> > verify the correctness of the log file. Let's talk about a concept I
> > call a "(file) partition": this is a set of n consecutive messages.
> > Within each partition, you create the hashes and chain them. When a
> > partition is complete (n messages reached, configurable), a partition
> > signature record is written. That contains the last hash used inside
> > the partition and is signed with a trusted key (using strong
> > cryptography, can use PKI but must not). When you read the file, you
> > check the hashes and, each time you reach a partition boundary, verify
> > the partition as whole via the signature. This keeps overhead low and
> > security high, without the need to distribute specific hashes. Obviously,
> security can only be guaranteed for complete partitions.
> 
> This sounds like a good solution. Much more complete than the Jounral
> proposal.

In case you are into some pain, I have pushed the current "code" to a git
repository:  ;)

http://git.adiscon.com/?p=logtools.git;a=summary

So far it only creates the hashes, and *without* append functionality (which
makes it a real toy ;)). It also can read and verify the complete log.

Next step is to add append mode and then see that the rest is done...

Rainer

From tom.teal at noaa.gov  Mon Dec  5 21:43:34 2011
From: tom.teal at noaa.gov (Tom Teal)
Date: Mon, 05 Dec 2011 15:43:34 -0500
Subject: [rsyslog] Fwd: rsyslog on AIX
Message-ID: <4EDD2CF6.9070200@noaa.gov>

Seconding this a second time since we have been having a lot of problems
with email.
If any could has run across this and could assist it would be greatly
appreciated.

Tom

-------- Original Message --------
Subject: 	rsyslog on AIX
Date: 	Mon, 21 Nov 2011 14:29:23 -0500
From: 	Tom Teal <tom.teal at noaa.gov>
To: 	rsyslog at lists.adiscon.com



Hello,

Working on a rsyslog install on an AIX platform. 

The install of rsyslog worked with no errors and after editing the
rsyslog.conf file I get a Segmentation fault error:

Starting Rsyslogd... ./Srsyslog[66]: 9633992 Segmentation fault(coredump)
done.


Here are the statements added to the rsyslog.conf file (ip address was
masked with 9's for this email):

######## TCP Forwarding #########
$WorkDirectory /var/log/rsyslog # default location for work (spool) files
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down

# Temporary log server IP address
*.* @@999.999.999.999:5140

Here is the output from the dbx debug tool of the core file:

Type 'help' for help.
[using memory image in /etc/rc.d/rc2.d/core]
reading symbolic information ...
Segmentation fault in glink.strlen at 0xd55da6d0 ($t1)
0xd55da6d0 (strlen+0x30) 800c0000         lwz   r0,0x0(r12)
(dbx)  thread  state-k     wchan    state-u    k-tid   mode held scope
function
>$t1     run                  running  30277685     k   no   sys  strlen
(dbx) glink.strlen() at 0xd55da6d0
netClassInit(pModInfo = 0x30012e68), line 1636 in "net.c"
should_use_so_bsdcompat(0x5, 0x30012e70, 0x30012e88, 0x30005ab8,
0x30012e68), line 1665 in "net.c"
doModInit(modInit = 0xf0ef4494, name = "lmnet", pModHdlr = 0x00000003),
line 425 in "modules.c"
Load(pModName = "lmnet"), line 851 in "modules.c"
UseObj(srcFile = "conf.c", pObjName = "net", pObjFile = "lmnet", pIf =
0x300013e0), line 1157 in "obj.c"
confClassInit(pModInfo = (nil)), line 1294 in "conf.c"
rsrtInit(ppErrObj = 0x2ff226f4, pObjIF = 0x300039d0), line 186 in
"rsyslog.c"
InitGlobalClasses(), line 2247 in "syslogd.c"
legacyOptsParseTCP(ch = '^P', arg = warning: Unable to access address
0x1 from core
(invalid char ptr (0x00000001))), line 2610 in "syslogd.c"
main(argc = 5, argv = 0x2ff2293c), line 2907 in "syslogd.c"

Here is the rsyslog script that executes:

#!/usr/bin/ksh
#
# rsyslog:     Startup script for rsyslogd.
#
# Description: Rsyslogd is an enhanced multi-threaded syslogd supporting,
#              among others, MySQL, syslog/tcp, RFC 3195, permitted
#              sender lists, filtering on any message part, and fine
#              grain output format control.
#
# Mar 09, 2011, Michael Perzl (michael at perzl.org)
#

NAME=rsyslog
PROG=${NAME}d

RSYSLOGD_BIN=/opt/freeware/sbin/${PROG}

PIDFILE=/var/run/${PROG}.pid


# define some generic commands
AWK=/usr/bin/awk
CAT=/usr/bin/cat
ECHO=/usr/bin/echo
GREP=/usr/bin/grep
KILL=/usr/bin/kill
MKDIR=/usr/bin/mkdir
PRINTF=/usr/bin/printf
PS=/usr/bin/ps
RM=/usr/bin/rm


# check for missing binaries (stale symlinks should not happen)
test -x ${RSYSLOGD_BIN} ||
    {
      $ECHO "${RSYSLOGD_BIN} not installed"
      if [ "$1" = "stop" ] ; then
          exit 0
      else
          exit 5
      fi
    }


# source config
if [ -f /etc/sysconfig/${NAME} ] ; then
    . /etc/sysconfig/${NAME}
fi


case "$1" in
    start)
        if [ -r ${PIDFILE} ]; then
            pid=`$CAT ${PIDFILE}`
            if [ "`$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP
${pid} | $AWK '{ print $2 }'`" = "${pid}" ] ; then
                $ECHO "Rsyslogd is already running with PID ${pid}."
                exit 1
            else
                $RM -f ${PIDFILE}
            fi
        fi
        $PRINTF "Starting Rsyslogd... "

        ## start daemon and write PID to file ${PIDFILE}
        $MKDIR -p /var/run
        ${RSYSLOGD_BIN} -i "${PIDFILE}" ${SYSLOGD_OPTIONS}
        $ECHO "done."
        ;;
    stop)
        $PRINTF "Stopping Rsyslogd... "
        ## stop daemon
        if [ -r ${PIDFILE} ]; then
            $KILL -TERM `$CAT ${PIDFILE}`
            $RM -f ${PIDFILE}
        fi
        $ECHO "done."
        ;;
    status)
        if [ -r ${PIDFILE} ]; then
            pid=`$CAT ${PIDFILE}`
            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP ${pid}
| $AWK '{ print $2 }'` = ${pid} ] ; then
                $ECHO "Rsyslogd is running with PID ${pid}."
            fi
        else
            $ECHO "Rsyslogd is not running."
        fi
        ;;
    condrestart)
        if [ -r ${PIDFILE} ]; then
            pid=`$CAT ${PIDFILE}`
            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP ${pid}
| $AWK '{ print $2 }'` = ${pid} ] ; then
                $0 stop
                $0 start
            fi
        fi
        ;;
    restart)
        ## Stop the service and regardless of whether it was
        ## running or not, start it again.
        $0 stop
        $0 start
        ;;
    *)
        $ECHO "Usage: $0 {start|stop|status|condrestart|?restart}"
        exit 1
        ;;
esac


The debug log seems to be complaining about a string length.  Any help
assisting in correcting this problem would be greatly appreciated.

Tom



From david at lang.hm  Tue Dec  6 03:32:10 2011
From: david at lang.hm (david at lang.hm)
Date: Mon, 5 Dec 2011 18:32:10 -0800 (PST)
Subject: [rsyslog] Fwd: rsyslog on AIX
In-Reply-To: <4EDD2CF6.9070200@noaa.gov>
References: <4EDD2CF6.9070200@noaa.gov>
Message-ID: <alpine.DEB.2.02.1112051831250.28983@asgard.lang.hm>

Rainer is probably going to have to look at this, but a copy of the debug 
output may help him.

David Lang

On Mon, 5 Dec 2011, Tom Teal wrote:

> Date: Mon, 05 Dec 2011 15:43:34 -0500
> From: Tom Teal <tom.teal at noaa.gov>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] Fwd: rsyslog on AIX
> 
> Seconding this a second time since we have been having a lot of problems
> with email.
> If any could has run across this and could assist it would be greatly
> appreciated.
>
> Tom
>
> -------- Original Message --------
> Subject: 	rsyslog on AIX
> Date: 	Mon, 21 Nov 2011 14:29:23 -0500
> From: 	Tom Teal <tom.teal at noaa.gov>
> To: 	rsyslog at lists.adiscon.com
>
>
>
> Hello,
>
> Working on a rsyslog install on an AIX platform.
>
> The install of rsyslog worked with no errors and after editing the
> rsyslog.conf file I get a Segmentation fault error:
>
> Starting Rsyslogd... ./Srsyslog[66]: 9633992 Segmentation fault(coredump)
> done.
>
>
> Here are the statements added to the rsyslog.conf file (ip address was
> masked with 9's for this email):
>
> ######## TCP Forwarding #########
> $WorkDirectory /var/log/rsyslog # default location for work (spool) files
> $ActionQueueType LinkedList # use asynchronous processing
> $ActionQueueFileName srvrfwd # set file name, also enables disk mode
> $ActionResumeRetryCount -1 # infinite retries on insert failure
> $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
>
> # Temporary log server IP address
> *.* @@999.999.999.999:5140
>
> Here is the output from the dbx debug tool of the core file:
>
> Type 'help' for help.
> [using memory image in /etc/rc.d/rc2.d/core]
> reading symbolic information ...
> Segmentation fault in glink.strlen at 0xd55da6d0 ($t1)
> 0xd55da6d0 (strlen+0x30) 800c0000         lwz   r0,0x0(r12)
> (dbx)  thread  state-k     wchan    state-u    k-tid   mode held scope
> function
>> $t1     run                  running  30277685     k   no   sys  strlen
> (dbx) glink.strlen() at 0xd55da6d0
> netClassInit(pModInfo = 0x30012e68), line 1636 in "net.c"
> should_use_so_bsdcompat(0x5, 0x30012e70, 0x30012e88, 0x30005ab8,
> 0x30012e68), line 1665 in "net.c"
> doModInit(modInit = 0xf0ef4494, name = "lmnet", pModHdlr = 0x00000003),
> line 425 in "modules.c"
> Load(pModName = "lmnet"), line 851 in "modules.c"
> UseObj(srcFile = "conf.c", pObjName = "net", pObjFile = "lmnet", pIf =
> 0x300013e0), line 1157 in "obj.c"
> confClassInit(pModInfo = (nil)), line 1294 in "conf.c"
> rsrtInit(ppErrObj = 0x2ff226f4, pObjIF = 0x300039d0), line 186 in
> "rsyslog.c"
> InitGlobalClasses(), line 2247 in "syslogd.c"
> legacyOptsParseTCP(ch = '^P', arg = warning: Unable to access address
> 0x1 from core
> (invalid char ptr (0x00000001))), line 2610 in "syslogd.c"
> main(argc = 5, argv = 0x2ff2293c), line 2907 in "syslogd.c"
>
> Here is the rsyslog script that executes:
>
> #!/usr/bin/ksh
> #
> # rsyslog:     Startup script for rsyslogd.
> #
> # Description: Rsyslogd is an enhanced multi-threaded syslogd supporting,
> #              among others, MySQL, syslog/tcp, RFC 3195, permitted
> #              sender lists, filtering on any message part, and fine
> #              grain output format control.
> #
> # Mar 09, 2011, Michael Perzl (michael at perzl.org)
> #
>
> NAME=rsyslog
> PROG=${NAME}d
>
> RSYSLOGD_BIN=/opt/freeware/sbin/${PROG}
>
> PIDFILE=/var/run/${PROG}.pid
>
>
> # define some generic commands
> AWK=/usr/bin/awk
> CAT=/usr/bin/cat
> ECHO=/usr/bin/echo
> GREP=/usr/bin/grep
> KILL=/usr/bin/kill
> MKDIR=/usr/bin/mkdir
> PRINTF=/usr/bin/printf
> PS=/usr/bin/ps
> RM=/usr/bin/rm
>
>
> # check for missing binaries (stale symlinks should not happen)
> test -x ${RSYSLOGD_BIN} ||
>    {
>      $ECHO "${RSYSLOGD_BIN} not installed"
>      if [ "$1" = "stop" ] ; then
>          exit 0
>      else
>          exit 5
>      fi
>    }
>
>
> # source config
> if [ -f /etc/sysconfig/${NAME} ] ; then
>    . /etc/sysconfig/${NAME}
> fi
>
>
> case "$1" in
>    start)
>        if [ -r ${PIDFILE} ]; then
>            pid=`$CAT ${PIDFILE}`
>            if [ "`$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP
> ${pid} | $AWK '{ print $2 }'`" = "${pid}" ] ; then
>                $ECHO "Rsyslogd is already running with PID ${pid}."
>                exit 1
>            else
>                $RM -f ${PIDFILE}
>            fi
>        fi
>        $PRINTF "Starting Rsyslogd... "
>
>        ## start daemon and write PID to file ${PIDFILE}
>        $MKDIR -p /var/run
>        ${RSYSLOGD_BIN} -i "${PIDFILE}" ${SYSLOGD_OPTIONS}
>        $ECHO "done."
>        ;;
>    stop)
>        $PRINTF "Stopping Rsyslogd... "
>        ## stop daemon
>        if [ -r ${PIDFILE} ]; then
>            $KILL -TERM `$CAT ${PIDFILE}`
>            $RM -f ${PIDFILE}
>        fi
>        $ECHO "done."
>        ;;
>    status)
>        if [ -r ${PIDFILE} ]; then
>            pid=`$CAT ${PIDFILE}`
>            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP ${pid}
> | $AWK '{ print $2 }'` = ${pid} ] ; then
>                $ECHO "Rsyslogd is running with PID ${pid}."
>            fi
>        else
>            $ECHO "Rsyslogd is not running."
>        fi
>        ;;
>    condrestart)
>        if [ -r ${PIDFILE} ]; then
>            pid=`$CAT ${PIDFILE}`
>            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP ${pid}
> | $AWK '{ print $2 }'` = ${pid} ] ; then
>                $0 stop
>                $0 start
>            fi
>        fi
>        ;;
>    restart)
>        ## Stop the service and regardless of whether it was
>        ## running or not, start it again.
>        $0 stop
>        $0 start
>        ;;
>    *)
>        $ECHO "Usage: $0 {start|stop|status|condrestart|?restart}"
>        exit 1
>        ;;
> esac
>
>
> The debug log seems to be complaining about a string length.  Any help
> assisting in correcting this problem would be greatly appreciated.
>
> Tom
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From rgerhards at hq.adiscon.com  Tue Dec  6 08:29:08 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 6 Dec 2011 08:29:08 +0100
Subject: [rsyslog] Fwd: rsyslog on AIX
In-Reply-To: <alpine.DEB.2.02.1112051831250.28983@asgard.lang.hm>
References: <4EDD2CF6.9070200@noaa.gov>
	<alpine.DEB.2.02.1112051831250.28983@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815B7@GRFEXC.intern.adiscon.com>

Sorry, nothing I can handle. I don't even have an AIX machine...

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Tuesday, December 06, 2011 3:32 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Fwd: rsyslog on AIX
> 
> Rainer is probably going to have to look at this, but a copy of the
> debug
> output may help him.
> 
> David Lang
> 
> On Mon, 5 Dec 2011, Tom Teal wrote:
> 
> > Date: Mon, 05 Dec 2011 15:43:34 -0500
> > From: Tom Teal <tom.teal at noaa.gov>
> > Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] Fwd: rsyslog on AIX
> >
> > Seconding this a second time since we have been having a lot of
> problems
> > with email.
> > If any could has run across this and could assist it would be greatly
> > appreciated.
> >
> > Tom
> >
> > -------- Original Message --------
> > Subject: 	rsyslog on AIX
> > Date: 	Mon, 21 Nov 2011 14:29:23 -0500
> > From: 	Tom Teal <tom.teal at noaa.gov>
> > To: 	rsyslog at lists.adiscon.com
> >
> >
> >
> > Hello,
> >
> > Working on a rsyslog install on an AIX platform.
> >
> > The install of rsyslog worked with no errors and after editing the
> > rsyslog.conf file I get a Segmentation fault error:
> >
> > Starting Rsyslogd... ./Srsyslog[66]: 9633992 Segmentation
> fault(coredump)
> > done.
> >
> >
> > Here are the statements added to the rsyslog.conf file (ip address
> was
> > masked with 9's for this email):
> >
> > ######## TCP Forwarding #########
> > $WorkDirectory /var/log/rsyslog # default location for work (spool)
> files
> > $ActionQueueType LinkedList # use asynchronous processing
> > $ActionQueueFileName srvrfwd # set file name, also enables disk mode
> > $ActionResumeRetryCount -1 # infinite retries on insert failure
> > $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts
> down
> >
> > # Temporary log server IP address
> > *.* @@999.999.999.999:5140
> >
> > Here is the output from the dbx debug tool of the core file:
> >
> > Type 'help' for help.
> > [using memory image in /etc/rc.d/rc2.d/core]
> > reading symbolic information ...
> > Segmentation fault in glink.strlen at 0xd55da6d0 ($t1)
> > 0xd55da6d0 (strlen+0x30) 800c0000         lwz   r0,0x0(r12)
> > (dbx)  thread  state-k     wchan    state-u    k-tid   mode held
> scope
> > function
> >> $t1     run                  running  30277685     k   no   sys
> strlen
> > (dbx) glink.strlen() at 0xd55da6d0
> > netClassInit(pModInfo = 0x30012e68), line 1636 in "net.c"
> > should_use_so_bsdcompat(0x5, 0x30012e70, 0x30012e88, 0x30005ab8,
> > 0x30012e68), line 1665 in "net.c"
> > doModInit(modInit = 0xf0ef4494, name = "lmnet", pModHdlr =
> 0x00000003),
> > line 425 in "modules.c"
> > Load(pModName = "lmnet"), line 851 in "modules.c"
> > UseObj(srcFile = "conf.c", pObjName = "net", pObjFile = "lmnet", pIf
> =
> > 0x300013e0), line 1157 in "obj.c"
> > confClassInit(pModInfo = (nil)), line 1294 in "conf.c"
> > rsrtInit(ppErrObj = 0x2ff226f4, pObjIF = 0x300039d0), line 186 in
> > "rsyslog.c"
> > InitGlobalClasses(), line 2247 in "syslogd.c"
> > legacyOptsParseTCP(ch = '^P', arg = warning: Unable to access address
> > 0x1 from core
> > (invalid char ptr (0x00000001))), line 2610 in "syslogd.c"
> > main(argc = 5, argv = 0x2ff2293c), line 2907 in "syslogd.c"
> >
> > Here is the rsyslog script that executes:
> >
> > #!/usr/bin/ksh
> > #
> > # rsyslog:     Startup script for rsyslogd.
> > #
> > # Description: Rsyslogd is an enhanced multi-threaded syslogd
> supporting,
> > #              among others, MySQL, syslog/tcp, RFC 3195, permitted
> > #              sender lists, filtering on any message part, and fine
> > #              grain output format control.
> > #
> > # Mar 09, 2011, Michael Perzl (michael at perzl.org)
> > #
> >
> > NAME=rsyslog
> > PROG=${NAME}d
> >
> > RSYSLOGD_BIN=/opt/freeware/sbin/${PROG}
> >
> > PIDFILE=/var/run/${PROG}.pid
> >
> >
> > # define some generic commands
> > AWK=/usr/bin/awk
> > CAT=/usr/bin/cat
> > ECHO=/usr/bin/echo
> > GREP=/usr/bin/grep
> > KILL=/usr/bin/kill
> > MKDIR=/usr/bin/mkdir
> > PRINTF=/usr/bin/printf
> > PS=/usr/bin/ps
> > RM=/usr/bin/rm
> >
> >
> > # check for missing binaries (stale symlinks should not happen)
> > test -x ${RSYSLOGD_BIN} ||
> >    {
> >      $ECHO "${RSYSLOGD_BIN} not installed"
> >      if [ "$1" = "stop" ] ; then
> >          exit 0
> >      else
> >          exit 5
> >      fi
> >    }
> >
> >
> > # source config
> > if [ -f /etc/sysconfig/${NAME} ] ; then
> >    . /etc/sysconfig/${NAME}
> > fi
> >
> >
> > case "$1" in
> >    start)
> >        if [ -r ${PIDFILE} ]; then
> >            pid=`$CAT ${PIDFILE}`
> >            if [ "`$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP
> > ${pid} | $AWK '{ print $2 }'`" = "${pid}" ] ; then
> >                $ECHO "Rsyslogd is already running with PID ${pid}."
> >                exit 1
> >            else
> >                $RM -f ${PIDFILE}
> >            fi
> >        fi
> >        $PRINTF "Starting Rsyslogd... "
> >
> >        ## start daemon and write PID to file ${PIDFILE}
> >        $MKDIR -p /var/run
> >        ${RSYSLOGD_BIN} -i "${PIDFILE}" ${SYSLOGD_OPTIONS}
> >        $ECHO "done."
> >        ;;
> >    stop)
> >        $PRINTF "Stopping Rsyslogd... "
> >        ## stop daemon
> >        if [ -r ${PIDFILE} ]; then
> >            $KILL -TERM `$CAT ${PIDFILE}`
> >            $RM -f ${PIDFILE}
> >        fi
> >        $ECHO "done."
> >        ;;
> >    status)
> >        if [ -r ${PIDFILE} ]; then
> >            pid=`$CAT ${PIDFILE}`
> >            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP
> ${pid}
> > | $AWK '{ print $2 }'` = ${pid} ] ; then
> >                $ECHO "Rsyslogd is running with PID ${pid}."
> >            fi
> >        else
> >            $ECHO "Rsyslogd is not running."
> >        fi
> >        ;;
> >    condrestart)
> >        if [ -r ${PIDFILE} ]; then
> >            pid=`$CAT ${PIDFILE}`
> >            if [ `$PS -ef | $GREP -v grep | $GREP ${PROG} | $GREP
> ${pid}
> > | $AWK '{ print $2 }'` = ${pid} ] ; then
> >                $0 stop
> >                $0 start
> >            fi
> >        fi
> >        ;;
> >    restart)
> >        ## Stop the service and regardless of whether it was
> >        ## running or not, start it again.
> >        $0 stop
> >        $0 start
> >        ;;
> >    *)
> >        $ECHO "Usage: $0 {start|stop|status|condrestart|?restart}"
> >        exit 1
> >        ;;
> > esac
> >
> >
> > The debug log seems to be complaining about a string length.  Any
> help
> > assisting in correcting this problem would be greatly appreciated.
> >
> > Tom
> >
> >
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From rgerhards at hq.adiscon.com  Tue Dec  6 18:50:20 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 6 Dec 2011 18:50:20 +0100
Subject: [rsyslog] LogStore & Tools
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72815C8@GRFEXC.intern.adiscon.com>

Hi all,

I have completed the implementation of a small set of tools to manipulate
security-enhanced text log files, plus proposed a log store format. There are
no releases yet and no packages build, but I thought I begin to spread the
word:

http://blog.gerhards.net/2011/12/announcing-logstore.html

I see this as useful not only for syslog, but any text-based logs that one
whats to keep in a tamperproof (better: tamperdetect) way.

I think I can release the initial version very soon - just some more tool doc
is missing. So far, rsyslog can use it via omprog, only. The plan is to
mature store and tools a bit, and then think about integration into omfile or
a separate output (the store already is written as a library for that
reason).

Credits need to go to the journald folks for finally pushing that idea ;)

Feedback appreciated.
Rainer

From a.chapellon at horoa.net  Thu Dec  8 15:37:47 2011
From: a.chapellon at horoa.net (Alexandre Chapellon)
Date: Thu, 08 Dec 2011 15:37:47 +0100
Subject: [rsyslog] timereported timezone?
In-Reply-To: <alpine.DEB.2.02.1111282018530.2399@asgard.lang.hm>
References: <4ECE848B.6070203@horoa.net>
	<alpine.DEB.2.02.1111241944430.22361@asgard.lang.hm>
	<9B6E2A8877C38245BFB15CC491A11DA7281512@GRFEXC.intern.adiscon.com>
	<4ED41D43.70307@horoa.net>
	<alpine.DEB.2.02.1111282018530.2399@asgard.lang.hm>
Message-ID: <4EE0CBBB.9070001@horoa.net>

I had rsyslog all along the forwarding chain and had to witch to 
forwarding format to on each host forwarding syslog messages not only 
the sending host.

Thanks to all people who replied... now I have consistant times and 
dates in my data warehouse! :)


Le 29/11/2011 05:19, david at lang.hm a ?crit :
> On Tue, 29 Nov 2011, Alexandre Chapellon wrote:
>
>>
>> Le 25/11/2011 07:21, Rainer Gerhards a ?crit :
>>>
>>>> -----Original Message-----
>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>>>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>>>> Sent: Friday, November 25, 2011 4:57 AM
>>>> To: rsyslog-users
>>>> Subject: Re: [rsyslog] timereported timezone?
>>>>
>>>> On Thu, 24 Nov 2011, Alexandre Chapellon wrote:
>>>>
>>>>> I quickly read the rfc3164 and found this:
>>>>>
>>>>> "
>>>>>
>>>>> ...
>>>>>
>>>>>    For implementers that do choose to construct syslog messages with
>>>> the
>>>>>    RECOMMENDED format, the following guidance is offered.
>>>>>
>>>>>          If the originally formed message has a TIMESTAMP in the
>>>> HEADER
>>>>>          part, then it SHOULD be the local time of the device within
>>>> its
>>>>>          timezone...
>>>>>
>>>>> "
>>>>>
>>>>> So I guess the timezone of the device is not store in the syslog
>>>> message by
>>>>> itself. Right?
>>>> correct.
>>>>
>>>>> Is there a way to include the local timezonein the header? or at
>>>> least in the
>>>>> message? (I would really prefer in the header)
>>>> you can't do it with the RFC3164 format, I belive that the latest RFC
>>>> does
>>>> have a timestamp format that includes the timezone, but I don't think
>>>> that
>>>> it's a good idea to use local time in any case.
>>> RFC5424 provides high-precision timestamps with timezone 
>>> information. Rsyslog
>>> does so for many years. It is a mayor frustration for me that all 
>>> distros
>>> turn off that feature (which is enabled by default).
>>>
>>> But of course that doesn't help if the original sender does not 
>>> provide TZ
>>> information.
>>> rainer
>> OK great, I only use rsyslog all along... So, I guess I have to 
>> recompile the whole syslog forwarding chain?
>> What will happen for message not carying TZ when they arrive on a 
>> recompiled rsyslog server? The locale TZ of the final rsyslog 
>> destination server will apply?
>
> If you are using rsyslog from the sending server on, then all you need 
> to do is to change the format that you use to send the message to one 
> that includes the high precision timestamp
>
> David Lang
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

-- 
<http://www.horoa.net>

Alexandre Chapellon

Ing?nierie des syst?mes open sources et r?seaux.
Follow me on twitter: @alxgomz <http://www.twitter.com/alxgomz>


From velu1980 at gmail.com  Fri Dec  9 21:15:05 2011
From: velu1980 at gmail.com (Velu S)
Date: Fri, 9 Dec 2011 15:15:05 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP configuration.
	Please help
Message-ID: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>

Hi,

I am a newbie to Rsyslog and am having a difficult time with configuring
Rsyslog with TCP.

My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
centralise log server and logged into mysql DB.
Every thing works fine when running in TCP. But all the messages from the
clients are lost when shutdown the server.
The messages are not buffered in TCP. I have been struck with this for long
time. Any help is highly appreciated.
I have pasted the conf files and the log file. I noticed the following:

error forwarding via tcp, suspending.

I don't know how to resolve this. Please help.

*My client rsyslog.conf:*

$ModLoad imuxsock             # local message reception
$ModLoad imudp
$ModLoad immark # provides --MARK-- message capability
$ModLoad imklog # provides kernel logging support (previously done by
rklogd)

$EscapeControlCharactersOnReceive off
$RepeatedMsgReduction on
$MarkMessagePeriod 0

#ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # the traditional
forwarding format with low-precision timestamps

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# Log all kernel messages clutters everything
kern.*                                                  ~
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure
# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog
# Log cron stuff
cron.*                                                  /var/log/cron
# Everybody gets emergency messages
*.emerg                                                 *
# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler
# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

$WorkDirectory  /rsyslog/work

$ActionQueueType LinkedList
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
$ActionFileEnableSync   on

*.* @@10.XXX.XX.XX:10514

*Server rsyslog.conf file:*

$ModLoad imtcp
$ModLoad immark   # provides --MARK-- message capability
$ModLoad imuxsock # provides support for local system logging (e.g. via
logger command)
$ModLoad imklog   # kernel logging (formerly provided by rklogd)
$ModLoad imudp    # provides UDP syslog reception
$ModLoad MySQL

#InputTCPMaxSessions 500
$InputTCPServerRun 10514

$SystemLogSocketFlowControl on
$SystemLogSocketName syslog

$EscapeControlCharactersOnReceive off

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure
# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog
# Log cron stuff
cron.*                                                  /var/log/cron
# Everybody gets emergency messages
*.emerg                                                 *
# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

local0.*                                                /var/log/ltm
local4.*                                                /var/log/ltm

$WorkDirectory /rsyslog/work

$RepeatedMsgReduction on

$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName tcpfile  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down

:*.* :ommysql:127.0.0.1,DB,DBUser,dbpass


Log snippet:
9937.418783000:main queue:Reg/w0:  (/var/log/messages)
9937.418798000:main queue:Reg/w0: Filter: check for property 'msg' (value '
#eNpVUV1P4zAQ/CuWn0Aiwet8tISnuxa4StcKCU48Rq7jthZJ7PNHrwL1v7Nu0Qkkv3hndmd29p22IobdH6/coqMNAFzRNuhB0YbeO31F2A2ZK0k4AyBQNmXVFBNy9/RMkefUYIJaWORCDpznUOdVkRAct8eJJ4SdoOkkn8K5yVszejUzHYpwxj7pWibNIXotE21QYWfQERX9Og5zFYTufQKkGYM6BETs/pAKerQxeNq8n6mtTl0lL/DVSfGQRZv5uB4N1lft6ueifZo/tMDLEirOqgljDFhdFbwG/p+/9WOmk/+6wLVwPShzXqZ5Tv2NygfrzEb3yXPAX2aT64iLZGKrxmRvad5034vrKmfk4kWPnfnnyeqZVDncErdvsH5JHpR8NdeYbvIA5F47tTGH1PPFuZdOr3GyNLgmfRQOBUQ/wyCc6X/p7Q65nQii3ToTrT+F1mNNSKlsyOROOK+SpRg22ZQeMbT47eDKOePOB6HL5exx/uM3hnK6ZBedCNqMtCnh+AGmDKd7$')
contains 'pvx': FALSE
9937.418810000:main queue:Reg/w0: Filter: check for property 'syslogtag'
(value '[ReportingSysLog]') startswith 'pvx': FALSE
9937.418821000:main queue:Reg/w0: Filter: check for property 'syslogtag'
(value '[ReportingSysLog]') isequal '[ReportingSysLog]': TRUE
9937.418835000:main queue:Reg/w0: Called action, logging to builtin-fwd
9937.418852000:main queue:Reg/w0:  10.122.87.75
9937.418862000:main queue:Reg/w0:  10.122.87.75:10514/tcp
9937.418879000:main queue:Reg/w0: CheckConnection detected broken
connection - closing it
9937.418924000:main queue:Reg/w0: file netstrms.c released module
'lmnsd_ptcp', reference count now 0
9937.418934000:main queue:Reg/w0: module 'lmnsd_ptcp' has zero reference
count, unloading...
9937.418943000:main queue:Reg/w0: Unloading module lmnsd_ptcp
9937.418954000:main queue:Reg/w0: file nsd_ptcp.c released module
'lmnetstrms', reference count now 2
9937.419019000:main queue:Reg/w0: caller requested object 'nsd_ptcp', not
found (iRet -3003)
9937.419033000:main queue:Reg/w0: Requested to load module 'lmnsd_ptcp'
9937.419044000:main queue:Reg/w0: loading module
'/usr/local/lib/rsyslog/lmnsd_ptcp.so'
9937.419154000:main queue:Reg/w0: source file nsd_ptcp.c requested
reference for module 'lmnetstrms', reference count now 3
9937.419169000:main queue:Reg/w0: module of type 2 being loaded.
9937.419179000:main queue:Reg/w0: source file netstrms.c requested
reference for module 'lmnsd_ptcp', reference count now 1
9937.419316000:main queue:Reg/w0: file netstrms.c released module
'lmnsd_ptcp', reference count now 0
9937.419326000:main queue:Reg/w0: module 'lmnsd_ptcp' has zero reference
count, unloading...
9937.419347000:main queue:Reg/w0: Unloading module lmnsd_ptcp
9937.419358000:main queue:Reg/w0: file nsd_ptcp.c released module
'lmnetstrms', reference count now 2
9937.419384000:main queue:Reg/w0: error forwarding via tcp, suspending
9937.419393000:main queue:Reg/w0: Action requested to be suspended, done
that.
9937.419403000:main queue:Reg/w0: Filter: check for property 'syslogtag'
(value '[ReportingSysLog]') isequal '[QPassReportingSysLog]': FALSE
9937.419416000:main queue:Reg/w0: main queue:Reg/w0: worker IDLE, waiting
for work.
9942.951659000:imudp.c: CmpHost returns 0


Thanks in advance again.

Thanks,
Velu

From david at lang.hm  Fri Dec  9 21:30:22 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 12:30:22 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>

On Fri, 9 Dec 2011, Velu S wrote:

> I am a newbie to Rsyslog and am having a difficult time with configuring
> Rsyslog with TCP.
>
> My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
> centralise log server and logged into mysql DB.
> Every thing works fine when running in TCP. But all the messages from the
> clients are lost when shutdown the server.
> The messages are not buffered in TCP. I have been struck with this for long
> time. Any help is highly appreciated.

With TCP the sender thinks the message has been delivered as soon as it 
passes it to the TCP stack on the sending machine. As a result, when the 
server goes down, any messages that the sender has passed to the TCP 
stack.

To avoid this loss, you will need to use RELP instead of TCP. RELP doesn't 
consider the message delivered until the receiving server acknowledges it.


This is part of the problem you are having.

In addition, you may be having additional problems with your sending 
systems not buffering the messages, but it's a little hard to tell without 
either resolving this issue, or at least quantifying how much of the issue 
is this problem.

> I have pasted the conf files and the log file. I noticed the following:
>
> error forwarding via tcp, suspending.

This is exactly what you would expect to see when the connection goes 
down. The sender will fill up the TCP buffers on the sending machine and 
then it will find that it can't send any more and it will suspend the 
channel.

This is normal and what should be happening. What then should happen when 
the server comes back up is that the sender should notice that it can 
re-establish the connection it should resume the channel

what version of rsyslog are you using on the sender and receiver.

David Lang

From velu1980 at gmail.com  Fri Dec  9 21:43:45 2011
From: velu1980 at gmail.com (Velu S)
Date: Fri, 9 Dec 2011 15:43:45 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
Message-ID: <CALBAy55pOOXpZ0+9i9PT31TQpgh71Rjq580NHNxzB1nsznhRzg@mail.gmail.com>

Hi David,

Thank you very much for your quick reply. I am using rsyslog version 4.4.2
in both sender and receiver.
I guess the TCP message doesn't happen on the sending machine. The messages
are not send even
when the receiver is restarted.  Do i need to set any parameter other than
the parameters in my client
config file to buffer the messages.

*Client config file*

$ModLoad imuxsock             # local message reception
$ModLoad imudp
$ModLoad immark # provides --MARK-- message capability
$ModLoad imklog # provides kernel logging support (previously done by
rklogd)

$EscapeControlCharactersOnReceive off
$RepeatedMsgReduction on
$MarkMessagePeriod 0

#ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # the traditional
forwarding format with low-precision timestamps

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# Log all kernel messages clutters everything
kern.*                                                  ~
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure
# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog
# Log cron stuff
cron.*                                                  /var/log/cron
# Everybody gets emergency messages
*.emerg                                                 *
# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler
# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

$WorkDirectory  /rsyslog/work

$ActionQueueType LinkedList
$ActionQueueFileName srvrfwd  # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
$ActionFileEnableSync   on

*.* @@10.XXX.XX.XX:10514


Thanks,
Anand

On Fri, Dec 9, 2011 at 3:30 PM, <david at lang.hm> wrote:

> On Fri, 9 Dec 2011, Velu S wrote:
>
>  I am a newbie to Rsyslog and am having a difficult time with configuring
>> Rsyslog with TCP.
>>
>> My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
>> centralise log server and logged into mysql DB.
>> Every thing works fine when running in TCP. But all the messages from the
>> clients are lost when shutdown the server.
>> The messages are not buffered in TCP. I have been struck with this for
>> long
>> time. Any help is highly appreciated.
>>
>
> With TCP the sender thinks the message has been delivered as soon as it
> passes it to the TCP stack on the sending machine. As a result, when the
> server goes down, any messages that the sender has passed to the TCP stack.
>
> To avoid this loss, you will need to use RELP instead of TCP. RELP doesn't
> consider the message delivered until the receiving server acknowledges it.
>
>
> This is part of the problem you are having.
>
> In addition, you may be having additional problems with your sending
> systems not buffering the messages, but it's a little hard to tell without
> either resolving this issue, or at least quantifying how much of the issue
> is this problem.
>
>
>  I have pasted the conf files and the log file. I noticed the following:
>>
>> error forwarding via tcp, suspending.
>>
>
> This is exactly what you would expect to see when the connection goes
> down. The sender will fill up the TCP buffers on the sending machine and
> then it will find that it can't send any more and it will suspend the
> channel.
>
> This is normal and what should be happening. What then should happen when
> the server comes back up is that the sender should notice that it can
> re-establish the connection it should resume the channel
>
> what version of rsyslog are you using on the sender and receiver.
>
> David Lang
> ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From david at lang.hm  Fri Dec  9 22:04:44 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 13:04:44 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy55pOOXpZ0+9i9PT31TQpgh71Rjq580NHNxzB1nsznhRzg@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<CALBAy55pOOXpZ0+9i9PT31TQpgh71Rjq580NHNxzB1nsznhRzg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112091302200.29398@asgard.lang.hm>

On Fri, 9 Dec 2011, Velu S wrote:

> Thank you very much for your quick reply. I am using rsyslog version 4.4.2
> in both sender and receiver.

I seem to remember hearing about problems with TCP not restarting the 
dataflow properly and those problems getting fixed sometime in the last 
year or two (4.4.2 is rather old)

if you can go to the latest 5.x it would be best.

David Lang

> I guess the TCP message doesn't happen on the sending machine. The messages
> are not send even
> when the receiver is restarted.  Do i need to set any parameter other than
> the parameters in my client
> config file to buffer the messages.
>
> *Client config file*
>
> $ModLoad imuxsock             # local message reception
> $ModLoad imudp
> $ModLoad immark # provides --MARK-- message capability
> $ModLoad imklog # provides kernel logging support (previously done by
> rklogd)
>
> $EscapeControlCharactersOnReceive off
> $RepeatedMsgReduction on
> $MarkMessagePeriod 0
>
> #ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # the traditional
> forwarding format with low-precision timestamps
>
> *.info;mail.none;authpriv.none;cron.none                /var/log/messages
> # Log all kernel messages clutters everything
> kern.*                                                  ~
> # The authpriv file has restricted access.
> authpriv.*                                              /var/log/secure
> # Log all the mail messages in one place.
> mail.*                                                  -/var/log/maillog
> # Log cron stuff
> cron.*                                                  /var/log/cron
> # Everybody gets emergency messages
> *.emerg                                                 *
> # Save news errors of level crit and higher in a special file.
> uucp,news.crit                                          /var/log/spooler
> # Save boot messages also to boot.log
> local7.*                                                /var/log/boot.log
>
> $WorkDirectory  /rsyslog/work
>
> $ActionQueueType LinkedList
> $ActionQueueFileName srvrfwd  # set file name, also enables disk mode
> $ActionResumeRetryCount -1    # infinite retries on insert failure
> $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
> $ActionFileEnableSync   on
>
> *.* @@10.XXX.XX.XX:10514
>
>
> Thanks,
> Anand
>
> On Fri, Dec 9, 2011 at 3:30 PM, <david at lang.hm> wrote:
>
>> On Fri, 9 Dec 2011, Velu S wrote:
>>
>>  I am a newbie to Rsyslog and am having a difficult time with configuring
>>> Rsyslog with TCP.
>>>
>>> My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
>>> centralise log server and logged into mysql DB.
>>> Every thing works fine when running in TCP. But all the messages from the
>>> clients are lost when shutdown the server.
>>> The messages are not buffered in TCP. I have been struck with this for
>>> long
>>> time. Any help is highly appreciated.
>>>
>>
>> With TCP the sender thinks the message has been delivered as soon as it
>> passes it to the TCP stack on the sending machine. As a result, when the
>> server goes down, any messages that the sender has passed to the TCP stack.
>>
>> To avoid this loss, you will need to use RELP instead of TCP. RELP doesn't
>> consider the message delivered until the receiving server acknowledges it.
>>
>>
>> This is part of the problem you are having.
>>
>> In addition, you may be having additional problems with your sending
>> systems not buffering the messages, but it's a little hard to tell without
>> either resolving this issue, or at least quantifying how much of the issue
>> is this problem.
>>
>>
>>  I have pasted the conf files and the log file. I noticed the following:
>>>
>>> error forwarding via tcp, suspending.
>>>
>>
>> This is exactly what you would expect to see when the connection goes
>> down. The sender will fill up the TCP buffers on the sending machine and
>> then it will find that it can't send any more and it will suspend the
>> channel.
>>
>> This is normal and what should be happening. What then should happen when
>> the server comes back up is that the sender should notice that it can
>> re-establish the connection it should resume the channel
>>
>> what version of rsyslog are you using on the sender and receiver.
>>
>> David Lang
>> ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From velu1980 at gmail.com  Fri Dec  9 22:17:14 2011
From: velu1980 at gmail.com (Velu S)
Date: Fri, 9 Dec 2011 16:17:14 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112091302200.29398@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<CALBAy55pOOXpZ0+9i9PT31TQpgh71Rjq580NHNxzB1nsznhRzg@mail.gmail.com>
	<alpine.DEB.2.02.1112091302200.29398@asgard.lang.hm>
Message-ID: <CALBAy54ba65gOdEM8NJd92rW0_UkJh6q8EWmU=uFufHNT6PMDQ@mail.gmail.com>

Thank you David again for the quick reply. Really appreciate it!! I am
trying to install rsyslog-5.8.5 in my system.
I was able to run sudo ./configure succefully however when i make i get the
following error:
sudo make
make  all-recursive
make[1]: Entering directory `/home/mfadmin/rsyslog-5.8.5'
Making all in doc
make[2]: Entering directory `/home/mfadmin/rsyslog-5.8.5/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/mfadmin/rsyslog-5.8.5/doc'
Making all in runtime
make[2]: Entering directory `/home/mfadmin/rsyslog-5.8.5/runtime'
  CC     librsyslog_la-rsyslog.lo
In file included from stream.h:72,
                 from obj.h:50,
                 from rsyslog.h:452,
                 from rsyslog.c:63:
zlibw.h:28:18: error: zlib.h: No such file or directory
In file included from stream.h:72,
                 from obj.h:50,
                 from rsyslog.h:452,
                 from rsyslog.c:63:
zlibw.h:32: error: expected ')' before 'strm'
zlibw.h:33: error: expected ';' before 'int'
In file included from obj.h:50,
                 from rsyslog.h:452,
                 from rsyslog.c:63:
stream.h:123: error: expected specifier-qualifier-list before 'Bytef'
make[2]: *** [librsyslog_la-rsyslog.lo] Error 1
make[2]: Leaving directory `/home/mfadmin/rsyslog-5.8.5/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mfadmin/rsyslog-5.8.5'
make: *** [all] Error 2

I have made the rsyslog version 4.4.2 same way. It worked fine. Am i
missing any dependencies.

Thanks,
Velu


On Fri, Dec 9, 2011 at 4:04 PM, <david at lang.hm> wrote:

> On Fri, 9 Dec 2011, Velu S wrote:
>
>  Thank you very much for your quick reply. I am using rsyslog version 4.4.2
>> in both sender and receiver.
>>
>
> I seem to remember hearing about problems with TCP not restarting the
> dataflow properly and those problems getting fixed sometime in the last
> year or two (4.4.2 is rather old)
>
> if you can go to the latest 5.x it would be best.
>
> David Lang
>
>  I guess the TCP message doesn't happen on the sending machine. The
>> messages
>> are not send even
>> when the receiver is restarted.  Do i need to set any parameter other than
>> the parameters in my client
>> config file to buffer the messages.
>>
>> *Client config file*
>>
>>
>> $ModLoad imuxsock             # local message reception
>> $ModLoad imudp
>> $ModLoad immark # provides --MARK-- message capability
>> $ModLoad imklog # provides kernel logging support (previously done by
>> rklogd)
>>
>> $**EscapeControlCharactersOnRecei**ve off
>> $RepeatedMsgReduction on
>> $MarkMessagePeriod 0
>>
>> #ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # the traditional
>> forwarding format with low-precision timestamps
>>
>> *.info;mail.none;authpriv.**none;cron.none
>>  /var/log/messages
>> # Log all kernel messages clutters everything
>> kern.*                                                  ~
>> # The authpriv file has restricted access.
>> authpriv.*                                              /var/log/secure
>> # Log all the mail messages in one place.
>> mail.*                                                  -/var/log/maillog
>> # Log cron stuff
>> cron.*                                                  /var/log/cron
>> # Everybody gets emergency messages
>> *.emerg                                                 *
>> # Save news errors of level crit and higher in a special file.
>> uucp,news.crit                                          /var/log/spooler
>> # Save boot messages also to boot.log
>> local7.*                                                /var/log/boot.log
>>
>> $WorkDirectory  /rsyslog/work
>>
>> $ActionQueueType LinkedList
>> $ActionQueueFileName srvrfwd  # set file name, also enables disk mode
>> $ActionResumeRetryCount -1    # infinite retries on insert failure
>> $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
>> $ActionFileEnableSync   on
>>
>> *.* @@10.XXX.XX.XX:10514
>>
>>
>> Thanks,
>> Anand
>>
>> On Fri, Dec 9, 2011 at 3:30 PM, <david at lang.hm> wrote:
>>
>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>
>>>  I am a newbie to Rsyslog and am having a difficult time with configuring
>>>
>>>> Rsyslog with TCP.
>>>>
>>>> My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
>>>> centralise log server and logged into mysql DB.
>>>> Every thing works fine when running in TCP. But all the messages from
>>>> the
>>>> clients are lost when shutdown the server.
>>>> The messages are not buffered in TCP. I have been struck with this for
>>>> long
>>>> time. Any help is highly appreciated.
>>>>
>>>>
>>> With TCP the sender thinks the message has been delivered as soon as it
>>> passes it to the TCP stack on the sending machine. As a result, when the
>>> server goes down, any messages that the sender has passed to the TCP
>>> stack.
>>>
>>> To avoid this loss, you will need to use RELP instead of TCP. RELP
>>> doesn't
>>> consider the message delivered until the receiving server acknowledges
>>> it.
>>>
>>>
>>> This is part of the problem you are having.
>>>
>>> In addition, you may be having additional problems with your sending
>>> systems not buffering the messages, but it's a little hard to tell
>>> without
>>> either resolving this issue, or at least quantifying how much of the
>>> issue
>>> is this problem.
>>>
>>>
>>>  I have pasted the conf files and the log file. I noticed the following:
>>>
>>>>
>>>> error forwarding via tcp, suspending.
>>>>
>>>>
>>> This is exactly what you would expect to see when the connection goes
>>> down. The sender will fill up the TCP buffers on the sending machine and
>>> then it will find that it can't send any more and it will suspend the
>>> channel.
>>>
>>> This is normal and what should be happening. What then should happen when
>>> the server comes back up is that the sender should notice that it can
>>> re-establish the connection it should resume the channel
>>>
>>> what version of rsyslog are you using on the sender and receiver.
>>>
>>> David Lang
>>> ______________________________****_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> >
>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>> >
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>>  ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From david at lang.hm  Fri Dec  9 22:37:47 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 13:37:47 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy54ba65gOdEM8NJd92rW0_UkJh6q8EWmU=uFufHNT6PMDQ@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<CALBAy55pOOXpZ0+9i9PT31TQpgh71Rjq580NHNxzB1nsznhRzg@mail.gmail.com>
	<alpine.DEB.2.02.1112091302200.29398@asgard.lang.hm>
	<CALBAy54ba65gOdEM8NJd92rW0_UkJh6q8EWmU=uFufHNT6PMDQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112091336510.29398@asgard.lang.hm>

this sounds like you are missing the zlib development library. you may not 
have had compression enabled with your 4.x build in the config step.

David Lang

On Fri, 9 Dec 2011, Velu S wrote:

> Date: Fri, 9 Dec 2011 16:17:14 -0500
> From: Velu S <velu1980 at gmail.com>
> Reply-To: rsyslog-users <rsyslog at lists.adiscon.com>
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: Re: [rsyslog] Issues with configuring rsyslog with TCP configuration.
>      Please help
> 
> Thank you David again for the quick reply. Really appreciate it!! I am
> trying to install rsyslog-5.8.5 in my system.
> I was able to run sudo ./configure succefully however when i make i get the
> following error:
> sudo make
> make  all-recursive
> make[1]: Entering directory `/home/mfadmin/rsyslog-5.8.5'
> Making all in doc
> make[2]: Entering directory `/home/mfadmin/rsyslog-5.8.5/doc'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/mfadmin/rsyslog-5.8.5/doc'
> Making all in runtime
> make[2]: Entering directory `/home/mfadmin/rsyslog-5.8.5/runtime'
>  CC     librsyslog_la-rsyslog.lo
> In file included from stream.h:72,
>                 from obj.h:50,
>                 from rsyslog.h:452,
>                 from rsyslog.c:63:
> zlibw.h:28:18: error: zlib.h: No such file or directory
> In file included from stream.h:72,
>                 from obj.h:50,
>                 from rsyslog.h:452,
>                 from rsyslog.c:63:
> zlibw.h:32: error: expected ')' before 'strm'
> zlibw.h:33: error: expected ';' before 'int'
> In file included from obj.h:50,
>                 from rsyslog.h:452,
>                 from rsyslog.c:63:
> stream.h:123: error: expected specifier-qualifier-list before 'Bytef'
> make[2]: *** [librsyslog_la-rsyslog.lo] Error 1
> make[2]: Leaving directory `/home/mfadmin/rsyslog-5.8.5/runtime'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/mfadmin/rsyslog-5.8.5'
> make: *** [all] Error 2
>
> I have made the rsyslog version 4.4.2 same way. It worked fine. Am i
> missing any dependencies.
>
> Thanks,
> Velu
>
>
> On Fri, Dec 9, 2011 at 4:04 PM, <david at lang.hm> wrote:
>
>> On Fri, 9 Dec 2011, Velu S wrote:
>>
>>  Thank you very much for your quick reply. I am using rsyslog version 4.4.2
>>> in both sender and receiver.
>>>
>>
>> I seem to remember hearing about problems with TCP not restarting the
>> dataflow properly and those problems getting fixed sometime in the last
>> year or two (4.4.2 is rather old)
>>
>> if you can go to the latest 5.x it would be best.
>>
>> David Lang
>>
>>  I guess the TCP message doesn't happen on the sending machine. The
>>> messages
>>> are not send even
>>> when the receiver is restarted.  Do i need to set any parameter other than
>>> the parameters in my client
>>> config file to buffer the messages.
>>>
>>> *Client config file*
>>>
>>>
>>> $ModLoad imuxsock             # local message reception
>>> $ModLoad imudp
>>> $ModLoad immark # provides --MARK-- message capability
>>> $ModLoad imklog # provides kernel logging support (previously done by
>>> rklogd)
>>>
>>> $**EscapeControlCharactersOnRecei**ve off
>>> $RepeatedMsgReduction on
>>> $MarkMessagePeriod 0
>>>
>>> #ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # the traditional
>>> forwarding format with low-precision timestamps
>>>
>>> *.info;mail.none;authpriv.**none;cron.none
>>>  /var/log/messages
>>> # Log all kernel messages clutters everything
>>> kern.*                                                  ~
>>> # The authpriv file has restricted access.
>>> authpriv.*                                              /var/log/secure
>>> # Log all the mail messages in one place.
>>> mail.*                                                  -/var/log/maillog
>>> # Log cron stuff
>>> cron.*                                                  /var/log/cron
>>> # Everybody gets emergency messages
>>> *.emerg                                                 *
>>> # Save news errors of level crit and higher in a special file.
>>> uucp,news.crit                                          /var/log/spooler
>>> # Save boot messages also to boot.log
>>> local7.*                                                /var/log/boot.log
>>>
>>> $WorkDirectory  /rsyslog/work
>>>
>>> $ActionQueueType LinkedList
>>> $ActionQueueFileName srvrfwd  # set file name, also enables disk mode
>>> $ActionResumeRetryCount -1    # infinite retries on insert failure
>>> $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
>>> $ActionFileEnableSync   on
>>>
>>> *.* @@10.XXX.XX.XX:10514
>>>
>>>
>>> Thanks,
>>> Anand
>>>
>>> On Fri, Dec 9, 2011 at 3:30 PM, <david at lang.hm> wrote:
>>>
>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>
>>>>  I am a newbie to Rsyslog and am having a difficult time with configuring
>>>>
>>>>> Rsyslog with TCP.
>>>>>
>>>>> My environment : Rsyslog 4.4.2 in RHEL 5. Log messages are logged to a
>>>>> centralise log server and logged into mysql DB.
>>>>> Every thing works fine when running in TCP. But all the messages from
>>>>> the
>>>>> clients are lost when shutdown the server.
>>>>> The messages are not buffered in TCP. I have been struck with this for
>>>>> long
>>>>> time. Any help is highly appreciated.
>>>>>
>>>>>
>>>> With TCP the sender thinks the message has been delivered as soon as it
>>>> passes it to the TCP stack on the sending machine. As a result, when the
>>>> server goes down, any messages that the sender has passed to the TCP
>>>> stack.
>>>>
>>>> To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>> doesn't
>>>> consider the message delivered until the receiving server acknowledges
>>>> it.
>>>>
>>>>
>>>> This is part of the problem you are having.
>>>>
>>>> In addition, you may be having additional problems with your sending
>>>> systems not buffering the messages, but it's a little hard to tell
>>>> without
>>>> either resolving this issue, or at least quantifying how much of the
>>>> issue
>>>> is this problem.
>>>>
>>>>
>>>>  I have pasted the conf files and the log file. I noticed the following:
>>>>
>>>>>
>>>>> error forwarding via tcp, suspending.
>>>>>
>>>>>
>>>> This is exactly what you would expect to see when the connection goes
>>>> down. The sender will fill up the TCP buffers on the sending machine and
>>>> then it will find that it can't send any more and it will suspend the
>>>> channel.
>>>>
>>>> This is normal and what should be happening. What then should happen when
>>>> the server comes back up is that the sender should notice that it can
>>>> re-establish the connection it should resume the channel
>>>>
>>>> what version of rsyslog are you using on the sender and receiver.
>>>>
>>>> David Lang
>>>> ______________________________****_________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>
>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>
>>>>
>>>>  ______________________________**_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From gkra at unnerving.org  Fri Dec  9 22:54:02 2011
From: gkra at unnerving.org (Gregory K. Ruiz-Ade)
Date: Fri, 9 Dec 2011 13:54:02 -0800
Subject: [rsyslog] Issues with configuring rsyslog with TCP
	configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
Message-ID: <AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>

On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:

> To avoid this loss, you will need to use RELP instead of TCP. RELP doesn't consider the message delivered until the receiving server acknowledges it.

I'm currently using TCP delivery because I couldn't make sense of RELP when I put it in place. Currently, I have clients doing:

$WorkDirectory /var/spool/rsyslog
$ActionQueueFileName fwd_queue
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1
*.* @@logserver:1234;SiteIDForwardFormat

Would switching to RELP be as simple as replacing that last line with:

*.* :omrelp:logserver:2345;SiteIDForwardFormat

And adding a RELP listener on the new port on the server?

Thanks,

Gregory

-- 
Gregory K. Ruiz-Ade <gkra at unnerving.org>
OpenPGP Key ID: EAF4844B  keyserver: pgpkeys.mit.edu




From david at lang.hm  Fri Dec  9 23:03:03 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 14:03:03 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with
 TCP	configuration. Please help
In-Reply-To: <AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
Message-ID: <alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>

On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:

> On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>
>> To avoid this loss, you will need to use RELP instead of TCP. RELP doesn't consider the message delivered until the receiving server acknowledges it.
>
> I'm currently using TCP delivery because I couldn't make sense of RELP when I put it in place. Currently, I have clients doing:
>
> $WorkDirectory /var/spool/rsyslog
> $ActionQueueFileName fwd_queue
> $ActionQueueSaveOnShutdown on
> $ActionQueueType LinkedList
> $ActionResumeRetryCount -1
> *.* @@logserver:1234;SiteIDForwardFormat
>
> Would switching to RELP be as simple as replacing that last line with:
>
> *.* :omrelp:logserver:2345;SiteIDForwardFormat
>
> And adding a RELP listener on the new port on the server?

other than the need to load the relp module, it should be about that 
simple.

David Lang

From velu1980 at gmail.com  Fri Dec  9 23:35:38 2011
From: velu1980 at gmail.com (Velu S)
Date: Fri, 9 Dec 2011 17:35:38 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
Message-ID: <CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>

Thank you David again for your quick reply. I installed Rsyslog version
5.8.6 in both the sender and receiver. But My TCP messages are still not
logged when the central server is down. Here is my log snippet:

9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
reference count now 2
9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
9717.969857000:4266b940: earliest retry=1323469718
9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
9717.969877000:4266b940: tryDoAction: unexpected error code -2007[nElem 1,
Commited UpTo 0], finalizing
9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1, nElem 1
9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
next retry (if applicable): 1323469718 [now 1323469717]
9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
9717.969911000:4266b940: tryDoAction: unexpected error code -2123[nElem 1,
Commited UpTo 0], finalizing
9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
next retry (if applicable): 1323469718 [now 1323469717]
9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
9717.969936000:4266b940: Processing next rule


Thanks,
Velu



On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:

> On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>
>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>
>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>> doesn't consider the message delivered until the receiving server
>>> acknowledges it.
>>>
>>
>> I'm currently using TCP delivery because I couldn't make sense of RELP
>> when I put it in place. Currently, I have clients doing:
>>
>> $WorkDirectory /var/spool/rsyslog
>> $ActionQueueFileName fwd_queue
>> $ActionQueueSaveOnShutdown on
>> $ActionQueueType LinkedList
>> $ActionResumeRetryCount -1
>> *.* @@logserver:1234;**SiteIDForwardFormat
>>
>> Would switching to RELP be as simple as replacing that last line with:
>>
>> *.* :omrelp:logserver:2345;**SiteIDForwardFormat
>>
>> And adding a RELP listener on the new port on the server?
>>
>
> other than the need to load the relp module, it should be about that
> simple.
>
> David Lang
>
> ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From david at lang.hm  Sat Dec 10 00:55:05 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 15:55:05 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>

On Fri, 9 Dec 2011, Velu S wrote:

> Thank you David again for your quick reply. I installed Rsyslog version
> 5.8.6 in both the sender and receiver. But My TCP messages are still not
> logged when the central server is down. Here is my log snippet:

OK, I don't understand the problem

while the central server is down I would not expect the messages to be 
logged there. but with a disk assist mode they should show up after the 
server comes up.

I'm getting ready to head out for the evening, but will check in again in 
4-5 hours, so let's try to clarify what's happening.

are you using RELP or just TCP?

In the ideal world, what should happen is:

everything up, logs are written locally and sent to the remote server.

remote server goes down.

with TCP, messages in flight are lost, with RELP nothing is lost

you should see the transport be suspended, and it will retry, failing each 
time and eventually retry less frequently (to keep from wasting resources 
on the sending box)

log messages should still be written locally, but queue up to be sent to 
the remote server later.

   note that if you don't enable the disk assisted queue this will still 
happen, but only up to the point where you fill memory.

verify that logs are still being written locally, and look for files to be 
created in your working directory for the ones queued up to be sent later. 
you may need to generate a bunch of log messages to get to the point where 
they queue to disk.


then bring up the remote server. you should have logs start arriving there 
within a couple minutes, and then the older logs will start arriving.

the debug logs around the time that the remote server comes up should be 
interesting. I don't remember what the retry time is, but I seem to 
remember that by default it includes some sort of logrithmic backoff 
logic, so if you are down for a long time, it may take a long time before 
it decides to try again.

David Lang

> 9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
> reference count now 2
> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
> 9717.969857000:4266b940: earliest retry=1323469718
> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
> 9717.969877000:4266b940: tryDoAction: unexpected error code -2007[nElem 1,
> Commited UpTo 0], finalizing
> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1, nElem 1
> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
> next retry (if applicable): 1323469718 [now 1323469717]
> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
> 9717.969911000:4266b940: tryDoAction: unexpected error code -2123[nElem 1,
> Commited UpTo 0], finalizing
> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
> next retry (if applicable): 1323469718 [now 1323469717]
> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
> 9717.969936000:4266b940: Processing next rule
>
>
> Thanks,
> Velu
>
>
>
> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>
>> On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>
>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>
>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>> doesn't consider the message delivered until the receiving server
>>>> acknowledges it.
>>>>
>>>
>>> I'm currently using TCP delivery because I couldn't make sense of RELP
>>> when I put it in place. Currently, I have clients doing:
>>>
>>> $WorkDirectory /var/spool/rsyslog
>>> $ActionQueueFileName fwd_queue
>>> $ActionQueueSaveOnShutdown on
>>> $ActionQueueType LinkedList
>>> $ActionResumeRetryCount -1
>>> *.* @@logserver:1234;**SiteIDForwardFormat
>>>
>>> Would switching to RELP be as simple as replacing that last line with:
>>>
>>> *.* :omrelp:logserver:2345;**SiteIDForwardFormat
>>>
>>> And adding a RELP listener on the new port on the server?
>>>
>>
>> other than the need to load the relp module, it should be about that
>> simple.
>>
>> David Lang
>>
>> ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From velu1980 at gmail.com  Sat Dec 10 05:49:40 2011
From: velu1980 at gmail.com (Velu S)
Date: Fri, 9 Dec 2011 23:49:40 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
Message-ID: <CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>

Thank you David for the reply. Sorry for not explaining clearly in my
previous emails.
I use disk assisted mode and TCP both on the client and the server. When
all the servers are up everything works fine.
When the server goes down the message send from the client are not logged
in. Thats expected. But these messages are lost even when the server comes
back online. I will get the entire log of the client (When the center goes
down and up).
I haven't tried installing RELP yet. Will try installing it and test the
same scenario again. Thanks again for your timely help and time. Really
appreciate it.

Thanks,
Velu

On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:

> On Fri, 9 Dec 2011, Velu S wrote:
>
>  Thank you David again for your quick reply. I installed Rsyslog version
>> 5.8.6 in both the sender and receiver. But My TCP messages are still not
>> logged when the central server is down. Here is my log snippet:
>>
>
> OK, I don't understand the problem
>
> while the central server is down I would not expect the messages to be
> logged there. but with a disk assist mode they should show up after the
> server comes up.
>
> I'm getting ready to head out for the evening, but will check in again in
> 4-5 hours, so let's try to clarify what's happening.
>
> are you using RELP or just TCP?
>
> In the ideal world, what should happen is:
>
> everything up, logs are written locally and sent to the remote server.
>
> remote server goes down.
>
> with TCP, messages in flight are lost, with RELP nothing is lost
>
> you should see the transport be suspended, and it will retry, failing each
> time and eventually retry less frequently (to keep from wasting resources
> on the sending box)
>
> log messages should still be written locally, but queue up to be sent to
> the remote server later.
>
>  note that if you don't enable the disk assisted queue this will still
> happen, but only up to the point where you fill memory.
>
> verify that logs are still being written locally, and look for files to be
> created in your working directory for the ones queued up to be sent later.
> you may need to generate a bunch of log messages to get to the point where
> they queue to disk.
>
>
> then bring up the remote server. you should have logs start arriving there
> within a couple minutes, and then the older logs will start arriving.
>
> the debug logs around the time that the remote server comes up should be
> interesting. I don't remember what the retry time is, but I seem to
> remember that by default it includes some sort of logrithmic backoff logic,
> so if you are down for a long time, it may take a long time before it
> decides to try again.
>
> David Lang
>
>  9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
>> reference count now 2
>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
>> 9717.969857000:4266b940: earliest retry=1323469718
>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>> 9717.969877000:4266b940: tryDoAction: unexpected error code -2007[nElem 1,
>> Commited UpTo 0], finalizing
>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1, nElem 1
>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>> next retry (if applicable): 1323469718 [now 1323469717]
>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>> 9717.969911000:4266b940: tryDoAction: unexpected error code -2123[nElem 1,
>> Commited UpTo 0], finalizing
>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>> next retry (if applicable): 1323469718 [now 1323469717]
>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>> 9717.969936000:4266b940: Processing next rule
>>
>>
>> Thanks,
>> Velu
>>
>>
>>
>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>
>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>
>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>
>>>>
>>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>
>>>>> doesn't consider the message delivered until the receiving server
>>>>> acknowledges it.
>>>>>
>>>>>
>>>> I'm currently using TCP delivery because I couldn't make sense of RELP
>>>> when I put it in place. Currently, I have clients doing:
>>>>
>>>> $WorkDirectory /var/spool/rsyslog
>>>> $ActionQueueFileName fwd_queue
>>>> $ActionQueueSaveOnShutdown on
>>>> $ActionQueueType LinkedList
>>>> $ActionResumeRetryCount -1
>>>> *.* @@logserver:1234;****SiteIDForwardFormat
>>>>
>>>>
>>>> Would switching to RELP be as simple as replacing that last line with:
>>>>
>>>> *.* :omrelp:logserver:2345;****SiteIDForwardFormat
>>>>
>>>>
>>>> And adding a RELP listener on the new port on the server?
>>>>
>>>>
>>> other than the need to load the relp module, it should be about that
>>> simple.
>>>
>>> David Lang
>>>
>>> ______________________________****_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> >
>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>> >
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>>  ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From david at lang.hm  Sat Dec 10 06:23:08 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 9 Dec 2011 21:23:08 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>

On Fri, 9 Dec 2011, Velu S wrote:

> Thank you David for the reply. Sorry for not explaining clearly in my
> previous emails.
> I use disk assisted mode and TCP both on the client and the server. When
> all the servers are up everything works fine.
> When the server goes down the message send from the client are not logged
> in. Thats expected. But these messages are lost even when the server comes
> back online. I will get the entire log of the client (When the center goes
> down and up).

Ok, then the first thing that I would do to troubleshoot this is to 
simplify things.

try removing all of the actionqueue configuraiton entries and see what 
happens. you will only be able to store a relativly small number of 
messages before things block, but if you stop the server, wait until you 
get the suspend message, and then startup the server again, you should see 
the messages resume. If not, there is some sort of retry option that will 
need to be set

after we have the suspend/resume function working, then the next thing to 
do is configure the main queue to be disk assisted (even if you want a 
separate action queue eventually, changing the main queue is changing 
fewer things). make sure that when there are enough messages queued that 
without the disk assist things would block, you instead have files created 
in your work directory and that after the server is restarted, it gets the 
messages.

only at this point (where we know that suspend/resume works, and we know 
that a disk assisted queue works), would I then change the main queue back 
to the default and create an action queue.

David Lang

> I haven't tried installing RELP yet. Will try installing it and test the
> same scenario again. Thanks again for your timely help and time. Really
> appreciate it.
>
> Thanks,
> Velu
>
> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>
>> On Fri, 9 Dec 2011, Velu S wrote:
>>
>>  Thank you David again for your quick reply. I installed Rsyslog version
>>> 5.8.6 in both the sender and receiver. But My TCP messages are still not
>>> logged when the central server is down. Here is my log snippet:
>>>
>>
>> OK, I don't understand the problem
>>
>> while the central server is down I would not expect the messages to be
>> logged there. but with a disk assist mode they should show up after the
>> server comes up.
>>
>> I'm getting ready to head out for the evening, but will check in again in
>> 4-5 hours, so let's try to clarify what's happening.
>>
>> are you using RELP or just TCP?
>>
>> In the ideal world, what should happen is:
>>
>> everything up, logs are written locally and sent to the remote server.
>>
>> remote server goes down.
>>
>> with TCP, messages in flight are lost, with RELP nothing is lost
>>
>> you should see the transport be suspended, and it will retry, failing each
>> time and eventually retry less frequently (to keep from wasting resources
>> on the sending box)
>>
>> log messages should still be written locally, but queue up to be sent to
>> the remote server later.
>>
>>  note that if you don't enable the disk assisted queue this will still
>> happen, but only up to the point where you fill memory.
>>
>> verify that logs are still being written locally, and look for files to be
>> created in your working directory for the ones queued up to be sent later.
>> you may need to generate a bunch of log messages to get to the point where
>> they queue to disk.
>>
>>
>> then bring up the remote server. you should have logs start arriving there
>> within a couple minutes, and then the older logs will start arriving.
>>
>> the debug logs around the time that the remote server comes up should be
>> interesting. I don't remember what the retry time is, but I seem to
>> remember that by default it includes some sort of logrithmic backoff logic,
>> so if you are down for a long time, it may take a long time before it
>> decides to try again.
>>
>> David Lang
>>
>>  9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
>>> reference count now 2
>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
>>> 9717.969857000:4266b940: earliest retry=1323469718
>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>> 9717.969877000:4266b940: tryDoAction: unexpected error code -2007[nElem 1,
>>> Commited UpTo 0], finalizing
>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1, nElem 1
>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>>> next retry (if applicable): 1323469718 [now 1323469717]
>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>> 9717.969911000:4266b940: tryDoAction: unexpected error code -2123[nElem 1,
>>> Commited UpTo 0], finalizing
>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>>> next retry (if applicable): 1323469718 [now 1323469717]
>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>> 9717.969936000:4266b940: Processing next rule
>>>
>>>
>>> Thanks,
>>> Velu
>>>
>>>
>>>
>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>
>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>
>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>
>>>>>
>>>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>>
>>>>>> doesn't consider the message delivered until the receiving server
>>>>>> acknowledges it.
>>>>>>
>>>>>>
>>>>> I'm currently using TCP delivery because I couldn't make sense of RELP
>>>>> when I put it in place. Currently, I have clients doing:
>>>>>
>>>>> $WorkDirectory /var/spool/rsyslog
>>>>> $ActionQueueFileName fwd_queue
>>>>> $ActionQueueSaveOnShutdown on
>>>>> $ActionQueueType LinkedList
>>>>> $ActionResumeRetryCount -1
>>>>> *.* @@logserver:1234;****SiteIDForwardFormat
>>>>>
>>>>>
>>>>> Would switching to RELP be as simple as replacing that last line with:
>>>>>
>>>>> *.* :omrelp:logserver:2345;****SiteIDForwardFormat
>>>>>
>>>>>
>>>>> And adding a RELP listener on the new port on the server?
>>>>>
>>>>>
>>>> other than the need to load the relp module, it should be about that
>>>> simple.
>>>>
>>>> David Lang
>>>>
>>>> ______________________________****_________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>
>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>
>>>>
>>>>  ______________________________**_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From velu1980 at gmail.com  Sat Dec 10 06:56:34 2011
From: velu1980 at gmail.com (Velu S)
Date: Sat, 10 Dec 2011 00:56:34 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
	<alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
Message-ID: <CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>

Thank you David again for the help. Here is what i tried. The messages are
still not buffered when the central server is down.
I disabled all the action queue messages. I restarted both the sender and
receiver.
When both servers are up the messages gets logged in fine, but when the
central server is down,
the messages don't get logged in. I tried by setting the
following parameters on, but still couldn't succed:

$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionFileEnableSync   on
$ActionSendResendLastMsgOnReconnect     on



Thanks,
Anand


On Sat, Dec 10, 2011 at 12:23 AM, <david at lang.hm> wrote:

> On Fri, 9 Dec 2011, Velu S wrote:
>
>  Thank you David for the reply. Sorry for not explaining clearly in my
>> previous emails.
>> I use disk assisted mode and TCP both on the client and the server. When
>> all the servers are up everything works fine.
>> When the server goes down the message send from the client are not logged
>> in. Thats expected. But these messages are lost even when the server comes
>> back online. I will get the entire log of the client (When the center goes
>> down and up).
>>
>
> Ok, then the first thing that I would do to troubleshoot this is to
> simplify things.
>
> try removing all of the actionqueue configuraiton entries and see what
> happens. you will only be able to store a relativly small number of
> messages before things block, but if you stop the server, wait until you
> get the suspend message, and then startup the server again, you should see
> the messages resume. If not, there is some sort of retry option that will
> need to be set
>
> after we have the suspend/resume function working, then the next thing to
> do is configure the main queue to be disk assisted (even if you want a
> separate action queue eventually, changing the main queue is changing fewer
> things). make sure that when there are enough messages queued that without
> the disk assist things would block, you instead have files created in your
> work directory and that after the server is restarted, it gets the messages.
>
> only at this point (where we know that suspend/resume works, and we know
> that a disk assisted queue works), would I then change the main queue back
> to the default and create an action queue.
>
> David Lang
>
>  I haven't tried installing RELP yet. Will try installing it and test the
>> same scenario again. Thanks again for your timely help and time. Really
>> appreciate it.
>>
>> Thanks,
>> Velu
>>
>> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>>
>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>
>>>  Thank you David again for your quick reply. I installed Rsyslog version
>>>
>>>> 5.8.6 in both the sender and receiver. But My TCP messages are still not
>>>> logged when the central server is down. Here is my log snippet:
>>>>
>>>>
>>> OK, I don't understand the problem
>>>
>>> while the central server is down I would not expect the messages to be
>>> logged there. but with a disk assist mode they should show up after the
>>> server comes up.
>>>
>>> I'm getting ready to head out for the evening, but will check in again in
>>> 4-5 hours, so let's try to clarify what's happening.
>>>
>>> are you using RELP or just TCP?
>>>
>>> In the ideal world, what should happen is:
>>>
>>> everything up, logs are written locally and sent to the remote server.
>>>
>>> remote server goes down.
>>>
>>> with TCP, messages in flight are lost, with RELP nothing is lost
>>>
>>> you should see the transport be suspended, and it will retry, failing
>>> each
>>> time and eventually retry less frequently (to keep from wasting resources
>>> on the sending box)
>>>
>>> log messages should still be written locally, but queue up to be sent to
>>> the remote server later.
>>>
>>>  note that if you don't enable the disk assisted queue this will still
>>> happen, but only up to the point where you fill memory.
>>>
>>> verify that logs are still being written locally, and look for files to
>>> be
>>> created in your working directory for the ones queued up to be sent
>>> later.
>>> you may need to generate a bunch of log messages to get to the point
>>> where
>>> they queue to disk.
>>>
>>>
>>> then bring up the remote server. you should have logs start arriving
>>> there
>>> within a couple minutes, and then the older logs will start arriving.
>>>
>>> the debug logs around the time that the remote server comes up should be
>>> interesting. I don't remember what the retry time is, but I seem to
>>> remember that by default it includes some sort of logrithmic backoff
>>> logic,
>>> so if you are down for a long time, it may take a long time before it
>>> decides to try again.
>>>
>>> David Lang
>>>
>>>  9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
>>>
>>>> reference count now 2
>>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
>>>> 9717.969857000:4266b940: earliest retry=1323469718
>>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>>> 9717.969877000:4266b940: tryDoAction: unexpected error code -2007[nElem
>>>> 1,
>>>> Commited UpTo 0], finalizing
>>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1,
>>>> nElem 1
>>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>>> 9717.969911000:4266b940: tryDoAction: unexpected error code -2123[nElem
>>>> 1,
>>>> Commited UpTo 0], finalizing
>>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state: susp,
>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>>> 9717.969936000:4266b940: Processing next rule
>>>>
>>>>
>>>> Thanks,
>>>> Velu
>>>>
>>>>
>>>>
>>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>>
>>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>
>>>>>
>>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>>
>>>>>
>>>>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>>>
>>>>>>  doesn't consider the message delivered until the receiving server
>>>>>>> acknowledges it.
>>>>>>>
>>>>>>>
>>>>>>>  I'm currently using TCP delivery because I couldn't make sense of
>>>>>> RELP
>>>>>> when I put it in place. Currently, I have clients doing:
>>>>>>
>>>>>> $WorkDirectory /var/spool/rsyslog
>>>>>> $ActionQueueFileName fwd_queue
>>>>>> $ActionQueueSaveOnShutdown on
>>>>>> $ActionQueueType LinkedList
>>>>>> $ActionResumeRetryCount -1
>>>>>> *.* @@logserver:1234;******SiteIDForwardFormat
>>>>>>
>>>>>>
>>>>>>
>>>>>> Would switching to RELP be as simple as replacing that last line with:
>>>>>>
>>>>>> *.* :omrelp:logserver:2345;******SiteIDForwardFormat
>>>>>>
>>>>>>
>>>>>>
>>>>>> And adding a RELP listener on the new port on the server?
>>>>>>
>>>>>>
>>>>>>  other than the need to load the relp module, it should be about that
>>>>> simple.
>>>>>
>>>>> David Lang
>>>>>
>>>>> ______________________________******_________________
>>>>> rsyslog mailing list
>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>> >
>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>> >
>>>>>
>>>>>>
>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>> >
>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>> >
>>>>>
>>>>>>
>>>>>>
>>>>>  ______________________________****_________________
>>>>>
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>> >
>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>> >
>>>>
>>>>  ______________________________****_________________
>>>>
>>> rsyslog mailing list
>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> >
>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>> >
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>>  ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From velu1980 at gmail.com  Sat Dec 10 07:22:37 2011
From: velu1980 at gmail.com (Velu S)
Date: Sat, 10 Dec 2011 01:22:37 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
	<alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
	<CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>
Message-ID: <CALBAy55aFX=rQkMXC0R9cPjZQX2m0=tWeGq4_GQnfwX2L3SVCQ@mail.gmail.com>

Hi,

Btw i tried the RELP installation too in Rsyslog 5.8.6. I was configure,
make and make install from the tar file. But
When i start the server in debug mode i get the following error:

dlopen: /usr/local/lib/rsyslog/imrelp.so: cannot open shared object file:
No such file or directory

Is there any additional steps i need to take for installing RELP and make
it work. Here is my Server config for RELP:

$ModLoad imtcp
$ModLoad immark   # provides --MARK-- message capability
$ModLoad imuxsock # provides support for local system logging (e.g. via
logger command)
$ModLoad imklog   # kernel logging (formerly provided by rklogd)
$ModLoad imudp    # provides UDP syslog reception
$ModLoad MySQL
$ModLoad imrelp


#InputTCPMaxSessions 500
$InputTCPServerRun 10514

$InputRELPServerRun     10514

$SystemLogSocketFlowControl on
$SystemLogSocketName syslog

$EscapeControlCharactersOnReceive off

Thanks,
Velu

On Sat, Dec 10, 2011 at 12:56 AM, Velu S <velu1980 at gmail.com> wrote:

> Thank you David again for the help. Here is what i tried. The messages are
> still not buffered when the central server is down.
> I disabled all the action queue messages. I restarted both the sender and
> receiver.
> When both servers are up the messages gets logged in fine, but when the
> central server is down,
> the messages don't get logged in. I tried by setting the
> following parameters on, but still couldn't succed:
>
> $ActionResumeRetryCount -1    # infinite retries on insert failure
> $ActionFileEnableSync   on
> $ActionSendResendLastMsgOnReconnect     on
>
>
>
> Thanks,
> Anand
>
>
> On Sat, Dec 10, 2011 at 12:23 AM, <david at lang.hm> wrote:
>
>> On Fri, 9 Dec 2011, Velu S wrote:
>>
>>  Thank you David for the reply. Sorry for not explaining clearly in my
>>> previous emails.
>>> I use disk assisted mode and TCP both on the client and the server. When
>>> all the servers are up everything works fine.
>>> When the server goes down the message send from the client are not logged
>>> in. Thats expected. But these messages are lost even when the server
>>> comes
>>> back online. I will get the entire log of the client (When the center
>>> goes
>>> down and up).
>>>
>>
>> Ok, then the first thing that I would do to troubleshoot this is to
>> simplify things.
>>
>> try removing all of the actionqueue configuraiton entries and see what
>> happens. you will only be able to store a relativly small number of
>> messages before things block, but if you stop the server, wait until you
>> get the suspend message, and then startup the server again, you should see
>> the messages resume. If not, there is some sort of retry option that will
>> need to be set
>>
>> after we have the suspend/resume function working, then the next thing to
>> do is configure the main queue to be disk assisted (even if you want a
>> separate action queue eventually, changing the main queue is changing fewer
>> things). make sure that when there are enough messages queued that without
>> the disk assist things would block, you instead have files created in your
>> work directory and that after the server is restarted, it gets the messages.
>>
>> only at this point (where we know that suspend/resume works, and we know
>> that a disk assisted queue works), would I then change the main queue back
>> to the default and create an action queue.
>>
>> David Lang
>>
>>  I haven't tried installing RELP yet. Will try installing it and test the
>>> same scenario again. Thanks again for your timely help and time. Really
>>> appreciate it.
>>>
>>> Thanks,
>>> Velu
>>>
>>> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>>>
>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>
>>>>  Thank you David again for your quick reply. I installed Rsyslog version
>>>>
>>>>> 5.8.6 in both the sender and receiver. But My TCP messages are still
>>>>> not
>>>>> logged when the central server is down. Here is my log snippet:
>>>>>
>>>>>
>>>> OK, I don't understand the problem
>>>>
>>>> while the central server is down I would not expect the messages to be
>>>> logged there. but with a disk assist mode they should show up after the
>>>> server comes up.
>>>>
>>>> I'm getting ready to head out for the evening, but will check in again
>>>> in
>>>> 4-5 hours, so let's try to clarify what's happening.
>>>>
>>>> are you using RELP or just TCP?
>>>>
>>>> In the ideal world, what should happen is:
>>>>
>>>> everything up, logs are written locally and sent to the remote server.
>>>>
>>>> remote server goes down.
>>>>
>>>> with TCP, messages in flight are lost, with RELP nothing is lost
>>>>
>>>> you should see the transport be suspended, and it will retry, failing
>>>> each
>>>> time and eventually retry less frequently (to keep from wasting
>>>> resources
>>>> on the sending box)
>>>>
>>>> log messages should still be written locally, but queue up to be sent to
>>>> the remote server later.
>>>>
>>>>  note that if you don't enable the disk assisted queue this will still
>>>> happen, but only up to the point where you fill memory.
>>>>
>>>> verify that logs are still being written locally, and look for files to
>>>> be
>>>> created in your working directory for the ones queued up to be sent
>>>> later.
>>>> you may need to generate a bunch of log messages to get to the point
>>>> where
>>>> they queue to disk.
>>>>
>>>>
>>>> then bring up the remote server. you should have logs start arriving
>>>> there
>>>> within a couple minutes, and then the older logs will start arriving.
>>>>
>>>> the debug logs around the time that the remote server comes up should be
>>>> interesting. I don't remember what the retry time is, but I seem to
>>>> remember that by default it includes some sort of logrithmic backoff
>>>> logic,
>>>> so if you are down for a long time, it may take a long time before it
>>>> decides to try again.
>>>>
>>>> David Lang
>>>>
>>>>  9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
>>>>
>>>>> reference count now 2
>>>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
>>>>> 9717.969857000:4266b940: earliest retry=1323469718
>>>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>>>> 9717.969877000:4266b940: tryDoAction: unexpected error code
>>>>> -2007[nElem 1,
>>>>> Commited UpTo 0], finalizing
>>>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1,
>>>>> nElem 1
>>>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>> susp,
>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>>>> 9717.969911000:4266b940: tryDoAction: unexpected error code
>>>>> -2123[nElem 1,
>>>>> Commited UpTo 0], finalizing
>>>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>> susp,
>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>>>> 9717.969936000:4266b940: Processing next rule
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Velu
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>>>
>>>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>>
>>>>>>
>>>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>>>
>>>>>>
>>>>>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>>>>
>>>>>>>  doesn't consider the message delivered until the receiving server
>>>>>>>> acknowledges it.
>>>>>>>>
>>>>>>>>
>>>>>>>>  I'm currently using TCP delivery because I couldn't make sense of
>>>>>>> RELP
>>>>>>> when I put it in place. Currently, I have clients doing:
>>>>>>>
>>>>>>> $WorkDirectory /var/spool/rsyslog
>>>>>>> $ActionQueueFileName fwd_queue
>>>>>>> $ActionQueueSaveOnShutdown on
>>>>>>> $ActionQueueType LinkedList
>>>>>>> $ActionResumeRetryCount -1
>>>>>>> *.* @@logserver:1234;******SiteIDForwardFormat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Would switching to RELP be as simple as replacing that last line
>>>>>>> with:
>>>>>>>
>>>>>>> *.* :omrelp:logserver:2345;******SiteIDForwardFormat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> And adding a RELP listener on the new port on the server?
>>>>>>>
>>>>>>>
>>>>>>>  other than the need to load the relp module, it should be about that
>>>>>> simple.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>> ______________________________******_________________
>>>>>> rsyslog mailing list
>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>> >
>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>> >
>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>  ______________________________****_________________
>>>>>>
>>>>> rsyslog mailing list
>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>> >
>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>> >
>>>>>
>>>>>  ______________________________****_________________
>>>>>
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>> >
>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>> >
>>>>
>>>>  ______________________________**_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>
>

From david at lang.hm  Sat Dec 10 14:08:37 2011
From: david at lang.hm (david at lang.hm)
Date: Sat, 10 Dec 2011 05:08:37 -0800 (PST)
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy55aFX=rQkMXC0R9cPjZQX2m0=tWeGq4_GQnfwX2L3SVCQ@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
	<alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
	<CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>
	<CALBAy55aFX=rQkMXC0R9cPjZQX2m0=tWeGq4_GQnfwX2L3SVCQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112100507400.9718@asgard.lang.hm>

On Sat, 10 Dec 2011, Velu S wrote:

>
> Btw i tried the RELP installation too in Rsyslog 5.8.6. I was configure,
> make and make install from the tar file. But
> When i start the server in debug mode i get the following error:
>
> dlopen: /usr/local/lib/rsyslog/imrelp.so: cannot open shared object file:
> No such file or directory
>
> Is there any additional steps i need to take for installing RELP and make
> it work. Here is my Server config for RELP:

it sounds as if it's not compiled in. go back to the configure step and 
look at it's final output to see if you have relp enabled. you may need to 
do --enable-relp to make it compile.

David Lang

> $ModLoad imtcp
> $ModLoad immark   # provides --MARK-- message capability
> $ModLoad imuxsock # provides support for local system logging (e.g. via
> logger command)
> $ModLoad imklog   # kernel logging (formerly provided by rklogd)
> $ModLoad imudp    # provides UDP syslog reception
> $ModLoad MySQL
> $ModLoad imrelp
>
>
> #InputTCPMaxSessions 500
> $InputTCPServerRun 10514
>
> $InputRELPServerRun     10514
>
> $SystemLogSocketFlowControl on
> $SystemLogSocketName syslog
>
> $EscapeControlCharactersOnReceive off
>
> Thanks,
> Velu
>
> On Sat, Dec 10, 2011 at 12:56 AM, Velu S <velu1980 at gmail.com> wrote:
>
>> Thank you David again for the help. Here is what i tried. The messages are
>> still not buffered when the central server is down.
>> I disabled all the action queue messages. I restarted both the sender and
>> receiver.
>> When both servers are up the messages gets logged in fine, but when the
>> central server is down,
>> the messages don't get logged in. I tried by setting the
>> following parameters on, but still couldn't succed:
>>
>> $ActionResumeRetryCount -1    # infinite retries on insert failure
>> $ActionFileEnableSync   on
>> $ActionSendResendLastMsgOnReconnect     on
>>
>>
>>
>> Thanks,
>> Anand
>>
>>
>> On Sat, Dec 10, 2011 at 12:23 AM, <david at lang.hm> wrote:
>>
>>> On Fri, 9 Dec 2011, Velu S wrote:
>>>
>>>  Thank you David for the reply. Sorry for not explaining clearly in my
>>>> previous emails.
>>>> I use disk assisted mode and TCP both on the client and the server. When
>>>> all the servers are up everything works fine.
>>>> When the server goes down the message send from the client are not logged
>>>> in. Thats expected. But these messages are lost even when the server
>>>> comes
>>>> back online. I will get the entire log of the client (When the center
>>>> goes
>>>> down and up).
>>>>
>>>
>>> Ok, then the first thing that I would do to troubleshoot this is to
>>> simplify things.
>>>
>>> try removing all of the actionqueue configuraiton entries and see what
>>> happens. you will only be able to store a relativly small number of
>>> messages before things block, but if you stop the server, wait until you
>>> get the suspend message, and then startup the server again, you should see
>>> the messages resume. If not, there is some sort of retry option that will
>>> need to be set
>>>
>>> after we have the suspend/resume function working, then the next thing to
>>> do is configure the main queue to be disk assisted (even if you want a
>>> separate action queue eventually, changing the main queue is changing fewer
>>> things). make sure that when there are enough messages queued that without
>>> the disk assist things would block, you instead have files created in your
>>> work directory and that after the server is restarted, it gets the messages.
>>>
>>> only at this point (where we know that suspend/resume works, and we know
>>> that a disk assisted queue works), would I then change the main queue back
>>> to the default and create an action queue.
>>>
>>> David Lang
>>>
>>>  I haven't tried installing RELP yet. Will try installing it and test the
>>>> same scenario again. Thanks again for your timely help and time. Really
>>>> appreciate it.
>>>>
>>>> Thanks,
>>>> Velu
>>>>
>>>> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>>>>
>>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>>
>>>>>  Thank you David again for your quick reply. I installed Rsyslog version
>>>>>
>>>>>> 5.8.6 in both the sender and receiver. But My TCP messages are still
>>>>>> not
>>>>>> logged when the central server is down. Here is my log snippet:
>>>>>>
>>>>>>
>>>>> OK, I don't understand the problem
>>>>>
>>>>> while the central server is down I would not expect the messages to be
>>>>> logged there. but with a disk assist mode they should show up after the
>>>>> server comes up.
>>>>>
>>>>> I'm getting ready to head out for the evening, but will check in again
>>>>> in
>>>>> 4-5 hours, so let's try to clarify what's happening.
>>>>>
>>>>> are you using RELP or just TCP?
>>>>>
>>>>> In the ideal world, what should happen is:
>>>>>
>>>>> everything up, logs are written locally and sent to the remote server.
>>>>>
>>>>> remote server goes down.
>>>>>
>>>>> with TCP, messages in flight are lost, with RELP nothing is lost
>>>>>
>>>>> you should see the transport be suspended, and it will retry, failing
>>>>> each
>>>>> time and eventually retry less frequently (to keep from wasting
>>>>> resources
>>>>> on the sending box)
>>>>>
>>>>> log messages should still be written locally, but queue up to be sent to
>>>>> the remote server later.
>>>>>
>>>>>  note that if you don't enable the disk assisted queue this will still
>>>>> happen, but only up to the point where you fill memory.
>>>>>
>>>>> verify that logs are still being written locally, and look for files to
>>>>> be
>>>>> created in your working directory for the ones queued up to be sent
>>>>> later.
>>>>> you may need to generate a bunch of log messages to get to the point
>>>>> where
>>>>> they queue to disk.
>>>>>
>>>>>
>>>>> then bring up the remote server. you should have logs start arriving
>>>>> there
>>>>> within a couple minutes, and then the older logs will start arriving.
>>>>>
>>>>> the debug logs around the time that the remote server comes up should be
>>>>> interesting. I don't remember what the retry time is, but I seem to
>>>>> remember that by default it includes some sort of logrithmic backoff
>>>>> logic,
>>>>> so if you are down for a long time, it may take a long time before it
>>>>> decides to try again.
>>>>>
>>>>> David Lang
>>>>>
>>>>>  9717.969783000:4266b940: file nsd_ptcp.c released module 'lmnetstrms',
>>>>>
>>>>>> reference count now 2
>>>>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state: susp
>>>>>> 9717.969857000:4266b940: earliest retry=1323469718
>>>>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>>>>> 9717.969877000:4266b940: tryDoAction: unexpected error code
>>>>>> -2007[nElem 1,
>>>>>> Commited UpTo 0], finalizing
>>>>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1,
>>>>>> nElem 1
>>>>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>> susp,
>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>>>>> 9717.969911000:4266b940: tryDoAction: unexpected error code
>>>>>> -2123[nElem 1,
>>>>>> Commited UpTo 0], finalizing
>>>>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>> susp,
>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>>>>> 9717.969936000:4266b940: Processing next rule
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Velu
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>>>>
>>>>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>>>
>>>>>>>
>>>>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>>>>
>>>>>>>
>>>>>>>>  To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>>>>>
>>>>>>>>  doesn't consider the message delivered until the receiving server
>>>>>>>>> acknowledges it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  I'm currently using TCP delivery because I couldn't make sense of
>>>>>>>> RELP
>>>>>>>> when I put it in place. Currently, I have clients doing:
>>>>>>>>
>>>>>>>> $WorkDirectory /var/spool/rsyslog
>>>>>>>> $ActionQueueFileName fwd_queue
>>>>>>>> $ActionQueueSaveOnShutdown on
>>>>>>>> $ActionQueueType LinkedList
>>>>>>>> $ActionResumeRetryCount -1
>>>>>>>> *.* @@logserver:1234;******SiteIDForwardFormat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Would switching to RELP be as simple as replacing that last line
>>>>>>>> with:
>>>>>>>>
>>>>>>>> *.* :omrelp:logserver:2345;******SiteIDForwardFormat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> And adding a RELP listener on the new port on the server?
>>>>>>>>
>>>>>>>>
>>>>>>>>  other than the need to load the relp module, it should be about that
>>>>>>> simple.
>>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>> ______________________________******_________________
>>>>>>> rsyslog mailing list
>>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>>>
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>>
>>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>  ______________________________****_________________
>>>>>>>
>>>>>> rsyslog mailing list
>>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>>
>>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>>>
>>>>>>
>>>>>>  ______________________________****_________________
>>>>>>
>>>>> rsyslog mailing list
>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>
>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>>
>>>>>
>>>>>  ______________________________**_________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>
>>>>  ______________________________**_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>
>>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From rgerhards at hq.adiscon.com  Mon Dec 12 18:50:38 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 12 Dec 2011 18:50:38 +0100
Subject: [rsyslog] LogTools initial public release
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281605@GRFEXC.intern.adiscon.com>

Hi all,

I have just released the initial version of LogTools. Right now, it provides
the new, hash-chained log store. While it is closely related to rsyslog (and
can be used with it), it offers the functionality in a separate set of tools.
That way it is accessible to a broader range of users and applications (one
may, for example, think about doing some -late- hashing during logrotate). It
can be used with rsyslog's omprog output module (doc on this will be
available soon).

The release announcement is available here:

http://www.logtools.org/2011/12/12/logtools-0-1-0-released/

I would appreciate feedback, and I would also appreciate if you could pass
the link along to folks that may be interested in this project (but not
necessarily in rsyslog).

Thanks,
Rainer



From bodik at civ.zcu.cz  Mon Dec 12 23:46:22 2011
From: bodik at civ.zcu.cz (bodik)
Date: Mon, 12 Dec 2011 23:46:22 +0100
Subject: [rsyslog] omgssapi segfault
Message-ID: <4EE6843E.7040905@civ.zcu.cz>

Hello,

we'r considering rsyslog as a new central syslogging daemon in our 
heavily kerberized environment. I managed to put omgssapi and imgssapi 
to work, but found that omgssapi segfaults when central server is 
offline for some seconds and then comes back online (eg. restart ...) 
stacktrace is down below.

it looks like wired behavior since omgssapi.c:367 states that this 
should not happen ;)

omgssapi.c:367
        case eDestFORW:
                 /* rgerhards, 2007-09-11: this can not happen, but I've 
included it to
                  * a) make the compiler happy, b) detect any logic 
errors */
                 assert(0); <<<<<<<<<<<<<< line 367
                 break;



I'm not familiar with rsyslog internals to figure out whats going on 
there, so i'd like to ask:


* are gssapi plugins ment to be in usable state or it's kind of beta 
while it's not even maintained by rgerhards ?
   http://lists.adiscon.net/pipermail/rsyslog/2011-July/013472.html


* or if it would be better to hook gss into librelp ? since than we can 
leverage relp and gss at the same time ...


* or use some kind of external gss tunel ?



Thanks for any ideas

Best regards
Radoslav Bodo



---------------

#0  0x00007ff450277165 in raise (sig=<value optimized out>) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ff450279f70 in abort () at abort.c:92
#2  0x00000000004246e7 in sigsegvHdlr (signum=6) at debug.c:832
#3  <signal handler called>
#4  0x00007ff450277165 in raise (sig=<value optimized out>) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5  0x00007ff450279f70 in abort () at abort.c:92
#6  0x00007ff4502702b1 in __assert_fail (assertion=0x7ff44f19d667 "0", 
file=<value optimized out>, line=367, function=0x7ff44f19dc12 
"doTryResume") at assert.c:81
#7  0x00007ff44f19c367 in doTryResume (pData=0x12d5700) at omgssapi.c:367
#8  0x0000000000442dfa in actionDoRetry (pThis=0x12d6080, 
pbShutdownImmediate=0x12d61e0) at ../action.c:574
#9  actionTryResume (pThis=0x12d6080, pbShutdownImmediate=0x12d61e0) at 
../action.c:638
#10 0x000000000044371e in actionPrepare (pAction=0x12d6080, 
pBatch=0x12d57c0, nElem=1) at ../action.c:660
#11 actionProcessMessage (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1) 
at ../action.c:876
#12 tryDoAction (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1) at 
../action.c:973
#13 submitBatch (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1) at 
../action.c:1049
#14 0x0000000000443ce0 in processAction (pAction=0x12d6080, 
pBatch=0x12d57c0, pbShutdownImmediate=<value optimized out>) at 
../action.c:1139
#15 processBatchMain (pAction=0x12d6080, pBatch=0x12d57c0, 
pbShutdownImmediate=<value optimized out>) at ../action.c:1173
#16 0x0000000000441ae4 in doQueueEnqObjDirectBatch (pAction=<value 
optimized out>, pBatch=0x12d57c0) at ../action.c:1597
#17 0x000000000044262b in doSubmitToActionQNotAllMarkBatch 
(pAction=0x12d6080, pBatch=0x12d57c0) at ../action.c:1523
#18 0x000000000043d893 in processBatchDoActions (pData=0x12d6080, 
pParam=0x1a31) at rule.c:103
#19 0x0000000000420597 in llExecFunc (pThis=0x12d5658, pFunc=0x43d860 
<processBatchDoActions>, pParam=0x12d57c0) at linkedlist.c:391
#20 0x000000000043deeb in processBatch (pThis=0x12d5600, 
pBatch=0x12d57c0) at rule.c:289
#21 0x000000000043cb22 in processBatchDoRules (pData=0x12d5600, 
pParam=0x12d57c0) at ruleset.c:150
#22 0x0000000000420597 in llExecFunc (pThis=0x12bfa98, pFunc=0x43cae0 
<processBatchDoRules>, pParam=0x12d57c0) at linkedlist.c:391
#23 0x000000000043d02c in processBatch (pBatch=0x12d57c0) at ruleset.c:232
#24 0x000000000040d4a6 in msgConsumer (notNeeded=<value optimized out>, 
pBatch=0x12d57c0, pbShutdownImmediate=0x12d64f0) at syslogd.c:702
#25 0x000000000043c19e in ConsumerReg (pThis=0x12d64d0, pWti=0x12d5790) 
at queue.c:1705
#26 0x0000000000432be6 in wtiWorker (pThis=<value optimized out>) at 
wti.c:315
#27 0x00000000004316da in wtpWorker (arg=<value optimized out>) at wtp.c:387
#28 0x00007ff4509b88ba in start_thread (arg=<value optimized out>) at 
pthread_create.c:300
#29 0x00007ff45031402d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#30 0x0000000000000000 in ?? ()

From kaushalshriyan at gmail.com  Tue Dec 13 00:16:44 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Tue, 13 Dec 2011 04:46:44 +0530
Subject: [rsyslog] rsyslog step by step guide
Message-ID: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>

Hi

Is there a step by step guide to install rsyslog on Ubuntu Linux 10.04 LTS
Server(Lucid Lynx) and configure clients to listen to the rsyslog server
and any free GUI Web Interface to view rsyslog server ?

Regards,

Kaushal

From david at lang.hm  Tue Dec 13 01:12:53 2011
From: david at lang.hm (david at lang.hm)
Date: Mon, 12 Dec 2011 16:12:53 -0800 (PST)
Subject: [rsyslog] imfile against a directory
Message-ID: <alpine.DEB.2.02.1112121612110.13039@asgard.lang.hm>

is there any way to give imfile a directory (or wildcard list of files) 
and have it slurp them all in?

David Lang


From rgerhards at hq.adiscon.com  Tue Dec 13 09:30:53 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 13 Dec 2011 09:30:53 +0100
Subject: [rsyslog] imfile against a directory
In-Reply-To: <alpine.DEB.2.02.1112121612110.13039@asgard.lang.hm>
References: <alpine.DEB.2.02.1112121612110.13039@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281606@GRFEXC.intern.adiscon.com>

There is an experimental imfile inside a forum thread that seems to have this
capability. I think there is also a git branch that contains it (or a
somewhat older version).

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Tuesday, December 13, 2011 1:13 AM
> To: rsyslog-users
> Subject: [rsyslog] imfile against a directory
> 
> is there any way to give imfile a directory (or wildcard list of files)
> and have it slurp them all in?
> 
> David Lang
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From rgerhards at hq.adiscon.com  Tue Dec 13 09:36:39 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 13 Dec 2011 09:36:39 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE6843E.7040905@civ.zcu.cz>
References: <4EE6843E.7040905@civ.zcu.cz>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281607@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of bodik
> Sent: Monday, December 12, 2011 11:46 PM
> To: rsyslog at lists.adiscon.com
> Cc: Daniel Kouril; varmojfekoj at gmail.com
> Subject: [rsyslog] omgssapi segfault
> 
> Hello,
> 
> we'r considering rsyslog as a new central syslogging daemon in our
> heavily kerberized environment. I managed to put omgssapi and imgssapi
> to work, but found that omgssapi segfaults when central server is
> offline for some seconds and then comes back online (eg. restart ...)
> stacktrace is down below.
> 
> it looks like wired behavior since omgssapi.c:367 states that this
> should not happen ;)
> 
> omgssapi.c:367
>         case eDestFORW:
>                  /* rgerhards, 2007-09-11: this can not happen, but
> I've
> included it to
>                   * a) make the compiler happy, b) detect any logic
> errors */
>                  assert(0); <<<<<<<<<<<<<< line 367
>                  break;
> 
> 
> 
> I'm not familiar with rsyslog internals to figure out whats going on
> there, so i'd like to ask:
> 
> 
> * are gssapi plugins ment to be in usable state or it's kind of beta
> while it's not even maintained by rgerhards ?
>    http://lists.adiscon.net/pipermail/rsyslog/2011-July/013472.html
>
The gssapi functionality is contributed, I unfortunately have no insight into
it. It was contributed by some friends from Red Hat. So if you happen to have
RHEL, it would probably a good idea to file a bug with them.

I actually have not cared so much about GSSAPI, as RFC5425 provides the same
and more features.
 
> 
> * or if it would be better to hook gss into librelp ? since than we can
> leverage relp and gss at the same time ...

If so, I would use TLS. But we are always open for custom programming ;)

> * or use some kind of external gss tunel ?

This I cannot answer (simply have no idea).

HTH
Rainer
> 
> 
> 
> Thanks for any ideas
> 
> Best regards
> Radoslav Bodo
> 
> 
> 
> ---------------
> 
> #0  0x00007ff450277165 in raise (sig=<value optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00007ff450279f70 in abort () at abort.c:92
> #2  0x00000000004246e7 in sigsegvHdlr (signum=6) at debug.c:832
> #3  <signal handler called>
> #4  0x00007ff450277165 in raise (sig=<value optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #5  0x00007ff450279f70 in abort () at abort.c:92
> #6  0x00007ff4502702b1 in __assert_fail (assertion=0x7ff44f19d667 "0",
> file=<value optimized out>, line=367, function=0x7ff44f19dc12
> "doTryResume") at assert.c:81
> #7  0x00007ff44f19c367 in doTryResume (pData=0x12d5700) at
> omgssapi.c:367
> #8  0x0000000000442dfa in actionDoRetry (pThis=0x12d6080,
> pbShutdownImmediate=0x12d61e0) at ../action.c:574
> #9  actionTryResume (pThis=0x12d6080, pbShutdownImmediate=0x12d61e0) at
> ../action.c:638
> #10 0x000000000044371e in actionPrepare (pAction=0x12d6080,
> pBatch=0x12d57c0, nElem=1) at ../action.c:660
> #11 actionProcessMessage (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1)
> at ../action.c:876
> #12 tryDoAction (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1) at
> ../action.c:973
> #13 submitBatch (pAction=0x12d6080, pBatch=0x12d57c0, nElem=1) at
> ../action.c:1049
> #14 0x0000000000443ce0 in processAction (pAction=0x12d6080,
> pBatch=0x12d57c0, pbShutdownImmediate=<value optimized out>) at
> ../action.c:1139
> #15 processBatchMain (pAction=0x12d6080, pBatch=0x12d57c0,
> pbShutdownImmediate=<value optimized out>) at ../action.c:1173
> #16 0x0000000000441ae4 in doQueueEnqObjDirectBatch (pAction=<value
> optimized out>, pBatch=0x12d57c0) at ../action.c:1597
> #17 0x000000000044262b in doSubmitToActionQNotAllMarkBatch
> (pAction=0x12d6080, pBatch=0x12d57c0) at ../action.c:1523
> #18 0x000000000043d893 in processBatchDoActions (pData=0x12d6080,
> pParam=0x1a31) at rule.c:103
> #19 0x0000000000420597 in llExecFunc (pThis=0x12d5658, pFunc=0x43d860
> <processBatchDoActions>, pParam=0x12d57c0) at linkedlist.c:391
> #20 0x000000000043deeb in processBatch (pThis=0x12d5600,
> pBatch=0x12d57c0) at rule.c:289
> #21 0x000000000043cb22 in processBatchDoRules (pData=0x12d5600,
> pParam=0x12d57c0) at ruleset.c:150
> #22 0x0000000000420597 in llExecFunc (pThis=0x12bfa98, pFunc=0x43cae0
> <processBatchDoRules>, pParam=0x12d57c0) at linkedlist.c:391
> #23 0x000000000043d02c in processBatch (pBatch=0x12d57c0) at
> ruleset.c:232
> #24 0x000000000040d4a6 in msgConsumer (notNeeded=<value optimized out>,
> pBatch=0x12d57c0, pbShutdownImmediate=0x12d64f0) at syslogd.c:702
> #25 0x000000000043c19e in ConsumerReg (pThis=0x12d64d0, pWti=0x12d5790)
> at queue.c:1705
> #26 0x0000000000432be6 in wtiWorker (pThis=<value optimized out>) at
> wti.c:315
> #27 0x00000000004316da in wtpWorker (arg=<value optimized out>) at
> wtp.c:387
> #28 0x00007ff4509b88ba in start_thread (arg=<value optimized out>) at
> pthread_create.c:300
> #29 0x00007ff45031402d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #30 0x0000000000000000 in ?? ()
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From bodik at civ.zcu.cz  Tue Dec 13 14:53:50 2011
From: bodik at civ.zcu.cz (bodik)
Date: Tue, 13 Dec 2011 14:53:50 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281607@GRFEXC.intern.adiscon.com>
References: <4EE6843E.7040905@civ.zcu.cz>
	<9B6E2A8877C38245BFB15CC491A11DA7281607@GRFEXC.intern.adiscon.com>
Message-ID: <4EE758EE.7010005@civ.zcu.cz>

Dne 12/13/11 09:36, Rainer Gerhards napsal(a):
>> * are gssapi plugins ment to be in usable state or it's kind of beta
>> while it's not even maintained by rgerhards ?
>>    http://lists.adiscon.net/pipermail/rsyslog/2011-July/013472.html
>>
> The gssapi functionality is contributed, I unfortunately have no insight into
> it. It was contributed by some friends from Red Hat. So if you happen to have
> RHEL, it would probably a good idea to file a bug with them.
> 
> I actually have not cared so much about GSSAPI, as RFC5425 provides the same
> and more features.

that is not an option, and IMHO GSS is not providing same features as syslog
over TLS does ..

but anyway, could you point me somewhere to docs where i can found what a magic

 switch (pData->eDestState) {
        ...
	case eDestFORW:

ment to be ?

rsyslog programming style is brand new for me and it would be very helpfull to
get into it quickly ...


best regards
radoslav bodo

From velu1980 at gmail.com  Tue Dec 13 16:47:10 2011
From: velu1980 at gmail.com (Velu S)
Date: Tue, 13 Dec 2011 10:47:10 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <alpine.DEB.2.02.1112100507400.9718@asgard.lang.hm>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
	<alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
	<CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>
	<CALBAy55aFX=rQkMXC0R9cPjZQX2m0=tWeGq4_GQnfwX2L3SVCQ@mail.gmail.com>
	<alpine.DEB.2.02.1112100507400.9718@asgard.lang.hm>
Message-ID: <CALBAy57VPciYQ_mFwBAtyEXRUkedeFb6gM1fMc4D7_QkqPmn+w@mail.gmail.com>

Hi David,

Sorry for the late reply. I was travelling and struck up with other stuffs.
I was running my rsyslog in debug mode both in the client and the server.
Here is the log snippet when the client communicates tries to communicate
to the server, when the central server is down:

7073.730513000:429eb940: Called action 0xbbe2870 (complex case), logging to
builtin-file
7073.730534000:429eb940: action 0xbbe2870: filterOK:0 state:0
execWhenPrev:0 prevWasSusp:0
7073.730542000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
7073.730550000:429eb940: Processing next rule
7073.730561000:429eb940: Filter: check for property 'msg' (value '
#eNpVUV2P0zAQ/CuWn0C65LxO0pbwBC0clWh10hXxGLnOtrVIYuOPUnG6/37rFiGQn7wzuzM7+8w7leLpW0C/7nkLAHe8i2ZE3vJdwjsGFVuhZlIAMPGureZtU7FPTztOPI+jjbh2xIUSpCxhUcoM0LQzDbwC4oos5uUCbj3B2Sng0vakIYX4Qzc6S44pGJ1pI8aTJUNcDfs0rjAqM4QMaDtFvERC3PmSC2ZyKQbePt+oncldIKv8suKlSK4IaT9Zqm+77cd197R66EDWNTRSNHMhBIhZU8kZyL/8Y5gKk/3PqhJmtB3UpazzPI8/E4bovD2YIXuO9Ctcdp1okUIdccr2Nva3GQZ135SCvflupt7+Cmy7Y00J75k/t1R/yx5Q/7D3FG72AOyz8Xiwl9zzj/OgvdnTZG1pTf6oPAmoYUlBeDt8MccTcXsVVXf0NrlwDW2gmtIaXSz0SfmA2VKKh2LBXyi09N+90Xvrbwfhm83ycfXhK4VS5XT75FU0duJtXb+8AjuBp00=$')
contains 'pvx': FALSE
7073.730573000:429eb940: Processing next action
7073.730582000:429eb940: Called action 0xbbe40e0 (complex case), logging to
builtin-fwd
7073.730590000:429eb940: action 0xbbe40e0: filterOK:0 state:0
execWhenPrev:0 prevWasSusp:0
7073.730598000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
7073.730606000:429eb940: Processing next rule
7073.730615000:429eb940: Filter: check for property 'syslogtag' (value
'[ReportingSysLog]') startswith 'pvx': FALSE
7073.730626000:429eb940: Processing next action
7073.730634000:429eb940: Called action 0xbbe8600 (complex case), logging to
builtin-fwd
7073.730642000:429eb940: action 0xbbe8600: filterOK:0 state:0
execWhenPrev:0 prevWasSusp:0
7073.730650000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
7073.730657000:429eb940: Processing next rule
7073.730666000:429eb940: Filter: check for property 'syslogtag' (value
'[ReportingSysLog]') isequal '[ReportingSysLog]': TRUE
7073.730676000:429eb940: Processing next action
7073.730684000:429eb940: Called action 0xbbe8d50 (complex case), logging to
builtin-fwd
7073.730692000:429eb940: action 0xbbe8d50: filterOK:1 state:0
execWhenPrev:0 prevWasSusp:0
7073.730702000:429eb940: Called action(complex case), logging to builtin-fwd
7073.730714000:429eb940: XXXXX:  tryDoAction 0xbbe8d50, pnElem 1, nElem 1
7073.730722000:429eb940: Action 0xbbe8d50 transitioned to state: rtry
7073.730731000:429eb940:  10.122.87.75
7073.730747000:429eb940: caller requested object 'nsd_ptcp', not found
(iRet -3003)
7073.730757000:429eb940: Requested to load module 'lmnsd_ptcp'
7073.730769000:429eb940: loading module
'/usr/local/lib/rsyslog/lmnsd_ptcp.so'
7073.730927000:429eb940: source file nsd_ptcp.c requested reference for
module 'lmnetstrms', reference count now 3
7073.730946000:429eb940: module of type 2 being loaded.
7073.730955000:429eb940: entry point 'isCompatibleWithFeature' not present
in module
7073.730964000:429eb940: source file netstrms.c requested reference for
module 'lmnsd_ptcp', reference count now 1
7073.731126000:429eb940: file netstrms.c released module 'lmnsd_ptcp',
reference count now 0
7073.731136000:429eb940: module 'lmnsd_ptcp' has zero reference count,
unloading...
7073.731144000:429eb940: Unloading module lmnsd_ptcp
7073.731155000:429eb940: file nsd_ptcp.c released module 'lmnetstrms',
reference count now 2
7073.731205000:429eb940: Action 0xbbe8d50 transitioned to state: susp
7073.731214000:429eb940: *earliest retry=1323787074*
7073.731222000:429eb940: action 0xbbe8d50 call returned -2007
7073.731231000:429eb940: tryDoAction: unexpected error code -2007[nElem 1,
Commited UpTo 0], finalizing
7073.731239000:429eb940: XXXXX:  tryDoAction 0xbbe8d50, pnElem 1, nElem 1
7073.731249000:429eb940: actionTryResume: action 0xbbe8d50 state: susp,
next retry (if applicable): 1323787074 [now 1323787073]
7073.731257000:429eb940: action 0xbbe8d50 call returned -2123
7073.731265000:429eb940: tryDoAction: unexpected error code -2123[nElem 1,
Commited UpTo 0], finalizing
7073.731274000:429eb940: actionTryResume: action 0xbbe8d50 state: susp,
next retry (if applicable): 1323787074 [now 1323787073]

I noticed the earliest retry=1323787074, but i have set it
to $ActionResumeInterval 1. Am not sure if earliest retry is the number of
seconds rsyslog takes before sending the message to the server. Please let
me know if i need to set any other parameter. Thanks in advance. Any help
is highly appreciated.

Thanks,
Anand





On Sat, Dec 10, 2011 at 8:08 AM, <david at lang.hm> wrote:

> On Sat, 10 Dec 2011, Velu S wrote:
>
>
>> Btw i tried the RELP installation too in Rsyslog 5.8.6. I was configure,
>> make and make install from the tar file. But
>> When i start the server in debug mode i get the following error:
>>
>> dlopen: /usr/local/lib/rsyslog/imrelp.**so: cannot open shared object
>> file:
>> No such file or directory
>>
>> Is there any additional steps i need to take for installing RELP and make
>> it work. Here is my Server config for RELP:
>>
>
> it sounds as if it's not compiled in. go back to the configure step and
> look at it's final output to see if you have relp enabled. you may need to
> do --enable-relp to make it compile.
>
> David Lang
>
>  $ModLoad imtcp
>> $ModLoad immark   # provides --MARK-- message capability
>> $ModLoad imuxsock # provides support for local system logging (e.g. via
>> logger command)
>> $ModLoad imklog   # kernel logging (formerly provided by rklogd)
>> $ModLoad imudp    # provides UDP syslog reception
>> $ModLoad MySQL
>> $ModLoad imrelp
>>
>>
>> #InputTCPMaxSessions 500
>> $InputTCPServerRun 10514
>>
>> $InputRELPServerRun     10514
>>
>> $SystemLogSocketFlowControl on
>> $SystemLogSocketName syslog
>>
>> $**EscapeControlCharactersOnRecei**ve off
>>
>> Thanks,
>> Velu
>>
>> On Sat, Dec 10, 2011 at 12:56 AM, Velu S <velu1980 at gmail.com> wrote:
>>
>>  Thank you David again for the help. Here is what i tried. The messages
>>> are
>>> still not buffered when the central server is down.
>>> I disabled all the action queue messages. I restarted both the sender and
>>> receiver.
>>> When both servers are up the messages gets logged in fine, but when the
>>> central server is down,
>>> the messages don't get logged in. I tried by setting the
>>> following parameters on, but still couldn't succed:
>>>
>>> $ActionResumeRetryCount -1    # infinite retries on insert failure
>>> $ActionFileEnableSync   on
>>> $**ActionSendResendLastMsgOnRecon**nect     on
>>>
>>>
>>>
>>> Thanks,
>>> Anand
>>>
>>>
>>> On Sat, Dec 10, 2011 at 12:23 AM, <david at lang.hm> wrote:
>>>
>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>
>>>>  Thank you David for the reply. Sorry for not explaining clearly in my
>>>>
>>>>> previous emails.
>>>>> I use disk assisted mode and TCP both on the client and the server.
>>>>> When
>>>>> all the servers are up everything works fine.
>>>>> When the server goes down the message send from the client are not
>>>>> logged
>>>>> in. Thats expected. But these messages are lost even when the server
>>>>> comes
>>>>> back online. I will get the entire log of the client (When the center
>>>>> goes
>>>>> down and up).
>>>>>
>>>>>
>>>> Ok, then the first thing that I would do to troubleshoot this is to
>>>> simplify things.
>>>>
>>>> try removing all of the actionqueue configuraiton entries and see what
>>>> happens. you will only be able to store a relativly small number of
>>>> messages before things block, but if you stop the server, wait until you
>>>> get the suspend message, and then startup the server again, you should
>>>> see
>>>> the messages resume. If not, there is some sort of retry option that
>>>> will
>>>> need to be set
>>>>
>>>> after we have the suspend/resume function working, then the next thing
>>>> to
>>>> do is configure the main queue to be disk assisted (even if you want a
>>>> separate action queue eventually, changing the main queue is changing
>>>> fewer
>>>> things). make sure that when there are enough messages queued that
>>>> without
>>>> the disk assist things would block, you instead have files created in
>>>> your
>>>> work directory and that after the server is restarted, it gets the
>>>> messages.
>>>>
>>>> only at this point (where we know that suspend/resume works, and we know
>>>> that a disk assisted queue works), would I then change the main queue
>>>> back
>>>> to the default and create an action queue.
>>>>
>>>> David Lang
>>>>
>>>>  I haven't tried installing RELP yet. Will try installing it and test
>>>> the
>>>>
>>>>> same scenario again. Thanks again for your timely help and time. Really
>>>>> appreciate it.
>>>>>
>>>>> Thanks,
>>>>> Velu
>>>>>
>>>>> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>>>>>
>>>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>>
>>>>>>
>>>>>>  Thank you David again for your quick reply. I installed Rsyslog
>>>>>> version
>>>>>>
>>>>>>  5.8.6 in both the sender and receiver. But My TCP messages are still
>>>>>>> not
>>>>>>> logged when the central server is down. Here is my log snippet:
>>>>>>>
>>>>>>>
>>>>>>>  OK, I don't understand the problem
>>>>>>
>>>>>> while the central server is down I would not expect the messages to be
>>>>>> logged there. but with a disk assist mode they should show up after
>>>>>> the
>>>>>> server comes up.
>>>>>>
>>>>>> I'm getting ready to head out for the evening, but will check in again
>>>>>> in
>>>>>> 4-5 hours, so let's try to clarify what's happening.
>>>>>>
>>>>>> are you using RELP or just TCP?
>>>>>>
>>>>>> In the ideal world, what should happen is:
>>>>>>
>>>>>> everything up, logs are written locally and sent to the remote server.
>>>>>>
>>>>>> remote server goes down.
>>>>>>
>>>>>> with TCP, messages in flight are lost, with RELP nothing is lost
>>>>>>
>>>>>> you should see the transport be suspended, and it will retry, failing
>>>>>> each
>>>>>> time and eventually retry less frequently (to keep from wasting
>>>>>> resources
>>>>>> on the sending box)
>>>>>>
>>>>>> log messages should still be written locally, but queue up to be sent
>>>>>> to
>>>>>> the remote server later.
>>>>>>
>>>>>>  note that if you don't enable the disk assisted queue this will still
>>>>>> happen, but only up to the point where you fill memory.
>>>>>>
>>>>>> verify that logs are still being written locally, and look for files
>>>>>> to
>>>>>> be
>>>>>> created in your working directory for the ones queued up to be sent
>>>>>> later.
>>>>>> you may need to generate a bunch of log messages to get to the point
>>>>>> where
>>>>>> they queue to disk.
>>>>>>
>>>>>>
>>>>>> then bring up the remote server. you should have logs start arriving
>>>>>> there
>>>>>> within a couple minutes, and then the older logs will start arriving.
>>>>>>
>>>>>> the debug logs around the time that the remote server comes up should
>>>>>> be
>>>>>> interesting. I don't remember what the retry time is, but I seem to
>>>>>> remember that by default it includes some sort of logrithmic backoff
>>>>>> logic,
>>>>>> so if you are down for a long time, it may take a long time before it
>>>>>> decides to try again.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>>  9717.969783000:4266b940: file nsd_ptcp.c released module
>>>>>> 'lmnetstrms',
>>>>>>
>>>>>>  reference count now 2
>>>>>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state:
>>>>>>> susp
>>>>>>> 9717.969857000:4266b940: earliest retry=1323469718
>>>>>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>>>>>> 9717.969877000:4266b940: tryDoAction: unexpected error code
>>>>>>> -2007[nElem 1,
>>>>>>> Commited UpTo 0], finalizing
>>>>>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1,
>>>>>>> nElem 1
>>>>>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>>> susp,
>>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>>>>>> 9717.969911000:4266b940: tryDoAction: unexpected error code
>>>>>>> -2123[nElem 1,
>>>>>>> Commited UpTo 0], finalizing
>>>>>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>>> susp,
>>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>>>>>> 9717.969936000:4266b940: Processing next rule
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Velu
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>>>>>
>>>>>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>>>>
>>>>>>>
>>>>>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>   To avoid this loss, you will need to use RELP instead of TCP. RELP
>>>>>>>>>
>>>>>>>>>  doesn't consider the message delivered until the receiving server
>>>>>>>>>
>>>>>>>>>> acknowledges it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  I'm currently using TCP delivery because I couldn't make sense of
>>>>>>>>>>
>>>>>>>>> RELP
>>>>>>>>> when I put it in place. Currently, I have clients doing:
>>>>>>>>>
>>>>>>>>> $WorkDirectory /var/spool/rsyslog
>>>>>>>>> $ActionQueueFileName fwd_queue
>>>>>>>>> $ActionQueueSaveOnShutdown on
>>>>>>>>> $ActionQueueType LinkedList
>>>>>>>>> $ActionResumeRetryCount -1
>>>>>>>>> *.* @@logserver:1234;********SiteIDForwardFormat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Would switching to RELP be as simple as replacing that last line
>>>>>>>>> with:
>>>>>>>>>
>>>>>>>>> *.* :omrelp:logserver:2345;********SiteIDForwardFormat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And adding a RELP listener on the new port on the server?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  other than the need to load the relp module, it should be about
>>>>>>>>> that
>>>>>>>>>
>>>>>>>> simple.
>>>>>>>>
>>>>>>>> David Lang
>>>>>>>>
>>>>>>>> ______________________________********_________________
>>>>>>>> rsyslog mailing list
>>>>>>>> http://lists.adiscon.net/********mailman/listinfo/rsyslog<http://lists.adiscon.net/******mailman/listinfo/rsyslog>
>>>>>>>> <http**://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>>> >
>>>>>>>> <http:**//lists.adiscon.net/****mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/**listinfo/rsyslog>
>>>>>>>> <htt**p://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  <http:**//lists.adiscon.net/****mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/**listinfo/rsyslog>
>>>>>>>> <htt**p://lists.adiscon.net/mailman/****listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>>> >
>>>>>>>> <htt**p://lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>  http://www.rsyslog.com/********professional-services/<http://www.rsyslog.com/******professional-services/>
>>>>>>>>> <http://**www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>> <http://**www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  <http://**www.rsyslog.com/****professional-**services/<http://www.rsyslog.com/**professional-**services/>
>>>>>>>> <http:**//www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>>> >
>>>>>>>> <http:**//www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   ______________________________******_________________
>>>>>>>>
>>>>>>>>  rsyslog mailing list
>>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>> >
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>> >
>>>>>>>
>>>>>>>>
>>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>> >
>>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>>> >
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>  ______________________________******_________________
>>>>>>>
>>>>>>>  rsyslog mailing list
>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>> >
>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>> >
>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>  ______________________________****_________________
>>>>>>
>>>>> rsyslog mailing list
>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>> >
>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>> >
>>>>>
>>>>>  ______________________________****_________________
>>>>>
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>> >
>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>> >
>>>>
>>>>
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>>  ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

From theinric at redhat.com  Tue Dec 13 18:43:22 2011
From: theinric at redhat.com (Tomas Heinrich)
Date: Tue, 13 Dec 2011 18:43:22 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE6843E.7040905@civ.zcu.cz>
References: <4EE6843E.7040905@civ.zcu.cz>
Message-ID: <4EE78EBA.6050006@redhat.com>

On 12/12/2011 11:46 PM, bodik wrote:
> Hello,
>
> we'r considering rsyslog as a new central syslogging daemon in our
> heavily kerberized environment. I managed to put omgssapi and imgssapi
> to work, but found that omgssapi segfaults when central server is
> offline for some seconds and then comes back online (eg. restart ...)
> stacktrace is down below.
>
> it looks like wired behavior since omgssapi.c:367 states that this
> should not happen ;)
>
> omgssapi.c:367
> case eDestFORW:
> /* rgerhards, 2007-09-11: this can not happen, but I've included it to
> * a) make the compiler happy, b) detect any logic errors */
> assert(0); <<<<<<<<<<<<<< line 367
> break;

Hi,

I wrote the original plugin, but it has been quite some time since
then, so my recollection of the specifics might not be accurate.

By the way, which version of rsyslog are you using?
I've looked at the code of v5.8.6 briefly and hopefully there is an
easy fix for this bug.

The code was based on the omfwd module. As omfwd and the supporting
code were updated, some parts of omgssapi were missed. Specifically:
- when an omgssapi action is recovering from a "suspended state" using
   doTryResume(), it just sets pData->eDestState to eDestFORW and waits
   for the next doAction() to actually determine the state
- doTryResume() used to only be called from actionDoRetry() ->
   'eDestState == eDestFORW' could never have happened
- nowadays doTryResume() can consequently be called from
   tryDoAction(), triggering the abort()

If these observations are correct, the solution is simply to remove
the abort() and let the function to continue (to tcpclt.Send(), which
will potentially suspend the action again).
But _I haven't actually verified_ this is the case.

> I'm not familiar with rsyslog internals to figure out whats going on
> there, so i'd like to ask:
>
> * are gssapi plugins ment to be in usable state or it's kind of beta
> while it's not even maintained by rgerhards ?
> http://lists.adiscon.net/pipermail/rsyslog/2011-July/013472.html

They probably aren't used that much and hence receive limited testing.

HTH,
Tomas

From bodik at civ.zcu.cz  Tue Dec 13 22:28:40 2011
From: bodik at civ.zcu.cz (bodik)
Date: Tue, 13 Dec 2011 22:28:40 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE78EBA.6050006@redhat.com>
References: <4EE6843E.7040905@civ.zcu.cz> <4EE78EBA.6050006@redhat.com>
Message-ID: <4EE7C388.5060700@civ.zcu.cz>

Dne 12/13/2011 06:43 PM, Tomas Heinrich napsal(a):
> On 12/12/2011 11:46 PM, bodik wrote:
>> Hello,
>>
>> we'r considering rsyslog as a new central syslogging daemon in our
>> heavily kerberized environment. I managed to put omgssapi and imgssapi
>> to work, but found that omgssapi segfaults when central server is
>> offline for some seconds and then comes back online (eg. restart ...)
>> stacktrace is down below.
>>
>> it looks like wired behavior since omgssapi.c:367 states that this
>> should not happen ;)
>>
>> omgssapi.c:367
>> case eDestFORW:
>> /* rgerhards, 2007-09-11: this can not happen, but I've included it to
>> * a) make the compiler happy, b) detect any logic errors */
>> assert(0); <<<<<<<<<<<<<< line 367
>> break;
>
> Hi,
>
> I wrote the original plugin, but it has been quite some time since
> then, so my recollection of the specifics might not be accurate.
>
> By the way, which version of rsyslog are you using?
> I've looked at the code of v5.8.6 briefly and hopefully there is an
> easy fix for this bug.
>
> The code was based on the omfwd module. As omfwd and the supporting
> code were updated, some parts of omgssapi were missed. Specifically:
> - when an omgssapi action is recovering from a "suspended state" using
> doTryResume(), it just sets pData->eDestState to eDestFORW and waits
> for the next doAction() to actually determine the state
> - doTryResume() used to only be called from actionDoRetry() ->
> 'eDestState == eDestFORW' could never have happened
> - nowadays doTryResume() can consequently be called from
> tryDoAction(), triggering the abort()
>
> If these observations are correct, the solution is simply to remove
> the abort() and let the function to continue (to tcpclt.Send(), which
> will potentially suspend the action again).
> But _I haven't actually verified_ this is the case.


hi,

thanks for reply I tried this one, at it stops client from segfault ...
is that what you mean to do ? or we shloud discard "case eDestFORW:" 
completely ?

b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsyslog-omgssapi-w1.patch
Type: text/x-patch
Size: 837 bytes
Desc: not available
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111213/c573c9cf/attachment.bin>

From velu1980 at gmail.com  Tue Dec 13 23:55:35 2011
From: velu1980 at gmail.com (Velu S)
Date: Tue, 13 Dec 2011 17:55:35 -0500
Subject: [rsyslog] Issues with configuring rsyslog with TCP
 configuration. Please help
In-Reply-To: <CALBAy57VPciYQ_mFwBAtyEXRUkedeFb6gM1fMc4D7_QkqPmn+w@mail.gmail.com>
References: <CALBAy57FqjV01gjZ8U+_LiLEtkLK-QZ0G+qtL88K9zAuaOOSzw@mail.gmail.com>
	<alpine.DEB.2.02.1112091217320.20722@asgard.lang.hm>
	<AA6ACEA1-D503-414E-B73C-DA218BB9A1E5@unnerving.org>
	<alpine.DEB.2.02.1112091401511.29398@asgard.lang.hm>
	<CALBAy56N2XWCN1XQkHDb52hXML4u+2CZ9oWdN+S6U_C+CTCQMQ@mail.gmail.com>
	<alpine.DEB.2.02.1112091547170.9718@asgard.lang.hm>
	<CALBAy55SBHZivbOxoCeAfSDNoYsp7-ZYC-0Vckqf0Qhqh4qWow@mail.gmail.com>
	<alpine.DEB.2.02.1112092117340.9718@asgard.lang.hm>
	<CALBAy57HZgNbaSPUfiuB=pnuxcUPpScm_pbFZithnUqWMW1vDA@mail.gmail.com>
	<CALBAy55aFX=rQkMXC0R9cPjZQX2m0=tWeGq4_GQnfwX2L3SVCQ@mail.gmail.com>
	<alpine.DEB.2.02.1112100507400.9718@asgard.lang.hm>
	<CALBAy57VPciYQ_mFwBAtyEXRUkedeFb6gM1fMc4D7_QkqPmn+w@mail.gmail.com>
Message-ID: <CALBAy55ipdELAUUbiH2hP3HON8z486WW1Ki2upZsjbwgHEGEJg@mail.gmail.com>

Hi David,

I tried installing RELP:

I was able to install and build it without any errors.I am trying to log
all my messages
to a central log server. Am trying to use RELP for better reliability.

When i start my Centralised server in debug mode i get the following error:

rsyslogd: could not load module '/usr/local/lib/rsyslog/imrelp.so',
dlopen: /usr/local/lib/rsyslog/imrelp.so: undefined symbol:
relpEngineAddListner
 [try http://www.rsyslog.com/e/2066 ]
rsyslogd: the last error occured in /etc/rsyslog.conf, line 7:"$ModLoad
imrelp"
rsyslogd: invalid or yet-unknown config file command - have you forgotten
to load a module? [tryhttp://www.rsyslog.com/e/3003 ]
rsyslogd: the last error occured in /etc/rsyslog.conf, line
12:"$InputRELPServerRun     10514"
rsyslogd: CONFIG ERROR: could not interpret master config file
'/etc/rsyslog.conf'. [tryhttp://www.rsyslog.com/e/2124 ]


The imrelp.so does exist in the specified directory with correct
permissions.
Did anyone had similar issue. Any help will be highly appreciated

Thanks,
Velu

On Tue, Dec 13, 2011 at 10:47 AM, Velu S <velu1980 at gmail.com> wrote:

> Hi David,
>
> Sorry for the late reply. I was travelling and struck up with other
> stuffs. I was running my rsyslog in debug mode both in the client and the
> server. Here is the log snippet when the client communicates tries to
> communicate to the server, when the central server is down:
>
> 7073.730513000:429eb940: Called action 0xbbe2870 (complex case), logging
> to builtin-file
> 7073.730534000:429eb940: action 0xbbe2870: filterOK:0 state:0
> execWhenPrev:0 prevWasSusp:0
> 7073.730542000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
> 7073.730550000:429eb940: Processing next rule
> 7073.730561000:429eb940: Filter: check for property 'msg' (value '
> #eNpVUV2P0zAQ/CuWn0C65LxO0pbwBC0clWh10hXxGLnOtrVIYuOPUnG6/37rFiGQn7wzuzM7+8w7leLpW0C/7nkLAHe8i2ZE3vJdwjsGFVuhZlIAMPGureZtU7FPTztOPI+jjbh2xIUSpCxhUcoM0LQzDbwC4oos5uUCbj3B2Sng0vakIYX4Qzc6S44pGJ1pI8aTJUNcDfs0rjAqM4QMaDtFvERC3PmSC2ZyKQbePt+oncldIKv8suKlSK4IaT9Zqm+77cd197R66EDWNTRSNHMhBIhZU8kZyL/8Y5gKk/3PqhJmtB3UpazzPI8/E4bovD2YIXuO9Ctcdp1okUIdccr2Nva3GQZ135SCvflupt7+Cmy7Y00J75k/t1R/yx5Q/7D3FG72AOyz8Xiwl9zzj/OgvdnTZG1pTf6oPAmoYUlBeDt8MccTcXsVVXf0NrlwDW2gmtIaXSz0SfmA2VKKh2LBXyi09N+90Xvrbwfhm83ycfXhK4VS5XT75FU0duJtXb+8AjuBp00=$')
> contains 'pvx': FALSE
> 7073.730573000:429eb940: Processing next action
> 7073.730582000:429eb940: Called action 0xbbe40e0 (complex case), logging
> to builtin-fwd
> 7073.730590000:429eb940: action 0xbbe40e0: filterOK:0 state:0
> execWhenPrev:0 prevWasSusp:0
> 7073.730598000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
> 7073.730606000:429eb940: Processing next rule
> 7073.730615000:429eb940: Filter: check for property 'syslogtag' (value
> '[ReportingSysLog]') startswith 'pvx': FALSE
> 7073.730626000:429eb940: Processing next action
> 7073.730634000:429eb940: Called action 0xbbe8600 (complex case), logging
> to builtin-fwd
> 7073.730642000:429eb940: action 0xbbe8600: filterOK:0 state:0
> execWhenPrev:0 prevWasSusp:0
> 7073.730650000:429eb940: ruleset: get iRet 0 from rule.ProcessMsg()
> 7073.730657000:429eb940: Processing next rule
> 7073.730666000:429eb940: Filter: check for property 'syslogtag' (value
> '[ReportingSysLog]') isequal '[ReportingSysLog]': TRUE
> 7073.730676000:429eb940: Processing next action
> 7073.730684000:429eb940: Called action 0xbbe8d50 (complex case), logging
> to builtin-fwd
> 7073.730692000:429eb940: action 0xbbe8d50: filterOK:1 state:0
> execWhenPrev:0 prevWasSusp:0
> 7073.730702000:429eb940: Called action(complex case), logging to
> builtin-fwd
> 7073.730714000:429eb940: XXXXX:  tryDoAction 0xbbe8d50, pnElem 1, nElem 1
> 7073.730722000:429eb940: Action 0xbbe8d50 transitioned to state: rtry
> 7073.730731000:429eb940:  10.122.87.75
> 7073.730747000:429eb940: caller requested object 'nsd_ptcp', not found
> (iRet -3003)
> 7073.730757000:429eb940: Requested to load module 'lmnsd_ptcp'
> 7073.730769000:429eb940: loading module
> '/usr/local/lib/rsyslog/lmnsd_ptcp.so'
> 7073.730927000:429eb940: source file nsd_ptcp.c requested reference for
> module 'lmnetstrms', reference count now 3
> 7073.730946000:429eb940: module of type 2 being loaded.
> 7073.730955000:429eb940: entry point 'isCompatibleWithFeature' not present
> in module
> 7073.730964000:429eb940: source file netstrms.c requested reference for
> module 'lmnsd_ptcp', reference count now 1
> 7073.731126000:429eb940: file netstrms.c released module 'lmnsd_ptcp',
> reference count now 0
> 7073.731136000:429eb940: module 'lmnsd_ptcp' has zero reference count,
> unloading...
> 7073.731144000:429eb940: Unloading module lmnsd_ptcp
> 7073.731155000:429eb940: file nsd_ptcp.c released module 'lmnetstrms',
> reference count now 2
> 7073.731205000:429eb940: Action 0xbbe8d50 transitioned to state: susp
> 7073.731214000:429eb940: *earliest retry=1323787074*
> 7073.731222000:429eb940: action 0xbbe8d50 call returned -2007
> 7073.731231000:429eb940: tryDoAction: unexpected error code -2007[nElem 1,
> Commited UpTo 0], finalizing
> 7073.731239000:429eb940: XXXXX:  tryDoAction 0xbbe8d50, pnElem 1, nElem 1
> 7073.731249000:429eb940: actionTryResume: action 0xbbe8d50 state: susp,
> next retry (if applicable): 1323787074 [now 1323787073]
> 7073.731257000:429eb940: action 0xbbe8d50 call returned -2123
> 7073.731265000:429eb940: tryDoAction: unexpected error code -2123[nElem 1,
> Commited UpTo 0], finalizing
> 7073.731274000:429eb940: actionTryResume: action 0xbbe8d50 state: susp,
> next retry (if applicable): 1323787074 [now 1323787073]
>
> I noticed the earliest retry=1323787074, but i have set it
> to $ActionResumeInterval 1. Am not sure if earliest retry is the number of
> seconds rsyslog takes before sending the message to the server. Please let
> me know if i need to set any other parameter. Thanks in advance. Any help
> is highly appreciated.
>
> Thanks,
> Anand
>
>
>
>
>
> On Sat, Dec 10, 2011 at 8:08 AM, <david at lang.hm> wrote:
>
>> On Sat, 10 Dec 2011, Velu S wrote:
>>
>>
>>> Btw i tried the RELP installation too in Rsyslog 5.8.6. I was configure,
>>> make and make install from the tar file. But
>>> When i start the server in debug mode i get the following error:
>>>
>>> dlopen: /usr/local/lib/rsyslog/imrelp.**so: cannot open shared object
>>> file:
>>> No such file or directory
>>>
>>> Is there any additional steps i need to take for installing RELP and make
>>> it work. Here is my Server config for RELP:
>>>
>>
>> it sounds as if it's not compiled in. go back to the configure step and
>> look at it's final output to see if you have relp enabled. you may need to
>> do --enable-relp to make it compile.
>>
>> David Lang
>>
>>  $ModLoad imtcp
>>> $ModLoad immark   # provides --MARK-- message capability
>>> $ModLoad imuxsock # provides support for local system logging (e.g. via
>>> logger command)
>>> $ModLoad imklog   # kernel logging (formerly provided by rklogd)
>>> $ModLoad imudp    # provides UDP syslog reception
>>> $ModLoad MySQL
>>> $ModLoad imrelp
>>>
>>>
>>> #InputTCPMaxSessions 500
>>> $InputTCPServerRun 10514
>>>
>>> $InputRELPServerRun     10514
>>>
>>> $SystemLogSocketFlowControl on
>>> $SystemLogSocketName syslog
>>>
>>> $**EscapeControlCharactersOnRecei**ve off
>>>
>>> Thanks,
>>> Velu
>>>
>>> On Sat, Dec 10, 2011 at 12:56 AM, Velu S <velu1980 at gmail.com> wrote:
>>>
>>>  Thank you David again for the help. Here is what i tried. The messages
>>>> are
>>>> still not buffered when the central server is down.
>>>> I disabled all the action queue messages. I restarted both the sender
>>>> and
>>>> receiver.
>>>> When both servers are up the messages gets logged in fine, but when the
>>>> central server is down,
>>>> the messages don't get logged in. I tried by setting the
>>>> following parameters on, but still couldn't succed:
>>>>
>>>> $ActionResumeRetryCount -1    # infinite retries on insert failure
>>>> $ActionFileEnableSync   on
>>>> $**ActionSendResendLastMsgOnRecon**nect     on
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Anand
>>>>
>>>>
>>>> On Sat, Dec 10, 2011 at 12:23 AM, <david at lang.hm> wrote:
>>>>
>>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>>
>>>>>  Thank you David for the reply. Sorry for not explaining clearly in my
>>>>>
>>>>>> previous emails.
>>>>>> I use disk assisted mode and TCP both on the client and the server.
>>>>>> When
>>>>>> all the servers are up everything works fine.
>>>>>> When the server goes down the message send from the client are not
>>>>>> logged
>>>>>> in. Thats expected. But these messages are lost even when the server
>>>>>> comes
>>>>>> back online. I will get the entire log of the client (When the center
>>>>>> goes
>>>>>> down and up).
>>>>>>
>>>>>>
>>>>> Ok, then the first thing that I would do to troubleshoot this is to
>>>>> simplify things.
>>>>>
>>>>> try removing all of the actionqueue configuraiton entries and see what
>>>>> happens. you will only be able to store a relativly small number of
>>>>> messages before things block, but if you stop the server, wait until
>>>>> you
>>>>> get the suspend message, and then startup the server again, you should
>>>>> see
>>>>> the messages resume. If not, there is some sort of retry option that
>>>>> will
>>>>> need to be set
>>>>>
>>>>> after we have the suspend/resume function working, then the next thing
>>>>> to
>>>>> do is configure the main queue to be disk assisted (even if you want a
>>>>> separate action queue eventually, changing the main queue is changing
>>>>> fewer
>>>>> things). make sure that when there are enough messages queued that
>>>>> without
>>>>> the disk assist things would block, you instead have files created in
>>>>> your
>>>>> work directory and that after the server is restarted, it gets the
>>>>> messages.
>>>>>
>>>>> only at this point (where we know that suspend/resume works, and we
>>>>> know
>>>>> that a disk assisted queue works), would I then change the main queue
>>>>> back
>>>>> to the default and create an action queue.
>>>>>
>>>>> David Lang
>>>>>
>>>>>  I haven't tried installing RELP yet. Will try installing it and test
>>>>> the
>>>>>
>>>>>> same scenario again. Thanks again for your timely help and time.
>>>>>> Really
>>>>>> appreciate it.
>>>>>>
>>>>>> Thanks,
>>>>>> Velu
>>>>>>
>>>>>> On Fri, Dec 9, 2011 at 6:55 PM, <david at lang.hm> wrote:
>>>>>>
>>>>>>  On Fri, 9 Dec 2011, Velu S wrote:
>>>>>>
>>>>>>>
>>>>>>>  Thank you David again for your quick reply. I installed Rsyslog
>>>>>>> version
>>>>>>>
>>>>>>>  5.8.6 in both the sender and receiver. But My TCP messages are still
>>>>>>>> not
>>>>>>>> logged when the central server is down. Here is my log snippet:
>>>>>>>>
>>>>>>>>
>>>>>>>>  OK, I don't understand the problem
>>>>>>>
>>>>>>> while the central server is down I would not expect the messages to
>>>>>>> be
>>>>>>> logged there. but with a disk assist mode they should show up after
>>>>>>> the
>>>>>>> server comes up.
>>>>>>>
>>>>>>> I'm getting ready to head out for the evening, but will check in
>>>>>>> again
>>>>>>> in
>>>>>>> 4-5 hours, so let's try to clarify what's happening.
>>>>>>>
>>>>>>> are you using RELP or just TCP?
>>>>>>>
>>>>>>> In the ideal world, what should happen is:
>>>>>>>
>>>>>>> everything up, logs are written locally and sent to the remote
>>>>>>> server.
>>>>>>>
>>>>>>> remote server goes down.
>>>>>>>
>>>>>>> with TCP, messages in flight are lost, with RELP nothing is lost
>>>>>>>
>>>>>>> you should see the transport be suspended, and it will retry, failing
>>>>>>> each
>>>>>>> time and eventually retry less frequently (to keep from wasting
>>>>>>> resources
>>>>>>> on the sending box)
>>>>>>>
>>>>>>> log messages should still be written locally, but queue up to be
>>>>>>> sent to
>>>>>>> the remote server later.
>>>>>>>
>>>>>>>  note that if you don't enable the disk assisted queue this will
>>>>>>> still
>>>>>>> happen, but only up to the point where you fill memory.
>>>>>>>
>>>>>>> verify that logs are still being written locally, and look for files
>>>>>>> to
>>>>>>> be
>>>>>>> created in your working directory for the ones queued up to be sent
>>>>>>> later.
>>>>>>> you may need to generate a bunch of log messages to get to the point
>>>>>>> where
>>>>>>> they queue to disk.
>>>>>>>
>>>>>>>
>>>>>>> then bring up the remote server. you should have logs start arriving
>>>>>>> there
>>>>>>> within a couple minutes, and then the older logs will start arriving.
>>>>>>>
>>>>>>> the debug logs around the time that the remote server comes up
>>>>>>> should be
>>>>>>> interesting. I don't remember what the retry time is, but I seem to
>>>>>>> remember that by default it includes some sort of logrithmic backoff
>>>>>>> logic,
>>>>>>> so if you are down for a long time, it may take a long time before it
>>>>>>> decides to try again.
>>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>>  9717.969783000:4266b940: file nsd_ptcp.c released module
>>>>>>> 'lmnetstrms',
>>>>>>>
>>>>>>>  reference count now 2
>>>>>>>> 9717.969836000:4266b940: Action 0x1e25ae30 transitioned to state:
>>>>>>>> susp
>>>>>>>> 9717.969857000:4266b940: earliest retry=1323469718
>>>>>>>> 9717.969865000:4266b940: action 0x1e25ae30 call returned -2007
>>>>>>>> 9717.969877000:4266b940: tryDoAction: unexpected error code
>>>>>>>> -2007[nElem 1,
>>>>>>>> Commited UpTo 0], finalizing
>>>>>>>> 9717.969885000:4266b940: XXXXX:  tryDoAction 0x1e25ae30, pnElem 1,
>>>>>>>> nElem 1
>>>>>>>> 9717.969894000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>>>> susp,
>>>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>>>> 9717.969903000:4266b940: action 0x1e25ae30 call returned -2123
>>>>>>>> 9717.969911000:4266b940: tryDoAction: unexpected error code
>>>>>>>> -2123[nElem 1,
>>>>>>>> Commited UpTo 0], finalizing
>>>>>>>> 9717.969919000:4266b940: actionTryResume: action 0x1e25ae30 state:
>>>>>>>> susp,
>>>>>>>> next retry (if applicable): 1323469718 [now 1323469717]
>>>>>>>> 9717.969928000:4266b940: ruleset: get iRet 0 from rule.ProcessMsg()
>>>>>>>> 9717.969936000:4266b940: Processing next rule
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Velu
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 9, 2011 at 5:03 PM, <david at lang.hm> wrote:
>>>>>>>>
>>>>>>>>  On Fri, 9 Dec 2011, Gregory K. Ruiz-Ade wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>  On Dec 9, 2011, at 12:30 PM, david at lang.hm wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   To avoid this loss, you will need to use RELP instead of TCP.
>>>>>>>>>> RELP
>>>>>>>>>>
>>>>>>>>>>  doesn't consider the message delivered until the receiving server
>>>>>>>>>>
>>>>>>>>>>> acknowledges it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  I'm currently using TCP delivery because I couldn't make sense
>>>>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>> RELP
>>>>>>>>>> when I put it in place. Currently, I have clients doing:
>>>>>>>>>>
>>>>>>>>>> $WorkDirectory /var/spool/rsyslog
>>>>>>>>>> $ActionQueueFileName fwd_queue
>>>>>>>>>> $ActionQueueSaveOnShutdown on
>>>>>>>>>> $ActionQueueType LinkedList
>>>>>>>>>> $ActionResumeRetryCount -1
>>>>>>>>>> *.* @@logserver:1234;********SiteIDForwardFormat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Would switching to RELP be as simple as replacing that last line
>>>>>>>>>> with:
>>>>>>>>>>
>>>>>>>>>> *.* :omrelp:logserver:2345;********SiteIDForwardFormat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And adding a RELP listener on the new port on the server?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  other than the need to load the relp module, it should be about
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>> simple.
>>>>>>>>>
>>>>>>>>> David Lang
>>>>>>>>>
>>>>>>>>> ______________________________********_________________
>>>>>>>>> rsyslog mailing list
>>>>>>>>> http://lists.adiscon.net/********mailman/listinfo/rsyslog<http://lists.adiscon.net/******mailman/listinfo/rsyslog>
>>>>>>>>> <http**://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>>>> >
>>>>>>>>> <http:**//lists.adiscon.net/****mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/**listinfo/rsyslog>
>>>>>>>>> <htt**p://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  <http:**//lists.adiscon.net/****mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/**listinfo/rsyslog>
>>>>>>>>> <htt**p://lists.adiscon.net/mailman/****listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>>>> >
>>>>>>>>> <htt**p://lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>  http://www.rsyslog.com/********professional-services/<http://www.rsyslog.com/******professional-services/>
>>>>>>>>>> <http://**www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>> <http://**www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  <http://**www.rsyslog.com/****professional-**services/<http://www.rsyslog.com/**professional-**services/>
>>>>>>>>> <http:**//www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>>>> >
>>>>>>>>> <http:**//www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   ______________________________******_________________
>>>>>>>>>
>>>>>>>>>  rsyslog mailing list
>>>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>>> >
>>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>>> >
>>>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>  ______________________________******_________________
>>>>>>>>
>>>>>>>>  rsyslog mailing list
>>>>>>> http://lists.adiscon.net/******mailman/listinfo/rsyslog<http://lists.adiscon.net/****mailman/listinfo/rsyslog>
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>>> >
>>>>>>> <http:**//lists.adiscon.net/**mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/**listinfo/rsyslog>
>>>>>>> <htt**p://lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>>> >
>>>>>>>
>>>>>>>>
>>>>>>>>  http://www.rsyslog.com/******professional-services/<http://www.rsyslog.com/****professional-services/>
>>>>>>> <http://**www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>>> >
>>>>>>> <http://**www.rsyslog.com/**professional-**services/<http://www.rsyslog.com/professional-**services/>
>>>>>>> <http:**//www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>>>>> >
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>  ______________________________****_________________
>>>>>>>
>>>>>> rsyslog mailing list
>>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>>> >
>>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>>> >
>>>>>>
>>>>>>  ______________________________****_________________
>>>>>>
>>>>> rsyslog mailing list
>>>>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog>
>>>>> <http:**//lists.adiscon.net/mailman/**listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>>>> >
>>>>> http://www.rsyslog.com/****professional-services/<http://www.rsyslog.com/**professional-services/>
>>>>> <http://**www.rsyslog.com/professional-**services/<http://www.rsyslog.com/professional-services/>
>>>>> >
>>>>>
>>>>>
>>>>
>>>>  ______________________________**_________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>>
>>>  ______________________________**_________________
>> rsyslog mailing list
>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>>
>
>

From kaushalshriyan at gmail.com  Wed Dec 14 03:03:00 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Wed, 14 Dec 2011 07:33:00 +0530
Subject: [rsyslog] rsyslog step by step guide
In-Reply-To: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>
References: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>
Message-ID: <CAD7Ssm9tGWMPb9K52wgYkRj93E4vY++=11Fas=ObBFCMUwyU+g@mail.gmail.com>

On Tue, Dec 13, 2011 at 4:46 AM, Kaushal Shriyan
<kaushalshriyan at gmail.com>wrote:

> Hi
>
> Is there a step by step guide to install rsyslog on Ubuntu Linux 10.04 LTS
> Server(Lucid Lynx) and configure clients to listen to the rsyslog server
> and any free GUI Web Interface to view rsyslog server ?
>
> Regards,
>
> Kaushal
>

Hi,

Can someone please reply me to my earlier post to this Mailing List.

Regards

Kaushal

From mbiebl at gmail.com  Wed Dec 14 03:17:30 2011
From: mbiebl at gmail.com (Michael Biebl)
Date: Wed, 14 Dec 2011 03:17:30 +0100
Subject: [rsyslog] rsyslog step by step guide
In-Reply-To: <CAD7Ssm9tGWMPb9K52wgYkRj93E4vY++=11Fas=ObBFCMUwyU+g@mail.gmail.com>
References: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>
	<CAD7Ssm9tGWMPb9K52wgYkRj93E4vY++=11Fas=ObBFCMUwyU+g@mail.gmail.com>
Message-ID: <CAGWsdOhi6vD7m6-+o8nvV+icBPKUrWTsQ1xG0yL7owC1EYDMCw@mail.gmail.com>

2011/12/14 Kaushal Shriyan <kaushalshriyan at gmail.com>:
> On Tue, Dec 13, 2011 at 4:46 AM, Kaushal Shriyan
> <kaushalshriyan at gmail.com>wrote:
>
>> Hi
>>
>> Is there a step by step guide to install rsyslog on Ubuntu Linux 10.04 LTS
>> Server(Lucid Lynx) and configure clients to listen to the rsyslog server
>> and any free GUI Web Interface to view rsyslog server ?
>>
>> Regards,
>>
>> Kaushal
>>
>
> Hi,
>
> Can someone please reply me to my earlier post to this Mailing List.

Demanding an answer is rude. Especially since you apparently not even
tried to read up on the existing documentation.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

From kaushalshriyan at gmail.com  Wed Dec 14 03:55:36 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Wed, 14 Dec 2011 08:25:36 +0530
Subject: [rsyslog] rsyslog step by step guide
In-Reply-To: <CAGWsdOhi6vD7m6-+o8nvV+icBPKUrWTsQ1xG0yL7owC1EYDMCw@mail.gmail.com>
References: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>
	<CAD7Ssm9tGWMPb9K52wgYkRj93E4vY++=11Fas=ObBFCMUwyU+g@mail.gmail.com>
	<CAGWsdOhi6vD7m6-+o8nvV+icBPKUrWTsQ1xG0yL7owC1EYDMCw@mail.gmail.com>
Message-ID: <CAD7Ssm-PqyytX+09uP9GExpGX-mzDnUeugRJH-V47omphiXg=w@mail.gmail.com>

On Wed, Dec 14, 2011 at 7:47 AM, Michael Biebl <mbiebl at gmail.com> wrote:

> 2011/12/14 Kaushal Shriyan <kaushalshriyan at gmail.com>:
> > On Tue, Dec 13, 2011 at 4:46 AM, Kaushal Shriyan
> > <kaushalshriyan at gmail.com>wrote:
> >
> >> Hi
> >>
> >> Is there a step by step guide to install rsyslog on Ubuntu Linux 10.04
> LTS
> >> Server(Lucid Lynx) and configure clients to listen to the rsyslog server
> >> and any free GUI Web Interface to view rsyslog server ?
> >>
> >> Regards,
> >>
> >> Kaushal
> >>
> >
> > Hi,
> >
> > Can someone please reply me to my earlier post to this Mailing List.
>
> Demanding an answer is rude. Especially since you apparently not even
> tried to read up on the existing documentation.
>
>
> --
>
Hi Michael,

Apologies if my earlier post was meant to be rude, I have gone through
http://wiki.rsyslog.com/index.php/Main_Page. Basically i was looking out
for something like a remote centralized rsyslog server and collect all
syslogs from remote linux clients and any Open Source UI web interface
similar in line with "splunk" to query and parse those logs. The reason
being splunk is a paid version.

Let me know if you have further questions and once again apologies.

Regards

Kaushal

From mturczan at nyp.org  Wed Dec 14 05:17:20 2011
From: mturczan at nyp.org (Mark S. Turczan)
Date: Tue, 13 Dec 2011 23:17:20 -0500
Subject: [rsyslog] rsyslog step by step guide
In-Reply-To: <CAD7Ssm-PqyytX+09uP9GExpGX-mzDnUeugRJH-V47omphiXg=w@mail.gmail.com>
References: <CAD7Ssm9SaFG4TXDU38o6xG7dwKurnpFuz835MMhxRPthcMRLXw@mail.gmail.com>
	<CAD7Ssm9tGWMPb9K52wgYkRj93E4vY++=11Fas=ObBFCMUwyU+g@mail.gmail.com>
	<CAGWsdOhi6vD7m6-+o8nvV+icBPKUrWTsQ1xG0yL7owC1EYDMCw@mail.gmail.com>
	<CAD7Ssm-PqyytX+09uP9GExpGX-mzDnUeugRJH-V47omphiXg=w@mail.gmail.com>
Message-ID: <13969_1323836243_0LW600AIBEKWDP20_A9E2D430-A368-455E-BF19-8CE147684E69@nyp.org>


On Dec 13, 2011, at 9:55 PM, Kaushal Shriyan wrote:

> Hi Michael,
>
> Apologies if my earlier post was meant to be rude, I have gone through
> http://wiki.rsyslog.com/index.php/Main_Page. Basically i was looking out
> for something like a remote centralized rsyslog server and collect all
> syslogs from remote linux clients and any Open Source UI web interface
> similar in line with "splunk" to query and parse those logs. The reason
> being splunk is a paid version.
>
> Let me know if you have further questions and once again apologies.
>
> Regards
>
> Kaushal
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

http://bit.ly/rR28t6


This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message. Thank you.


--------------------

This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited.  If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message.  Thank you.




--------------------

This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited.  If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message.  Thank you.




From theinric at redhat.com  Wed Dec 14 17:24:06 2011
From: theinric at redhat.com (Tomas Heinrich)
Date: Wed, 14 Dec 2011 17:24:06 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE7C388.5060700@civ.zcu.cz>
References: <4EE6843E.7040905@civ.zcu.cz> <4EE78EBA.6050006@redhat.com>
	<4EE7C388.5060700@civ.zcu.cz>
Message-ID: <4EE8CDA6.4050400@redhat.com>

On 12/13/2011 10:28 PM, bodik wrote:
> thanks for reply I tried this one, at it stops client from segfault ...
> is that what you mean to do ? or we shloud discard "case eDestFORW:"
> completely ?

My guess at the solution is attached. Please let me know if it works for 
you.

Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsyslog-5.8.6-omgssapi-segv.patch
Type: text/x-patch
Size: 543 bytes
Desc: not available
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111214/c2095932/attachment.bin>

From rgerhards at hq.adiscon.com  Wed Dec 14 18:21:20 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 14 Dec 2011 18:21:20 +0100
Subject: [rsyslog] Feedback Request
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>

Hi all,

I have finally consolidated the info how I intend to design the log store
secure storage system in regard to digital signatures. As security is easy to
get wrong, I would appreciate as widespread feedback as possible. Please have
a look at the idea and feel free to send it to others that may be interested:

http://www.logtools.org/logstore-digital-signatures/

Thanks,
Rainer


From bodik at civ.zcu.cz  Thu Dec 15 09:52:35 2011
From: bodik at civ.zcu.cz (bodik)
Date: Thu, 15 Dec 2011 09:52:35 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE8CDA6.4050400@redhat.com>
References: <4EE6843E.7040905@civ.zcu.cz> <4EE78EBA.6050006@redhat.com>
	<4EE7C388.5060700@civ.zcu.cz> <4EE8CDA6.4050400@redhat.com>
Message-ID: <4EE9B553.5010108@civ.zcu.cz>

Dne 12/14/11 17:24, Tomas Heinrich napsal(a):
> On 12/13/2011 10:28 PM, bodik wrote:
>> thanks for reply I tried this one, at it stops client from segfault ...
>> is that what you mean to do ? or we shloud discard "case eDestFORW:"
>> completely ?
> 
> My guess at the solution is attached. Please let me know if it works for you.

it works ;) .. thanks a lot, will you push it to upstream please ?

bodik

From rgerhards at hq.adiscon.com  Thu Dec 15 10:37:41 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 15 Dec 2011 10:37:41 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE9B553.5010108@civ.zcu.cz>
References: <4EE6843E.7040905@civ.zcu.cz>
	<4EE78EBA.6050006@redhat.com><4EE7C388.5060700@civ.zcu.cz>
	<4EE8CDA6.4050400@redhat.com> <4EE9B553.5010108@civ.zcu.cz>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA728162D@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of bodik
> Sent: Thursday, December 15, 2011 9:53 AM
> To: Tomas Heinrich
> Cc: rsyslog-users; Daniel Kouril
> Subject: Re: [rsyslog] omgssapi segfault
> 
> Dne 12/14/11 17:24, Tomas Heinrich napsal(a):
> > On 12/13/2011 10:28 PM, bodik wrote:
> >> thanks for reply I tried this one, at it stops client from segfault
> ...
> >> is that what you mean to do ? or we shloud discard "case eDestFORW:"
> >> completely ?
> >
> > My guess at the solution is attached. Please let me know if it works
> for you.
> 
> it works ;) .. thanks a lot, will you push it to upstream please ?

I'll merge it :)

Rainer
> 
> bodik
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From david at lang.hm  Thu Dec 15 20:16:47 2011
From: david at lang.hm (david at lang.hm)
Date: Thu, 15 Dec 2011 11:16:47 -0800 (PST)
Subject: [rsyslog] Feedback Request
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112151057140.18571@asgard.lang.hm>

On Wed, 14 Dec 2011, Rainer Gerhards wrote:

> I have finally consolidated the info how I intend to design the log store
> secure storage system in regard to digital signatures. As security is easy to
> get wrong, I would appreciate as widespread feedback as possible. Please have
> a look at the idea and feel free to send it to others that may be interested:
>
> http://www.logtools.org/logstore-digital-signatures/

Overall this looks good, but one significant issue is that if the logtools 
on the box have the ability to access the keys to sign something, an 
attacker on the box can get access to the key as well and sign his 
replacement logs.

This does make it harder to do, but it doesn't prevent it.

The textbook answer to this is to not have the passphrase for the key 
anywhere other than in ram. The problem with this textbook answer is that 
this requires someone to type in the passphrase every time to tool starts 
(which isn't practical in just about all environments)

The other answer to this is to involve an external box to do the signature 
(including timestamping the signature so that an attacker's modification 
would be detected by the out of place timestamp), but this isn't that much 
better than just sending the hash/log elsewhere.

This is the catch-22 of most PKI 'solutions'

David Lang

From rgerhards at hq.adiscon.com  Fri Dec 16 11:10:54 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 16 Dec 2011 11:10:54 +0100
Subject: [rsyslog] omgssapi segfault
In-Reply-To: <4EE8CDA6.4050400@redhat.com>
References: <4EE6843E.7040905@civ.zcu.cz>
	<4EE78EBA.6050006@redhat.com><4EE7C388.5060700@civ.zcu.cz>
	<4EE8CDA6.4050400@redhat.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281642@GRFEXC.intern.adiscon.com>

FYI: I have just merged the patch.

Thx! Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Tomas Heinrich
> Sent: Wednesday, December 14, 2011 5:24 PM
> To: bodik
> Cc: rsyslog-users; Daniel Kouril
> Subject: Re: [rsyslog] omgssapi segfault
> 
> On 12/13/2011 10:28 PM, bodik wrote:
> > thanks for reply I tried this one, at it stops client from segfault ...
> > is that what you mean to do ? or we shloud discard "case eDestFORW:"
> > completely ?
> 
> My guess at the solution is attached. Please let me know if it works for
you.
> 
> Tomas

From rgerhards at hq.adiscon.com  Fri Dec 16 11:14:03 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 16 Dec 2011 11:14:03 +0100
Subject: [rsyslog] Feedback Request
In-Reply-To: <alpine.DEB.2.02.1112151057140.18571@asgard.lang.hm>
References: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112151057140.18571@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281643@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Thursday, December 15, 2011 8:17 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Feedback Request
> 
> On Wed, 14 Dec 2011, Rainer Gerhards wrote:
> 
> > I have finally consolidated the info how I intend to design the log
> > store secure storage system in regard to digital signatures. As
> > security is easy to get wrong, I would appreciate as widespread
> > feedback as possible. Please have a look at the idea and feel free to
send it
> to others that may be interested:
> >
> > http://www.logtools.org/logstore-digital-signatures/
> 
> Overall this looks good, but one significant issue is that if the logtools
on the
> box have the ability to access the keys to sign something, an attacker on
the
> box can get access to the key as well and sign his replacement logs.
> 
> This does make it harder to do, but it doesn't prevent it.
> 
> The textbook answer to this is to not have the passphrase for the key
> anywhere other than in ram. The problem with this textbook answer is that
> this requires someone to type in the passphrase every time to tool starts
> (which isn't practical in just about all environments)
> 
> The other answer to this is to involve an external box to do the signature
> (including timestamping the signature so that an attacker's modification
> would be detected by the out of place timestamp), but this isn't that much
> better than just sending the hash/log elsewhere.
> 
> This is the catch-22 of most PKI 'solutions'

Yeah, good reminder, but I agree I don't have any good idea on how to solve
that dilemma...

Rainer

From bodik at civ.zcu.cz  Fri Dec 16 11:15:53 2011
From: bodik at civ.zcu.cz (bodik)
Date: Fri, 16 Dec 2011 11:15:53 +0100
Subject: [rsyslog] omgssapi prevents local logs when remote server is down
 && reconnect DoS
Message-ID: <4EEB1A59.7070908@civ.zcu.cz>

Hello,

first)

finally I manage om/imgssapi to work, we also put in a little patch to save
principal into beginning of the message, it looks like it's working fine ...

  http://home.zcu.cz/~bodik/rsyslog/

but

while testing we have found, that when 2 syslog servers are configured in
client, and one of them is not responding to gssapi transport, rsyslog stops
even local logging ;(


I tested it in 2 scenarios, and it looks like order of remote syslog servers
somehow matters ..

---------------- working
$ModLoad omgssapi
$GSSForwardServiceName host
*.* :omgssapi:<server.down>
*.* :omgssapi:<server.up>


In latter case, there is only "rsyslog startup" message coming in (to
<server.up>, followed by nothing, and no logs are going to be written to local
logs ..

---------------- not working
$ModLoad omgssapi
$GSSForwardServiceName host
*.* :omgssapi:<server.up>
*.* :omgssapi:<server.down>








second)

I found, that when remote syslog server is down, client makes about 2000
attempts to connect in very short time before it backs off. after some logs are
comming from `logger`, it makes another round, this will result in severe DDoS
when deployed in mid sized network ;(( ...



do you have any ideas how to solve theese issues please ?

bodik

From maykel at maykel.sytes.net  Fri Dec 16 12:07:44 2011
From: maykel at maykel.sytes.net (=?ISO-8859-1?Q?Maykel_Franco_Hern=E1ndez?=)
Date: Fri, 16 Dec 2011 12:07:44 +0100
Subject: [rsyslog] Send apache logs to remote rsyslogd
Message-ID: <4EEB2680.2050009@maykel.sytes.net>

Hi, I followed this guide explains the configuration to send logs apache to rsyslogd remote server. I configured the server and the client but I have a problem. Rsyslog client only send the file error.log to the remote server. The access.log not found in the file syslog the remote server logs.


http://wiki.rsyslog.com/index.php/Working_Apache_and_Rsyslog_configuration

http://rsyslog.com/sending-messages-to-a-remote-syslog-server/

http://rsyslog.com/receiving-messages-from-a-remote-system/

Can I help me please??

Thanks in advanced. Sorry for my English.


From rgerhards at hq.adiscon.com  Fri Dec 16 12:22:58 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 16 Dec 2011 12:22:58 +0100
Subject: [rsyslog] omgssapi prevents local logs when remote server is
	down && reconnect DoS
In-Reply-To: <4EEB1A59.7070908@civ.zcu.cz>
References: <4EEB1A59.7070908@civ.zcu.cz>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281646@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of bodik
> Sent: Friday, December 16, 2011 11:16 AM
> Cc: rsyslog-users; Daniel Kouril
> Subject: [rsyslog] omgssapi prevents local logs when remote server is down
> && reconnect DoS
> 
> Hello,
> 
> first)
> 
> finally I manage om/imgssapi to work, we also put in a little patch to save
> principal into beginning of the message, it looks like it's working fine
...

That changes the on-the-wire format. If it's not an option,I can not include
it -- sorry...
> 
>   http://home.zcu.cz/~bodik/rsyslog/
> 
> but
> 
> while testing we have found, that when 2 syslog servers are configured in
> client, and one of them is not responding to gssapi transport, rsyslog
stops
> even local logging ;(

See:
http://rsyslog.com/doc/rsyslog_reliable_forwarding.html

Rainer

From bodik at civ.zcu.cz  Fri Dec 16 12:59:46 2011
From: bodik at civ.zcu.cz (bodik)
Date: Fri, 16 Dec 2011 12:59:46 +0100
Subject: [rsyslog] omgssapi prevents local logs when remote server is
 down && reconnect DoS
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281646@GRFEXC.intern.adiscon.com>
References: <4EEB1A59.7070908@civ.zcu.cz>
	<9B6E2A8877C38245BFB15CC491A11DA7281646@GRFEXC.intern.adiscon.com>
Message-ID: <4EEB32B2.4090803@civ.zcu.cz>

Dne 12/16/11 12:22, Rainer Gerhards napsal(a):
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of bodik
>> Sent: Friday, December 16, 2011 11:16 AM
>> Cc: rsyslog-users; Daniel Kouril
>> Subject: [rsyslog] omgssapi prevents local logs when remote server is down
>> && reconnect DoS
>>
>> Hello,
>>
>> first)
>>
>> finally I manage om/imgssapi to work, we also put in a little patch to save
>> principal into beginning of the message, it looks like it's working fine
>>   http://home.zcu.cz/~bodik/rsyslog/
> That changes the on-the-wire format. If it's not an option,I can not include
> it -- sorry...

it's just a a PoC now. if it will be in form that can be configured from config
file it would be accepted ?

or the problem is in the way we include information to the message ?
or we have to put feature in other part of rsyslogd ?


>>
>> but
>>
>> while testing we have found, that when 2 syslog servers are configured in
>> client, and one of them is not responding to gssapi transport, rsyslog
> stops
>> even local logging ;(
> 
> See:
> http://rsyslog.com/doc/rsyslog_reliable_forwarding.html

thanks, now it works like a charm ...


what about that reconnect DoS ?

bodik

From aoz.syn at gmail.com  Fri Dec 16 14:43:58 2011
From: aoz.syn at gmail.com (RB)
Date: Fri, 16 Dec 2011 06:43:58 -0700
Subject: [rsyslog] Feedback Request
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281626@GRFEXC.intern.adiscon.com>
Message-ID: <CADkMHC=UJFPFNtBXOH8-4a9nOQdr0mF2q+QFa4i-vGHoteaB6Q@mail.gmail.com>

On Wed, Dec 14, 2011 at 10:21, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
> I have finally consolidated the info how I intend to design the log store
> secure storage system in regard to digital signatures. As security is easy to
> get wrong, I would appreciate as widespread feedback as possible. Please have
> a look at the idea and feel free to send it to others that may be interested:
>
> http://www.logtools.org/logstore-digital-signatures/

I've not read your proposal yet and this suggestion may be inane, but
check out the AFF specifications.  AFF is a forensic file format
designed with the ability to cryptographically sign all or portions of
the evidence.  You may get some "sideways" input there.

From david at lang.hm  Fri Dec 16 18:25:39 2011
From: david at lang.hm (david at lang.hm)
Date: Fri, 16 Dec 2011 09:25:39 -0800 (PST)
Subject: [rsyslog] omgssapi prevents local logs when remote server is
 down && reconnect DoS
In-Reply-To: <4EEB32B2.4090803@civ.zcu.cz>
References: <4EEB1A59.7070908@civ.zcu.cz>
	<9B6E2A8877C38245BFB15CC491A11DA7281646@GRFEXC.intern.adiscon.com>
	<4EEB32B2.4090803@civ.zcu.cz>
Message-ID: <alpine.DEB.2.02.1112160923260.18571@asgard.lang.hm>

On Fri, 16 Dec 2011, bodik wrote:

> Dne 12/16/11 12:22, Rainer Gerhards napsal(a):
>>> -----Original Message-----
>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>>> bounces at lists.adiscon.com] On Behalf Of bodik
>>> Sent: Friday, December 16, 2011 11:16 AM
>>> Cc: rsyslog-users; Daniel Kouril
>>> Subject: [rsyslog] omgssapi prevents local logs when remote server is down
>>> && reconnect DoS
>>>
>>> Hello,
>>>
>>> first)
>>>
>>> finally I manage om/imgssapi to work, we also put in a little patch to save
>>> principal into beginning of the message, it looks like it's working fine
>>>   http://home.zcu.cz/~bodik/rsyslog/
>> That changes the on-the-wire format. If it's not an option,I can not include
>> it -- sorry...
>
> it's just a a PoC now. if it will be in form that can be configured from config
> file it would be accepted ?
>
> or the problem is in the way we include information to the message ?
> or we have to put feature in other part of rsyslogd ?

the best way to do this would be to make this value a property and then 
use the normal formatting options.

Rainer, with liblognorm you have some mechanism to create properties 
dynamically rather than just the hard-coded set. Is this something that 
can be extended easily for other input or parsing modules to create 
properties?

David Lang


From rgerhards at hq.adiscon.com  Fri Dec 16 18:50:57 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 16 Dec 2011 18:50:57 +0100
Subject: [rsyslog] omgssapi prevents local logs when remote server is
	down && reconnect DoS
In-Reply-To: <alpine.DEB.2.02.1112160923260.18571@asgard.lang.hm>
References: <4EEB1A59.7070908@civ.zcu.cz><9B6E2A8877C38245BFB15CC491A11DA7281646@GRFEXC.intern.adiscon.com><4EEB32B2.4090803@civ.zcu.cz>
	<alpine.DEB.2.02.1112160923260.18571@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA728164D@GRFEXC.intern.adiscon.com>

> > or the problem is in the way we include information to the message ?
> > or we have to put feature in other part of rsyslogd ?
> 
> the best way to do this would be to make this value a property and then use
> the normal formatting options.

Yeah, that would be the way to go.
> 
> Rainer, with liblognorm you have some mechanism to create properties
> dynamically rather than just the hard-coded set. Is this something that can
be
> extended easily for other input or parsing modules to create properties?

It can, but it requires more work. Currently its limited to liblognorm. I
need to integrate that capability into the regular mechanism, what also means
rewriting small parts of the disk queue code. Unfortuantely, there is so much
going on at the moment...

Rainer

From kaushalshriyan at gmail.com  Sun Dec 18 08:01:26 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Sun, 18 Dec 2011 12:31:26 +0530
Subject: [rsyslog] User with ldap authentication to login to loganalyzer Web
	Interface
Message-ID: <CAD7Ssm92tggGWg6RrmVz_GbmNrzA98An3rTTn7FY7CnLxxBURA@mail.gmail.com>

Hi

Can ldap authentication be mapped to loganalyzer webinterface meaning any
user can login to loganalyzer web interface using ldap login credentials.
Any ideas?

Regards,

Kaushal

From kaushalshriyan at gmail.com  Sun Dec 18 18:26:10 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Sun, 18 Dec 2011 22:56:10 +0530
Subject: [rsyslog] R in Rsyslog stands for ?
Message-ID: <CAD7Ssm_4kqNOVVV75fpfJ9ief20gZ55=BScXZzcQ3=JAqk5s+A@mail.gmail.com>

Hi,

What does R in Rsyslog stands for ?

Regards,

Kaushal

From cclark at quadrantsec.com  Sun Dec 18 18:53:32 2011
From: cclark at quadrantsec.com (=?utf-8?B?Q2hhbXAgQ2xhcmsgSUlJIChRdWFkcmFudCk=?=)
Date: Sun, 18 Dec 2011 12:53:32 -0500
Subject: [rsyslog] =?utf-8?q?R_in_Rsyslog_stands_for_=3F?=
Message-ID: <201112181753.pBIHr9Dh018378@a.qsecure.net>

My guess is Rainer. :)

Champ Clark III - Quadrant information security

----- Reply message -----
From: "Kaushal Shriyan" <kaushalshriyan at gmail.com>
Date: Sun, Dec 18, 2011 12:26
Subject: [rsyslog] R in Rsyslog stands for ?
To: "rsyslog-users" <rsyslog at lists.adiscon.com>

Hi,

What does R in Rsyslog stands for ?

Regards,

Kaushal
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/

From rgerhards at hq.adiscon.com  Sun Dec 18 19:53:44 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Sun, 18 Dec 2011 19:53:44 +0100
Subject: [rsyslog] R in Rsyslog stands for ?
Message-ID: <009d01ccbdb6$05b60315$100013ac@intern.adiscon.com>

>From phone: nope: reliable. See history doc from the doc set ( i dont have the link at hand)

Rainer"Champ Clark III (Quadrant)" <cclark at quadrantsec.com> hat geschrieben:My guess is Rainer. :)

Champ Clark III - Quadrant information security

----- Reply message -----
From: "Kaushal Shriyan" <kaushalshriyan at gmail.com>
Date: Sun, Dec 18, 2011 12:26
Subject: [rsyslog] R in Rsyslog stands for ?
To: "rsyslog-users" <rsyslog at lists.adiscon.com>

Hi,

What does R in Rsyslog stands for ?

Regards,

Kaushal
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/

From ariel.p at hostdime.com  Sun Dec 18 22:13:07 2011
From: ariel.p at hostdime.com (Ariel Poliak)
Date: Sun, 18 Dec 2011 16:13:07 -0500
Subject: [rsyslog] User with ldap authentication to login to loganalyzer
 Web Interface
In-Reply-To: <CAD7Ssm92tggGWg6RrmVz_GbmNrzA98An3rTTn7FY7CnLxxBURA@mail.gmail.com>
References: <CAD7Ssm92tggGWg6RrmVz_GbmNrzA98An3rTTn7FY7CnLxxBURA@mail.gmail.com>
Message-ID: <4EEE5763.2000902@hostdime.com>

Although LogAnalyzer does not support LDAP authentication natively, you 
can use mod_ldap and mod_authnz_ldap to configure authentication in Apache:
http://httpd.apache.org/docs/2.2/mod/mod_ldap.html
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Or use the LDAP authentication backend in lighttpd:
http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModAuth#ldap

Or a LDAP authentication module for the HTTP daemon of your choice...

You would be password-protecting the LA directory, and using LDAP to 
grant access.
Although you can't get separation of privileges using this method, the 
log files will show what logged in user ran what, giving you 
accountability in case of errors/compromise.

Ariel Poliak
Network and Security Operations
HostDime.com, Inc.


On 2011-12-18 02:01, Kaushal Shriyan wrote:
> Hi
>
> Can ldap authentication be mapped to loganalyzer webinterface meaning any
> user can login to loganalyzer web interface using ldap login credentials.
> Any ideas?
>
> Regards,
>
> Kaushal
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1708 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111218/d5072417/attachment.bin>

From kaushalshriyan at gmail.com  Sun Dec 18 23:27:50 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Mon, 19 Dec 2011 03:57:50 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
Message-ID: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>

Hi,

Is there a trigger feature available in Rsyslog meaning if for example
rsyslog detects any disk failure or memory failure or any hardware failure
and also it may be a software bug or critical error on any client host, it
should trigger an event in the form of sms or email to the administrator.

Regards,

Kaushal

From rpkelly22 at gmail.com  Sun Dec 18 23:51:39 2011
From: rpkelly22 at gmail.com (Ryan Kelly)
Date: Sun, 18 Dec 2011 17:51:39 -0500
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
Message-ID: <20111218225139.GA30773@llserver.lakeliving.com>

> Is there a trigger feature available in Rsyslog meaning if for example
> rsyslog detects any disk failure or memory failure or any hardware failure
> and also it may be a software bug or critical error on any client host, it
> should trigger an event in the form of sms or email to the administrator.
Please check out the ommail module. You can then configure rsyslog to
match on certain log messages containing the failures you are talking
about and send email to administrators (or to an email-to-sms gateway).

-Ryan Kelly


From kaushalshriyan at gmail.com  Mon Dec 19 00:07:09 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Mon, 19 Dec 2011 04:37:09 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <20111218225139.GA30773@llserver.lakeliving.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
Message-ID: <CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>

On Mon, Dec 19, 2011 at 4:21 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:

> > Is there a trigger feature available in Rsyslog meaning if for example
> > rsyslog detects any disk failure or memory failure or any hardware
> failure
> > and also it may be a software bug or critical error on any client host,
> it
> > should trigger an event in the form of sms or email to the administrator.
> Please check out the ommail module. You can then configure rsyslog to
> match on certain log messages containing the failures you are talking
> about and send email to administrators (or to an email-to-sms gateway).
>
> -Ryan Kelly
>
>
Hi Ryan,

Thanks for the quick reply, I have around 200 client hosts which pushes
syslog to a Remote Centralized Rsyslog server. Do i need to use
http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
setup only on Remote Centralized Rsyslog server.

Please suggest

Thanks and Regards,

Kaushal


_______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From rpkelly22 at gmail.com  Mon Dec 19 00:25:03 2011
From: rpkelly22 at gmail.com (Ryan Kelly)
Date: Sun, 18 Dec 2011 18:25:03 -0500
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
Message-ID: <20111218232503.GB30773@llserver.lakeliving.com>

> Thanks for the quick reply, I have around 200 client hosts which pushes
> syslog to a Remote Centralized Rsyslog server. Do i need to use
> http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
> setup only on Remote Centralized Rsyslog server.
It can be setup just on the centralized server, assuming those messages
you are interested in are actually being forwarded to that server.

-Ryan Kelly


From kaushalshriyan at gmail.com  Mon Dec 19 00:48:38 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Mon, 19 Dec 2011 05:18:38 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <20111218232503.GB30773@llserver.lakeliving.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
Message-ID: <CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>

On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:

> > Thanks for the quick reply, I have around 200 client hosts which pushes
> > syslog to a Remote Centralized Rsyslog server. Do i need to use
> > http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
> > setup only on Remote Centralized Rsyslog server.
> It can be setup just on the centralized server, assuming those messages
> you are interested in are actually being forwarded to that server.
>
>
Thanks Ryan and any further use cases or several examples regarding
$template (*Configuration Directives*) as mentioned in
http://rsyslog.com/doc/ommail.html

Please suggest.

Regards

Kaushal

From kaushalshriyan at gmail.com  Mon Dec 19 05:00:48 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Mon, 19 Dec 2011 09:30:48 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
Message-ID: <CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>

On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan
<kaushalshriyan at gmail.com>wrote:

>
>
> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>
>> > Thanks for the quick reply, I have around 200 client hosts which pushes
>> > syslog to a Remote Centralized Rsyslog server. Do i need to use
>> > http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
>> > setup only on Remote Centralized Rsyslog server.
>> It can be setup just on the centralized server, assuming those messages
>> you are interested in are actually being forwarded to that server.
>>
>>
> Thanks Ryan and any further use cases or several examples regarding
> $template (*Configuration Directives*) as mentioned in
> http://rsyslog.com/doc/ommail.html
>
> Please suggest.
>
> Regards
>
> Kaushal
>

Hi,

I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
alerts using email-to-sms feature
Basically i am interested in various conditions or strings which can be
captured or trapped and post it to the user

For example "if $msg contains 'hard disk fatal failure' then
:ommail:;mailBody" as per that link

so how would i know what strings i can expect if there is a hardware or
software error in the syslog ?
I mean typical error description for specific problem

Please guide me

Regards

Kaushal

From kaushalshriyan at gmail.com  Mon Dec 19 05:15:49 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Mon, 19 Dec 2011 09:45:49 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
Message-ID: <CAD7Ssm-gyQspVt1UR0E52FjqPWzo26vsRJzSs_ivydULZzaFKg@mail.gmail.com>

On Mon, Dec 19, 2011 at 9:30 AM, Kaushal Shriyan
<kaushalshriyan at gmail.com>wrote:

>
>
> On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan <kaushalshriyan at gmail.com
> > wrote:
>
>>
>>
>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>
>>> > Thanks for the quick reply, I have around 200 client hosts which pushes
>>> > syslog to a Remote Centralized Rsyslog server. Do i need to use
>>> > http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it
>>> be
>>> > setup only on Remote Centralized Rsyslog server.
>>> It can be setup just on the centralized server, assuming those messages
>>> you are interested in are actually being forwarded to that server.
>>>
>>>
>> Thanks Ryan and any further use cases or several examples regarding
>> $template (*Configuration Directives*) as mentioned in
>> http://rsyslog.com/doc/ommail.html
>>
>> Please suggest.
>>
>> Regards
>>
>> Kaushal
>>
>
> Hi,
>
> I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
> alerts using email-to-sms feature
> Basically i am interested in various conditions or strings which can be
> captured or trapped and post it to the user
>
> For example "if $msg contains 'hard disk fatal failure' then
> :ommail:;mailBody" as per that link
>
> so how would i know what strings i can expect if there is a hardware or
> software error in the syslog ?
> I mean typical error description for specific problem
>
> Please guide me
>
> Regards
>
> Kaushal
>
> Hi Again

Also as per http://wiki.rsyslog.com/index.php/FailoverSyslogServer, the
data is stored in /var/log/localbuffer on client hosts
Once the  Centralized Primary or Secondary Server is up, will it push the
data which was stored locally on client hosts in /var/log/localbuffer to
the centralized server automatically ?

Regards,

Kaushal

From pchacin at inteleye.com  Mon Dec 19 12:59:49 2011
From: pchacin at inteleye.com (Pablo Chacin)
Date: Mon, 19 Dec 2011 12:59:49 +0100
Subject: [rsyslog] Fwd: zeromq modules for rsyslog
Message-ID: <4EEF2735.7080700@inteleye.com>

Hi all

I already sent this message to the developers of the
zeromq modules, but  I'll appreciate the comments from any
one that has experience with this module.

Pablo

-------- Original Message --------
Subject: 	zeromq modules for rsyslog
Date: 	Fri, 16 Dec 2011 20:01:16 +0100
From: 	Pablo Chacin <pchacin at inteleye.com>
To: 	ken at bonsai.com



Hi Ken

I've been trying to make the zeromq modules for rsyslog but with no luck.
First, I tried with rsyslog 6.3.6 and had to tweak a little bit to make them
compile (see the attached diff files). However, I can't make them work.
I tried sending log records from a test program.

Also, tried to use rsyslog to read records from a file (see zmq.log) ,
sent it using omzeromq to imzeromq and the
to a output file, but it didn't work (see attached config file).

I'm not getting any error, but neither any signal of zeromq doing anything.

I'll appreciate if you could help me with this. For example, how to debug
the modules in rsyslog (I tried with gdb but couldn't find a way to set a
breakpoint at any of these modules)

Thanks in advance

Pablo

-- 
Pablo Chacin
R&D Engineer
Sensefields SL
Tlf (+34) 93 418 05 85
Baixada de Gomis 1,
08023 Barcelona (Spain)
http://www.sensefields.com/




-------------- next part --------------
A non-text attachment was scrubbed...
Name: im.diff
Type: text/x-patch
Size: 522 bytes
Desc: not available
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111219/d8258151/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: om.diff
Type: text/x-patch
Size: 780 bytes
Desc: not available
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111219/d8258151/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: zmqlogger.conf
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111219/d8258151/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zmq.log
Type: text/x-log
Size: 642 bytes
Desc: not available
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111219/d8258151/attachment-0002.bin>

From cclark at quadrantsec.com  Mon Dec 19 14:44:38 2011
From: cclark at quadrantsec.com (=?utf-8?B?Q2hhbXAgQ2xhcmsgSUlJIChRdWFkcmFudCk=?=)
Date: Mon, 19 Dec 2011 08:44:38 -0500
Subject: [rsyslog] =?utf-8?q?R_in_Rsyslog_stands_for_=3F?=
Message-ID: <201112191344.pBJDiLY4032665@a.qsecure.net>

Dang!   It was more fun guessing :)

Champ Clark III - Quadrant information security

----- Reply message -----
From: "Rainer Gerhards" <rgerhards at hq.adiscon.com>
Date: Sun, Dec 18, 2011 13:53
Subject: [rsyslog] R in Rsyslog stands for ?
To: <rsyslog at lists.adiscon.com>

From phone: nope: reliable. See history doc from the doc set ( i dont have the link at hand)

Rainer"Champ Clark III (Quadrant)" <cclark at quadrantsec.com> hat geschrieben:My guess is Rainer. :)

Champ Clark III - Quadrant information security

----- Reply message -----
From: "Kaushal Shriyan" <kaushalshriyan at gmail.com>
Date: Sun, Dec 18, 2011 12:26
Subject: [rsyslog] R in Rsyslog stands for ?
To: "rsyslog-users" <rsyslog at lists.adiscon.com>

Hi,

What does R in Rsyslog stands for ?

Regards,

Kaushal
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/

From taotetek at gmail.com  Mon Dec 19 17:41:45 2011
From: taotetek at gmail.com (Brian Knox)
Date: Mon, 19 Dec 2011 11:41:45 -0500
Subject: [rsyslog] Fwd: zeromq modules for rsyslog
In-Reply-To: <4EEF2735.7080700@inteleye.com>
References: <4EEF2735.7080700@inteleye.com>
Message-ID: <CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>

Pablo -

I'm one of the maintainers of the rsyslog zeromq modules.  I wanted to drop
you a note to let you know, we have never built the modules against rsyslog
6 (we are using 5.8.x).  We have plans to begin tests against rsyslog 6
early next year.

I'm working on a "getting started" article with our plugins that should be
of use to people trying to use them that should be completed this week.
I'll drop a note on the mailing list when the article is up!

Brian

On Mon, Dec 19, 2011 at 6:59 AM, Pablo Chacin <pchacin at inteleye.com> wrote:

> Hi all
>
> I already sent this message to the developers of the
> zeromq modules, but  I'll appreciate the comments from any
> one that has experience with this module.
>
> Pablo
>
> -------- Original Message --------
> Subject:        zeromq modules for rsyslog
> Date:   Fri, 16 Dec 2011 20:01:16 +0100
> From:   Pablo Chacin <pchacin at inteleye.com>
> To:     ken at bonsai.com
>
>
>
> Hi Ken
>
> I've been trying to make the zeromq modules for rsyslog but with no luck.
> First, I tried with rsyslog 6.3.6 and had to tweak a little bit to make
> them
> compile (see the attached diff files). However, I can't make them work.
> I tried sending log records from a test program.
>
> Also, tried to use rsyslog to read records from a file (see zmq.log) ,
> sent it using omzeromq to imzeromq and the
> to a output file, but it didn't work (see attached config file).
>
> I'm not getting any error, but neither any signal of zeromq doing anything.
>
> I'll appreciate if you could help me with this. For example, how to debug
> the modules in rsyslog (I tried with gdb but couldn't find a way to set a
> breakpoint at any of these modules)
>
> Thanks in advance
>
> Pablo
>
> --
> Pablo Chacin
> R&D Engineer
> Sensefields SL
> Tlf (+34) 93 418 05 85
> Baixada de Gomis 1,
> 08023 Barcelona (Spain)
> http://www.sensefields.com/
>
>
>
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>
>

From rgerhards at hq.adiscon.com  Mon Dec 19 17:44:57 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Mon, 19 Dec 2011 17:44:57 +0100
Subject: [rsyslog] Fwd: zeromq modules for rsyslog
In-Reply-To: <CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>
References: <4EEF2735.7080700@inteleye.com>
	<CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA728165F@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Brian Knox
> Sent: Monday, December 19, 2011 5:42 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Fwd: zeromq modules for rsyslog
> 
> Pablo -
> 
> I'm one of the maintainers of the rsyslog zeromq modules.  I wanted to drop
> you a note to let you know, we have never built the modules against rsyslog
> 6 (we are using 5.8.x).  We have plans to begin tests against rsyslog 6
early
> next year.

Off-topic, but maybe of interest: the config part in v6 is pretty different.
However, it should be easy to move to the new config system. I suggest to
look at e.g. omfile to see how it was modified.

Rainer

From pchacin at inteleye.com  Mon Dec 19 18:51:40 2011
From: pchacin at inteleye.com (Pablo Chacin)
Date: Mon, 19 Dec 2011 18:51:40 +0100
Subject: [rsyslog] Fwd: zeromq modules for rsyslog
In-Reply-To: <CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>
References: <4EEF2735.7080700@inteleye.com>
	<CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>
Message-ID: <4EEF79AC.1030200@inteleye.com>

Brian

Thanks for the info. That getting started guide will be of great help.
I'll spend some more time debugging the zeromq modules to see why
they fail and will report this info back to you.

I'll also see what Reiner said in the other message in the list about the
changes in the configuration.

I'll stay tuned waiting for news.

Pablo

On 12/19/2011 05:41 PM, Brian Knox wrote:
> Pablo -
>
> I'm one of the maintainers of the rsyslog zeromq modules.  I wanted to drop
> you a note to let you know, we have never built the modules against rsyslog
> 6 (we are using 5.8.x).  We have plans to begin tests against rsyslog 6
> early next year.
>
> I'm working on a "getting started" article with our plugins that should be
> of use to people trying to use them that should be completed this week.
> I'll drop a note on the mailing list when the article is up!
>
> Brian
>
> On Mon, Dec 19, 2011 at 6:59 AM, Pablo Chacin<pchacin at inteleye.com>  wrote:
>
>> Hi all
>>
>> I already sent this message to the developers of the
>> zeromq modules, but  I'll appreciate the comments from any
>> one that has experience with this module.
>>
>> Pablo
>>
>> -------- Original Message --------
>> Subject:        zeromq modules for rsyslog
>> Date:   Fri, 16 Dec 2011 20:01:16 +0100
>> From:   Pablo Chacin<pchacin at inteleye.com>
>> To:     ken at bonsai.com
>>
>>
>>
>> Hi Ken
>>
>> I've been trying to make the zeromq modules for rsyslog but with no luck.
>> First, I tried with rsyslog 6.3.6 and had to tweak a little bit to make
>> them
>> compile (see the attached diff files). However, I can't make them work.
>> I tried sending log records from a test program.
>>
>> Also, tried to use rsyslog to read records from a file (see zmq.log) ,
>> sent it using omzeromq to imzeromq and the
>> to a output file, but it didn't work (see attached config file).
>>
>> I'm not getting any error, but neither any signal of zeromq doing anything.
>>
>> I'll appreciate if you could help me with this. For example, how to debug
>> the modules in rsyslog (I tried with gdb but couldn't find a way to set a
>> breakpoint at any of these modules)
>>
>> Thanks in advance
>>
>> Pablo
>>
>> --
>> Pablo Chacin
>> R&D Engineer
>> Sensefields SL
>> Tlf (+34) 93 418 05 85
>> Baixada de Gomis 1,
>> 08023 Barcelona (Spain)
>> http://www.sensefields.com/
>>
>>
>>
>>
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>>
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/


-- 
Pablo Chacin
R&D Engineer
Sensefields SL
Tlf (+34) 93 418 05 85
Baixada de Gomis 1,
08023 Barcelona (Spain)
http://www.sensefields.com/



From smoser at ubuntu.com  Mon Dec 19 21:16:13 2011
From: smoser at ubuntu.com (Scott Moser)
Date: Mon, 19 Dec 2011 15:16:13 -0500 (EST)
Subject: [rsyslog] regression in V5 Stable branch for messages without
	TIMESTAMP
Message-ID: <alpine.DEB.2.02.1112191500360.4260@brickies>

Hi,

I have to apologize in advance for my general ignorance of syslog or
rsyslog specifically.

I'm using python logging [1] to write to syslog in cloud-init [2].
I've noticed a problem in the development version of ubuntu that has
rsyslog 5.8.6, that does not exist in the Ubuntu 11.10 release that has
rsyslog 5.8.1 [3].

The issue can be seen by running the attached test case.
If you run it like:
  $ ./python-logging-syslog.py foobar
You'll see output to the console of:
  [MYTAG] python-logging-syslog.py[DEBUG]: foobar
and in /var/log/syslog, you see a message like:
  Dec 19 19:01:21 server-3418 ogging-syslog.py[DEBUG]: foobar

strace led me to see that the python-logging messages do not have a
TIMESTAMP field directly after the PRIVAL.  As a result, 16 characters are
getting chopped from the incoming message.

It seems that rsyslog was previously more forgiving there and allow
messages without a TIMESTAMP.

The Ubuntu and Debian default rsyslog.conf has
  $ModLoad imuxsock
And I'm writing to syslog in python through /dev/log.

I've not tested, but it looks to me like this behavior might have changed
it would seem that commit 54cee2ce69c5bbd96aa51ac8636f4b029e2ceb7 [4]
might be the source of the change.

Is it intended that messages require the TIMESTAMP field now?

--
[1] http://docs.python.org/library/logging.html
[2] https://launchpad.net/cloud-init
[3] http://pad.lv/905419
[4] http://git.adiscon.com/?p=rsyslog.git;a=commit;h=54cee2ce69c5bbd96aa51ac8636f4b029e2ceb75
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-logging-syslog.py
Type: text/x-python
Size: 764 bytes
Desc: 
URL: <http://lists.adiscon.net/pipermail/rsyslog/attachments/20111219/3f06b644/attachment.py>

From mike.forbes at koordinates.com  Mon Dec 19 21:26:25 2011
From: mike.forbes at koordinates.com (Mike Forbes)
Date: Tue, 20 Dec 2011 09:26:25 +1300
Subject: [rsyslog] regression in V5 Stable branch for messages without
	TIMESTAMP
In-Reply-To: <alpine.DEB.2.02.1112191500360.4260@brickies>
References: <alpine.DEB.2.02.1112191500360.4260@brickies>
Message-ID: <CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com>

I can confirm this too..

In fact, I logged a bug earlier this month about it:

http://bugzilla.adiscon.com/show_bug.cgi?id=295

includes the crappy fix we had to do in order to get it to work.
(padding out the front of the log message)



On Tue, Dec 20, 2011 at 9:16 AM, Scott Moser <smoser at ubuntu.com> wrote:
> Hi,
>
> I have to apologize in advance for my general ignorance of syslog or
> rsyslog specifically.
>
> I'm using python logging [1] to write to syslog in cloud-init [2].
> I've noticed a problem in the development version of ubuntu that has
> rsyslog 5.8.6, that does not exist in the Ubuntu 11.10 release that has
> rsyslog 5.8.1 [3].
>
> The issue can be seen by running the attached test case.
> If you run it like:
> ?$ ./python-logging-syslog.py foobar
> You'll see output to the console of:
> ?[MYTAG] python-logging-syslog.py[DEBUG]: foobar
> and in /var/log/syslog, you see a message like:
> ?Dec 19 19:01:21 server-3418 ogging-syslog.py[DEBUG]: foobar
>
> strace led me to see that the python-logging messages do not have a
> TIMESTAMP field directly after the PRIVAL. ?As a result, 16 characters are
> getting chopped from the incoming message.
>
> It seems that rsyslog was previously more forgiving there and allow
> messages without a TIMESTAMP.
>
> The Ubuntu and Debian default rsyslog.conf has
> ?$ModLoad imuxsock
> And I'm writing to syslog in python through /dev/log.
>
> I've not tested, but it looks to me like this behavior might have changed
> it would seem that commit 54cee2ce69c5bbd96aa51ac8636f4b029e2ceb7 [4]
> might be the source of the change.
>
> Is it intended that messages require the TIMESTAMP field now?
>
> --
> [1] http://docs.python.org/library/logging.html
> [2] https://launchpad.net/cloud-init
> [3] http://pad.lv/905419
> [4] http://git.adiscon.com/?p=rsyslog.git;a=commit;h=54cee2ce69c5bbd96aa51ac8636f4b029e2ceb75
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>



-- 
// Mike Forbes
GPG: BFC7 3F32 2CCF D91F 53E1 ?DF88 1578 B2E4 1399 6844

From kaushalshriyan at gmail.com  Tue Dec 20 02:19:25 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Tue, 20 Dec 2011 06:49:25 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
Message-ID: <CAD7Ssm9muiSO8EwXP26iZWO4zBjbzZqLGGeOPQJHL4QL1FuUGw@mail.gmail.com>

On Mon, Dec 19, 2011 at 9:30 AM, Kaushal Shriyan
<kaushalshriyan at gmail.com>wrote:

>
>
> On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan <kaushalshriyan at gmail.com
> > wrote:
>
>>
>>
>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>
>>> > Thanks for the quick reply, I have around 200 client hosts which pushes
>>> > syslog to a Remote Centralized Rsyslog server. Do i need to use
>>> > http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it
>>> be
>>> > setup only on Remote Centralized Rsyslog server.
>>> It can be setup just on the centralized server, assuming those messages
>>> you are interested in are actually being forwarded to that server.
>>>
>>>
>> Thanks Ryan and any further use cases or several examples regarding
>> $template (*Configuration Directives*) as mentioned in
>> http://rsyslog.com/doc/ommail.html
>>
>> Please suggest.
>>
>> Regards
>>
>> Kaushal
>>
>
> Hi,
>
> I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
> alerts using email-to-sms feature
> Basically i am interested in various conditions or strings which can be
> captured or trapped and post it to the user
>
> For example "if $msg contains 'hard disk fatal failure' then
> :ommail:;mailBody" as per that link
>
> so how would i know what strings i can expect if there is a hardware or
> software error in the syslog ?
> I mean typical error description for specific problem
>
> Please guide me
>
> Regards
>
> Kaushal
>
>
Hi

Checking in again for my earlier post to this Mailing List.

Regards

Kaushal

From kaushalshriyan at gmail.com  Tue Dec 20 02:20:02 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Tue, 20 Dec 2011 06:50:02 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-gyQspVt1UR0E52FjqPWzo26vsRJzSs_ivydULZzaFKg@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
	<CAD7Ssm-gyQspVt1UR0E52FjqPWzo26vsRJzSs_ivydULZzaFKg@mail.gmail.com>
Message-ID: <CAD7Ssm8gK1X7rbbuvwKLJsF8ap1y-BdcngVssB0Y9zmgLmYhhQ@mail.gmail.com>

On Mon, Dec 19, 2011 at 9:45 AM, Kaushal Shriyan
<kaushalshriyan at gmail.com>wrote:

>
>
> On Mon, Dec 19, 2011 at 9:30 AM, Kaushal Shriyan <kaushalshriyan at gmail.com
> > wrote:
>
>>
>>
>> On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan <
>> kaushalshriyan at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>>
>>>> > Thanks for the quick reply, I have around 200 client hosts which
>>>> pushes
>>>> > syslog to a Remote Centralized Rsyslog server. Do i need to use
>>>> > http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it
>>>> be
>>>> > setup only on Remote Centralized Rsyslog server.
>>>> It can be setup just on the centralized server, assuming those messages
>>>> you are interested in are actually being forwarded to that server.
>>>>
>>>>
>>> Thanks Ryan and any further use cases or several examples regarding
>>> $template (*Configuration Directives*) as mentioned in
>>> http://rsyslog.com/doc/ommail.html
>>>
>>> Please suggest.
>>>
>>> Regards
>>>
>>> Kaushal
>>>
>>
>> Hi,
>>
>> I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
>> alerts using email-to-sms feature
>> Basically i am interested in various conditions or strings which can be
>> captured or trapped and post it to the user
>>
>> For example "if $msg contains 'hard disk fatal failure' then
>> :ommail:;mailBody" as per that link
>>
>> so how would i know what strings i can expect if there is a hardware or
>> software error in the syslog ?
>> I mean typical error description for specific problem
>>
>> Please guide me
>>
>> Regards
>>
>> Kaushal
>>
>> Hi Again
>
> Also as per http://wiki.rsyslog.com/index.php/FailoverSyslogServer, the
> data is stored in /var/log/localbuffer on client hosts
> Once the  Centralized Primary or Secondary Server is up, will it push the
> data which was stored locally on client hosts in /var/log/localbuffer to
> the centralized server automatically ?
>
> Regards,
>
> Kaushal
>
>
Hi

Checking in again for my earlier post to this Mailing List.

Regards

Kaushal

From david.donchez at smartjog.com  Tue Dec 20 11:12:31 2011
From: david.donchez at smartjog.com (David Donchez)
Date: Tue, 20 Dec 2011 11:12:31 +0100
Subject: [rsyslog] Rsyslog - RELP Issue - Configuration archiving
Message-ID: <4EF05F8F.7020206@smartjog.com>

Hi All,

I'm experiencing Rsyslog 5.8.1 with RELP Module on a Debian Squeeze x64
system.

My architecture est running fine but i have some question about the RELP
features.

I will explains my setup :

ServerA -> RELP -> Ingestor Server -> RELP -> 3  Remote Server.

My issue is :

If one of the 3 last remote server is crashed (e.g. full disk), All the
chain is slow and the server begin to queue all syslog messages. Is
there a way to continue to push to others servers?
I have seen with strace that the ingestor seems to be locked on a select
(Service unavailable from the remote server). It will be fine if rsyslog
can push to all others server even if one is crashed

This is my Ingestor config :
##
## Global conf
##

$WorkDirectory /var/spool/rsyslog/archive
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_archive
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

if $fromhost-ip startswith '10.' and $programname startswith 'TEST.'
then  :omrelp:10.19.0.3:514;RSYSLOG_ForwardFormat
& ~

$WorkDirectory /var/spool/rsyslog/dispatcher
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_dispatcher
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

#if $fromhost-ip startswith '10.' and $programname startswith 'TEST.'
then  :omrelp:10.19.0.10:20514
#& ~

$WorkDirectory /var/spool/rsyslog/system
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_system
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on


if ( $fromhost-ip startswith '10.' and not ( $programname  startswith
'TEST.' )) then :omrelp:10.19.0.4:514;RSYSLOG_ForwardFormat
& ~


Also i have another question about file archiving.

(One of the 3 Remove server above is a archive server).

I archive all logs in files.

My config is :
$WorkDirectory /mnt/space/
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on


$omfileziplevel  9
$template
Service,"/mnt/space/%$YEAR%-%$MONTH%-%$DAY%/%programname%/%HOSTNAME%/TEST.log.gz"

if $programname startswith 'TEST.' then ?Service
& ~


This setup work fine. But if a server is queuing for 3 days, then push
his queue, all logs will go in the "CURRENT DAY" directory on this
archive server ( Due to the template %$YEAR%-%$MONTH%-%$DAY%)
Is there a way to archive the log in the directory corresponding to the
generated date file ?

I have look to the "timegenerated" variables but it seems to be a little
bit complicated.

Thanks a lot for your help.





From rgerhards at hq.adiscon.com  Tue Dec 20 16:43:47 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Tue, 20 Dec 2011 16:43:47 +0100
Subject: [rsyslog] regression in V5 Stable branch for messages
	withoutTIMESTAMP
In-Reply-To: <CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com>
References: <alpine.DEB.2.02.1112191500360.4260@brickies>
	<CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281673@GRFEXC.intern.adiscon.com>

Sorry, too much going on at the moment...

I have now updated the bug tracker with a proposed patch and would appreciate
feedback (for details so bug tracker).

Rainer 

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Mike Forbes
> Sent: Monday, December 19, 2011 9:26 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] regression in V5 Stable branch for messages
> withoutTIMESTAMP
> 
> I can confirm this too..
> 
> In fact, I logged a bug earlier this month about it:
> 
> http://bugzilla.adiscon.com/show_bug.cgi?id=295
> 
> includes the crappy fix we had to do in order to get it to work.
> (padding out the front of the log message)
> 
> 
> 
> On Tue, Dec 20, 2011 at 9:16 AM, Scott Moser <smoser at ubuntu.com>
> wrote:
> > Hi,
> >
> > I have to apologize in advance for my general ignorance of syslog or
> > rsyslog specifically.
> >
> > I'm using python logging [1] to write to syslog in cloud-init [2].
> > I've noticed a problem in the development version of ubuntu that has
> > rsyslog 5.8.6, that does not exist in the Ubuntu 11.10 release that
> > has rsyslog 5.8.1 [3].
> >
> > The issue can be seen by running the attached test case.
> > If you run it like:
> > ?$ ./python-logging-syslog.py foobar
> > You'll see output to the console of:
> > ?[MYTAG] python-logging-syslog.py[DEBUG]: foobar and in
> > /var/log/syslog, you see a message like:
> > ?Dec 19 19:01:21 server-3418 ogging-syslog.py[DEBUG]: foobar
> >
> > strace led me to see that the python-logging messages do not have a
> > TIMESTAMP field directly after the PRIVAL. ?As a result, 16 characters
> > are getting chopped from the incoming message.
> >
> > It seems that rsyslog was previously more forgiving there and allow
> > messages without a TIMESTAMP.
> >
> > The Ubuntu and Debian default rsyslog.conf has
> > ?$ModLoad imuxsock
> > And I'm writing to syslog in python through /dev/log.
> >
> > I've not tested, but it looks to me like this behavior might have
> > changed it would seem that commit
> > 54cee2ce69c5bbd96aa51ac8636f4b029e2ceb7 [4] might be the source of
> the change.
> >
> > Is it intended that messages require the TIMESTAMP field now?
> >
> > --
> > [1] http://docs.python.org/library/logging.html
> > [2] https://launchpad.net/cloud-init
> > [3] http://pad.lv/905419
> > [4]
> >
> http://git.adiscon.com/?p=rsyslog.git;a=commit;h=54cee2ce69c5bbd96aa51
> > ac8636f4b029e2ceb75
> _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> >
> 
> 
> 
> --
> // Mike Forbes
> GPG: BFC7 3F32 2CCF D91F 53E1 ?DF88 1578 B2E4 1399 6844
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From smoser at ubuntu.com  Tue Dec 20 17:53:56 2011
From: smoser at ubuntu.com (Scott Moser)
Date: Tue, 20 Dec 2011 11:53:56 -0500 (EST)
Subject: [rsyslog] regression in V5 Stable branch for messages
 withoutTIMESTAMP
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281673@GRFEXC.intern.adiscon.com>
References: <alpine.DEB.2.02.1112191500360.4260@brickies>
	<CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com>
	<9B6E2A8877C38245BFB15CC491A11DA7281673@GRFEXC.intern.adiscon.com>
Message-ID: <alpine.DEB.2.02.1112201153350.4260@brickies>

On Tue, 20 Dec 2011, Rainer Gerhards wrote:

> Sorry, too much going on at the moment...
>
> I have now updated the bug tracker with a proposed patch and would appreciate
> feedback (for details so bug tracker).

I built and tested the fix and it "works for me".
It will hopefully get pulled into Ubuntu, merge request at
https://code.launchpad.net/~smoser/ubuntu/precise/rsyslog/lp905419

Thanks for the quick fix.
Scott

From pchacin at inteleye.com  Tue Dec 20 19:31:37 2011
From: pchacin at inteleye.com (Pablo Chacin)
Date: Tue, 20 Dec 2011 19:31:37 +0100
Subject: [rsyslog] Fwd: zeromq modules for rsyslog
In-Reply-To: <4EEF79AC.1030200@inteleye.com>
References: <4EEF2735.7080700@inteleye.com>
	<CAPi=7hPNB3DV82Mw6CnhFVmwhLeUidfJcAyj7bv-ch3BcJgafA@mail.gmail.com>
	<4EEF79AC.1030200@inteleye.com>
Message-ID: <4EF0D489.70702@inteleye.com>

So far, both modules seems to work well in version 6.3 with the patch I 
already commented.
I tested reading from a file, forwarding messages using omzeromq, 
reading those messages
using imzeromq and sending to another file.



On 12/19/2011 06:51 PM, Pablo Chacin wrote:
> Brian
>
> Thanks for the info. That getting started guide will be of great help.
> I'll spend some more time debugging the zeromq modules to see why
> they fail and will report this info back to you.
>
> I'll also see what Reiner said in the other message in the list about the
> changes in the configuration.
>
> I'll stay tuned waiting for news.
>
> Pablo
>
> On 12/19/2011 05:41 PM, Brian Knox wrote:
>> Pablo -
>>
>> I'm one of the maintainers of the rsyslog zeromq modules.  I wanted 
>> to drop
>> you a note to let you know, we have never built the modules against 
>> rsyslog
>> 6 (we are using 5.8.x).  We have plans to begin tests against rsyslog 6
>> early next year.
>>
>> I'm working on a "getting started" article with our plugins that 
>> should be
>> of use to people trying to use them that should be completed this week.
>> I'll drop a note on the mailing list when the article is up!
>>
>> Brian
>>
>> On Mon, Dec 19, 2011 at 6:59 AM, Pablo Chacin<pchacin at inteleye.com>  
>> wrote:
>>
>>> Hi all
>>>
>>> I already sent this message to the developers of the
>>> zeromq modules, but  I'll appreciate the comments from any
>>> one that has experience with this module.
>>>
>>> Pablo
>>>
>>> -------- Original Message --------
>>> Subject:        zeromq modules for rsyslog
>>> Date:   Fri, 16 Dec 2011 20:01:16 +0100
>>> From:   Pablo Chacin<pchacin at inteleye.com>
>>> To:     ken at bonsai.com
>>>
>>>
>>>
>>> Hi Ken
>>>
>>> I've been trying to make the zeromq modules for rsyslog but with no 
>>> luck.
>>> First, I tried with rsyslog 6.3.6 and had to tweak a little bit to make
>>> them
>>> compile (see the attached diff files). However, I can't make them work.
>>> I tried sending log records from a test program.
>>>
>>> Also, tried to use rsyslog to read records from a file (see zmq.log) ,
>>> sent it using omzeromq to imzeromq and the
>>> to a output file, but it didn't work (see attached config file).
>>>
>>> I'm not getting any error, but neither any signal of zeromq doing 
>>> anything.
>>>
>>> I'll appreciate if you could help me with this. For example, how to 
>>> debug
>>> the modules in rsyslog (I tried with gdb but couldn't find a way to 
>>> set a
>>> breakpoint at any of these modules)
>>>
>>> Thanks in advance
>>>
>>> Pablo
>>>
>>> -- 
>>> Pablo Chacin
>>> R&D Engineer
>>> Sensefields SL
>>> Tlf (+34) 93 418 05 85
>>> Baixada de Gomis 1,
>>> 08023 Barcelona (Spain)
>>> http://www.sensefields.com/
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>>
>>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>
>


-- 
Pablo Chacin
R&D Engineer
Sensefields SL
Tlf (+34) 93 418 05 85
Baixada de Gomis 1,
08023 Barcelona (Spain)
http://www.sensefields.com/



From david at lang.hm  Tue Dec 20 21:05:11 2011
From: david at lang.hm (david at lang.hm)
Date: Tue, 20 Dec 2011 12:05:11 -0800 (PST)
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112201151010.15498@asgard.lang.hm>

On Mon, 19 Dec 2011, Kaushal Shriyan wrote:

> On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan
> <kaushalshriyan at gmail.com>wrote:
>
>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>
>>>> Thanks for the quick reply, I have around 200 client hosts which pushes
>>>> syslog to a Remote Centralized Rsyslog server. Do i need to use
>>>> http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
>>>> setup only on Remote Centralized Rsyslog server.
>>> It can be setup just on the centralized server, assuming those messages
>>> you are interested in are actually being forwarded to that server.
>>>
>>>
>> Thanks Ryan and any further use cases or several examples regarding
>> $template (*Configuration Directives*) as mentioned in
>> http://rsyslog.com/doc/ommail.html
>>
>> Please suggest.
>>
>> Regards
>>
>> Kaushal
>>
>
> Hi,
>
> I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
> alerts using email-to-sms feature
> Basically i am interested in various conditions or strings which can be
> captured or trapped and post it to the user
>
> For example "if $msg contains 'hard disk fatal failure' then
> :ommail:;mailBody" as per that link
>
> so how would i know what strings i can expect if there is a hardware or
> software error in the syslog ?
> I mean typical error description for specific problem
>
> Please guide me

It's not clear what you are asking.

Are you asking what error messages could indicate hardware or software 
problems in your logs? if so, that is too large a list of errors for 
anyone to predict (in part it will depend on what software you are 
running)

or are you asking what log messages rsyslog produces if there are errors? 
(this is a smaller list, but still hard to define)

as a general statement, just about any log message could potentially 
indicate an error of some sort, you have to know the system to know what 
it means.

Alerting on every potentially bbad message does not work well in practice 
(too many messages have the potential to mean something bad)

rsyslog does have the ability to generate e-mails if you match something, 
but that's not really an efficient way to do alerting. You really need to 
do a lot more logic on the logs to decide if something is bad (a message 
may inddicate a problem only in combination with other mesages, only if it 
happens more than X times in Y minutes, only if some other message 
_doesn't_ show up within X minutes, etc)

the right answer to finding bad things in the logs is very complex and 
involves several tools. It's also something where there is no one True 
Answer (TM)

What I like to do is to send the logs to Simple Event Correlator (SEC) 
where I can program it to generate alerts on things that it sees.

Tofigure out what I need to alert on, I use the 'artificial ignorance' 
method. get all your logs for a day, do some simple filtering to replace 
IP addresses, pids, numbers, etc with placeholders and then run the logs 
through sort |uniq -c |sort -n and look at your most common logs for the 
time period.

for each log message type, decide which category it falls under

1. Something that you want to create a summary report on

   this could be a list of what sites accessed a webserver for example

2. Something that is not interesting

   but note that the number of times that something 'not interesting 
happened' could be interesting, especially if that count changes 
significantly

3. Something that you want to alert on (at least potentially)


update your reporting script to filter out the log messages that you have 
classified and repeat the process. you will find that you very quickly 
classify all the log messages that you have seen, and the report of these 
'unknown' messages starts getting rather small. have someone review these 
unknown messages each day to catch new things (which may involve creating 
a report or otherwise classifying the messages using the same logic)

David Lang


From david at lang.hm  Tue Dec 20 21:06:58 2011
From: david at lang.hm (david at lang.hm)
Date: Tue, 20 Dec 2011 12:06:58 -0800 (PST)
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-gyQspVt1UR0E52FjqPWzo26vsRJzSs_ivydULZzaFKg@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
	<CAD7Ssm-gyQspVt1UR0E52FjqPWzo26vsRJzSs_ivydULZzaFKg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112201205270.15498@asgard.lang.hm>

On Mon, 19 Dec 2011, Kaushal Shriyan wrote:

> On Mon, Dec 19, 2011 at 9:30 AM, Kaushal Shriyan
> <kaushalshriyan at gmail.com>wrote:
>
>>
>>
>> On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan <kaushalshriyan at gmail.com
>>> wrote:
>>
>>>
>>>
>>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>>
>>>>> Thanks for the quick reply, I have around 200 client hosts which pushes
>>>>> syslog to a Remote Centralized Rsyslog server. Do i need to use
>>>>> http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it
>>>> be
>>>>> setup only on Remote Centralized Rsyslog server.
>>>> It can be setup just on the centralized server, assuming those messages
>>>> you are interested in are actually being forwarded to that server.
>>>>
>>>>
>>> Thanks Ryan and any further use cases or several examples regarding
>>> $template (*Configuration Directives*) as mentioned in
>>> http://rsyslog.com/doc/ommail.html
>>>
>>> Please suggest.
>>>
>>> Regards
>>>
>>> Kaushal
>>>
>>
>> Hi,
>>
>> I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
>> alerts using email-to-sms feature
>> Basically i am interested in various conditions or strings which can be
>> captured or trapped and post it to the user
>>
>> For example "if $msg contains 'hard disk fatal failure' then
>> :ommail:;mailBody" as per that link
>>
>> so how would i know what strings i can expect if there is a hardware or
>> software error in the syslog ?
>> I mean typical error description for specific problem
>>
>> Please guide me
>>
>> Regards
>>
>> Kaushal
>>
>> Hi Again
>
> Also as per http://wiki.rsyslog.com/index.php/FailoverSyslogServer, the
> data is stored in /var/log/localbuffer on client hosts
> Once the  Centralized Primary or Secondary Server is up, will it push the
> data which was stored locally on client hosts in /var/log/localbuffer to
> the centralized server automatically ?

If you configure the clients to buffer things and send them when the 
server comes back up they will. Rsyslog provides the option to do lots of 
things, but the default configuration does not do this sort of fancy stuff 
(because there are too many ways that people may want to do things)

David LAng

From david at lang.hm  Tue Dec 20 21:16:16 2011
From: david at lang.hm (david at lang.hm)
Date: Tue, 20 Dec 2011 12:16:16 -0800 (PST)
Subject: [rsyslog] Rsyslog - RELP Issue - Configuration archiving
In-Reply-To: <4EF05F8F.7020206@smartjog.com>
References: <4EF05F8F.7020206@smartjog.com>
Message-ID: <alpine.DEB.2.02.1112201210570.15498@asgard.lang.hm>

On Tue, 20 Dec 2011, David Donchez wrote:

> Hi All,
>
> I'm experiencing Rsyslog 5.8.1 with RELP Module on a Debian Squeeze x64
> system.
>
> My architecture est running fine but i have some question about the RELP
> features.
>
> I will explains my setup :
>
> ServerA -> RELP -> Ingestor Server -> RELP -> 3  Remote Server.
>
> My issue is :
>
> If one of the 3 last remote server is crashed (e.g. full disk), All the
> chain is slow and the server begin to queue all syslog messages. Is
> there a way to continue to push to others servers?
> I have seen with strace that the ingestor seems to be locked on a select
> (Service unavailable from the remote server). It will be fine if rsyslog
> can push to all others server even if one is crashed

the simple answer is that you can do this, but you need to configure 
rsyslog use separate action queues for each server so that only the one 
queue gets stalled (and then you have to worry about what happens when 
that queue fills up)

What is the purpose of sending to the multiple servers? is there a way of 
dealing with the problem on the server side?

> Also i have another question about file archiving.
>
> (One of the 3 Remove server above is a archive server).
>
> I archive all logs in files.
>
> $omfileziplevel  9
> $template
> Service,"/mnt/space/%$YEAR%-%$MONTH%-%$DAY%/%programname%/%HOSTNAME%/TEST.log.gz"
>
> if $programname startswith 'TEST.' then ?Service
> & ~
>
>
> This setup work fine. But if a server is queuing for 3 days, then push
> his queue, all logs will go in the "CURRENT DAY" directory on this
> archive server ( Due to the template %$YEAR%-%$MONTH%-%$DAY%)
> Is there a way to archive the log in the directory corresponding to the
> generated date file ?
>
> I have look to the "timegenerated" variables but it seems to be a little
> bit complicated.

$YEAR $MINTH $DAY are the current time on the server as the log is being 
processed. you will need to work with the $timegenerated variables, and 
yes they are ugly, they are what is provided by the machine sending the 
log (or if that machine doesn't put a timestamp in it, by the first 
machine to receive and process the log) If you are lucky enough for all 
your machines to use the same format for their timestamps, then you should 
be able to use regex and field processing to extract the values you want 
from that field.

David Lang

From mike.forbes at koordinates.com  Tue Dec 20 21:37:56 2011
From: mike.forbes at koordinates.com (Mike Forbes)
Date: Wed, 21 Dec 2011 09:37:56 +1300
Subject: [rsyslog] regression in V5 Stable branch for messages
	withoutTIMESTAMP
In-Reply-To: <alpine.DEB.2.02.1112201153350.4260@brickies>
References: <alpine.DEB.2.02.1112191500360.4260@brickies>
	<CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com>
	<9B6E2A8877C38245BFB15CC491A11DA7281673@GRFEXC.intern.adiscon.com>
	<alpine.DEB.2.02.1112201153350.4260@brickies>
Message-ID: <CADWNQmKtS78DyxLzv8XW_L=Qez9rQxmOGHOORFLAOxRaaOPXQw@mail.gmail.com>

I can also confirm the fix works for me.

Cheers,


On Wed, Dec 21, 2011 at 5:53 AM, Scott Moser <smoser at ubuntu.com> wrote:
> On Tue, 20 Dec 2011, Rainer Gerhards wrote:
>
>> Sorry, too much going on at the moment...
>>
>> I have now updated the bug tracker with a proposed patch and would appreciate
>> feedback (for details so bug tracker).
>
> I built and tested the fix and it "works for me".
> It will hopefully get pulled into Ubuntu, merge request at
> https://code.launchpad.net/~smoser/ubuntu/precise/rsyslog/lp905419
>
> Thanks for the quick fix.
> Scott
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/



-- 
// Mike Forbes

Operations Engineer
Koordinates Ltd.

PO Box 1604, Shortland St, Auckland 1140, New Zealand

Cell +64-21-999416
Phone +64-9-966 0433
Fax +64-9-969 0045

Web http://koordinates.com/

GPG: BFC7 3F32 2CCF D91F 53E1 ?DF88 1578 B2E4 1399 6844

From kaushalshriyan at gmail.com  Wed Dec 21 00:45:43 2011
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Wed, 21 Dec 2011 05:15:43 +0530
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <alpine.DEB.2.02.1112201151010.15498@asgard.lang.hm>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
	<alpine.DEB.2.02.1112201151010.15498@asgard.lang.hm>
Message-ID: <CAD7Ssm-etScK+kDdRth-cUHfj6TehUiuEC-1=3+oH0H-BJCkrw@mail.gmail.com>

On Wed, Dec 21, 2011 at 1:35 AM, <david at lang.hm> wrote:

> On Mon, 19 Dec 2011, Kaushal Shriyan wrote:
>
>  On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan
>> <kaushalshriyan at gmail.com>**wrote:
>>
>>  On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <rpkelly22 at gmail.com> wrote:
>>>
>>>  Thanks for the quick reply, I have around 200 client hosts which pushes
>>>>> syslog to a Remote Centralized Rsyslog server. Do i need to use
>>>>> http://rsyslog.com/doc/ommail.**html<http://rsyslog.com/doc/ommail.html>on all 200 client hosts or can it be
>>>>> setup only on Remote Centralized Rsyslog server.
>>>>>
>>>> It can be setup just on the centralized server, assuming those messages
>>>> you are interested in are actually being forwarded to that server.
>>>>
>>>>
>>>>  Thanks Ryan and any further use cases or several examples regarding
>>> $template (*Configuration Directives*) as mentioned in
>>>
>>> http://rsyslog.com/doc/ommail.**html<http://rsyslog.com/doc/ommail.html>
>>>
>>> Please suggest.
>>>
>>> Regards
>>>
>>> Kaushal
>>>
>>>
>> Hi,
>>
>> I am referring to http://rsyslog.com/doc/ommail.**html<http://rsyslog.com/doc/ommail.html>to set email or sms
>> alerts using email-to-sms feature
>> Basically i am interested in various conditions or strings which can be
>> captured or trapped and post it to the user
>>
>> For example "if $msg contains 'hard disk fatal failure' then
>> :ommail:;mailBody" as per that link
>>
>> so how would i know what strings i can expect if there is a hardware or
>> software error in the syslog ?
>> I mean typical error description for specific problem
>>
>> Please guide me
>>
>
> It's not clear what you are asking.
>
> Are you asking what error messages could indicate hardware or software
> problems in your logs? if so, that is too large a list of errors for anyone
> to predict (in part it will depend on what software you are running)
>
> or are you asking what log messages rsyslog produces if there are errors?
> (this is a smaller list, but still hard to define)
>
> as a general statement, just about any log message could potentially
> indicate an error of some sort, you have to know the system to know what it
> means.
>
> Alerting on every potentially bbad message does not work well in practice
> (too many messages have the potential to mean something bad)
>
> rsyslog does have the ability to generate e-mails if you match something,
> but that's not really an efficient way to do alerting. You really need to
> do a lot more logic on the logs to decide if something is bad (a message
> may inddicate a problem only in combination with other mesages, only if it
> happens more than X times in Y minutes, only if some other message
> _doesn't_ show up within X minutes, etc)
>
> the right answer to finding bad things in the logs is very complex and
> involves several tools. It's also something where there is no one True
> Answer (TM)
>
> What I like to do is to send the logs to Simple Event Correlator (SEC)
> where I can program it to generate alerts on things that it sees.
>
> Tofigure out what I need to alert on, I use the 'artificial ignorance'
> method. get all your logs for a day, do some simple filtering to replace IP
> addresses, pids, numbers, etc with placeholders and then run the logs
> through sort |uniq -c |sort -n and look at your most common logs for the
> time period.
>
> for each log message type, decide which category it falls under
>
> 1. Something that you want to create a summary report on
>
>  this could be a list of what sites accessed a webserver for example
>
> 2. Something that is not interesting
>
>  but note that the number of times that something 'not interesting
> happened' could be interesting, especially if that count changes
> significantly
>
> 3. Something that you want to alert on (at least potentially)
>
>
> update your reporting script to filter out the log messages that you have
> classified and repeat the process. you will find that you very quickly
> classify all the log messages that you have seen, and the report of these
> 'unknown' messages starts getting rather small. have someone review these
> unknown messages each day to catch new things (which may involve creating a
> report or otherwise classifying the messages using the same logic)
>
> David Lang
>
>
> ______________________________**_________________
> rsyslog mailing list
> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
>

Hi David

I have gone through http://simple-evcorr.sourceforge.net/ and it is quite
interesting and there is also a learning process. At present I am using
rsyslog daemon as a centralized server and several rsyslog clients
connecting to it. Not sure i understand how sec is used in conjunction with
rsyslog daemon or are they separate applications.

Please help me understand.

Regards

Kaushal

From david at lang.hm  Wed Dec 21 02:39:37 2011
From: david at lang.hm (david at lang.hm)
Date: Tue, 20 Dec 2011 17:39:37 -0800 (PST)
Subject: [rsyslog] Trigger mechanism in Rsyslog
In-Reply-To: <CAD7Ssm-etScK+kDdRth-cUHfj6TehUiuEC-1=3+oH0H-BJCkrw@mail.gmail.com>
References: <CAD7Ssm_F0zaTb8XzF9Oq5Tqhr0pCTTBvDee8m5+CfQWOwyZvmA@mail.gmail.com>
	<20111218225139.GA30773@llserver.lakeliving.com>
	<CAD7Ssm-p=DCFV5JtfL5F+a9F5LK6Kr_2oeKfLOE4ABJRVcmjEQ@mail.gmail.com>
	<20111218232503.GB30773@llserver.lakeliving.com>
	<CAD7Ssm_HhdVCo-8WDv9BcN88CL2jU=dXcStv7y3Sf_httbrt5A@mail.gmail.com>
	<CAD7Ssm-vhnkz=bJj1zMM+eW5chZJKTFLq1V2Q_ODsurxe1En_A@mail.gmail.com>
	<alpine.DEB.2.02.1112201151010.15498@asgard.lang.hm>
	<CAD7Ssm-etScK+kDdRth-cUHfj6TehUiuEC-1=3+oH0H-BJCkrw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112201734590.15498@asgard.lang.hm>

On Wed, 21 Dec 2011, Kaushal Shriyan wrote:

> I have gone through http://simple-evcorr.sourceforge.net/ and it is quite
> interesting and there is also a learning process. At present I am using
> rsyslog daemon as a centralized server and several rsyslog clients
> connecting to it. Not sure i understand how sec is used in conjunction with
> rsyslog daemon or are they separate applications.
>
> Please help me understand.

one of the core Unix ideas is that instead of getting one monolithic 
program that does everything, you get a bunch of individual programs that 
each do one thing really well and you combine them to get the results that 
you want (which may not be the results that someone else wants, so they 
woul dcombine a slightly different set of tools)

rsyslog is great at transporting log messages (gathering them, 
transporting them, storing them) and includes some really neat 
functionality for dividing the logs. It's not designed to alert on logs.

SEC is designed to read it's input, compare the input to it's files and 
then take action based on the contents of the logs.

So rsyslog gathers the logs and writes them to SEC. you could do this with 
omprog in rsyslog to start SEC  and feed it the data via stdin, or you can 
make a named pipe on your filesystem and have rsyslog write to that 'file' 
and SEC read from that 'file' as it's input.

David Lang

From david.donchez at smartjog.com  Wed Dec 21 09:45:33 2011
From: david.donchez at smartjog.com (David Donchez)
Date: Wed, 21 Dec 2011 09:45:33 +0100
Subject: [rsyslog] Rsyslog - RELP Issue - Configuration archiving
In-Reply-To: <alpine.DEB.2.02.1112201210570.15498@asgard.lang.hm>
References: <4EF05F8F.7020206@smartjog.com>
	<alpine.DEB.2.02.1112201210570.15498@asgard.lang.hm>
Message-ID: <4EF19CAD.1020006@smartjog.com>

Thanks for your reply !

On 12/20/2011 09:16 PM, david at lang.hm wrote:
> On Tue, 20 Dec 2011, David Donchez wrote:
>
>> Hi All,
>>
>> I'm experiencing Rsyslog 5.8.1 with RELP Module on a Debian Squeeze x64
>> system.
>>
>> My architecture est running fine but i have some question about the RELP
>> features.
>>
>> I will explains my setup :
>>
>> ServerA -> RELP -> Ingestor Server -> RELP -> 3  Remote Server.
>>
>> My issue is :
>>
>> If one of the 3 last remote server is crashed (e.g. full disk), All the
>> chain is slow and the server begin to queue all syslog messages. Is
>> there a way to continue to push to others servers?
>> I have seen with strace that the ingestor seems to be locked on a select
>> (Service unavailable from the remote server). It will be fine if rsyslog
>> can push to all others server even if one is crashed
>
> the simple answer is that you can do this, but you need to configure
> rsyslog use separate action queues for each server so that only the
> one queue gets stalled (and then you have to worry about what happens
> when that queue fills up)
Hmm i think i already use 3 queues for the 3 destinations. I will
investigate on this way, but i can put my config :

##
## Global conf
##

$WorkDirectory /var/spool/rsyslog/archive
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_archive
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

if $fromhost-ip startswith '10.' and $programname startswith 'TEST.'
then  :omrelp:10.119.0.3:514;RSYSLOG_ForwardFormat
& ~

$WorkDirectory /var/spool/rsyslog/dispatcher
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_dispatcher
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

#if $fromhost-ip startswith '10.' and $programname startswith 'TEST.'
then  :omrelp:10.119.0.10:20514
#& ~

$WorkDirectory /var/spool/rsyslog/system
$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_system
$ActionQueueMaxDiskSpace 10g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on


if ( $fromhost-ip startswith '10.' and not ( $programname  startswith
'TEST.' )) then :omrelp:10.119.0.4:514;RSYSLOG_ForwardFormat
& ~


Please let me know if there is a mistake in this configuration.

>
> What is the purpose of sending to the multiple servers? is there a way
> of dealing with the problem on the server side?
In fact, i send the logs to 3 servers :
 - One which is the head of a parsing software to generate statistics
 - One which archives theses logs in a gzip format
 - One which only store system logs

>
>> Also i have another question about file archiving.
>>
>> (One of the 3 Remove server above is a archive server).
>>
>> I archive all logs in files.
>>
>> $omfileziplevel  9
>> $template
>> Service,"/mnt/space/%$YEAR%-%$MONTH%-%$DAY%/%programname%/%HOSTNAME%/TEST.log.gz"
>>
>>
>> if $programname startswith 'TEST.' then ?Service
>> & ~
>>
>>
>> This setup work fine. But if a server is queuing for 3 days, then push
>> his queue, all logs will go in the "CURRENT DAY" directory on this
>> archive server ( Due to the template %$YEAR%-%$MONTH%-%$DAY%)
>> Is there a way to archive the log in the directory corresponding to the
>> generated date file ?
>>
>> I have look to the "timegenerated" variables but it seems to be a little
>> bit complicated.
>
> $YEAR $MINTH $DAY are the current time on the server as the log is
> being processed. you will need to work with the $timegenerated
> variables, and yes they are ugly, they are what is provided by the
> machine sending the log (or if that machine doesn't put a timestamp in
> it, by the first machine to receive and process the log) If you are
> lucky enough for all your machines to use the same format for their
> timestamps, then you should be able to use regex and field processing
> to extract the values you want from that field.
Yes, finally, i have use this ugly method like :
%timereported:1:4:date-mysql%-%timereported:5:6:date-mysql%-%timereported:7:8:date-mysql% 
to have a generated date like YYYY-MM-DD
>
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>


From rgerhards at hq.adiscon.com  Wed Dec 21 14:50:14 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 21 Dec 2011 14:50:14 +0100
Subject: [rsyslog] regression in V5 Stable branch for
	messageswithoutTIMESTAMP
In-Reply-To: <CADWNQmKtS78DyxLzv8XW_L=Qez9rQxmOGHOORFLAOxRaaOPXQw@mail.gmail.com>
References: <alpine.DEB.2.02.1112191500360.4260@brickies><CADWNQm+F0ViWeWWXLGOQfMOO=XaZK0CyPpAoPpLBUf6bP9RW3g@mail.gmail.com><9B6E2A8877C38245BFB15CC491A11DA7281673@GRFEXC.intern.adiscon.com><alpine.DEB.2.02.1112201153350.4260@brickies>
	<CADWNQmKtS78DyxLzv8XW_L=Qez9rQxmOGHOORFLAOxRaaOPXQw@mail.gmail.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281680@GRFEXC.intern.adiscon.com>

Thanks everyone!

Rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Mike Forbes
> Sent: Tuesday, December 20, 2011 9:38 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] regression in V5 Stable branch for
> messageswithoutTIMESTAMP
> 
> I can also confirm the fix works for me.
> 
> Cheers,
> 
> 
> On Wed, Dec 21, 2011 at 5:53 AM, Scott Moser <smoser at ubuntu.com>
> wrote:
> > On Tue, 20 Dec 2011, Rainer Gerhards wrote:
> >
> >> Sorry, too much going on at the moment...
> >>
> >> I have now updated the bug tracker with a proposed patch and would
> >> appreciate feedback (for details so bug tracker).
> >
> > I built and tested the fix and it "works for me".
> > It will hopefully get pulled into Ubuntu, merge request at
> > https://code.launchpad.net/~smoser/ubuntu/precise/rsyslog/lp905419
> >
> > Thanks for the quick fix.
> > Scott
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> 
> 
> 
> --
> // Mike Forbes
> 
> Operations Engineer
> Koordinates Ltd.
> 
> PO Box 1604, Shortland St, Auckland 1140, New Zealand
> 
> Cell +64-21-999416
> Phone +64-9-966 0433
> Fax +64-9-969 0045
> 
> Web http://koordinates.com/
> 
> GPG: BFC7 3F32 2CCF D91F 53E1 ?DF88 1578 B2E4 1399 6844
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From rgerhards at hq.adiscon.com  Wed Dec 21 15:26:05 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 21 Dec 2011 15:26:05 +0100
Subject: [rsyslog] Problem with re-enabling a failed destination server?
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281687@GRFEXC.intern.adiscon.com>

Hi all,

I have a little time left before going on vacation and am looking to clean up
some things. I thought there was a bug mentioned where rsyslog does not
re-enable sending after a remote system was unresponsive. Unfortunately I
could not find a bug tracker and a quick mail search did also not bring up
anything. If someone has the problem, please let me know. It would probably
be good to open a bug tracker in that case. I can't promise I will look at it
before the xmas season, but I may ;)

Thanks,
Rainer

From pchacin at inteleye.com  Wed Dec 21 15:57:09 2011
From: pchacin at inteleye.com (Pablo Chacin)
Date: Wed, 21 Dec 2011 15:57:09 +0100
Subject: [rsyslog] Questions on rsyslog design
Message-ID: <4EF1F3C5.4040808@inteleye.com>

Hi Reiser

I have to mostly unrelated questions about the design of rsyslog.

First, I'm working in a custom parser for my application's messages.
Looking at the code of the prfc3164 module, I realized that the
internal message format used by rsyslog (msg_t)
has what it seams to me like redundant fields, which are not
in an union:
     char *pszTIMESTAMP3164;    /* TIMESTAMP as RFC3164 formatted string 
(always 15 charcters) */
     char *pszTIMESTAMP3339;    /* TIMESTAMP as RFC3339 formatted string 
(32 charcters at most) */
     char *pszTIMESTAMP_MySQL;/* TIMESTAMP as MySQL formatted string 
(always 14 charcters) */
     char *pszTIMESTAMP_PgSQL;/* TIMESTAMP as PgSQL formatted string 
(always 21 characters) *

Way are they needed? should the parser generate values for each of them?

Second, it is possible to change the configuration file's format? Is 
this configuration processor a
pluggable component? could it, in your opinion, be easily replaced (for 
what I've seen, other
components only need to subscribe to specific directives. they don't 
depend on the general
format of the file. I'm thinking in a xml based configuration with 
basically the same information
but a "nicer" syntax (a mater of taste). In our case, we don't expect to 
use all rsyslog modules.

Many thanks in advance.

Pablo

-- 
Pablo Chacin
R&D Engineer
Sensefields SL
Tlf (+34) 93 418 05 85
Baixada de Gomis 1,
08023 Barcelona (Spain)
http://www.sensefields.com/



From rgerhards at hq.adiscon.com  Wed Dec 21 16:04:05 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 21 Dec 2011 16:04:05 +0100
Subject: [rsyslog] Questions on rsyslog design
In-Reply-To: <4EF1F3C5.4040808@inteleye.com>
References: <4EF1F3C5.4040808@inteleye.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA728168C@GRFEXC.intern.adiscon.com>

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Pablo Chacin
> Sent: Wednesday, December 21, 2011 3:57 PM
> To: rsyslog-users
> Subject: [rsyslog] Questions on rsyslog design
> 
> Hi Reiser
> 
> I have to mostly unrelated questions about the design of rsyslog.
> 
> First, I'm working in a custom parser for my application's messages.
> Looking at the code of the prfc3164 module, I realized that the internal
> message format used by rsyslog (msg_t) has what it seams to me like
> redundant fields, which are not in an union:
>      char *pszTIMESTAMP3164;    /* TIMESTAMP as RFC3164 formatted string
> (always 15 charcters) */
>      char *pszTIMESTAMP3339;    /* TIMESTAMP as RFC3339 formatted string
> (32 charcters at most) */
>      char *pszTIMESTAMP_MySQL;/* TIMESTAMP as MySQL formatted string
> (always 14 charcters) */
>      char *pszTIMESTAMP_PgSQL;/* TIMESTAMP as PgSQL formatted string
> (always 21 characters) *
> 
> Way are they needed? 
They are buffers that prevent these formats to be generated multiple times.
When they are used, they are populated.

> should the parser generate values for each of them?
Definitely not :)

> Second, it is possible to change the configuration file's format? Is this
> configuration processor a pluggable component? could it, in your opinion,
be
> easily replaced (for what I've seen, other components only need to
subscribe
> to specific directives. they don't depend on the general format of the
file. I'm
> thinking in a xml based configuration with basically the same information
but
> a "nicer" syntax (a mater of taste). In our case, we don't expect to use
all
> rsyslog modules.

No - for details, search the mailing list archive and my blog. It's a long
story and has often been written about. Also be sure to read the top post on
the rsyslog site ;) The short story is that v6 has a different format.

Rainer
> 
> Many thanks in advance.
> 
> Pablo
> 
> --
> Pablo Chacin
> R&D Engineer
> Sensefields SL
> Tlf (+34) 93 418 05 85
> Baixada de Gomis 1,
> 08023 Barcelona (Spain)
> http://www.sensefields.com/
> 
> 
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From victor.lu at citi.com  Wed Dec 21 17:51:01 2011
From: victor.lu at citi.com (Lu, Victor )
Date: Wed, 21 Dec 2011 10:51:01 -0600
Subject: [rsyslog] TCP socket does not close
Message-ID: <35B12B7283BF44478AFA717323EE52951CF5D0AE26@extxmb32.nam.nsroot.net>

Hi All,

We found lots of rsyslog clients that had several ESTABLISHED port open with rsyslog collectors. They will not go away until client or collector restart the rsyslog process. Because of that  it quickly consume TCP socket resources on the collector side which made it not available to accept any new events.

Anybody experienced the same issue before?
Is there any parameter to specify to timeout the connection if it runs too long or a bug fix necessary to resolve the issue?

Thanks

Victor

From alexc223 at googlemail.com  Wed Dec 21 20:33:03 2011
From: alexc223 at googlemail.com (Alex Cartwright)
Date: Wed, 21 Dec 2011 19:33:03 +0000
Subject: [rsyslog] ommail condition stops other messages being logged
Message-ID: <CAJvURM+-Tt=yvH3U8At4LwGfFR4=cFEiR1oeRwTSegWDp_pW_w@mail.gmail.com>

Hello,

I am trying to configure ommail on Debian 6 so that it will send me
email notification if a message contains a certain string. I have got
it working using the following configuration below, however as a
side-effect it appears that all other messages that were once logged
to /var/log/syslog are no longer being logged.

For example, if I was to disable my ommail configuration and do
`logger foobar; grep foobar /var/log/syslog` it would appear. As soon
as I enable my ommail configuration and log a different message, it
simply does not get added to /var/log/syslog. Messages that *do* match
the condition do get emailed to my via ommail, however.

The following exists in /etc/rsyslog.d/email-ozwebapp.conf:

$ModLoad ommail

$ActionMailSMTPServer localhost
$ActionMailFrom foo at example.com
$ActionMailTo bar at example.com

$template mailSubject,"ozwebapp log event occured on %hostname%"
$template mailBody,"The following log event has occured with one of
our web applications::\r\n%msg%"

$ActionMailSubject mailSubject
# Only send an email out once in 10 minutes
$ActionExecOnlyOnceEveryInterval 600

if $msg contains 'cake' then :ommail:;mailBody


Kind regards,
Alex Cartwright

From rgerhards at hq.adiscon.com  Wed Dec 21 20:39:56 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Wed, 21 Dec 2011 20:39:56 +0100
Subject: [rsyslog] ommail condition stops other messages being logged
Message-ID: <009e01ccc017$f398e22d$100013ac@intern.adiscon.com>

I guess the onceinterval needs to be manually reset for the next action.

Rainer

Alex Cartwright <alexc223 at googlemail.com> hat geschrieben:Hello,

I am trying to configure ommail on Debian 6 so that it will send me
email notification if a message contains a certain string. I have got
it working using the following configuration below, however as a
side-effect it appears that all other messages that were once logged
to /var/log/syslog are no longer being logged.

For example, if I was to disable my ommail configuration and do
`logger foobar; grep foobar /var/log/syslog` it would appear. As soon
as I enable my ommail configuration and log a different message, it
simply does not get added to /var/log/syslog. Messages that *do* match
the condition do get emailed to my via ommail, however.

The following exists in /etc/rsyslog.d/email-ozwebapp.conf:

$ModLoad ommail

$ActionMailSMTPServer localhost
$ActionMailFrom foo at example.com
$ActionMailTo bar at example.com

$template mailSubject,"ozwebapp log event occured on %hostname%"
$template mailBody,"The following log event has occured with one of
our web applications::\r\n%msg%"

$ActionMailSubject mailSubject
# Only send an email out once in 10 minutes
$ActionExecOnlyOnceEveryInterval 600

if $msg contains 'cake' then :ommail:;mailBody


Kind regards,
Alex Cartwright
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/

From alexc223 at googlemail.com  Wed Dec 21 20:48:14 2011
From: alexc223 at googlemail.com (Alex Cartwright)
Date: Wed, 21 Dec 2011 19:48:14 +0000
Subject: [rsyslog] ommail condition stops other messages being logged
In-Reply-To: <009e01ccc017$f398e22d$100013ac@intern.adiscon.com>
References: <009e01ccc017$f398e22d$100013ac@intern.adiscon.com>
Message-ID: <CAJvURM+VfSLGHRx8mQ+hk4u-=DSNBVaSxwhjWqdeNhBKweh9rQ@mail.gmail.com>

Perfect, adding the following below the 'if' line works a treat :)

$ActionExecOnlyOnceEveryInterval 0

Thank you very much!

On 21 December 2011 19:39, Rainer Gerhards <rgerhards at hq.adiscon.com> wrote:
> I guess the onceinterval needs to be manually reset for the next action.
>
> Rainer
>
> Alex Cartwright <alexc223 at googlemail.com> hat geschrieben:Hello,
>
> I am trying to configure ommail on Debian 6 so that it will send me
> email notification if a message contains a certain string. I have got
> it working using the following configuration below, however as a
> side-effect it appears that all other messages that were once logged
> to /var/log/syslog are no longer being logged.
>
> For example, if I was to disable my ommail configuration and do
> `logger foobar; grep foobar /var/log/syslog` it would appear. As soon
> as I enable my ommail configuration and log a different message, it
> simply does not get added to /var/log/syslog. Messages that *do* match
> the condition do get emailed to my via ommail, however.
>
> The following exists in /etc/rsyslog.d/email-ozwebapp.conf:
>
> $ModLoad ommail
>
> $ActionMailSMTPServer localhost
> $ActionMailFrom foo at example.com
> $ActionMailTo bar at example.com
>
> $template mailSubject,"ozwebapp log event occured on %hostname%"
> $template mailBody,"The following log event has occured with one of
> our web applications::\r\n%msg%"
>
> $ActionMailSubject mailSubject
> # Only send an email out once in 10 minutes
> $ActionExecOnlyOnceEveryInterval 600
>
> if $msg contains 'cake' then :ommail:;mailBody
>
>
> Kind regards,
> Alex Cartwright
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From nathans at aconex.com  Wed Dec 21 22:44:39 2011
From: nathans at aconex.com (Nathan Scott)
Date: Thu, 22 Dec 2011 08:44:39 +1100 (EST)
Subject: [rsyslog] Problem with re-enabling a failed destination server?
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281687@GRFEXC.intern.adiscon.com>
Message-ID: <1489125458.29942.1324503878997.JavaMail.root@acxmail-au2.aconex.com>


----- Original Message -----
> 
> Hi all,
> 
> I have a little time left before going on vacation and am looking to
> clean up
> some things. I thought there was a bug mentioned where rsyslog does
> not
> re-enable sending after a remote system was unresponsive.
> Unfortunately I
> could not find a bug tracker and a quick mail search did also not
> bring up
> anything. If someone has the problem, please let me know. It would

You might be thinking of this one?
http://www.mail-archive.com/rsyslog at lists.adiscon.com/msg05773.html
We haven't seen a repeat of the problem since rolling out that patch.

cheers.

-- 
Nathan

From david at lang.hm  Thu Dec 22 05:56:50 2011
From: david at lang.hm (david at lang.hm)
Date: Wed, 21 Dec 2011 20:56:50 -0800 (PST)
Subject: [rsyslog] adaptation of /dev/log input
Message-ID: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>

how hard would it be to make an adaptation of the input module that 
controls /dev/log (imunixmux IIRC) so that you could have multiple 
listeners, with a facility and/or priority set for each one? (similar to 
how imfile works)

There's a discussion on the linux-kernel list about the android kernel 
based logger and how it is 'better' than syslog

ignoring speed and size issues for the moment, the only functional thing i 
can't figure out how to do is to have multiple /dev/log-type inputs and 
have them each be labled differently.

David Lang

From sean at conman.org  Thu Dec 22 06:44:06 2011
From: sean at conman.org (Sean Conner)
Date: Thu, 22 Dec 2011 00:44:06 -0500
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
Message-ID: <20111222054406.GA24475@brevard.conman.org>

It was thus said that the Great david at lang.hm once stated:
> how hard would it be to make an adaptation of the input module that 
> controls /dev/log (imunixmux IIRC) so that you could have multiple 
> listeners, with a facility and/or priority set for each one? (similar to 
> how imfile works)
> 
> There's a discussion on the linux-kernel list about the android kernel 
> based logger and how it is 'better' than syslog
> 
> ignoring speed and size issues for the moment, the only functional thing i 
> can't figure out how to do is to have multiple /dev/log-type inputs and 
> have them each be labled differently.

  A workaround (in case an adaptation of the input module can't be made) is
to have rsyslog log the various facilities/levels to multicast addresses. 
At home, my main logging system [1] forwards all the logs to 239.255.0.1 (a
multicast address)---that way, I can have multiple programs monitoring this
address [2].  For me, it wouldn't be hard to set up multiple multicast
addresses for various combinations of facility/level and have listeners
register for what they are interested in.

  Yes, it's UDP, and yes, it spams the local network with traffic, but it is
a work-around.

  -spc

[1]	A custom syslog daemon written in C/Lua, only UDP, but supports
	/dev/log, IPv4 and IPv6.

[2]	I have a custom "front-end" on each computer that listens on
	239.255.0.1 [3] and displays the entries in real time (my log volume
	isn't so great that I can't read the display), color coded by level
	(debug in blue, info in dark green, notice at light green, warning
	in yellow, err in red, etc.).  Makes for a neat screen saver.




From david at lang.hm  Thu Dec 22 07:43:33 2011
From: david at lang.hm (david at lang.hm)
Date: Wed, 21 Dec 2011 22:43:33 -0800 (PST)
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <20111222054406.GA24475@brevard.conman.org>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
	<20111222054406.GA24475@brevard.conman.org>
Message-ID: <alpine.DEB.2.02.1112212239260.28597@asgard.lang.hm>

On Thu, 22 Dec 2011, Sean Conner wrote:

> It was thus said that the Great david at lang.hm once stated:
>> how hard would it be to make an adaptation of the input module that
>> controls /dev/log (imunixmux IIRC) so that you could have multiple
>> listeners, with a facility and/or priority set for each one? (similar to
>> how imfile works)
>>
>> There's a discussion on the linux-kernel list about the android kernel
>> based logger and how it is 'better' than syslog
>>
>> ignoring speed and size issues for the moment, the only functional thing i
>> can't figure out how to do is to have multiple /dev/log-type inputs and
>> have them each be labled differently.
>
>  A workaround (in case an adaptation of the input module can't be made) is
> to have rsyslog log the various facilities/levels to multicast addresses.
> At home, my main logging system [1] forwards all the logs to 239.255.0.1 (a
> multicast address)---that way, I can have multiple programs monitoring this
> address [2].  For me, it wouldn't be hard to set up multiple multicast
> addresses for various combinations of facility/level and have listeners
> register for what they are interested in.
>
>  Yes, it's UDP, and yes, it spams the local network with traffic, but it is
> a work-around.

this doesn't solve what I'm looking for.

what I'm looking for is to have /dev/emer, /dev/info, etc  and a line 
written to /dev/info would be classified one way and /dev/ememr a 
different way (this example uses severity instead of facility, but i 
figure the mechanism that does one should be able to do both)

by the way, with your system, you may want to look at using multicast MAC 
instead of a multicast address. the multicast address can be run through 
routers, but it requires special software to deal with it, multicast MAC 
has an IP address just like everything else on your network, and with both 
you can have multiple machines listening to the traffic (with CLUSTERIP in 
iptables on linux and the similar function on BSD you can have a farm of 
machines split the traffic between them as well)

David Lang


>
>  -spc
>
> [1]	A custom syslog daemon written in C/Lua, only UDP, but supports
> 	/dev/log, IPv4 and IPv6.
>
> [2]	I have a custom "front-end" on each computer that listens on
> 	239.255.0.1 [3] and displays the entries in real time (my log volume
> 	isn't so great that I can't read the display), color coded by level
> 	(debug in blue, info in dark green, notice at light green, warning
> 	in yellow, err in red, etc.).  Makes for a neat screen saver.
>
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From sean at conman.org  Thu Dec 22 08:37:51 2011
From: sean at conman.org (Sean Conner)
Date: Thu, 22 Dec 2011 02:37:51 -0500
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <alpine.DEB.2.02.1112212239260.28597@asgard.lang.hm>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
	<20111222054406.GA24475@brevard.conman.org>
	<alpine.DEB.2.02.1112212239260.28597@asgard.lang.hm>
Message-ID: <20111222073748.GB24475@brevard.conman.org>

It was thus said that the Great david at lang.hm once stated:
> On Thu, 22 Dec 2011, Sean Conner wrote:
> 
> > A workaround (in case an adaptation of the input module can't be made) is
> >to have rsyslog log the various facilities/levels to multicast addresses.
> >At home, my main logging system [1] forwards all the logs to 239.255.0.1 (a
> >multicast address)---that way, I can have multiple programs monitoring this
> >address [2].  For me, it wouldn't be hard to set up multiple multicast
> >addresses for various combinations of facility/level and have listeners
> >register for what they are interested in.
> >
> > Yes, it's UDP, and yes, it spams the local network with traffic, but it is
> >a work-around.
> 
> this doesn't solve what I'm looking for.
> 
> what I'm looking for is to have /dev/emer, /dev/info, etc  and a line 
> written to /dev/info would be classified one way and /dev/ememr a 
> different way (this example uses severity instead of facility, but i 
> figure the mechanism that does one should be able to do both)

  Ah, now I get it.  [3]

> by the way, with your system, you may want to look at using multicast MAC 
> instead of a multicast address. the multicast address can be run through 
> routers, but it requires special software to deal with it, multicast MAC 
> has an IP address just like everything else on your network, and with both 
> you can have multiple machines listening to the traffic (with CLUSTERIP in 
> iptables on linux and the similar function on BSD you can have a farm of 
> machines split the traffic between them as well)

  I already have multiple machines listening in on the traffic, granted,
they're all on the same segment, but that's okay for my current setup.

  -spc (I should have noted my setup is at home, and not a work environment)

> >[1]	A custom syslog daemon written in C/Lua, only UDP, but supports
> >	/dev/log, IPv4 and IPv6.
> >
> >[2]	I have a custom "front-end" on each computer that listens on
> >	239.255.0.1 [3] and displays the entries in real time (my log volume
> >	isn't so great that I can't read the display), color coded by level
> >	(debug in blue, info in dark green, notice at light green, warning
> >	in yellow, err in red, etc.).  Makes for a neat screen saver.

[3]	It's interesting that very functionality you mentioned is actually
	doable with my custom syslog daemon [1]---you can specify multiple
	local Unix domain sockets, and do the whatever classification you
	want since the input location is part of the message as it's being
	processed via Lua. [4]

[4]	Not that I'm trying to sell my syslog daemon on the rsyslogd mailing
	list ...

From david at lang.hm  Thu Dec 22 09:00:08 2011
From: david at lang.hm (david at lang.hm)
Date: Thu, 22 Dec 2011 00:00:08 -0800 (PST)
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <20111222073748.GB24475@brevard.conman.org>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
	<20111222054406.GA24475@brevard.conman.org>
	<alpine.DEB.2.02.1112212239260.28597@asgard.lang.hm>
	<20111222073748.GB24475@brevard.conman.org>
Message-ID: <alpine.DEB.2.02.1112212358280.28597@asgard.lang.hm>

On Thu, 22 Dec 2011, Sean Conner wrote:

> It was thus said that the Great david at lang.hm once stated:
>> On Thu, 22 Dec 2011, Sean Conner wrote:
>>
>>> A workaround (in case an adaptation of the input module can't be made) is
>>> to have rsyslog log the various facilities/levels to multicast addresses.
>>> At home, my main logging system [1] forwards all the logs to 239.255.0.1 (a
>>> multicast address)---that way, I can have multiple programs monitoring this
>>> address [2].  For me, it wouldn't be hard to set up multiple multicast
>>> addresses for various combinations of facility/level and have listeners
>>> register for what they are interested in.
>>>
>>> Yes, it's UDP, and yes, it spams the local network with traffic, but it is
>>> a work-around.
>>
>> this doesn't solve what I'm looking for.
>>
>> what I'm looking for is to have /dev/emer, /dev/info, etc  and a line
>> written to /dev/info would be classified one way and /dev/ememr a
>> different way (this example uses severity instead of facility, but i
>> figure the mechanism that does one should be able to do both)
>
>  Ah, now I get it.  [3]
>
>> by the way, with your system, you may want to look at using multicast MAC
>> instead of a multicast address. the multicast address can be run through
>> routers, but it requires special software to deal with it, multicast MAC
>> has an IP address just like everything else on your network, and with both
>> you can have multiple machines listening to the traffic (with CLUSTERIP in
>> iptables on linux and the similar function on BSD you can have a farm of
>> machines split the traffic between them as well)
>
>  I already have multiple machines listening in on the traffic, granted,
> they're all on the same segment, but that's okay for my current setup.

I was meaning that you could have two machines listening, each processing 
half the messages.

>  -spc (I should have noted my setup is at home, and not a work environment)
>
>>> [1]	A custom syslog daemon written in C/Lua, only UDP, but supports
>>> 	/dev/log, IPv4 and IPv6.
>>>
>>> [2]	I have a custom "front-end" on each computer that listens on
>>> 	239.255.0.1 [3] and displays the entries in real time (my log volume
>>> 	isn't so great that I can't read the display), color coded by level
>>> 	(debug in blue, info in dark green, notice at light green, warning
>>> 	in yellow, err in red, etc.).  Makes for a neat screen saver.
>
> [3]	It's interesting that very functionality you mentioned is actually
> 	doable with my custom syslog daemon [1]---you can specify multiple
> 	local Unix domain sockets, and do the whatever classification you
> 	want since the input location is part of the message as it's being
> 	processed via Lua. [4]
>
> [4]	Not that I'm trying to sell my syslog daemon on the rsyslogd mailing
> 	list ...

thanks for the info, I'll be looking in to it.

David Lang

From rgerhards at hq.adiscon.com  Thu Dec 22 09:58:39 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 22 Dec 2011 09:58:39 +0100
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <20111222073748.GB24475@brevard.conman.org>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm><20111222054406.GA24475@brevard.conman.org><alpine.DEB.2.02.1112212239260.28597@asgard.lang.hm>
	<20111222073748.GB24475@brevard.conman.org>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281691@GRFEXC.intern.adiscon.com>

 
> [4]	Not that I'm trying to sell my syslog daemon on the rsyslogd
> mailing

It's interesting you mention that. Especially as it seems to do everything
far better than rsyslog ;)

Rainer

From rgerhards at hq.adiscon.com  Thu Dec 22 10:00:24 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Thu, 22 Dec 2011 10:00:24 +0100
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
References: <alpine.DEB.2.02.1112212052190.28597@asgard.lang.hm>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7281692@GRFEXC.intern.adiscon.com>

David,

I am not sure if I got you right, but I think 

$AddUnixListenSocket

Already does what you want. See the sample cases at

http://rsyslog.com/doc/imuxsock.html

Am I right?
Rainer

> -----Original Message-----
> From: david at lang.hm [mailto:david at lang.hm]
> Sent: Thursday, December 22, 2011 5:57 AM
> To: rsyslog-users; Rainer Gerhards
> Subject: adaptation of /dev/log input
> 
> how hard would it be to make an adaptation of the input module that
> controls /dev/log (imunixmux IIRC) so that you could have multiple
> listeners, with a facility and/or priority set for each one? (similar
> to
> how imfile works)
> 
> There's a discussion on the linux-kernel list about the android kernel
> based logger and how it is 'better' than syslog
> 
> ignoring speed and size issues for the moment, the only functional
> thing i
> can't figure out how to do is to have multiple /dev/log-type inputs and
> have them each be labled differently.
> 
> David Lang

From sean at conman.org  Thu Dec 22 17:32:10 2011
From: sean at conman.org (Sean Conner)
Date: Thu, 22 Dec 2011 11:32:10 -0500
Subject: [rsyslog] adaptation of /dev/log input
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281691@GRFEXC.intern.adiscon.com>
References: <20111222073748.GB24475@brevard.conman.org>
	<9B6E2A8877C38245BFB15CC491A11DA7281691@GRFEXC.intern.adiscon.com>
Message-ID: <20111222163209.GA25744@brevard.conman.org>

It was thus said that the Great Rainer Gerhards once stated:
>  
> > [4]	Not that I'm trying to sell my syslog daemon on the rsyslogd
> > mailing
> 
> It's interesting you mention that. Especially as it seems to do everything
> far better than rsyslog ;)

  Well, with the processing logic in Lua, I think rsyslog has a leg up on
speed (even if LuaJIT is used).  Also, it's a single-threaded program, so
again, it loses out on speed [1].  Also, the Lua code *is* the
configuration, so if you aren't keen on "programming" (and I think this is
why mine appears better), then rsyslog wins again.

  -spc (Not to mention the UDP only support of my syslogd ... )

[1]	Really, I think the single-threaded nature of the code is the sole
	reason why rsyslog will win out in pure speed (on a multicore
	system).  Even so, I am able to push around 30k messages/second on a
	2.4GHz Pentium core using Lua (*not* LuaJIT---I've yet to benchmark
	that), which, for a scripting language, I don't think is that bad.


From yingfeng.zhang at gmail.com  Fri Dec 23 11:22:40 2011
From: yingfeng.zhang at gmail.com (Yingfeng Zhang)
Date: Fri, 23 Dec 2011 18:22:40 +0800
Subject: [rsyslog] Question about imfile
Message-ID: <CAE0+06ng+GbJTMyy=tzD1wdoXNEFb4v1R0OTZOxeTE5t_3HEjA@mail.gmail.com>

Hi,

I am going to use imfile to provide a "tail -f" log file monitoring
utility. Here's my configuration:


$WorkDirectory /tmp/rsyslog/
$ModLoad imfile
$InputFileName /mypath//ll.log
$InputFileTag ruby
$InputFileStateFile stat-file1
$InputFileSeverity error
$InputFileFacility local1
$InputRunFileMonitor
$InputFilePollInterval 5

#I am going to send the tail of "ll.log" to zeromq
$ModLoad omzeromq.so # zeromq output
$local1.* :omzeromq:bind=tcp://*:5557

$local1.*                                                /var/log/boot.log


I found that whenever a new line is added to "ll.log",  imfile will outputs
the whole content to output modules, such as:
If the content of ll.log is:
aa
bb
cc
And ll.log is created from an empty file, and we add a new line gradually.


Then the outputs of imfile (through boot.log) would be:
aa

aa
bb

aa
bb
cc


As a result, it's not a "tail -f" utility at all.  Am I missed something ?
Thanks a lot~



-- 
Regards
Yingfeng

From rgerhards at hq.adiscon.com  Fri Dec 23 11:25:44 2011
From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Date: Fri, 23 Dec 2011 11:25:44 +0100
Subject: [rsyslog] Question about imfile
In-Reply-To: <CAE0+06ng+GbJTMyy=tzD1wdoXNEFb4v1R0OTZOxeTE5t_3HEjA@mail.gmail.com>
References: <CAE0+06ng+GbJTMyy=tzD1wdoXNEFb4v1R0OTZOxeTE5t_3HEjA@mail.gmail.com>
Message-ID: <9B6E2A8877C38245BFB15CC491A11DA72816A4@GRFEXC.intern.adiscon.com>

Probably too-old version.

rainer

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Yingfeng Zhang
> Sent: Friday, December 23, 2011 11:23 AM
> To: rsyslog at lists.adiscon.com
> Subject: [rsyslog] Question about imfile
> 
> Hi,
> 
> I am going to use imfile to provide a "tail -f" log file monitoring
> utility. Here's my configuration:
> 
> 
> $WorkDirectory /tmp/rsyslog/
> $ModLoad imfile
> $InputFileName /mypath//ll.log
> $InputFileTag ruby
> $InputFileStateFile stat-file1
> $InputFileSeverity error
> $InputFileFacility local1
> $InputRunFileMonitor
> $InputFilePollInterval 5
> 
> #I am going to send the tail of "ll.log" to zeromq
> $ModLoad omzeromq.so # zeromq output
> $local1.* :omzeromq:bind=tcp://*:5557
> 
> $local1.*
> /var/log/boot.log
> 
> 
> I found that whenever a new line is added to "ll.log",  imfile will
> outputs
> the whole content to output modules, such as:
> If the content of ll.log is:
> aa
> bb
> cc
> And ll.log is created from an empty file, and we add a new line
> gradually.
> 
> 
> Then the outputs of imfile (through boot.log) would be:
> aa
> 
> aa
> bb
> 
> aa
> bb
> cc
> 
> 
> As a result, it's not a "tail -f" utility at all.  Am I missed
> something ?
> Thanks a lot~
> 
> 
> 
> --
> Regards
> Yingfeng
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From yingfeng.zhang at gmail.com  Fri Dec 23 11:27:32 2011
From: yingfeng.zhang at gmail.com (Yingfeng Zhang)
Date: Fri, 23 Dec 2011 18:27:32 +0800
Subject: [rsyslog] Question about imfile
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA72816A4@GRFEXC.intern.adiscon.com>
References: <CAE0+06ng+GbJTMyy=tzD1wdoXNEFb4v1R0OTZOxeTE5t_3HEjA@mail.gmail.com>
	<9B6E2A8877C38245BFB15CC491A11DA72816A4@GRFEXC.intern.adiscon.com>
Message-ID: <CAE0+06nCfVXTZE=k0LdDT+d-ZkFsa8UfkFCoWfq9qczJbz_kmw@mail.gmail.com>

The version I used is 5.8.0 , is it too old?  Since it's the version that
could work with zeromq<https://github.com/aggregateknowledge/rsyslog-zeromq>

On Fri, Dec 23, 2011 at 6:25 PM, Rainer Gerhards
<rgerhards at hq.adiscon.com>wrote:

> Probably too-old version.
>
> rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Yingfeng Zhang
> > Sent: Friday, December 23, 2011 11:23 AM
> > To: rsyslog at lists.adiscon.com
> > Subject: [rsyslog] Question about imfile
> >
> > Hi,
> >
> > I am going to use imfile to provide a "tail -f" log file monitoring
> > utility. Here's my configuration:
> >
> >
> > $WorkDirectory /tmp/rsyslog/
> > $ModLoad imfile
> > $InputFileName /mypath//ll.log
> > $InputFileTag ruby
> > $InputFileStateFile stat-file1
> > $InputFileSeverity error
> > $InputFileFacility local1
> > $InputRunFileMonitor
> > $InputFilePollInterval 5
> >
> > #I am going to send the tail of "ll.log" to zeromq
> > $ModLoad omzeromq.so # zeromq output
> > $local1.* :omzeromq:bind=tcp://*:5557
> >
> > $local1.*
> > /var/log/boot.log
> >
> >
> > I found that whenever a new line is added to "ll.log",  imfile will
> > outputs
> > the whole content to output modules, such as:
> > If the content of ll.log is:
> > aa
> > bb
> > cc
> > And ll.log is created from an empty file, and we add a new line
> > gradually.
> >
> >
> > Then the outputs of imfile (through boot.log) would be:
> > aa
> >
> > aa
> > bb
> >
> > aa
> > bb
> > cc
> >
> >
> > As a result, it's not a "tail -f" utility at all.  Am I missed
> > something ?
> > Thanks a lot~
> >
> >
> >
> > --
> > Regards
> > Yingfeng
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>



-- 
Best
Yingfeng

From kaiwang.chen at gmail.com  Fri Dec 23 16:26:27 2011
From: kaiwang.chen at gmail.com (Kaiwang Chen)
Date: Fri, 23 Dec 2011 23:26:27 +0800
Subject: [rsyslog] rsyslog-5.8.6 log entry corruption
Message-ID: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>

Hi all,

I found rsyslogd occasionally produced corrupted log entries like

<6>1 2011-12-23T23:03:18.089938+08:00 db1 <D0>#001 D^kernel  - -
device eth0 entered promiscuous mode

I believe that problem appeared in earlier versions including 5.8.2.
Looks like corruption never occur before hostname field. Is it a
reported bug? Any clue?

rsyslogd 5.8.6, compiled with:
        FEATURE_REGEXP:                         Yes
        FEATURE_LARGEFILE:                      No
        GSSAPI Kerberos 5 support:              Yes
        FEATURE_DEBUG (debug build, slow code): No
        32bit Atomic operations supported:      Yes
        64bit Atomic operations supported:      Yes
        Runtime Instrumentation (slow code):    No

/etc/rsyslog.conf
$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
$ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format

$ModLoad imklog
$ModLoad imuxsock
$ModLoad impstats

$SystemLogSocketIgnoreMsgTimestamp  off
$SystemLogUsePIDFromSystem on

$PStatInterval 600
$PStatSeverity 7

$WorkDirectory /var/spool/rsyslog

$MainMsgQueueSaveOnShutdown on
$MainMsgQueueFileName mq
$MainMsgQueueMaxFileSize 5m

$ActionQueueType LinkedList
$ActionQueueSaveOnShutdown on
$ActionQueueFileName dbq
$ActionQueueMaxFileSize 10m
$ActionResumeRetryCount -1
*.*       @@(o)10.2.3.4


# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log


Thanks,
Kaiwang

From david at lang.hm  Sun Dec 25 00:32:00 2011
From: david at lang.hm (david at lang.hm)
Date: Sat, 24 Dec 2011 15:32:00 -0800 (PST)
Subject: [rsyslog] rsyslog-5.8.6 log entry corruption
In-Reply-To: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>
References: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1112241523440.17029@asgard.lang.hm>

On Fri, 23 Dec 2011, Kaiwang Chen wrote:

> Hi all,
>
> I found rsyslogd occasionally produced corrupted log entries like
>
> <6>1 2011-12-23T23:03:18.089938+08:00 db1 <D0>#001 D^kernel  - -
> device eth0 entered promiscuous mode
>
> I believe that problem appeared in earlier versions including 5.8.2.
> Looks like corruption never occur before hostname field. Is it a
> reported bug? Any clue?

the question is if this problem is in the raw message being sent to you, 
or is it something added by the rsyslog processing.

I would suggest adding something along the following line.

:rawmesg, :contains, "#001"  /var/log/badmessages:RSYSLOG_DEBUG

this will look for any messages with the hex 01 character in them and spit 
out all the info that you can use about the message in to the file 
/var/log/badmessages

run this for a little while and look to see what the raw message that is 
being received over the wire looks like. If it's bad, then you need to 
look at the sender. If the raw message looks sane, but rsyslog isn't 
handling it right, then we can troubleshoot from there.

David Lang

  > rsyslogd 5.8.6, compiled with:
>        FEATURE_REGEXP:                         Yes
>        FEATURE_LARGEFILE:                      No
>        GSSAPI Kerberos 5 support:              Yes
>        FEATURE_DEBUG (debug build, slow code): No
>        32bit Atomic operations supported:      Yes
>        64bit Atomic operations supported:      Yes
>        Runtime Instrumentation (slow code):    No
>
> /etc/rsyslog.conf
> $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
> $ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format
>
> $ModLoad imklog
> $ModLoad imuxsock
> $ModLoad impstats
>
> $SystemLogSocketIgnoreMsgTimestamp  off
> $SystemLogUsePIDFromSystem on
>
> $PStatInterval 600
> $PStatSeverity 7
>
> $WorkDirectory /var/spool/rsyslog
>
> $MainMsgQueueSaveOnShutdown on
> $MainMsgQueueFileName mq
> $MainMsgQueueMaxFileSize 5m
>
> $ActionQueueType LinkedList
> $ActionQueueSaveOnShutdown on
> $ActionQueueFileName dbq
> $ActionQueueMaxFileSize 10m
> $ActionResumeRetryCount -1
> *.*       @@(o)10.2.3.4
>
>
> # Log all kernel messages to the console.
> # Logging much else clutters up the screen.
> #kern.*                                                 /dev/console
>
> # Log anything (except mail) of level info or higher.
> # Don't log private authentication messages!
> *.info;mail.none;authpriv.none;cron.none                /var/log/messages
>
> # The authpriv file has restricted access.
> authpriv.*                                              /var/log/secure
>
> # Log all the mail messages in one place.
> mail.*                                                  -/var/log/maillog
>
>
> # Log cron stuff
> cron.*                                                  /var/log/cron
>
> # Everybody gets emergency messages
> *.emerg                                                 *
>
> # Save news errors of level crit and higher in a special file.
> uucp,news.crit                                          /var/log/spooler
>
> # Save boot messages also to boot.log
> local7.*                                                /var/log/boot.log
>
>
> Thanks,
> Kaiwang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
>

From kaiwang.chen at gmail.com  Tue Dec 27 12:50:25 2011
From: kaiwang.chen at gmail.com (Kaiwang Chen)
Date: Tue, 27 Dec 2011 19:50:25 +0800
Subject: [rsyslog] rsyslog-5.8.6 log entry corruption
In-Reply-To: <alpine.DEB.2.02.1112241523440.17029@asgard.lang.hm>
References: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>
	<alpine.DEB.2.02.1112241523440.17029@asgard.lang.hm>
Message-ID: <CAKSQQ5MEFyC36B17ip1RGGe2tNnaOsmpwj1iS1qKSmuPk-aLdw@mail.gmail.com>

2011/12/25  <david at lang.hm>:
> On Fri, 23 Dec 2011, Kaiwang Chen wrote:
>
>> Hi all,
>>
>> I found rsyslogd occasionally produced corrupted log entries like
>>
>> <6>1 2011-12-23T23:03:18.089938+08:00 db1 <D0>#001 D^kernel ?- -
>> device eth0 entered promiscuous mode
>>
>> I believe that problem appeared in earlier versions including 5.8.2.
>> Looks like corruption never occur before hostname field. Is it a
>> reported bug? Any clue?
>
>
> the question is if this problem is in the raw message being sent to you, or
> is it something added by the rsyslog processing.
>
> I would suggest adding something along the following line.
>
> :rawmesg, :contains, "#001" ?/var/log/badmessages:RSYSLOG_DEBUG
>
> this will look for any messages with the hex 01 character in them and spit
> out all the info that you can use about the message in to the file
> /var/log/badmessages
>
> run this for a little while and look to see what the raw message that is
> being received over the wire looks like. If it's bad, then you need to look
> at the sender. If the raw message looks sane, but rsyslog isn't handling it
> right, then we can troubleshoot from there.

Looks like it's related to tcp transmission. On the original server
that get input from unix socket, it is OK; while on the centeral log
server, the raw message is already corrupted.

===== on central log server
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - -  Connection from
UDP: [172.25.0.230]:53547
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - -  Received SNMP
packet(s) from UDP: [172.25.0.230]:53547
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 2#032#025<D5>1 - -
Connection from UDP: [172.25.0.230]:53547

Debug line with all properties:
FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
PROCID: '24254', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Connection from UDP: [172.25.0.230]:53547'
escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
24254 - -  Connection from UDP: [172.25.0.230]:53547'

Debug line with all properties:
FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
PROCID: '24254', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
24254 - -  Received SNMP packet(s) from UDP: [172.25.0.230]:53547'

Debug line with all properties:
FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[2#032#025<D5>1]', programname: 'snmpd', APP-NAME:
'snmpd', PROCID: '2#032#025<D5>1', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Connection from UDP: [172.25.0.230]:53547'
escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
2#032#025<D5>1 - -  Connection from UDP: [172.25.0.230]:53547'

===== on the orginal host  (*.*       @@(o)172.25.0.230:514)
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - -  Connection from
UDP: [172.25.0.230]:53547
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - -  Received SNMP
packet(s) from UDP: [172.25.0.230]:53547
<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - -  Connection from
UDP: [172.25.0.230]:53547

Debug line with all properties:
FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
PROCID: '24254', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Connection from UDP: [172.25.0.230]:53547'
escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
Connection from UDP: [172.25.0.230]:53547'

Debug line with all properties:
FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
PROCID: '24254', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
Received SNMP packet(s) from UDP: [172.25.0.230]:53547'

Debug line with all properties:
FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
PROCID: '24254', MSGID: '-',
TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
msg: ' Connection from UDP: [172.25.0.230]:53547'
escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
Connection from UDP: [172.25.0.230]:53547'


Thanks,
Kaiwang
>
> David Lang
>
> ?> rsyslogd 5.8.6, compiled with:
>>
>> ? ? ? FEATURE_REGEXP: ? ? ? ? ? ? ? ? ? ? ? ? Yes
>> ? ? ? FEATURE_LARGEFILE: ? ? ? ? ? ? ? ? ? ? ?No
>> ? ? ? GSSAPI Kerberos 5 support: ? ? ? ? ? ? ?Yes
>> ? ? ? FEATURE_DEBUG (debug build, slow code): No
>> ? ? ? 32bit Atomic operations supported: ? ? ?Yes
>> ? ? ? 64bit Atomic operations supported: ? ? ?Yes
>> ? ? ? Runtime Instrumentation (slow code): ? ?No
>>
>> /etc/rsyslog.conf
>> $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
>> $ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format
>>
>> $ModLoad imklog
>> $ModLoad imuxsock
>> $ModLoad impstats
>>
>> $SystemLogSocketIgnoreMsgTimestamp ?off
>> $SystemLogUsePIDFromSystem on
>>
>> $PStatInterval 600
>> $PStatSeverity 7
>>
>> $WorkDirectory /var/spool/rsyslog
>>
>> $MainMsgQueueSaveOnShutdown on
>> $MainMsgQueueFileName mq
>> $MainMsgQueueMaxFileSize 5m
>>
>> $ActionQueueType LinkedList
>> $ActionQueueSaveOnShutdown on
>> $ActionQueueFileName dbq
>> $ActionQueueMaxFileSize 10m
>> $ActionResumeRetryCount -1
>> *.* ? ? ? @@(o)10.2.3.4
>>
>>
>> # Log all kernel messages to the console.
>> # Logging much else clutters up the screen.
>> #kern.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /dev/console
>>
>> # Log anything (except mail) of level info or higher.
>> # Don't log private authentication messages!
>> *.info;mail.none;authpriv.none;cron.none ? ? ? ? ? ? ? ?/var/log/messages
>>
>> # The authpriv file has restricted access.
>> authpriv.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/secure
>>
>> # Log all the mail messages in one place.
>> mail.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-/var/log/maillog
>>
>>
>> # Log cron stuff
>> cron.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/cron
>>
>> # Everybody gets emergency messages
>> *.emerg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *
>>
>> # Save news errors of level crit and higher in a special file.
>> uucp,news.crit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/spooler
>>
>> # Save boot messages also to boot.log
>> local7.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/boot.log
>>
>>
>> Thanks,
>> Kaiwang
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/

From marcin at mejor.pl  Fri Dec 30 11:09:59 2011
From: marcin at mejor.pl (=?UTF-8?B?TWFyY2luIE1pcm9zxYJhdw==?=)
Date: Fri, 30 Dec 2011 11:09:59 +0100
Subject: [rsyslog] Problem with re-enabling a failed destination server?
In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7281687@GRFEXC.intern.adiscon.com>
References: <9B6E2A8877C38245BFB15CC491A11DA7281687@GRFEXC.intern.adiscon.com>
Message-ID: <4EFD8DF7.9050001@mejor.pl>

W dniu 21.12.2011 15:26, Rainer Gerhards pisze:
> Hi all,
> 
> I have a little time left before going on vacation and am looking to clean up
> some things. I thought there was a bug mentioned where rsyslog does not
> re-enable sending after a remote system was unresponsive. Unfortunately I
> could not find a bug tracker and a quick mail search did also not bring up
> anything. If someone has the problem, please let me know. It would probably
> be good to open a bug tracker in that case. I can't promise I will look at it
> before the xmas season, but I may ;)

Hello,
there is my proposal: http://bugzilla.adiscon.com/show_bug.cgi?id=299

I wish happy New Year for everyone!

From kaiwang.chen at gmail.com  Sat Dec 31 05:09:00 2011
From: kaiwang.chen at gmail.com (Kaiwang Chen)
Date: Sat, 31 Dec 2011 12:09:00 +0800
Subject: [rsyslog] rsyslog-5.8.6 log entry corruption
In-Reply-To: <CAKSQQ5MEFyC36B17ip1RGGe2tNnaOsmpwj1iS1qKSmuPk-aLdw@mail.gmail.com>
References: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>
	<alpine.DEB.2.02.1112241523440.17029@asgard.lang.hm>
	<CAKSQQ5MEFyC36B17ip1RGGe2tNnaOsmpwj1iS1qKSmuPk-aLdw@mail.gmail.com>
Message-ID: <CAKSQQ5O7EV5qrh7K1_HPODpagMRnFdB37u+X=aqxAcreYmczLA@mail.gmail.com>

Also spotted corrupted messages from imuxsock:

Debug line with all properties:
FROMHOST: 'squid9', fromhost-ip: '127.0.0.1', HOSTNAME: 'squid9', PRI: 47,
syslogtag 'rsyslogd-pstats:', programname: '<88>+?<99>2
<88>+?<99>rssyslogd-pstats', APP-NAME: '', PROCID: '', MSGID: '-',
TIMESTAMP: 'Dec 30 21:46:14', STRUCTURED-DATA: '-',
msg: 'imuxsock: submitted=429 ratelimit.discarded=0
ratelimit.numratelimiters=213 '
escaped msg: 'imuxsock: submitted=429 ratelimit.discarded=0
ratelimit.numratelimiters=213 '
inputname: impstats rawmsg: 'imuxsock: submitted=429
ratelimit.discarded=0 ratelimit.numratelimiters=213 '


Thanks,
Kaiwang

2011/12/27 Kaiwang Chen <kaiwang.chen at gmail.com>:
> 2011/12/25 ?<david at lang.hm>:
>> On Fri, 23 Dec 2011, Kaiwang Chen wrote:
>>
>>> Hi all,
>>>
>>> I found rsyslogd occasionally produced corrupted log entries like
>>>
>>> <6>1 2011-12-23T23:03:18.089938+08:00 db1 <D0>#001 D^kernel ?- -
>>> device eth0 entered promiscuous mode
>>>
>>> I believe that problem appeared in earlier versions including 5.8.2.
>>> Looks like corruption never occur before hostname field. Is it a
>>> reported bug? Any clue?
>>
>>
>> the question is if this problem is in the raw message being sent to you, or
>> is it something added by the rsyslog processing.
>>
>> I would suggest adding something along the following line.
>>
>> :rawmesg, :contains, "#001" ?/var/log/badmessages:RSYSLOG_DEBUG
>>
>> this will look for any messages with the hex 01 character in them and spit
>> out all the info that you can use about the message in to the file
>> /var/log/badmessages
>>
>> run this for a little while and look to see what the raw message that is
>> being received over the wire looks like. If it's bad, then you need to look
>> at the sender. If the raw message looks sane, but rsyslog isn't handling it
>> right, then we can troubleshoot from there.
>
> Looks like it's related to tcp transmission. On the original server
> that get input from unix socket, it is OK; while on the centeral log
> server, the raw message is already corrupted.
>
> ===== on central log server
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
> UDP: [172.25.0.230]:53547
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Received SNMP
> packet(s) from UDP: [172.25.0.230]:53547
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 2#032#025<D5>1 - -
> Connection from UDP: [172.25.0.230]:53547
>
> Debug line with all properties:
> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
> PROCID: '24254', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Connection from UDP: [172.25.0.230]:53547'
> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
> 24254 - - ?Connection from UDP: [172.25.0.230]:53547'
>
> Debug line with all properties:
> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
> PROCID: '24254', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
> escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
> 24254 - - ?Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>
> Debug line with all properties:
> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[2#032#025<D5>1]', programname: 'snmpd', APP-NAME:
> 'snmpd', PROCID: '2#032#025<D5>1', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Connection from UDP: [172.25.0.230]:53547'
> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
> 2#032#025<D5>1 - - ?Connection from UDP: [172.25.0.230]:53547'
>
> ===== on the orginal host ?(*.* ? ? ? @@(o)172.25.0.230:514)
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
> UDP: [172.25.0.230]:53547
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Received SNMP
> packet(s) from UDP: [172.25.0.230]:53547
> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
> UDP: [172.25.0.230]:53547
>
> Debug line with all properties:
> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
> PROCID: '24254', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Connection from UDP: [172.25.0.230]:53547'
> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
> Connection from UDP: [172.25.0.230]:53547'
>
> Debug line with all properties:
> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
> PROCID: '24254', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
> escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
> Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>
> Debug line with all properties:
> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
> PROCID: '24254', MSGID: '-',
> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
> msg: ' Connection from UDP: [172.25.0.230]:53547'
> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
> Connection from UDP: [172.25.0.230]:53547'
>
>
> Thanks,
> Kaiwang
>>
>> David Lang
>>
>> ?> rsyslogd 5.8.6, compiled with:
>>>
>>> ? ? ? FEATURE_REGEXP: ? ? ? ? ? ? ? ? ? ? ? ? Yes
>>> ? ? ? FEATURE_LARGEFILE: ? ? ? ? ? ? ? ? ? ? ?No
>>> ? ? ? GSSAPI Kerberos 5 support: ? ? ? ? ? ? ?Yes
>>> ? ? ? FEATURE_DEBUG (debug build, slow code): No
>>> ? ? ? 32bit Atomic operations supported: ? ? ?Yes
>>> ? ? ? 64bit Atomic operations supported: ? ? ?Yes
>>> ? ? ? Runtime Instrumentation (slow code): ? ?No
>>>
>>> /etc/rsyslog.conf
>>> $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
>>> $ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format
>>>
>>> $ModLoad imklog
>>> $ModLoad imuxsock
>>> $ModLoad impstats
>>>
>>> $SystemLogSocketIgnoreMsgTimestamp ?off
>>> $SystemLogUsePIDFromSystem on
>>>
>>> $PStatInterval 600
>>> $PStatSeverity 7
>>>
>>> $WorkDirectory /var/spool/rsyslog
>>>
>>> $MainMsgQueueSaveOnShutdown on
>>> $MainMsgQueueFileName mq
>>> $MainMsgQueueMaxFileSize 5m
>>>
>>> $ActionQueueType LinkedList
>>> $ActionQueueSaveOnShutdown on
>>> $ActionQueueFileName dbq
>>> $ActionQueueMaxFileSize 10m
>>> $ActionResumeRetryCount -1
>>> *.* ? ? ? @@(o)10.2.3.4
>>>
>>>
>>> # Log all kernel messages to the console.
>>> # Logging much else clutters up the screen.
>>> #kern.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /dev/console
>>>
>>> # Log anything (except mail) of level info or higher.
>>> # Don't log private authentication messages!
>>> *.info;mail.none;authpriv.none;cron.none ? ? ? ? ? ? ? ?/var/log/messages
>>>
>>> # The authpriv file has restricted access.
>>> authpriv.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/secure
>>>
>>> # Log all the mail messages in one place.
>>> mail.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-/var/log/maillog
>>>
>>>
>>> # Log cron stuff
>>> cron.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/cron
>>>
>>> # Everybody gets emergency messages
>>> *.emerg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *
>>>
>>> # Save news errors of level crit and higher in a special file.
>>> uucp,news.crit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/spooler
>>>
>>> # Save boot messages also to boot.log
>>> local7.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/boot.log
>>>
>>>
>>> Thanks,
>>> Kaiwang
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/

From kaiwang.chen at gmail.com  Sat Dec 31 15:07:10 2011
From: kaiwang.chen at gmail.com (Kaiwang Chen)
Date: Sat, 31 Dec 2011 22:07:10 +0800
Subject: [rsyslog] rsyslog-5.8.6 log entry corruption
In-Reply-To: <CAKSQQ5O7EV5qrh7K1_HPODpagMRnFdB37u+X=aqxAcreYmczLA@mail.gmail.com>
References: <CAKSQQ5N0h2Y5u4i3y7O5E_grf7CVinQvNtxUA9B1at8+FRU3sw@mail.gmail.com>
	<alpine.DEB.2.02.1112241523440.17029@asgard.lang.hm>
	<CAKSQQ5MEFyC36B17ip1RGGe2tNnaOsmpwj1iS1qKSmuPk-aLdw@mail.gmail.com>
	<CAKSQQ5O7EV5qrh7K1_HPODpagMRnFdB37u+X=aqxAcreYmczLA@mail.gmail.com>
Message-ID: <CAKSQQ5NB1y02rAXtViyq2jB7nLBDSWGL5_aodY9n-ymVFUmN0Q@mail.gmail.com>

Even worse case
<6>1 2011-12-31T12:04:05.036812+08:00 squid6 kernel  - - imklog 5.8.6,
log source = /proc/kmsg started.
...several SYN flooding entries in the same second...
*** glibc detected *** /sbin/rsyslogd: free(): invalid next size
(fast): 0x00007fafb8000e00 ***
*** glibc detected *** /sbin/rsyslogd: malloc(): memory corruption:
0x00007fafb8000e20 ***

 And possibly hours later the host was not responsive to ssh
connection requests, and even TTY login attempts failed...
Interestingly the debug log in another file continues a little beyond:

Debug line with all properties:
FROMHOST: 'squid6', fromhost-ip: '127.0.0.1', HOSTNAME: 'squid6', PRI: 47,
syslogtag 'rsyslogd-pstats:', programname: 'rsyslogd-pstats',
APP-NAME: 'rsyslogd-pstats', PROCID: '', MSGID: '-',
TIMESTAMP: 'Dec 31 12:24:05', STRUCTURED-DATA: '-',
msg: 'main Q[DA]: size=0 enqueued=0 full=0 maxqsize=0 '
escaped msg: 'main Q[DA]: size=0 enqueued=0 full=0 maxqsize=0 '
inputname: impstats rawmsg: 'main Q[DA]: size=0 enqueued=0 full=0 maxqsize=0 '

Debug line with all properties:
FROMHOST: 'squid6', fromhost-ip: '127.0.0.1', HOSTNAME: 'squid6', PRI: 47,
syslogtag 'rsyslogd-pstats:', programname: 'rsyslogd-pstats',
APP-NAME: 'rsyslogd-pstats', PROCID: '', MSGID: '-',
TIMESTAMP: 'Dec 31 12:24:05', STRUCTURED-DATA: '-',
msg: 'main Q: size=4 enqueued=30 full=0 maxqsize=5 '
escaped msg: 'main Q: size=4 enqueued=30 full=0 maxqsize=5 '
inputname: impstats rawmsg: 'main Q: size=4 enqueued=30 full=0 maxqsize=5 '

Fortunately the squid service on that host was not badly affected. So
I did graceful failover and reboot the host, everything became OK.
Although there was no direct timestamp associated, I guess the problem
occured soon after rsyslogd started. I also spotted several corrupted
messages on other hosts when rsyslogd started. They are same version:

# rsyslogd -v
rsyslogd 5.8.6, compiled with:
        FEATURE_REGEXP:                         Yes
        FEATURE_LARGEFILE:                      No
        GSSAPI Kerberos 5 support:              Yes
        FEATURE_DEBUG (debug build, slow code): No
        32bit Atomic operations supported:      Yes
        64bit Atomic operations supported:      Yes
        Runtime Instrumentation (slow code):    No


Thanks,
Kaiwang

2011/12/31 Kaiwang Chen <kaiwang.chen at gmail.com>:
> Also spotted corrupted messages from imuxsock:
>
> Debug line with all properties:
> FROMHOST: 'squid9', fromhost-ip: '127.0.0.1', HOSTNAME: 'squid9', PRI: 47,
> syslogtag 'rsyslogd-pstats:', programname: '<88>+?<99>2
> <88>+?<99>rssyslogd-pstats', APP-NAME: '', PROCID: '', MSGID: '-',
> TIMESTAMP: 'Dec 30 21:46:14', STRUCTURED-DATA: '-',
> msg: 'imuxsock: submitted=429 ratelimit.discarded=0
> ratelimit.numratelimiters=213 '
> escaped msg: 'imuxsock: submitted=429 ratelimit.discarded=0
> ratelimit.numratelimiters=213 '
> inputname: impstats rawmsg: 'imuxsock: submitted=429
> ratelimit.discarded=0 ratelimit.numratelimiters=213 '
>
>
> Thanks,
> Kaiwang
>
> 2011/12/27 Kaiwang Chen <kaiwang.chen at gmail.com>:
>> 2011/12/25 ?<david at lang.hm>:
>>> On Fri, 23 Dec 2011, Kaiwang Chen wrote:
>>>
>>>> Hi all,
>>>>
>>>> I found rsyslogd occasionally produced corrupted log entries like
>>>>
>>>> <6>1 2011-12-23T23:03:18.089938+08:00 db1 <D0>#001 D^kernel ?- -
>>>> device eth0 entered promiscuous mode
>>>>
>>>> I believe that problem appeared in earlier versions including 5.8.2.
>>>> Looks like corruption never occur before hostname field. Is it a
>>>> reported bug? Any clue?
>>>
>>>
>>> the question is if this problem is in the raw message being sent to you, or
>>> is it something added by the rsyslog processing.
>>>
>>> I would suggest adding something along the following line.
>>>
>>> :rawmesg, :contains, "#001" ?/var/log/badmessages:RSYSLOG_DEBUG
>>>
>>> this will look for any messages with the hex 01 character in them and spit
>>> out all the info that you can use about the message in to the file
>>> /var/log/badmessages
>>>
>>> run this for a little while and look to see what the raw message that is
>>> being received over the wire looks like. If it's bad, then you need to look
>>> at the sender. If the raw message looks sane, but rsyslog isn't handling it
>>> right, then we can troubleshoot from there.
>>
>> Looks like it's related to tcp transmission. On the original server
>> that get input from unix socket, it is OK; while on the centeral log
>> server, the raw message is already corrupted.
>>
>> ===== on central log server
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
>> UDP: [172.25.0.230]:53547
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Received SNMP
>> packet(s) from UDP: [172.25.0.230]:53547
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 2#032#025<D5>1 - -
>> Connection from UDP: [172.25.0.230]:53547
>>
>> Debug line with all properties:
>> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
>> PROCID: '24254', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Connection from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
>> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
>> 24254 - - ?Connection from UDP: [172.25.0.230]:53547'
>>
>> Debug line with all properties:
>> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[24254]', programname: 'snmpd', APP-NAME: 'snmpd',
>> PROCID: '24254', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
>> 24254 - - ?Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>>
>> Debug line with all properties:
>> FROMHOST: '172.25.0.71', fromhost-ip: '172.25.0.71', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[2#032#025<D5>1]', programname: 'snmpd', APP-NAME:
>> 'snmpd', PROCID: '2#032#025<D5>1', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Connection from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
>> inputname: imptcp rawmsg: '<30>1 2011-12-27T14:06:56+08:00 gw71 snmpd
>> 2#032#025<D5>1 - - ?Connection from UDP: [172.25.0.230]:53547'
>>
>> ===== on the orginal host ?(*.* ? ? ? @@(o)172.25.0.230:514)
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
>> UDP: [172.25.0.230]:53547
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Received SNMP
>> packet(s) from UDP: [172.25.0.230]:53547
>> <30>1 2011-12-27T14:06:56+08:00 gw71 snmpd 24254 - - ?Connection from
>> UDP: [172.25.0.230]:53547
>>
>> Debug line with all properties:
>> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
>> PROCID: '24254', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Connection from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
>> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
>> Connection from UDP: [172.25.0.230]:53547'
>>
>> Debug line with all properties:
>> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
>> PROCID: '24254', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
>> Received SNMP packet(s) from UDP: [172.25.0.230]:53547'
>>
>> Debug line with all properties:
>> FROMHOST: 'gw71', fromhost-ip: '127.0.0.1', HOSTNAME: 'gw71', PRI: 30,
>> syslogtag 'snmpd[24254]:', programname: 'snmpd', APP-NAME: 'snmpd',
>> PROCID: '24254', MSGID: '-',
>> TIMESTAMP: 'Dec 27 14:06:56', STRUCTURED-DATA: '-',
>> msg: ' Connection from UDP: [172.25.0.230]:53547'
>> escaped msg: ' Connection from UDP: [172.25.0.230]:53547'
>> inputname: imuxsock rawmsg: '<30>Dec 27 14:06:56 snmpd[24254]:
>> Connection from UDP: [172.25.0.230]:53547'
>>
>>
>> Thanks,
>> Kaiwang
>>>
>>> David Lang
>>>
>>> ?> rsyslogd 5.8.6, compiled with:
>>>>
>>>> ? ? ? FEATURE_REGEXP: ? ? ? ? ? ? ? ? ? ? ? ? Yes
>>>> ? ? ? FEATURE_LARGEFILE: ? ? ? ? ? ? ? ? ? ? ?No
>>>> ? ? ? GSSAPI Kerberos 5 support: ? ? ? ? ? ? ?Yes
>>>> ? ? ? FEATURE_DEBUG (debug build, slow code): No
>>>> ? ? ? 32bit Atomic operations supported: ? ? ?Yes
>>>> ? ? ? 64bit Atomic operations supported: ? ? ?Yes
>>>> ? ? ? Runtime Instrumentation (slow code): ? ?No
>>>>
>>>> /etc/rsyslog.conf
>>>> $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
>>>> $ActionForwardDefaultTemplate RSYSLOG_SyslogProtocol23Format
>>>>
>>>> $ModLoad imklog
>>>> $ModLoad imuxsock
>>>> $ModLoad impstats
>>>>
>>>> $SystemLogSocketIgnoreMsgTimestamp ?off
>>>> $SystemLogUsePIDFromSystem on
>>>>
>>>> $PStatInterval 600
>>>> $PStatSeverity 7
>>>>
>>>> $WorkDirectory /var/spool/rsyslog
>>>>
>>>> $MainMsgQueueSaveOnShutdown on
>>>> $MainMsgQueueFileName mq
>>>> $MainMsgQueueMaxFileSize 5m
>>>>
>>>> $ActionQueueType LinkedList
>>>> $ActionQueueSaveOnShutdown on
>>>> $ActionQueueFileName dbq
>>>> $ActionQueueMaxFileSize 10m
>>>> $ActionResumeRetryCount -1
>>>> *.* ? ? ? @@(o)10.2.3.4
>>>>
>>>>
>>>> # Log all kernel messages to the console.
>>>> # Logging much else clutters up the screen.
>>>> #kern.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /dev/console
>>>>
>>>> # Log anything (except mail) of level info or higher.
>>>> # Don't log private authentication messages!
>>>> *.info;mail.none;authpriv.none;cron.none ? ? ? ? ? ? ? ?/var/log/messages
>>>>
>>>> # The authpriv file has restricted access.
>>>> authpriv.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/secure
>>>>
>>>> # Log all the mail messages in one place.
>>>> mail.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-/var/log/maillog
>>>>
>>>>
>>>> # Log cron stuff
>>>> cron.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/cron
>>>>
>>>> # Everybody gets emergency messages
>>>> *.emerg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *
>>>>
>>>> # Save news errors of level crit and higher in a special file.
>>>> uucp,news.crit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/spooler
>>>>
>>>> # Save boot messages also to boot.log
>>>> local7.* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/var/log/boot.log
>>>>
>>>>
>>>> Thanks,
>>>> Kaiwang
>>>> _______________________________________________
>>>> rsyslog mailing list
>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>>> http://www.rsyslog.com/professional-services/
>>>>
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/