innfeed

title: innfeed(8)

summary: Multi\-host, multi\-connection, streaming NNTP feeder

text:
# innfeed(8)

## NAME
innfeed, imapfeed - Multi-host, multi-connection, streaming NNTP feeder

## SYNOPSIS
innfeed [-ChmMvxyz] [-a spool-dir] [-b directory] [-c config-file] [-d log-level] [-e bytes] [-l logfile] [-o bytes] [-p pid-file] [-s command] [-S status-file] [file]

## DESCRIPTION
innfeed implements the NNTP protocol for transferring news between computers. It handles the standard IHAVE protocol as well as the CHECK/TAKETHIS streaming extension. innfeed can feed any number of remote hosts at once and will open multiple connections to each host if configured to do so. The only limitations are the process limits for open file descriptors and memory.

As an alternative to using NNTP, INN may also be fed to an IMAP server. This is done by using an executable called imapfeed, which is identical to innfeed except for the delivery process. The new version has two types of connections: an LMTP connection to deliver regular messages and an IMAP connection to handle control messages.

## MODES
innfeed has three modes of operation: channel, funnel-file and batch.

Channel mode is used when no filename is given on the command line, the input-file keyword is not given in the config file, and the -x option is not given. In channel mode, innfeed runs with stdin connected via a pipe to innd. Whenever innd closes this pipe (and it has several reasons during normal processing to do so), innfeed will exit. It first will try to finish sending all articles it was in the middle of transmitting, before issuing a QUIT command. This means innfeed may take a while to exit depending on how slow your peers are. It never (well, almost never) just drops the connection. The recommended way to restart innfeed when run in channel mode is therefore to tell innd to close the pipe and spawn a new innfeed process. This can be done with "ctlinnd flush feed" where feed is the name of the innfeed channel feed in the newsfeeds file.

Funnel-file mode is used when a filename is given as an argument or the input-file keyword is given in the config file. In funnel-file mode, it reads the specified file for the same formatted information as innd would give in channel mode. It is expected that innd is continually writing to this file, so when innfeed reaches the end of the file, it will check periodically for new information. To prevent the funnel file from growing without bounds, you will need to periodically move the file to the side (or simply remove it) and have innd flush the file. Then, after the file is flushed by innd, you can send innfeed a SIGALRM, and it too will close the file and open the new file created by innd. Something like:

```
    innfeed -p <pathrun in inn.conf>/innfeed.pid my-funnel-file &
    while true; do
        sleep 43200
        rm -f my-funnel-file
        ctlinnd flush funnel-file-site
        kill -ALRM `cat <pathrun>/innfeed.pid`
    done
```

Batch mode is used when the -x flag is used. In batch mode, innfeed will ignore stdin, and will simply process any backlog created by a previously running innfeed. This mode is not normally needed as innfeed will take care of backlog processing.

## CONFIGURATION
innfeed expects a couple of things to be able to run correctly: a directory where it can store backlog files and a configuration file to describe which peers it should handle.

The configuration file is described in innfeed.conf(5). The -c option can be used to specify a different file. For each peer (say, "foo"), innfeed manages up to 4 files in the backlog directory:

- A foo.lock file, which prevents other instances of innfeed from interfering with this one.

- A foo.input file which has old article information innfeed is reading for re-processing.

- A foo.output file where innfeed is writing information on articles that could not be processed (normally due to a slow or blocked peer).

- A foo file that is never created by innfeed, but if innfeed notices it, it will rename it to foo.input at the next opportunity and will start reading from it. This lets you create a batch file and put it in a place where innfeed will find it.

You should never alter the foo.input or foo.output files of a running innfeed. The format of these last three files is one of the following:

```
    /path/to/article <message-id>
    @token@ <message-id>
```

This is the same as the first two fields of the lines innd feeds to innfeed, and the same as the first two fields of the lines of the batch file innd will write if innfeed is unavailable for some reason. When innfeed processes its own batch files, it ignores everything after the first two whitespace separated fields, so moving the innd-created batch file to the appropriate spot will work, even though the lines have extra fields.

The first field can also be a storage API token. The two types of lines can be intermingled; innfeed will use the storage manager if appropriate, and otherwise treat the first field as a filename to read directly.

innfeed writes its current status to the file innfeed.status (or the file given by the -S option). This file contains details on the process as a whole, and on each peer this instance of innfeed is managing.

If innfeed is told to send an article to a host it is not managing, then the article information will be put into a file matching the pattern innfeed-dropped.*, with part of the file name matching the pid of the innfeed process that is writing to it. innfeed will not process this file except to write to it. If nothing is written to the file, then it will be removed if innfeed exits normally. Otherwise, the file remains, and procbatch can be invoked to process it afterwards.

## SIGNALS
Upon receipt of a SIGALRM, innfeed will close the funnel file specified on the command line, and will reopen it (see funnel file description above).

innfeed with catch SIGINT and will write a large debugging snapshot of the state of the running system.

