In the early days of the Internet, newsgroups were a hugely popular way of sharing information to a wide audience, and also helped early collaboration between developers and users. In fact, the existence of Linux was first announced to a newsgroup by Linus Torvalds back in 1994.
Nowadays, collaboration has moved onto websites with tools such as Wikis and web forums becoming more popular. However, there are still reasons why you would use newsgroups, or, to give it its proper title, network news. If you are responsible for providing information to a wide range of people, you might find that deploying your own local news server could be beneficial.
Although fairly mature in their development, news servers are typically complicated to configure. This chapter will give you information on how to get started and what common pitfalls to avoid.
The InterNetNews (INN) package is the most popular news server software on UNIX servers. The Internet Software Consortium (ISC) currently maintains it, along with the INN website (http://www.isc.org/products/INN/). Fedora includes the INN package as a standard RPM file, although you have to use the custom installation if you want INN installed by default.
The following sections take you through the whole process of installing InterNetNews, including an overview of the package, things to think about when installing and configuring, and also some tips to help you avoid some of the sand traps that InterNetNews can land you in. Some of the information does get quite detailed because news servers present some unique challenges.
If you are an average home user, you probably will never need to configure a news server because you would be well catered for by your own ISP. However, system administrators at larger companies and ISPs, read on!
You can use a number of methods to implement a news server on a network, and the way you intend to use the news server determines how you must configure it. The following sections describe three of the most popular types of news servers on local networks: full newsfeed servers, leaf node servers, and local news servers.
A full newsfeed server receives all the available Usenet newsgroup postings from an upstream news server (a large, commercial server). Because it receives all the newsgroups, a full newsfeed server can itself serve as an upstream news server for other sites and provide newsfeeds to other servers. The other servers themselves might or might not subscribe to all the newsgroups. In addition to providing newsfeeds for other sites, a full newsfeed news server can also support newsreader clients that connect to the news server to read and post articles to newsgroups.
Each news server receives newsfeeds and forwards postings to one or more remote news servers. The full newsfeed server must have enough storage capacity to maintain the newsfeeds for all the newsgroups it services. If the remote news servers do not connect to download their newsfeeds on a daily basis, the newsfeed server must be capable of maintaining all the newsfeeds for the intervening days. This can require a very large amount of data storage capacity beyond the capabilities of systems that are common among home users and many businesses.
The other important factor to remember is bandwidth. Although news is mainly made up of text information, the fact is that there is a huge amount of it. Be very aware of the amount of data that is involved; if your Internet connection suddenly seem sluggish, you can bet that the traffic from the newsfeeds is slowing things down.
A leaf node server receives newsfeeds only from upstream news servers: It does not feed other news servers. This is the most common configuration for corporate news servers. Because the leaf node server does not have to feed other news servers, it does not have to retrieve all the newsgroups from its upstream newsfeed. You can pick and choose which newsgroups the news server retrieves from the newsfeed. The main role of the leaf node news server is to provide news services to newsreader clients.
The leaf node does, however, have to maintain a system for users to connect to the news server to read and post messages. This is often done using UNIX, Windows, or Mac OS software. Each client must connect to the leaf node to download articles from specific newsgroups, and it must upload postings made to the newsgroups. The leaf node must be capable of forwarding new postings to the newsfeed server.
An organization that does not want to participate in the worldwide Usenet newsgroups still might want to use Usenet software to create its own news server to handle internal communications within the organization. Usually these communications need to remain private to the organization and do not need to be sent to all the Usenet newsfeed hosts around the world. This is likely the most common use of a news server you might be asked to configure.
Two methods are used to implement a local news server. An organization might create a standalone news server that does not receive any newsfeeds from Usenet servers. The server contains only local newsgroups that are used for internal corporate communications. Alternatively, on a Usenet news server you can create local newsgroups that are not forwarded through any newsfeeds in the Usenet system. This enables organizations to create their own local newsgroups that their employees can participate in without sharing their information with the rest of the world.
Thus, local newsgroups can be created on news servers that either are not connected to the Usenet network or that are connected to the Usenet network but do not forward the local groups to their upstream newsfeeds. Any postings to the local newsgroups appear only on the local news server. The Usenet news servers enable clients to post articles to both the local and Usenet newsgroups. However, only the articles posted to Usenet newsgroups are forwarded to the upstream news server. The local articles remain on only the local news server.
The INN package (which is formed around the innd
daemon) contains many executable programs and configuration files that enable the Fedora server to work as a network news server. The standard INN RPM package contains all the files necessary for the installation. Table 29.1 describes some of the INN programs included in the distribution, in the order in which you will find them in the file.
Table 29.1. INN Package Program Files
Program File | Description |
---|---|
| Allows the user to manually send control messages to the |
| Obtains a list of newsgroups from a news server |
| Queries the history database files for a specific message ID value and returns the record information |
| Examines INN configuration files and databases |
| Prints the values of parameters that are specified in the |
| Handles all incoming newsfeeds and spawns INN programs as necessary |
| Starts the |
| Summarizes INN log files into readable reports |
| Prints a snapshot of the current status of the INN system |
| Monitors the running INN system and, if necessary, throttles the newsfeeds to help reduce the load on the news server |
| Manually sends a mail message into a specified newsgroup |
| Creates binary indexed database files from the history file |
| Creates a text history file of message IDs seen by the news server |
| Runs as a |
| Communicates with newsreaders via the |
| Connects to a remote news server and retrieves articles that are specified on the standard input |
| Connects to a remote news server and posts articles to newsgroups |
| Attempts to repair a damaged INN database file |
| Attempts to upgrade an existing INN database file |
| Removes specific filenames from the history file |
| Retrieves newsgroup articles from one news server and forwards them to another news server |
| Receives newsgroup articles from a news server by using a UUCP connection |
| Summarizes information in the INN log files and performs general cleaning and rotating of the log files |
| Provides a command-line interface to the article storage manager |
As you can see in Table 29.1, a number of the INN programs are used to help facilitate the news process on the server. The INN package also contains a number of configuration files that define how articles are handled. Table 29.2 lists and describes these files.
Table 29.2. INN Package Configuration Files
Configuration File | Description |
---|---|
| Specifies how control messages are handled |
| Specifies how articles are expired |
| Specifies addresses and authentication information for servers that send newsfeeds to your news server |
| Acts as the primary general configuration file for the |
| Specifies parameters for the incoming newsfeed handler |
| Determines how the |
| Specifies email addresses for moderators of moderated newsgroups |
| Specifies which information is posted to newsreaders when a |
| Specifies which newsgroups are fed to other news servers from this news server |
| Specifies newsreaders or servers that should have their activity recorded during an NNTP session |
| Specifies remote news servers that your news server feeds articles to in batch mode |
| Specifies passwords used to connect to remote news servers |
| Specifies authorized remote newsreader addresses and newsgroup permissions |
| Specifies file locations for the encryption keys used for the SASL configuration |
| Specifies the storage method used for specific newsgroup articles |
| Specifies a list of newsgroups to which newsreaders can subscribe |
Do not let the long list of configuration files in Table 29.2 worry you; most of the parameters defined in the configuration files work fine with their default settings. Typically, you need to make only a few changes to configure the INN news server to work in your particular network news environment.
To work in your particular network news environment, Fedora uses two separate RPM files to install the INN package. The first package, simply called inn
, installs the configuration and application files needed for the INN package to work on the system. The second package, called inn-devel
, is used to install INN header files some external newsreader programs use to work with innd
. You do not have to install the inn-devel
package for INN, but if you are using other newsreader packages on the server, you should install it. The default INN installation also installs the inews
and cleanfeed
packages, which are used to forward articles to the server and filter out spam.
After all the INN files are installed, you must begin the task of setting the proper parameters in the configuration files (installed in /etc/news
) before you attempt to start the innd
program. When you modify the INN configuration files, you must ensure that you are logged in as the news user or use the su
command to become the news user (note that there is no password for the news user). If the ownership or permissions of any of the INN configuration files change, the innd
package will not start.
Although there are many configuration files, only a handful of files need to be modified for a simple news server. The following sections describe common changes that must be made to the configuration files to make the news server operational.
The /etc/news/inn.conf
file is the heart of the innd
configuration. It defines the core features of the news server operation. Each parameter is listed on a separate line, using the following format:
parameter: value
Many parameters are defined in the inn.conf
file, but fortunately most of them work just fine with their default values. Table 29.3 shows the parameters that should be changed in the innd.conf
file to represent your news server environment.
Table 29.3. innd.conf
Configuration Parameters
Parameter | Description |
---|---|
| The command used to invoke the system MTA mailer. The |
| A text description of your organization. This value is used in the article header lines for all articles posted from your site, so be careful to enter accurate information. |
| The storage method used for the article indexes. The default, |
| The name of the host to place in the |
| The path to the news binaries, which is already set for your Fedora system. |
| The complete domain name of your Internet domain. This parameter is blank until you fill it. |
| The command |
| The name of a default NNTP server. |
| The maximum number of incoming NNTP connections your news server will support, based on your network’s available bandwidth. |
| The domain the INN system uses to construct email addresses. It should be set to your local system address. |
| The email address to which messages posted to moderated newsgroups are sent if there is no corresponding entry in the moderator’s file. |
| How frequently (in seconds) |
| How frequently (in seconds) |
The inn.conf
file is a text file you can modify by using any standard text editor. At a minimum, you should ensure that the organization
, domain
, mailcmd
, mta
, server
, and fromhost
parameters are specified. Listing 29.1 shows sample inn.conf
file entries for a test server.
Example 29.1. Sample inn.conf
Configuration File Entries
mta: /usr/sbin/sendmail -oi -oem %s organization: Internal Newserver ovmethod: tradindexed domain: company.com mailcmd: /usr/bin/innmail status: 3600 timer: 3600
The sample configuration shown uses the standard Sendmail MTA for the mailer and the traditional indexed method for overview databases, and it creates new status reports every hour.
The /etc/news/incoming.conf
fileis used to define the source from which the news server receives its newsfeeds. If you are building a standalone news server that doesn’t receive newsfeeds, this file is still important because it also specifies the local address of the news server.
The incoming.conf
file contains three types of data:
Peer news server definitions
Groups of news server definitions
Parameter value definitions
Parameters can be defined globally, within peer definitions, and within group definitions. As you would expect, parameters defined globally apply to all peers and groups defined in the configuration file. Parameters defined within group definitions apply to all peers within the group definition and override any global definitions of the same parameter. Finally, parameters defined within peer definitions apply only to the peer, and they override any group or global definitions of the same parameter.
Ten parameters can be used to define the connection with a remote news server. In the case of a local news server only, you would not be accessing any incoming feeds, so the incoming.conf
file can remain unmodified. In addition, the innfeed.conf
file that defines communication with peer news servers can remain unmodified, as can the incoming.conf
file because no newsfeeds will be received.
Another important configuration file used by innd
is the /etc/news/storage.conf
file. This file tells the innd
program how to store newsgroup articles on the news server. Fedora suggests two methods for storing articles on the news server:
Time hashed spool—. The time hashed spool method (timehash
) stores articles on the news server by creating directories based on the arrival time of the articles. This creates more directories with fewer articles in each directory. Using timehash
requires additional overhead for reading articles, however, because it is more difficult for the news server to find an individual article stored in this method.
Cyclic buffer spool—. The cyclic spool (cnfs
) method speeds up the process of storing articles by using a preconfigured file buffer. As articles are received, they are placed in a preconfigured file of a set size. This greatly speeds up processing because no new files are created as articles are received.
Using cnfs
does have a drawback, however. The buffer files are created at a set size, so when the articles fill up a buffer file, the file is overwritten, starting from the beginning. This method, therefore, forces an automatic expiration of articles on the news server. Although using a set buffer file size prevents the server from running out of disk space, it can cause premature article expiration, depending on the size of the buffer file. Most news administrators who use this method learn by trial and error the buffer file size necessary to handle the standard news traffic load at their sites.
If a newsgroup is not covered by a specific storage method, INN does not store the articles received for that newsgroup, and it produces an error message for each article. This can have a devastating effect on the news server. For a simple news server, it is best to select a single method of storage and configure the storage.conf
file to use that method for all the newsgroups.
By default, the Fedora /etc/news/storage.conf
file does not define any default storage method, but it is fully configured and commented out. You must define at least one method to use for INN to work properly; to do so, you can simply uncomment the desired section.
You use the /etc/news/readers.conf
configuration file to define permissions for newsreaders that use your news server. If you are allowing your local users to connect to your news server to read articles, you must configure the readers.conf
file to support them.
The readers.conf
file consists of the following three types of data:
An authentication definition
An access definition
Parameters and values
The authentication definition defines categories of users who will be accessing your news server. You can create several categories of users, based on various factors, such as remote address, newsgroups accessed, and type of authentication method used. The syntax of the authentication section is as follows:
auth name { hosts: hostlist auth: auth-program res: res-program default: defuser default-domain: defdomain }
The name
value is used as a label to uniquely identify the authentication definition. The authentication definition uses parameters and values to identify its actions. The hosts
parameter uses the hostlist
value to identify individual remote hosts covered by the authentication definition. These can be listed by using either hostnames or numeric IP addresses, along with matching wildcard characters.
You can use the res
parameter to specify an authentication program used to authenticate the connection based on its network information. Alternatively, you can use the auth
parameter to specify an authentication program that can authenticate the connection by using a user ID/password pair. If you are interested in authenticating remote news servers, you should consult the INN documentation because it is a somewhat complicated process.
The access definition defines categories of access restrictions and permissions for groups of newsreaders. The syntax of the access definition is as follows:
access name { users: identity-wildmat newsgroups: group-wildmat access: permissions }
The name
value must match a corresponding authentication definition. The parameters defined in the access
definition apply only to the hosts
defined in the corresponding authentication definition. The users
parameter limits the access rules to the specific set of users listed in the value. If the users
parameter is not present, the access rules apply to all users. The newsgroups
parameter defines to which newsgroups the group has access, and the access
parameter defines which access privileges the group has. The privileges are defined as follows:
R
—. Read-only access is allowed.
P
—. Posting articles is allowed.
A
—. Posting approved articles is allowed (using a moderator).
N
—. The NEWNEWS
command is allowed.
L
—. The group is allowed to post to newsgroups that are set to disallow local posting.
Here is a sample readers.conf
file that allows all local newsreaders to read and post articles to all newsgroups:
# readers.conf auth "localhost" hosts: "localhost, 127.0.0.1, 192.168.1.100, stdin" default: "<localhost>" } access "localhost" { users: "<localhost>" newsgroups: "*" access: RPA } auth "localnet" { hosts: "192.168.*" default: "<user>" default-domain: "isp.net" } access "localnet" { users: "*@isp.net" newsgroups: "*" access: "RP }
The sample readers.conf
file shown here defines two separate groups of users. The first group, called localhost
, enables the local host, address 127.0.0.1
, address 192.168.1.100
(the local host’s network address), and any connection using the standard input to connect to the news server. The unmodified readers.conf
file provided by Fedora allows access only from users on the local host.
The second group defines any client located on the 192.168.
network; it allows both reading and posting of all newsgroups to any client on the network. You can adjust these addresses as necessary for your network.
The active
and newsgroups
files, although not specifically identified as configuration files, are crucial to the operation of the news server. These files control which newsgroups your news server can handle. Each newsgroup handled by the news server must have an entry in both the active
and newsgroups
files. Both of these files are located in the /var/lib/news
directory when they are installed by using the Fedora RPM package.
The syntax of the active file is as follows:
newsgroup first last post
Each newsgroup handled by the news server is defined on a separate line in the active file. The default Fedora INN configuration supplies a skeleton active file that defines several special newsgroups:
control 0000000000 0000000001 n control.cancel 0000000000 0000000001 n control.checkgroups 0000000000 0000000001 n control.newgroup 0000000000 0000000001 n control.rmgroup 0000000000 0000000001 n junk 0000000000 0000000001 n
This default file is fine if you are running a standalone news server. The first field of this file defines the newsgroup name. The second and third fields define the first and last article sequence numbers. The final field defines whether posting is allowed for the newsgroup on the news server. The default newsgroups are set to n
to prevent posting.
The control
and control.cancel
newsgroups are used to receive NNTP control articles for performing maintenance on the news server. As remote sites create new newsgroups and delete old ones, control articles are sent to the news servers to perform these tasks. The control series of newsgroups handles these articles. Also, the junk
newsgroup is created to handle articles that have not been posted correctly and have no place to go.
The newsgroups
file is parallel with the active
file; it must contain the same newsgroup definitions as the active
file.
Also in the /var/lib/news
directory are the INN history
files. These files are used to keep a running index of each article posted to each newsgroup. It is crucial that these files not be tampered with because if they get out of sync with the actual newsgroup articles, the news server has problems retrieving articles.
The history
files have two separate parts: a text history
file and a set of binary index
files that are created by using a database program such as the common Berkeley db
package. You must create both sets of files before you can start the innd
daemon.
You use the /var/lib/news/bin/makehistory
command to create the text history
file based on the current newsgroup articles on the server (which should be none). Fedora provides a blank history
file.
After you create the text history
file, you create the binary index
files. You use the /usr/lin/news/bin/makedbz
program to convert the text history
file into the binary index
files. The makedbz -i
command creates the following three separate binary files:
history.n.dir
history.n.index
history.n.hash
You should rename these files to the standard history filenames (history.dir
, history.index
, and history.pag
) so that the innd
program can recognize them. After the history files have been created, you are finally ready to start the news server.
Using the /var/lib/news/bin/inndstart
program is the best way to start the innd
daemon, which in turn starts other INN package programs. The inndstart
program must be run from the news user ID. It starts the innd
program as well as the controlchan
program in background mode.
The innd
program listens for newsfeeds and newsreader requests on the NNTP TCP port. If a remote newsreader establishes a connection, the innd
program spawns the active program to authenticate the remote connection and handle the newsreader requests. If the incoming articles are control articles, they are passed to the controlchan
program for processing.
Fedora has thoughtfully configured the System V files that are necessary for starting the news server; you can use (in an appropriate way) chkconfig
, nytsysv
, service
, or system-config-services
to start the server. (See Chapter 15, “Automating Tasks,” for details.) Here is an example:
# /sbin/service inn start
When the innd
program is running, you can control it by using the ctlinnd
program, with the following syntax:
ctlinnd [ -h ] [ -s ] [ -t timeout] command [ argument...]
The -s
option suppresses any output from the ctlinnd
command. This option is often used in batch programs. The -t
option specifies how long to wait for a response from the server (in seconds). If you are connecting to a server across a slow link or are connecting to a slow server, you can increase the value of timeout
.
The command parameters define which actions the ctlinnd
program should take with the innd
news server. The -h
option prints a summary of all the available command parameters that can be used with ctlinnd
. For now, you can use the newgroup
command to create a new local newsgroup that newsreaders can use to read and send messages:
$ ctlinnd newgroup local.linux.group y [email protected]
The newgroup
command uses three parameters:
The name of the new newsgroup
A flag to define which type of newsgroup to create (y
stands for a regular open group and m
stands for a moderated group)
An email address for the maintainer of the new newsgroup
The ctlinnd
program should be run from the news user ID. If the command is successful, it returns a simple OK message. You can use the ctlinnd
command to check whether the new newsgroup has been added to the news server.
http://www.faqs.org/rfcs/rfc977.html—RFC 977, which is the NNTP protocol.
http://www.faqs.org/rfcs/rfc1036.html—RFC 1036, which is the format of news messages.
http://www.list.org/—The home page for the Mailman mailing list manager.
18.117.138.178