makehistory

title: makehistory(8)

text:
# makehistory(8)

## NAME
makehistory - Initialize or rebuild INN history database

## SYNOPSIS
makehistory [-abFIOSx] [-f filename] [-l count] [-L load-average] [-s size] [-T tmpdir]

## DESCRIPTION
makehistory rebuilds the history(5) text file, which contains a list of message-IDs of articles already seen by the server. It can also be used to rebuild the overview database. Note that even though the dbz indices for the history file are also rebuilt by makehistory, it is useful to run makedbz(8) after makehistory(8) in order to improve the efficiency of the indices (makehistory does not know how large to make the hash table at first run, unless the size is given by the -s flag).

The default location of the history text file is pathdb/history; to specify an alternate location, use the -f flag.

By default, makehistory will scan the entire spool, using the storage manager, and write a history line for every article. To also generate overview information, use the -O flag.

If a malformed article is found in the news spool, in a way which prevents its integration into the history or overview data, a log line will be output and the malformed article will just be skipped.

## OVERVIEW REBUILD
WARNING: If you're trying to rebuild the overview database, be sure to stop innd(8) and delete or zero out the existing database before you start for the best results. An overview rebuild should not be done while the server is running. Unless the existing overview is deleted, you may end up with problems like out-of-order overview entries, excessively large overview buffers, and the like.

If ovmethod in inn.conf is "ovdb", you must have the ovdb processes running while rebuilding overview. ovdb needs them available while writing overview entries. You can start them by hand separate from the rest of the server by running ovdb_init; see ovdb_init(8) for more details.

Similarly, if ovmethod in inn.conf is "ovsqlite", you must have the ovsqlite-server process running while rebuilding overview. See ovsqlite-server(8) for more details and how to start it by hand.

Rebuilding overview data is as straight-forward as:

1.

Checking that the configuration file of the new overview storage method is present in pathetc and fits your needs (buffindexed.conf, ovdb.conf or ovsqlite.conf). Note that the tradindexed overview storage method does not have a dedicated configuration file.

2.

