September 2012 - syslog-ng - lists.balabit.hu

[Bug 186] New: resettable stats
by bugzilla＠bugzilla.balabit.com 21 Dec '13

21 Dec '13

https://bugzilla.balabit.com/show_bug.cgi?id=186 Summary: resettable stats Product: syslog-ng Version: 3.4.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: szaki(a)balabit.hu Type of the Report: --- Estimated Hours: 0.0 According to https://lists.balabit.hu/pipermail/syslog-ng/2011-October/017457.html It would be a good idea to be able to reset the statistic, when needed, without full restart, or any magic like altering the config a bit and reload. So I suggest the enable_stats_reset(yes) default option, for sources and destinations (everywhere are statcounters defined), and the syslog-ng-ctl reset-stats command - to reset the statistic where the enable_stats_reset(yes) option allows this. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

Output to file in /proc
by Valentijn Sessink 13 Dec '13

13 Dec '13

Hello list, As most of the functionality of "sshguard", "fail2ban" and others is in syslog-ng, I'm trying to use syslog-ng to add entries to my Linux kernel based firewall (iptables). I'm almost ready to implement one, but I have a question about undeliverable log lines: what happens if a certain file() destination blocks? Will syslog-ng retry to deliver the same message, or will it lose the message? What I'm doing is using the "ipt_recent" module; with this module, one can check if a certain IP address was seen before. For example, the following rule will block you if you were seen 5 or more times ("hitcount 5") in the "violators" list last minute ("seconds 60): iptables -A INPUT -m recent \ --rcheck --hitcount 5 --seconds 60 --name violators -j DROP The fun part is, that you can add IP adresses by stuffing them into a file in /proc: echo '+127.0.0.1' > /proc/net/xt_recent/violators ... will add 127.0.0.1 to the "violators" with the current time. However: echo 'whatever' > /proc/net/xt_recent/violators ... gives an error: Invalid argument (22) As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address? Because then, an implementation of sshguard could be simply swapped with a simple: destination df_ipt_recent { file ("/proc/net/xt_recent/blocker" template("+${usracct.device}\n") ); }; filter f_ipt_recent { tags("secevt") and match("REJECT" value("secevt.verdict")); }; log { source (s_all); parser(pattern_db); filter(f_addtofirewall);destination(df_addtofirewall);}; ... which would be cool! Best regards, Valentijn

6 26

[Bug 169] New: Feature Request - reconnect network also resolve dns name
by bugzilla＠bugzilla.balabit.com 10 Oct '13

10 Oct '13

https://bugzilla.balabit.com/show_bug.cgi?id=169 Summary: Feature Request - reconnect network also resolve dns name 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: erempel(a)uvic.ca Type of the Report: --- Estimated Hours: 0.0 When a network connection is dropped the destination name should be resolved via DNS prior to the reconnect. Every couple of years to renew the hardware supporting our core syslog service we move the IP name to a new host. The desired process is; 1. Build a new host and ensure that syslog-ng is running correctly. 2. Change the DNS for our central syslog server to the address of the new server. 3. Restart the syslog-ng service on the old syslog server. 4. All of the clients will loose the connection to the old syslog server. 5. All of the clients will reconnect to the *IP Name* in their configuration files. 6. Monitor the old syslog server to determine any hosts that have not made the transition. What really happened in step 5 was that all of the client reconnected to the old syslog server :-( To accomplish the switch over I had to visit 450 servers and manually restart the syslog service on the client. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 155] New: Compilation failure in 3.3.3: the Darwin linker does not accept "--whole-archive"
by bugzilla＠bugzilla.balabit.com 26 Aug '13

26 Aug '13

https://bugzilla.balabit.com/show_bug.cgi?id=155 Summary: Compilation failure in 3.3.3: the Darwin linker does not accept "--whole-archive" Product: syslog-ng Version: 3.3.x Platform: Macintosh OS/Version: Mac OS Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: jacknagel(a)gmail.com Type of the Report: bug Estimated Hours: 0.0 Trying to compile 3.3.3 on Mac OS X 10.6.8/XCode 4.2, I get this: libtool: link: /usr/bin/llvm-gcc -std=gnu99 -dynamiclib -o .libs/libsyslog-ng-3.3.3.dylib [...] ld: unknown option: --whole-archive collect2: ld returned 1 exit status some cursory googling reveals that the Darwin linker does not accept "--whole-archive". I'd be happy to help test a patch. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 173] New: Compile issues with syslog-ng_3.3.4.tar.gz
by bugzilla＠bugzilla.balabit.com 26 Aug '13

26 Aug '13

