# INN FAQ Part 2/9

From: INN FAQ Maintainers
Newsgroups: news.software.nntp,news.software.b
Subject: INN FAQ Part 2/9: Specific notes for specific operating systems
Followup-To: news.software.nntp
Summary: This article is part 2 of a multi-part FAQ: Part 2: Advice specific to certain operating systems.
Posted-By: post_faq 2.10
Archive-name: usenet/software/inn-faq/part2
Last Changed: $Date: 1997/12/18 21:42:25 $ $Revision: 1.6 $

INN FAQ Part 1: General and questions from people that don't (yet) run INN
INN FAQ Part 2: Specific notes for specific operating systems
INN FAQ Part 3: Reasons why INN isn't starting
INN FAQ Part 4: The debugging tutorial (setup of feeds etc.)
INN FAQ Part 5: Other error messages and what they mean
INN FAQ Part 6: Day-to-day operation and changes to the system
INN FAQ Part 7: Problems with INN already running
INN FAQ Part 8: Appendix A: Norman's install guide
INN FAQ Part 9: Appendix B: Configurations for certain systems

Go to the table of contents

Subject: Table Of Contents for Part 2/9

TABLE OF CONTENTS FOR PART 2/9

SPECIFIC NOTES FOR SPECIFIC OPERATING SYSTEMS:

