Serving news (2.206.4)

Candidates should be able to install and configure news servers using inn. This objective includes customizing and monitoring served newsgroups.

Key files, terms and utilities include:

innd

Internet News

From the README file in the INN distribution:

INN (InterNetNews), originally written by Rich Salz, is an extremely flexible and configurable Usenet / netnews news server. For a complete description of the protocols behind Usenet and netnews, see RFC 1036 and RFC 977. In brief, netnews is a set of protocols for exchanging messages between a decentralized network of news servers. News articles are organized into newsgroups, which are themselves organized into hierarchies. Each individual news server stores locally all articles it has received for a given newsgroup, making access to stored articles extremely fast. Netnews does not require any central server; instead, each news server passes along articles it receives to all of the news servers it peers with, those servers pass the articles along to their peers, and so on, resulting in flood fill propagation of news articles.

A news server performs three basic functions: It accepts articles from other servers and stores them on disk, sends articles it has received out to other servers and offers stored news articles to readers on demand. It additionally has to perform some periodic maintenance tasks, such as deleting older articles to make room for new ones.

Originally, a news server would just store all of the news articles it had received in a filesystem. Users could then read news by reading the article files on disk (or more commonly using news reading software that did this efficiently). These days, news servers are almost always stand-alone systems and news reading is supported via network connections. A user who wants to read a newsgroup opens that newsgroup in their newsreader software, which opens a network connection to the news server and sends requests for articles and related information. The protocol that a newsreader uses to talk to a news server and that a news server uses to talk to another news server over TCP/IP is called NNTP (Network News Transport Protocol).

INN supports accepting articles via either NNTP connections or via UUCP. innd, the heart of INN, handles NNTP feeding connections directly; UUCP newsfeeds use rnews (included in INN) to hand articles off to innd. Other parts of INN handle feeding articles out to other news servers, most commonly innfeed (for real-time outgoing feeds) or nntpsend and innxmit (used to send batches of news created by innd to a remote site via TCP/IP). INN can also handle outgoing UUCP feeds.

The part of INN that handles connections from newsreaders is nnrpd.

Also included in INN are a wide variety of supporting programs to handle periodic maintenance and recovery from crashes, process special control messages, maintain the list of active newsgroups, and generate and record a staggering variety of statistics and summary information on the usage and performance of the server.

INN also supports an extremely powerful filtering system that allows the server administrator to reject unwanted articles (such as spam and other abuses of Usenet).

Installing INN

Installing INN is not very difficult. Either download a pre-compiled binary from your favorite distribution, or download the source and compile it yourself. When compiling from source, you can probably do:

./configure --with-perl
make
make install

Read the INSTALL file to make sure this is what you want.

The difficult part is, of course, to configure INN.

Configuring INN

For the purpose of this exam preparation, we will assume that we need a stand-alone server (as opposed to distributed architectures) with a traditional spool directory. For more information on this and other configurations see Samsonova00.

Start by editing inn.conf. This file is a series of key-value pairs, one per line. First the key, followed by a colon and one or more whitespace characters and the value itself.

The standard file from the distribution is well documented, with reasonable default values. For more information on options in this file, consult the inn.conf manual page.

For our stand-alone configuration, make sure nnrpdposthost is set to nothing so the server knows that articles should be posted locally

Creating News Groups

Active news groups are listed in the ~news/db/active file (could be located in /var/lib/news). Editing this file by hand is not recommended, because of the rather strict syntax.

You can use ctlinnd to create news groups, but only when INN is running. INN will not run unless there are news groups in the active file.

To solve this chicken and egg problem, create an active file with two mandatory groups:

control 0000000000 0000000001 y
junk 0000000000 0000000001 y

Also create active.times in the same directory:

touch active.times

Make sure this file is owned by user news and group news.

If INN was installed from a DEB or RPM packet, there may already be default active and active.times files.

Now when you start INN, you can add newsgroups with the ctlinnd command:

ctlinnd newgroup <group> <flags> <creator>

where:

<group>

The name of the newsgroup. If the newsgroup already exists, this command will act as the changegroup command, changing the flags and/or the creator.

<flags>

Possible plags include:

y Local posting is allowed
n No local posting is allowed, only remote ones
m The group is moderated and all postings must be approved
j Articles in this group are not kept, but only passed on
x Articles cannot be posted to this newsgroup

<creator>

The name of the person creating the newsgroup. Can be omitted and will default to the newsmaster.

If you want to create a local group that can be used for testing purposes, you would issue the following command:

ctlinnd newgroup local.testing y ben

This will create a newsgroup called local.testing which accepts local posting.

Newsfeeds

Before we begin, it is worth mentioning the so-called wildmat pattern-matching syntax used in many configuration files. These are simple wildcard matches using the asterisk (*) as the wildcard character, much like the simple wildcard expansion used by Unix shells.

In many cases, wildmat patterns can be specified in a comma-separated list to indicate a list of newsgroups. When used in this fashion, each pattern is checked in turn to see if it matches, and the last pattern in the line that matches the group name is used. Patterns beginning with ! designate groups to exclude based on the pattern match. For example:

comp.*, !comp.os.*, comp.os.linux.*

In this case, we will match everything under comp (comp.*), except groups under comp.os (!comp.os.*) unless they are under the comp.os.linux hierarchy (comp.os.linux.*).

Incoming newsfeeds are configured in incoming.conf. This file should at least contain a default number of max-connections and peer ME, which is the entry for the localhost. Without this entry articles will not appear in your spool.

An example incoming.conf file with a newsfeed from your upstream ISP for the comp.* newsgroups will look like this:

max-connections:    8      # per feed

peer ME {
  hostname:         "localhost, 127.0.0.1"
}

peer isp {
  hostname:         news.isp.com
  # accept the comp newsgroups from this host
  patterns:         comp.*
}

If you want to send the local postings to the comp.* newsgroups back to the upstream ISP, you have to set up an outgoing feed in newsfeeds:

news.isp.com:comp.*:Tf:news.isp.com

The flag Tf specifies that a file should be written. The name of the file must be unique, and defaults to the hostname of the feed (news.isp.com). Note that this only specifies that a log entry should be written in a file. A separate program, innfeed, will use this file to do the actual feed. This means that innfeed should be configured to read the file and send the articles to the peer. This is done by adding the following entry to the innfeed.conf file:

peer isp {
  hostname:         news.isp.com
}

Copyright Snow B.V. The Netherlands