https://bugzilla.balabit.com/show_bug.cgi?id=173 Summary: Compile issues with syslog-ng_3.3.4.tar.gz 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: mark.ulmer(a)apollogrp.edu Type of the Report: bug Estimated Hours: 0.0 Bazsi, I've been working to get a version of 3.3.x compiled on our RHEL 5.6 server for quite some time. I finally have found part of what I think is an issue that might need to be resolved on my side. I don't know. So the latest eventlog-0.2.12 compiles, makes and installs fine. Then in compiling syslog-ng-3.3.4 I get the following error: checking sanity checking Glib headers... no configure: error: Glib headers inconsistent with current compiler setting. You might be using 32 bit Glib with a 64 bit compiler, check PKG_CONFIG_PATH I see in the config.log it's looing for include files in /usr/include/glib-2.0/glib-2.0. The path on my server only has one level glib-2.0. I've tried work arounds and this still gets replicated to lower modules with the same duplicated path level. Go you have a suggestion for me to get past this? Thanks in advance for your assistance. Mark Ulmer Phoenix, AZ, USA -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

4 9

[Bug 172] New: tcp() destination driver ignores ts_format() parameter
by bugzilla＠bugzilla.balabit.com 13 Feb '13

13 Feb '13

https://bugzilla.balabit.com/show_bug.cgi?id=172 Summary: tcp() destination driver ignores ts_format() parameter Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: chiestand(a)salk.edu Type of the Report: bug Estimated Hours: 0.0 The documentation (http://www.balabit.com/sites/default/files/syslog-ng-ose-v3.3-guide-admin-e…) states that you may use the ts_format() paramater to modify the timestamp format. However this parameter does not work, rfc3164 format seems to be used no matter what you specify in ts_format(). So either the documentation is wrong or there is a bug. I am running 3.3.4 on Debian Wheezy. I also had the problem running 3.1 in Debian Squeeze. my driver: destination My_Syslog { tcp("syslog.server.salk.edu" port(514) ts_format(iso) ); }; log { source(s_src); destination(My_Syslog); }; tcpdump: @.m..<hw<86>Apr 6 01:24:01 host CRON[1923]: pam_unix(cron:session): session closed for user root I emailed the mailing list on this issue, the thread can be viewed here: https://lists.balabit.hu/pipermail/syslog-ng/2012-April/018638.html -- 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 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

[Bug 198] New: debug-info fails to extract info from libsyslog-ng-crypto.so
by bugzilla＠bugzilla.balabit.com 18 Jan '13

18 Jan '13

https://bugzilla.balabit.com/show_bug.cgi?id=198 Summary: debug-info fails to extract info from libsyslog-ng- crypto.so Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: packaging AssignedTo: folti(a)balabit.hu ReportedBy: svensken(a)jla.rutgers.edu Type of the Report: bug Estimated Hours: 0.0 The syslog-ng package fails to build on Centos6 using mock with version 3.3.6 source code and a syslog-ng-3.2.5-3.el6 spec file. The problem seems to involve the debug info package, provided by rpm-4.8.0-27.el6.x86_64 and rpm-build-4.8.0-27.el6.x86_64 Seemingly, debug info cannot be extracted from libsyslog-ng-crypto.so, whether the .so or the 'debugedit' binary is doing something incorrectly. Here's the relevant part of the build log: --------- ... + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/syslog-ng-3.3.6 extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/usr/bin/pdbtool extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/usr/bin/loggen extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/lib64/libsyslog-ng-3.3.6.so extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/lib64/syslog-ng/libcsvparser.so extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/lib64/syslog-ng/libdbparser.so extracting debug info from /builddir/build/BUILDROOT/syslog-ng-3.3.6-2.ru6.x86_64/lib64/syslog-ng/libsyslog-ng-crypto.so error: Bad exit status from /var/tmp/rpm-tmp.BZBLBe (%install) Bad exit status from /var/tmp/rpm-tmp.BZBLBe (%install) RPM build errors: Child returncode was: 1 ... --------- Throwing "%define debug_package %{nil}" into the spec will make the rpm build without errors. So it looks like the script "/usr/lib/rpm/find-debuginfo.sh" is failing to 'extract debug info' from "libsyslog-ng-crypto.so" The lack of an error message is no surprise; here's the function (inside find-debuginfo.sh) that's actually doing the debug info extraction: --------- 202 echo "extracting debug info from $f" 203 id=$(/usr/lib/rpm/debugedit -b "$RPM_BUILD_DIR" -d /usr/src/debug \ 204 -i -l "$SOURCEFILE" "$f") || exit 205 if [ -z "$id" ]; then 206 echo >&2 "*** ${strict_error}: No build ID note found in $f" 207 $strict && exit 2 208 fi --------- I tried modifying it, and found that the "exit" function is never even reached, since (as it turns out) /usr/lib/rpm/debugedit returns "Segmentation fault" when run on libsyslog-ng-crypto.so... Running /usr/lib/rpm/debugedit on the libraries that seem to be working (e.g. libcsvparser.so and libdbparser.so) without extra arguments returns no errors, however. I've found that the library itself, libsyslog-ng-crypto.so, seems to have a debug info format different from the other libraries' that succeeded in the build. As I understand it, the following command will display the debug info for a shared library: `readelf -w /path/to/library.so` It seems that the libcsvparser.so and libdbparser.so libraries both use an ".eh_frame section" to store their debug info, while libsyslog-ng-crypto.so seems to put its info into a ".debug_info section" (with hex line numbers of some sort), with an empty ".eh_frame section" section. I noticed that this crypto library was added fairly recently in the change logs, so perhaps it uses a newish format for its debug-info that is not yet supported by the debugedit binary, which is owned by rpm-build-4.8.0-27.el6.x86_64 Could there be a problem on my end, or is this an issue with the library itself? Could it be both? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 42] New: capabilities, chown, chmod
by bugzilla＠bugzilla.balabit.com 20 Dec '12

