[syslog-ng]Getting syslog-ng 1.6.2 running under IRIX

Leslie Robert Lait syslog-ng@lists.balabit.hu
Wed, 3 Mar 2004 18:22:30 -0500


Hi,

Our research group has started using syslog-ng (Version 1.6.2), which
compiles and runs fine on many of our machines. However, we do have
some SGI boxes running IRIX 6.5, and these presented some problems.  I
was able to get the software working on those machines after making a
few minor changes to the source.  (We compile with the native SGI C
compiler, by the way, not gcc.)

I am sending out this message with a description of each problem  we
encountered, and what we did to fix or work around the problem.  This
is not a request for support (although suggestions for better
workarounds are welcome, of course).  I simply hope that the
information may prove useful for others getting syslog-ng running under
IRIX, or perhaps for future releases of syslog-ng.  Looking through the
mailing list archives, I see that some have asked about IRIX in the
past.


Issue 1:
--------

The configuration script correctly detected that IRIX uses the
sun-streams() source for reading /dev/log (without the Solaris "door"
facility).  However, syslog-ng running under IRIX was not getting log
messages from /dev/log successfully.  Fortunately, I found that the
syslog-ng was in fact reading the log messages from the getmsg() call
in afstreams.c, but the messages were being discarded because no
terminating characters were being found by the memchr() calls.  The
current code in afstreams.c assumes that each message is terminated by
a newline or a null character, and IRIX apparently does not terminate
the message string with anything.  Apparently, SGI users are expected to
use the returned string length alone.

Our fix involves testing the returned string for a newline or a null in
its last character position (at line[n-1]).  If neither is found, then
a null terminating character is added, and the length n is
incremented.  In order to avoid the possibility of overwriting the end
of the buffer, of course, the maximum number of characters to read into
the buffer is set to one less than the length of the buffer.

----------------------- begin patch --------------------------------------
--- afstreams.c.O       Mon Feb 23 13:25:04 2004
+++ afstreams.c Mon Mar  1 11:36:43 2004
@@ -96,7 +96,8 @@
 
        ctl.maxlen = ctl.len = sizeof(lc);
        ctl.buf = (char *) &lc;
-       data.maxlen = length;
+       data.maxlen = length - 1;  /* the -1 is to allow for a possible null 
+                                terminator at the end */
        data.len = 0;
        data.buf = buf;
        flags = 0;
@@ -133,6 +134,17 @@
                UINT32 length;
                struct log_info *li;
 
+               /* Note: some systems do not terminate the message with anything.
+                  This null termination lets the memchr call below work
+                  in these cases.  We are not writing past the end of the
+                  buffer here, because we told the getmsg call to read in
+                  a maximum of (bufferlength - 1) characters, to guarantee
+                  room for this null terminator. */
+               if ( n > 0 && line[n-1] != '\0' && line[n-1] != '\n' ) {
+                       line[n] = '\0';
+                       n++;
+               }
+    
                bol = line;
                eol = memchr(bol, '\n', n);
                if (!eol) eol = memchr(bol, '\0', n);
----------------------- end patch --------------------------------------

Issue 2:
--------

IRIX does not offer the date format construct "%z", so the ISODATE
macro leaves a stray "%z" in the output of each output log line.  We
tried avoiding using $ISODATE and getting the same effect with
"$YEAR-$MONTH=$DAYT$HOUR$MIN$SEC" instead, but of course the "T" turns
DAY into the nonexistent DAYT macro, and we could not find a way to
separate them.

Instead, we introduced a C macro, NO_TZOFFSET, into macros.c.
If defined, it omits the %z construct from the ISODATE
definition.

When we run configure, we make sure to define the CPPFLAGS environment 
variable beforehand to include "-DNO_TZOFFSET".  In fact, we do this on
all machines, not just IRIX, so that our logs have a consistent,
architecture-independent format.

----------------------- begin patch --------------------------------------
--- macros.c.O  Tue Jan 13 13:08:02 2004
+++ macros.c    Thu Feb 26 11:41:28 2004
@@ -320,7 +320,11 @@
                case M_ISODATE:
                case M_ISODATE_RECVD:
                case M_ISODATE_STAMP:
