- syslog-ng - lists.balabit.hu

[Bug 188] New: Syslog-ng 3.3.5.90-20120810 problems: undefined symbol and ld.so library path
by bugzilla＠bugzilla.balabit.com 06 Sep '12

06 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=188 Summary: Syslog-ng 3.3.5.90-20120810 problems: undefined symbol and ld.so library path Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Mac OS Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: jpo(a)di.uminho.pt Type of the Report: --- Estimated Hours: 0.0 Linux distro: Fedora 17 x86_64 Syslog-ng source tarball: syslog-ng-3.3.5.90-20120810-v3.3.5-43-g19f6c.tar.gz we have encountered a couple of problems when running syslog-ng-3.3.5.90-20120810 under Fedora 17 x86_64: 1) ld.so library path 2) undefined symbol: tls_context_setup_session Steps to reproduce the problem: 1) just run "/usr/sbin/syslog-ng --version" ---------- # /usr/sbin/syslog-ng --version syslog-ng 3.3.5.90 Installer-Version: 3.3.5.90 Revision: Compile-Date: Aug 17 2012 22:09:52 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afsql Error opening plugin module; module='afsocket', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' Error opening plugin module; module='afsocket-notls', error='//usr/lib64/syslog-ng/libafsocket-notls.so: undefined symbol: tls_context_setup_session' Error opening plugin module; module='afsocket-tls', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' Available-Modules: dummy,afsql,tfjson,dbparser,csvparser,convertfuncs,afuser,basicfuncs,afmongodb,confgen,syslogformat,affile,afprog Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-Linux-Caps: on Enable-Pcre: on ---------- The library path problem can be solved by creating the file "/etc/ld.so.conf.d/syslog-ng.conf" containing the syslog-ng module directory ( /usr/lib64/syslog-ng in this particular case ). Running syslog-ng under strace without touching the ld.so library paths produces: ---------- # # strace -e trace=file /usr/sbin/syslog-ng --version ... access("//usr/lib64/syslog-ng/libafsocket.so", F_OK) = 0 stat("//usr/lib64/syslog-ng/libafsocket.so", {st_mode=S_IFREG|0755, st_size=103560, ...}) = 0 open("//usr/lib64/syslog-ng/libafsocket.so", O_RDONLY|O_CLOEXEC) = 4 open("/lib64/tls/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls/x86_64", 0x7fff0f81fcb0) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 open("/usr/lib64/x86_64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/x86_64", 0x7fff0f81fcb0) = -1 ENOENT (No such file or directory) open("/usr/lib64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=49152, ...}) = 0 Error opening plugin module; module='afsocket', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' ... ----------- Note that all syslog-ng modules with the exception of libsyslog-ng-crypto.so are loaded from the syslog-ng modules directory. Output of "syslog-ng --version" after creating the file "/etc/ld.so.conf.d/syslog-ng.conf" ---------- # /usr/sbin/syslog-ng --version syslog-ng 3.3.5.90 Installer-Version: 3.3.5.90 Revision: Compile-Date: Aug 17 2012 22:09:52 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afsql Error opening plugin module; module='afsocket-notls', error='//usr/lib64/syslog-ng/libafsocket-notls.so: undefined symbol: tls_context_setup_session' Available-Modules: dummy,afsocket,afsql,tfjson,dbparser,csvparser,convertfuncs,afuser,basicfuncs,afmongodb,afsocket-tls,confgen,syslogformat,affile,afprog Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-Linux-Caps: on Enable-Pcre: on ---------- /jpo -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 13

DNS-based port knocking demo
by Endre Szabo 06 Sep '12

06 Sep '12

Hi list, Here's a proof of concept of DNS based port knocking. Firewall opens up port of SSHd for 10 seconds after nameserver answering to a predefined DNS query. It uses pattern db and netfilter only. http://vimeo.com/endreszabo/dns-portknocking Endre

5 5

The "3.3.7 RC"
by Marvin Nipper 05 Sep '12

05 Sep '12

