syslog-ng 3.5.1 - question about flags(final)...
Hello all, I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1. In 3.3.9, I use the following structure of imbedded log statements: ################################################################################ # Service ipsec # filter f_ipsec_pgm{program("IPSEC-*" type("glob")) or program("IKE-*" type("glob")) or program("CHARON-*" type("glob")) or program("charon-*" type("glob")); }; filter f_ipsec_lvl_01{level(warning..emerg)}; filter f_ipsec_lvl_02{level(info..emerg)}; log { source(s_local); filter(f_ipsec_pgm); log { filter(f_ipsec_lvl_01); destination(d_logID_11); }; log { filter(f_ipsec_lvl_02); rewrite(r_quote_newlines); destination(d_logID_13); }; flags(final); }; In this case log messages of the 'correct' program would further be filtered on their severity level. * Info level messages would only be sent to 'd_logID_13' * Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'. * Debug level messages would be discarded. Under 3.5.1, the 'filtering ' stops after it matches once: * Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'. * Info messages are still (correctly) being sent only to 'd_logID_13'. If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered :)) except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'. NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that. So, what would be the correct way to set up my log statement to re-create the 3.3 behavior? Thanks, Chris ---------------------------------------- Christopher Johnson chris.johnson3@hp.com<mailto:chris.johnson3@hp.com> HP Software - Security Product Group (916) 785-2817 ----------------------------------------
On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
################################################################################
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
This sounds like a bug to me. Although there's nothing related in the 3.5 tree, 3.4 had a great reorganization in the area. Let me check. -- Bazsi
Hi, This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first. If you don't hear from me in 2 days, feel free to ping me. Cheers, Bazsi On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
################################################################################
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
*ping* :) Chris -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, November 19, 2013 4:21 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)... Hi, This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first. If you don't hear from me in 2 days, feel free to ping me. Cheers, Bazsi On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
###################################################################### ##########
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
hi, thanks, moving this higher on my list. On Mon, 2013-11-25 at 22:36 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
*ping* :)
Chris
-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, November 19, 2013 4:21 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)...
Hi,
This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first.
If you don't hear from me in 2 days, feel free to ping me.
Cheers, Bazsi
On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
###################################################################### ##########
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hi, A fix and test is available on this branch: https://github.com/balabit/syslog-ng/tree/3.5/f/cfg-tree-final-fix I'd really appreciate any further testing and whether the 3.4/3.5 behaviour is consistent with 3.3. Algernon should pick these patches to the stable branches shortly, here's the pull request for that: https://github.com/balabit/syslog-ng/pull/26 Thanks for the report. Bazsi On Wed, 2013-11-27 at 11:22 +0100, Balazs Scheidler wrote:
hi,
thanks, moving this higher on my list.
On Mon, 2013-11-25 at 22:36 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
*ping* :)
Chris
-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, November 19, 2013 4:21 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)...
Hi,
This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first.
If you don't hear from me in 2 days, feel free to ping me.
Cheers, Bazsi
On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
###################################################################### ##########
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hi, Any news if these fix the issue for you? On Dec 1, 2013 1:19 PM, "Balazs Scheidler" <bazsi@balabit.hu> wrote:
Hi,
A fix and test is available on this branch:
https://github.com/balabit/syslog-ng/tree/3.5/f/cfg-tree-final-fix
I'd really appreciate any further testing and whether the 3.4/3.5 behaviour is consistent with 3.3.
Algernon should pick these patches to the stable branches shortly, here's the pull request for that:
https://github.com/balabit/syslog-ng/pull/26
Thanks for the report. Bazsi
On Wed, 2013-11-27 at 11:22 +0100, Balazs Scheidler wrote:
hi,
thanks, moving this higher on my list.
On Mon, 2013-11-25 at 22:36 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
*ping* :)
Chris
-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto: syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, November 19, 2013 4:21 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)...
Hi,
This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first.
If you don't hear from me in 2 days, feel free to ping me.
Cheers, Bazsi
On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
######################################################################
##########
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
· Info level messages would only be sent to 'd_logID_13'
· Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
· Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
· Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
· Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Bazsi, Yes, it 'fixed' the issue with 'flags(final);' and embedded logs. Thanks! Chris From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, December 10, 2013 11:59 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)... Hi, Any news if these fix the issue for you? On Dec 1, 2013 1:19 PM, "Balazs Scheidler" <bazsi@balabit.hu<mailto:bazsi@balabit.hu>> wrote: Hi, A fix and test is available on this branch: https://github.com/balabit/syslog-ng/tree/3.5/f/cfg-tree-final-fix I'd really appreciate any further testing and whether the 3.4/3.5 behaviour is consistent with 3.3. Algernon should pick these patches to the stable branches shortly, here's the pull request for that: https://github.com/balabit/syslog-ng/pull/26 Thanks for the report. Bazsi On Wed, 2013-11-27 at 11:22 +0100, Balazs Scheidler wrote:
hi,
thanks, moving this higher on my list.
On Mon, 2013-11-25 at 22:36 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
*ping* :)
Chris
-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> [mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>] On Behalf Of Balazs Scheidler Sent: Tuesday, November 19, 2013 4:21 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 3.5.1 - question about flags(final)...
Hi,
This seems to be a bug. I'll have to put it aside for now, but I'll try to work on this ASAP. Just Evan also posted some details about a bug of his and I'd like to work on that first.
If you don't hear from me in 2 days, feel free to ping me.
Cheers, Bazsi
On Mon, 2013-11-18 at 22:02 +0000, Johnson, Chris (HP TippingPoint Roseville) wrote:
Hello all,
I'm in the process of upgrading from version 3.3.9 to 3.5.1 and have a question about how the 'flags(final);' is working in 3.5.1.
In 3.3.9, I use the following structure of imbedded log statements:
###################################################################### ##########
# Service ipsec
#
filter f_ipsec_pgm{program("IPSEC-*" type("glob"))
or program("IKE-*" type("glob"))
or program("CHARON-*" type("glob"))
or program("charon-*" type("glob"));
};
filter f_ipsec_lvl_01{level(warning..emerg)};
filter f_ipsec_lvl_02{level(info..emerg)};
log {
source(s_local);
filter(f_ipsec_pgm);
log {
filter(f_ipsec_lvl_01);
destination(d_logID_11);
};
log {
filter(f_ipsec_lvl_02);
rewrite(r_quote_newlines);
destination(d_logID_13);
};
flags(final);
};
In this case log messages of the 'correct' program would further be filtered on their severity level.
* Info level messages would only be sent to 'd_logID_13'
* Warning level messages (and above) would be sent to BOTH 'd_logID_11' and 'd_logID_13'.
* Debug level messages would be discarded.
Under 3.5.1, the 'filtering ' stops after it matches once:
* Warning messages (and above) are only sent to 'd_logID_11' and NOT 'd_logID_13'.
* Info messages are still (correctly) being sent only to 'd_logID_13'.
If I remove (or comment out) the 'flags(final);' statement, messages are filtered correctly (i.e. the way I *want* them to be filtered J)
except that they also are being processed by all the following log statements and are being caught in my final filter of 'program("*" type("glob"))'.
NOTE: yes, I know that I could use 'flags(fallback)' in my final filter, but that would still have every message processed by every log filter, and I would like to avoid that.
So, what would be the correct way to set up my log statement to re-create the 3.3 behavior?
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
participants (3)
-
Balazs Scheidler
-
Balazs Scheidler
-
Johnson, Chris (HP TippingPoint Roseville)