innfeed will catch SIGHUP and will reload both the config and the log files. See innfeed.conf(5) for more details.

innfeed will catch SIGCHLD and will close and reopen all backlog files.

innfeed will catch SIGTERM and will do an orderly shutdown.

Upon receipt of a SIGUSR1, innfeed will increment the debugging level by one; receipt of a SIGUSR2 will decrement it by one. The debugging level starts at zero (unless the -d option it used), in which case no debugging information is emitted. A larger value for the level means more debugging information. Numbers up to 5 are currently useful.

## SYSLOG ENTRIES
There are 3 different categories of syslog entries for statistics: host, connection and global.

The host statistics are generated for a given peer at regular intervals after the first connection is made (or, if the remote is unreachable, after spooling starts). The host statistics give totals over all connections that have been active during the given time frame. For example (broken here to fit the page, with "vixie" being the peer):

```
    May 23 12:49:08 news innfeed[16015]: vixie checkpoint
        seconds 1381 offered 2744 accepted 1286 refused 1021 rejected 437
        missing 0 accsize 8506220 rejsize 142129 spooled 990
        on_close 0 unspooled 240 deferred 10/15.3 requeued 25
        queue 42.1/100:14,35,13,4,24,10
```

The meanings of these fields are:

seconds

The time since innfeed connected to the host or since the statistics were reset by a "final" log entry.

offered

The number of IHAVE commands sent to the host if it is not in streaming mode. The sum of the number of TAKETHIS commands sent when no-CHECK mode is in effect plus the number of CHECK commands sent in streaming mode (when no-CHECK mode is not in effect).

accepted

The number of articles which were sent to the remote host and accepted by it.

refused

The number of articles offered to the host that it indicated it did not want because it had already seen the message-ID. The remote host indicates this by sending a 435 response to an IHAVE command or a 438 response to a CHECK command.

rejected

The number of articles transferred to the host that it did not accept because it determined either that it already had the article or it did not want it because of the article's Newsgroups: or Distribution: header fields, etc. The remote host indicates that it is rejecting the article by sending a 437 or 439 response after innfeed sent the entire article.

missing

The number of articles which innfeed was told to offer to the host but which were not present in the article spool. These articles were probably cancelled or expired before innfeed was able to offer them to the host.

accsize

The number of bytes of all accepted articles transferred to the host.

rejsize

The number of bytes of all rejected articles transferred to the host.

spooled

The number of article entries that were written to the .output backlog file because the articles either could not be sent to the host or were refused by it. Articles are generally spooled either because new articles are arriving more quickly than they can be offered to the host, or because innfeed closed all the connections to the host and pushed all the articles currently in progress to the .output backlog file.

on_close

The number of articles that were spooled when innfeed closed all the connections to the host.

unspooled

The number of article entries that were read from the .input backlog file.

deferred

The first number is the number of articles that the host told innfeed to retry later by sending a 431 or 436 response. innfeed immediately puts these articles back on the tail of the queue. The second number is the average (mean) size of deferred articles during the previous logging interval

requeued

The number of articles that were in progress on connections when innfeed dropped those connections and put the articles back on the queue. These connections may have been broken by a network problem or became unresponsive causing innfeed to time them out.

queue

The first number is the average (mean) queue size during the previous logging interval. The second number is the maximum allowable queue size. The third number is the percentage of the time that the queue was empty. The fourth through seventh numbers are the percentages of the time that the queue was >0% to 25% full, 25% to 50% full, 50% to 75% full, and 75% to <100% full. The last number is the percentage of the time that the queue was totally full.

If the -z option is used (see below), then when the peer stats are generated, each connection will log its stats too. For example, for connection number zero (from a set of five):

```
    May 23 12:49:08 news innfeed[16015]: vixie:0 checkpoint
        seconds 1381 offered 596 accepted 274 refused 225
        rejected 97 accsize 773623 rejsize 86591
```

If you only open a maximum of one connection to a remote, then there will be a close correlation between connection numbers and host numbers, but in general you cannot tie the two sets of number together in any easy or very meaningful way. When a connection closes, it will always log its stats.

If all connections for a host get closed together, then the host logs its stats as "final" and resets its counters. If the feed is so busy that there is always at least one connection open and running, then after some amount of time (set via the config file), the host stats are logged as final and reset. This is to make generating higher level stats from log files, by other programs, easier.

There is one log entry that is emitted for a host just after its last connection closes and innfeed is preparing to exit. This entry contains counts over the entire life of the process. The "seconds" field is from the first time a connection was successfully built, or the first time spooling started. If a host has been completely idle, it will have no such log entry.

```
    May 23 12:49:08 news innfeed[16015]: decwrl global
        seconds 1381 offered 34 accepted 22 refused 3 rejected 7
        missing 0 accsize 81277 rejsize 12738 spooled 0 unspooled 0
```

The final log entry is emitted immediately before exiting. It contains a summary of the statistics over the entire life of the process.

