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