Description of problem: Syslog-ng is old syslog-ng-2.1.4-9.el5 in EPEL5, but the current upstream version is 3.2.4. Note EPEL6 is current with syslog-ng-3.2.4-1.el6. Actual results: syslog-ng is old Expected results: syslog-ng should be current (at least the 3.x series, preferable 3.2, ideally 3.2.4 (or newer)) Additional info: See the bottom of http://www.balabit.com/downloads/files/syslog-ng/sources/ E.g., http://www.balabit.com/downloads/files?path=/syslog-ng/sources/3.2.4
(In reply to comment #0) > Description of problem: ... > Actual results: > syslog-ng is old and no longer supported by upstream > Expected results: > syslog-ng should be current (at least the 3.x series, preferable 3.2, ideally > 3.2.4 (or newer)) It needs to be version 3.2.3 or newer (see https://bugzilla.redhat.com/show_bug.cgi?id=651823#c26)
JP Vossen, You can find a temporary syslog-ng SRPM for EPEL5 here: * http://um-pe09-2.di.uminho.pt/fedora/syslog-ng-3.2.4-0.0.2.el5.1.src.rpm and see the packaging differences between the EPEL6 and this SRPM here: * http://um-pe09-2.di.uminho.pt/fedora/syslog-ng-3.2.4-epel6-to-epel5-packaging-differences.diff It currently handles all the problems mentioned in the syslog-ng mailing list thread with the exception on the test failure (it currently doesn't run the test suite). * [syslog-ng] Rpmbuild syslog-ng-3.2.4-1.el6: FAIL: test_nvtable https://lists.balabit.hu/pipermail/syslog-ng/2011-June/016756.html /jpo
Some related tickets: EPEL5: * Bug 705486 - RFE: tcp_wrappers - add a tcp_wrappers-devel virtual provide https://bugzilla.redhat.com/show_bug.cgi?id=705486 * Bug 704690 - syslog-ng 3.x SELinux violations https://bugzilla.redhat.com/show_bug.cgi?id=704690 selinux-policy >= 2.4.6-306.el5 (RHEL 5.7) EPEL6: * Bug 699541 - syslog-ng not available for EPEL6 https://bugzilla.redhat.com/show_bug.cgi?id=699541 Fedora: * Bug 651823 - please update to syslog-ng version 3.2 https://bugzilla.redhat.com/show_bug.cgi?id=651823 * Bug 713965 - [regression] broken $HOST after upgrade to 3.2.4 https://bugzilla.redhat.com/show_bug.cgi?id=713965
Test failure in EPEL5: ---------- ... PASS: test_resolve_pwgr Assertion strcmp(name, dyn_name) == 0 failed at line 69FAIL: test_nvtable PASS: test_msgsdata ... ---------- Change test to print the strings values: ---------- $ diff -u ./tests/unit/test_nvtable.c.orig ./tests/unit/test_nvtable.c --- ./tests/unit/test_nvtable.c.orig 2010-07-14 08:47:35.000000000 +0100 +++ ./tests/unit/test_nvtable.c 2011-06-20 17:56:28.000000000 +0100 @@ -66,6 +66,8 @@ prev_handle = handle; } name = nv_registry_get_handle_name(reg, handle, &len); + fprintf(stderr, "name=<%s> dyn_name=<%s>\n", name, dyn_name); + fflush(stderr); TEST_ASSERT(strcmp(name, dyn_name) == 0); TEST_ASSERT(strlen(name) == len); ---------- Output produced: ---------- ... name=<DYN00004> dyn_name=<DYN00004> name=<DYN00005> dyn_name=<DYN00005> name=<DYN00006> dyn_name=<DYN00006> name=<DYN00007> dyn_name=<DYN00007> name=<DYN00008> dyn_name=<DYN00008> name=<DYN00009> dyn_name=<DYN00009> name=<DYN00010> dyn_name=<DYN00010> name=<DYN00011> dyn_name=<DYN00011> name=<DYN00012> dyn_name=<DYN00012> name=<DYN00004> dyn_name=<DYN00013> Assertion strcmp(name, dyn_name) == 0 failed at line 71 ... ----------
You probably want to debug lines 93 and 99 also: 69 // TEST_ASSERT(strcmp(name, dyn_name) == 0); 93 // TEST_ASSERT(strcmp(name, dyn_name) == 0); 99 // TEST_ASSERT(handle == 0); I had to comment out all 3 lines to get that test to "pass" so the rpm would build. I'll attach the trivial patch I used in the spec file.
Created attachment 505669 [details] Patch to comment out 3 lines so test will "pass" & rpm will build
The test fails due to problems in the glib 2 hash table implementation: there collisions in the version shipped with RHEL 5.x. Example code: ---------- #include <stdio.h> #include <glib.h> // gcc -Wall -Wextra `pkg-config glib-2.0 --cflags` `pkg-config glib-2.0 --libs` ghashtable.c void insert(GHashTable *name_map, const gchar *name) { printf("hash insert: key = <%s>: ", name); gpointer p = g_hash_table_lookup(name_map, name); if (p) { printf("found (ARGH)\n"); } else { printf("not found\n"); g_hash_table_insert(name_map, (gpointer)name, (gpointer)name); } } int main(void) { int i; GHashTable *h = g_hash_table_new(g_str_hash, g_str_equal); for (i = 4; i < 15; i++) { gchar dyn_name[16]; g_snprintf(dyn_name, sizeof(dyn_name), "DYN%05d", i); insert(h, dyn_name); } printf("There are %d keys in the hash\n", g_hash_table_size(h)); g_hash_table_destroy(h); return 0; } ---------- Program output in EPEL 5 (glib2-devel-2.12.3-4): ---------- hash insert: key = <DYN00004>: not found hash insert: key = <DYN00005>: not found hash insert: key = <DYN00006>: not found hash insert: key = <DYN00007>: not found hash insert: key = <DYN00008>: not found hash insert: key = <DYN00009>: not found hash insert: key = <DYN00010>: found (ARGH) hash insert: key = <DYN00011>: not found hash insert: key = <DYN00012>: not found hash insert: key = <DYN00013>: not found hash insert: key = <DYN00014>: not found There are 10 keys in the hash ---------- Program output in EPEL 6 (glib2-devel-2.22.5-5) or in Fedora 15 (glib2-devel-2.28.8-1) ---------- hash insert: key = <DYN00004>: not found hash insert: key = <DYN00005>: not found hash insert: key = <DYN00006>: not found hash insert: key = <DYN00007>: not found hash insert: key = <DYN00008>: not found hash insert: key = <DYN00009>: not found hash insert: key = <DYN00010>: not found hash insert: key = <DYN00011>: not found hash insert: key = <DYN00012>: not found hash insert: key = <DYN00013>: not found hash insert: key = <DYN00014>: not found There are 11 keys in the hash ----------
please note that configuration files are not compatible between syslog-ng 2 and 3, so that this update must not be done without special announcements. It would be preferable to create a 'syslog-ng3' package and keep the existing 'syslog-ng' one.
Excellent point! 'syslog-ng3' works for me and is certainly more in keeping with "least surprise..."
Enrico, (In reply to comment #8) > please note that configuration files are not compatible between syslog-ng 2 and > 3, so that this update must not be done without special announcements. I have no plans to pushed it unannounced. It also won't be built, at least by me, before the final release of RHEL 5.7 (and CentoS 5.7) due to the bug 704690. I also would like to see first solutions/workarounds for the testing failure and the regression you reported. > It would be preferable to create a 'syslog-ng3' package and keep the existing > 'syslog-ng' one. Personally I don't think it is a good idea to keep two different syslog-ng packages for EPEL5 due to the simple fact that version 2.1 is unsupported since 2009-12-31 [1]. Regards, jpo [1] - http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/support
I noticed that 'syslog-ng.init.d' has "# chkconfig: - 12 88" instead of the "# chkconfig: 2345 12 88" I'd expect. I assume that is on purpose?
I confirm the problem and fix from comment #2 for the "nasty macro expansion that causes the pidfile to be created in the wrong directory." (Namely, adding %global _sharedstatedir /var/lib to the spec file, per your diff file in comment #2.) My RPM without the macro fix installed, but as expected failed to start with: # /etc/init.d/syslog-ng restart Stopping syslog-ng: [FAILED] syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' Starting syslog-ng: syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' Error creating persistent state file; filename='/usr/com/syslog-ng/syslog-ng.persist-', error='Permission denied (13)' [FAILED] However, even after applying the macro fix, I still get: # /etc/init.d/syslog-ng restart Stopping syslog-ng: [ OK ] syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' Starting syslog-ng: syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' [ OK ] Oddly, I do *not* get that error when starting with 'syslog-ng -d': # syslog-ng -d Trying to open module; module='syslogformat', filename='/lib/syslog-ng/libsyslogformat.so' Trying to open module; module='basicfuncs', filename='/lib/syslog-ng/libbasicfuncs.so' Trying to open module; module='afsocket', filename='/lib/syslog-ng/libafsocket.so' Trying to open module; module='affile', filename='/lib/syslog-ng/libaffile.so' Trying to open module; module='afprog', filename='/lib/syslog-ng/libafprog.so' Trying to open module; module='afuser', filename='/lib/syslog-ng/libafuser.so' Trying to open module; module='dbparser', filename='/lib/syslog-ng/libdbparser.so' Trying to open module; module='csvparser', filename='/lib/syslog-ng/libcsvparser.so' Running application hooks; hook='1' Running application hooks; hook='3' syslog-ng starting up; version='3.2.4' < CTRL-C > Termination requested via signal, terminating; syslog-ng shutting down; version='3.2.4' Running application hooks; hook='4' This appears to be an SELinux issue, but I'm unclear why I do not see that when running from the CLI using '-d'. # echo 0 >/selinux/enforce # cat /selinux/enforce 0 # /etc/init.d/syslog-ng restart Stopping syslog-ng: [ OK ] Starting syslog-ng: [ OK ] # echo 1 >/selinux/enforce # /etc/init.d/syslog-ng restart Stopping syslog-ng: [ OK ] syslog-ng: Error setting file number limit; limit='4095'; error='Permission denied' Starting syslog-ng: syslog-ng: Error setting file number limit; limit='4095'; error='Permission denied' [ OK ] I can live with the error (or fiddle the SELinux policy later), but FYI...
After starting using '-d' then exiting using CTRL-C (see comment #12), I can't restart using the inid.d script, as follows: # /etc/init.d/syslog-ng start syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' Starting syslog-ng: syslog-ng: Error setting file number limit; limit='4096'; error='Permission denied' Error binding socket; addr='AF_UNIX(/dev/log)', error='Address already in use (98)' Error initializing source driver; source='s_sys', id='s_sys#1' Error initializing message pipeline; [FAILED] It seems like the '-d' mode (also tried -dF = same) is not removing /dev/log for some reason. After 'rm /dev/log' the usual '/etc/init.d/syslog-ng start' works.
(In reply to comment #11) > I noticed that 'syslog-ng.init.d' has "# chkconfig: - 12 88" instead of the "# > chkconfig: 2345 12 88" I'd expect. I assume that is on purpose? Correct. Syslog-ng being a sysklogd and/or rsyslog replacement daemon is always off by default. The sysadmin has to manually enable/start it. 1) install the syslog-ng RPM 2) chkconfig rsyslog off; chkconfig syslog-ng on 3) service rsyslog stop; service syslog-ng start
(In reply to comment #12) > ... > I can live with the error (or fiddle the SELinux policy later), but FYI... Please (re)read comments 3 and 10.
(In reply to comment #15) > > Please (re)read comments 3 and 10. And I even already had bug 704690 open in another tab... Figures... Sorry about the dup.
(In reply to comment #7) > The test fails due to problems in the glib 2 hash table implementation: there > collisions in the version shipped with RHEL 5.x. > > ... Ticket opened against the glib2 component of RHEL 5: * Bug 716447 - glib2 problem: hash table collisions https://bugzilla.redhat.com/show_bug.cgi?id=716447
New SRPM: * http://um-pe09-2.di.uminho.pt./fedora/syslog-ng-3.2.4-0.0.4.el5.1.src.rpm Changelog: * includes patch for the chain hostnames regression (#713965)
Found an issue with the current 3.2.4.2_el6 package where SSL is still left disabled. Was this intentional? I need to run TLS so I am rebuilding the RPM with --enablessl in the spec. Could it be this was missed after testing? Cheers, Kahn
Sam: thank you for your feedback. There is an issue regarding ssl and syslog-ng: Syslog-ng installs to /sbin, ssl libraries are in /usr/lib. If you're getting /usr over nfs, i.e. mounting /usr after running syslog-ng, you'll end in some desaster. No Fedora/RHEL/EPEL package has ssl enabled. Suse packages copy ssl-libs to /lib, which is strictly forbidden for rhel/epel/fedora. So: this is intentional (until this issue is fixed) I hope, this describes the situation best.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.