Making sure that INN is stopped ("rc.news stop" as the news user, or whichever command you're using).

3.

Setting the new overview storage method in the ovmethod parameter in inn.conf.

4.

Making sure that the directory specified by the pathoverview parameter in inn.conf exists and is empty (or contains freshly created buffindexed buffers, if using that overview storage method). Otherwise, rename the current directory (to backup existing overview data) and re-create pathoverview as the news user.

5.

Starting ovdb_init or ovsqlite-server as the news user if the new overview storage method is respectively ovdb or ovsqlite.

6.

Running "makehistory -O -x -F" and waiting for the command to finish. (You may notice a few logs about articles for which overview data cannot be inserted into the new overview storage method. As long as there aren't tons of them, it is normal, notably because there is an internal limit in the length of overview data generated by makehistory, contrary to innd. Unfortunately, these rare articles won't be present in the new overview.)

7.

Stopping ovdb or ovsqlite helper programs if you started them during the previous steps (running "rc.news stop" as the news user will stop them; do not mind the messages related to the fact that the news server was not running).

8.

Starting INN and checking the logs to make sure everything is fine. You will normally notice that the active file is renumbered (rc.news takes care of that when run after an overview rebuild; otherwise, manually run "ctlinnd renumber ''").

## OPTIONS
-a

Append to the history file rather than generating a new one. If you append to the main history file, make sure innd(8) is throttled or not running, or you can corrupt the history.

-b

Delete any messages found in the spool that do not have valid Message-ID header fields in them.

-F

Fork a separate process to flush overview data to disk rather than doing it directly. The advantage of this is that it allows makehistory to continue to collect more data from the spool while the first batch of data is being written to the overview database. The disadvantage is that up to twice as much temporary disk space will be used for the generated overview data. This option only makes sense in combination with -O. With buffindexed, the overchan program is invoked to write overview.

-f filename

Rather than writing directly to pathdb/history, instead write to filename, also in pathdb.

-I

Don't store overview data for articles numbered lower than the lowest article number in active. This is useful if there are for whatever reason old articles on disk that shouldn't be available to readers or put into the overview database.

-l count

This option specifies how many articles to process before writing the accumulated overview information out to the overview database. The default is 10000. Since overview write performance is faster with sorted data, each "batch" gets sorted. Increasing the batch size with this option may further improve write performance, at the cost of longer sort times. Also, temporary space will be needed to store the overview batches. At a rough estimate, about 300 * count bytes of temporary space will be required (not counting temp files created by sort(1)). See the description of the -T option for how to specify the temporary storage location. This option has no effect with buffindexed, because buffindexed does not need sorted overview and no batching is done.

-L load-average

Temporarily pause activities if the system load average exceeds the specified level load-average. This allows makehistory to run on a system being used for other purposes without monopolizing system resources and thus making the response time for other applications unacceptably slow. Using nice(1) does not help much for that because the problem comes from disk I/O usage, and ionice(1) is not always available or efficient.

-O

Create the overview database as well as the history file. Overview information is only required if the server supports readers; it is not needed for a transit-only server (see enableoverview in inn.conf(5)). If you are using the buffindexed overview storage method, erase all of your overview buffers before running makehistory with -O.

-S

Rather than storing the overview data into the overview database, just write it to standard output in a form suitable for feeding to overchan later if wished. When this option is used, -F, -I, -l, and -T are ignored. This option only makes sense in combination with -O.

-s size

Size the history database for approximately size key-value pairs (i.e. lines in history). Accurately specifying the size is an optimization that will create a more efficient database. (The size should be the estimated eventual number of articles, typically the size of the old history file, in lines.) By default, makehistory will create a database optimized for handling about 6,000,000 articles (or 500,000 if the slower tagged hash format is used). This size does not limit the number of articles the news server can store in its history file. It will just get slower when that optimal size is exceeded, until the next run of news.daily which will appropriately resize it.

-T tmpdir

If -O is given, makehistory needs a location to write temporary overview data. By default, it uses pathtmp, set in inn.conf, but if this option is given, the provided tmpdir is used instead. This is also used for temporary files created by sort(1) (which is invoked in the process of writing overview information since sorted overview information writes faster). By default, sort usually uses your system temporary directory; see the sort(1) man page on your system to be sure.

-x

If this option is given, makehistory won't write out history file entries. This is useful mostly for building overview without generating a new history file.

## EXAMPLES
Here's a typical example of rebuilding the entire history and overview database, removing broken articles in the news spool. This uses the default temporary file locations and should be done while innd isn't running (or is throttled).

```
    makehistory -b -f history.n -O -l 30000 -I
```

This will rebuild the overview (if using buffindexed, erase the existing overview buffers before running this command) and leave a new history file as "history.n" in pathdb. To preserve all of the history entries from the old history file that correspond to rejected articles or expired articles, follow the above command with:

```
    cd <pathdb>
    awk 'NF == 2 { print }' < history >> history.n
```

(replacing the path with your pathdb, if it isn't the default). Then look over the new history file for problems and run:

```
    makedbz -s `wc -l < history.n` -f history.n
```

Then rename all of the files matching "history.n.*" to "history.*", replacing the current history database and indices. After that, it's safe to unthrottle innd.

For a simpler example:

```
    makehistory -b -f history.n -I -O
```

will scan the spool, removing broken articles and generating history and overview entries for articles missing from history.

To pre-size the history file for 100,000,000 articles, and generate overview data at the same time, you may directly use the following command:

```
    makehistory -O -s 100000000
```

You then do not need running makedbz as the history file has already been generated and optimized for the expected number of articles.

To just rebuild overview:

```
    makehistory -O -x -F
```

## FILES
pathdb/history

This is the default output file for makehistory.

pathtmp

Where temporary files are written unless -T is given.

## HISTORY
Originally written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews and updated by various other people since.

## SEE ALSO
active(5), ctlinnd(8), history(5), inn.conf(5), innd(8), libinn_dbz(3), makedbz(8), ovdb_init(8), overchan(8), ovsqlite-server(8).


mod-active

package: inn

title: mod-active(8)

text:
# mod-active(8)

## NAME
mod-active - Batch processing of newsgroups creation and removal commands

## SYNOPSIS
mod-active [ctlinnd-command-file ...]

## DESCRIPTION
mod-active is a Perl script that updates the active file based on its input lines of ctlinnd "newgroup", "rmgroup" and "changegroup" commands. It pauses the server briefly while the existing active file is read and rewritten, which not only keeps innd from updating the active file but also locks against other instances of mod-active.

The script must be run as the news user.

The input to mod-active can come either from one or more ctlinnd-command-file files named on the command line, or from the standard input. Typically its input is the output from the docheckgroups or actsync commands. Every line which contains the string "ctlinnd newgroup", "ctlinnd rmgroup", or "ctlinnd changegroup", optionally preceded by whitespace and/or the path to ctlinnd, is noted for the update. Redundant commands, such as a newgroup directive for a group that already exists, are silently ignored. All other lines in the input are also silently ignored. After the new active file has been generated, the existing one is renamed to active.old and the new one is moved into place. The script then displays the differences between the two files. Any groups that were added to the active file are also added to the active.times file with the string "checkgroups-update".

Please note that no syntax checking is performed on group names by mod-active.

## BUGS
Though innd is paused while mod-active works, it is not inconceivable that there could be a conflict if something else tries to update the active file during the relatively short time that mod-active is working. The two most realistic ways for this to happen are either by an administrator concurrently doing a manual ctlinnd command, or by innd receiving a control message, then mod-active pausing the server, then the control message handler script that innd forked running its own ctlinnd command while mod-active is working. Note that such scenarios are very unlikely to happen.

## HISTORY
Written by David C Lawrence <tale@isc.org> for InterNetNews. Converted to POD by Julien Elie.

## SEE ALSO
active(5), active.times(5), actsync(8), ctlinnd(8), docheckgroups(8), innd(8).

branch: sisyphus


news.daily

title: news.daily(8)

summary: Perform daily Usenet maintenance tasks

text:
# news.daily(8)

## NAME
news.daily - Perform daily Usenet maintenance tasks

## SYNOPSIS
news.daily [delayrm] [expctl=path] [expdir=path] [expireover] [expireoverflags=args] [flags=args] [lowmark] [mailto=address] [noexpire] [noexpireover] [noexplog] [nologs] [nomail] [noprocbatch] [norenumber] [norm] [norotate] [nostat] [notdaily] [postexec=program] [procbatchdir=path] [tmpdir=path] [/path/to/a/program]

## DESCRIPTION
news.daily performs a number of important Usenet administrative functions. This includes:

- producing a status report with innstat;

- removing old news articles (with expirerm if the delayrm keyword is specified);

- purging the overview database with expireover (if the corresponding eponym keyword is specified or if enableoverview is true in inn.conf);

- processing log files and rotating the archived log files with scanlogs;

- processing innfeed dropped files with procbatch;

- processing spooled messages with rnews invoked with the -U flag;

- renumbering the active file with ctlinnd;

- rebuilding the history file with expire;

- removing any old socket files found in the pathrun directory;

- collecting all the output and mailing it.

Please note that this program should be run under the news administrator's account (usually "news"), not as root. By default, news.daily performs all of its functions and mails the output to the news administrator, which is the user specified with --with-news-master at configure time (it is "usenet" by default). You can also change this behaviour with the mailto keyword.

By specifying keywords on the command line, it is possible to modify the functions performed, as well as change the arguments given to expire(8) and expireover(8). news.daily should be run once a day, typically out of cron(8). Since it will slow the server down while it is running, it should be run during periods of low server usage, such as in the middle of the night. To run it at 3am, for example, add the following entry to the news user's crontab file:

```
    0 3 * * * <pathbin in inn.conf>/news.daily expireover lowmark
```

If you're using any non-CNFS storage methods, add the delayrm keyword to the above option list for news.daily.

It may be run more often, but such invocations should at least use the norotate keyword (or perhaps the notdaily keyword) to prevent the log files from being processed and rotated too fast. The shlock(1) program is used to prevent simultaneous executions.

The program specified by the given path /path/to/a/program is executed just before any expiration is done. A typical use is to specify an alternate expiration program and use the noexpire keyword. Multiple programs may be specified; they will be invoked in order.

## KEYWORDS
The following keywords may be used:

delayrm

This uses the -z flag when invoking expire and expireover. The names of articles to be removed are written to a temporary file, and then renamed after expiration by calling expirerm which in turn calls fastrm.

expctl=path

Specify the file to use as the expire.ctl file for expire.

expdir=path

By default, expire builds the new history file and database in the same directory as the current files. Using this keyword specifies a different location to build the new files (by passing the -d flag to expire), which will then be moved to the right location when finished.

expireover

The expireover program is called after expiration to purge the overview database. If no overview data is created, the expireover keyword is not needed. This is the case when the server runs only for feeders (no reader). By default, expireover is not called by news.daily unless enableoverview is set to true in inn.conf.

expireoverflags=args

If the expireover keyword is used, this keyword may be used to specify the flags to be passed to expireover. If the delayrm keyword is used, then the default value is -z and the list of deleted files; otherwise, the default value is -s.

flags=args

By default, expire is invoked with argument -v1. Using this keyword changes the arguments to those specified. Be careful to use quotes if multiple arguments are needed. This keyword has no effect if the noexpire keyword is used.

lowmark

If the lowmark keyword is used, "ctlinnd lowmark" is used for renumbering active. Normal "ctlinnd renumber" operation will take long time. With the lowmark keyword, this will take less time. If the lowmark keyword is used, the norenumber keyword is not needed since news.daily specifies it implicitly. If the lowmark keyword is given to news.daily, then the expireover keyword must also be given; otherwise, that kind of renumbering will not be taken into account.

mailto=address

By default, news.daily mails the report to the newsmaster address specified with --with-news-master at configure time. The mailto keyword can specify a different address to which to mail the report. Note that using this keyword has no effect if the nomail keyword is also specified.

noexpire

By default, expire is invoked to remove old news articles. Using this keyword disables this function.

noexpireover

By default, expireover is invoked to remove old overview database if enableoverview is set in inn.conf. Using this keyword disables this function.

noexplog

expire normally appends information to pathlog/expire.log (see newslog(5)). Using this keyword causes the expire output to be handled as part of news.daily's output. It has no effect if the noexpire keyword is used.

nologs

After expiration, scanlogs is invoked to process the log files. Using this keyword disables all log processing functions.

nomail

news.daily normally sends a mail message containing the results to the administrator. Using this keyword causes this message to be sent to stdout and stderr instead. Normally, all utilities invoked by the script have their stdout and stderr redirected into a file. If the file is empty, no message is sent.

noprocbatch

This keyword disables the run of procbatch on innfeed dropped files generated in its spool directory. These files contain a list of articles which were not correctly sent to peers. By default, they will be processed and removed afterwards.

norenumber

This keyword disables the "ctlinnd renumber" operation. Normally, the low water marks for all newsgroups are reset in the active file.

norm

By default, any ctlinnd socket that has not been modified for two days will be removed. Using this keyword disables this function.

norotate

By default, log processing includes rotating and cleaning out log files. Using this keyword disables the rotating and cleaning aspect of the log processing: the logs files are only scanned for information and no contents are altered. This keyword has no effect if the nologs keyword is used. The norotate keyword is passed on to scanlogs if it is invoked.

nostat

This keyword disables the status report generated by innstat. Without this keyword, the status report is the first function performed, just prior to obtaining the news.daily lock.

notdaily

By default, news.daily expects to be run only once a day, and it does various things (like rotating logs) that normally should only be done on daily basis. Use this keyword any extra times news.daily is run in the day and the normal log files processing (and rotation) will not be done. This keyword implies nologs.

postexec=program

The program specified by the given path program is executed just after all expiration is done. Multiple programs may be specified; they will be invoked in order.

procbatchdir=path

news.daily tries to find the backlog directory of innfeed in innfeed.conf and innfeed-delayed.conf. In case several instances of innfeed are running or when its configuration file is not the default one, the procbatchdir keyword can be used to specify the path of the backlog directory. This keyword can be used more than once in the command-line, permitting specifying several backlog directories.

tmpdir=path

Overrides the pathtmp setting in inn.conf by setting the environment variable $TMPDIR to the specified path. Various parts of the expire process, such as sort, will then use this path as the directory for temporary files.

## HISTORY
news.daily and this manual page were written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. It was converted to POD by Julien Elie.

## SEE ALSO
active(5), ctlinnd(8), expire(8), expire.ctl(5), expireover(8), expirerm(8), fastrm(1), inn.conf(5), innstat(8), newslog(5), procbatch(8), scanlogs(8), shlock(1).


title: news2mail(8)

summary: Channel script to gateway news into e\-mails

text:
# news2mail(8)

## NAME
news2mail - Channel script to gateway news into e-mails

## SYNOPSIS
news2mail

## DESCRIPTION
news2mail runs as a channel process underneath innd. It is set up as channel feed in newsfeeds, with different mailing-lists as funnel entries pointing to it (see below); news2mail expects the token of an article followed by a sequence of list names.

news2mail uses the configuration file pathetc/news2mail.cf to map mailing-list names to e-mail addresses. news2mail causes the mail transport agent (usually sendmail, as set in the mta parameter in inn.conf) to queue the messages for later delivery (to avoid DOS attacks by mass postings). You must run "sendmail -q" periodically to get the queue processed.

## CONFIGURATION FILE
The configuration file format is simple: comments (starting with a hash sign "#") and blank lines are ignored. All other lines have two or three fields on them. The first is the list name and is what innd uses (i.e. the site field of the entry in the newsfeeds file). The second field is the actual e-mail address to send the article to. The third field is optional: it sets the envelope-from address (for instance a list member's address; if not set, it defaults to the "news" user).

In e-mail messages, the To header field body will have the mailing-list address (i.e. the second field). Besides, news2mail strips most article header fields from the article before mailing.

In newsfeeds, the channel feed should look like:

```
    news2mail!:!*:Ac,Tc,Wn*:<pathbin>/news2mail
```

and for each mailing-list, you only have to add to newsfeeds an entry list like:

```
    list-big-red-ants/lists.ucsd.edu\
        :!*,rec.pets.red-ants\
        :Ap,Tm:news2mail!
```

Please note the use of "Ap" and the exclusion of the list owner domain to protect the list from feeding back new arrivals from the list. The site name used in the newfeeds entry for a mailing-list (above "list-big-red-ants") must be the same as the first field in an entry in news2mail.cf. For instance:

```
    # newsfeeds-name   list-to-address      [list-sender-address]
    list-big-red-ants  ants@lists.ucsd.edu  news+ants@news.server.org
```

## FILES
pathbin/news2mail

The Perl program itself used to gateway news into e-mails.

pathetc/news2mail.cf

The configuration file which specifies the mapping to use for gatewaying.

## BUGS
The news2mail program is set up as a funnelled channel in newsfeeds, implying multiple matches should be handled as one - and multiple matching funnelled feeds will result in a single call to the script. Therefore, since only one mail is sent, crossposts are not currently properly handled as for the envelope-from address (which then defaults to the "news" user).

## HISTORY
news2mail was written by Brian Kantor in 1998. This man page was written by James Brister and converted to POD by Julien Elie. The third optional field in news2mail.cf was added by D. Stussy in 2008.

## SEE ALSO
innd(8), newsfeeds(5).


ninpaths

title: ninpaths(8)

text:
# ninpaths(8)

## NAME
ninpaths - Report Usenet Path header field statistics (new inpaths)

## SYNOPSIS
ninpaths -p -d dumpfile

ninpaths -r site -u dumpfile [-u dumpfile ...] -v level

## DESCRIPTION
This is an efficient and space-saving inpaths reporting program. It works as follows: you feed it the Path header fields via an INN channel feed or some other similar method, and from time to time the program writes all its internal counters accumulated so far to a dump file. Another instance of the program picks up all the dump files, adds them up and formats them into the report. The purpose of the final report is to summarize the frequency of occurrence of sites in the Path header fields of articles.

Some central sites accumulate the Path header field data from many news servers running this program or one like it, and then report statistics on the most frequently seen news servers in Usenet article Path header fields. The sendinpaths script can be run daily to mail the accumulated statistics to such a site and remove the old dump files.

You can get a working setup by doing the following:

1.

Create a directory at pathlog/path (replacing pathlog here and in all steps that follow with the full path to your INN log directory). Do not change the name of the "path" subdirectory because it is used by sendinpaths.

2.

Set up a channel feed using a newsfeeds entry like:

```
    inpaths!\
        :*\
        :Tc,WP:<pathbin>/ninpaths -p -d <pathlog>/path/inpaths.%d

```

if your version of INN supports "WP" (2.0 and later all do). Replace <pathbin> with the full path to your INN binaries directory, and <pathlog> with the full path to your INN log directory.

Note that the naming convention of the generated inpaths dump files should not be changed. sendinpaths explicitly searches files whose name starts with "inpaths." in the <pathlog>/path directory.

3.

Run the following command to start logging these statistics:

```
    ctlinnd reload newsfeeds 'inpaths feed setup'

```

4.

Enter into your news user crontab these two lines:

```
    6   6 * * *   <pathbin>/ctlinnd flush inpaths!
    10  6 * * *   <pathbin>/sendinpaths

```

(the actual time doesn't matter). This will force ninpaths to generate a dump file once a day. Then, a few minutes later, sendinpaths collects the dumps, makes a report, sends the collected statistics, and deletes the old dumps.

Note that you can manually generate a report without mailing it, and without deleting processed dump files, with "sendinpaths -n". Another useful command is "sendinpaths -c" so as to receive a copy of the e-mail sent by sendinpaths and therefore make sure that everything is properly set.

5.

In a couple of days, check that your daily statistics properly appear in <http://top1000.anthologeek.net/>.

## OPTIONS
-d dumpfile

Save dumps in dumpfile. Any %d in dumpfile will be replaced with the current system time when the dump is made. This option should be used with -p. If dumpfile is "-", then stdout is used. The format of these dump files is described below.

-p

Read Path header fields from standard input.

-r site

Generate a report for site. Generally site should be the value of pathhost from inn.conf.

-u dumpfile

Read data from dumpfile. This option can be repeated to read data from multiple dump files.

-v level

Set the verbosity level of the report. Valid values for level are 0, 1, and 2, with 2 being the default.

## DUMP FILE FORMAT
The format of the generated dump files is:

```
   !!NINP <version> <start-time> <end-time> <nb-sites> <nb-articles>
       <average-time>
   <site_0> <count_0> <site_1> <count_1> <site_2> <count_2> ...
   !!NLREC
   :<site_a>!<site_b>,<count_ab>:<site_c>!<site_d>,<count_cd> ...
   !!NEND <nb-relations>
```

where times are UNIX timestamps. Then, nb-sites records follow. Each record is separated by a space or a new line, and consists of a host name site_n followed by a number of appearances count_n. The number of processed Path header fields is nb-articles.

Afterwards, nb-relations relations follow. In 3.0.x versions, the relations are separated by a space or a new line, and their syntax is "site_a!site_b!count_ab" where site_a and site_b are numbers of the site records starting at 0.

In 3.1.x versions, the relations begin with a colon and are separated by either nothing or a new line. Their syntax is ":site_a!site_b,count_ab" with the same meaning as in previous versions. The count can be omitted when it is 1. More than two sites can be specified in the relation (":site_a!site_b!site_c,count_abc").

For instance:

```
    !!NINP 3.1.1 1302944821 1302944838 5 2 1302944826
    newsgate.cistron.nl 1 news.trigofacile.com 2 news.ecp.fr 2
        usenet.stanford.edu 1
    bleachbot 1
    !!NLREC
    :3!2:2!1,2:4!0:0!2
    !!NLEND 4
```

where the two processed Path header fields are:

```
    Path: news.trigofacile.com!news.ecp.fr!usenet.stanford.edu
        !not-for-mail
    Path: news.trigofacile.com!news.ecp.fr!newsgate.cistron.nl
        !bleachbot!not-for-mail
```

## NOTES
If your INN doesn't have the "WP" feed flag (1.5 does not, 1.6 and 1.7 do, 2.0 and later all do), use the following newsfeeds entry:

```
   inpaths!:*:Tc,WH:<pathbin>/ginpaths
```

where ginpaths is the following script:

```
    #!/bin/sh
    exec egrep '^Path: ' \
        | <pathbin>/ninpaths -p -d <pathlog>/path/inpaths.%d
```

replacing <pathbin> and <pathlog> as above.

## HISTORY
This is a slightly modified version of Olaf Titz's original ninpaths program, which is posted to alt.sources and kept on his WWW archive under <http://sites.inka.de/~bigred/sw/>.

The idea and some implementation details for ninpaths come from the original inpaths program, but most of the code has been rewritten for clarity. This program is in the public domain.

## SEE ALSO
newsfeeds(5), sendinpaths(8).


nnrpd

title: nnrpd(8)

summary: NNTP server for reader clients

text:
# nnrpd(8)

## NAME
nnrpd - NNTP server for reader clients

## SYNOPSIS
nnrpd [-BDfnoSt] [-4 address] [-6 address] [-b address] [-c configfile] [-i initial] [-I instance] [-p port] [-P prefork] [-r reason] [-s padding]

## DESCRIPTION
nnrpd is an NNTP server for newsreaders. It accepts commands on its standard input and responds on its standard output. It is normally invoked by innd(8) with those descriptors attached to a remote client connection. nnrpd also supports running as a standalone daemon.

Unlike innd(8), nnrpd supports all NNTP commands for user-oriented reading and posting. nnrpd uses the readers.conf file to control who is authorized to access the Usenet database.

On exit, nnrpd will report usage statistics through syslog(3).

nnrpd is run from innd (the default) or from inetd(8), xinetd(8), or some equivalent. As often as not, it is also run as a daemon, with the -D option, to provide TLS support on a dedicated port.

nnrpd only reads config files (readers.conf, inn.conf and inn-secrets.conf) when it is spawned. You can therefore never change the behaviour of a client that's already connected. As a new nnrpd process is spawned for every connection, any changes to these configuration files will be immediately effective for all new connections. There's only one exception: when nnrpd is run as a daemon with the -D option, any configuration changes in inn.conf won't take effect until nnrpd is restarted.

The inn.conf setting nnrpdflags can be used to pass any of the options below to instances of nnrpd that are spawned directly from innd. Many options only make sense when -D is used, so these options should not be used with nnrpdflags. See also the discussion of nnrpdflags in inn.conf(5).

When nnrpdloadlimit in inn.conf is not 0, it will also reject connections if the load average is greater than that value (typically 16). nnrpd can also prevent high-volume posters from abusing your resources. See the discussion of exponential backoff in inn.conf(5).

nnrpd injects articles into the local server running innd through a UNIX domain socket, or an INET domain socket if not supported. If another server should be used for injection, you can set it with the nnrpdposthost parameter in inn.conf. In case authentication credentials are requested during the injection, nnrpd will use the passwd.nntp file in pathetc.

## OPTIONS
-4 address

The -4 parameter instructs nnrpd to bind to the specified IPv4 address when started as a standalone daemon using the -D flag. This has to be a valid IPv4 address belonging to an interface of the local host. It can also be 0.0.0.0, saying to bind to all addresses (this is the default).

-6 address

The -6 parameter instructs nnrpd to bind to the specified IPv6 address when started as a standalone daemon using the -D flag. This has to be a valid IPv6 address belonging to an interface of the local host. It can also be "::0", saying to bind to all IPv6 addresses. By default, nnrpd in daemon mode listens to both IPv4 and IPv6 addresses. With this option, it will listen only to the specified IPv6 addresses. On some systems however, a value of "::0" will cause it to listen to all IPv4 addresses as well.

-b address

Similar to the -4 flag. -b is kept for backwards compatibility.

-B

If specified, nnrpd will report login attempts to blacklistd(8) for automatic blocking after a number of failed attempts. To use this flag, the blacklist library must have been found at configure time, or --with-blacklist specified at configure time. For more information, see "BLACKLISTD SUPPORT" below.

-c configfile

By default, nnrpd reads the readers.conf configuration file to determine how to authenticate connections. The -c flag specifies an alternate file for this purpose. If the file name isn't fully qualified, it is taken to be relative to pathetc in inn.conf. (This is useful to have several instances of nnrpd running on different ports or IP addresses with different settings.)

-D

If specified, this parameter causes nnrpd to operate as a daemon. That is, it detaches itself and runs in the background, forking a process for every connection. By default, nnrpd listens on the NNTP port (119), so either innd(8) has to be started on another port or the -p parameter used. Note that with this parameter, nnrpd continues running until killed. This means that it reads inn.conf once on startup and never again until restarted. nnrpd should therefore be restarted if inn.conf is changed. When started in daemon mode, nnrpd will write its PID into a file in the pathrun directory. The file will be named nnrpd.pid if nnrpd listens on port 119 (default), or nnrpd-%d.pid, where %d is replaced with the port that nnrpd is configured to listen on (-p option is given and its argument is not 119).

You may also want to use -s when running nnrpd as a daemon.

-f

If specified, nnrpd does not detach itself and runs in the foreground when started as a standalone daemon using the -D flag.

-i initial

Specify an initial command to nnrpd. When used, initial is taken as if it were the first command received by nnrpd. After having responded, nnrpd will close the connection.

-I instance

If specified, instance is used as an additional static portion within Message-IDs generated by nnrpd, when virtualhost is set in access groups in readers.conf; typically this option would be used where a cluster of machines exist with the same virtual hostname and must be disambiguated during posts.

-n

The -n flag turns off resolution of IP addresses to names. If you only use IP-based restrictions in readers.conf and can handle IP addresses in your logs, using this flag may result in some additional speed.

-o

The -o flag causes all articles to be spooled instead of sending them to innd(8). rnews with the -U flag should be invoked from cron on a regular basis to take care of these articles. This flag is useful if innd is accepting articles and nnrpd is started standalone or using inetd(8).

-p port

The -p parameter instructs nnrpd to listen on port when started as a standalone daemon using the -D flag.

-P prefork

The -P parameter instructs nnrpd to prefork prefork children awaiting connections when started as a standalone daemon using the -D flag.

-r reason

If the -r flag is used, then nnrpd will reject the incoming connection giving reason as the text. This flag is used by innd(8) when it is paused or throttled. reason should be encoded in UTF-8.

-s padding

As each command is received from a client, nnrpd tries to change its "argv" array containing the process title so that commands like ps(1) will print out the hostname of the connected client and the command being executed. To get a full display, the -s flag may be used with a long string as its argument, which will be overwritten when nnrpd changes its title. When innd spawns nnrpd, this flag is used with an argument made of 48 spaces.

-S

If specified, nnrpd will start a negotiation for a TLS session as soon as connected. To use this flag, the OpenSSL SSL and crypto libraries must have been found at configure time, or --with-openssl specified at configure time. For more information on running nnrpd with TLS support, see "TLS SUPPORT".

-t

If the -t flag is used, then all client commands and initial responses will be traced by reporting them in syslog. This flag is set by innd(8) under the control of the ctlinnd(8) "trace" command, and is toggled upon receipt of a SIGHUP; see signal(2).

## TLS SUPPORT
If INN is built with --with-openssl or if the OpenSSL SSL and crypto libraries are found at configure time, nnrpd will support news reading over TLS (also known as SSL). For clients that use the STARTTLS command, no special configuration is needed beyond creating a TLS/SSL certificate for the server. You should do this in exactly the same way that you would generate a certificate for a web server.

If you're happy with a self-signed certificate (which will generate warnings with some news reader clients), you can create and install one in the default path by running "make cert" after "make install" when installing INN, or by running the following commands:

```
    umask 077
    openssl req -new -x509 -nodes -out <pathetc>/cert.pem \
        -days 366 -keyout <pathetc>/key.pem
    chown news:news <pathetc>/cert.pem
    chmod 640 <pathetc>/cert.pem
    chown news:news <pathetc>/key.pem
    chmod 600 <pathetc>/key.pem
```

Replace the paths with something appropriate to your INN installation. This will create a self-signed certificate that will expire in a year. The openssl program will ask you a variety of questions about your organization. Enter the fully qualified domain name of your news service (either the server canonical name or a dedicated alias for the news service) as the name the certificate is for.

You then have to set these inn.conf parameters with the right paths:

```
    tlscapath:      <pathetc>
    tlscertfile:    <pathetc>/cert.pem
    tlskeyfile:     <pathetc>/key.pem
```

If you want to use a complete certificate chain, you can directly put it in tlscertfile (like Apache's SSLCertificateFile directive). Alternately, you can put a single certificate in tlscertfile and use tlscafile for additional certificates needed to complete the chain, like a separate authority root certificate.

More concretely, when using Let's Encrypt certificates, Certbot's files can be installed as follows:

```
    tlscapath:      /etc/letsencrypt/live/news.server.com
    tlscertfile:    /etc/letsencrypt/live/news.server.com/fullchain.pem
    tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem
```

or:

```
    tlscapath:      /etc/letsencrypt/live/news.server.com
    tlscafile:      /etc/letsencrypt/live/news.server.com/chain.pem
    tlscertfile:    /etc/letsencrypt/live/news.server.com/cert.pem
    tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem
```

Make sure that the permission rights are properly set so that the news user or the news group can read these directories and files (typically, he should access /etc/letsencrypt/live/news.server.com and /etc/letsencrypt/archive/news.server.com where the real keys are located, and the private key should not be world-readable).

If you prefer to point to files outside the directory of Let's Encrypt, you may add a post-renewal hook for Let's Encrypt to copy the generated files to another location, and give them the expected rights.

There are two common ways for a news client to negotiate a TLS connection: either via the use of a dedicated port (usually 563) on which TLS is immediately negotiated upon connection, or via the now discouraged way (per RFC 8143) to use the STARTTLS command on the usual NNTP port (119) to dynamically upgrade from unencrypted to TLS-protected traffic during an NNTP session. innd does not, however, know how to listen for connections to that separate port (563). You will therefore need to arrange for nnrpd to listen on that port through some other means. This can be done with the -D flag along with "-p 563" and put into your init scripts:

```
    su news -s /bin/sh -c '<pathbin>/nnrpd -D -p 563 -S'
```

but the easiest way is probably to add a line like:

```
    nntps stream tcp nowait news <pathbin>/nnrpd nnrpd -S
```

to /etc/inetd.conf or the equivalent on your system and let inetd run nnrpd. (Change the path to nnrpd to match your installation.) You may need to replace "nntps" with 563 if "nntps" isn't defined in /etc/services on your system. You may also want to use the lowercase -s flag with a long string as its argument to see more information about incoming connections in ps(1) output.

Optionally, you may set the tlsciphers, tlsciphers13, tlscompression, tlseccurve, tlspreferserverciphers, and tlsprotocols parameters in inn.conf to fine-tune the behaviour of the TLS/SSL negotiation whenever a new attack on the TLS protocol or some supported cipher suite is discovered.

## BLACKLISTD SUPPORT
blacklistd(8) is a FreeBSD/NetBSD daemon for preventing brute force attacks by blocking attackers after a number of failed login attempts. When nnrpd is built with blacklistd support, it will report login attempts to the blacklistd daemon for potential blocking.

Adding the configuration below to /etc/blacklistd.conf under the "[local]" section, assuming nnrpd is listening on port 563, would lead to attackers being blocked for 10 minutes after 5 failed login attempts.

```
    # adr/mask:port type    proto owner name nfail disable
    563             stream  *     *     *    5     10m
```

See the blacklistd(8) documentation for more information.

## PROTOCOL DIFFERENCES
nnrpd implements the NNTP commands defined in RFC 3977 (NNTP), RFC 4642 updated by RFC 8143 (TLS/NNTP), RFC 4643 (NNTP authentication), RFC 6048 (NNTP LIST additions) and RFC 8054 (NNTP compression) with the following differences:

1.

The XGTITLE [wildmat] command is provided. This extension is used by ANU-News and documented in RFC 2980. It returns a 282 reply code, followed by a one-line description of all newsgroups that match the pattern. The default is the current group. Note that LIST NEWSGROUPS should be used instead of XGTITLE.

2.

The XHDR header [message-ID|range] command is implemented. It returns a 221 reply code, followed by specific header fields for the specified range; the default is to return the data for the current article. See RFC 2980. Note that HDR should be used instead of XHDR.

3.

The XOVER [range] command is provided. It returns a 224 reply code, followed by the overview data for the specified range; the default is to return the data for the current article. See RFC 2980. Note that OVER should be used instead of XOVER.

4.

A new command, XPAT header message-ID|range pattern [pattern ...], is provided. The first argument is the case-insensitive name of the header field to be searched. The second argument is either an article range or a single message-ID, as specified in RFC 2980. The third argument is a uwildmat-style pattern; if there are additional arguments, they are joined together separated by a single space to form the complete pattern. This command is similar to the XHDR command. It returns a 221 response code, followed by the text response of all article numbers that match the pattern.

5.

A newsgroup name is case-sensitive for nnrpd.

6.

If IHAVE has been advertised, it will not necessarily be advertised for the entire session (contrary to section 3.4.1 of RFC 3977). nnrpd only advertises the IHAVE capability when it is really available.

7.

nnrpd allows a wider syntax for wildmats and ranges (especially "-" and "-article-number").

8.

When keyword generation is used, an experimental feature enabled with the keywords parameter in inn.conf, "Keywords:full" is advertised in LIST OVERVIEW.FMT even though overview information is computed and does not necessarily come from Keywords header fields.

## HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Overview support added by Rob Robertston <rob@violet.berkeley.edu> and Rich in January, 1993. Exponential backoff (for posting) added by Dave Hayes in Febuary 1998.

## SEE ALSO
blacklistd(8), ctlinnd(8), innd(8), inn.conf(5), inn-secrets.conf(5), libinn_uwildmat(3), nnrpd.track(5), passwd.nntp(5), readers.conf(5), signal(2).


nntpsend

title: nntpsend(8)

summary: Send Usenet articles to remote sites

text:
# nntpsend(8)

## NAME
nntpsend - Send Usenet articles to remote sites

## SYNOPSIS
nntpsend [-acDdlNnpr] [-P portnum] [-s size] [-T timelimit] [-t timeout] [-w delay] [sitename fqdn] ...

## DESCRIPTION
nntpsend is a front-end that invokes innxmit to send Usenet articles to a remote NNTP site. The sites to be fed may be specified by giving sitename fqdn pairs on the command line. If no such pairs are given, nntpsend defaults to the information given in the nntpsend.ctl config file. The sitename should be the name of the site as specified in the newsfeeds file. The fqdn should be the hostname or IP address of the remote site. An innxmit is launched for sites with queued news. All innxmit processes are spawned in the background and the script waits for them all to finish before returning. Output is sent to the file nntpsend.log in pathlog. In order to keep from overwhelming the local system, nntpsend waits five seconds before spawning each child.

nntpsend expects that the batch file for a site is named sitename in pathoutgoing. To prevent batch files corruption, shlock is used to "lock" these files. When sitename fqdn pairs are given on the command line, any flags given on the command completely describe how innxmit and shrinkfile operate. When no such pairs are given on the command line, then the information found in nntpsend.ctl becomes the default flags for that site. Any flags given on the command line override the default flags for the site.

An alternative to nntpsend can be innduct, mentioned in the innfeed(8) man page.

## OPTIONS
-D, -d

The -D flag causes nntpsend to send output to stdout rather than the log file nntpsend.log in pathlog. The -d flag does the same and it passes -d to all innxmit invocations, which in turn causes innxmit to go into debug mode.

-n

If the -n flag is used, then nntpsend does not use shlock to lock the use of nntpsend. Batch files will still be locked.

-s size

If the -s flag is used, then shrinkfile will be invoked to perform a head truncation of size bytes on the batch file and the flag will be passed to it.

-w delay

If the -w flag is used, then nntpsend waits for delay seconds after flushing the site before launching innxmit.

-a, -c, -l, -N, -P portnum, -p, -r, -T timelimit, -t timeout

The -a, -c, -l, -P portnum, -p, -r, -T timelimit and -t timeout flags are passed on to the child innxmit program. The -N flag is passed as -s flag to the child innxmit program. See innxmit(8) for more details. Note that if the -p flag is used, then no connection is made and no articles are fed to the remote site. It is useful to have cron(8) invoke nntpsend with this flag in case a site cannot be reached for an extended period of time.

## EXAMPLES
With the following nntpsend.ctl config file:

```
    nsavax:erehwon.nsavax.gov::-t60
    group70:group70.org::
    walldrug:walldrug.com:4m-1m:-T1800 -t300
    kremvax:kremvax.cis:2m:
```

the command "nntpsend" will result in the following:

```
    Sitename        Truncation      innxmit flags
    nsavax          (none)          -a -t60
    group70         (none)          -a -t180
    walldrug        1m if >4m       -T1800 -t300
    kremvax         2m              -t180
```

The command "nntpsend -d -T1200" will result in the following:

```
    Sitename        Truncation      innxmit flags
    nsavax          (none)          -a -d -T1200 -t60
    group70         (none)          -a -d -T1200 -t180
    walldrug        1m if >4m       -d -T1200 -t300
    kremvax         2m              -d -T1200 -t180
```

The command "nntpsend -s 5m -T1200 nsavax erehwon.nsavax.gov group70 group70.org" will result in the following:

```
    Sitename        Truncation      innxmit flags
    nsavax          5m              -T1200 -t180
    group70         5m              -T1200 -t180
```

Remember that -a is always given when there is no size limit, and -t defaults to 180.

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

## SEE ALSO
inn.conf(5), innxmit(8), newsfeeds(5), nntpsend.ctl(5), shlock(1), shrinkfile(1).


title: ovdb_init(8)

summary: Prepare ovdb database for use

text:
# ovdb_init(8)

## NAME
ovdb_init - Prepare ovdb database for use

## SYNOPSIS
ovdb_init [-r|-u]

## DESCRIPTION
This command must be run before any other process can access the overview database. ovdb_init is normally invoked automatically by rc.news when starting the news system.

ovdb_init performs the following steps:

1.

Creates the database environment, if necessary.

2.

If the database is idle (and if the -u option is not specified), it performs a normal recovery. The recovery will remove stale locks, recreate the memory pool cache, and repair any damage caused by a system crash or improper shutdown.

3.

If the -u option is specified, it performs any necessary upgrades to the database. See the "UPGRADING" section below.

4.

Starts the database housekeeping processes (ovdb_monitor) if they are not already running. (Unless the -r option is specified.)

5.

Starts the ovdb readserver processes (ovdb_server) if readserver in ovdb.conf is true, and if they are not already running. (Unless the -r option is specified.)

Returns exit status of 0 if all steps were completed successfully. In the event of an error, messages are written to syslog and/or stderr.

If a recovery was attempted but failed, the database may be damaged beyond repair, requiring a rebuild with makehistory.

This command can be run multiple times.

## OPTIONS
-r

Perform recovery only. ovdb_monitor is not started.

-u

Perform any needed upgrades. Recovery is not attempted. ovdb_monitor is started if the upgrade succeeded. This option can be used even if no upgrades are needed.

## UPGRADING
There are two situations in which the database will need to be upgraded:

- You upgrade the Berkeley DB library to a newer version, for example from 2.7.7 to 3.1.17. In this case, the Berkeley DB "db->upgrade()" method is used.

- You upgrade ovdb to a newer major version; i.e., ovdb-1.0 (shipped with INN 2.3.0 up to INN 2.3.5) to ovdb-2.0 (since INN 2.4.0).

In both of these cases, the database is upgraded in-place; and the upgrade cannot be undone. Do not interrupt the upgrade process once it has started, because there is a risk of irreparable corruption. The upgrade may take several minutes to complete. If an upgrade does get interrupted, try running the upgrade again.

Here's an example procedure to upgrade a database created with Berkeley DB 2.7.7 to use Berkeley DB 3.1.17:

1.

Build and install the Berkeley DB 3.1.17 version;

2.

Run configure in the INN source tree and make sure it picks up the right Berkeley DB directory (e.g., /usr/local/BerkeleyDB.3.1);

3.

Do a "make";

4.

Shut down INN (e.g., with "rc.news stop") and be sure to kill all instances of nnrpd as well;

5.

Do a "make update" to install the new binaries;

6.

Run "ovdb_init -u" as the news user;

7.

Start INN with the "rc.news" command.

## HISTORY
Written by Heath Kehoe <hakehoe@avalon.net> for InterNetNews.

## SEE ALSO
ovdb(5), makehistory(8), rc.news(8).


title: ovdb_monitor(8)

summary: Database maintenance

text:
# ovdb_monitor(8)

## NAME
ovdb_monitor - Database maintenance

## SYNOPSIS
Use ovdb_init to start ovdb_monitor

## DESCRIPTION
When started (normally by ovdb_init that is invoked by rc.news), ovdb_monitor forks three processes that perform routine database maintenance tasks. These are transaction checkpointing (every 30 seconds), deadlock detection (every 30 seconds), and transaction log removal (every 45 seconds).

The process ID of the parent is written to ovdb_monitor.pid in the pathrun directory. This PID is used by other INN commands to verify that ovdb_monitor is running.

To shut down ovdb_monitor, send a TERM signal to the process ID in ovdb_monitor.pid. The parent process will shut down the three children and wait for their exit before exiting itself. Note that when running the "rc.news stop" command to stop the news system, rc.news automatically takes care of stopping ovdb_monitor.

## HISTORY
Written by Heath Kehoe <hakehoe@avalon.net> for InterNetNews.

## SEE ALSO
ovdb(5), ovdb_init(8), rc.news(8).


title: ovdb_server(8)

summary: Overview helper server for nnrpd

text:
# ovdb_server(8)

## NAME
ovdb_server - Overview helper server for nnrpd

## SYNOPSIS
Use ovdb_init to start ovdb_server

## DESCRIPTION
If the readserver parameter in ovdb.conf is true, ovdb_init (if not invoked with the -r flag) will start as many ovdb_server processes as the numrsprocs parameter states.

ovdb_server opens the overview database, and accesses it on behalf of the nnrpd reader processes.

To shut down ovdb_server, send a TERM signal to the process ID mentioned in ovdb_server.pid in pathrun (note that the rc.news script already does that if used to shut down INN). The parent process will shut down its children and wait for their exit before exiting itself.

## HISTORY
Written by Heath Kehoe <hakehoe@avalon.net> for InterNetNews.

## SEE ALSO
ovdb(5), ovdb_init(8), rc.news(8).


title: ovdb_stat(8)

text:
# ovdb_stat(8)

## NAME
ovdb_stat - Display information from the ovdb database

## SYNOPSIS
ovdb_stat [-Hgci] [-r artnumrange] newsgroup [newsgroup ...]

ovdb_stat -HklmMtv [-d database]

## DESCRIPTION
ovdb_stat displays information from the ovdb database: Berkeley DB statistics, newsgroup data, and overview records. The output can optionally be in HTML format.

The number of overview records stored in the database can be obtained with the "inndf -n" command.

## OPTIONS
-g

Newsgroup high water mark, low marker mark, article count, and flag for the given newsgroups (as stored in the ovdb groupinfo database) are displayed.

-c

Similar to -g, except the high water mark, low water mark, and article count are calculated by actually scanning the overview records and counting them. This can be a lengthy operation on groups with lots of articles.

-i

Internal data regarding the given newsgroups are displayed.

-r artnumrange

Overview records are retrieved. The artnumrange parameter may be a single article number, or a range of articles in the format "low-high".

-H

Output is presented in HTML format.

-k

Displays lock region statistics, as returned by the Berkeley DB "lock_stat()" call.

-l

Displays log region statistics, as returned by the Berkeley DB "log_stat()" call.

-m

Displays global memory pool statistics, as returned by the Berkeley DB "memp_stat()" call.

-M

Same as -m, and also displays memory pool statistics for each database file.

-t

Displays log region statistics, as returned by the Berkeley DB "txn_stat()" call.

-v

Displays ovdb version, and Berkeley DB version.

-d database

Displays information about the given database, as returned by the Berkeley DB "db->stat()" call. This operation may take a long time on busy systems (several minutes or more).

## WARNINGS
ovdb_stat may be safely killed with the INT, TERM, or HUP signals. It catches those signals and exits cleanly. Do not kill ovdb_stat with other signals, unless absolutely necessary, because it may leave stale locks in the database environment.

## HISTORY
Written by Heath Kehoe <hakehoe@avalon.net> for InterNetNews.

## SEE ALSO
inndf(8), ovdb(5).


overchan

title: overchan(8)

summary: Batch update the INN overview database

text:
# overchan(8)

## NAME
overchan - Batch update the INN overview database

## SYNOPSIS
overchan [file ...]

## DESCRIPTION
overchan reads overview data from the specified files or from standard input if no files are specified, and writes that data into the INN overview database. (The file "-" means to read data from standard input as well.)

Normally, overview data is stored by innd for articles as they're accepted. For performance, however, it's sometimes useful to have overview data written by a separate process. To do this, set useoverchan to true in inn.conf to tell innd to not write overview data directly and then add an overchan channel in newsfeeds:

```
    overview!:*:Tc,WnteO:<pathbin>/overchan
```

where <pathbin> is pathbin in inn.conf. Additionally, overchan can be used to bulk-load overview data from appropriately formatted batch files (such as overflow files from an overchan channel).

Each line of input should have the following format:

```
    <token> <arrived> <expires> <data>
```

where <token> is the storage API token of the article in textual form (surrounded by "@" characters), <arrived> is the arrival timestamp of the article in seconds since epoch, <expires> is the expiration time of the article in seconds since epoch or 0 if there is none, and <data> is the tab-separated overview data. Each of these fields must be separated by a single space.

## HISTORY
Written by Rob Robertson <rob@violet.berkeley.edu> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Man page rewritten in POD by Russ Allbery <eagle@eyrie.org>.

## SEE ALSO
inn.conf(5), innd(8), newsfeeds(5)


ovsqlite-server

title: ovsqlite-server(8)

summary: Sole owner of the ovsqlite database

text:
# ovsqlite-server(8)

## NAME
ovsqlite-server - Sole owner of the ovsqlite database

## SYNOPSIS
ovsqlite-server [-d]

## DESCRIPTION
The ovsqlite-server daemon is the only program that opens the overview SQLite database. It accepts connections from the other parts of INN that want to operate on overview data (innd, nnrpd, expireover, makehistory).

This daemon must therefore be started before any other process can access the overview database. ovsqlite-server is normally invoked automatically by rc.news when starting the news system. It is also stopped automatically by rc.news when stopping the news system.

In case you need to talk to this daemon from Perl, the binary protocol used to communicate with it has been implemented in the "INN::ovsqlite_client" Perl module. See its manual page for more information about its possibilities.

## OPTIONS
-d

ovsqlite-server normally puts itself into the background, points its standard output and error to log files, and disassociates itself from the terminal. Using -d prevents all of this, resulting in log messages being written to the standard error output; this is generally useful only for debugging.

## FILES
pathetc/ovsqlite.conf

The configuration file. See ovsqlite(5).

pathoverview/ovsqlite.db

The SQLite database file.

pathrun/ovsqlite.pid

Stores the PID of the server process while it's running.

pathrun/ovsqlite.sock

When Unix-domain sockets are available, the server binds its listening socket to this path.

pathrun/ovsqlite.port

When Unix-domain sockets aren't available, the server binds its listening socket to a dynamic TCP port on the IPv4 loopback interface and stores the port number in this file.

## HISTORY
Initial implementation of ovsqlite written by Bo Lindbergh <2bfjdsla52kztwejndzdstsxl9athp@gmail.com> for InterNetNews.

## SEE ALSO
INN::ovsqlite_client(3pm), ovsqlite(5), rc.news(8).


ovsqlite-util

title: ovsqlite-util(8)

text:
# ovsqlite-util(8)

## NAME
ovsqlite-util - Overview manipulation utility for ovsqlite

## SYNOPSIS
ovsqlite-util [-AFghioO] [-a article] [-n newsgroup] [-p path]

## DESCRIPTION
ovsqlite-util is an administrative interface to the ovsqlite overview method for INN. It only works on ovsqlite overview databases, not on any other type of INN overview. (See dedicated ovdb_stat(8) and tdx-util(8) programs for ovdb and tradindexed overview methods.) It allows the administrator to dump various information about the internal state of the overview, audit it for errors, and fix these errors.

To audit the entire overview database for problems, use -A. The checks can take an extended period of time, depending on the number of newsgroups and articles present in the overview database. Any problems found will be reported to standard error. Use -F to correct the errors found.

It is safe to run this utility while the server is running. In case fixes should be made to the database (when using the -F flag), ovsqlite-util will properly pause the server before performing its operations, and then resume it.

The number of overview records stored in the database can be obtained with the "inndf -n" command.

As ovsqlite-util directly opens the ovsqlite overview database, it may take a longer time to complete when INN is running owing to the fact that ovsqlite-server may hold locks on certain tables, in which case ovsqlite-util just waits for the locks to be released. (The transtimelimit parameter in ovsqlite.conf controls the duration of a transaction, so you may check you have not set a too high value.)

## REQUIREMENTS
The "DBI" Perl module with the "DBD::SQLite" driver must be installed for this program to work. They are present in most distributions as a package named like "libdbd-sqlite3-perl", "perl-DBD-SQLite" or "p5-DBD-SQLite". They can also be directly installed from CPAN ("DBI" and "DBD-SQLite" distributions available at <https://metacpan.org/dist/DBI> and <https://metacpan.org/dist/DBD-SQLite>).

Naturally, an ovsqlite overview database also needs being in use, as detailed in the ovsqlite(5) manual page.

## OPTIONS
-a article

The article number or numbers to act on. article is a valid NNTP range, meaning that it can be either a single article number or a range of article numbers (like "1-5"). Either the start or the end (or both) of the range may be omitted, in which case they will be set to the first or last article number in the group. Passing "-" for article is therefore equivalent to not using the -a option at all. Only useful in combination with the -g, -o and -O options to dump overview information.

-A

Audit the entire overview database for problems. Currently, only one consistency check is performed: the verification that the low water mark, the high water mark and the article count of each newsgroup match the reality of articles present in overview. No changes will be made to the database, but problems will be reported to standard error.

-F

Audit the entire overview database for problems, fixing them as they're detected where possible. This runs the same checks as the -A flag, and fixes the problems found. Using this option takes care of pausing and resuming INN so that the overview data are not changed by another process during the operations. To see what would be changed by -F, run ovsqlite-util with -A first.

-g

Dump overall overview information for a particular group. The fields are, in order, the article number, the length of the overview data, the time (in seconds since epoch) when the article arrived on the server, the time (in seconds since epoch) when the article should expire based on its Expires header field (or 0 if there is no Expires header field), and the storage API token of the article. If this option is given, the -n option must also be given to specify the newsgroup on which to act.

-i

Dump newsgroup-related overview information from the database. This contains similar information to the server active file, such as high and low water marks and moderation status, and is the information that nnrpd hands out to clients. The fields are, in order, the newsgroup name, the high water mark, the low water mark, the count of articles in the group, the group status, the time (in seconds since epoch) when that newsgroup was last expired (or 0 if expireover hasn't run on it yet), and the deletion status of that newsgroup (0 if not marked for removal during the next expiration, and a positive value otherwise).

A particular newsgroup can be specified with the -n option. If -n is not given, the entire master index will be dumped.

-n newsgroup

Specify the newsgroup on which to act, required for the -g, -o, and -O options, and optional for the -i option.

-o

Dump the overview information for a newsgroup, in the same format as it would be returned to clients but with one modification. Appended to the end of each entry will be four additional pieces of data: the article number according to overview information labelled with "Article:", the storage API token for that article labelled with "Token:", the arrival date for that article on the server in RFC 5322 date format labelled with "Arrived:", and the expiration date for that article (from the Expires header field) in RFC 5322 date format if there is any, labelled with "Expires:". If this option is given, the -n option must also be given to specify the newsgroup on which to act. By default, all of the overview information for that newsgroup is dumped, but the -a option may be given to restrict the dump to the information for a single article or a range of article numbers.

-O

Dump the overview information for a newsgroup in the format used by overchan as input. Each line will start with the storage API token, the arrival timestamp in seconds since epoch, the expires timestamp in the same format (or 0 if there is no Expires header field), and then the overview data. If this option is given, the -n option must also be given to specify the newsgroup on which to act. By default, all of the overview information for that newsgroup is dumped, but the -a option may be given to restrict the dump to the information for a single article or a range of article numbers.

-p path

Act on the overview database rooted in path, overriding the overview path specified in the pathoverview parameter in inn.conf.

## EXAMPLES
Dump newsgroup-related overview information for the overview database in /news/overview, regardless of the overview path specified in inn.conf:

```
    ovsqlite-util -i -p /news/overview
```

Dump overall overview information for example.test:

```
    ovsqlite-util -g -n example.test
```

Dump the complete overview information for example.test:

```
    ovsqlite-util -o -n example.test
```

Dump the overview information for articles 45 and higher in example.test:

```
    ovsqlite-util -o -n example.test -a 45-
```

Audit the entire overview database for any problems:

```
    ovsqlite-util -A
```

## HISTORY
Written by Julien ELIE for InterNetNews.

## SEE ALSO
expireover(8), inndf(8), makehistory(8), nnrpd(8), ovsqlite(5).


perl-nocem

title: perl-nocem(8)

summary: A NoCeM\-on\-spool implementation for INN 2.x

text:
# perl-nocem(8)

## NAME
perl-nocem - A NoCeM-on-spool implementation for INN 2.x

## SYNOPSIS
perl-nocem [-hlu] [-b directory] [-c filename] [-g command] [-G command] [-i filename] [-k keyring] [-v level]

## DESCRIPTION
NoCeM, which is pronounced No See 'Em, is a protocol enabling authenticated third-parties to issue notices which can be used to cancel unwanted articles (like spam and articles in moderated newsgroups which were not approved by their moderators). It can also be used by readers as a third-party killfile. It is intended to eventually replace the protocol for third-party cancel messages which can too easily be forged as cancel messages are not authenticated, contrary to NoCeM notices.

perl-nocem processes third-party, PGP-signed article cancellation notices. It is possible to honour a selective set of NoCeM notices, and not all of them. You can configure in nocem.ctl in pathetc the list of NoCeM issuers you trust and add the corresponding public PGP keys to your NoCeM keyring (by default, no PGP keys are installed, so nobody is trusted). It is up to you to decide whether you wish to honour their notices, depending on the criteria they use. You are encouraged to regularly have a look at the official NoCeM Registry <https://rosalind.home.xs4all.nl/nocemreg/nocemreg.html> to check for possible new NoCeM issuers to add and see an overview of their policy. The daily summary of NoCeM messages sent <https://www.novabbs.com/SEARCH/search_nocem.php?stats=daily> may also be useful.

perl-nocem expects either storage tokens or file names on its standard input. It will then read and process the corresponding article. It appends all status messages to perl-nocem.log in pathlog if the syslog facility is not available or the -l flag is explicitly used; otherwise, the syslog facility is used in which case status messages are appended to a file usually named news.notice in pathlog. (Some logs will be written only if debug level is set up to be logged via syslog.)

## CONFIGURATION
Processing NoCeM notices is easy to set up:

1.

If not already done, install GnuPG, or an equivalent implementation of the OpenPGP standard, to be able to verify the signature of NoCeM messages. It will provide the gpg and gpgv programs. If GnuPG was already installed when INN was configured, then the paths to these programs were taken into account. Otherwise, you can use the -g and -G flags to set (or even override) the commands perl-nocem will use to run these programs. All still active NoCeM issuers use rather modern PGP keys accepted by both GnuPG 1.x and 2.x versions. It is no longer needed to explicitly use gpg1 to process NoCeM notices.

2.

Import the public keys of the NoCeM issuers you trust in order to check the authenticity of their notices. You can run the following command:

```
    gpg --no-default-keyring --allow-non-selfsigned-uid \
        --primary-keyring <pathetc>/pgp/ncmring.gpg --no-options \
        --no-permission-warning --batch --import <key-file>
    chmod 644 <pathetc>/pgp/ncmring.gpg

```

where <pathetc> is the value of the pathetc parameter set in inn.conf and <key-file> the file containing the public key(s) to import. The keyring is located in <pathetc>/pgp/ncmring.gpg by default; you only have to create the directory <pathetc>/pgp before using gpg (it will automatically generate the ncmring.gpg file) and make sure the news user can read this file, once generated. You can use another location and file name for the keyring, and then run perl-nocem with the -k flag.

The public keys of NoCeM issuers can be found in the web site of The NoCeM Registry <https://rosalind.home.xs4all.nl/nocemreg/nocemreg.html> where you can even download a unique file which contains all the public keys.

3.

Create or update the nocem.ctl configuration file in pathetc to indicate the NoCeM issuers and the types of notices you want to follow. This permission file contains lines like:

```
    bleachbot@httrack.com:spam,site
    pgpmoose@killfile.org:pgpmoose-forged-moderation

```

This will remove all articles for which the issuer (first part of the line, before the colon ":") has issued NoCeM notices of a type present in the comma-separated list of types specified after the colon (using "*" is possible, and means that all types are accepted).

Blank lines and lines beginning with a hash sign ("#") are ignored. Case is insensitive. Any entry with no corresponding public PGP key in the keyring will be skipped.

You will also find information about the issuers on the web site of The NoCeM Registry. Note that INN is shipped with an up-to-date nocem.ctl file already configured with the current NoCeM issuers. (Only the public PGP keys installed at the previous step are not included, so as to leave you the choice of whom to trust, and download the most recent ones, in case they have changed.)

4.

Add to the newsfeeds file in pathetc an entry like this one in order to feed perl-nocem with the NoCeM messages (cross)posted to news.lists.filters, the global newsgroup where notices should be sent:

```
    nocem!\
        :!*,news.lists.filters\
        :Tc,Wf,Ap:<pathbin>/perl-nocem

```

with the correct path to perl-nocem, located in <pathbin>, and any optional flag you want to use. Then, run "inncheck" to ensure the syntax of the modified newsfeeds file is correct, and reload it (via "ctlinnd reload newsfeeds 'NoCeM channel feed'").

Note that you should at least carry news.lists.filters on your news server (or other newsgroups where NoCeM notices are sent) if you wish to process them.

5.

Everything should now work. However, do not hesitate to manually test perl-nocem with a NoCeM message, using either:

```
    grephistory '<Message-ID>' | perl-nocem -l -v 2
    echo '/path/to/a/nocem/message' | perl-nocem -l -v 2

```

perl-nocem expects either storage tokens or file names on its standard input (grephistory returns the storage token of an article identified by its Message-ID).

Check the logs of that test in perl-nocem.log in pathlog.

You can also check the list of installed PGP public keys with the following command, adapted to the location of the NoCeM keyring:

```
    gpg --no-default-keyring --list-keys \
        --primary-keyring <pathetc>/pgp/ncmring.gpg

```

## OPTIONS
-b directory

Back up cancelled articles into files in directory. The directory should exist and be writable by the news user. Files are named issuer%type, and contain the articles actually removed from your news spool by the given NoCeM issuer for the given type of NoCeM notices. Cancelled articles which are not stored in your news spool when the notice is processed cannot be backed up. This flag is primarily meant for auditing possible false positives. As the backups are not automatically purged, you should prune them from time to time after having inspected their contents.

-c filename

By default, perl-nocem reads a configuration file named nocem.ctl in pathetc. This flag permits reading another configuration file, specified with an absolute path.

-g command

By default, perl-nocem runs the gpg(1) binary whose path was determined when INN was configured. If GnuPG wasn't installed at that time, or if you want to use another program, this flag will be helpful. Please ensure that at least an equivalent of the default options given to gpg is present in command; otherwise, perl-nocem may malfunction. Assuming "/bin/gpg" corresponds to the gpg binary, the default is:

```
    -g "/bin/gpg --status-fd=1 --verify --allow-weak-digest-algos"

```

-G command

By default, perl-nocem runs the gpgv(1) binary whose path was determined when INN was configured. If GnuPG wasn't installed at that time, or if you want to use another program, this flag will be helpful. Please ensure that at least an equivalent of the default option given to gpgv is present in command; otherwise, perl-nocem may malfunction. Assuming "/bin/gpgv" corresponds to the gpgv binary, the default is:

```
    -G "/bin/gpgv --status-fd=1"

```

Note that gpg will be preferentially used over gpgv when both are available, unless -g is given an empty string.

-h

Print to standard output a usage message and exit.

-i filename

When this flag is used, perl-nocem includes an external Perl script named filename, specified with an absolute path. It permits loading a "local_want_cancel_id" function with local rules to fine-tune within a NoCeM notice which articles get cancelled. All the articles present in a NoCeM notice are otherwise cancelled by default. This function is called for every article in the notice and has access to several variables: the Message-ID $msgid of the NoCeM message, the Message-ID $artid of the article to cancel, the comma-separated list of newsgroups $groups to which the article to cancel was posted, the hash reference $hdrs to the pseudo header fields of the NoCeM notice, in lowercase value. The article is kept if the function returns 0, and cancelled otherwise.

Here is an illustration of what this function can do, when defined in filename and the -i flag is used:

```
    sub local_want_cancel_id {
        my ($msgid, $artid, $groups, $hdrs) = @_;
        my $carried = 0;
        # Walk through the newsgroups the article was posted to.
        foreach my $group (split(/,/, $groups)) {
            # Keep it if posted to news.software.nntp.
            return 0 if $group eq "news.software.nntp";
            # Keep it if posted to fr.* and the issuer is "john".
            return 0
              if $group =~ /^fr\./ and $hdrs->{issuer} eq "john";
            # The article has been posted to at least a newsgroup
            # in the fr.* or news.* hierarchy.  You may use here
            # a regular expression corresponding to the newsgroups
            # pattern you ask your feeds to send you.
            $carried = 1 if $group =~ /^(fr|news)\./;
        }
        # In case the server only carries fr.* and news.*, this
        # rule permits discarding NoCeM notices related to
        # newsgroups not carried by the server, and therefore
        # neither treating nor remembering in the history file
        # Message-IDs of articles which won't reach the server.
        return 0 if not $carried;
        # Keep it if only posted to news.admin.net-abuse.usenet
        # and the type of the notice is "spam".
        return 0
          if $groups eq "news.admin.net-abuse.usenet"
          and $hdrs->{type} eq "spam";
        # Cancel it!
        return 1;
    }

```

If any syntax problem occurs when Perl loads the function, perl-nocem will die and report the reason in the logs. You'll then have to fix the function.

-k keyring

By default, perl-nocem verifies the signatures of NoCeM messages with the PGP public keys present in a keyring named ncmring.gpg in the pathetc/pgp directory. This flag permits using another keyring, specified with an absolute path. A --keyring= flag with the keyring value is then passed to the gpg(1) and gpgv(1) commands unless keyring is an empty string.

-l

By default, perl-nocem send logs to syslog(3). In case the syslog facility is not available or this flag is used, logs are sent to perl-nocem.log in pathlog. Error log level will still additionally be sent to syslog if available.

-u

By default, innreport will show unprocessed NoCeM notices in daily reports it generates. When this flag is used, issuers or types of notices not configured in nocem.ctl will still be mentioned in the logs but the corresponding log lines will not be parsed by innreport.

-v level

Increase log verbosity to that level, from 1 to 3. Default is 1.

## FILES
pathbin/perl-nocem

The Perl script itself used to process NoCeM messages.

pathetc/nocem.ctl

The configuration file which specifies the NoCeM notices to be processed. Another file can be specified with the -c flag.

pathetc/pgp/ncmring.gpg

The keyring which contains the public keys of trusted NoCeM issuers. Another file can be specified with the -k flag.

pathlog/perl-nocem.log

The log file used when the syslog facility is not available or the -l flag is used.

## NOTES
The accuracy of the newsgroups following the Message-IDs to cancel in the NoCeM body is not checked, nor is the Newsgroups pseudo header field if present. Well, as we already trust the issuer of the notice about the Message-IDs he marks as spam, let's also be confident about the listed newsgroups.

## HISTORY
Copyright 2000 by Miquel van Smoorenburg <miquels@cistron.nl>.

Copyright 2001 by Marco d'Itri <md@linux.it>.

## SEE ALSO
gpg(1), gpgv(1), grephistory(1), inn.conf(5), innreport(8), newsfeeds(5), pgp(1).


procbatch

title: procbatch(8)

summary: Process an INN funnel file or innfeed\-dropped file

text:
# procbatch(8)

## NAME
procbatch - Process an INN funnel file or innfeed-dropped file

## SYNOPSIS
procbatch [-hquv] [-c [-s spooldir]] [-d outdir] [-e peer] [-m [-t backlogdir]] batchfile

## DESCRIPTION
procbatch will take an INN funnel or innfeed-dropped file and split it up by host for direct processing with innfeed or innxmit.

While funnel files will normally only be of interest after a crash, innfeed may drop articles for a variety of reasons, not all of which indicate a fundamental problem. For example, innfeed may drop articles when started and stopped in quick succession while INN processes a large number of control messages (a temporary indisposition), or when INN feeds it articles for a site that isn't in innfeed.conf (a misconfiguration).

Every running innfeed opens a file named innfeed-dropped.<id>, which should normally always be zero length and deleted on exit. If there are non-zero length files, innfeed has dropped some articles, and those dropped article files have to be processed or those articles will never be sent to peers. Though news.daily automatically process these files (invoking procbatch), it is also possible to do that manually. First make sure that the file doesn't correspond to a currently running innfeed, for example by calling "ctlinnd flush innfeed!".

An INN funnel file, or an innfeed-dropped file, will usually be of the format:

```
    pathname message-id peer1 peer2 peer3 ...
```

where pathname can alternatively be a storage API token.

procbatch will break this file up into files named peer1.tmp, peer2.tmp, peer3.tmp, etc. of the format:

```
    pathname message-id
```

These tape files will be sorted and stripped of duplicate entries. Simply renaming them to peer1, peer2, peer3, etc. in a running innfeed's backlog directory will cause them to be picked up automatically by innfeed every backlog-newfile-period seconds (as set in innfeed.conf). Use the -m flag to have procbatch rename and move them into place automatically.

After running procbatch, you may want to make sure that every generated backlog file has a corresponding ".lock" file. Otherwise, innfeed doesn't have that site configured as a peer, meaning your innfeed.conf may need fixing.

## OPTIONS
-c

Check for the existence of an article before writing references to it to the tape files. Currently, this option can only be used with a tradspool article store. Using it with any other spool format will lead to all articles being dropped.

-d outdir

Put the output file(s) into the directory outdir (defaults to pathtmp as set in inn.conf). When also specifying -m, the temporary output files will still be put here before being moved into their final location.

-e peer

Only process entries for peer.

-h

Display a short help screen.

-m

Directly append to tape files in innfeed's backlog directory.

-q

Quiet mode: only display error messages.

-s spooldir

Use spooldir as the location of the article spool (defaults to patharticles as set in inn.conf). This option has an effect only on a tradspool storage system when also specifying -c.

-t backlogdir

Use backlogdir as the location of the innfeed backlog directory (the directory where the created tape files will be put). Defaults to pathspool/innfeed. This option has an effect only when also specifying -m.

-u

Unlink the input batchfile after processing.

-v

Add verbosity.

## EXAMPLES
Take the file innfeed-dropped.B012345, process its lines appending to tapefiles in innfeed's backlog directory, and remove it when done. Be verbose while doing so:

```
    procbatch -umv innfeed-dropped.B012345
```

Go through innfeed-dropped.B012345 saving entries for "peer1" in /tmp/peer1.tmp, but only if the articles are still available in the local tradspool:

```
    procbatch -e peer1 -d /tmp -c innfeed-dropped.B012345
```

## BUGS
procbatch should be able to check for the existence of articles with any kind of article store, possibly using grephistory.

## HISTORY
procbatch was written by James Brister and improved for speed by Clayton O'Neill.

This manual page was written by Florian Schlichting, with the help of a memo by Russ Allbery.

## SEE ALSO
innfeed(8), innxmit(8), news.daily(8).


prunehistory

title: prunehistory(8)

summary: Remove tokens from Usenet history file

text:
# prunehistory(8)

## NAME
prunehistory - Remove tokens from Usenet history file

## SYNOPSIS
prunehistory [-p] [-f filename]

## DESCRIPTION
prunehistory modifies a history(5)-format text file to "remove" a set of tokens from it. The tokens are removed by overwriting them with spaces, so that the size and position of any following entries does not change. This has an effect similar to expiring the article, in that it is still mentioned in the history database but cannot be retrieved.

prunehistory reads the standard input. The input is taken as a set of lines. Blank lines and lines starting with a number sign ("#") are ignored. All other lines should consist of a message-ID followed by zero or more other fields (which are ignored). The message-ID is used as the dbz key to get an offset into the text file. Since innd only appends to the text file, prunehistory does not need to have any interaction with it.

## OPTIONS
-p

prunehistory will normally complain about lines that do not follow the correct format. If the -p flag is used, then the program will silently print any invalid lines on its standard output. (Blank lines and comment lines are also passed through.)

-f filename

The default name of the history file is pathdb/history; to specify a different name, use the -f flag.

## HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

## SEE ALSO
history(5), innd(8), libinn_dbz(3).


radius

title: radius(8)

summary: nnrpd RADIUS password authenticator

text:
# radius(8)

## NAME
radius - nnrpd RADIUS password authenticator

## SYNOPSIS
radius [-h] [-f config]

## DESCRIPTION
radius is an nnrpd authenticator, accepting a username and password from nnrpd (given to nnrpd by a reader connection) and attempting to authenticate that username and password against a RADIUS server. See readers.conf(5) for more information on how to configure an nnrpd authenticator. It is useful for a site that already does user authentication via RADIUS and wants to authenticate news reading connections as well.

By default, radius reads pathetc/inn-radius.conf for configuration information, but a different configuration file can be specified with -f. See inn-radius.conf(5) for a description of the configuration file.

## OPTIONS
-f config

Read config instead of pathetc/inn-radius.conf for configuration information.

-h

Print out a usage message and exit.

## EXAMPLE
The following readers.conf(5) fragment tells nnrpd to authenticate all connections using this authenticator:

```
    auth radius {
        auth: radius
        default: <FAIL>
        default-domain: example.com
    }
```

"@example.com" will be appended to the user-supplied identity, and if RADIUS authentication fails, the user will be assigned an identity of "<FAIL>@example.com".

## BUGS
It has been reported that this authenticator doesn't work with Ascend RADIUS servers, but does work with Cistron RADIUS servers. It's also believed to work with Livingston's RADIUS server. Contributions to make it work better with different types of RADIUS servers would be gratefully accepted.

This code has not been audited against the RADIUS protocol and may not implement it correctly.

## HISTORY
The RADIUS authenticator was originally written by Aidan Cully. This documentation was written by Russ Allbery <eagle@eyrie.org>.

## SEE ALSO
inn-radius.conf(5), nnrpd(8), readers.conf(5).


rc.news

title: rc.news(8)

summary: Start or stop INN daemons

text:
# rc.news(8)

## NAME
rc.news - Start or stop INN daemons

## SYNOPSIS
rc.news ["start" | "stop"]

## DESCRIPTION
rc.news can be used to start or stop innd and supporting programs. It checks to make sure INN is not already running, handles cases of unclean shutdown, finishes up tasks which might have been interrupted by the preceding shutdown, e-mails certain boot-time warnings to newsmaster (as set in inn.conf), and is generally safer and easier than starting and stopping everything directly. It needs to be run as the news user so that files in pathrun are created with the right ownership (though this is less important for "rc.news stop").

Programs run and stopped by this script include:

- Always: innd is started or stopped.

- If doinnwatch is true in inn.conf: innwatch is started and stopped.

- If docnfsstat is true in inn.conf: cnfsstat is started and stopped.

- If ovmethod is set to "ovdb" in inn.conf: ovdb_init is run; ovdb_server and ovdb_monitor are stopped.

- If ovmethod is set to "ovsqlite" in inn.conf: ovsqlite-server is started and stopped.

- If rc.news.local exists in pathbin: rc.news.local is run with argument "start" or "stop" (to perform site-specific startup or shutdown tasks).

- When started, if INN appears to have previously been shut down during its expiry process, run expirerm if there are articles to unlink.

- When started, if overview data appears to have just been rebuilt and active needs to be renumbered, then actually renumber it.

## OPTIONS
"start"

If the first argument is "start", or no first argument is given, rc.news initiates INN startup.

"stop"

If the first argument is "stop", rc.news initiates INN shutdown.

## EXAMPLES
To start INN and leave certain error messages going to the terminal:

```
       su news -s /bin/sh -c <pathbin in inn.conf>/rc.news
```

To run INN at startup time from appropriate system boot scripts:

```
       su news -s /bin/sh -c <pathbin>/rc.news >> <pathlog>/rc.news 2>&1
```

To stop INN:

```
       su news -s /bin/sh -c '<pathbin>/rc.news stop'
```

## HISTORY
This manual page written by Jeffrey M. Vinocur <jeff@litech.org> for InterNetNews.

## SEE ALSO
ctlinnd(8), cnfsstat(8), expirerm(8), inn.conf(5), innwatch(8), ovdb(5), ovsqlite(5).


scanlogs

title: scanlogs(8)

summary: Summarize and rotate INN log files

text:
# scanlogs(8)

## NAME
scanlogs - Summarize and rotate INN log files

## SYNOPSIS
scanlogs [norotate]

## DESCRIPTION
scanlogs summarizes the information recorded in the INN log files which reside in the pathlog directory set in inn.conf (see newslog(5) for further details about these log files). It is normally invoked by the news.daily(8) script which performs daily server maintenance tasks.

It invokes "ctlinnd flushlogs" to close the news and error log files, rename them to add ".old" to the file names and open fresh news and error logs; the active file is also flushed to disk, along with the history database.

By default, scanlogs rotates and cleans out the logs. It keeps up to logcycles old compressed log files in pathlog/OLD (the logcycles parameter can be set in inn.conf). scanlogs also keeps archives of the active file in this directory.

It invokes tally.control if newgroup.log or rmgroup.log exists in pathlog (see the control.log entry of newslog(5) for more information about that).

scanlogs displays the first 50 lines of errlog, news.err and news.crit, if non-empty, and runs innreport to summarize the contents of news, news.notice and perl-nocem.log, and to update the unwanted.log file amongst other things (see more information about that in innreport(8)).

## OPTIONS
Only one option is currently accepted:

norotate

Using this option disables the rotating and cleaning aspect of the log processing: the logs files are only scanned for information and no contents are altered. If scanlogs is invoked more than once a day, the norotate option should be used to prevent premature log cleaning.

## FILES
See newslog(5) for the list of log files processed by scanlogs.

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

## SEE ALSO
inn.conf(5), innreport(8), news.daily(8), newslog(5), shlock(1), tally.control(8).


scanspool

title: scanspool(8)

text:
# scanspool(8)

## NAME
scanspool - Perform a sanity scan over all articles in news spool

## SYNOPSIS
scanspool [-cnrv] [-a active-file] [-s spool-dir]

## DESCRIPTION
scanspool is a Perl script for use with a tradspool article spool. It will scan the active file as well as all articles in the spool and report on the errors it encounters. As this may take a while, using the -v switch is recommended to see how far the program has progressed.

scanspool will skip any file named other than just all-digits when treating the contents of the news spool.

First, scanspool scans the active file, noting problems such as:

- malformed lines;

- duplicate entries;

- newsgroups aliased to a non-existent newsgroup;

- newsgroups aliased to a newsgroup that is also aliased.

Then it will examine all articles under your news spool directory, complaining about articles that:

- have a basename that starts with a leading 0;

- have a basename that is out of range according to the low and high water marks of the active file;

- do not contain a Newsgroups header field;

- are in a directory for which there is no newsgroup in the active file;

- are in a newsgroup to which they do not belong.

scanspool will also complain about directories with an all-digit component, in case the parent directory is a newsgroup with a high water mark below that all-digit component, as the name of such directories will conflict with a future article file with the same name.

scanspool understands aliased newsgroups. Thus, if an article is posted to foo.old.name that is aliased to foo.bar, it will be expected to be found under foo.bar and not foo.old.name.

scanspool assumes that the path of a valid newsgroup's directory from the root of the spool tree will not contain any "." character. Thus, directories such as out.going, tmp.dir, in.coming and news.archive will not be searched. This program also assumes that article basenames contain only decimal digits. Last, files under the top level directory lost+found are not scanned.

## OPTIONS
-a active-file

The active file to use; pathdb/active is the default.

-c

Only check article filenames. scanspool will therefore not actually scan the Newsgroups header field of the articles.

-n

Don't throttle innd while scanning.

-r

Remove articles reported to have a problem. To see the list of articles in question, run scanspool without this flag first. Be warned that using this flag may result in inaccessible articles if articles are removed whereas they are perfectly valid articles. Have a look at them to ensure they can be safely removed, and then use this flag.

-s spool-dir

The root of the spool tree; patharticles is the default.

-v

Setting this flag enables a verbose mode. scanspool will then print which newsgroup is currently worked upon. It will list all the articles found in non-active directories (that is to say articles sorted into groups no longer present in the active file), rather than just printing the group once.

## DIAGNOSTICS
The output of scanspool will start with one of the following forms:

"FATAL:" (to stderr)

Fatal or internal error.

"WARNING:" (to stderr)

active or article format problem, newsgroup alias problem, find(1) error, article open error.

"path/123:" (to stdout)

Issues such as:

- basename starts with 0;

- article number out of range;

- article in the wrong directory;

- article in a directory not related to an active non-aliased newsgroup.

"\t ..." (to stdout)

Verbose messages start with a tab.

## HISTORY
scanspool was written by Landon Curt Noll (chongo was here /\../\).

This manual page was written by Florian Schlichting, largely based on comments in the script.

## SEE ALSO
active(5).