- syslog-ng - lists.balabit.hu

3.2.4 to be released in the coming days
by Balazs Scheidler 04 May '11

04 May '11

Hi, Since the release of 3.2.3 spurred some activity around the 3.2.x branch again, I accumulated some changes that either fix build related issues and fixes for a bug or two. I'm going to prepare a release later today, or latest tomorrow, so if you have an 3.2.x related issue, it's best to speak up now, so that I can perhaps fix it before doing a release. Thanks, -- Bazsi

1 0

Integrating syslog-ng on Solaris 10
by Pramod Pillai 04 May '11

04 May '11

Hi On Solaris machine the legacy logging is done by SMF system-log. And there are many Solaris SMF which depends on system-log SMF. If I want to integrate syslog-ng to Solaris box , should I disable system-log SMF ? But disabling "system-log" will cause few legacy SMF to go down. I can't have system-log SMF and syslog-ng enabled at the same time since it would result in logging twice. Can any one suggest alternative approach for integrating syslog-ng to Solaris box. Regards Pramod

5 4

[list admin] discussion of patches
by Balazs Scheidler 03 May '11

03 May '11

Hi, I intend to make the development of syslog-ng even more transparent and this means that more and more patches and development related questions needs to be discussed. See for instance the last e-mail about linking options. The big question is whether these discussions should be moved to a separate list, or rather it should stay here. I don't have a definitive view, as I read both development and non-development discussions, but I guess there are others on this list, who couldn't care less about linking options, patches and whatnot. But even for a user, seeing what kind of features are development, might be useful information, even if the code itself is less interesting. For me, it is more convinient as it is now. The question is how you, the other list members think about it? Please share your thoughts. Thanks. -- Bazsi

6 5

Setting facility/priority in 2.1.4?
by Ray Van Dolson 03 May '11

03 May '11