20 Dec '12

https://bugzilla.balabit.com/show_bug.cgi?id=42 Summary: capabilities, chown, chmod Product: syslog-ng Version: 3.0.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: zbyniu(a)pld-linux.org Type of the Report: bug Estimated Hours: 0.0 Let's take a look at syslog-ng-3.0.1/src/affile.c lines 60-83 1. CAP_SYS_ADMIN is needed only for /proc/kmsg, it is added w/o check 2. CAP_DAC_READ_SEARCH should be added only if open fail with errno 13 2a. CAP_DAC_OVERRIDE should be added only if open fail with errno 13 and with CAP_DAC_READ_SEARCH set 3. fchown needs CAP_CHOWN unconditionaly 4. fchmod needs CAP_FOWNER if file owner != euid (root here) 5. all caps should be restored summary: - CAP_SYS_ADMIN and CAP_DAC_OVERRIDE are set always even if unnecessary, and permanently - owner, group and perm doesn't work -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 10

syslog uses wrong and weird hostnames
by Daniel Neubacher 28 Nov '12

28 Nov '12

Hello there, My syslog-ng is logging fine from 700 servers but a few times per day it is logging into a wrong folder which is created by the $HOST variable. Normally syslog should use a hostname like host-1.worker.foobar.com but a few times a day it creates a folder names like: 4.22 p6-allrouter? p6-localnet p6-mc? p6-mcastpref p6-mcastpref? host-1.worker.foobar.xcom and other weird names... It only logs one or two lines and then uses the right folder again. Does anyone have a clue where I have to look for the problem? Here are the option line from the server and the client: Client: @version: 3.3 options { threaded(yes); use_dns(yes); use_fqdn(yes); dns_cache(yes); dns_cache_size(16384); dns_cache_expire(3600); dns_cache_expire_failed(10); log_msg_size(256000); log_fifo_size(100000); normalize_hostnames(yes); check_hostname(yes); bad_hostname("^gconfd$"); create_dirs(yes); owner("root"); group("root"); perm(0640); time_reopen(30); }; Server: options { threaded(yes); owner("root"); group("root"); perm(0660); dir_owner("root"); dir_group("root"); dir_perm(0770); create_dirs(yes); chain_hostnames(no); normalize_hostnames(yes); check_hostname(yes); keep_hostname(no); use_fqdn(yes); dns_cache(yes); dns_cache_size(16384); dns_cache_expire(3600); dns_cache_expire_failed(60); log_msg_size(256000); log_fifo_size(1000000); }; Destination example: destination d_syslog { file("/log/syslog/${R_YEAR}/${R_MONTH}/${R_DAY}/$HOST/$PROGRAM"); }; -- Daniel Neubacher, Network Administrator daniel.neubacher(a)xing.com<mailto:daniel.neubacher@xing.com> XING AG Gaensemarkt 43, 20354 Hamburg, Germany Tel. +49 40 419131-28, Fax +49 40 419131-11 Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 98807 Exec. Board (Vorstand): Dr. Stefan Groß-Selbeck (Vorsitzender), Dr. Thomas Vollmoeller, Ingo Chu, Dr. Helmut Becker, Jens Pape Chairman of the Supervisory Board (Aufsichtsratsvorsitzender): Dr. Neil Sunderland 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 unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden and may be unlawful.

2 3