Chapter 21
C News

Contents:
Delivering News
Installation
The sys File
The active File
Article Batching
Expiring News
Miscellaneous Files
Control Messages
C News in an NFS Environment
Maintenance Tools and Tasks

One of the most popular software packages for Netnews is C News. It was designed for sites that carry news over UUCP links. This chapter will discuss the central concepts of C News, basic installation, and maintenance tasks.

C News stores its configuration files in /etc/news, and most of its binaries are kept below the /usr/lib/news/ directory. Articles are kept below /var/spool/news. You should make sure that virtually all files in these directories are owned by user news or group news. Most problems arise from files being inaccessible to C News. Use su to become the user news before you touch anything in the directory. The only exception is the setnewsids command, which is used to set the real user ID of some news programs. It must be owned by root and have the setuid bit set.

In this chapter, we describe all C News configuration files in detail and show you what you have to do to keep your site running.

Delivering News

Articles can be fed to C News in several ways. When a local user posts an article, the newsreader usually hands it to the inews command, which completes the header information. News from remote sites, be it a single article or a whole batch, is given to the rnews command, which stores it in the /var/spool/news/in.coming directory, from where it will be picked up at a later time by newsrun. With any of these two techniques, however, the article will eventually be handed to the relaynews command.

For each article, the relaynews command first checks if the article has already been seen at the local site by looking up the message ID in the history file. Duplicate articles are dropped. Then relaynews looks at the Newsgroups: header line to find out if the local site requests articles from any of these groups. If it does, and the newsgroup is listed in the active file, relaynews tries to store the article in the corresponding directory in the news spool area. If this directory does not exist, it is created. The article's message ID is then logged to the history file. Otherwise, relaynews drops the article.

Sometimes relaynews fails to store an incoming article because a group to which it has been posted is not listed in your active file. In this case, the article is moved to the junk group.[1] relaynews also checks for stale or misdated articles and reject them. Incoming batches that fail for any other reason are moved to /var/spool/news/in.coming/bad, and an error message is logged.

[1] There may be a difference between the groups that exist at your site and those that your site is willing to receive. For example, the subscription list might specify comp.all, which should send all newsgroups below the comp hierarchy, but at your site you might not list several of the comp newsgroups in the active file. Articles posted to those groups will be moved to junk.

After this, the article is relayed to all other sites that request news from these groups, using the transport specified for each particular site. To make sure an article isn't sent to a site that has already seen it, each destination site is checked against the article's Path: header field, which contains the list of sites the article has traversed so far, written in the UUCP-style bang-path source-routing style described in Chapter 17, Electronic Mail. If the destination site's name does not appear in this list, the article is sent to it.

C News is commonly used to relay news between UUCP sites, although it is also possible to use it in an NNTP environment. To deliver news to a remote UUCP site, either in single articles or whole batches, uux is used to execute the rnews command on the remote site and feed the article or batch to it on standard input. Refer to Chapter 16, Managing Taylor UUCP, for more information on UUCP.

Batching is the term used to describe sending large bundles of individual articles all in one transmission. When batching is enabled for a given site, C News does not send any incoming article immediately; instead, it appends its path name to a file, usually called out.going/site/togo. Periodically, a program is executed from a crontab entry by the cron program, which reads this file and bundles all of the listed articles into one or more file, optionally compressing them and sending them to rnews at the remote site.[2]

[2] Note that this should be the crontab of news; file permissions will not be mangled.

Figure 21.1 shows the news flow through relaynews. Articles may be relayed to the local site (denoted by ME), to a site named ponderosa via email, and a site named moria, for which batching is enabled.

Figure 21.1: News flow through relaynews

Installation

C News should be available in a prepackaged format for any modern Linux distribution, so installation will be easy. If not, or if you want to install from the original source distribution, then of course you can.[3] No matter how you install it, you will need to edit the C News configuration files. Their formats are described in the following list:

[3] You can obtain the C News source distribution from its home site at ftp.cs.toronto.edu /pub/c-news/c-news.tar.Z

sys

The sys file controls which newsgroups your site receives and forwards. We discuss it in detail in the following section.

active

Not usually edited by the administration; contains directions for handling articles in each newsgroup the site handles.

organization

This file should contain your organization's name, for example, "Virtual Brewery, Inc." On your home machine, enter "private site," or anything else you like. Most people will not consider your site properly configured if you haven't customized this file.

