You can still access new articles if you're not running mthreads, but you will have all those "A GENUINE INVESTMENT OPPORTUNITY" articles scattered across your article selection menu, instead of a single thread you may easily skip.
To turn on threading for particular newsgroups, invoke mthreads with the list of newsgroups on the command line. The format of the list is the same as the one in the C News sys file:
$ mthreads 'comp,rec,!rec.games.go'
This command enables threading for all of comp and rec, except for rec.games.go (people who play Go don't need fancy threads). After that, you simply invoke mthreads with no options at all to make it thread any newly arrived articles. Threading of all groups found in your active file can be turned on by invoking mthreads with a group list of all.
If you're receiving news during the night, you will customarily run mthreads once in the morning, but you can also to do so more frequently if necessary. Sites that have very heavy traffic may want to run mthreads in daemon mode. When it is started at boot time using the -d option, it puts itself in the background, wakes up every ten minutes to check if there are any newly arrived articles, and threads them. To run mthreads in daemon mode, put the following line in your rc.news script:
/usr/local/bin/rn/mthreads -deav
The -a option makes mthreads automatically turn on threading for new groups as they are created; -v enables verbose log messages to the mthreads log file mt.log in the directory where you have trn installed.
Old articles that are no longer available must be removed from the index files regularly. By default, only articles with a number below the low-water mark will be removed.[142] Articles above this number that have been expired (because the oldest article has been assigned a long expiration date by an Expires: header field) may nevertheless be removed by giving mthreads the -e option to force an "enhanced" expiry run. When mthreads is running in daemon mode, the -e option makes mthreads put in such an enhanced expiry run once a day, shortly after midnight.
nn Configuration
nn, written by Kim F. Storm, claims to be a newsreader whose ultimate goal is not to read news. Its name stands for "No News," and its motto is "No news is good news. nn is better."
To achieve this ambitious goal, nn comes with a large assortment of maintenance tools that not only allow thread generation, but also extensive database consistency checks, accounting, gathering of usage statistics, and access restrictions. There is also an administration program called nnadmin, which allows you to perform these tasks interactively. It is very intuitive, so we will not dwell on these aspects, but deal only with the generation of the index files.
The nn threads database manager is called nnmaster. It is usually run as a daemon, started from an rc file at boot time. It is invoked as:
/usr/local/lib/nn/nnmaster -l -r -C
This enables threading for all newsgroups present in your active file.
Equivalently, you may invoke nnmaster periodically from cron, giving it a list of groups to act upon. This list is very similar to the subscription list in the sys file, except that it uses blanks instead of commas. Instead of the fake group name all, an empty argument of " should be used to denote all groups. A sample invocation looks like this:
# /usr/local/lib/nn/nnmaster!rec.games.go rec comp
Note that the order is significant. The leftmost group specification that matches always wins. Thus, if we had put !rec.games.go after rec, all articles from this group would have been threaded nevertheless.
nn offers several methods to remove expired articles from its databases. The first is to update the database by scanning the newsgroup directories and discarding the entries whose corresponding article has exceeded its expiration date. This is the default operation obtained by invoking nnmaster with the -E option. It is reasonably quick, unless you're doing this via NNTP.
The second method behaves exactly like a default expiration run of mthreads; it removes only those entries that refer to articles with numbers below the low-water mark in the active file. It may be enabled using the -e option.
Finally, the third strategy discards the entire database and recollects all articles. It may be enabled using the -E3 option.
The list of groups to be expired is given by the -F option in the same fashion as above. However, if you have nnmaster running as daemon, you must kill it (using -k) before expiration can take place, and restart it with the original options afterward. Thus the proper command to run expiration on all groups using the first method is:
# nnmaster -kF ""
# nnmaster -lrC
There are many more flags that fine-tune the nn 's behavior. If you are concerned about removing bad articles or assembling article digests, read the nnmaster manual page.
nnmaster relies on a file named GROUPS, which is located in /var/lib/nn. If it does not exist when nnmaster is first run, it is created. For each newsgroup, it contains a line that begins with the group's name, optionally followed by a time stamp and flags. You may edit these flags to enable certain behavior for the group in question, but you may not change the order in which the groups appear.[143] The flags allowed and their effects are detailed in the nnmaster manual page, too.
Appendix A. Example Network: The Virtual Brewery
Throughout this book we've used the following example that is a little less complex than Groucho Marx University and may be closer to the tasks you will actually encounter.
The Virtual Brewery is a small company that brews, as the name suggests, virtual beer. To manage their business more efficiently, the virtual brewers want to network their computers, which all happen to be PCs running the brightest and shiniest production Linux kernel. Figure A.1 shows the network configuration.
On the same floor, just across the hall, there's the Virtual Winery, which works closely with the brewery. The vintners run an Ethernet of their own. Quite naturally, the two companies want to link their networks once they are operational. As a first step, they want to set up a gateway host that forwards datagrams between the two subnets. Later, they also want to have a UUCP link to the outside world, through which they exchange mail and news. In the long run, they also want to set up PPP connections to connect to offsite locations and to the Internet.
The Virtual Brewery and the Virtual Winery each have a class C subnet of the Brewery's class B network, and gateway to each other via the host vlager, which also supports the UUCP connection. Figure A.2 shows the configuration.
Figure A.1: The Virtual Brewery and Virtual Winery subnets
Figure A.2: The Virtual Brewery Network
Connecting the Virtual Subsidiary Network
The Virtual Brewery grows and opens a branch in another city. The subsidiary runs an Ethernet of its own using the IP network number 172.16.3.0, which is subnet 3 of the Brewery's class B network. The host vlager acts as the gateway for the Brewery network and will support the PPP link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1. This network is illustrated in Figure A.2.
142
Note that C News (described in Chapter 21, C News) doesn't update this low-water mark automatically; you have to run updatemin to do so.