🚀 go-pugleaf

> > On another note, INN *must* have more going for it than just what
> > is described above. What other reasons might make it worthwhile to
> > switch to INN.

> Lots.

   Matthias lists some of the advantages on INN.  Well, we're a UUCP
site and we just switched from C News (pre Performance Release) to INN
1.2, so I thought I'd offer some comments on how the two systems
compare from the point of view of a site which only has UUCP feeds.
We had been running C News for over a year, and it's been quite
reliable.  We've had INN test systems up for a couple of months, and
just put it into "production" a few days ago.

   If I've made any errors herein, I have complete faith that the fine
folks on the net will energetically make corrections.  :-)

   First, I should mention that all internal newsreading and posting
here is done via NNTP.  This is an important consideration when
deciding which software to run.  If you wish to use NNTP internally,
then with C News you have to also install the standard NNTP package.
This may or may not be a negative for you.  Since NNTP support is
integral to INN, you get it all in one package.

   Also, our news machine has lots of memory.  This is fairly
important for INN.   

   The biggest motivator for switching for us was synchronous posting.
With the C News Performance Release, local posts are queued up to be
posted later, and there is a case where an article can be dropped
altogether without warning.  With older versions of C News, your
posting program would be blocked for some possibly extensive period of
time if there was a news processing run underway when you tried to
post.  INN has none of these problems.  Posts are fast and immediate.
This makes users happy.

   As you know, INN was designed for a site receiving NNTP feeds over
the Internet, and for that it's said to be far more efficient than C
News and standard NNTP together.  For a UUCP site, the efficiency
advantages aren't that clear.  For our setup, INN appears to be
approximately as fast as C News.  I haven't done any real
measurements, but INN doesn't "feel" any faster when processing lots
of news batches.  Expiration seems to be about twice as fast, though.

   You have less control over when incoming news is processed with
INN.  Specifically, there is no equivalent to "newsrunning off".  Rich
has mentioned to me in E-mail that such a feature may be forthcoming
in a future release.  Another difference is that in C News, the rnews
program simply copies incoming batches into an intermediate directory
(in.coming), from which they are later processed.  In INN, rnews
uncompresses the batches and hands each article to the main daemon
(innd) for processing.  This has both advantages and disadvantages.
The obvious advantage is that INN avoids extra disk activity by not
copying the batch (in fact, INN avoids a second copy, as C News
uncompresses a batch in place before processing it, whereas INN rnews
uncompresses over a pipe).  The disadvantage is that batch processing
ties up your UUCP processing (via uuxqt), such that queued mail jobs
may have to wait until news processing is finished.  Running multiple
uuxqt's might help out somewhat.  This probably isn't a significant
disadvantage. 

   INN's biggest weakness for a UUCP site is outgoing batching.
Helpful scripts are provided, but not like the easy to configure and
extend C News batching subsystem.  This is an area that will likely
see some improvements with future releases.

   Fortunately, you have a couple of options available to you now.
Christophe Wolfhugel <Christophe.Wolfhugel@grasp1.univ-lyon1.fr> has
created a C News-like batching subsystem that you can use with INN.
The option we chose was to use newsxd, a daemon which can control news
batching (and be sensitive to system load), by Chris Myers
<chris@wugate.wustl.edu>.  newsxd is highly configurable, and it
didn't take much effort to get it working with the sendbatch script
that comes with INN.

   I've had very few problems with INN.  One problem that cropped up
at one point (but that has since vanished - odd) is an occasional
crash of the innd daemon.  This is rather serious, as it prevents
users from reading news via NNTP.  The easy solution is to write a
wrapper script that restarts innd should it fail.  I haven't seen a
failure in almost two months now, though.

   All in all, this INN administrator is a happy camper, and our users
are happy, too.  (So I owe Rich a post card - haven't found a good one
yet.)


--
David Myers                                             (513) 865-1343   
Mead Data Central           No news is             Fabrication Systems
P.O. Box 933                 bad news.                dem@meaddata.com
Dayton, Ohio  45401                             ...!uunet!meaddata!dem