Configuring innd

 < Day Day Up > 

Configuring innd

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 won't 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 inn.conf File

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 28.3 shows the parameters that should be changed in the innd.conf file to represent your news server environment.

Table 28.3. innd.conf Configuration Parameters

Parameter

Description

mta

The command used to invoke the system MTA mailer. The %s variable is included to replace the recipient address in the command line. If you have installed the default Fedora Core Sendmail package, mta should be set correctly.

organization

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.

ovmethod

The storage method used for the article indexes. The default, tradindexed, is usually fine for small sites but might not be fast enough for large sites.

pathhost

The name of the host to place in the Path: article header line. This should represent your news server hostname. In the default file, it is shown as localhost and is commented out.

pathnews

The path to the news binaries, which is already set for your Fedora Core system.

domain

The complete domain name of your Internet domain. This parameter is blank until you fill it.

mailcmd

The command innd uses to send mail messages. Usually this should be the innmail program.

server

The name of a default NNTP server.

maxconnections

The maximum number of incoming NNTP connections your news server will support, based on your network's available bandwidth.

fromhost

The domain the INN system uses to construct email addresses. It should be set to your local system address.

moderatormailer

The email address to which messages posted to moderated newsgroups are sent if there is no corresponding entry in the moderator's file.

status

How frequently (in seconds) innd should create a status report. A value of 0 disables this feature. (A value of 0 is not recommended if you want to receive status reports, but it's the default Fedora Core setting. Set whatever you feel comfortable with.)

timer

How frequently (in seconds) innd should report performance statistics to the log files. A value of 0 disables this feature. (A value of 0 is not recommended, but it's the default Fedora Core setting. Set whatever you feel comfortable with.)


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 28.1 shows sample inn.conf file entries for a test server.

Listing 28.1. Sample inn.conf Configuration File Entries
 mta:               /usr/sbin/sendmail -oi -oem %s organization:      Hoyt's MaximumNews ovmethod:          tradindexed domain:            maximumhoyt.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 incoming.conf File

The /etc/news/incoming.conf file is 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.

The storage.conf File

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 Core 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.

CAUTION

If a newsgroup is not covered by a specific storage method, INN doesn't 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 Core /etc/news/storage.conf file doesn't 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.

The readers.conf File

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-wildcat               newsgroups: group-wildcat               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 isn't 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 Core 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

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 Core 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 Core Linux 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.

The history Files

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 Core 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 the innd program can recognize them. After the history files have been created, you are finally ready to start the news server.

Running innd

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 Core has thoughtfully configured the SystemV 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 14, "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 hoyt@maximumhoyt.com 

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.

Filtering Spam with the cleanfeed Package

One problem that has plagued the Usenet newsgroup system is the proliferation of spam Usenet messages. Spam providers often attempt to post their messages to newsgroups to force messages to a large, captive audience. One of the most effective methods for blocking spam messages from being posted to a newsgroup is to use the cleanfeed package. The cleanfeed package is a Perl script that filters out spam before it hits your news server. You can configure this software by editing its configuration file, cleanfeed.conf, under the /etc/news directory.

The newsgroup example offered in this chapter is designed for a closed system and doesn't need to filter spam. But you can learn more about cleanfeed in the FAQ found at http://www.exit109.com/~jeremy/news/cleanfeed/.


Relevant Fedora Core Linux Commands

You can use the following commands to manage newsgroups and other collaborative communication processes in Fedora Core Linux:

emacs The premier editing environment that can also be used to read Usenet news

innd The INN daemon and its plethora of associated commands

knode KDE's graphical Usenet newsreading client

mozilla The mail and newsgroups component of the Open Source Mozilla browser

pan An easy-to-use Usenet newsreader for GNOME

pine A text-based mail client that can also read Usenet news

slrn A text-based graphical Usenet newsreader


     < Day Day Up > 


    Red Hat Fedora 4 Unleashed
    Red Hat Fedora 4 Unleashed
    ISBN: 0672327929
    EAN: 2147483647
    Year: 2006
    Pages: 361

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net