```
    Feb 13 14:43:41 news innfeed[22344]: ME global
        seconds 15742 offered 273441 accepted 45750 refused 222008
        rejected 3334 missing 217 accsize 93647166 rejsize 7421839
        spooled 10 unspooled 0
```

## OPTIONS
innfeed takes the following options.

-a spool-dir

The -a flag is used to specify the top of the article spool tree. innfeed does a chdir(2) to this directory, so it should probably be an absolute path. The default is patharticles as set in inn.conf.

-b directory

The -b flag may be used to specify a different directory for backlog file storage and retrieval, as well as for lock files. If the path is relative, then it is relative to pathspool as set in inn.conf. The default is "innfeed".

-c config-file

The -c flag may be used to specify a different config file from the default value. If the path is relative, then it is relative to pathetc as set in inn.conf. The default is innfeed.conf.

-C

The -C flag is used to have innfeed simply check the config file, report on any errors and then exit.

-d log-level

The -d flag may be used to specify the initial logging level. All debugging messages go to stderr (which may not be what you want, see the -l flag below).

-e bytes

The -e flag may be used to specify the size limit (in bytes) for the .output backlog files innfeed creates. If the output file gets bigger than 10% more than the given number, innfeed will replace the output file with the tail of the original version. The default value is 0, which means there is no limit.

-h

Use the -h flag to print the usage message.

-l logfile

The -l flag may be used to specify a different log file from stderr. As innd starts innfeed with stderr attached to /dev/null, using this option can be useful in catching any abnormal error messages, or any debugging messages (all "normal" errors messages go to syslog).

-m

The -m flag is used to turn on logging of all missing articles. Normally, if an article is missing, innfeed keeps a count, but logs no further information. When this flag is used, details about message-IDs and expected path names are logged.

-M

If innfeed has been built with mmap support, then the -M flag turns OFF the use of mmap(); otherwise, it has no effect.

-o bytes

The -o flag sets a value of the maximum number of bytes of article data innfeed is supposed to keep in memory. This does not work properly yet.

-p pid-file

The -p flag is used to specify the file name to write the pid of the process into. A relative path is relative to pathrun as set in inn.conf. The default is innfeed.pid.

-s command

The -s flag specifies the name of a command to run in a subprocess and read article information from. This is similar to channel mode operation, only that command takes the place usually occupied by innd.

-S status-file

The -S flag specifies the name of the file to write the periodic status to. If the path is relative, it is considered relative to pathlog as set in inn.conf. The default is innfeed.status.

-v

When the -v flag is given, version information is printed to stderr and then innfeed exits.

-x

The -x flag is used to tell innfeed not to expect any article information from innd but just to process any backlog files that exist and then exit.

-y

The -y flag is used to allow dynamic peer binding. If this flag is used and article information is received from innd that specifies an unknown peer, then the peer name is taken to be the IP name too, and an association with it is created. Using this, it is possible to only have the global defaults in the innfeed.conf file, provided the peer name as used by innd is the same as the IP name. Note that innfeed with -y and no peer in innfeed.conf would cause a problem that innfeed drops the first article.

-z

The -z flag is used to cause each connection, in a parallel feed configuration, to report statistics when the controller for the connections prints its statistics.

## BUGS
When using the -x option, the config file entry's initial-connections field will be the total number of connections created and used, no matter how many big the batch file, and no matter how big the max-connections field specifies. Thus a value of 0 for initial-connections means nothing will happen in -x mode.

innfeed does not automatically grab the file out of pathoutgoing. This needs to be prepared for it by external means.

Probably too many other bugs to count.

## ALTERNATIVE
An alternative to innfeed can be innduct, maintained by Ian Jackson and available at <http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8>. It is intended to solve a design issue in the way innfeed works. As a matter of fact, the program feed protocol spoken between innd and innfeed is lossy: if innfeed dies unexpectedly, articles which innd has written to the pipe to innfeed will be skipped. innd has no way of telling which articles those are, no useful records, and no attempts to resend these articles.

## FILES
pathbin/innfeed

The binary program itself.

pathetc/innfeed.conf

The configuration file.

pathspool/innfeed

The directory for backlog files.

## HISTORY
Written by James Brister <brister@vix.com> for InterNetNews. Converted to POD by Julien Elie.

Earlier versions of innfeed (up to 0.10.1) were shipped separately; innfeed is now part of INN and shares the same version number.

$Id: innfeed.pod 9588 2013-12-19 17:46:41Z iulius $

## SEE ALSO
ctlinnd(8), inn.conf(5), innfeed.conf(5), innd(8), procbatch(8).


innreport

package: inn

title: innreport(8)

summary: summarize INN log files.

text:
# innreport(8)

## NAME
innreport - summarize INN log files.

## SYNOPSIS
innreport -f innreport.conf [ -[no]options ] [ logfiles ]

## DESCRIPTION
Innreport is a perl(1) script that summarizes INN log files. It is normally invoked by scanlogs(8). Supported programs are innd(8), innfeed(1), innxmit(8), nntplink, nnrpd(8), batcher(8), rnews(1) and a few others.

