- syslog-ng - lists.balabit.hu

[Bug 215] New: syslog-ng v3 - tcp() does not support no-multi-line as docs reference.
by bugzilla＠bugzilla.balabit.com 13 Feb '13

13 Feb '13

https://bugzilla.balabit.com/show_bug.cgi?id=215 Summary: syslog-ng v3 - tcp() does not support no-multi-line as docs reference. Product: syslog-ng Version: 3.3.x Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: balabit(a)32ths.com Type of the Report: --- Estimated Hours: 0.0 So after doing some test cases, I've noticed that on no-multi-line is not stripping newlines on v3.3.7. I've not tested previous versions yet. Here is my syslog-ng config: source s_net_tcp { tcp(ip(0.0.0.0) port(514) flags(no-multi-line)); }; destination all { file("/var/log/all"); }; log { source(s_net_tcp); destination(all); flags(final); }; I've also attempted to do this with no-parse flags passed in to no avail. When using the udp() source, it works just fine. My test case: # cat blah line1 line2 line3 # cat blah | nc -r -n myhost 514 And on "myhost" Jan 2 12:25:16 192.2.0.1 line1 Jan 2 12:25:16 192.2.0.1 line2 Jan 2 12:25:16 192.2.0.1 line3 So I assume this has something to do with it: https://bugzilla.balabit.com/show_bug.cgi?id=74 Particularly about newlines being message terminators over tcp(), however, why do the docs even say tcp() supports the no-multi-line flag? Maybe there is a way to adjust the terminator if this is the case? I must admit, I was curious what syslog-ng would do if the message size exceeded the mtu of the network. With UDP, I assume the end of the packet is the end of the message so any messages large enough to span two udp packets would actually be two log entries. I assumed it would also be the case with TCP, even if it is stream based. So the potential problems I see are: 1. tcp() doesn't really support no-multi-line (bug) or 2. the docs should be updated to not say it supports no-multi-line (bug) or 3. I've overlooked the doc references or 4. I'm missing some option (terminator?) in order to get tcp() to work with no-multi-line. (env) Thanks as always, - Mike -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

Support for OpenBSD
by C. L. Martinez 12 Feb '13

12 Feb '13

Hi all, Is syslog-ng supported under openbsd (releses 5.x)?? Can I expect problems installing under OpenBSD?? Thanks.

2 2

Systemd troubles: incompatibility with journald ?
by Guillaume Rousse 08 Feb '13

08 Feb '13

Hello list. I'm unable to run syslog-ng, whatever the version (I tried 3.3.6 and 3.4.1), on a recent system using systemd (mageia cauldron 64 bits, systemd 195). As soon as I'm launching syslog-ng, systemd and systemd-journal cpu usages reach 80/95%, and systemd fill dmesg log with this kind of message: [ 5962.484250] systemd[1]: syslog-ng.service start request repeated too quickly, refusing to start I tried to disable journald, but i didn't suceed. I also found indication of using the journald socket ( /run/systemd/journal/syslog) instead of /dev/log in syslog-ng configuration, but it doesn't change much. Also, the fedora package for syslog-ng doesn't contains anything special, either in default configuration, or in systemd service unit (excepted a patch to force pid file location). So, I'm a bit lost here... There is a user bug report on this issue: https://bugs.mageia.org/show_bug.cgi?id=8944 -- BOFH excuse #223: The lines are all busy (busied out, that is -- why let them in to begin with?).

3 5

[Bug 214] New: Build / Install Issues on AIX
by bugzilla＠bugzilla.balabit.com 08 Feb '13

08 Feb '13

https://bugzilla.balabit.com/show_bug.cgi?id=214 Summary: Build / Install Issues on AIX Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: AIX Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: blentz(a)cswg.com Type of the Report: --- Estimated Hours: 0.0 More fun for the AIX platform; Using version 3.3.7, GNU Make and GCC 4.2.0 However lib/syslog-ng/libafsocket.so is installed it is installed in such a way that the dependency for libsyslog-ng-crypto.a cannot be found. Seems like some kind of libtool problem. $ ldd /opt/local/syslogng/lib/syslog-ng/libafsocket.so /opt/local/syslogng/lib/syslog-ng/libafsocket.so needs: Cannot find libsyslog-ng-crypto.a(libsyslog-ng-crypto.so) /opt/local/syslogng/lib/libssl.so /opt/local/syslogng/lib/libcrypto.so /opt/local/syslogng/lib/libglib-2.0.a(libglib-2.0.so.0) /opt/local/syslogng/lib/libevtlog.a(libevtlog.so.0) /opt/local/syslogng/lib/libsyslog-ng.a(libsyslog-ng-3.3.7.so) /usr/lib/libc.a(shr.o) /usr/lib/librtl.a(shr.o) /opt/local/syslogng/lib/libgcc_s.a(shr.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libiconv.a(shr4.o) /usr/lib/libpthread.a(shr_comm.o) /usr/lib/libpthread.a(shr_xpg5.o) /opt/local/syslogng/lib/libintl.a(libintl.so.8) /opt/local/syslogng/lib/libgmodule-2.0.a(libgmodule-2.0.so.0) /opt/local/syslogng/lib/libgthread-2.0.a(libgthread-2.0.so.0) /opt/local/syslogng/lib/libivykis.a(libivykis.so.0) /unix /usr/lib/libcrypt.a(shr.o) /usr/lib/libpthreads.a(shr_comm.o) /usr/lib/libthread.a(shr.o) Also, be aware that shared libraries on AIX use the .a suffix, not .so. Out of the box shared libraries are archived into .a files. $ ar tv /opt/local/syslogng/lib/syslog-ng/libafsocket.a rwxr-xr-x 0/0 572423 Dec 19 20:23 2012 libafsocket-tls.so The default "make install" process leaves nothing but *.a files in lib/syslog-ng and on startup the user is greeted with many errors about missing loadable modules. The RPM that Perzl makes gets around this by running ar -X32 -x'ing all of these .a files so the system is populated with both .a and .so versions of the files. ( cd ${RPM_BUILD_ROOT}%{_libdir} for f in *.a ; do /usr/bin/ar -X32 -x ${f} done cd ${RPM_BUILD_ROOT}%{_libdir}/%{name} for f in *.a ; do /usr/bin/ar -X32 -x ${f} done ) Can this be fixed? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 18