[ Wasn't subscribed to the list -- apologies if this ends up getting posted twice. ] I have a source (a FIFO/pipe) which I am re-emitting to another syslog-ng server via TCP. How do I define what facility and priority the data from this source is transmitted with? What is the default (daemon.info?)? This is syslog-ng 2.1.4 (old I know). Thanks, Ray

2 2

Solaris 10 UDP overflows, message drops
by Mishou Michael 03 May '11

03 May '11

All, I've done a lot of reading, and I can't figure out what I can do to this config in order to fix the UDP drops due to udpInOverflows on netstat -s. Here are some statistics relating to the amount of traffic we receive via syslog-ng, it's pretty busy but in reading I'm finding that some folks are doing much more. These stats are based on a ~30 second window of traffic during peak times, but variance due to time is not so much in our environment. I used tcpdump with a bpf to capture only inbound udp/514, so this is what the interface is seeing in the way of syslog. Elapsed: 00:00:34 Packets: 200000 Avg. packets/sec: 5836.546 Avg. packet size: 303.182 bytes Bytes: 60636477 Avg. bytes/sec: 1769537.884 Avg. MBit/sec: 14.156 So, about 6k messages per second. Here are the drop numbers over a time sample (done right after a process restart, you can see the buffer takes a moment to fill up [64 MB so_rcvbuf]): # while true; do echo -en "$(date) :: "; netstat -s | grep udpInOverflows | head -n 1 | sed 's|.*=||'; sleep 10; done Fri Apr 15 14:12:46 GMT 2011 :: 472517477 Fri Apr 15 14:12:56 GMT 2011 :: 472517477 Fri Apr 15 14:13:06 GMT 2011 :: 472517477 Fri Apr 15 14:13:16 GMT 2011 :: 472517477 Fri Apr 15 14:13:26 GMT 2011 :: 472543152 Fri Apr 15 14:13:36 GMT 2011 :: 472592800 Fri Apr 15 14:13:46 GMT 2011 :: 472638848 Fri Apr 15 14:13:56 GMT 2011 :: 472684407 So that's about 5k overflows a second, which jives with our calculations, suggesting we're getting only ~10% of our messages logged to disk. I inherited a config with _very_ many filter statements, but have decided to cut all that out to see if my performance problems in the way of udp drops continue (they do). I've attached a sanitized config to this message, all the stuff here concerns this config running (even though I thought eliminating the filters would really help, it didn't). We're running Solaris 10 SPARC. The syslog-ng version is: # /usr/local/sbin/syslog-ng -V syslog-ng 3.1.2 Installer-Version: 3.1.2 Revision: ssh+git://bazsi@git.balabit//var/scm/git/syslog-ng/syslog-ng-ose--mainli ne--3.1#master#8bf13c304b6ab5fc1a372b49d55c78370efe14ca Compile-Date: Oct 25 2010 23:56:18 Enable-Threads: off Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-Sun-STREAMS: on Enable-Sun-Door: on Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: off Enable-SSL: on Enable-SQL: off Enable-Linux-Caps: off Enable-Pcre: on The following options are set for the OS: # ndd /dev/udp udp_max_buf 1073741824 # ndd /dev/udp udp_recv_hiwat 65536 Some options lines from the config based on what I've seen: * note the TCP stuff can be safely ignored, it's legacy from some testing but isn't currently seeing traffic * all 3 udp sources set with so_rcvbuf(67108864) (64 MB) options { # things I've changed/tweaked flush_lines(1000); flush_timeout(20); log_fifo_size (67108864); log_msg_size(8192); chain_hostnames(yes); # end my changes <snip> }; So I'm totally stumped. I can set the buffers with so_rcvbuf() to 1 GB, it still doesn't matter, they eventually fill up and I start losing packets. I'm hoping that someone can point me to some tweaks I can do to get the numbers of drops down or eliminated. Is it unreasonable to expect to be able to process this many messages per second via UDP? Maybe that's the problem. I might experiment some with default syslog to see if it can write this many messages without drops...this doesn't seem like an insane amount of traffic. But perhaps my expectations are unrealistic, that's what I'm hoping someone can tell me. Regards, --Mike

11 37

[PATCH] basicfuncs: Implement a few numeric template functions.
by Gergely Nagy 03 May '11

03 May '11

From: Gergely Nagy <algernon(a)madhouse-project.org> Implement addition, substraction, multiplication, division and modulus template functions: $(+ N M), $(- N M), $(* N M), $(/ N M) and $(% N M), respectively. All of them take two numeric arguments, and log an error, if they receive less or more, or in case the number cannot be fully parsed as a number. Signed-off-by: Gergely Nagy <algernon(a)madhouse-project.org> --- modules/basicfuncs/basic-funcs.c | 106 ++++++++++++++++++++++++++++++++++++- 1 files changed, 103 insertions(+), 3 deletions(-) diff --git a/modules/basicfuncs/basic-funcs.c b/modules/basicfuncs/basic-funcs.c index a03e221..2be4584 100644 --- a/modules/basicfuncs/basic-funcs.c +++ b/modules/basicfuncs/basic-funcs.c @@ -23,7 +23,7 @@ tf_echo(LogMessage *msg, gint argc, GString *argv[], GString *result) TEMPLATE_FUNCTION_SIMPLE(tf_echo); static gboolean -tf_substr_parse_int(const gchar *s, long *d) +tf_parse_int(const gchar *s, long *d) { gchar *endptr; glong val; @@ -42,6 +42,101 @@ tf_substr_parse_int(const gchar *s, long *d) return TRUE; } +static gboolean +tf_num_parse(gint argc, GString *argv[], + const gchar *func_name, glong *n, glong *m) +{ + if (argc != 2) + { + msg_error("Template function requires two arguments.", + evt_tag_str("function", func_name), NULL); + return FALSE; + } + + if (!tf_parse_int(argv[0]->str, n)) + { + msg_error("Parsing failed, template function's first argument is not a number", + evt_tag_str("function", func_name), + evt_tag_str("arg1", argv[0]->str), NULL); + return FALSE; + } + + if (!tf_parse_int(argv[1]->str, m)) + { + msg_error("Parsing failed, template function's first argument is not a number", + evt_tag_str("function", func_name), + evt_tag_str("arg1", argv[1]->str), NULL); + return FALSE; + } + + return TRUE; +} + +static void +tf_num_plus(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + glong n, m; + + if (!tf_num_parse(argc, argv, "+", &n, &m)) + return; + + g_string_append_printf(result, "%li", n + m); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_num_plus); + +static void +tf_num_minus(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + glong n, m; + + if (!tf_num_parse(argc, argv, "-", &n, &m)) + return; + + g_string_append_printf(result, "%li", n - m); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_num_minus); + +static void +tf_num_multi(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + glong n, m; + + if (!tf_num_parse(argc, argv, "*", &n, &m)) + return; + + g_string_append_printf(result, "%li", n * m); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_num_multi); + +static void +tf_num_div(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + glong n, m; + + if (!tf_num_parse(argc, argv, "/", &n, &m)) + return; + + g_string_append_printf(result, "%li", (glong)(n / m)); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_num_div); + +static void +tf_num_mod(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + glong n, m; + + if (!tf_num_parse(argc, argv, "%", &n, &m)) + return; + + g_string_append_printf(result, "%li", n % m); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_num_mod); + static void tf_substr(LogMessage *msg, gint argc, GString *argv[], GString *result) { @@ -64,14 +159,14 @@ tf_substr(LogMessage *msg, gint argc, GString *argv[], GString *result) return; /* get offset position from second argument */ - if (!tf_substr_parse_int(argv[1]->str, &start)) { + if (!tf_parse_int(argv[1]->str, &start)) { msg_error("$(substr) parsing failed, start could not be parsed", evt_tag_str("start", argv[1]->str), NULL); return; } /* if we were called with >2 arguments, third was desired length */ if (argc > 2) { - if (!tf_substr_parse_int(argv[2]->str, &len)) { + if (!tf_parse_int(argv[2]->str, &len)) { msg_error("$(substr) parsing failed, length could not be parsed", evt_tag_str("length", argv[2]->str), NULL); return; } @@ -282,6 +377,11 @@ static Plugin basicfuncs_plugins[] = TEMPLATE_FUNCTION_PLUGIN(tf_grep, "grep"), TEMPLATE_FUNCTION_PLUGIN(tf_if, "if"), TEMPLATE_FUNCTION_PLUGIN(tf_substr, "substr"), + TEMPLATE_FUNCTION_PLUGIN(tf_num_plus, "+"), + TEMPLATE_FUNCTION_PLUGIN(tf_num_minus, "-"), + TEMPLATE_FUNCTION_PLUGIN(tf_num_multi, "*"), + TEMPLATE_FUNCTION_PLUGIN(tf_num_div, "/"), + TEMPLATE_FUNCTION_PLUGIN(tf_num_mod, "%"), }; gboolean -- 1.7.2.5

2 5

[PATCH] loggen: Fix a possible division by zero.
by Gergely Nagy 03 May '11

03 May '11

In some cases where we could not send a single message, loggen tried to divide by zero shortly before printing the statistics at the end. This was trivially reproducible by using -R with a file that contained invalid syslog lines. Signed-off-by: Gergely Nagy <algernon(a)balabit.hu> --- tests/loggen/loggen.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/tests/loggen/loggen.c b/tests/loggen/loggen.c index bf5d111..c5399a7 100644 --- a/tests/loggen/loggen.c +++ b/tests/loggen/loggen.c @@ -467,7 +467,12 @@ gen_messages(send_data_t send_func, void *send_func_ud, int thread_id, FILE *rea printf("%d;%lu.%06lu;%.2lf;%lu\n", thread_id, (long) diff_tv.tv_sec, (long) diff_tv.tv_usec, (((double) (count - last_count) * USEC_PER_SEC) / diff_usec), count); if (readfrom) - raw_message_length = sum_linelen/count; + { + if (count) + raw_message_length = sum_linelen/count; + else + raw_message_length = 0; + } free(testsdata); return count; } -- 1.7.2.5

2 1

[new shared lib] libsyslog-ng-crypto.so
by Balazs Scheidler 03 May '11

03 May '11

Hi, I just wanted to give a heads-up for people doing development on syslog-ng code, that I've introduced libsyslog-ng-crypto.so in the core, which is to contain core code that depends on libssl. You probably know, that one of the driving factors for modularizing syslog-ng was to make the core of syslog-ng independent of OpenSSL, since that is not available during early boot on a number of systems. Anyhow, there's a lot of code, that should be shared between plugins, but would depend on OpenSSL. To resolve this problem, I've now created libsyslog-ng-crypto.so, installed into $prefix/lib/syslog-ng (e.g. a private lib, which lives in the same place as the plugins), which is now responsible for: - seeding the random number generator - TLS transport code (tlstransport.c, earlier in the afsocket module) - TLS context code (tlscontext.c, -"-) I guess some others may follow. Plugins that would use openssl, should _always_ link against libsyslog-ng-crypto.so, as the random number generator is seeded when this library is loaded. (of course not all platforms need explicit PRNG seeding, but some do). Now as I'm reviewing the patch again, it is quite dirty, contains some unrelated changes, so don't take it as an example, but now a lot of others have accumulated on top of it, so I don't want to rebase and change the history. This is the patch I'm talking about: Author: Balazs Scheidler <bazsi(a)balabit.hu> 2011-04-30 20:17:44 Committer: Balazs Scheidler <bazsi(a)balabit.hu> 2011-04-30 20:17:44 Parent: adff96aa401c8ef398a617c14daf7dc45f85cab7 (logreader: fixed parsing flags containing dashes or underscores) Child: 2b65655028da7cc216aa747d0bb206fe28b93955 (logwriter: initialize the queue_filled event earlier) Branches: master, remotes/origin/master Follows: v3.3.0alpha2 Precedes: libsyslog-ng-crypto.so: This patch introduces a new shared object where openssl dependent core goes The TLS code is sufficiently independent from the afsocket plugin, however currently they go in the afsocket module directory. This patch introduces a new shared object called libsyslog-ng-crypto.so, which contains TLS code, random number initialization and basically everything that would introduce an openssl dependency. Signed-off-by: Balazs Scheidler <bazsi(a)balabit.hu> -- Bazsi

1 0

rewrite problem
by Micah Anderson 03 May '11

03 May '11

Hi, I've been trying to use the rewrite functionality using 3.1.3, but I am having some problems: 1. when having a rewrite setup, I can denial of service syslog-ng :( if I do this: rewrite r_ip { subst("([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}", "\[REDACTED\]", value("MESSAGE"), type("pcre"), flags("global")); }; filter f_mail { facility(mail) and not facility(local1) and not program("^postfix/"); }; destination df_mail { file("/var/log/mail.log"); }; log { source(s_src); filter(f_mail); rewrite(r_ip); destination(df_mail); flags(final); }; and then I do: $ logger -p mail.info hi syslog-ng starts going crazy, it eats 100% of the CPU and the memory. If you are lucky, the OOM killer kicks in and stops it before your system goes down. I originally thought that this was due to a bad regexp I had, but the above regexp works fine for normal mail syslog messages. However, in the process of trying to make a better rewrite rule, I found that I've created ones where normal mail messages do this too. 2. \. doesn't match literal periods Using the above rewrite, one would expect that the regexp would match three times a number containing 1-3 digits, each time followed by a literal period. Then a number containing 1-3 digits. A basic, and not very complete IPv4 regexp, that would match something like: 192.168.25.1. In fact, it does match that IPv4 address, but it is also matching other things that do not have periods in them. For example: rewrite r_ip { subst("([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}", "\[REDACTED\]", value("MESSAGE"), type("pcre"), flags("global")); }; $ logger -i -p mail.info 'Apr 21 20:38:58 algae postfix/smtp[14817]: EB4A2168: to=<482092-subscribe(a)bugs.debian.org>, relay=192.168.164.34[192.168.164.34]:587, delay=2.9, delays=0.19/0.14/2/0.58, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6722214C119)' I would expect that the two IP addressesw in the above to be matched and replaced, but this is what happens: Apr 22 12:45:11 algae logger[6234]: Apr [REDACTED] algae postfix/smtp[14817]: EB4A2168: to=<482092-subscribe(a)bugs.debian.org>, relay=[REDACTED][[REDACTED]]:587, delay=2.9, delays=[REDACTED]/2/0.58, dsn=2.0.0, status=sent ([REDACTED] Ok: queued as [REDACTED]) Its matching the queue ID 'EB4A2168' and its also matching '6722214C119', neither of those have periods in them, and EB4A2168 is not 0-9, which is what :digit: should be matching. I tried to replace [[:digit:]] with \d, but that caused issue #1 to happen. micah --

3 7

differing linking options
by Balazs Scheidler 03 May '11

03 May '11

Hi, @Corinna: I'm ccing you because of a cygwin question at the end of this email. Thanks for answering it if you have time. While cherry-picking changes from your tree at git://git.balabit.hu/syslog-ng-team/syslog-ng-core-4.1.git I've noticed that you are changing linking command lines for modules, which would break mixed linking mode used by Linux distributions in their native packages. Since it's bad to differ on things like this, I've figured it might make sense to come to a solution that's good for both of us. This is the patch that adds the new libraries: commit 23ca7a66c5a612ee7135c2543d707c7e484571a1 Author: Tamas Pal <folti(a)balabit.hu> Date: Tue Mar 29 11:42:00 2011 +0200 [autoconfuse]: make system specific libafsocket symlink with the proper shlib extension. Added proper LIBS dependencies, to prevent linking error in case libtool fails to parse .la files properly And this is the hunk that is (for instance) problematic: -libafsocket_notls_la_LIBADD = ../../lib/libsyslog-ng.la $(LIBNET_LIBS) $(LIBWRAP_LIBS) +libafsocket_notls_la_LIBADD = ../../lib/libsyslog-ng.la $(LIBNET_LIBS) $(LIBWRAP_LIBS) $(GLIB_LIBS) $(EVTLOG_LIBS) $(IVYKIS_LIBS) The technical issue at hand is that glib, evtlog and ivykis can all be static libraries in mixed mode, which would result in their inclusion into each module shared object, causing trouble at runtime. (not to mention that the static libs are probably not compiled with -fPIC so they cannot be linked into .so files). I do have a problem with AIX linking with 3.2 now, which is probably the root cause that you've added these libraries into the Makefiles in the first place. AIX linker is quite restrictive on how symbols are reexported from the main executable, but I do remember I could successfully create a linking mode that worked on AIX and wasn't broken on Linux in mixed mode. Clearly adding the libraries to that command line unconditionally is not such a combination. Mixed mode doesn't need to be supported on AIX, (I wouldn't dare to try to support that with non-GNU linkers). I think the breakage is rooted by the addition of -no-undefined to the libtool command line, which causes the AIX linker to ignore symbols exported by the main executable. -no-undefined was added to catch errors on Cygwin, which doesn't allow to link DLLs with undefined symbols in them. The questions are: 1) Since last time we've checked that OSE 3.2 built on cygwin, which doesn't include those libs, I think the cygwin linker would accept symbols exported by the dependencies of libsyslog-ng.so. Is that right Corinna? 2) AIX seems to have worked without -no-undefined (I've just retried that with 3.2.3, and confirmed that works). 3) @syslog-ng-team: Are there any other reasons you've included the libs explicitly on those command lines? So I'm proposing to make -no-undefined conditional, and only include it on non-AIX versions, and skip the listing of libs provided by libsyslog-ng.so from LIBADD. What do you think? -- Bazsi

2 1