Hi
I have not been able to figure out yet why the firewall would cause me to
loose packets send by rsyslog. I thought I would write a summary for anyone
reading this thread later on.
In summary this is what I have done so far:
Client Config:
module(load="imuxsock") # provides support for local system logging (e.g.
via logger command)
module(load="imklog") # provides kernel logging support (previously done
by rklogd)
module(load="omrelp")
module(load="impstats" interval="10" severity="7")
if $syslogtag contains 'rsyslogd-pstats' then {
action(type="omfile" queue.type="linkedlist" queue.discardmark="980"
name="pstats" file="/var/log/pstats")
stop
}
#### GLOBAL DIRECTIVES ####
$IncludeConfig /etc/rsyslog.d/*.conf
#### RULES ####
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg :omusrmsg:*
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
action( type="omrelp"
name="logtoserver"
target="192.168.8.134"
port="514"
queue.size="500"
queue.type="LinkedList"
queue.spoolDirectory="/var/lib/rsyslog"
queue.filename="testforwardingqueue"
queue.lowwatermark="200"
queue.highwatermark="350"
queue.discardmark="500"
queue.maxfilesize="1g"
queue.saveonshutdown="on"
)
Server Config:
module(load="imuxsock") # provides support for local system logging (e.g.
via logger command)
module(load="imklog") # provides kernel logging support (previously done
by rklogd)
module(load="imrelp")
input(type="imrelp" port="514")
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg :omusrmsg:*
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
My test methodology is as follows:
1. Start firewall on rsyslog server
2. Run for loop: for i in $(seq 1 600); do logger -p error
"############### TESTING ########### SEQ005-${i}"; done
1. Change SEQ number as required
3. Stop firewall
4. Wait for logs to come across
5. Run grep SEQ### -c /var/log/messages on rsyslog server.
I am expecting to see a count of 600 when I do so but I get 249. I
consistently get 249 and if I change my queue sizes I get a bigger number
but also consistently the same value. So I loose messages but a predictable
amount.
If I do the same test but I disable the networking on the server then I get
all 600 messages or whatever amount I have send. So it seems that for some
strange reason firewalld causes me to loose messages but not quite sure
why. I have done a tcpdump but there is nothing there that particularly
jumps out at me.
Regards
On 15 July 2015 at 11:13, Gerhardus Geldenhuis <
[email protected]> wrote:
> I can't see any firwalld related issues. What is interesting is that
> running: systemctl stop rsyslog on the server seems to cause issues. I
> can't run systemctl start rsyslog and get an error:
> systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xn' for
> details.
>
> If I run: systemctl enable rsyslog I don't get the error any more but I
> then if I run systemctl stop rsyslog it does not stop... it becomes a
> vampire which I can't kill. I don't have any silver bullets.
>
> Regards
>
> On 15 July 2015 at 10:55, Gerhardus Geldenhuis <
> [email protected]> wrote:
>
>> Hmmmm,
>> There should not be... it is firewalld and I don't think it limits
>> connections. I can dig around a bit more to see if there is something else
>> that would do that or cause it to happen. It is suppose to be vanilla
>> firewalld...
>>
>> I will do another test where I shutdown rsyslog on the remote server and
>> see what happens.
>>
>> Regards
>>
>> On 15 July 2015 at 10:36, Rainer Gerhards <[email protected]>
>> wrote:
>>
>>> 2015-07-15 11:33 GMT+02:00 Gerhardus Geldenhuis
>>> <[email protected]>:
>>> > I have made a bit of progress...
>>> > 2015-07-14T19:53:26.374223+01:00 rclient rsyslogd-pstats: logtoserver
>>> > queue[DA]: origin=core.queue size=0 enqueued=15232 full=0
>>> discarded.full=0
>>> > discarded.nf=0 maxqsize=15232
>>> > 2015-07-14T19:53:26.374227+01:00 rclient rsyslogd-pstats: logtoserver
>>> > queue: origin=core.queue size=24642 enqueued=56608 full=0
>>> discarded.full=0
>>> > discarded.nf=0 maxqsize=35002
>>> >
>>> > Those lines show that the DA queue has a smaller max queue size of
>>> 15232.
>>> > If I subtract that from 40 000 I get 24 768 which is the exact amount
>>> of
>>> > messages that I get on the remote server. The max queue size value is
>>> thus
>>> > the number of messages that I seem to loose or not get on the remote
>>> server.
>>> >
>>> > I don't have a solution yet but I think that will give some guidance
>>> as to
>>> > where things are going wrong ( I suspect in my config and/or
>>> assumptions )
>>>
>>> Not a solution, but a thought: This looks like the remote end does not
>>> accept the additional connection the DA queue tries to make. I have
>>> seen similar effects during testing when running against nc, which
>>> only permits one connection. Something in the firewall that limits
>>> that?
>>>
>>> Rainer
>>> >
>>> > Regards
>>> >
>>> > On 15 July 2015 at 09:58, Gerhardus Geldenhuis <
>>> > [email protected]> wrote:
>>> >
>>> >> Hi
>>> >> I am attaching a pstats file here as requested.
>>> >>
>>> >> I configured pstats to log every 10 seconds and the queue that
>>> forwards to
>>> >> the remote host is called:
>>> >> action( type="omrelp"
>>> >> name="logtoserver"
>>> >> target="192.168.8.134"
>>> >> port="514"
>>> >> queue.size="50000"
>>> >> queue.type="LinkedList"
>>> >> queue.spoolDirectory="/var/lib/rsyslog"
>>> >> queue.filename="testforwardingqueue"
>>> >> queue.lowwatermark="20000"
>>> >> queue.highwatermark="35000"
>>> >> queue.discardmark="50000"
>>> >> queue.maxfilesize="1g"
>>> >> queue.saveonshutdown="on"
>>> >> # queue.fulldelaymark="2500"
>>> >> )
>>> >>
>>> >> My process were:
>>> >> Start firewall on remote server to block syslog
>>> >>
>>> >> Run script:
>>> >>
>>> >> #!/bin/bash
>>> >>
>>> >> echo '' > /var/log/pstats
>>> >>
>>> >> echo "" >> /var/log/pstats
>>> >> echo "BEGINING of TEST with SEQ-${1}" >> /var/log/pstats
>>> >> echo "" >> /var/log/pstats
>>> >>
>>> >> echo 'Starting log storm'
>>> >> for i in $(seq 1 40000); do logger -p error "############### TESTING
>>> >> ########### SEQ${1}-${i}"; done
>>> >>
>>> >> echo "" >> /var/log/pstats
>>> >> echo "END of TEST with SEQ-${1}" >> /var/log/pstats
>>> >> echo "" >> /var/log/pstats
>>> >>
>>> >> after having run the script, I then stopped the firewall and waited
>>> for
>>> >> the logs to flush. Some logs flushed and after I saw them appear in
>>> the
>>> >> remote server I stopped rsyslog on the client and took a copy of the
>>> pstats
>>> >> file.
>>> >>
>>> >> I am trawling through the pstats file now but hopefully you might have
>>> >> some useful tool that can make it easier on your side and if not
>>> experience
>>> >> will always reveal things quicker.
>>> >>
>>> >> Regards
>>> >>
>>> >> On 14 July 2015 at 17:12, Rainer Gerhards <[email protected]>
>>> >> wrote:
>>> >>
>>> >>> 2015-07-14 17:32 GMT+02:00 Gerhardus Geldenhuis
>>> >>> <[email protected]>:
>>> >>> > Thanks David,
>>> >>> > I configured RELP but it has not made a difference...
>>> >>> >
>>> >>> > More specifically if I turn on the firewall by
>>> >>> >
>>> >>> > 1. running: systemctl start firewalld on the master server
>>> >>> > 2. and then start generating 40 000 log entries on the client,
>>> and
>>> >>> wait
>>> >>> > for it to finish
>>> >>> > 3. run: systemctl stop firewalld
>>> >>> > 4. Wait for logs to come over
>>> >>> > 5. Count logs
>>> >>> >
>>> >>> > I still get 24767 messages instead of 40000.
>>> >>>
>>> >>> can you share the impstats data with us? We may get a better
>>> >>> understanding of what's going on based on it...
>>> >>>
>>> >>> Rainer
>>> >>> >
>>> >>> > If however I physically turn of the network on the master machine
>>> using
>>> >>> > VMWare, I do get 40 000 messages when I connect the network back
>>> again.
>>> >>> >
>>> >>> > So why is RELP handling it like this surely if it does not get any
>>> >>> response
>>> >>> > from the firewall for if the firewall sends it to a black hole
>>> then it
>>> >>> > should not mark messages as delivered. I am also willing to admit
>>> that
>>> >>> my
>>> >>> > testing methodology is flawed but then I would like to understand
>>> why
>>> >>> > exactly and at the moment I feel my testing methodology represents
>>> a
>>> >>> real
>>> >>> > world scenario which would make loosing logs a reality even if you
>>> use
>>> >>> RELP.
>>> >>> >
>>> >>> > Importantly I enable the firewall before starting the log test so
>>> it
>>> >>> should
>>> >>> > all be blocked from the very beginning.
>>> >>> >
>>> >>> > Regards
>>> >>> >
>>> >>> > On 14 July 2015 at 12:44, David Lang <[email protected]> wrote:
>>> >>> >
>>> >>> >> One issue you are probably running into is the fact that TCP is
>>> not
>>> >>> >> reliable enough. TCP is 'reliable' in that if a packet gets
>>> dropped it
>>> >>> will
>>> >>> >> detect and re-send it as part of the same connection, but there
>>> is a
>>> >>> >> problem when the connection is interrupted (as it is in your test
>>> by
>>> >>> the
>>> >>> >> firewall)
>>> >>> >>
>>> >>> >> When the sending rsyslog hands the message to the OS on the
>>> sending
>>> >>> >> system, it is told "yes, I have this and will deliver it" by the
>>> OS.
>>> >>> But if
>>> >>> >> the OS is unable to deliver it (because the network connection
>>> breaks),
>>> >>> >> there is no way for the OS to go back to the sending application
>>> and
>>> >>> say
>>> >>> >> "oops, I really can't get this through to the other end" so the
>>> >>> messages
>>> >>> >> are lost.
>>> >>> >>
>>> >>> >> This is what the RELP protocol was developed to fix. It does
>>> >>> application
>>> >>> >> level acks for the messages so that if the network is
>>> interrupted, it
>>> >>> knows
>>> >>> >> what messages didn't get through and will re-send them. switch to
>>> >>> >> omrelp/imrelp instead of omfwd/imtcp and you should avoid loosing
>>> any
>>> >>> >> messages
>>> >>> >>
>>> >>> >> If you make the firewall send resets rather than dropping
>>> packets, the
>>> >>> >> sending machine will detect the problem faster.
>>> >>> >>
>>> >>> >>
>>> >>> >> This would account for some messages being lost between the time
>>> that
>>> >>> you
>>> >>> >> ahve the firewall block the connection and the time that rsyslog
>>> >>> detects
>>> >>> >> this. But once rsyslog detects this and starts queueing messages,
>>> those
>>> >>> >> messages should be sent when rsyslog re-establishes the
>>> connection.
>>> >>> >>
>>> >>> >> enable impstats writing stats rapidly (say every 10 seconds or so
>>> for
>>> >>> >> testing)
>>> >>> >>
>>> >>> >> then block the connection and send a small number of messages
>>> until
>>> >>> >> rsyslog logs locally that it's unable to send and the queue for
>>> the
>>> >>> action
>>> >>> >> starts filling.
>>> >>> >>
>>> >>> >> then do your write of 40000 test messages
>>> >>> >>
>>> >>> >> then open the firewall and you should see all the messages get
>>> sent
>>> >>> once
>>> >>> >> rsyslog retries and notices that the connection is open again.
>>> >>> >>
>>> >>> >> David Lang
>>> >>> >>
>>> >>> >> On Tue, 14 Jul 2015, Gerhardus Geldenhuis wrote:
>>> >>> >>
>>> >>> >> Date: Tue, 14 Jul 2015 11:20:46 +0100
>>> >>> >>> From: Gerhardus Geldenhuis <[email protected]>
>>> >>> >>> Reply-To: rsyslog-users <[email protected]>
>>> >>> >>> To: rsyslog-users <[email protected]>
>>> >>> >>> Subject: Re: [rsyslog] Disk queue to flush after restart
>>> >>> >>>
>>> >>> >>> Hi,
>>> >>> >>> I don't seem to be making as much progress as I would hope for.
>>> I now
>>> >>> have
>>> >>> >>> the following client config:
>>> >>> >>> action( type="omfwd"
>>> >>> >>> target="192.168.8.134"
>>> >>> >>> port="514"
>>> >>> >>> protocol="tcp"
>>> >>> >>> queue.size="50000"
>>> >>> >>> queue.type="LinkedList"
>>> >>> >>> queue.spoolDirectory="/var/lib/rsyslog"
>>> >>> >>> queue.filename="testforwardingqueue"
>>> >>> >>> queue.lowwatermark="20000"
>>> >>> >>> queue.highwatermark="35000"
>>> >>> >>> queue.discardmark="50000"
>>> >>> >>> queue.maxfilesize="1g"
>>> >>> >>> queue.saveonshutdown="on"
>>> >>> >>> # queue.fulldelaymark="2500"
>>> >>> >>> )
>>> >>> >>>
>>> >>> >>> I have made the numbers smaller to be able to do testing that
>>> will
>>> >>> finish
>>> >>> >>> in a reasonable amount of time.
>>> >>> >>>
>>> >>> >>> My process is:
>>> >>> >>>
>>> >>> >>> 1. Start firewall on master server to block all access.
>>> >>> >>> 2. On client server start logging using: for i in $(seq 1
>>> 40000); do
>>> >>> >>> logger -p error "############### TESTING ###########
>>> SEQ001-${i}";
>>> >>> done
>>> >>> >>> 3. Wait for for loop to finish and check if all entries are
>>> >>> contained
>>> >>> >>> locally
>>> >>> >>> 4. watch 'ls -l /var/lib/rsyslog' to see if queue gets created.
>>> >>> >>> 5. Disable firewall on master
>>> >>> >>> 6. run logger -p error with one message to get logs going again
>>> >>> >>> 7. Wait for logs to arrive on master server
>>> >>> >>> 8. grep 'SEQ001' /var/log/messages -c
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> The problem I am getting is that the number of messages I
>>> receive on
>>> >>> the
>>> >>> >>> remote server does not correspond with what I get on the master
>>> >>> server.
>>> >>> >>> I only get 24768 messages on the master server.
>>> >>> >>>
>>> >>> >>> Is there anything else that I have missed out of the
>>> configuration? I
>>> >>> >>> can't
>>> >>> >>> see anything that would cause my messages to not arrive. The
>>> queue
>>> >>> file I
>>> >>> >>> specified grows in size but interestingly when I grep'ed it for
>>> >>> SEQ005 I
>>> >>> >>> only get 15232 matches. I did the grep after re-enabling the
>>> firewall.
>>> >>> >>>
>>> >>> >>> I thought that it might be because syslog thinks my messages are
>>> the
>>> >>> same
>>> >>> >>> and then marks them as duplicates. I then added:
>>> >>> >>> for i in $(seq 1 40000); do logger -p error "###############
>>> TESTING
>>> >>> >>> ########### SEQ005-${i}-$(openssl rand -base64 32)"; done
>>> >>> >>>
>>> >>> >>> to try and prevent that. However if the firewall is not enabled
>>> then
>>> >>> all
>>> >>> >>> 40k messages arrive on the master server.
>>> >>> >>>
>>> >>> >>> Any help would be appreciated.
>>> >>> >>>
>>> >>> >>> Regards
>>> >>> >>>
>>> >>> >>> On 13 July 2015 at 14:20, Rainer Gerhards <
>>> [email protected]>
>>> >>> >>> wrote:
>>> >>> >>>
>>> >>> >>> 2015-07-13 15:18 GMT+02:00 Gerhardus Geldenhuis
>>> >>> >>>> <[email protected]>:
>>> >>> >>>>
>>> >>> >>>>> Hi,
>>> >>> >>>>> Thanks for the replies. I think the bulk of my problem was
>>> mixing
>>> >>> old
>>> >>> >>>>> and
>>> >>> >>>>> new config and I much further along to get something working.
>>> I have
>>> >>> >>>>> discovered a few other niggles but will report back once I have
>>> >>> >>>>> something
>>> >>> >>>>> working properly. As far as pull requests go, I would really
>>> >>> consider
>>> >>> >>>>>
>>> >>> >>>> doing
>>> >>> >>>>
>>> >>> >>>>> so but as always time is a factor.
>>> >>> >>>>>
>>> >>> >>>>
>>> >>> >>>> yup - for everyone ;) And that is what it is like it currently
>>> is ;)
>>> >>> >>>>
>>> >>> >>>> It does bug me so much that I must just
>>> >>> >>>>> end up doing it for the documentation. I will give debug mode
>>> a go.
>>> >>> >>>>>
>>> >>> >>>>> Regards
>>> >>> >>>>>
>>> >>> >>>>> On 13 July 2015 at 13:17, Rainer Gerhards <
>>> [email protected]
>>> >>> >
>>> >>> >>>>>
>>> >>> >>>> wrote:
>>> >>> >>>>
>>> >>> >>>>>
>>> >>> >>>>> 2015-07-10 13:40 GMT+02:00 Gerhardus Geldenhuis
>>> >>> >>>>>> <[email protected]>:
>>> >>> >>>>>>
>>> >>> >>>>>>> Hi
>>> >>> >>>>>>> I am struggling a bit to get rsyslog to work as described.
>>> >>> >>>>>>>
>>> >>> >>>>>>> <rant>
>>> >>> >>>>>>> Firstly the documentation is a struggle. There is some
>>> reference
>>> >>> to
>>> >>> >>>>>>>
>>> >>> >>>>>> old
>>> >>> >>>>
>>> >>> >>>>> and
>>> >>> >>>>>>
>>> >>> >>>>>>> new style configuration but no clear differentiation between
>>> the
>>> >>> two.
>>> >>> >>>>>>>
>>> >>> >>>>>> What
>>> >>> >>>>>>
>>> >>> >>>>>>> makes it more confusing is that documents like
>>> >>> >>>>>>> http://www.rsyslog.com/doc/queues.html then refers to what
>>> looks
>>> >>> like
>>> >>> >>>>>>>
>>> >>> >>>>>> the
>>> >>> >>>>>>
>>> >>> >>>>>>> old style of config and none of the examples contains new
>>> syntax
>>> >>> >>>>>>>
>>> >>> >>>>>> examples.
>>> >>> >>>>>>
>>> >>> >>>>>>>
>>> >>> >>>>>>> There was also an expectation that the new rsyslog package
>>> would
>>> >>> >>>>>>>
>>> >>> >>>>>> install
>>> >>> >>>>
>>> >>> >>>>> a
>>> >>> >>>>>>
>>> >>> >>>>>>> new style config but that turned out to be not the case. I
>>> >>> deleted the
>>> >>> >>>>>>> config file and did a yum reinstall just to be sure.
>>> >>> >>>>>>> </rant>
>>> >>> >>>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> well, this is open source. Pull requests are always
>>> appreciated,
>>> >>> >>>>>> anything else happens as time permits ;)
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>>> OS: CentOS 7
>>> >>> >>>>>>> RSyslog:
>>> >>> >>>>>>> rsyslog-8.11.0-1.el7.x86_64
>>> >>> >>>>>>> rsyslog-relp-8.11.0-1.el7.x86_64
>>> >>> >>>>>>> rsyslog-gnutls-8.11.0-1.el7.x86_64
>>> >>> >>>>>>>
>>> >>> >>>>>>> So basically what I am trying to achieve is the following:
>>> >>> >>>>>>>
>>> >>> >>>>>>> - Log remotely to a rsyslog server
>>> >>> >>>>>>> - Turn off the remote server ( via firewall )
>>> >>> >>>>>>> - Have logs be cached locally and saved to disk
>>> >>> >>>>>>> - Restart client server
>>> >>> >>>>>>> - Turn remote server back on
>>> >>> >>>>>>> - See cached logs appear in the remote server
>>> >>> >>>>>>>
>>> >>> >>>>>>> It does not work...
>>> >>> >>>>>>>
>>> >>> >>>>>>> - So more specifically, if I turn the firewall off, log a
>>> few
>>> >>> >>>>>>>
>>> >>> >>>>>> messages
>>> >>> >>>>
>>> >>> >>>>> and turn it back on then the caching works and I get the
>>> >>> messages.
>>> >>> >>>>>>> - If however I restart the client server, the logs never
>>> make
>>> >>> it to
>>> >>> >>>>>>>
>>> >>> >>>>>> the
>>> >>> >>>>>>
>>> >>> >>>>>>> remote sever, I can see the logs in the cached file but it
>>> >>> does not
>>> >>> >>>>>>>
>>> >>> >>>>>> get
>>> >>> >>>>>>
>>> >>> >>>>>>> send to the remote server.
>>> >>> >>>>>>>
>>> >>> >>>>>>> My config on the client:
>>> >>> >>>>>>> #### MODULES ####
>>> >>> >>>>>>> module(load="imuxsock") # provides support for local system
>>> >>> logging
>>> >>> >>>>>>>
>>> >>> >>>>>> (e.g.
>>> >>> >>>>
>>> >>> >>>>> via logger command)
>>> >>> >>>>>>> module(load="imklog") # provides kernel logging support
>>> >>> (previously
>>> >>> >>>>>>>
>>> >>> >>>>>> done
>>> >>> >>>>>>
>>> >>> >>>>>>> by rklogd)
>>> >>> >>>>>>>
>>> >>> >>>>>>> #### GLOBAL DIRECTIVES ####
>>> >>> >>>>>>> $IncludeConfig /etc/rsyslog.d/*.conf
>>> >>> >>>>>>>
>>> >>> >>>>>>> #### RULES ####
>>> >>> >>>>>>>
>>> >>> >>>>>>> *.info;mail.none;authpriv.none;cron.none
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/messages
>>> >>> >>>>
>>> >>> >>>>> authpriv.*
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/secure
>>> >>> >>>>
>>> >>> >>>>> mail.*
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/maillog
>>> >>> >>>>
>>> >>> >>>>> cron.*
>>> >>> /var/log/cron
>>> >>> >>>>>>> *.emerg
>>> >>> :omusrmsg:*
>>> >>> >>>>>>> uucp,news.crit
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/spooler
>>> >>> >>>>
>>> >>> >>>>> local7.*
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/boot.log
>>> >>> >>>>
>>> >>> >>>>>
>>> >>> >>>>>>> # ### begin forwarding rule ###
>>> >>> >>>>>>> $WorkDirectory /var/lib/rsyslog # where to place spool files
>>> >>> >>>>>>> $MainMsgQueueFileName LocalCaching # unique name prefix for
>>> spool
>>> >>> >>>>>>>
>>> >>> >>>>>> files
>>> >>> >>>>
>>> >>> >>>>> $MainMsgQueueSaveOnShutdown on # save messages to disk on
>>> shutdown
>>> >>> >>>>>>> # $MainMsgQueueType LinkedList
>>> >>> >>>>>>> $MainMsgQueueType Disk
>>> >>> >>>>>>> $MainMsgResumeRetryCount -1 # infinite retries if host is
>>> down
>>> >>> >>>>>>>
>>> >>> >>>>>>> *.* @@192.168.8.253:514
>>> >>> >>>>>>>
>>> >>> >>>>>>> # ### end of the forwarding rule ###
>>> >>> >>>>>>>
>>> >>> >>>>>>> My config on the remote server:
>>> >>> >>>>>>> module(load="imuxsock") # provides support for local system
>>> >>> logging
>>> >>> >>>>>>>
>>> >>> >>>>>> (e.g.
>>> >>> >>>>
>>> >>> >>>>> via logger command)
>>> >>> >>>>>>> module(load="imklog") # provides kernel logging support
>>> >>> (previously
>>> >>> >>>>>>>
>>> >>> >>>>>> done
>>> >>> >>>>>>
>>> >>> >>>>>>> by rklogd)
>>> >>> >>>>>>> module(load="imtcp") # needs to be done just once
>>> >>> >>>>>>> input(type="imtcp" port="514")
>>> >>> >>>>>>> $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
>>> >>> >>>>>>> $IncludeConfig /etc/rsyslog.d/*.conf
>>> >>> >>>>>>> *.info;mail.none;authpriv.none;cron.none
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/messages
>>> >>> >>>>
>>> >>> >>>>> authpriv.*
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/secure
>>> >>> >>>>
>>> >>> >>>>> mail.*
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/maillog
>>> >>> >>>>
>>> >>> >>>>> cron.*
>>> >>> /var/log/cron
>>> >>> >>>>>>> *.emerg
>>> >>> :omusrmsg:*
>>> >>> >>>>>>> uucp,news.crit
>>> >>> >>>>>>>
>>> >>> >>>>>> /var/log/spooler
>>> >>> >>>>
>>> >>> >>>>> local7.*
>>> >>> >>>>>>>
>>> >>> >>>>>>> Any pointers would be appreciated. I am hoping I am missing
>>> >>> something
>>> >>> >>>>>>> obvious or misunderstanding what I am suppose to be doing.
>>> >>> >>>>>>>
>>> >>> >>>>>>>
>>> >>> >>>>>> You should run rsyslog in such a situation in debug mode.From
>>> the
>>> >>> >>>>>> debug log, we can see why it thinks it can't deliver to the
>>> remote
>>> >>> >>>>>> system (well, hopefully ;)).
>>> >>> >>>>>>
>>> >>> >>>>>> HTH
>>> >>> >>>>>> Rainer
>>> >>> >>>>>>
>>> >>> >>>>>> Regards
>>> >>> >>>>>>>
>>> >>> >>>>>>> --
>>> >>> >>>>>>> Gerhardus Geldenhuis
>>> >>> >>>>>>> _______________________________________________
>>> >>> >>>>>>> rsyslog mailing list
>>> >>> >>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> >>>>>>> http://www.rsyslog.com/professional-services/
>>> >>> >>>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> >>>>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED
>>> by a
>>> >>> >>>>>>>
>>> >>> >>>>>> myriad
>>> >>> >>>>
>>> >>> >>>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
>>> POST if
>>> >>> you
>>> >>> >>>>>> DON'T LIKE THAT.
>>> >>> >>>>>> _______________________________________________
>>> >>> >>>>>> rsyslog mailing list
>>> >>> >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> >>>>>> http://www.rsyslog.com/professional-services/
>>> >>> >>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> >>>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED
>>> by a
>>> >>> >>>>>> myriad
>>> >>> >>>>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
>>> POST if
>>> >>> you
>>> >>> >>>>>> DON'T LIKE THAT.
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>> --
>>> >>> >>>>> Gerhardus Geldenhuis
>>> >>> >>>>> _______________________________________________
>>> >>> >>>>> rsyslog mailing list
>>> >>> >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> >>>>> http://www.rsyslog.com/professional-services/
>>> >>> >>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> >>>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED
>>> by a
>>> >>> myriad
>>> >>> >>>>>
>>> >>> >>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST
>>> if
>>> >>> you
>>> >>> >>>> DON'T LIKE THAT.
>>> >>> >>>> _______________________________________________
>>> >>> >>>> rsyslog mailing list
>>> >>> >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> >>>> http://www.rsyslog.com/professional-services/
>>> >>> >>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> >>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by
>>> a
>>> >>> myriad
>>> >>> >>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST
>>> if
>>> >>> you
>>> >>> >>>> DON'T LIKE THAT.
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> _______________________________________________
>>> >>> >> rsyslog mailing list
>>> >>> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> >> http://www.rsyslog.com/professional-services/
>>> >>> >> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
>>> >>> myriad
>>> >>> >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST
>>> if you
>>> >>> >> DON'T LIKE THAT.
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Gerhardus Geldenhuis
>>> >>> > _______________________________________________
>>> >>> > rsyslog mailing list
>>> >>> > http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> > http://www.rsyslog.com/professional-services/
>>> >>> > What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
>>> >>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
>>> POST if
>>> >>> you DON'T LIKE THAT.
>>> >>> _______________________________________________
>>> >>> rsyslog mailing list
>>> >>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> >>> http://www.rsyslog.com/professional-services/
>>> >>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
>>> myriad
>>> >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if
>>> you
>>> >>> DON'T LIKE THAT.
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Gerhardus Geldenhuis
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Gerhardus Geldenhuis
>>> > _______________________________________________
>>> > rsyslog mailing list
>>> > http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> > http://www.rsyslog.com/professional-services/
>>> > What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
>>> myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if
>>> you DON'T LIKE THAT.
>>> _______________________________________________
>>> rsyslog mailing list
>>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
>>> DON'T LIKE THAT.
>>>
>>
>>
>>
>> --
>> Gerhardus Geldenhuis
>>
>
>
>
> --
> Gerhardus Geldenhuis
>
--
Gerhardus Geldenhuis
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