Sorry for what will be "stupid questions". I know that you were wanting us to "try out" the 3.3.7 RC, and that (last week) you were expecting to produce that as earlier as last Friday. However... there was all of that weekend traffic, with a whole new set of ivykis-related problems, so I'm not sure what the state of the "current" packaging is at this point, and also not 100% sure what packaging I should be pulling down. My _guess_ is maybe the HEAD file from here: http://packages.madhouse-project.org/syslog-ng/3.3/3.3.6/, and I see that a new package was built last night. Bottom line... can you just let us know when you have all of the latest fixes rolled up into a potential RC package, and just verify where we should pull that from. I'm more than happy to run/test the RC package, but I just need to know when/where I should grab it. Thanks. Marvin Nipper Director of Security Stream Global Services This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

[Bug 193] New: syslog-ng 3.3. 6 spins at 100% on FreeBSD with spoof-source compiled in
by bugzilla＠bugzilla.balabit.com 04 Sep '12

04 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=193 Summary: syslog-ng 3.3.6 spins at 100% on FreeBSD with spoof- source compiled in Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: FreeBSD Status: ASSIGNED Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: algernon(a)balabit.hu ReportedBy: algernon(a)balabit.hu Type of the Report: regression Estimated Hours: 0.0 With the default syslog-ng.conf on FreeBSD, syslog-ng 3.3.6 will spin at 100% CPU when spoof source is enabled. 3.3.5 did not have this problem, neither does it happen with --disable-spoof-source, and by all accounts, this is a problem in syslog-ng, so a lib/ivykis upgrade will not help. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 12

[Bug 192] New: 3.3.6 fails to compile with --disable-spoof-source
by bugzilla＠bugzilla.balabit.com 03 Sep '12