## OPTIONS
There are lots of 'em. Run innreport with ``-h'' or ``-help'' to get full details.

## HISTORY
Written by Fabien Tassin <fta@sofaraway.org> for InterNetNews. This is revision 8242, dated 2008-12-21.

## SEE ALSO
innd(8), innfeed(8), innxmit(8), news.daily(8), newslog(5), nnrpd(8), scanlogs(8), writelog(8).


innstat

title: innstat(8)

summary: print snapshot of INN system

text:
# innstat(8)

## NAME
innstat - print snapshot of INN system

## SYNOPSIS
innstat

## DESCRIPTION
The innstat script prints a snapshot of the INN system. It displays the operating mode of the server, as well as disk usage and the status of all log and lock files.

## HISTORY
Written by Landon Curt Noll <chongo@toad.com> and Rich $alz <rsalz@uunet.uu.net> for InterNetNews. This is revision 584, dated 1998-04-09.

## SEE ALSO
innd(8), news.daily(8), newslog(5), nnrpd(8)


innupgrade

title: innupgrade(8)

summary: Upgrade INN configuration files

text:
# innupgrade(8)

## NAME
innupgrade - Upgrade INN configuration files

## SYNOPSIS
innupgrade directory

innupgrade [-t type] -f file

## DESCRIPTION
innupgrade is intended to be run during a major upgrade of INN to fix the configuration files with any required changes. If given a directory, it will scan that directory for any files that it has updates defined for, try to perform those updates, and replace the files with updated versions if applying the updates resulted in any changes. The old versions of the files will be saved with a ".OLD" extension.

If the -f flag is used, only that file will be updated. If the file name doesn't match the standard file name of an INN configuration file, the optional -t flag may be given to specify the type. See "EXAMPLES" for an example of this.

Currently, innupgrade knows how to apply the following updates:

inn.conf

- Quote values with whitespace and comment out keys with no values, required for the change in configuration parsers introduced in INN 2.4. The new format is not backward compatible with the previous parser, since the previous parser will include the double-quotes in the value of the parameter.

- Add the hismethod parameter if not found (introduced in INN 2.4, with the default value "hisv6"). Rename nntpactsync to incominglogfrequency (since INN 2.5). Rename addnntppostingdate and addnntppostinghost to respectively addinjectiondate and addinjectionpostinghost (since INN 2.6).

- If the overview.fmt file exists, its content is merged in the extraoverviewadvertised and extraoverviewhidden parameters introduced in INN 2.5. The file is then renamed to overview.fmt.OLD.

- If the sasl.conf file exists, its content is merged in the tlscapath, tlscafile, tlscertfile and tlskeyfile parameters introduced in INN 2.5. The file is then renamed to sasl.conf.OLD.

newsfeeds

•

Replace the use of startinnfeed with the appropriate direct invocation of innfeed or imapfeed.

A few obsolete programs or configuration files are renamed with a ".OLD" extension by innupgrade. Obsolete man pages are directly removed.

Normally, innupgrade should be run at least on the pathetc directory after any upgrade of INN other than a patch release (any upgrade that changes the first or second version numbers). This may occur automatically during the upgrade process.

## OPTIONS
-f file

Only act on file rather than working on an entire directory.

-t type

For a file specified with -f, parse it and upgrade it as if it were named type. Used for upgrading files with the same syntax as normal INN configuration files but with different names. Only makes sense in combination with -f.

## EXAMPLES
Upgrade any configuration files found in pathetc and append a ".OLD" extension to obsolete files in pathetc:

```
    innupgrade <pathetc in inn.conf>
```

Upgrade only /news/etc/inn.conf:

```
    innupgrade -f /news/etc/inn.conf
```

Upgrade a file named inn-special.conf that should have the same syntax as inn.conf:

```
    innupgrade -t inn.conf -f inn-special.conf
```

Any upgrade rules that apply to inn.conf will be applied to the alternate file.

## HISTORY
Written by Russ Allbery <eagle@eyrie.org> for InterNetNews.

$Id: innupgrade.pod 9767 2014-12-07 21:13:43Z iulius $


innwatch

title: innwatch(8)

summary: Monitor the state of INN and the system

text:
# innwatch(8)

## NAME
innwatch - Monitor the state of INN and the system

## SYNOPSIS
innwatch [-f ctlfile] [-i seconds] [-l logfile] [-t seconds]

## DESCRIPTION
innwatch is normally started by rc.news. Every innwatchsleeptime seconds, as set in inn.conf, it examines the load average, and the number of free blocks and inodes on the spool partition, as described by its control file, innwatch.ctl in pathetc.

If the load gets too high, or the disk gets too full, it throttles the server. When the condition restores, it unblocks the server. In addition, on each pass through the loop, it will check the logfile pathlog/news.crit to see if it has been modified, and send mail to the news administrator if so.