- 2.1 BASH tips
- 2.2 GNUS tips
- 2.3 AIX tips
- 2.4 SunOS 4.1.1 tips
- 2.5 Ultrix tips
- 2.6 HP-UX tips
- 2.7 UnixWare tips
- 2.8 Linux tips
- 2.9 A/UX 3.0 (Macintosh) tips
- 2.10 Alpha OSF tips
- 2.11 SGI IRIX 5.x tips
- 2.12 Systems where only root can have "cron" jobs.
- 2.13 System V based Unixes (SVR4, Solaris 2.x, SCO ODT 3.0, AIX, A/UX, DELL, ...)
- 2.14 Solaris 2.x special needs
- 2.15 Slackware Tips
- 2.16 BSDi 2.0 / FreeBSD / NetBSD
- 2.17 3Com Router users
- 2.18 NOV problems on a Pyramid
- 2.19 Warnings to people that must set HAVE_UNIX_DOMAIN to DONT
- 2.20 INN for SNI RM400
- 2.21 INN on NeXT-/OpenStep

  Note: See also Appendix B (Part 9 of the FAQ)

  SPECIFIC NOTES FOR SPECIFIC OPERATING SYSTEMS

  Go to the table of contents

  Subject: (2.1) BASH tips

  If you are using a Unix who's /bin/sh is a hardlink to bash, you'll find problems using nntpsend. nntpsend uses a variable named PPID, which is a read-only variable in BASH.

  You'll get errors that look like this:
  sh: PPID: read-only variable

  You can fix it using the the following patch:

  `*** nntpsend~ Thu Aug 12 03:36:16 1993` `--- nntpsend Sat Oct 23 15:54:11 1993` ***************
  *** 1,4 ****
  ! #! /bin/sh

        ##  $Revision: 1.6 $
        ##  Send news via NNTP by running several innxmit processes in the background.

        ##  Usage:

  --- 1,4 ---- ! #!/usr/local/bin/bash

        ##  $Revision: 1.6 $
        ##  Send news via NNTP by running several innxmit processes in the background.

        ##  Usage:

  ***************
  *** 130,140 ****

            chmod 0660 ${LOG}
            exec >>${LOG} 2>&1
        fi

  ! PPID=$$ ! echo "${PROGNAME}: [${PPID}] start"

        ##  Set up environment.

  ! export BATCH PROGNAME PPID INNFLAGS

        ##  Loop over all sites.

        cat ${INPUT} | while read SITE HOST MAXSIZE FLAGS; do

  --- 130,140 ----

            chmod 0660 ${LOG}
            exec >>${LOG} 2>&1
        fi

  ! CPID=$$ ! echo "${PROGNAME}: [${CPID}] start"

        ##  Set up environment.

  ! export BATCH PROGNAME CPID INNFLAGS

        ##  Loop over all sites.

        cat ${INPUT} | while read SITE HOST MAXSIZE FLAGS; do

  ***************
  *** 240,246 ****

            fi

            ##  Start sending this site in the background.

  `! export SITE HOST LOCKS BATCHFILE PROGNAME PPID SIZE TMPDIR`

            sh -c '
              BATCHFILE=${HOST}.nntp

  LOCK=${LOCKS}/LOCK.${HOST}
  --- 240,246 ----

            fi

            ##  Start sending this site in the background.

  `! export SITE HOST LOCKS BATCHFILE PROGNAME CPID SIZE TMPDIR`

            sh -c '
              BATCHFILE=${HOST}.nntp

  LOCK=${LOCKS}/LOCK.${HOST}
  ***************
  *** 247,253 ****

              trap "rm -f ${LOCK} ; exit 1" 1 2 3 15
              shlock -p $$ -f ${LOCK} || {
                  WHY="`cat ${LOCK}`"

  `! echo "${PROGNAME}: [${PPID}:$$] ${HOST} locked ${WHY} `date`"`

                  exit
              }
              if [ -f ${SITE}.work ] ; then

  --- 247,253 ----

              trap "rm -f ${LOCK} ; exit 1" 1 2 3 15
              shlock -p $$ -f ${LOCK} || {
                  WHY="`cat ${LOCK}`"

  `! echo "${PROGNAME}: [${CPID}:$$] ${HOST} locked ${WHY} `date`"`

                  exit
              }
              if [ -f ${SITE}.work ] ; then

  ***************
  *** 254,259 ****
  --- 254,260 ----

                  cat ${SITE}.work >>${BATCHFILE}
                  rm -f ${SITE}.work
              fi

  `+ if [ -s ${SITE} ] ; then`

              mv ${SITE} ${SITE}.work
              if ctlinnd -s -t30 flush ${SITE} ; then
                  cat ${SITE}.work >>${BATCHFILE}

  ***************
  *** 260,273 ****

                  rm -f ${SITE}.work
                  test -n "${SIZE}" && shrinkfile -s${SIZE} -v ${BATCHFILE}
                  if [ -s ${BATCHFILE} ] ; then

  `! echo "${PROGNAME}: [${PPID}:$$] begin ${HOST} `date`"` `! echo "${PROGNAME}: [${PPID}:$$] innxmit ${INNFLAGS} ${HOST} ..."`

                      eval innxmit ${INNFLAGS} ${HOST} ${BATCH}/${BATCHFILE}

  `! echo "${PROGNAME}: [${PPID}:$$] end ${HOST} `date`"`

                  else
                      rm -f ${BATCHFILE}
                  fi
              fi
              rm -f ${LOCK}
            ' &
            sleep 5

  --- 261,275 ----

                  rm -f ${SITE}.work
                  test -n "${SIZE}" && shrinkfile -s${SIZE} -v ${BATCHFILE}
                  if [ -s ${BATCHFILE} ] ; then

  `! echo "${PROGNAME}: [${CPID}:$$] begin ${HOST} `date`"` `! echo "${PROGNAME}: [${CPID}:$$] innxmit ${INNFLAGS} ${HOST} ..."`

                      eval innxmit ${INNFLAGS} ${HOST} ${BATCH}/${BATCHFILE}

  `! echo "${PROGNAME}: [${CPID}:$$] end ${HOST} `date`"`

                  else
                      rm -f ${BATCHFILE}
                  fi
              fi

  `+ fi`

              rm -f ${LOCK}
            ' &
            sleep 5

  ***************
  *** 275,278 ****

        wait
        rm -f ${INPUT}

  ! echo "${PROGNAME}: [${PPID}] stop" --- 277,280 ----

        wait
        rm -f ${INPUT}

  ! echo "${PROGNAME}: [${CPID}] stop"

  Go to the table of contents

  Subject: (2.2) GNUS tips

  In article <3g82ll$mr4@tid.tid.es> Emilio Losantos <emilio@tid.es> writes:

  > I have to use GNUS 4.1 to read news from a nntp server running INN 1.4, but
  > whenever I try to select a group I receive the message:

  > "GROUP" not implemented; try "help"

  > Could anybody tell me how to fix this problem?

  jbryans@csulb.edu (Jack Bryans) replies:

  Patch your nntp.el something like this:

  *** 72,77 ****
  --- 72,79 ----

          (set-process-sentinel nntp/connection 'nntp/sentinel)
          (process-kill-without-query nntp/connection)
          (let ( (code (nntp/response)) )

  `+ (nntp/command "mode reader")` `+ (nntp/response)`

            (or (eq code 200) (eq code 201))))

        (defun nntp-server-opened ()

  Note that your line numbers may vary. There's a lot of nntp.el's out there.

  Go to the table of contents

  Subject: (2.3) AIX tips

  Q: Is there a config.data for AIX 4.1 ?

  A: In <http://www.news.inet.tele.dk/config.data> you will find one for AIX 4.1.4 and INN1.5.1. If you want to use this with older INN versions, then you have to remove some lines from it. Note that it might be that in the sample CLX_STYLE is set to IOCTL. You might change this to FCNTL as described below (2.13) if you get many overchan processes.

  Q: In config.data, should ACT_STYLE be set to READ or MMAP?

  A: Gee, some say MMAP works, some say it doesn't. I recommend you use READ. After you've been running for a month, try MMAP for a day and see what happens.

  Kurt Jaeger <Kurt.Jaeger@RUS.Uni-Stuttgart.DE> adds:

  On 3.2.5, MMAP works if one makes some patch to the innd so that it allocates one byte more than filelength(active) or filelength(history [or whatever is mapped by innd]).

  Reason: If filelength(active/whatever file) on AIX is a multiple of page size (4096 bytes), searching for a trailing NUL byte in a MMAPed file will kill the process with SEGV or the AIX equivalent.

  Q: What compiler should I use?

  A: Most people use what's listed in Install.ms, though we have one report of a AIX 3.2.5 user that found bsdcc worked better.

  Q: When I run news.daily, there's always a few lines of error messages at the end of the output:

  | compress: bad file number

  A: AIX /usr/bin/compress has a bug when compressing files with zero length. Then it spits out this error. Solution: Ignore it or use a different compress program and change config.data accordingly.
  (from Kurt Jaeger <pi@rus.uni-stuttgart.de>)

  Q: innwatch doesn't work well from /etc/inittab, does it?

  A: Nope. Instead, you can create a "subsystem" with this command:

  mkssys -s innwatch -p /usr/local/news/bin/innwatch \

      	-u `id -u news` -G news -S -n 15 -f 9

  Note that your path to innwatch may differ, depending on where you decided to install the inn components. You also need to enter the command as one long line.

  This will create a subsystem named "innwatch" belonging to an SRC group named "news". The "-S" means that it uses signals for SRC to tell it when to stop and the "-n" is the SIGTERM signal, for normal shutdown, and the "-f" is the SIGKILL signal, which is sent if the process does not stop within 20 seconds. Then, modify rc.news to issue the command

          startsrc -s innwatch

  to get innwatch going. That's it!

  Shane Castle <swcxt@boco.co.gov, swcxt@csn.org>

  Q: When I compile I get something like:

      	0706-317 ERROR: Unresolved or undefined symbols detected:
      		Symbols in error (followed by references) are
      		dumped to the load map.

      		The -bloadmap:<filename> option will create a load map.

      		.dbzwrit
      	cd frontends ; make  all ; cd ..

      	Target all is up to date.

  A: That means you don't have a program called "patch" installed on your machine. Refer to "Subject: ld.so: Undefined symbol: _dbzwritethrough"

  Q: What can I change in innwatch.ctl to make it work right?

  A: The "df" command in AIX has a funny output that requires you to modify innwatch.ctl. The FTP site has an install.ctl that uses "df -i" (some AIX versions) and another one that uses "df -v" (recommended by someone with AIX 3.2.5).

  Q: Can I use a compressed filesystem?

  A: (From Kurt Jaeger):

  On AIX 4.1.x, use compressed filesystems with 512 bytes per fragment and 2048 bytes per inode. This is the best space optimazation I could find up to now. News is I/O bound, so doing some more compression to save on head seeks and reads will better balance your system. I currently have a 100/60% yield: If the disk would be 100% full, 60% of the inodes would be used.

  Go to the table of contents

  Subject: (2.4) SunOS 4.1.1 tips

  SunOS 4.1.1 (but not 4.1.2 or 4.1.3) broke the write system call but a patch is available. Any write could fail "half way", it is just more likely to happen when writing large files and in-core DBZ writes the history file out in one chunk. The "Known Problems" section of the installation manual says to install Patch 100293-01, but that has been replaced by 100622-01.

  Go to the table of contents

  Subject: (2.5) Ultrix tips

  Tip #1: Ultrix has a "mmap()" function, but it doesn't do the same thing as the SunOS/BSD mmap() function. Therefore, do not configure INN to use mmap() on a Ultrix system. INN wants to find a mmap() function that is like the one on SunOS/BSD systems.

  Tip #2: The sendsys script breaks Ultrix 'nawk'. You can make a 1-line change or you can switch to 'awk' or "gawk".
  Original line:

      	${AWK} "/^$1"'[/:\\]/,/[^\\]$/' ${NEWSFEEDS} >${TEMP}

  Modified line:

      	${AWK} "/^$1"'[\/:\\]/,/[^\\]$/' ${NEWSFEEDS} >${TEMP}

  The original line will work with awk, gawk, but not nawk.
  The modified line will work with awk, gawk, or nawk.
  If you have gawk running on your machine use it. Otherwise, switch to awk.

  Tip #3: The syslog on Ultrix sucks rotten eggs and Digital refuses to fix it. (source: everyone that uses Ultrix and has ever used other systems) Luckily, you can replace it with the routine that comes with INN. However, some people have had better luck installing the syslog that can be found on "gatekeeper.dec.com:/pub/DEC/jtkohl-syslog-complete.tar.Z". It still works with old clients but does new-style syslogging, too. Works great for me so far. (this information from: nelson@reed.edu (Nelson Minar)). The syslog that is shipped with INN works pretty well but there have been some claims that some old clients don't like it.

  Go to the table of contents

  Subject: (2.6) HP-UX tips

  Q. My logs keep telling me there is no space for articles A. Edit innwatch.ctl to use "bdf" instead of "df".

  Q. I am running inn on an HP machine. INN won't start up automatically.
  I can start it manually. There is no problem with news or INN once it is started.

  A. Try adding a "sleep 10" to the bottom of /etc/rc.news, or in /etc/rc, right after /etc/rc.news is invoked. On some machines, including HP, the shell started by "#!/bin/sh" when /etc/rc is executed will exit before innd has disassociated itself from that shell. This causes innd to exit, sometimes without printing an error message.
  (source: pjoslin@mbvlab.wpafb.af.mil (Paul Joslin ))

  This problem goes away if you set HAVE_SETSID to "DO". Something to do with Posix Session Leader concepts. Ick. (source: Steve Howie <showie@uoguelph.ca>). You can also do something like:

      	echo /usr/lib/etc/rc.news | at now + 2 minutes

  or else

      	nohup su news -c /usr/local/etc/rc.news&

  HP-UX 8.x and 9.x users might find a problem with getting innwatch to start up. People have found that having "at" start it seems to work more reliably than other methods:

  ${DOINNWATCH} && {

      	echo "${INNWATCH} &" | su ${NEWSUSER} -c 'at now + 2 min' > /dev/null

  }

  The '&' in the command line prevents innwatch from taking up an at-job slot. SysV-style crons have a per-category and overall limit on the number of jobs executing simultaneously.

  Q: INN-1.4sec running on an HP9000 s700 with HP-UX 9.01 leaks memory like crazy. The innd process grows and grows, then stops with:

      	"ME cant remalloc 8192 bytes Not enough space"

  A: The cause turns out to be a memory leak in the standard C library (both /lib/libc.a and /lib/libc.sl). Installed patch PHCO_5056 (or the latest libc patch).

  Go to the table of contents

  Subject: (2.7) UnixWare tips

  UnixWare 1.1.2 works with domain sockets. Install ptf149 "unix domain sockets" and ptf678 "fix for sockmod's incorrect handling of disconnect indication"

  Otherwise, configure like any SVR4 system.

  Go to the table of contents

  Subject: (2.8) Linux tips

  Get inn-1.4-linux-0.1.tar from ftp://sunsite.unc.edu/pub/Linux/system/News It contains instructions for installing INN on a Linux system and a working config.data file. (from ghio@myriad.pc.cc.cmu.edu)

  If you don't follow the directions in inn-1.4-linux-0.1.tar, here are some of the problems you might have:

  > nntpsend.log says the following.

  > nntpsend: [214:222] innxmit -a -t300 -T1800
  > travelers.mail.cornell.edu ...
  > Ignoring line "cornell/test/13 805 ..."
  > sh: PPID read-only variable

  Tomasz Surmacz <tsurmacz@ict.pwr.wroc.pl> writes:

  If you are using INN under Linux or have your /bin/sh a symlink to /bin/bash the above problem appears (in nntpsend precisely speaking, not innxmit)

  The problem is that bash already defines the PPID variable and nntpsend is trying to use it too. To fix this:

  1. comment out line PPID = $$ 2. change all occurrences of PPID to say PARENTPID

  I have also noticed that changing first line of nntpsend from '#!/bin/sh' to "#!/bin/bash" helps in such occasions.

  Slackware 3.0 seems to have a different incarnation of df than others - so if you want to run innwatch change the following in innwatch.ctl:

  From:
  < ## =()<!!! df -i . | awk 'NR == 2 { print $3 }' ! lt ! @<INNWATCH_SPOOLNODES>@ ! throttle ! No space (spool inodes)>()= < !!! df -i . | awk 'NR == 2 { print $3 }' ! lt ! 200 ! throttle ! No space (spool inodes) To:
  > ## =()<!!! df -i . | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_SPOOLNODES>@ ! throttle ! No space (spool inodes)>()=
  > !!! df -i . | awk 'NR == 2 { print $4 }' ! lt ! 200 ! throttle ! No space (spool inodes)

  (from Jim Kerr <jak7@opsirm1.em.cdc.gov>)

  ------

  Linux 2.x complains at compiling:

  gcc -O -o nnrpd article.o group.o commands.o misc.o newnews.o nnrpd.o post.o loadave.o ../libinn.a loadave.o(.text+0x3b): undefined reference to `nlist'

  You can either add /usr/lib/libelf.a as missing library to the Makefile or apply the following patch (with some fuzz ... ) from coneill@premier1.premier.net (Clayton O'Neill) :

  --- /usr/local/news/INN/nnrpd/loadave.c Fri Jan 29 10:51:58 1993 `+++ loadave.c Wed Jul 17 15:36:30 1996` @@ -1,8 +1,28 @@ -/* $Revision: 1.6 $ +/* $Revision: 1.6 $

       **

       */
       #include "nnrpd.h"
       #if    NNRP_LOADLIMIT > 0

  +#ifdef linux + +/*
  +** Get the current load average as an integer.
  +*/ +int +GetLoadAverage() +{ `+ FILE *ProcLoadAve;` `+ float load;` + `+ if ((ProcLoadAve=fopen("/proc/loadavg", "r"))==NULL)` `+ return -1;` `+ if (fscanf(ProcLoadAve,"%f", &load)!=1)` `+ return -1;` `+ fclose(ProcLoadAve);` `+ return (int)(load+0.5);` +} + +#else

       #include <nlist.h>

  [...] + #endif /* linux */

      #endif  /* NNRP_LOADLIMIT &gt; 0 */

  ------

  In some newer versions of Linux, nnrpd seems to seg fault. Reason is the size of fd_set (1024 bit), but the macros FD_??? operate on 256bit). This happens if HAVE_UNISTD is set to DONT, so set it to DO.
  If it still happens, then include <sys/time.h> at the top of include/clibrary.h

  ------

  It might be that rc.news never terminates in unoff4 (and probably other versions), when having DOINNWATCH=true. If this happenes then include a '&' in rc.news as shown:

  : ${DOINNWATCH} && { `: ( sleep 60 ; ${INNWATCH} & ) &`

                                    ^^^

  Go to the table of contents

  Subject: (2.9) A/UX 3.0 (Macintosh) tips

  Tip #1: Use the INN malloc.

  Tip #2: If you are running INN 1.4 on a Mac running A/UX 3.0.1, Every so often, (generally when someone fires up a reader), INN goes berserk.
  Syslog says:

      	innd: ME cant select Bad file number

  This message repeats about 20 times per second. It freezes up my computer and I need to reboot.

  That's a kernel bug. You do have to reboot.

  If you compiled inn with gcc, don't. My experience was that somehow, if INN was compiled with GCC the kernel bug is triggered, but that doesn't happen with cc.

  Go to the table of contents

  Subject: (2.10) Alpha OSF tips:

  To compile INN for the DEC Alpha, follow the instructions in the INN patch archive on ftp://ftp.isc.org/isc/inn/unoff-patches

  A config.data file for OSF1.3a is in:

      	ftp://infinite.cs.swt.edu/pub/usenet/inn/

  A config.data file for OSF3.0 is in:

      	ftp://infinite.cs.swt.edu/pub/usenet/inn/

  In rc.news you need to start $INNWATCH using the following:

  ${DOINNWATCH} && {

          echo "${INNWATCH} &" | su ${NEWSUSER} -c 'at now + 2 min' > /dev/null

  }

  The '&' in the command line prevents innwatch from taking up an at-job slot. SysV-style crons have a per-category and overall limit on the number of jobs executing simultaneously.

  Go to the table of contents

  Subject: (2.11) SGI IRIX 5.x tips

  Some people have reported that IRIX 5.1 isn't very reliable and that it `is worth it to run 5.2. 5.3 is even better, but it is still not` perfect. (In other words: IT WORKS FINE AS Install.ms DESCRIBES!)

  Robert Keller <rck@fangio.asd.sgi.com> has some tips for filesystem layout:

  NOTE: For efs filesystems, you want to be sure that you mount your news spool using the lbsize option (/etc/fstab) set to 4096, eg:

          /dev/dsk/dks1d5s7 /spool efs rw,raw=/dev/rdsk/dks1d5s7,lbsize=4096 0 0

  This tells efs to only preallocate 4K worth of space on the first write of a file to disk. The default of 32K causes a terrible waste of effort for the writing of an average 2K news posting. This also can Innd slow down quite a bit, as the efs is searching for spare 32kB blocks on disk. If you can use xfs then do so.

  For the new xfs filesystems, you want to be increase the default filesystem block size from 512 bytes to about 2K for maximum performance. I just setup a 8 Gig xfs news spool on a Challenge L using 2K blocks and the performance is absolutely incredible.

  See also <http://reality.sgi.com/rck/software/inn.html> for more tips on running INN on SGI platforms.

  Another note to the 5.3XFS: (From: olson@anchor.engr.sgi.com (Dave Olson))

         The ordering/location of files in a directory can change when
         files are unlinked, with xfs, and some of fastrm's assumptions
         therefore break.

  So if you get files which are to be expired with fastrm, but which stay in spool, then try to use normal expire or edit expirerm to remove -s option from RMPROC:

         old: RMPROC="fastrm -e -s ${SPOOL}"
         new: RMPROC="fastrm -e -u ${SPOOL}"

  6.2XFS has been changed to respect the traditional readdir() behaviour (after rck@fangio.asd.sgi.com (Robert Keller)).

  Jack Bryans <jbryans@csulb.edu> writes:

  Both ACT_STYLE and DBZCFLAGS may use MMAP. If you use either, you'll need the following patch:
  `*** include/clibrary.h.orig Thu Mar 18 13:04:07 1993` --- include/clibrary.h Sat Mar 9 14:13:40 1996 ***************
  *** 103,109 ****
  --- 103,111 ----

        extern POINTER                malloc();
        extern POINTER                realloc();
        #if   defined(ACT_MMAP)

  + #ifndef __sgi

        extern char           *mmap();

  + #endif /* not sgi */

        #endif        /* defined(ACT_MMAP) */

  Go to the table of contents

  Subject: (2.12) Systems where only root can have "cron" jobs.

  Your cron jobs may not work if you use:

      	su news -c /usr/lib/news/bin/news.daily delayrm expireover

  Instead, you must put the entire command in quotes. Like this:

      	su news -c "/usr/lib/news/bin/news.daily delayrm expireover"

  Look for "Pyramid" later in this FAQ for the interesting details.

  Go to the table of contents

  Subject: (2.13) System V based Unixes (SVR4, Solaris 2.x, SCO ODT 3.0, AIX, A/UX, DELL, ...)

  NOTE: Solaris 2.x is based on SVR4.0. These tips are useful in a limited way. Read this section for general advice, but follow the "Solaris 2.x" section details.

  If you are running any non-BSD (i.e. System V based) Unix you MUST have the following option set:

      ##  How should close-on-exec be done?  Pick IOCTL or FCNTL.<BR>
      #### =()<CLX_STYLE              @<CLX_STYLE>@>()=
      CLX_STYLE               FCNTL

  This includes SVR4, Solaris 2.x, A/UX and SCO ODT 3.0. (SVR4 means systems based on System V Release 4 from USL. Please check your manual to see if your operating system is based on SVR4.)

  This CLX_STYLE setting is clearly stated in the Install.ms file and repeated here since so many people post to news.software.nntp after ignoring the warnings.

  If CLX_STYLE isn't set to FCNTL, you'll get tons of overchan processes hanging around.

  With SCO ODT 3.0 and MOST systems, innd will link and run if you use IOCTL but eventually will stop answering incoming calls.

  Don't be fooled. Just because it compiles doesn't mean it's going to work.

  If you start innd on an AT&T SysV Rel 4.0 machine and get syslog messages like:

      	localhost:15 cant setsockopt(SNDBUF) Protocol error
      	localhost:15 cant setsockopt(RCVBUF) Protocol error

  then you should FIRST try to change HAVE_UNIX_DOMAIN to "DONT" in config.data. If that doesn't fix the problem, you should add "-USO_SNDBUF" to your DEFS parameter in config.data. Or, you can comment out the "setsockopt()" calls. This is also mentioned in the Install.ms file (which means if you needed to read it here, you weren't paying attention when you read Install.ms)

  Many SVR4 for i486 binaries (sendmail, mh, vmail, innd, rnews are now on ftp.germany.eu.net in pub/comp/i486/svr4/*.SVR4.tgz But remember that some of the above need site specific changes, so their usefulness may be limited.

  If you get syslog messages that say, "ME cant accept RCreader" please refer to Part 3 of this FAQ.

  DELL ships their Unix with /dev/log chmod'ed to 0644 which means nobody can syslog anything. Pretty stupid, eh? INN uses syslog extensively.
  If you find that you don't get any syslog messages check to see if you need to: "chmod 0666 /dev/log".

  Nobody knows why SVR4 boxes often give error messages like, "innd: accept: SIOCGPGRP failed errno 22". There's some sort of obscure bug with the SVR4 accept() call that can lead to these messages, if the executable is linked a certain way. I suspect that the same symbol -- for two totally separate variables or routines -- is defined in two different libraries, so if you link in certain ways you get the "wrong" thing. This error drove me crazy when I first built sendmail V8 on our NCR 3000 box. But I re-linked it a different way and I haven't seen the error since. Good riddance. I suggest you play around with your link libraries and/or order of linkage.

  kevin@cfc.com (Kevin Darcy) says he never gets these messages since he started using (in config.data):
  `LIBS -lsocket -lnsl -lelf`

  If your SVR4 system still doesn't run correctly, check the Solaris 2.x suggestions.

  Go to the table of contents

  Subject: (2.14) Solaris 2.x special needs

  Solaris 2.5:

      	Sun assures that Solaris 2.5 does no longer have the socket bug
      	(see fix #7 below) and Dave Zavatson <dhzavatson@ucdavis.edu> writes
      	that the bug still exists ... So if you see "'resource temp
      	unavailable' errors, you have to apply it.

  Joe St Sauver <JOE@OREGON.UOREGON.EDU> submitted the following:
  Symptom: One of the topologically distant sites notices far lower than normal article throughput. Further investigation by the remote site (using netstat) identifies a large number of "completely duplicated packets" originating with the Solaris feed host.

  Resolution: The local Solaris 2.5 host had not applied Sun patches 103169-05 ("ip driver and ifconfig fixes") and 103447-03 ("tcp patch") as can be obtained from ftp://sunsolve1.Sun.COM/pub/patches/patches.html (Solaris 2.5.1 users, see 103582-01 and 103630-01).

  Without these patches, when working with hosts that are topologically remote, TCP/IP throughput reportedly can drop to as little as 5% of what it should be. For further information, see: <199607140422.VAA04495@yorick.cygnus.com> quoting a 7 June 1996 article posted to comp.unix.solaris by Cathe A. Ray (Manager of Internet Engineering for Sun).

  Thanks to Howard Goldstein <hgoldste@bbs.mpcs.com> for the detective work in isolating and resolving this problem!

  SOLARIS 2.4: Install the Recommended cluster patch from Sun.
  The Recommended cluster patch is:

      	ftp://sunsolve1.sun.com/pub/patches/2.4_Recommended.tar.Z
      	The README is:
      	ftp://sunsolve1.sun.com/pub/patches/2.4_Recommended.README

  Then follow the directions in

      	ftp://ftp.isc.org/isc/inn/unoff-patches/OLD/solaris-2.4.patch.
      	The patch needs to be applied BY HAND, it is not in the correct format
      	to work with Larry Wall's patch program.  Also, do *not* link with the
      	/usr/ucblib stuff, and HAVE_WAITPID should be set to "DO".

  On 3/25/95 Sun introduced patch 101945-23 which fixes bug #1178506 titled

      	"INN wounded after upgrade to SunOS 5.4".  This fixes the
      	"cant read Resource temporarily unavailable" bug that some
      	have reported.

          But Even if the Sun Patch mentions
      	"1186224 socket select hangs in NON-BLOCKED mode", this seems not to
      	be totally fixed. Ian Dickinson <idickins@fore.com>
              doesn't notice it on his lightly loaded
      	server. But on heavily loaded machines, it occurs occasionally
      	(<5 times a day). See below for a patch (Solaris Fix #7 )

  It seems that the last version of the kernel patch for Sparc is 19945-36; 191945-29 is known to work. For x86 the latest version is 101946-29, which has problems with Unix domain sockets, so 101946-12 seems to be the last usable one here ...

  Include /opt/SUNWspro/bin and /usr/bin in your path before /usr/ucb as

      	/usr/ucb/sed does not work well.

  SOLARIS 2.3: If you install the "Recommended cluster patch" I *think*

      	you will only need to pay attention to Fix #5 listed below.  It would
      	be helpful if people sent an update about this.

  The Recommended cluster patch is:

      	ftp://sunsolve1.sun.com/pub/patches/2.3_Recommended.tar.Z

  The README is:

      	ftp://sunsolve1.sun.com/pub/patches/2.3_Recommended.README

  (note: If you trust other people to compile programs for you [especially ones that run as root] you can get inn1.4sec pre-compiled w/gcc at ccnews.ke.sanet.sk:/pub/solaris/inn1.4sec-src+bin.tar.gz)

  INN works with Solaris 2.[0123]. It's not easy, but it will work.
  The problem is that depending on which Solaris patches you have installed, you have to install various INN patches. There are too many combinations of Sun patches and INN patches to be able to say what is required and what isn't. (See the "SOLARIS 2.3" tip above for one tried and tested configuration).

  Here is the general guide:

  Step 1: Use the info for config.data for Solaris 2.x that is included

      	Install.ms.

  Step 2: As you go, if you get any of the problems listed below, try

      	the fix listed.

  Eventually you will be up and running with only the fixes you need. If you try to install ALL the fixes at once, things will definitely not work.

  COMPILER TIPS: Use gcc or /opt/SUNWspro/bin/cc. Do *not* use /usr/ucb/cc. In fact, remove /usr/ucb from your path when you compile.

  For directory structure - be careful about /var/news, as the news(1) tool also writes in this area an might damage your files. (Need more input on this).

  The patch program supplied with Solaris 2.5 appears to not understand the "new-style" context diffs which virtually everyone uses these days so you have to fetch the gnu-patch as described in part8 of this FAQ. Also it doesn't know -p0 option ; it wants -p 0 and the file to patch has to be writable.

  ---------- Solaris Fix #1

  Under Solaris 2.[012] (SunOS 5.0, 5.1, 5.2) you must add the following at the beginning of each file using gethostbyname():

      #define gethostbyname __switch_gethostbyname

  Under Solaris 2.3 gethostbyname() might work without changes depending on your configuration. We haven't figured out when they work and when they don't. If you run into problems, try to change "gethostbyname()" to "solaris_gethostbyname()" and then use the gethostbyname() listed in the Solaris Porting FAQ. This isn't a perfect solution, because you now need a different binary for Solaris 2.[012] systems.

  It also seems to be a good idea to put dns in front of nis in /etc/nsswitch.conf

  hosts: dns nis files

  It would be great if someone were to submit a solaris_gethostbyname() function who's binary works under all Solaris revs and gives all the semantics of BSD gethostbyname(). In particular, one that doesn't have the problems discussed in sun bugid #1126573 or #1135988. It would be amazing if this was submitted by one of the many Sun employees that flame the INN FAQ maintainer in comp.sys.sun.admin every time he bitches about how much he hates Solaris 2.x. :-)

  ---------- Solaris Fix #2

  Under all Solaris 2.* versions there is a problem with innwatch.ctl.
  It expects to use "df -i" to find out how many inodes are free on your disk. /usr/{sbin,5bin,bin}/df doesn't support the "-i" option, it has a "-e" option that outputs the info you want, but in a different format. You should use "/usr/ucb/df -i" instead, since this version of df includes the "-i" option.

  If you have too much space left on your disks (;-)) you will see the following:

  `Filesystem iused ifree %iused Mounted on` `/dev/md/dsk/d10 103495213433720 7% /var/spool/news`

  So awk will print 7% as number of free inodes ...

  Ian Dickinson <idickins@fore.com> wrote a inndf which can be found at the usual place. This inndf compiled with gcc and -DHAVE_STATVFS seems to work though (after Nash E. Foster <nef10958@usln1b.glaxo.com> ).
  A new version of this is available which works with large filesystems is available from ftp://ftp.csv.warwick.ac.uk/pub/usenet/inn/inndf.tar.gz

  If you have your news spool NFS mounted from another box, which is absolutely not recommended (see 5.15 , ME cant nonblock), then the following might help: rsh other_box /usr/ucb/df -u /var/spool/news

  /usr/ucb/df is part of the BSD Compatibility stuff. If you loaded Solaris 2.x without that, you can replace innwatch.ctl's disk checks with these lines:

      ##  If load is OK, check space (and inodes) on various filesystems
      ##  =()<!!! /usr/bin/df -k . | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_SPOOLSPACE>@ ! throttle ! No space (spool)>()=
      !!! /usr/bin/df -k . | awk 'NR == 2 { print $4 }' ! lt ! 8000 ! throttle ! No space (spool)
      ##  =()<!!! /usr/bin/df -k @<_PATH_BATCHDIR>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_BATCHSPACE>@ ! throttle ! No space (newsq)>()=
      !!! /usr/bin/df -k /news2/spool/out.going | awk 'NR == 2 { print $4 }' ! lt ! 800 ! throttle ! No space (newsq)
      ##  =()<!!! /usr/bin/df -k @<_PATH_NEWSLIB>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_LIBSPACE>@ ! throttle ! No space (newslib)>()=
      !!! /usr/bin/df -k /news2/privcontrol | awk 'NR == 2 { print $4 }' ! lt ! 40000 ! throttle ! No space (newslib)
      ##  =()<!!! /usr/bin/df -k @<_PATH_OVERVIEWDIR>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_OVERVIEWSPACE>@ ! throttle ! No space (overview)>()=
      !!! /usr/bin/df -k /news3/overview | awk 'NR == 2 { print $4 }' ! lt ! 6000 ! throttle ! No space (overview)
      ##  =()<!!! /usr/bin/df -e . | awk 'NR == 2 { print $2 }' ! lt ! @<INNWATCH_SPOOLNODES>@ ! throttle ! No space (spool inodes)>()=
      !!! /usr/bin/df -e . | awk 'NR == 2 { print $2 }' ! lt ! 200 ! throttle ! No space (spool inodes)

  ---------- Solaris fix #3

  Don't run the "lint" step if you use Solaris. In fact, nobody needs to execute this step except Rich, when he's writing new code. If you have a Solaris machine without "lint", just make "lint" a symlink to "/bin/echo".

  ---------- Solaris fix #4

  People running Solaris 2.3 have built INN with HAVE_UNIX_DOMAIN set to TRUE and everything seems to be ok. I guess Sun has fixed enough bugs in 2.3 to make it usable. I recommend the latest "recommended patches" if you run any version of Solaris 2.x. To install all of the "Recommended Patches" in one command, refer to:
  ftp://sunsolve1.sun.com/pub/patches/patches.html

  ---------- Solaris fix #5

  If "inews" outputs "Bad Message-ID" when posting Under Solaris 2.x (where x = 0, 1, 2 or 3) you need to change the file "getfqdn.c". Find the lines that read:

      	if (strchr(hp->h_name, '.') == NULL) {
      		/* Try to force DNS lookup if NIS/whatever gets in the way. */
      		(void)strncpy(temp, buff, sizeof buff);
      		(void)strcat(temp, ".");
      		hp = gethostbyname(temp);
      	}

  and delete them.

  ---------- Solaris fix #6

  If posting gets you "441 Can't generate Message-ID, Error 0" and you are running with DNS, then the problem is with Solaris 2.3's gethostbyname. dns. If you ask for a host with "hostname." it returns "hostname." instead "hostname.yourdomain.com" as expected by nn. The workaround is to define "domain" in your inn.conf and apply the following patch to getfqdn.c:

  `*** getfqdn.c.~1~ Sun Sep 4 09:02:37 1994` `--- getfqdn.c Sun Sep 4 09:53:11 1994` ***************
  *** 35,45 ****

            if ((hp = gethostbyname(buff)) == NULL)
              return NULL;

  `! if (strchr(hp->h_name, '.') == NULL) {` `! /* Try to force DNS lookup if NIS/whatever gets in the way. */` `! (void)strncpy(temp, buff, sizeof buff);` `! (void)strcat(temp, ".");` `! hp = gethostbyname(temp);` `! }` `! if (hp != NULL && strchr(hp->h_name, '.') != NULL) {`

              if (strlen(hp->h_name) < sizeof buff - 1)
                  return strcpy(buff, hp->h_name);

  --- 35,39 ----

            if ((hp = gethostbyname(buff)) == NULL)
              return NULL;

  `! if (strchr(hp->h_name, '.') != NULL) {`

              if (strlen(hp->h_name) < sizeof buff - 1)
                  return strcpy(buff, hp->h_name);

  ---------- Solaris fix #7

  From Ian Dickinson <ian@fore.com>:
  Sun appear to reduced the frequency of the problem, but not fixed the bug itself. I still need this under SunOS5.4 101945-29. You should already have -DSUNOS5 in your DEFS setting in config.data anyway.
  (Note that in 1.5.x this workaround is already in the source. You can enable with with specifying -DPOLL_BUG in the DEFS settings in config.data. Thanks to rhaskins@shiva.com who pointed that out).

  This should apply - maybe with a bit of fuzz:

  `*** innd/chan.c.ORIG Wed Dec 14 11:03:16 1994` --- innd/chan.c Thu Dec 15 17:00:54 1994 ***************
  *** 497,502 ****
  --- 497,508 ----

            bp->Left = bp->Size - bp->Used;
            i = read(cp->fd, &bp->Data[bp->Used], bp->Left - 1);
            if (i < 0) {

  + #ifdef SUNOS5 `+ /* return of -2 indicates EAGAIN, for SUNOS5.4 poll() bug workaround */` `+ if (errno == EAGAIN) {` `+ return -2;` `+ }` + #endif

              syslog(L_ERROR, "%s cant read %m", p);
              return -1;
            }

  `*** innd/nc.c.ORIG Thu Mar 18 21:04:28 1993` `--- innd/nc.c Thu Dec 15 17:00:41 1994` ***************
  *** 783,788 ****
  --- 783,794 ----

            /* Read any data that's there; ignore errors (retry next time it's our
             * turn) and if we got nothing, then it's EOF so mark it closed. */
            if ((i = CHANreadtext(cp)) < 0) {

  + #ifdef SUNOS5 `+ /* return of -2 indicates EAGAIN, for SUNOS5.4 poll() bug workaround */` `+ if (i == -2) {` `+ return;` `+ }` + #endif

              if (cp->BadReads++ >= BAD_IO_COUNT) {
                  if (NCcount > 0)
                      NCcount--;

  ---------- Solaris fix #8

  From: Joe St Sauver <joe@decoy.uoregon.edu>

  We recently upgraded some machines in our news farm to fast ethernet, and after doing so we noticed poor performance (ping times of 30msec between two machines each connected to dedicated switch ports on the same switch...).

  Poking around a little, we noticed that under Solaris 2.5, tcp_conn_req_max is set to 32 by default, which is a little low if you are working with a fair number of peers or have a lot of readers. We bumped that value to 1000 or so (1024 max under Solaris 2.5), using:

      # ndd -set /dev/tcp tcp_conn_req_max 1000

  and now ping times are back into the 0 or 1 msec reported range you'd hope to see from that sort of topology. :-)

  Go to the table of contents

  Subject: (2.15) Slackware Tips

  Slackware comes with The Reference Implementation of NNTP as well as INN. However, if you select "INN" it doesn't remove the nntp entry in your /etc/inetd.conf. If the Slackware people aren't sure why INN requires you to remove that line from /etc/inetd.conf, they should get out of the business. (oh, they can complain to tal@plts.org... he wrote this paragraph).

  Go to the table of contents

  Subject: (2.16) BSDi 2.0 / FreeBSD / NetBSD

  Paul Vixie <paul@vix.com> wrote that for BSDi 2.0the use of mmap for use with the history file is ok (add -DMMAP to DBZCFLAGS in config.data), but not for active, so set ACT_STYLE to READ. Others write that it is not. Your mileage may vary and depend on how heavily-used your machine is.

  For NetBSD1.0 and 1.1 one shouldn't use mmap() unless you add the following:

  *** icd.c.orig Wed Jun 7 15:04:05 1995 `--- icd.c Sat Dec 30 16:22:50 1995` ***************
  *** 369,375 ****

        ICDwriteactive()
        {
        #if   defined(ACT_MMAP)

  `! /* No-op. */`

        #else

  --- 369,375 ----

        ICDwriteactive()
        {
        #if   defined(ACT_MMAP)

  `! msync(ICDactpointer, 0);`

        #else

  In NetBSD 1.1 the use of -DMMAP is also ok.(after Curt Sampson <curt@portal.ca>)

  FreeBSD users should use mmap() with caution. There are serious problems with some realeases of the FreeBSD operating system concerning mmap() and the performance without is quite good. With current releases, namely 2.2.1, this seems fixed.

  Users of 4.4 BSD derived systems should set LSEEKVAL in config.data to ``off_t'' in order to reflect the 64bit long off_t's in those systems.

  If you have problems with makehistory on BSDi then replace the BSDi sort command with an other one e.g. from the gnu textutils package. It seems that the BSDi one has some problems with 64kB boundaries.

  BSDi has a default some datasize limits which will let some operations fail. Add the following at the beginning of rc.news (and also of news.daily):

  limit datasize unlimited limit openfiles 256 limit memoryuse unlimited limit maxproc unlimited

  If this still fails look at 5.24 (the same applies to FreeBSD).

  In 2.1, BSDi introduced a bug with wrong spelling of ``february'' somewhere which lets inn fail somehow .. But they also have a patch:

  ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-002

  Here's the Summary from the fix:

          This patch fixes a bug in the BSD/OS 2.1 release of the inn
          programs.  A fix that we made between the 2.0 and 2.1
          releases introduced a bug that caused innd to incorrectly
          parse dates.  The symptom is that inn programs fail with
          "437 Bad "Date" header" in the /var/log/news/news file, or
          that Pnews will fail with "441 Can't parse "Date" header"
          messages.

  For FreeBSD 2.1.6 and INN1.5 Vincent Archer <archer@frmug.org> has written a autoconf package, that you can get from <ftp://ftp.frmug.org/pub/news/autoconf-inn.1.5.tar.gz> James will try to incorporate this into the main INN tree.

  To get it to work:

  Go to your inn 1.5 source directory, untar, you'll get configure and config/config.data.in.

  Type ./configure; make; make install :) (well, you might want to check the pathnames and parameters first, or type

       ./configure --help)

  Go to the table of contents

  Subject: (2.17) 3Com Router users

  If you observe strange behavior, like nnrpd locking and not sending some articles to the clients, and if you find no clues about other potential problems, then check your IP layer: some users have observed bugs in the IP implementation of 3Com routers caused TCP sessions lock outs. You have very probably also NFS problems then.
  Upgrading to the latest PROMs fixes this totally bizarre problem.

  Go to the table of contents

  Subject: (2.18) NOV problems on a Pyramid

  This applies only to Pyramid systems that run OSx. Newer systems run DC/OSx and/or Sinix 5.43 which are "normal" SysV that have normal cronjobs.

  Q: I just turned on the overview stuff and I don't think news.daily is properly expiring the .overview files. I'm using a Pyramid.

  A: Do you need quotes in your crontab entry? Look at your news.daily report -- expire using "expireover delayrm" should take a few minutes.
  If it takes longer than, say, 10-20 minutes, then the keywords aren't being seen by news.daily so perhaps the commandline quoting is wrong.

  i.e. you had:

      	su news -c /usr/lib/news/bin/news.daily delayrm expireover

  You should have:

      	su news -c "/usr/lib/news/bin/news.daily delayrm expireover"

  Without quoting, the options are thrown away and only the "news.daily" is executed.

  Go to the table of contents

  Subject: (2.19) Warnings to people that must set HAVE_UNIX_DOMAIN to DONT

  Disclaimer: First of all, if you have to set HAVE_UNIX_DOMAIN to DONT, YOU HAVE TO SET IT to DONT. It's not a choice you can make, it's a description of the operating system that you've purchased. If you've wrongly set this variable to DO your system isn't going to work *at*
  *all*.

  When you use POST (the NNTP command), you are talking to nnrpd. nnrpd cleans up your headers, adds the missing headers that it is allowed to add, checks whatever it checks, and then submits the finalized version to innd. How does it talk to innd?

  If you have HAVE_UNIX_DOMAIN set to DO, nnrpd opens a Unix domain socket and sends the text. At this point it is talking to innd somewhat like ctlinnd does. innd can trust that the post isn't forged since it is coming from a program trustworthy enough to get to the socket (which isn't much).

  If you have HAVE_UNIX_DOMAIN set to DONT, it has no choice but to open a socket to port 119, issue the "IHAVE" command, and send the text that way (just like a remote newsreader). This means that innd (not another nnrpd) has to be at the other end of the pipe. If it opens the connection and sees a "nnrpd" you're hosed and you get "441 480 Transfer permission denied". (Better the "441 480" message than an infinite loop of nnrpd's connecting to nnrpd's!) To get innd to not hand off the connection to a nnrpd process, you must have the host's name in the hosts.nntp file. (don't forget to do "ctlinnd reload hosts.nntp")

  If you have your host's name in the hosts.nntp file, then any newsreader running on your nntphost must be "INN-aware" (i.e. that they issue the "mode reader" command) or they must read news via the file system instead of NNTP.

  If you have NNTP-based newsreaders that can't send the "mode reader" command, you can try including "server: localhost" in your inn.conf file, but then you must have a different inn.conf file for the other machines. If you can't do that, you have no other options but to recompile your newsreaders.

  Remember, if you change your inn.conf file, you must shutdown and restart innd. There is no "ctlinnd reload inn.conf" command.

  There is a patch which is listed in the unoff3/UNOFF-NOTES that seems to work at least for linux but should theoretically work for other os that have to set HAVE_UNIX_DOMAIN to DONT which resolves the problem that multiple invocations of ctlinnd break.

  Go to the table of contents

  Subject: (2.20) INN for SNI RM400

  There seems to be no working config.data available for that hardware, but you can get a ported version of INN from SNI in the ``NetServe'' package.
  If anyone has a working configuration and tips how to get there, then mail the FAQ maintainer for inclusion in part9 ..

  Go to the table of contents

  Subject: (2.21) INN on NeXT-/OpenStep

  Scott Anguish <sanguish@digifix.com> has made his tips of configuring INN on NeXT-/OpenStep available on

  http://www.stepwise.com/Resources/Software/inn_1.5.1_configuration.html

  Continue with Part 3...