LDP/LDP/guide/docbook/nag2/ch24.sgm

351 lines
15 KiB
Plaintext

<chapter id="X-087-2-newsreaders"><title>Newsreader <?lb>Configuration</title>
<indexterm id="chnr.newsrdr.config" class="startofrange"><primary>newsreaders</primary><secondary>configuring</secondary></indexterm>
<indexterm id="chnr.config.newsrdr" class="startofrange"><primary>configuring</primary><secondary>newsreader</secondary></indexterm>
<para>
A <command>newsreader</command> is a program that users invoke to view,
store, and create news articles. Several newsreaders have been ported to
Linux. We will describe the basic setup for the three most popular
newsreaders: <command>tin</command>, <command>trn</command>, and <command>nn</command>.
</para>
<para>
One of the most effective newsreaders is:
<screen>
$ <userinput>find /var/spool/news -name '[0-9]*' -exec cat {} \; | more</userinput>
</screen>
</para>
<para>
This is the way Unix die-hards read their news.
</para>
<para>
Most newsreaders, however, are much more sophisticated. They usually offer
a full-screen interface with separate levels for displaying all groups the
user has subscribed to, an overview of all articles in each group, and
individual articles. Many web browsers double as newsreaders, but if you want
to use a standalone newsreader, this chapter explains how to configure two
classic ones: <command>trn</command> and <command>nn</command>.
</para>
<para>
At the newsgroup level, most newsreaders display a list of articles,
showing their subject lines and authors. In big groups, it is difficult
for the user to keep track of articles relating to each other, although
it is possible to identify responses to earlier articles.
</para>
<para>
<indexterm><primary>newsreaders</primary><secondary>threading</secondary></indexterm>
<indexterm><primary>news (network)</primary><secondary>follow-up</secondary></indexterm>
A response usually repeats the original article's subject, prepending it
with <literal>Re:</literal>. Additionally, the <literal>References:</literal>
header line should include the message ID of the article on which the
response is directly following up. Sorting articles by these two criteria
generates small clusters (in fact, trees) of articles, which are called
<emphasis>threads</emphasis>. One of the tasks of writing a newsreader is
devising an efficient scheme of threading, because the time required for this
is proportional to the square of the number of articles.
</para>
<para>
We will not go into how the user interfaces are built here. All newsreaders
currently available for Linux have a good help function; please refer to it
for more details.
</para>
<para>
In the following sections, we will deal only with administrative tasks. Most of
these relate to the creation of threads databases and accounting.
</para>
<sect1 id="X-087-2-newsreaders.tin"><title>tin Configuration</title>
<indexterm><primary>newsreaders</primary><secondary>tass</secondary></indexterm>
<indexterm><primary>newsreaders</primary><secondary>tin</secondary></indexterm>
<indexterm><primary>tass newsreader</primary></indexterm>
<indexterm><primary>tin newsreader, configuration</primary></indexterm>
<para>
The most versatile newsreader with respect to threading is
<command>tin</command>. It was written by Iain Lea and is loosely modeled
on an older newsreader named <command>tass</command> (written by Rich Skrenta).
It does its threading when the user enters the newsgroup, and it is
pretty fast unless you're getting posts via NNTP.
</para>
<para>
On a 486DX50, it takes roughly 30 seconds to thread 1,000 articles when
reading directly from disk. It would take more than 5 minutes over NNTP
to reach a loaded news server.<footnote id="X-087-2-FNNR01"><para>
Things improve drastically if the NNTP server does the threading itself and
lets the client retrieve the threads databases; INN does this, for instance.
</para>
</footnote>
You may improve this time by regularly updating your index file by invoking
<command>tin</command> with the <option>&ndash;u</option> option, so that when
you next start <command>tin</command> to read news the threads already exist.
Alternatively, you can invoke <command>tin</command> with the
<option>&ndash;U</option> option to read news. When invoked this way,
<command>tin</command> forks a background process to build the index files
while you are reading news.
</para>
<para>
Usually, <command>tin</command> dumps its threading databases in the user's
home directory below <filename>.tin/index</filename>. This may be costly
in terms of resources, however, so you should keep a single copy of them in
a central location. This may be achieved by making <command>tin</command>
setuid to <systemitem role="userid">news</systemitem>, for
example. <command>tin</command> will then keep all thread databases below
<filename>/var/spool/news/.index</filename>. For any file access or shell
escape, it will reset its effective uid to the real uid of the user who
invoked it.<footnote id="X-087-2-FNNR03"><para>
This is the reason why you will get ugly error messages when invoking
<command>tin</command> as superuser. But you shouldn't do routine work as
<systemitem role="userid">root</systemitem>, anyway.
</para>
</footnote>
</para>
<para>
The version of <command>tin</command> included in some Linux distributions
is compiled without NNTP support, but most do have it now. When invoked as
<command>rtin</command> or with the <option>&ndash;r</option> option,
<command>tin</command> tries to connect to the NNTP server specified in
the file <filename>/etc/nntpserver</filename> or in the
<systemitem class=environvar>NNTPSERVER</systemitem> environment variable.
The <filename>nntpserver</filename> file simply contains the server's name
on a single line.
<indexterm><primary sortas="etc/nntpserver file">/etc/nntpserver file</primary></indexterm>
<indexterm><primary>NNTPSERVER environment variables</primary></indexterm>
<indexterm><primary>environment variables</primary><secondary>NNTPSERVER</secondary></indexterm>
</para>
</sect1>
<sect1 id="X-087-2-newsreaders.trn"><title>trn Configuration</title>
<indexterm><primary>newsreaders</primary><secondary>trn</secondary></indexterm>
<indexterm><primary>trn newsreader, configuration</primary></indexterm>
<para>
<?troff .hw Davidson>
<command>trn</command> is also the successor to an older newsreader, namely
<command>rn</command> (which means <emphasis>read news</emphasis>). The
&ldquo;t&rdquo; in its name stands for &ldquo;threaded.&rdquo; It was
written by Wayne Davidson.
</para>
<para>
<indexterm><primary>newsreaders</primary><secondary>creating thread databases</secondary></indexterm>
Unlike <command>tin</command>, <command>trn</command> has no provision for
generating its threading database at runtime. Instead, it uses those prepared
by a program called <command>mthreads</command> that has to be invoked
regularly from <command>cron</command> to update the index files.
</para>
<para>
<indexterm><primary>mthreads program</primary></indexterm>
You can still access new articles if you're not running
<command>mthreads</command>, but you will have all those
&ldquo;A GENUINE INVESTMENT OPPORTUNITY&rdquo; articles scattered across your
article selection menu, instead of a single thread you may easily skip.
</para>
<para>
To turn on threading for particular newsgroups, invoke
<command>mthreads</command> with the list of newsgroups on the command line.
The format of the list is the same as the one in the C News
<filename>sys</filename> file:
<screen>
$ <userinput>mthreads &rsquo;comp,rec,!rec.games.go&rsquo;</userinput>
</screen>
</para>
<para>
This command enables threading for all of
<systemitem role="newsgroup">comp</systemitem> and
<systemitem role="newsgroup">rec</systemitem>, except for
<systemitem role="newsgroup">rec.games.go</systemitem> (people who play Go don't
need fancy threads). After that, you simply invoke <command>mthreads</command>
with no options at all to make it thread any newly arrived articles. Threading
of all groups found in your <filename>active</filename> file can be turned on
by invoking <command>mthreads</command> with a group list of
<systemitem role="newsgroup">all</systemitem>.
</para>
<para>
If you're receiving news during the night, you will customarily run
<command>mthreads</command> 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 <command>mthreads</command> in daemon mode. When it is started at boot
time using the <option>&ndash;d</option> 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 <command>mthreads</command> in daemon
mode, put the following line in your <filename>rc.news</filename> script:
<screen>
/usr/local/bin/rn/mthreads -deav
</screen>
</para>
<para>
The <option>&ndash;a</option> option makes <command>mthreads</command>
automatically turn on threading for new groups as they are created;
<option>&ndash;v</option> enables verbose log messages to the
<command>mthreads</command> log file <filename>mt.log</filename> in
the directory where you have <command>trn</command> installed.
</para>
<para>
<indexterm><primary>C News</primary><secondary>update low water mark</secondary></indexterm>
<indexterm><primary>news (network)</primary><secondary>expiration of</secondary></indexterm>
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.<footnote id="X-087-2-FNNR04"><para>
Note that C News (described in <xref linkend="X-087-2-cnews">) doesn't update
this low-water mark automatically; you have to run <command>updatemin</command>
to do so.
</para>
</footnote>
Articles above this number that have been expired (because the
oldest article has been assigned a long expiration date by an
<replaceable>Expires:</replaceable> header field) may nevertheless be removed by giving
<command>mthreads</command> the <option>&ndash;e</option> option to force an
&ldquo;enhanced&rdquo; expiry run. When <command>mthreads</command> is running
in daemon mode, the <option>&ndash;e</option> option makes
<command>mthreads</command> put in such an enhanced expiry run once a day,
shortly after midnight.
</para>
</sect1>
<sect1 id="X-087-2-newsreaders.nn"><title>nn Configuration</title>
<indexterm><primary>newsreaders</primary><secondary>nn</secondary></indexterm>
<indexterm><primary>nn newsreader, configuration</primary></indexterm>
<indexterm><primary>Storm, Kim F.</primary></indexterm>
<para>
<command>nn</command>, written by Kim F. Storm, claims to be a newsreader
whose ultimate goal is not to read news. Its name stands for
&ldquo;No News,&rdquo; and its motto is
&ldquo;No news is good news. <command>nn</command> is better.&rdquo;
</para>
<para>
To achieve this ambitious goal, <command>nn</command> 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 <command>nnadmin</command>, 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.
</para>
<para>
<indexterm><primary>newsreaders</primary><secondary>creating thread databases</secondary></indexterm>
The <command>nn</command> threads database manager is called
<command>nnmaster</command>. It is usually run as a daemon, started from an
<filename>rc</filename> file at boot time. It is invoked as:
<screen>
/usr/local/lib/nn/nnmaster -l -r -C
</screen>
</para>
<para>
This enables threading for all newsgroups present in your
<filename>active</filename> file.
</para>
<para>
<indexterm><primary>cron</primary><secondary>running</secondary><tertiary>nnmaster via</tertiary></indexterm>
Equivalently, you may invoke <command>nnmaster</command> periodically from
<command>cron</command>, giving it a list of groups to act upon. This list is
very similar to the subscription list in the <filename>sys</filename> file,
except that it uses blanks instead of commas. Instead of the fake group name
<emphasis role="bold">all</emphasis>, an empty argument of <literal>""</literal> should be
used to denote all groups. A sample invocation looks like this:
<screen>
# <userinput>/usr/local/lib/nn/nnmaster !rec.games.go rec comp</userinput>
</screen>
</para>
<para>
Note that the order is significant. The leftmost group specification that
matches always wins. Thus, if we had put
<systemitem role="keyword">!rec.games.go</systemitem> after
<systemitem role="keyword">rec</systemitem>, all articles from this group
would have been threaded nevertheless.
</para>
<para>
<indexterm><primary>news (network)</primary><secondary>expiration of</secondary></indexterm>
<command>nn</command> 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 <command>nnmaster</command> with the <option>&ndash;E</option> option.
It is reasonably quick, unless you're doing this via NNTP.
</para>
<para>
The second method behaves exactly like a default expiration run of
<command>mthreads</command>; it removes only those entries that refer
to articles with numbers below the low-water mark in the
<filename>active</filename> file. It may be enabled using the
<option>&ndash;e</option> option.
</para>
<para>
Finally, the third strategy discards the entire database and recollects all
articles. It may be enabled using the <option>&ndash;E3</option> option.
</para>
<para>
The list of groups to be expired is given by the <option>&ndash;F</option>
option in the same fashion as above. However, if you have
<command>nnmaster</command> running as daemon, you must kill it (using
<option>&ndash;k</option>) 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:
<screen>
# <userinput>nnmaster -kF ""</userinput>
# <userinput>nnmaster -lrC</userinput>
</screen>
</para>
<para>
There are many more flags that fine-tune the <command>nn</command>'s
behavior. If you are concerned about removing bad articles or
assembling article digests, read the <command>nnmaster</command> manual page.
</para>
<para>
<command>nnmaster</command> relies on a file named <filename>GROUPS</filename>,
which is located in <filename>/var/lib/nn</filename>. If it does not exist
when <command>nnmaster</command> 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.<footnote id="X-087-2-FNNR05"><para>
Their order has to agree with that of the entries in the
(binary) <filename>MASTER</filename> file.
</para>
</footnote> The flags allowed and
their effects are detailed in the <command>nnmaster</command> manual page, too.
<indexterm class="endofrange" startref="chnr.newsrdr.config">
<indexterm class="endofrange" startref="chnr.config.newsrdr">
</para>
</sect1>
</chapter>