[Bug 121] New: After service syslog-ng reload, the first log don' t transfer to remote servicer via TLS
by bugzilla＠bugzilla.balabit.com 08 Feb '13

08 Feb '13

https://bugzilla.balabit.com/show_bug.cgi?id=121 Summary: After service syslog-ng reload, the first log don't transfer to remote servicer via TLS Product: syslog-ng Version: 3.0.x Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: yong.zheng(a)nsn.com Type of the Report: bug Estimated Hours: 0.0 The version:syslog-ng 3.0.5 options { flush_lines (0); time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (yes); use_fqdn (no); create_dirs (no); keep_hostname (yes); stats_freq (3600); }; I will upload the logs to remote syslog-ng server via TLS, I encounter a issue, On client: after reload the configure via below command: #service syslog-ng reload. I write a log: #logger -p local1.info "this is test" but I don't see the log to transfer to server immediately, I wait many minutes, still don't see. I must write the second log to triger that client send the 2 logs to server #logger -p local1.info "this is test 2" the 2 logs have transfered to server immediately successfully, I can see the 2 logs on server. It is 100% reproduced. Is this a known issue, or not ? Thanks. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

sysutils/syslog-ng-devel is now 3.4.1
by Peter Czanik 08 Feb '13

08 Feb '13

Hello, Just a heads up: the FreeBSD sysutils/syslog-ng-devel is now updated to 3.4.1. I plan to update the sysutils/syslog-ng port from 3.3 to 3.4 once 3.4.2 is available. Until that please use the -devel port to get known with 3.4 and let us know any problems you run into. Bye, -- Peter Czanik (CzP) <czanik(a)balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/

1 0

which eventlog version ?
by Guillaume Rousse 08 Feb '13

08 Feb '13

Hello. I'm sorry if that was explained in the release announcement, but I can't understand why syslog-ng 3.4.1 download pages include a link to an eventlog release with a mysterious 0.2.12+20120504+1700 version number, whereas 3.4.0rc1 had 0.2.13 release instead ? Has any kind of regression found, that couldn't be fixed with a regular 0.2.14 or 0.2.13.1 release instead ? -- BOFH excuse #144: Too few computrons available.

2 1

Compilation issue with syslog-ng 3.4.1
by Guillaume Rousse 07 Feb '13

07 Feb '13

Hello list. I'm facing some compilation issue with the pacct plugin: libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lib -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/eventlog -D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD -DHAVE_NET_ETHERNET_H -I/usr/include -I../../lib/ivykis/src/include -I../../lib/ivykis/src/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -Wall -pthread -MT libpacctformat_la-pacct-format-plugin.lo -MD -MP -MF .deps/libpacctformat_la-pacct-format-plugin.Tpo -c pacct-format-plugin.c -fPIC -DPIC -o .libs/libpacctformat_la-pacct-format-plugin.o pacct-format-plugin.c:38:3: warning: initialization from incompatible pointer type [enabled by default] pacct-format-plugin.c:38:3: warning: (near initialization for 'pacct_format_plugin.construct') [enabled by default] mv -f .deps/libpacctformat_la-pacct-format-plugin.Tpo .deps/libpacctformat_la-pacct-format-plugin.Plo pacct-format.c:155:1: error: unknown type name 'LogProtoOptions' pacct-format.c:155:98: error: conflicting types for 'options' pacct-format.c:155:41: note: previous definition of 'options' was here pacct-format.c: In function 'pacct_construct_proto': pacct-format.c:157:3: warning: implicit declaration of function 'log_proto_binary_record_server_new' [-Wimplicit-function-declaration] pacct-format.c:157:3: warning: 'return' with a value, in function returning void [enabled by default] pacct-format.c: At top level: pacct-format.c:162:3: error: unknown field 'alter_proto_options' specified in initializer pacct-format.c:162:26: error: 'pacct_alter_proto_options' undeclared here (not in a function) pacct-format.c:164:1: warning: initialization from incompatible pointer type [enabled by default] pacct-format.c:164:1: warning: (near initialization for 'pacct_handler.parse') [enabled by default] make[3]: *** [libpacctformat_la-pacct-format.lo] Erreur 1 This is a mageia cauldron system, 64 bits, with gcc 4.7.2. -- BOFH excuse #368: Failure to adjust for daylight savings time.