newsgroups

This file is a list of all newsgroups, with a one-line description of each one's purpose. These descriptions are frequently used by your newsreader when displaying the list of all groups to which you are subscribed.

mailname

Your site's mail name, e.g., vbrew.com.

whoami

Your site's name for news purposes. Quite often, the UUCP site name is used, e.g., vbrew.

explist

You should probably edit this file to reflect your preferred expiration times for special newsgroups. Disk space may play an important role in your choices.

To create an initial hierarchy of newsgroups, obtain active and newsgroups files from the site that feeds you. Install them in /etc/news, making sure they are owned by news and have a mode of 644, using the chmod command. Remove all to.* groups from the active file, and add to.my-site, to.feed-site, junk, and control. The to.* groups are normally used for exchanging ihave/sendme messages, but you should list them regardless of whether you plan to use ihave/sendme or not. Next, replace all article numbers in the second and third field of active using the following commands:

# 
cp active active.old


# 
sed 's/ [0-9]* [0-9]* / 0000000000 00001 /' active.old > active


# 
rm active.old

The second command invokes the sed stream editor. This invocation replaces two strings of digits with a string of zeroes and the string 000001, respectively.

Finally, create the news spool directory and the subdirectories used for incoming and outgoing news:

# 
cd /var/spool


# 
mkdir news news/in.coming news/out.going news/out.master


# 
chown -R news.news news


# 
chmod -R 755 news

If you're using precompiled newsreaders sourced from a different distribution to the C News server you have running, you may find that some expect the news spool in /usr/spool/news rather than /var/spool/news. If your newsreader doesn't seem to find any articles, create a symbolic link from /usr/spool/news to /var/spool/news like this:

# 
ln -sf /usr/spool/news /var/spool/news

Now you are ready to receive news. Note that you don't have to create the individual newsgroup spool directories. C News automatically creates spool directories for any newsgroup it receives an article for, if one doesn't already exist.

In particular, this happens to all groups to which an article has been cross-posted. So, after a while, you will find your news spool cluttered with directories for newsgroups you have never subscribed to, like alt.lang.teco. You may prevent this by either removing all unwanted groups from active, or by regularly running a shell script that removes all empty directories below /var/spool/news (except out.going and in.coming, of course).

C News needs a user to send error messages and status reports to. By default, this is usenet. If you use the default, you have to set up an alias for it that forwards all of its mail to one or more responsible person. You may also override this behavior by setting the environment variable NEWSMASTER to the appropriate name. You have to do so in news's crontab file, as well as every time you invoke an administrative tool manually, so installing an alias is probably easier. Mail aliases are described in Chapter 18, Sendmail, and Chapter 19, Getting Exim Up and Running.

While you're hacking /etc/passwd, make sure that every user has her real name in the pw_gecos field of the password file (this is the fourth field). It is a question of Usenet netiquette that the sender's real name appears in the From: field of the article. Of course, you will want to do so anyway when you use mail.

The sys File

The sys file, located in /etc/news, controls which hierarchies you receive and forward to other sites. Although there are maintenance tools named addfeed and delfeed, we think it's better to maintain this file by hand.

The sys file contains entries for each site to which you forward news, as well as a description of the groups you will accept. The first line is a ME entry that describes your system. It's a safe bet to use the following:

ME:all/all::

You also have to add a line for each site to which you feed news. Each line looks like this:

site[/exclusions]:grouplist[/distlist][:flags[:cmds]]

