Bug 714409 - EPEL5: Update syslog-ng to version 3.2.4
Summary: EPEL5: Update syslog-ng to version 3.2.4
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: syslog-ng
Version: el5
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jose Pedro Oliveira
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-19 05:14 UTC by JP Vossen
Modified: 2017-04-06 10:05 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-06 10:05:10 UTC
Type: ---


Attachments (Terms of Use)
Patch to comment out 3 lines so test will "pass" & rpm will build (1.09 KB, patch)
2011-06-20 18:46 UTC, JP Vossen
no flags Details | Diff

Description JP Vossen 2011-06-19 05:14:20 UTC
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

Comment 1 Jose Pedro Oliveira 2011-06-19 14:23:31 UTC
(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)

Comment 2 Jose Pedro Oliveira 2011-06-19 14:59:09 UTC
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

Comment 3 Jose Pedro Oliveira 2011-06-19 15:17:15 UTC
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

Comment 4 Jose Pedro Oliveira 2011-06-20 17:04:27 UTC
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
...
----------

Comment 5 JP Vossen 2011-06-20 18:44:50 UTC
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.

Comment 6 JP Vossen 2011-06-20 18:46:49 UTC
Created attachment 505669 [details]
Patch to comment out 3 lines so test will "pass" & rpm will build

Comment 7 Jose Pedro Oliveira 2011-06-20 19:51:32 UTC
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
----------

Comment 8 Enrico Scholz 2011-06-20 20:02:13 UTC
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.

Comment 9 JP Vossen 2011-06-20 20:51:49 UTC
Excellent point!  'syslog-ng3' works for me and is certainly more in keeping with "least surprise..."

Comment 10 Jose Pedro Oliveira 2011-06-20 21:05:15 UTC
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

Comment 11 JP Vossen 2011-06-22 04:43:06 UTC
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?

Comment 12 JP Vossen 2011-06-22 04:59:04 UTC
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...

Comment 13 JP Vossen 2011-06-22 05:00:29 UTC
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.

Comment 14 Jose Pedro Oliveira 2011-06-22 08:54:39 UTC
(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

Comment 15 Jose Pedro Oliveira 2011-06-22 08:58:22 UTC
(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.

Comment 16 JP Vossen 2011-06-22 09:09:23 UTC
(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.

Comment 17 Jose Pedro Oliveira 2011-06-24 13:48:57 UTC
(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

Comment 18 Jose Pedro Oliveira 2011-06-28 14:01:15 UTC
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)

Comment 19 Sam Wilson 2011-11-02 07:21:33 UTC
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

Comment 20 Matthias Runge 2011-11-02 07:34:38 UTC
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.

Comment 21 Fedora End Of Life 2017-04-06 10:05:10 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.