Upon receipt of an interrupt signal (SIGINT), innwatch will report its status in the file innwatch.status in pathrun.

## OPTIONS
-f file

Specify the control file to use, other than the default of innwatch.ctl in pathetc.

-i seconds

With this option, innwatch has an initial sleep of seconds seconds at startup. This is useful when innwatch is started at the same time as INN, so that it can wait a little before beginning performing its checks.

-l logfile

Specify a log file to watch, other than the default of news.crit.

-t seconds

Specify the period in seconds between checks, to override the value set in inn.conf.

## HISTORY
Written by Mike Cooper <mcooper@usc.edu>, with modifications by <kre@munnari.oz.au>, Steve Groom <stevo@elroy.jpl.nasa.gov> and Christophe Wolfhugel <wolf@pasteur.fr>. Converted to POD by Julien Elie.

$Id: innwatch.pod 9722 2014-09-24 17:47:12Z iulius $

## SEE ALSO
inn.conf(5), innwatch.ctl(5), newslog(5), rc.news(8).


innxbatch

title: innxbatch(8)

text:
# innxbatch(8)

## NAME
innxbatch - send xbatched Usenet articles to a remote NNTP server

## SYNOPSIS
innxbatch [ -D ] [ -t timeout ] [ -T timeout ] [ -v ] host file ...

## DESCRIPTION
Innxbatch connects to the NNTP server at the specified host and sends it the specified xbatch files, using the XBATCH extension to the NNTP protocol. It is normally invoked by a script run out of cron(8) that uses shlock(1) to lock the host name, followed by a ctlinnd(8) command to flush the batchfile.

Each file is removed after it has been successfully transferred.

If a communication error such as a write(2) failure, or an unexpected reply from the remote server occurs, innxbatch will stop sending and leave all remaining files untouched for later retry.

## OPTIONS
-t seconds

Innxbatch normally blocks until the connection is made. To specify a timeout on how long to try to make the connection, use the ``-t'' flag.

-T seconds

To specify the total amount of time that should be allowed for article transfers, use the ``-T'' flag.

The default is to wait until an I/O error occurs, or all the articles have been transferred. If the ``-T'' flag is used, the time is checked just before each article is started; it will not abort a transfer that is in progress.

-v

Upon exit, innxbatch reports transfer and CPU usage statistics via syslog(3). If the ``-v'' flag is used, they will also be printed on the standard output.

-D

Use the ``-D'' flag to print debugging information on standard error. This will show the protocol transactions between innxbatch and the NNTP server on the remote host.

## EXAMPLES
A sample newsfeeds(5) entry to produce appropriate xbatch files (thanks to Karsten Leipold <poldi@dfn.de>):

```
  nase\

    :*\

    :Tc,Wnb\

    :<pathbin in inn.conf>/batcher \

       -p "(<$ac_cv_path_COMPRESS in config.cache> >\

       <pathoutgoing in inn.conf>/nase.\$\$)" \

       nase.do.main
```

A sample script to invoke innxbatch(8) is:

```
  #!/bin/sh

  ##  SH script to send xbatches for a site, wrapped around innxbatch

  ##  Invocation:

  ##     sendxbatches.sh <sitename> <hostname> <xbatch file name> ...

  if [ $# -le 3 ]

  then
	echo "usage: $0 <sitename> <hostname> <xbatch file name>"
	exit 1

  fi

  . <pathbin in inn.conf>/innshellvars

  site="$1"; host="$2"; shift; shift

  ctlinnd flush "$site" \

  && sleep 5 \

  && exec $NEWSBIN/innxbatch -v -D "$host" $*
```

## HISTORY
Written by Stefan Petri <petri@ibr.cs.tu-bs.de>, modelled after innxmit(8) and the XBATCH patch for the nntp reference implementation.

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


innxmit

title: innxmit(8)

text:
# innxmit(8)

## NAME
innxmit - Send Usenet articles to a remote NNTP server

## SYNOPSIS
innxmit [-acdHlprsv] [-P portnum] [-T seconds] [-t seconds] host file

## DESCRIPTION
innxmit connects to the NNTP server at the specified host (validating itself via passwd.nntp if possible) and sends it the articles specified in the batch file named file. It is normally invoked by a script run out of cron(8) that uses shlock to lock the host name, followed by a ctlinnd command to flush the batch file. If file is not an absolute path name, it is taken relative to the directory specified by the pathoutgoing parameter in inn.conf. It is normally written by specifying the "Wnm" flags in the newsfeeds file. Each line in the batch file should be in one of the following formats:

```
    article Message-ID
    article
```

The first field is either the storage API token of an article or the name of a file holding an article. If it is not an absolute pathname or a storage API token, it is taken to be a file name relative to patharticles in inn.conf. If the second field is not specified, the message-ID will be obtained by scanning the article. The two fields, if present, are separated by a space. If a communication error such as a write(2) failure occurs, innxmit will stop sending and rewrite the batch file to contain the current article and any other unsent articles.

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

