<div dir="ltr">Hi, <div><br></div><div>Thanks for the prompt reply. </div><div><br></div><div>I think I got what I needed. </div><div>The reason I am looking into buffering an flow control is so that the setup is resilient to maintenance reboots, for example. </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 9 May 2018 at 20:40 PÁSZTOR György <<a href="mailto:pasztor@linux.gyakg.u-szeged.hu">pasztor@linux.gyakg.u-szeged.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
"Delon Lee Di Lun" <<a href="mailto:lee.delon2005@gmail.com" target="_blank">lee.delon2005@gmail.com</a>> írta 2018-05-09 12:21-kor:<br>
> I understand that this is a syslog-ng mailling list but however, in my<br>
> setup I am testing. I have to use rsyslog for the client.<br>
> <br>
> Has anybody tried a client as rsyslog and the server as syslog-ng does the<br>
> flow-control still kick in? Assume transportation protocol is TCP.<br>
> <br>
> I want to see if anybody tried it before, or let me know its impossible<br>
> before i commit my time into testing the setup.<br>
<br>
Well, I don't have first hands experience with this setup. But based on my<br>
current knowledge: it should work.<br>
So if you set up proper flow control on the syslog-ng side for the tcp<br>
source, and you also setup a disk buffer on the sender rsyslog side, it<br>
should fulfill your expectations, and should not loose any log events.<br>
<br>
I didn't analyzed exceptional cases here, eg. when you have some kind of<br>
transparent "loadbalancer" between your rsyslog and syslog-ng, and if your<br>
rsyslog get the ack but syslog-ng didn't really received the data.<br>
It's just playing with thoughts. So I could imagine situations when all your<br>
intention aiming failsafe log transportation will let you down. But it<br>
needs a really f..d up network configuration! In this case, if you can not<br>
trust your network setup, I suggest using an extra ssl layer for mutualy<br>
check parties via certificates. syslog-ng can handle that natively:<br>
<a href="https://syslog-ng.com/documents/html/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/tls-mutualauth.html" rel="noreferrer" target="_blank">https://syslog-ng.com/documents/html/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/tls-mutualauth.html</a><br>
The last time I check this part of rsyslog, they suggested using an stunnel<br>
for that scenario. If it's still the case, then stunnel can be a weak point:<br>
when rsyslog thinks it handed over the data to stunnel, but if that<br>
"crashes" or restarts, then it will loose its own buffer.<br>
Honestly, I don't know if rsyslog has any improvment on that side.<br>
<br>
Cheers,<br>
Gyu<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div>