03 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=192 Summary: 3.3.6 fails to compile with --disable-spoof-source Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: dreisner(a)archlinux.org Type of the Report: --- Estimated Hours: 0.0 Created an attachment (id=65) --> (https://bugzilla.balabit.com/attachment.cgi?id=65) fix build with --disable-spoof-source modules/afsocket/afinet.c misses some #ifdef protection of AFInetDestDriver.spoof_source, which leads to compilation failures with --disable-spoof-source. afinet.c: In function 'afinet_dd_init': afinet.c:545:11: error: 'AFInetDestDriver' has no member named 'spoof_source' mv -f .deps/libafsocket_notls_la-afsocket-plugin.Tpo .deps/libafsocket_notls_la-afsocket-plugin.Plo mv -f .deps/libafsocket_notls_la-afsocket-parser.Tpo .deps/libafsocket_notls_la-afsocket-parser.Plo make[4]: *** [libafsocket_notls_la-afinet.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... mv -f .deps/libafsocket_tls_la-afsocket-parser.Tpo .deps/libafsocket_tls_la-afsocket-parser.Plo afinet.c: In function 'afinet_dd_init': afinet.c:545:11: error: 'AFInetDestDriver' has no member named 'spoof_source' It looks like your public facing git repo isn't updated yet for the 3.3.x branch, so the attached patch is against the 3.3.6 tarball. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 190] New: syslog-ng with TCP source, fails to shutdown properly, and generates core dump
by bugzilla＠bugzilla.balabit.com 01 Sep '12

01 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=190 Summary: syslog-ng with TCP source, fails to shutdown properly, and generates core dump Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Solaris Status: NEW Severity: major Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: marvin.nipper(a)stream.com Type of the Report: bug Estimated Hours: 0.0 OK. I decided to jump to 3.3.6, so that I could get rid of the source patching that I was doing to fix the address spoofing bug in 3.3.5. It compiled cleanly, and I was hoping that I was finally going to be on an "unpatched" version of 3.3.x!! However, there is now a completely new bug that has apparently been introduced into 3.3.6, related to TCP sources. My environment is Solaris 10 U10 x86. What I am seeing: The daemon starts fine, and starts collecting log data just fine; When I execute the standard /etc/init.d script to stop the daemon (using the kill of the PID): I now instantly get a core dump; I find that both of the syslog-ng processes are still running; I find that syslog-ng no longer appears to be processing any of the UDP input (as the files that should grow, because of UDP input, are no longer growing); and I find that the one file that I generate from TCP input, is still continuing to grow. Put simply, it appears that the "kill" does not clearly shutdown the TCP source, and so syslog-ng just continues to run, and continues to "eat" TCP packets, and feed them to their designated target file. I end up having to do a kill -9 on both of the syslog-ng daemons, in order to get them to stop. The relevant statements are fairly trivial, and they work flawlessly in 3.3.5 (as well as all previous releases): source any_tcp { tcp(port(601) max-connections(40) flags("store-legacy-msghdr", "threaded") use_dns(no) log_fetch_limit(100) log_iw_size(250)); }; destination workstation_log { file("/var/adm/log/workstation.log" create_dirs(yes) flags("threaded")); }; log { source(any_tcp); destination(workstation_log); flags(final); }; Anyway, I'm hoping that you will possibly have some clue as to a particular bit of code that might have been changed between 3.3.5 and 3.3.6, that might be causing this behavior(??). Let me know what all you might want/need from me, to assist in sorting this out. SORRY for the bad news (really). I was really hoping that 3.3.6 would be "painless", and I'm sure that you were hoping for the same thing. As with the spoofing bug in 3.3.5, I am ALWAYS more than happy to try out a patch, to see if that fixes the problem. I know that it may not be easy to try out Solaris-related changes (and maybe this issue is just something in Solaris). As always, THANKS for your time and help. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

4 24

syslog-ng 3.3.7 roadmap
by Gergely Nagy 01 Sep '12

01 Sep '12

Hi! Since there were a couple of pending issues reported around the time 3.3.6 was released, a few little bugs remained in the release. The nastiest one only affects Solaris, and can be solved by updating the embedded ivykis. The others are - in my opinion - fairly rare corner cases. Nevertheless, they are all fixed in git, and I will release an RC sometime during the weekend. Any testing and feedback would be most appreciated, and if you have any issues you'd like to get fixed or implemented before the next release, do let me know! As of this writing, the following bugs were fixed in git: [#188]: afsocket-notls mistakenly being compiled as if TLS was enabled [#189]: syslog-ng --debug --version segfaulting at the module list [#190]: Solaris TCP source shutdown issue [#191]: glob-based @include working differently than the dir-based one I will have the RC going on for a little while, mostly to allow people time to install 3.3.6 (which, by and large, is the best 3.3 release so far, if I may says so myself, even with the Solaris issue), and find any bugs I may have missed. The plan is to release syslog-ng 3.3.7 on October 31st, because that's almost like a christmas present, and is far enough to allow people to test 3.3.6 and the upcoming RC, but soon enough to not let the already fixed bugs cause more damage. -- |8]

1 0

[Bug 189] New: Syslog-ng 3.3.5. 90 segfaults with cmd line options --version and --debug
by bugzilla＠bugzilla.balabit.com 01 Sep '12