## OPTIONS
-a

If all articles were sent successfully, innxmit will remove the batch file; otherwise it will rewrite it to contain the list of unsent articles. If no articles were sent or rejected, the file is left untouched. This can cause the batch file to grow excessively large if many articles have been expired and there are communication problems. To always rewrite the batch file, use the -a flag.

-c

In streaming mode, a check of each message-ID is still made to avoid sending articles already on the server. The -c flag will, if streaming mode is supported, result in sending articles without checking. This results in slightly greater throughput and may be appropriate when it is known that the site could not already have the articles such as in the case of a "leaf" site.

-d

Use the -d flag to print debugging information on standard error. This will show the protocol transactions between innxmit and the NNTP server on the remote host.

-H

If the -H flag is given, then only headers are sent to host for all articles except control messages. And the Bytes: header is also included even if it does not exist in the original article. The -H flag is useful for Diablo reader.

-l

The -l flag is used to turn on logging of reasons the remote gives for rejecting an article.

-P portnum

To specify a port number other than the default, use the -P flag.

-p

If the -p flag is given, then no connection is made and the batch file is purged of entries that refer to files that no longer exist. This implies the -a flag.

-r

If the remote server sends an unexpected reply code, innxmit will requeue the article and proceed. Use the -r flag if the article should not be requeued.

-s

innxmit will attempt to negotiate a streaming mode extension of the NNTP protocol with the server at connect time. If successful, it will use a slightly different protocol that enhances throughput. If the server does not recognize the streaming mode negotiation, innxmit will revert to normal NNTP transfer mode. Use the -s flag to disable the attempt to negotiate the streaming mode extension.

-T seconds

To specify the total amount of time that should be allowed for article transfers, use the -T flag. The default is to wait until an I/O error occurs, or all the articles have been transferred. If the -T flag is used, the time is checked just before each article is started; it will not abort a transfer that is in progress.

-t seconds

innxmit normally blocks until the connection is made. To specify a timeout on how long to try to make the connection, use the -t flag.

-v

Upon exit, innxmit reports transfer and CPU usage statistics via syslog. If the -v flag is used, they will also be printed on the standard output.

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

$Id: innxmit.pod 9588 2013-12-19 17:46:41Z iulius $

## SEE ALSO
ctlinnd(8), inn.conf(5), innd(8), newsfeeds(5), passwd.nntp(5), shlock(1).


mailpost

title: mailpost(8)

summary: Feed an e\-mail message into a newsgroup

text:
# mailpost(8)

## NAME
mailpost - Feed an e-mail message into a newsgroup

## SYNOPSIS
mailpost [-hn] [-a addr] [-b database] [-c wait-time] [-d distribution] [-f addr] [-m mailing-list] [-o output-command] [-p port] [-r addr] [-t tempdir] [-x header[:header...]] [-z header[:header...]] newsgroups

## DESCRIPTION
The mailpost program reads a properly formatted e-mail message from stdin and feeds it to inews for posting to a news server. newsgroups is a whitespace-separated list of group names to which to post the article (at least one newsgroup must be specified).

Before feeding the article to inews, it checks that the article has not been seen before, and it changes some header fields (cleans up some address headers, removes a few ones like X-Complaints-To: and X-Trace:, and puts "X-" in front of unknown header fields). The Received: and *-To: header fields are also altered to prevent spamming the gateway (the name of the news server or the domain name from inn.conf are removed).

If the article has been seen before (mailpost records the message-ID of each article it handles), then the article will be dropped with a non-zero error status. Other errors will cause the article to be mailed to the newsmaster (selected at configure time and defaulting to "usenet").

Normally, mailpost is run by sendmail(8) via an alias entry:

```
    local-mail-wreck-bikes: "|<pathbin in inn.conf>/mailpost
        -b /var/tmp -t /var/tmp -d local local.mail.rec.bicycles.racing"
```

The -b and -t flags are useful to change the directories used by mailpost by default. As a matter of fact, though it is recommended to run mailpost as the news user, it is as often as not run as another user, for instance the mail user. Therefore, you should make sure to create and set to be writable by the user that mailpost runs as the directories where to put the database and the temporary files.

Instead of /var/tmp, the mail spool directory can be specified, or any other directory where the mailpost process has write access.

## OPTIONS
-a addr

If the -a flag is used, the value given is added to the article as an Approved: header.

-b database

If the -b flag is used, then it defines the location of the persistent database used to store the message-IDs of articles sent on. This is to prevent articles looping around if a news-to-mail gateway sends them back here. This option may be required if the mailpost process does not have write access to the news database directory. The default value is pathdb as set in inn.conf.

-c wait-time

The -c flag indicates a length of time to sleep before posting. If duplicate messages are received in this interval (by any instance of mailpost using the same database), the article is only posted once, but with Newsgroups: header modified to crosspost the article to all indicated groups. The units for wait-time are seconds; a reasonable value may be anywhere from tens to hundreds of seconds, or even higher, depending on how long mail can be delayed on its way to your system.