+#ifndef NO_TZOFFSET
                        length = strftime(*dest, *left - 1, "%Y-%m-%dT%H:%M:%S%z", tm);
+#else
+                       length = strftime(*dest, *left - 1, "%Y-%m-%dT%H:%M:%S", tm);
+#endif
                        break;
                case M_FULLDATE:
                case M_FULLDATE_RECVD:
----------------------- end patch --------------------------------------


Issue 3:
--------

IRIX defines the AUDIT syslog facility (also called "sat", for some
reason) that syslog-ng does not know about.   (IRIX also defines
LOG_LFMT, but since it does not appear in the facilitynames[] list of
strings in /usr/include/sys/syslog.h, I stayed away from it.)  Linux
defines the "AUTHPRIV" facility, as well, which is different from
"AUTH". We added conditional definitions of these to syslog-names.c.

----------------------- begin patch --------------------------------------
--- syslog-names.c.O    Fri Oct 18 08:31:08 2002
+++ syslog-names.c      Thu Feb 26 13:37:53 2004
@@ -43,6 +43,9 @@
 }; 
 
 struct sl_name sl_facilities[] = {
+#ifdef LOG_AUDIT
+       { "audit", LOG_AUDIT },
+#endif
        { "auth", LOG_AUTH },
 #ifdef LOG_AUTHPRIV
        { "authpriv", LOG_AUTHPRIV },
@@ -56,6 +59,9 @@
        { "lpr", LOG_LPR },
        { "mail", LOG_MAIL },
        { "news", LOG_NEWS },
+#ifdef LOG_AUDIT
+       { "sat", LOG_AUDIT },
+#endif
        { "security", LOG_AUTH },           /* DEPRECATED */
        { "syslog", LOG_SYSLOG },
        { "user", LOG_USER },
----------------------- end patch --------------------------------------

Issue 4:
--------

When we tried to compile and install on our Linux machines (running a
recently-patched version of RedHat 7.3), with tcp_wrappers enabled, 
the compile fails trying to link src/tests/test_nscache.c, because
allow_severity and deny_severity are not defined. tcp wrappers doesn't
seem to be used here, but test_nscache is linked with the same flags
(including libraries) as other things, and the missing symbols trigger
an error before the linker realizes that we don't actually need the
tcp_wrapper library routines that require them.

Our solution was to add the snippet of code from afinet.c:
----------------------- begin patch --------------------------------------
--- tests/test_nscache.c.O    Fri Sep 27 05:12:08 2002
+++ tests/test_nscache.c      Mon Mar  1 16:15:38 2004
@@ -2,6 +2,12 @@
 #include "nscache.h"
 #include <stdio.h>
 
+#if ENABLE_TCP_WRAPPER
+#include <tcpd.h>
+int allow_severity = 0;
+int deny_severity = 0;
+#endif
+
 int main()
 {
   struct in_addr in;
----------------------- end patch --------------------------------------

Issue 5: 
--------

There is a bit of code in the configure script that sets CFLAGS to
include the "-Wall" parameter.  While this is OK for gcc, the native
SGI cc compiler does not recognize "-Wall".

The code is in configure.in (i.e., it is not generated by autoconf), so
it's a question of dropping the "-Wall" from the "else" clause around
lines 274 through 277 in configure.in.  Of course, the enable_debug
compiler options are likely to be installation-dependent as well. 
Perhaps pulling these out into a separate definition (say,
"CFLAGS_DEBUG") and getting autoconf to generate them, would work
better.

Anyway, for now, we have inserted a few lines in configure to 
test for IRIX and run CFLAGS through sed to remove "-Wall".
It's ugly, but it works.


[Oh, and I am probably required to say something along these lines: I
do not represent NASA or my employer SSAI in any official capacity.
Neither NASA nor SSAI officially endorse syslog-ng or take any
responsibility for any adverse consequences that may result from using
this advice or these patches.  Use at your own risk.  Your mileage may
vary.  "SGI", "IRIX", "Solaris", "Linux", and "RedHat" are all
trademarks registered by their respective owners.  Blah blah blah....]

-- 
Leslie Robert Lait            | I do not speak for NASA or for my
lrlait@code916.gsfc.nasa.gov  | employer, SSAI---at least, not until I
                              | have achieved my goal of complete world
                              | domination.