Network News Transfer Protocol (NNTP) is often used for TCP-based newsfeeds. In other words, if you are using a network to connect to a newsfeed, you can use NNTP to download your newsgroups instead of UUCP. Although UUCP users can use NNTP, the C News package is more popular and easier to work with (see Chapter 40, "C News") for UUCP transfers as it leaves off the comlexities NNTP adds. The primary advantage of NNTP-based network newsfeeds is the much higher throughput that can be achieved. UUCP is limited to modem speeds, but NNTP can function over fast local area networks at many megabits per second. This capability allows for larger downloads in the same timespan, which can be important if you receive a lot of newsgroups. NNTP is not a stand-alone package; it requires another news server system to be running. NNTP works with both the older B News (which is seldom available for Linux now) and the better C News (discussed in the next chapter).
This chapter looks at how you can implement NNTP for a local area network news system. Although this chapter doesn't cover every NNTP option and feature, the information presented here should be sufficient to get an NNTP feed working properly. The end of this chapter looks at INN (Internet News), an alternate package for handling news. INN is a complex package capable of supporting very complex networks and news requirements, but it is often overkill for small Linux systems.
NNTP operates in two modes: active and passive. The active mode, often called pushing, is much the same as C News' ihave/sendme protocol in which the sender (server) offers a particular article and waits for the receiver (client) to accept or refuse the article. Pushing has a disadvantage for the server in that it has a high overhead because each article must be checked in turn.
In the passive mode, called pulling, the receiving machine requests a list of all articles in a particular newsgroup that have arrived since a specified date. This request is sent through a newnews command. When the receiving machine has all the articles, it then discards any that are duplicated or not wanted using the article command. This mode is much easier for the sending machine because it simply sends a mass of articles, but the server does have to make sure it sends information that is allowed to pass to the receiver for security's sake.
NNTP is implemented on a Linux system with the NNTP daemon developed by Stan Barber and Phil Lapsley. This daemon is known almost universally as the reference implementation. Usually, you will only have the source code for the NNTP daemon, which is called nntpd, supplied with a Linux distribution because several site-specific details must be linked into the binary. The nntpd system consists of a server program and two different client programs (one for pushing and one for pulling). In addition, most Linux nntpd systems include a replacement for the inews program.
An alternative to nntpd is the INN (InterNet News) package developed by Rich Salz. This package is supplied with many Linux distribution packages. INN allows both UUCP and network-based newsfeeds, but it is really designed for large machines. If you anticipate a lot of newsgroup access, INN may be a better choice than nntpd, although nntpd can handle full newsfeeds almost as well.
When NNTP receives an article from a remote machine, it passes it on to one of the news subsystems that must be in place. Usually, this subsystem is rnews or inews. (You can also use NNTP for batching of articles, as explained in Chapter 40 "C News." In this case, the relaynews program handles the batch of articles.) NNTP uses the /usr/lib/news/history file to properly perform some protocol transfers, so this file must be configured correctly (Chapter 40 explains how to configure this file).
The NNTP server, which is called nntpd or in.nntpd, is usually supplied as source code only, as was previously mentioned. In most cases, you must compile it on your machine to include machine-specific information. To configure nntpd, you use a program usually stored as /usr/lib/news/common/conf.h. You can search for the source files with the command:
find / -name conf.h -print
Run this program (which is a number of macros) and answer all the questions about your system.
Begin the NNTP installation process by creating a directory for nntpd to store incoming articles. You should create this directory as /usr/spool/news/.tmp (or /var/spool/news/.tmp). Set the ownership of the directory to news. The two commands to perform these steps are as follows:
mkdir /usr/spool/news/.tmp chown news.news /usr/spool/news/tmp
You can configure the NNTP server in one of two different modes. The first mode is as a stand-alone daemon, which starts itself from the rc startup files (usually rc.inet2) when the Linux system is booted. Alternatively, you can configure nntpd to be managed through inetd instead of running all the time.
If you are configuring nntpd to run as a stand-alone daemon, make sure that no line in the /etc/inetd.conf file calls the daemon. Alternatively, check the /etc/inetd.conf file for potential conflicts if you start the nntpd daemon in the rc files.
To configure nntpd to run through inetd, which can reduce the overall load on your system except when news must be processed, you need to add an entry to the inetd configuration file. This file is usually stored as /etc/inetd.conf. Add the following line to this file with an ASCII editor:
nntp stream tcp nowait news /usr/etc/in.nntpd nntpd
The inetd.conf file may already have a line like this one commented out. In this case, verify that the line reads the same as the preceding one and remove the comment symbol.
Whether you are configuring nntpd to run as a stand-alone daemon or to be started by inetd, you need to verify that there is a line for the nntp service in the TCP /etc/services file that looks like the following:
nntp 119/tcp readnews untp
This line is commented out when you install most versions of Linux, so remove the comment symbol.
Once the nntpd binaries have been created by running the conf.h file, you can configure the file /usr/lib/news/nntp_access to control which remote machines can use NNTP on your system. The file is organized in a set of lines, one for each remote, using the format
sitename read|xfer|both|no post|no except
where sitename is the name of the remote machine, which can be identified by its sitename, a fully qualified domain name, or the IP address. NNTP allows for partial matches of the domain name and IP address, which are useful for providing multiple lines of information about newsgroups. If the remote machine's name or IP address matches the sitename exactly, only that one line is read (the rest of the file is ignored). If the match is only partial, that line is read, and then the rest of the file is examined to find further matches. If you want to match all remote machines, you can use the sitename default.
The access permissions for the site are defined in the second field. There are four legal values, which have these meanings:
|read||The remote can retrieve articles (pulling).|
|xfer||The remote can send articles (pushing).|
|both||The remote can send and receive articles.|
|no||The remote has no access to articles.|
The third field indicates whether the remote site can post articles. If the keyword post is used, the remote can send articles and the local NNTP system completes the header information. If the keyword no appears in the second or third field, the remote cannot post articles.
The last field identifies any newsgroups that the remote is denied access to. The newsgroups are separated by commas, and an exclamation mark preceds the field (you will see this format frequently in C News). For example, the entry
chatton.bignet.com both post !alt,local
allows the remote machine chatton.bignet.com to send and receive all articles except those in the alt and local newsgroup hierarchies. The remote may also post articles.
Usually, you set up the /usr/lib/news/nntp_access so that there is a default value for all machines, and then add specific entries for machines you want to work with. Look at the following sample /usr/lib/news/nntp_access file:
# default entry default xfer no # allow chatton full access chatton.bignet.com both post # allow brutus to read but not post brutus.bignet.com read no
This file lets any machine other than those explicitly specified transfer articles to your machine but not post articles. The machine called chatton can read and post articles, but brutus can only read articles.
Some versions of NNTP have implemented authorization systems to ensure that your machine does not get fooled into thinking another machine is at the other end of a connection. The authorization system has not been working well for most versions of nntpd and is best left alone at this point. Check future releases of nntpd for more information about the authorization process.
The Internet News (NNT) package is an alternative to NNTP. INN is designed to handle much larger and more complex news systems than NNTP and is therefore not used as much with Linux. However, there is no reason why you can't employ INN instead of NNTP on your Linux system. An INN version is included with most Linux distributions. If you have to support complex mail systems, the INN configuration process can get convoluted. For simpler LAN and stand-alone systems, though, you can easily configure INN for typical usage.
INN's behavior revolves around the server daemon called innd. The innd daemon does more than the nntpd daemon because it allows multiple streams to be handled at once. A different daemon, called nnrpd, handles the newsreader service, and a dedicated copy is spawned for each newsreader client application.
Most Linux distributions (including the Slackware CD-ROM accompanying this book) include the precompiled binaries for INN, so you needn't bother generating the binaries from the source code. If you have to generate the binaries, use the Makefile that builds the application. Check the Makefile and accompanying source file documentation for compilation instructions if you have to compile the code.
Once you have the INN binaries ready, you can follow a straightforward procedure to install the software in the proper locations and with the correct permissions and ownerships. Follow these steps:
After all these steps, INN is ready to start. You can either reboot your machine and let the daemons start from the rc startup files, or execute the daemon directly from the command line.
When the INN software is installed and the directories are ready, you can configure the software. This section assumes you are working with a fairly straightforward installation where you use one or more newsfeeds and handle the news on the downloading machine. More complex installations are certainly possible with INN, but you should read all the documentation to understand the process.
Begin by editing the hosts.nntp file, which lists the newsfeed locations for your system. When a machine connects to the INN daemon, it examines the hosts.nntp file for a match to the connecting machine's IP address or name. If a match is found, INN assumes the machine is feeding news. Otherwise, INN assumes a newsreader wants access and spawns a process (nnrpd) for this function. For this reason, INN must know the IP address or resolvable symbolic name for the newsfeed servers in the hosts.nntp file.
To configure the hosts.nntp file, enter the names of the newsfeed machine or machines. The file contains only the name or IP address, one newsfeed on a line. If you have only a single newsfeed called big_boy, the nntp.hosts file looks like the following:
Note that a colon must follow the name of the newsfeed. Alternatively, you could specify the IP address of big_boy. If you have several newsfeeds, each gets a line of its own. Some systems use a password to log in for newsfeeds. If you need to specify a password, it is included after the colon.
Machines that are connecting to act as newsreaders are listed in the file nnrp.access, which is checked by nnrpd when it is spawned. The machine names that are included in nnrp.access must match what the NNTP system thinks the machine name is, not necessarily what you think it is symbolically (or even by IP address). The best way to verify the machine name is to use the finger command. Whatever name finger displays is the name that must be used in nnrp.access. (Usually, this name matches the symbolic name, but some systems have two different names in use.) The syntax of the nnrp.access file is
where the hostname is the machine name of IP address (wildcards are allowed), permission is Read for read access, Post for post authorization, or RP for both, user is a username used for authentication before posting is allowed, password is a password for authentication, and groups are a pattern of newsgroup names that can be read or not read. If you want to prevent a client from posting, put a space in the user and password field (as they can't be matched). The default settings, if not specified, are no access, no authentication, and no groups, which is written as follows:
*:: -no- : -no- :!*
To add a machine to the nnrp.access file, use the following syntax and set the permissions:
This line lets any machine from the domain tpci.com read and post news in all newsgroups with no authentication process necessary. To create a wide-open system, use the following line:
This line lets anyone read and post. Don't use this line unless you know who can connect to your news system! For a client system to post news to INN, it must use the program inews.
Many things can go wrong with INN, but the error messages tend to be useful in isolating the problem. There are usually three files called faq-inn-1, faq-inn-2, and faq-inn3 that describe most aspects of the INN system, including installation, configuration, debugging, and special setups. Consult these files if you have any problems with your INN system.
Once you have completed the compilation and configuration of the NNTP system, you can continue to configure the underlying news subsystem (usually C News). Once that is done, you should be able to use NNTP to transfer articles from your newsfeed.