-d distribution

If the -d flag is used, the value given is added to the article as a Distribution: header.

-f addr

The -f flag is a synonym for the -r flag.

-h

Print usage information and exit.

-m mailing-list

If the -m flag is used, the value given is added to the article in a Mailing-List: header, if such a header doesn't already exist.

-n

If the -n flag is used, neither an article is posted nor a mail is sent in case an error occurs. Everything is written to the standard output.

-o output-command

Specifies the program to which the resulting article processed by mailpost should be sent. For debugging purpose, "-o cat" can be used. The default value is "inews -S -h".

-p port

Specifies the port on which nnrpd is listening, used for article posting. If given, -p is passed along to inews.

-r addr

A heuristic is used to determine a reasonable value for the Path: header. The -r flag indicates what to use if no other value can be determined.

-t tempdir

If the -t flag is used, then it defines the location of the directory to use to temporarily store error messages that are sent to the newsmaster. This option may be required if the default value refers to a path that does not exist or the mailpost process does not have write access to. Two paths are tried by default: pathtmp as set in inn.conf, and then /var/tmp if pathtmp is not writable.

-x header[:header...]

A colon-separated list of additional header fields which should be treated as known header fields; these header fields will be passed through to inews without having "X-" prepended. Known header fields are:

```
    Archive
    Archived-At
    Comments
    Content-*
    Date
    Distribution
    From
    Injection-Date
    Keywords
    Mailing-List
    Message-ID
    MIME-*
    Organization
    References
    Return-Path
    Sender
    Subject
    Summary

```

-z header[:header...]

A colon-separated list of additional header fields which should be removed. Removed header fields are:

```
    X-Trace
    X-Complaints-To

```

## FILES
pathbin/mailpost

The Perl script itself used to feed an e-mail message to a newsgroup.

pathdb/mailpost-msgid.dir and pathdb/mailpost-msgid.pag

The default database files which record previously seen message-IDs.

## HISTORY
Written by Paul Vixie long ago and then hacked up by James Brister for INN integration.

$Id: mailpost.in 10171 2017-07-22 14:01:37Z iulius $

## SEE ALSO
active(5), inews(1), inn.conf(5), nnrpd(8), uwildmat(3).


makedbz

title: makedbz(8)

summary: Rebuild dbz files

text:
# makedbz(8)

## NAME
makedbz - Rebuild dbz files

## SYNOPSIS
makedbz [-io] [-f filename] [-s size]

## DESCRIPTION
makedbz rebuilds dbz(3) database. The default name of the text file is pathdb/history; to specify a different name, use the -f flag.

## OPTIONS
-f filename

If the -f flag is used, then the database files are named "filename.dir", "filename.index", and "filename.hash". If the -f flag is not used, then a temporary link to the name "history.n" is made and the database files are written as "history.n.index" , "history.n.hash" and "history.n.dir".

-i

To ignore the old database, use the -i flag. Using the -o or -s flags implies the -i flag.

-o

If the -o flag is used, then the temporary link to "history.n" (or the name specified by the -f flag) is not made and any existing history files are overwritten. If the old database exists, makedbz will use it to determine the size of the new database.

-s size

makedbz will also ignore any old database if the -s flag is used to specify the approximate number of entries in the new database. Accurately specifying the size is an optimization that will create a more efficient database. Size is measured in key-value pairs (i.e. lines). (The size should be the estimated eventual size of the file, typically the size of the old file.) For more information, see the discussion of dbzfresh and dbzsize in dbz(3).

## HISTORY
Written by Katsuhiro Kondou <kondou@nec.co.jp> for InterNetNews. Converted to POD by Julien Elie.

$Id: makedbz.pod 9934 2015-08-28 19:28:56Z iulius $

## SEE ALSO
dbz(3), history(5).


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(3) 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.

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.

## 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: headers 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 pairs. Accurately specifying the size is an optimization that will create a more efficient database. (The size should be the estimated eventual size of the history file, typically the size of the old file, in lines.)

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

$Id: makehistory.pod 8534 2009-06-23 18:08:14Z iulius $

## SEE ALSO
active(5), ctlinnd(8), dbz(3), history(5), inn.conf(5), innd(8), makedbz(8), ovdb_init(8), overchan(8).


mod-active

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


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;

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

- processing innfeed dropped files with procbatch;

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

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

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.

$Id: news.daily.pod 9628 2014-05-14 17:22:01Z iulius $

## SEE ALSO
active(5), ctlinnd(8), expire(8), expire.ctl(5), expireover(8), expirerm(8), fastrm(8), 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 sendmail 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 will have the mailing-list address (i.e. the second field). Besides, news2mail strips most article headers 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     big-red-ants@lists.ucsd.edu     news+big-red-ants@local.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 funneled channel in newsfeeds, implying multiple matches should be handled as one - and multiple matching funneled 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.

$Id: news2mail.pod 8199 2008-11-30 13:30:47Z iulius $

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


