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 |
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 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.
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
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:
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.
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 |
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.
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
}