2 1

Need help upgrading from 2.0.4 to 3.2.5
by Edward Bailey 07 Feb '13

07 Feb '13

We have moved from OEL4 to OEL6 and I need help moving the 2.0.4 functionality to the new version of syslog-ng. I am having issues with our custom application logging which has very large messages and long stack traces. I am not seeing the same behavior in 3.2.5. In 3.2.5 I am seeing truncated messages and the first line of the stack trace is being logged to the correct facility local5 while the rest of the stack trace is being logged to /var/log/messages. Also the stack trace is not being preserved anymore. Instead every line is being treated as a new line and a new syslog entry. Our custom app logging is not the best and contains carriage returns which used to be stripped by 2.0.4 but that is not happening now. Can these behaviors from 2.0.4 be preserved in 3.2.5? Any suggestions are appreciated. Here is what I am trying to work with in 3.2.5 options { flush_lines (0); time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (yes); use_fqdn (no); create_dirs (no); keep_hostname (yes); stats_freq (50000); log_msg_size(8192); }; source s_sys { pipe("/proc/kmsg" log_prefix("kernel: ")); unix-dgram ("/dev/log" flags("no-multi-line")); internal(); udp(ip(127.0.0.1) port(514)); }; destination d_cons { file("/dev/console"); }; destination d_mesg { file("/var/log/messages" perm(0644)); }; destination d_mesgr { udp("remote syslog server" port(514)); }; destination d_auth { file("/var/log/secure"); }; destination d_authr { udp("remote syslog server" port(514)); }; destination d_mail { file("/var/log/maillog" flush_lines(10)); }; destination d_spol { file("/var/log/spooler"); }; destination d_boot { file("/var/log/boot.log"); }; destination d_cron { file("/var/log/cron"); }; destination d_cronr { udp("remote syslog server" port(514)); }; destination d_cust_app { file("/var/log/cust_app.log" owner("test") group("test") perm(0644)); }; destination d_kern { file("/var/log/kern"); }; destination d_mlal { usertty("*"); }; filter f_filter1 { facility(kern); }; filter f_filter2 { level(info..emerg) and not (facility(mail) or facility(authpriv) or facility(cron) or facility(local5)); }; filter f_filter3 { facility(authpriv); }; filter f_filter4 { facility(mail); }; filter f_filter5 { level(emerg); }; filter f_filter6 { facility(uucp) or (facility(news) and level(crit..emerg)); }; filter f_filter7 { facility(local7); }; filter f_filter9 { facility(local5); }; filter f_filter8 { facility(cron); }; log { source(s_sys); filter(f_filter1); destination(d_cons); }; log { source(s_sys); filter(f_filter1); destination(d_kern); }; log { source(s_sys); filter(f_filter2); destination(d_mesg); }; log { source(s_sys); filter(f_filter2); destination(d_mesgr); }; log { source(s_sys); filter(f_filter3); destination(d_auth); }; log { source(s_sys); filter(f_filter3); destination(d_authr); }; log { source(s_sys); filter(f_filter4); destination(d_mail); }; log { source(s_sys); filter(f_filter5); destination(d_mlal); }; log { source(s_sys); filter(f_filter6); destination(d_spol); }; log { source(s_sys); filter(f_filter7); destination(d_boot); }; log { source(s_sys); filter(f_filter8); destination(d_cron); }; log { source(s_sys); filter(f_filter8); destination(d_cronr); }; log { source(s_sys); filter(f_filter9); destination(d_cust_app); };

2 1

Host behind a NAT and multiple log files
by KERNEL - Mauricio Améndola 06 Feb '13

06 Feb '13

Hi everyone I've recently configured a syslog's server using syslog-ng and i have an issue to log from hosts that are outside my network in some place on internet. This is the thing, i have a few APs and a pfsense firewall/router. Each AP can log to a remote syslog server with a specific port. In my syslog server i add a new source, filter, destination and target and in pfsense box i create the rule to let pass trafic to the internal ap's IP. But the problem comes when i do the same for another AP, i configure another port but the syslog server doesn' t log. There is a way to log from remote multiple hosts that are behind just one public IP? Thanks in advance and sorry for my english. Regards, -- -- Mauricio Améndola Communications / Technical Department KERNEL Consultores Zabala 1327/402 , 11000, Montevideo, Uruguay T+(598-2) 915 6563 / (598-2) 915 9336

3 3