ninpaths

title: ninpaths(8)

text:
# ninpaths(8)

## NAME
ninpaths - Report Usenet Path: 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: lines 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: headers of articles.

Some central sites accumulate the Path: 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: lines. 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 an 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. The format of these dump files is described below.

-p

Read Path: lines 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 lines 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: headers 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.

$Id: ninpaths.pod 9383 2011-12-25 20:56:10Z iulius $

## 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 [-DfnoSt] [-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 only reads config files (both readers.conf and inn.conf) when it is spawned. You can therefore never change the behavior of a client that's already connected. If nnrpd is run from innd (the default) or from inetd(8), xinetd(8), or some equivalent, a new nnrpd process is spawned for every connection and therefore any changes to configuration files will be immediately effective for all new connections. If you are instead running nnrpd with the -D option, any configuration changes 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).

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

-c configfile

By default, nnrpd reads the readers.conf 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).

-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; 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(8) 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, nnrpd tries to change its "argv" array so that ps(1) will print out 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 the program changes its title.

-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
```

Note that unlike Apache's SSLCertificateFile directive, tlscertfile should not contain a concatenation of certificates. Instead, if you have a certificate authority root certificate, set tlscafile to its path.

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.

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.

## 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 headers 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 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(3)-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").

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

$Id: nnrpd.pod 10373 2020-05-21 21:00:33Z iulius $

## SEE ALSO
ctlinnd(8), innd(8), inn.conf(5), readers.conf(5), signal(2), uwildmat(3).


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.

$Id: nntpsend.pod 9588 2013-12-19 17:46:41Z iulius $

## SEE ALSO
inn.conf(5), innxmit(1), 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.

## 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 irrepairable 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.

Note that the -u option can be used even if no upgrades are needed.

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

$Id: ovdb_init.pod 10241 2018-02-04 15:38:19Z iulius $

## 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, deadlock detection, and transaction log removal.

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.

$Id: ovdb_monitor.pod 10241 2018-02-04 15:38:19Z iulius $

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

$Id: ovdb_server.pod 10191 2017-11-25 21:11:53Z iulius $

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

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

$Id: ovdb_stat.pod 10241 2018-02-04 15:38:19Z iulius $

## SEE ALSO
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>.

$Id: overchan.pod 9767 2014-12-07 21:13:43Z iulius $

## SEE ALSO
inn.conf(5), innd(8), newsfeeds(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

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

perl-nocem processes third-party, PGP-signed article cancellation notices. It is possible not to honour all NoCeM notices but only those which are sent by people whom you trust (that is to say if you trust the PGP key they use to sign their NoCeM notices). Indeed, it is up to you to decide whether you wish to honour their notices, depending on the criteria they use.

Processing NoCeM notices is easy to set up:

1.

Import the keys of the NoCeM issuers you trust in order to check the authenticity of their notices. You can do:

```
    gpg1 --no-default-keyring --primary-keyring <pathetc>/pgp/ncmring.gpg \
         --no-options --allow-non-selfsigned-uid --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 key(s) to import. The keyring must be located in <pathetc>/pgp/ncmring.gpg; 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.

As a few NoCeM issuers are still using old PGP-generated keys, you may have to use gpg1 with various legacy options in command-line (like in the example above) instead of more recent versions of gpg that no longer accept such keys.

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

2.

Create a nocem.ctl config file in pathetc indicating the NoCeM issuers and 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 corresponding to the criteria specified after the colon.

You will also find information about that on the web site of The NoCeM Registry.

3.

Add to the newsfeeds file an entry like this one in order to feed perl-nocem the NoCeM notices posted to alt.nocem.misc and news.lists.filters:

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

```

with the correct path to perl-nocem, located in <pathbin>. Then, reload the newsfeeds file ("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.

4.

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

```
    grephistory '<Message-ID>' | perl-nocem

```

Indeed, perl-nocem expects tokens on its standard input, and grephistory can easily give it the token of a known article, thanks to its Message-ID.

When you have verified that everything works, you can eventually turn off regular spam cancels, if you want, not processing any longer cancels containing "cyberspam" in the Path: header (see the refusecybercancels parameter in inn.conf).

## FILES
pathbin/perl-nocem

The Perl script itself used to process NoCeM notices.

pathetc/nocem.ctl

The configuration file which specifies the NoCeM notices to be processed.

pathetc/pgp/ncmring.gpg

The keyring which contains the public keys of trusted NoCeM issuers.

## BUGS
The Subject: header is not checked for the @@NCM string and there is no check for the presence of the References: header.

The Newsgroups: pseudo header is not checked, but this can be done in local_want_cancel_id().

The Hierarchies: header is ignored.

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

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

$Id: perl-nocem.in 10399 2020-11-12 20:24:35Z iulius $

## SEE ALSO
gpg(1), gpgv(1), grephistory(1), inn.conf(5), 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 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.

$Id: procbatch.pod 9371 2011-09-04 09:21:43Z iulius $

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