01 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=189 Summary: Syslog-ng 3.3.5.90 segfaults with cmd line options -- version and --debug Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: jpo(a)di.uminho.pt Type of the Report: --- Estimated Hours: 0.0 Linux distro: Fedora 17 x86_64 Syslog-ng source tarball: syslog-ng-3.3.5.90-20120810-v3.3.5-43-g19f6c.tar.gz Summary: Using the command line options --version and --debug simultaneously causes a segmentation fault. ---------- # /usr/sbin/syslog-ng --version --debug syslog-ng 3.3.5.90 Installer-Version: 3.3.5.90 Revision: Compile-Date: Aug 20 2012 05:49:44 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afsql Segmentation fault (core dumped) ---------- # gdb /usr/sbin/syslog-ng core.1065 GNU gdb (GDB) Fedora (7.4.50.20120120-49.fc17) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/syslog-ng...Reading symbols from /usr/lib/debug/usr/sbin/syslog-ng.debug...done. done. [New LWP 1065] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/syslog-ng --version --debug'. Program terminated with signal 11, Segmentation fault. #0 nv_registry_get_handle_name (length=0x7ffff9f5a1c8, handle=4, self=<optimized out>) at nvtable.h:86 86 stored = &g_array_index(self->names, NVHandleDesc, handle - 1); (gdb) backtrace #0 nv_registry_get_handle_name (length=0x7ffff9f5a1c8, handle=4, self=<optimized out>) at nvtable.h:86 #1 log_msg_get_value_name (handle=handle@entry=4, name_len=name_len@entry=0x7ffff9f5a1c8) at logmsg.c:305 #2 0x00007f52258d8bea in log_msg_set_value (self=self@entry=0xe7da00, handle=handle@entry=4, value=value@entry=0x7f522590069b "syslog-ng", value_len=value_len@entry=9) at logmsg.c:458 #3 0x00007f52258da937 in log_msg_new_internal (prio=47, msg=0xe7cfa0 "Trying to open module; module='dummy', filename='//usr/lib64/syslog-ng/libdummy.so'") at logmsg.c:1128 #4 0x00007f52258e7703 in msg_send_internal_message (prio=<optimized out>, msg=<optimized out>) at messages.c:141 #5 0x00007f52258e78d0 in msg_event_send (e=0xe7cf30) at messages.c:179 #6 0x00007f52258eb825 in plugin_dlopen_module (module_name=module_name@entry=0xe72560 "dummy", module_path=0x7f522590068f "//usr/lib64/syslog-ng") at plugin.c:188 #7 0x00007f52258ebf73 in plugin_list_modules (out=0x7f52240d3260, verbose=verbose@entry=0) at plugin.c:293 #8 0x00000000004018a4 in version () at main.c:134 #9 0x000000000040163c in main (argc=1, argv=0x7ffff9f5a488) at main.c:217 (gdb) ---------- -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 191] New: glob-based includes aren't evaluated in proper order
by bugzilla＠bugzilla.balabit.com 01 Sep '12

01 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=191 Summary: glob-based includes aren't evaluated in proper order Product: syslog-ng Version: 3.3.x Platform: All OS/Version: All Status: ASSIGNED Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: algernon(a)balabit.hu ReportedBy: algernon(a)balabit.hu Type of the Report: bug Estimated Hours: 0.0 While upgrading one of my trickier configs, I noticed that syslog-ng suddenly refused to start, saying it can't find the mongodb destination - this was clearly bogus. A little research revealed the problem: I had a setup where /etc/syslog-ng/syslog-ng.conf had an @include "/etc/syslog-ng/conf.d/" line prior to the upgrade, but when upgraded, that changed to @include "/etc/syslog-ng/conf.d/*.conf". It turns out, that while syslog-ng loads the files in the correct order in both cases, when using globs, the include stack gets botched up: Starting to read include file; filename='/home/algernon/install/sng/3.3/etc/conf.d/00-mongodb.conf', depth='1' Starting to read include file; filename='/home/algernon/install/sng/3.3/etc/conf.d/99-test.conf', depth='2' Error parsing destination, destination plugin mongodb not found in /home/algernon/install/sng/3.3/etc/conf.d/99-test.conf at line 2, column 2: included from /home/algernon/install/sng/3.3/etc/conf.d/00-mongodb.conf line 1, column 1 included from /home/algernon/install/sng/3.3/etc/syslog-ng.conf line 26, column 1 mongodb(); 00-mongodb.conf does NOT include 99-test.conf. syslog-ng.conf includes both with a glob include. But since it thinks 99-test.conf was included by 00-mongodb.conf, it did not evaluate the contents of the latter, and as such, the mongodb module did not get loaded, and then, of course, the 99-test.conf which would use it, will fail with a parse error. With a directory include, this does not happen. A similar issue affects 3.4 too, but there plugin loading happens automatically, so this particular config would work. However, if a later config relies on a former (eg, the former defines a block), then that would break too. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

recovering corrupt disk buffer?
by Jiann-Ming Su 31 Aug '12

31 Aug '12

Is it possible to recover a corrupted disk buffer? If so, how? I don't think I saw it in the admin guide. Thanks for any tips.

2 1