Entries may be continued across newlines using a backslash (\) at the end of the line to be continued. A hash sign (#) denotes a comment.

site

This is the name of the site the entry applies to. One usually chooses the site's UUCP name for this. There has to be an entry for your site in the sys file too, or you will not receive any articles yourself.

The special site name ME denotes your site. The ME entry defines all groups you are willing to store locally. Articles that aren't matched by the ME line will go to the junk group.

C News rejects any articles that have already passed through this site to prevent loops. C News does this by ensuring that the local site name does not appear in the Path: of the article. Some sites may be known by a number of valid names. For example, some sites use their fully qualified domain name in this field, or an alias like news. site.domain. To ensure the loop prevention mechanism works, it is important to add all aliases to the exclusion list, separating them by commas.

For the entry applying to site moria, for instance, the site field would contain moria/moria.orcnet.org. If moria were also by an alias of news.orcnet.org, then our site field would contain moria/moria.orcnet.org,news.orcnet.org.

grouplist

This is a comma-separated subscription list of groups and hierarchies for this particular site. A hierarchy may be specified by giving the hierarchy's prefix (such as comp.os for all groups whose names start with this prefix), optionally followed by the keyword all (e.g., comp.os.all).

You can exclude a hierarchy or group from forwarding by preceding it with an exclamation mark. If a newsgroup is checked against the list, the longest match applies. For example, if grouplist contains this list:

!comp,comp.os.linux,comp.folklore.computers

no groups from the comp hierarchy except comp.folklore.computers and all groups below comp.os.linux will be fed to that site.

If the site requests to be forwarded all news you receive yourself, enter all as grouplist.

distlist

This value is offset from the grouplist by a slash and contains a list of distributions to be forwarded. Again, you may exclude certain distributions by preceding them with an exclamation mark. All distributions are denoted by all. Omitting distlist implies a list of all.

For example, you may use a distribution list of all,!local to prevent news meant only for local use from being sent to remote sites.

There are usually at least two distributions: world, which is often the default distribution used when none is specified by the user, and local. There may be other distributions that apply to a certain region, state, country, etc. Finally, there are two distributions used by C News only; these are sendme and ihave, and are used for the sendme/ihave protocol.

The use of distributions is a subject of debate. The distribution field in a news article can be created arbitrarily, but for a distribution to be effective, the news servers in the network must know it. Some misbehaving newsreaders create bogus distributions by simply assuming the top-level newsgroup hierarchy of the article destination is a reasonable distribution. For example, one might assume comp to be a reasonable distribution to use when posting to the comp.os.linux.networking newsgroup. Distributions that apply to regions are often questionable, too, because news may travel outside of your region when sent across the Internet.[4] Distributions applying to an organization, however, are very meaningful; e.g., to prevent confidential information from leaving the company network. This purpose, however, is generally served better by creating a separate newsgroup or hierarchy.

[4] It is not uncommon for an article posted in say, Hamburg, to go to Frankfurt via reston.ans.net in the Netherlands, or even via some site in the U.S.

flags

This option describes certain parameters for the feed. It may be empty or a combination of the following:

F

This flag enables batching.

f

This is almost identical to the F flag, but allows C News to calculate the size of outgoing batches more precisely, and should probably be used in preference.

I

This flag makes C News produce an article list suitable for use by ihave/sendme. Additional modifications to the sys and the batchparms file are required to enable ihave/sendme.

n

This creates batch files for active NNTP transfer clients like nntpxmit (see Chapter 22, NNTP and the nntpd Daemon). The batch files contain the article's filename along with its message ID.

L

This tells C News to transmit only articles posted at your site. This flag may be followed by a decimal number n, which makes C News transfer articles posted only within n hops from your site. C News determines the number of hops from the Path: field.

u

This tells C News to batch only articles from unmoderated groups.

m

This tells C News to batch only articles from moderated groups.

You may use at most one of F, f, I, or n.

cmds

This field contains a command that will be executed for each article, unless you enable batching. The article will be fed to the command on standard input. This should be used for very small feed only; otherwise, the load on both systems will be too high.

The default command is:

uux - -r -z remote-system!rnews

This invokes rnews on the remote system, feeding it the article on standard input.

The default search path for commands given in this field is /bin:/usr/bin:/usr/lib/news/batch. The latter directory contains a number of shell scripts whose names start with via; they are briefly described later in this chapter.

If batching is enabled using one of the F, f, I, or n flags, C News expects to find a filename in this field rather than a command. If the filename does not begin with a slash (/), it is assumed to be relative to /var/spool/news/out.going. If the field is empty, it defaults to remote-system/togo. The file is expected to be in the same format as the remote-system/togo file and contain a list of articles to transmit.

When setting up C News, you will most probably have to write your own sys file. Here is a sample file for vbrew.com, from which you may copy what you need:

# We take whatever they give us. ME:all/all:: # We send everything we receive to moria, except for local and # brewery-related articles. We use batching. moria/moria.orcnet.org:all,!to,to.moria/all,!local,!brewery:f: # We mail comp.risks to jack@ponderosa.uucp ponderosa:comp.risks/all::rmail jack@ponderosa.uucp # swim gets a minor feed swim/swim.twobirds.com:comp.os.linux,rec.humor.oracle/all,!local:f: # Log mail map articles for later processing usenet-maps:comp.mail.maps/all:F:/var/spool/uumaps/work/batch

The active File

The active file is located in /etc/, and lists all groups known at your site and the articles currently online. You will rarely have to touch it, but we explain it nevertheless for sake of completion. Entries take the following form:

newsgroup high low perm

newsgroup is the group's name. low and high are the lowest and highest numbers of articles currently available. If none are available at the moment, low is equal to high+1.

At least that's what the low field is meant to do. However, for efficiency, C News doesn't update this field. This wouldn't be such a big loss if there weren't newsreaders that depend on it. For instance, trn checks this field to see if it can purge any articles from its thread database. To update the low field, you therefore have to run the updatemin command regularly (or, in earlier versions of C News, the upact script).

perm is a parameter detailing the access users are granted to the group. It takes one of the following values:

y

Users are allowed to post to this group.

n

Users are not allowed to post to this group. However, the group may still be read.

x

This group has been disabled locally. This happens sometimes when news administrators (or their superiors) take offense at articles posted to certain groups.

Articles received for this group are not stored locally, although they are forwarded to the sites that request them.

m

This denotes a moderated group. When a user tries to post to this group, an intelligent newsreader notifies her of this and send the article to the moderator instead. The moderator's address is taken from the moderators file in /var/lib/news.

= real-group

This marks newsgroup as being a local alias for another group, namely real-group. All articles posted to newsgroup will be redirected to it.

In C News, you will generally not have to access this file directly. Groups can be added or deleted locally using addgroup and delgroup (see the section "Maintenance Tools and Tasks" later in this chapter). A newgroup control message adds a group for the whole of Usenet, while a rmgroup message deletes a group. Never send such a message yourself! For instructions on how to create a newsgroup, read the monthly postings in news.announce.newusers.

The active.times file is closely related to the active file. Whenever a group is created, C News logs a message to this file containing the name of the group created, the date of creation, whether it was done by a newgroup control message or locally, and who did it. This is convenient for newsreaders that may notify the user of any recently created groups. It is also used by the NEWGROUPS command of NNTP.

Article Batching

News batches follow a particular format that is the same for B News, C News, and INN. Each article is preceded by a line like this:

#! rnews count

count is the number of bytes in the article. When you use batch compression, the resulting file is compressed as a whole and preceded by another line, indicated by the message to be used for unpacking. The standard compression tool is compress, which is marked by:

#! cunbatch

Sometimes, when the news server sends batches via mail software that removes the eighth bit from all data, a compressed batch may be protected using what is called c7-encoding; these batches will be marked by c7unbatch.

When a batch is fed to rnews on the remote site, it checks for these markers and processes the batch appropriately. Some sites also use other compression tools, like gzip, and precede their gzipped files with the word zunbatch instead. C News does not recognize nonstandard headers like these; you have to modify the source to support them.

In C News, article batching is performed by /usr/lib/news/batch/sendbatches, which takes a list of articles from the site/togo file and puts them into several newsbatches. It should be executed once per hour, or even more frequently, depending on the volume of traffic. Its operation is controlled by the batchparms file in /var/lib/news. This file describes the maximum batch size allowed for each site, the batching and optional compression program to be used, and the transport for delivering it to the remote site. You may specify batching parameters on a per-site basis, as well as a set of default parameters for sites not explicitly mentioned.

When installing C News, you will most likely find a batchparms file in your distribution that contains a reasonable default entry, so there's a good chance that you won't have to touch the file. Just in case, we describe its format. Each line consists of six fields, separated by spaces or tabs:

site size max batcher muncher transport

site

site is the name of the site to which the entry applies. The togo file for this site must reside in out.going/togo below the news spool. A site name of /default/ denotes the default entry and is to match any site not directly specified with an entry unique to it.

size

size is the maximum size of article batches created (before compression). For single articles larger than this, C News makes an exception and puts each in a single batch by itself.

max

max is the maximum number of batches created and scheduled for transfer before batching stalls for this particular site. This is useful in case the remote site should be down for a long time, because it prevents C News from cluttering your UUCP spool directories with zillions of newsbatches.

C News determines the number of queued batches using the queuelen script in /usr/lib/news/. If you've installed C News in a prepackaged format, the script should not need any editing, but if you choose to use a different flavor of spool directories, for example, Taylor UUCP, you might have to write your own. If you don't care about the number of spool files (because you're the only person using your computer and you don't write articles by the megabyte), you may replace the script's contents by a simple exit 0 statement.

batcher

The batcher field contains the command used for producing a batch from the list of articles in the togo file. For regular feeds, this is usually batcher. For other purposes, alternative batchers may be provided. For instance, the ihave/sendme protocol requires the article list to be turned into ihave or sendme control messages, which are posted to the newsgroup to.site. This is performed by batchih and batchsm.

muncher

The muncher field specifies the compression command. Usually, this is compcun, a script that produces a compressed batch.[5] Alternatively, suppose you create a muncher that uses gzip, say gzipcun (note that you have to write it yourself). You have to make sure that uncompress on the remote site is patched to recognize files compressed with gzip.

[5] As shipped with C News, compcun uses compress with the 12-bit option, since this is the lowest common denominator for most sites. You may produce a copy of the script, say compcun16, for which you use 16-bit compression. The improvement is not too impressive, though.

If the remote site does not have an uncompress command, you may specify nocomp, which does not do any compression.

transport

The last field, transport, describes the transport to be used. A number of standard commands for different transports are available; their names begin with via. sendbatches passes them the destination sitename on the command line. If the batchparms entry is not /default/, sendbatches derives the sitename from the site field by stripping it of anything after and including the first dot or slash. If the batchparms entry is /default/, the directory names in out.going are used.

To perform batching for a specific site, use the following command:

# 
su news -c "/usr/lib/news/batch/sendbatches site"

When invoked without arguments, sendbatches handles all batch queues. The interpretation of "all" depends on the presence of a default entry in batchparms. If one is found, all directories in /var/spool/news/out.going are checked; otherwise, sendbatches cycles through all entries in batchparms, processing just the sites found there. Note that sendbatches, when scanning the out.going directory, takes only those directories that contain no dots or at signs (@) as sitenames.

There are two commands that use uux to execute rnews on the remote system: viauux and viauuxz. The latter sets the -z flag for uux to keep older versions from returning success messages for each article delivered. Another command, viamail, sends article batches to the user rnews on the remote system via mail. Of course, this requires that the remote system somehow feeds all mail for rnews to its local news system. For a complete list of these transports, refer to the newsbatch manual page.

All commands from the last three fields must be located in either out.going/site or /usr/lib/news/batch. Most of them are scripts; you can easily tailor new tools for your personal needs. They are invoked through pipes. The list of articles is fed to the batcher on standard input, which produces the batch on standard output. This is piped into the muncher, and so on.

Here is a sample file:

# batchparms file for the brewery # site        | size   |max    |batcher  |muncher    |transport #-------------+--------+-------+---------+-----------+----------- /default/       100000  22      batcher   compcun     viauux swim             10000  10      batcher   nocomp      viauux

Expiring News

In B News, expiration needs to be performed by a program called expire, which took a list of newsgroups as arguments, along with a time specification after which articles had to be expired. To have different hierarchies expire at different times, you had to write a script that invoked expire for each of them separately. C News offers a more convenient solution. In a file called explist, you may specify newsgroups and expiration intervals. A command called doexpire is usually run once a day from cron and processes all groups according to this list.

Occasionally, you may want to retain articles from certain groups even after they have been expired; for example, you might want to keep programs posted to comp.sources.unix. This is called archiving. explist permits you to mark groups for archiving.

An entry in explist looks like this:

grouplist perm times archive

grouplist is a comma-separated list of newsgroups to which the entry applies. Hierarchies may be specified by giving the group name prefix, optionally appended with all. For example, for an entry applying to all groups below comp.os, enter either comp.os or comp.os.all .

When expiring news from a group, the name is checked against all entries in explist in the order given. The first matching entry applies. For example, to throw away the majority of comp after four days, except for comp.os.linux.announce, which you want to keep for a week, you simply have an entry for the latter, which specifies a seven-day expiration period, followed by an expiration period for comp, which specifies four days.

The perm field details if the entry applies to moderated, unmoderated, or any groups. It may take the values m, u, or x, which denote moderated, unmoderated, or any type.

The third field, times, usually contains only a single number. This is the number of days after which articles expire if they haven't been assigned an artificial expiration date in an Expires: field in the article header. Note that this is the number of days counting from its arrival at your site, not the date of posting.

The times field may, however, be more complex than that. It may be a combination of up to three numbers separated from one another by dashes. The first denotes the number of days that have to pass before the article is considered a candidate for expiration, even if the Expires: field would have it expire already. It is rarely useful to use a value other than zero. The second field is the previously mentioned default number of days after which it will be expired. The third is the number of days after which an article will be expired unconditionally, regardless of whether it has an Expires: field or not. If only the middle number is given, the other two take default values. These may be specified using the special entry /bounds/, which is described a little later.

The fourth field, archive, denotes whether the newsgroup is to be archived and where. If no archiving is intended, a dash should be used. Otherwise, you either use a full pathname (pointing to a directory) or an at sign (@). The at sign denotes the default archive directory, which must then be given to doexpire by using the -a flag on the command line. An archive directory should be owned by news. When doexpire archives an article from say, comp.sources.unix, it stores it in the directory comp/sources/unix below the archive directory, creating it if necessary. The archive directory itself, however, will not be created.

There are two special entries in your explist file that doexpire relies on. Instead of a list of newsgroups, they have the keywords /bounds/ and /expired/. The /bounds/ entry contains the default values for the three values of the times field described previously.

The /expired/ field determines how long C News will hold onto lines in the history file. C News will not remove a line from the history file once the corresponding article(s) have been expired, but will hold onto it in case a duplicate should arrive after this date. If you are fed by only one site, you can keep this value small. Otherwise, a couple of weeks is advisable on UUCP networks, depending on the delays you experience with articles from these sites.

Here is a sample explist file with rather tight expiry intervals:

# keep history lines for two weeks. No article gets more than three months /expired/                       x       14      - /bounds/                        x       0-1-90  - # groups we want to keep longer than the rest comp.os.linux.announce          m       10      - comp.os.linux                   x       5       - alt.folklore.computers          u       10      - rec.humor.oracle                m       10      - soc.feminism                    m       10      - # Archive *.sources groups comp.sources,alt.sources        x       5       @ # defaults for tech groups comp,sci                        x       7       - # enough for a long weekend misc,talk                       x       4       - # throw away junk quickly junk                            x       1       - # control messages are of scant interest, too control                         x       1       - # catch-all entry for the rest of it all                             x       2       -

Expiring presents several potential problems. One is that your newsreader might rely on the third field of the active file described earlier, which contains the number of the lowest article online. When expiring articles, C News does not update this field. If you need (or want) to have this field represent the real situation, you need to run a program called updatemin after each run of doexpire. (In older versions of C News, a script called upact did this.)

C News does not expire by scanning the newsgroup's directory, but simply checks the history file if the article is due for expiration.[6] If your history file somehow gets out of sync, articles may be around on your disk forever because C News has literally forgotten them.[7] You can repair this by using the addmissing script in /usr/lib/news/maint, which will add missing articles to the history file or mkhistory, which rebuilds the entire file from scratch. Don't forget to become user news before invoking it, or else you will wind up with a history file unreadable by C News.

[6] The article's date of arrival is kept in the middle field of the history line and given in seconds since January 1, 1970.

[7] I don't know why this happens, but it does from time to time.

Miscellaneous Files

There are a number of files that control the behavior of C News, but are not essential. All of them reside in /etc/news. We describe them briefly here:

newsgroups

This is a companion file of active that contains a list of each newsgroup name along with a one-line description of its main topic. This file is automatically updated when C News receives a checknews control message.

localgroups

If you have a lot of local groups, you can keep C News from complaining about them each time you receive a checkgroups message by putting their names and descriptions in this file, just as they would appear in newsgroups.

mailpaths

This file contains the moderator's address for each moderated group. Each line contains the group name followed by the moderator's email address (offset by a tab).

Two special entries are provided as defaults: backbone and internet. Both provide, in bang-path notation, the path to the nearest backbone site and the site that understands RFC-822 style addresses (user@host). The default entries are:

internet           backbone

You do not have to change the internet entry if you have exim or sendmail installed; they understand RFC-822 addressing.

The backbone entry is used whenever a user posts to a moderated group whose moderator is not listed explicitly. If the newsgroup's name is alt.sewer and the backbone entry contains path!%s, C News will mail the article to path!alt-sewer, hoping that the backbone machine is able to forward the article. To find out which path to use, ask the news-admin at the site that feeds you. As a last resort, you can also use uunet.uu.net!%s.

distributions

This file is not really a C News file, but is used by some newsreaders and nntpd. It contains the list of distributions recognized by your site and a description of their (intended) effects. For example, Virtual Brewery has the following file:

world         everywhere in the world local         Only local to this site nl            Netherlands only mugnet        MUGNET only fr            France only de            Germany only brewery       Virtual Brewery only

log

This file contains a log of all C News activities. It is culled regularly by running newsdaily; copies of the old log files are kept in log.o, log.oo, etc.

errlog

This is a log of all error messages created by C News. These messages do not include logs of articles junked due to being sent to an invalid wrong group or other user errors. This file is mailed to the newsmaster (usenet by default) automatically by newsdaily if it is not found empty.

errlog is cleared by newsdaily. errlog.o keeps old copies and companions.

batchlog

This file logs all runs of sendbatches. It is usually of scant interest. It is also attended by newsdaily.

watchtime

This is an empty file created each time newswatch runs.

Control Messages

The Usenet news protocol knows a special category of articles that evoke certain responses or actions by the news system. These are called control messages. They are recognized by the presence of a Control: field in the article header, which contains the name of the control operation to be performed. There are several types of them, all of which are handled by shell scripts located in /usr/lib/news/ctl.

Most of these messages perform their action automatically at the time the article is processed by C News without notifying the newsmaster. By default, only checkgroups messages will be handed to the newsmaster, but you may change this by editing the scripts.

The cancel Message

The most widely known message is cancel, with which a user can cancel an article sent earlier. This effectively removes the article from the spool directories, if it exists. The cancel message is forwarded to all sites that receive news from the groups affected, regardless of whether the article has been seen already. This takes into account the possibility that the original article has been delayed over the cancellation message. Some news systems allow users to cancel other people's messages; this is, of course, a definite no-no.

newgroup and rmgroup

Two messages dealing with creation or removal of newsgroups are the newgroup and rmgroup messages. Newsgroups below the "usual" hierarchies may be created only after a discussion and voting has been held among Usenet readers. The rules applying to the alt hierarchy allow for something close to anarchy. For more information, see the regular postings in news.announce.newusers and news.announce.newgroups. Never send a newgroup or rmgroup message yourself unless you definitely know that you are allowed to.

The checkgroups Message

checkgroups messages are sent by news administrators to make all sites within a network synchronize their active files with the realities of Usenet. For example, commercial Internet Service Providers might send out such a message to their customers' sites. Once a month, the "official" checkgroups message for the major hierarchies is posted to comp.announce.newgroups by its moderator. However, it is posted as an ordinary article, not as a control message. To perform the checkgroups operation, save this article to a file, say /tmp/check, remove everything up to the beginning of the control message itself, and feed it to the checkgroups script using the following command:

# 
su news -c "/usr/lib/news/ctl/checkgroups" < /tmp/check

This will update your newsgroups file from the new list of groups, adding the groups listed in localgroups. The old newsgroups file will be moved to newsgroups.bac. Note that posting the message locally rarely works, because inews, the command that accepts and posts articles from users, refuses to accept that large an article.

If C News finds mismatches between the checkgroups list and the active file, it produces a list of commands that would bring your site up to date and mails it to the news administrator.

The output typically looks like this:

From news Sun Jan 30 16:18:11 1994 Date: Sun, 30 Jan 94 16:18 MET From: news (News Subsystem) To: usenet Subject: Problems with your active file The following newsgroups are not valid and should be removed.         alt.ascii-art         bionet.molbio.gene-org         comp.windows.x.intrisics         de.answers You can do this by executing the commands:          /usr/lib/news/maint/delgroup alt.ascii-art          /usr/lib/news/maint/delgroup bionet.molbio.gene-org          /usr/lib/news/maint/delgroup comp.windows.x.intrisics          /usr/lib/news/maint/delgroup de.answers The following newsgroups were missing.         comp.binaries.cbm         comp.databases.rdb         comp.os.geos         comp.os.qnx         comp.unix.user-friendly         misc.legal.moderated         news.newsites         soc.culture.scientists         talk.politics.crypto         talk.politics.tibet

When you receive a message like this from your news system, don't believe it automatically. Depending on who sent the checkgroups message, it may lack a few groups or even entire hierarchies; you should be careful about removing any groups. If you find groups are listed as missing that you want to carry at your site, you have to add them using the addgroup script. Save the list of missing groups to a file and feed it to the following little script:

#!/bin/sh # WHOIAM=`whoami` if [ "$WHOIAM" != "news" ] then         echo "You must run $0 as user 'news'" >&2         exit 1 fi # cd /usr/lib/news while read group; do     if grep -si "^$group[[:space:]].*moderated" newsgroup; then         mod=m     else         mod=y     fi     /usr/lib/news/maint/addgroup $group $mod done

sendsys, version, and senduuname

Finally, there are three messages that can be used to find out about the network's topology. These are sendsys, version, and senduuname. They cause C News to return the sys file to the sender, as well as a software version string and the output of uuname, respectively. C News is very laconic about version messages; it returns a simple, unadorned C.

Again, you should never issue such a message unless you have made sure that it cannot leave your (regional) network. Replies to sendsys messages can quickly bring down a UUCP network.[8]

[8] I wouldn't try this on the Internet, either.

C News in an NFS Environment

A simple way to distribute news within a local network is to keep all news on a central host and export the relevant directories via NFS so that newsreaders may scan the articles directly. The overhead involved in retrieving and threading articles is significantly lower than NNTP. NNTP, on the other hand, wins in a heterogeneous network where equipment varies widely among hosts, or where users don't have equivalent accounts on the server machine.

When you use NFS, articles posted on a local host have to be forwarded to the central machine because accessing adminstrative files might otherwise expose the system to race conditions that leave the files inconsistent. Also, you might want to protect your news spool area by exporting it read-only, which also requires forwarding to the central machine.

C News handles this central machine configuration transparently to the user. When you post an article, your newsreader usually invokes inews to inject the article into the news system. This command runs a number of checks on the article, completes the header, and checks the file server in /etc/news. If this file exists and contains a hostname different from the local host's name, inews is invoked on that server host via rsh. Since the inews script uses a number of binary commands and support files from C News, you have to either have C News installed locally or mount the news software from the server.

For the rsh invocation to work properly, each user who posts news must have an equivalent account on the server system, i.e., one to which she can log in without being asked for a password.

Make sure that the hostname given in server literally matches the output of the hostname command on the server machine, or else C News will loop forever in an attempt to deliver the article. We discuss NFS is detail in Chapter 14, The Network File System.

Maintenance Tools and Tasks

Despite the complexity of C News, a news administrator's life can be fairly easy; C News provides you with a wide variety of maintenance tools. Some of these are intended to be run regularly from cron, like newsdaily. Using these scripts greatly reduces daily care and feeding requirements of your C News installation.

Unless stated otherwise, these commands are located in /usr/lib/news/maint. (Note that you must become user news before invoking these commands. Running them as a superuser may render critical newsfiles inaccessible to C News.):

newsdaily

The name already says it: run this once a day. It is an important script that helps you keep log files small, retaining copies of each from the last three runs. It also tries to sense anomalies, like stale batches in the incoming and outgoing directories, postings to unknown or moderated newsgroups, etc. Resulting error messages are mailed to the newsmaster.

newswatch

This script should be run regularly to look for anomalies in the news system, once an hour or so. It is intended to detect problems that will have an immediate effect on the operability of your news system, in which case it mails a trouble report to the newsmaster. Things checked include stale lock files that don't get removed, unattended input batches, and disk space shortage.

addgroup

This script adds a group to your site locally. The proper invocation is:

addgroup groupname y|n|m|=realgroup

The second argument has the same meaning as the flag in the active file, meaning that anyone may post to the group (y), that no one may post (n), that it is moderated (m), or that it is an alias for another group (= realgroup). You might also want to use addgroup when the first articles in a newly created group arrive earlier than the newgroup control message that is intended to create it.

delgroup

This script allows you to delete a group locally. Invoke it as:

delgroup groupname

You still have to delete the articles that remain in the newsgroup's spool directory. Alternatively, you might leave it to the natural course of events (i.e., expiration) to make them go away.

addmissing

This script adds missing articles to the history file. Run it when there are articles that seem to hang around forever.

newsboot

This script should be run at system boot time. It removes any lock files left over when news processes were killed at shutdown, and closes and executes any batches left over from NNTP connections that were terminated when shutting down the system.

newsrunning

This script resides in /usr/lib/news/input and may be used to disable unbatching of incoming news, for instance during work hours. You may turn off unbatching by invoking:

/usr/lib/news/input/newsrunning off

It is turned on by using on instead of off.