expire

title: expire(8)

text:
# expire(8)

## NAME
expire - Usenet article and history expiration program

## SYNOPSIS
expire [-iNnptx] [-d dir] [-f file] [-g file] [-h file] [-r reason] [-s size] [-v level] [-w number] [-z file] [expire.ctl]

## DESCRIPTION
expire scans the history(5)-format text file pathdb/history and uses the information recorded in it to purge itself of old news articles. Its behaviour depends on the setting of groupbaseexpiry in inn.conf.

When groupbaseexpiry is false, article expiration is primarily done by expire based on the expiration rules in expire.ctl that match the storage class of each article. The articles and the history entries are removed by expire, and then expireover does the additional cleanup of removing the overview database entries. History entries of expired articles are removed only if they are older than the number of days specified in the "/remember/" line in expire.ctl. Articles stored using a storage method that has self-expire functionality like CNFS are by default not affected by expire's primary behaviour (but see the -N flag to disable this).

When groupbaseexpiry is true, article expiration is primarily done by expireover based on the expiration rules in expire.ctl that match each newsgroup. Articles are removed from the news spool by expireover, and then expire does some additional cleanup to remove old history database entries.

For articles in self-expiring storage methods when groupbaseexpiry is set to false in inn.conf and the -N flag is not given, or for all articles when groupbaseexpiry is set to true, expire.ctl is ignored except the "/remember/" line; expire then only probes to see if the article still exists, and purges the relevant history entries if appropriate.

Regardless the setting of groupbaseexpiry, expireover should be run along with expire, usually via news.daily out of cron.

Note that expire never purges articles which do not match any entry in expire.ctl.

Also note that if groupbaseexpiry is true, the server needs an overview database in order to expire articles in storage backends that are not self-expiring. If you do not plan to have an overview database, it would then be better to only use self-expiring backends like CNFS, as the history entries will still get cleaned up by expire when it detects that an article no longer exists in that backend.

## OPTIONS
-d dir

If the -d flag is used, then the new history file and database is created in the specified directory dir. This is useful when the filesystem does not have sufficient space to hold both the old and new history files. When this flag is used, expire leaves the server paused and creates a zero-length file named after the new history file, with an extension of ".done" to indicate that it has successfully completed the expiration. The calling script should install the new history file and unpause the server. The -r flag should be used with this flag.

-f file

To specify an alternate history file, use the -f flag. This flag is valid when used with the -d flag, and the output will be written to the specified file. The default without -f is "history".

-g file

If the -g flag is given, then a one-line summary equivalent to the output of -v 1, except preceded by the current time, will be appended to the specified file.

-h file

To specify an alternate input text history file, use the -h flag. expire uses the old dbz database to determine the size of the new one. (If the -d flag is not used, the output filename will be the same as the input filename with an extension of ".n".) The default without the -h flag is pathdb/history.

-i

To ignore the old database, use the -i flag.

-N

The control file is normally ignored for articles in storage methods which have self-expire functionality. If the -N flag is used, expire still uses the control file for these articles. This parameter is only useful when groupbaseexpiry is set to false in inn.conf.

-n

If innd is not running, use the -n flag and expire will not send the "pause" or "go" commands. (For more details on the commands, see ctlinnd(8)). Note that expire only needs exclusive access for a very short time -- long enough to see if any new articles arrived since it first hit the end of the file, and to rename the new files to the working files.

-p

expire makes its decisions on the time the article arrived, as found in the history file. This means articles are often kept a little longer than with other expiration programs that base their decisions on the article's posting date. To use the article's posting date, use the -p flag.

-r reason

expire normally sends a "pause" command to the local innd daemon when it needs exclusive access to the history file, using the string "Expiring" as the reason. To give a different reason, use the -r flag. The process ID will be appended to the reason. When expire is finished and the new history file is ready, it sends a "go" command. See also the -n flag.

-s size

expire determines the optimal size of the new history file from the size of the old one. In case you want to force a specific size, use this flag to optimize the new history database for approximately size key-value pairs (i.e. lines in history). Accurately specifying the size will create a more efficient database. (The size should be the estimated eventual number of articles, typically the size of the old history file, in lines.)

-t

If the -t flag is used, then expire will generate a list of the tokens that should be removed on its standard output, and the new history file will be left in history.n, history.n.dir, history.n.index and history.n.hash. This flag is useful for debugging when used with the -n flag. Note that if the -f flag is used, then the name specified with that flag will be used instead of history.

-v level

The -v flag is used to increase the verbosity of the program, generating messages to standard output. The level should be a number, where higher numbers result in more output. Level one will print totals of the various actions done (not valid if a new history file is not written), level two will print a report on each individual file, while level five results in multiple lines of output for every history line processed.

-w number

Use the -w flag to "warp" time so that expire thinks it is running at some time other than the current time. The value should be a signed floating point number indicating the number of days to use as the offset.

-x

If the -x flag is used, then expire will not create any new history files. This is most useful when combined with the -n and -t flags to see how different expiration policies would change the amount of disk space used.

-z file

If the -z flag is used, then articles are not removed, but their names are appended to the specified file. See the description of delayrm in news.daily(8). If a filename is specified, it is taken as the control file and parsed according to the rules in expire.ctl. A single dash ("-") may be used to read the file from standard input. If no file is specified, the file pathetc/expire.ctl is read.

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

## SEE ALSO
ctlinnd(8), expire.ctl(5), expireover(8), history(5), inn.conf(5), innd(8), libinn_dbz(3), libinn_inndcomm(3), news.daily(8).


expireover

package: inn

title: expireover(8)

text:
# expireover(8)

## NAME
expireover - Expire entries from the news overview database

## SYNOPSIS
expireover [-ekNpqs] [-f file] [-w offset] [-z rmfile] [-Z lowmarkfile]

## DESCRIPTION
expireover expires old entries from the news overview database. It reads in a list of newsgroups (by default from pathdb/active, but a different file can be specified with the -f option) and then removes from the overview database mentions of any articles that no longer exist in the news spool.

If groupbaseexpiry in inn.conf is true, expireover also removes old articles from the news spool according to the expiration rules in expire.ctl. Otherwise it only removes overview entries for articles that have already been removed by some other process, and -e, -k, -N, -p, -q, -w, and -z are all ignored.

When groupbaseexpiry is set, the default behavior of expireover is to remove the article from the spool once it expires out of all of the newsgroups to which it was crossposted. The article is, however, removed from the overview database of each newsgroup as soon as it expires out of that individual newsgroup. The effect is that an article crossposted to several groups will be removed from the overview database from each group one-by-one as its age passes the expiration threshold for that group as set in expire.ctl, and then when it expires out of the last newsgroup, it will be deleted from the news spool.

Articles that are stored in self-expiring storage backends such as CNFS are normally treated differently and not expired until they expire out of the backend regardless of expire.ctl. See -N, however.

By default, expireover purges all overview information for newsgroups that have been removed from the server; this behavior is suppressed if -f is given.

## OPTIONS
-e

Remove articles from the news spool and all overview databases as soon as they expire out of any newsgroup to which they are posted, rather than retain them until they expire out of all newsgroups. -e and -k cannot be used at the same time. This flag is ignored if groupbaseexpiry is false.

-f file

Use file as the newsgroup list instead of pathdb/active. file can be "-" to indicate standard input. Using this flag suppresses the normal purge of all overview information from newsgroups that have been removed from the server.

-k

Retain all overview information for an article, as well as the article itself, until it expires out of all newsgroups to which it was posted. This can cause articles to stick around in a newsgroup for longer than the expire.ctl rules indicate, when they're crossposted. -e and -k cannot be used at the same time. This flag is ignored if groupbaseexpiry is false.

-N

Apply expire.ctl rules to expire articles even from storage methods that have self-expire functionality. This may remove articles from self-expiring storage methods before the articles "naturally" expire. This flag is ignored if groupbaseexpiry is false.

-p

By default, expireover bases decisions on whether to remove an article on the arrival time on the server. This means that articles may be kept a little longer than if the decision were based on the article's posting date. If this option is given, expiration decisions are based on the article posting date instead. This flag is ignored if groupbaseexpiry is false.

-q

expireover normally prints statistics at the end of the expiration process. -q suppresses this report. This flag is ignored if groupbaseexpiry is false.

-s

expireover normally only checks the existence of articles in the news spool if querying the storage method for that article to see if it still exists is considered "inexpensive". To always check the existence of all articles regardless of how resource-intensive this may be, use the -s flag. See storage.conf(5) for more information about this metric.

-w offset

"Warps" time so that expireover thinks that it's running at some time other than the current time. This is occasionally useful to force groups to be expired or not expired without changing expire.ctl for the expire run. offset should be a signed floating point number specifying the number of days difference from the current time to use as "now". This flag is ignored if groupbaseexpiry is false.

-z rmfile

Don't remove articles immediately but instead write the path to the article or the token of the article to rmfile, which is suitable input for fastrm(1). This can substantially speed up deletion of expired articles for those storage methods where each article is a single file (such as tradspool and timehash). See the description of the delayrm keyword in news.daily(8) for more details. This flag is ignored if groupbaseexpiry is false.

-Z lowmarkfile

Write the lowest article numbers for each newsgroup as it's expired to the specified file. This file is then suitable for "ctlinnd lowmark". See ctlinnd(8) for more information.

## EXAMPLES
Normally expireover is invoked from news.daily(8), which handles such things as processing the rmfile and lowmarkfile if necessary. Sometimes it's convenient to manually expire a particular newsgroup, however. This can be done with a command like:

```
    echo example.test | expireover -f - -Z <pathtmp in inn.conf>/lowmark
    ctlinnd lowmark <pathtmp>/lowmark
```

This can be particularly useful if a lot of articles in a particular group have expired but the overview information is still present, causing some clients to see a lot of "this article may have been cancelled" messages when they first enter the newsgroup.

## HISTORY
Written by Rob Robertson <rob@violet.berkeley.edu> and Rich $alz <rsalz@uunet.uu.net> (with help from Dave Lawrence <tale@uunet.uu.net>) for InterNetNews.

## SEE ALSO
active(5), ctlinnd(8), expire(8), expire.ctl(5), inn.conf(5), news.daily(8).


expirerm

title: expirerm(8)

summary: Remove articles that have been expired

text:
# expirerm(8)

## NAME
expirerm - Remove articles that have been expired

## SYNOPSIS
expirerm file

## DESCRIPTION
expirerm is a script that removes a list of files. The specified file lists the files to be removed. It is usually created by expire -z. This file is sorted, and then fed into a pipeline responsible for doing the removal, normally fastrm. (You may want to edit expirerm to change the flags passed to fastrm.)

If there seemed to be a problem removing the files, then a mail is sent to the news administrator. If there were no problems, then file is renamed to pathlog/expire.list where it is kept (for safety) until the next time expiration is done.

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

## SEE ALSO
expire(8), fastrm(1), newslog(5).


ident

title: ident(8)

summary: nnrpd ident resolver

text:
# ident(8)

## NAME
ident - nnrpd ident resolver

## SYNOPSIS
ident [-p port] [-t]

## DESCRIPTION
This program attempts to resolve usernames for nnrpd by using the ident protocol to query the remote host. It contacts the remote host using either IPv4 or IPv6 depending on which protocol was used for the incoming NNTP connection.

## OPTIONS
-p port

If this option is given, attempt to contact identd on the specified remote port (which can be a numeric or symbolic specification). Non-numeric values will be looked up using getservbyname(3). The default value is the result of "getservbyname("ident")" if available, or port 113 otherwise.

-t

If this option is given, the identity returned will never have a domain part. That is, if the remote server returns a result containing an "@" character, ident truncates the response at the "@". This is useful to allow the default-domain parameter in readers.conf to override the domain supplied by the remote host (particularly if the supplied domain part is an unqualified local machine name rather than a full domain name).

## EXAMPLE
The following readers.conf(5) fragment tells nnrpd to trust ident information for hosts on a local network, but to replace the domain returned from the ident query:

```
    auth LAN {
        hosts: "192.168/16"
        res: "ident -t"
        default-domain: "internal.example.com"
    }
    access LAN {
        users: "*@internal.example.com"
        newsgroups: example.*
    }
```

Access is granted to the example.* groups for all users on the local network whose machines respond to ident queries.

## HISTORY
This documentation was written by Jeffrey M. Vinocur <jeff@litech.org>.

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


innbind

title: innbind(8)

text:
# innbind(8)

## NAME
innbind - Helper program to bind sockets to privileged ports

## SYNOPSIS
innbind [-p] fd,family,address,port [...]

## DESCRIPTION
innbind is a helper program that's not meant to be run directly. Instead, innd and nnrpd use it internally to bind to ports that require root privileges to bind to.

This program must be installed setuid root in order for innd or nnrpd to bind to ports under 1024. The only functions that it's willing to perform are to bind an open file descriptor to a given address and port or to create a new socket, bind it, and return the bound socket to its caller. It can only be run as the news user (as specified at configure time), and will only bind to ports 119, 433, 563, an additional port specified with the --with-innd-port argument to configure, or ports numbered 1024 or higher.

Each argument to innbind must be a comma-separated list of four elements. The first is the file descriptor number that should be bound, the second is the numeric family of the socket (AF_INET or AF_INET6), the third is the local address to bind to (in dotted-quad format for IPv4 and in colon-separated address format for IPv6), and the fourth is the port number. To bind to all addresses with IPv4, use 0.0.0.0 as the address. To bind to all addresses with IPv6, use "::" as the address.

Multiple arguments can be specified to tell innbind to bind multiple sockets at the same time. Any errors (other than permission denied -- see below) encountered will cause innbind to abort, and error messages will be sent both to syslog and to standard error.

By default, innbind attempts to just bind the already open file descriptor that it inherits from its caller. For each successfully bound file descriptor (in the order given on the command line), innbind prints "ok" and a newline to its standard output.

On some systems (apparently just STREAMS-based systems), however, even a setuid root program cannot bind a socket to a privileged port that was created by a process that didn't have permissions. If innbind gets permission denied when trying to bind a socket, it will print "no" and a newline to its standard output. It will then create a new socket, bind it as specified, and then attempt to pass that socket back to its caller using the I_SENDFD STREAMS ioctl. The caller should receive that file descriptor with I_RECVFD and use it instead of the one that it created.

Note that file descriptor passing is only supported on STREAMS-based systems since it is done with ioctls over a pipe. However, it is believed that those systems are exactly the systems that can't simply bind the inherited file descriptor. If this assumption proves to be incorrect, traditional BSD file descriptor passing over a Unix domain socket will have to be added.

## OPTIONS
-p

If given as the first command-line argument, no attempt will be made to bind the inherited file descriptor and innbind will only try creation of a new file descriptor and passing it back via standard output. This option is primarily useful for testing.

## SECURITY
As innbind is normally installed setuid root, security is even more of an issue for it than for other parts of INN. It is a fairly short program, and if you understand C, you are encouraged to audit it yourself to be certain that it does only what it is supposed to do. The only INN library functions it uses are the vector functions, the message functions for error reporting, and xstrdup.

The ports that will be bound are restricted to prevent potential attacks made possible by the ability to bind low-numbered ports, such as exploits of the rsh(1) family of commands on some systems. If innbind is installed setuid root, it can only be executed by the news user to prevent other users on the system from being able to bind to even those few privileged ports that it allows.

innbind uses no external configuration files; the only files it might open are through the system getpwnam(3) service to get the UID of the news user. The only user input that it accepts are its command-line arguments.

## DIAGNOSTICS
innbind may log the following messages to syslog and print them to standard error.

cannot create socket for %s: %s

(Fatal) innbind fell back on attempting to create a new socket to bind for the given argument, and the socket creation failed.

cannot bind socket for %s: %s

(Fatal) Calling bind for the socket corresponding to the given argument failed with a system error. If the error indicates permission denied, make sure that innbind is setuid root. This can also be caused by trying to use IPv6 on a system whose kernel does not support it.

cannot bind to restricted port %hu in %s

(Fatal) The port number portion of the given command-line argument is for a port below 1024 which is not 119, 433, 563, or a port given to --with-innd-port at configure time. Other ports are not allowed for security reasons.

cannot get socket options for file descriptor %d: %s

(Fatal) innbind was unable to get the socket options for that file descriptor. The most likely cause of this error is passing the wrong file descriptor number to innbind (a file descriptor that isn't open, or that corresponds to a regular file rather than a network socket).

cannot get UID for %s

(Fatal) innbind was unable to get the UID for the news user specified during configure (and defaulting to "news"). This normally means that user isn't in the system passwd file.

cannot mark socket reusable for %s: %s

(Fatal) innbind created a new socket for the given argument but was unable to mark its bind address reusable (the SO_REUSEADDR socket option).

cannot pass file descriptor: %s

(Fatal) innbind created and bound a new file descriptor but was unable to pass it back to its caller via its standard output, using the I_SENDFD STREAMS ioctl.

invalid file descriptor %d: not SOCK_STREAM

(Fatal) The given file descriptor is not a SOCK_STREAM socket. innbind can only bind SOCK_STREAM sockets.

invalid IPv4 address %s in %s

(Fatal) The IPv4 address specified in the given command-line option could not be parsed by inet_aton(3). IPv4 addresses should be specified in the standard dotted-quad format (10.2.3.4).

invalid IPv6 address %s in %s

(Fatal) The IPv6 address specified in the given command-line option could not be parsed by inet_pton(3). IPv6 addresses should be specified in RFC 4291 format (1080:0:0:0:8:800:200C:417A or 1080::8:800:200C:417A).

invalid command-line argument %s

(Fatal) The specified command-line argument could not be parsed or was not in the correct format.

invalid file descriptor %s in %s

(Fatal) The file descriptor portion of the given command-line argument is not a non-negative integer.

invalid port number %s in %s

(Fatal) The port number portion of the given command-line argument is not a non-negative integer.

invalid protocol family %s in %s

(Fatal) The protocol family portion of the given command-line argument is not a non-negative integer. It should be equal to either AF_INET or AF_INET6 on the system where innbind is run.

must be run by user %s (%lu), not %lu

(Fatal) When setuid root, innbind may only be run by the news user as specified at configure time ("news" by default), for security reasons.

no addresses specified

(Fatal) No arguments were given on the command line (except maybe -p).

port may not be zero in %s

(Fatal) The port number portion of the given command-line argument was zero.

unknown protocol family %s in %s

(Fatal) The protocol number portion of the given command-line argument is neither AF_INET nor AF_INET6.

## EXAMPLES
As mentioned above, innbind is never run directly, only by innd and other programs that need to bind to and listen to network ports. Sample invocations by innd would be:

```
    innbind 3,10,::,119
```

to bind the IPv6 socket on file descriptor 3 to port 119, all addresses, or:

```
    innbind 6,2,10.0.0.3,433
```

to bind the IPv4 socket on file descriptor 6 to port 433 in the address 10.0.0.3.

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

## SEE ALSO
inet_aton(3), inet_pton(3), innd(8), nnrpd(8).


inncheck

title: inncheck(8)

text:
# inncheck(8)

## NAME
inncheck - Check INN configuration and database files

## SYNOPSIS
inncheck [-afqv] [--noperm | --perm] [--pedantic] [file | file=path ...]

## DESCRIPTION
inncheck examines various configuration files and databases and verifies things about them. Things verified depend on the file being checked, but generally are things like permissions, ownership, syntax errors in config files, etc.

inncheck does not make changes to any files -- it just reports what it thinks may be wrong, and it is up to the operator to fix the problem

The set of files checked may be restricted by using file or file=path arguments. For example, putting "incoming.conf" causes only the incoming.conf file to be checked. Using "incoming.conf=/tmp/incoming.conf" on the command line will cause inncheck to only verify the incoming.conf file, and it will perform the checks on the /tmp/incoming.conf file instead of the default one. Setting a file path to an empty value like "incoming.conf=" will skip the check for that file (this only makes sense with -a, or no files will be checked at all).

Valid values for file are:

```
    active
    control.ctl
    control.ctl.local
    expire.ctl
    incoming.conf
    inn.conf
    innfeed.conf
    moderators
    newsfeeds
    nntpsend.ctl
    passwd.nntp
    readers.conf
    storage.conf
```

## OPTIONS
-a, --all

If any file value or file=path pairs (see below) are given, then normally only the files they refer to are checked. Use the -a (or --all) flag to specify that all files should be checked regardless. In this case the form file=path will be the more useful.

-f, --fix

Use the -f flag (or --fix) to have inncheck print the appropriate chown/chgrp/chmod command necessary to fix a problem that it reports. Any other output lines will be prefixed with a hash sign ("#") to make the output be valid input for a shell. Note that the --perm flag must be used as well when using this flag.

--noperm

To avoid doing any checking of file permissions or ownership, use the --noperm option.

--pedantic

Use the --pedantic option to get reports on things that are not necessarily wrong, but may indicate a bad configuration, such as inn.conf missing a key.

--perm

inncheck checks all files for permission problems. If the --perm flag is used, then only the files specified by the file or file=path command line arguments will be checked for problems other than permission problems.

-q, --quiet

Use the -q option (or --quiet) to get less output.

-v, --verbose

Use the -v option (or --verbose) to get more verbose output.

## EXAMPLES
To have inncheck check all files for syntax and permission problems simply run:

```
    inncheck
```

It is recommended to run the following command to be aware of all the potential problems inncheck can detect:

```
    inncheck -a --perm --pedantic
```

To have inncheck check all files for permission problems and to verify the syntax of the active and incoming.conf files, do:

```
    inncheck --perm active incoming.conf
```

To fix the permissions problems noted in the output of the above command, modify it as follows:

```
    inncheck -f --perm | sh
```

(Note that it is useless to mention the name of the two files since permission problems are checked on all files.)

To have inncheck check the test newsfeeds file in /var/tmp/newsfeeds.testing, do:

```
    inncheck newsfeeds=/var/tmp/newsfeeds.testing
```

To have inncheck check all the files as it normally does, but to specify a different location for the newsfeeds file and omit checking of the innfeed.conf file, do:

```
    inncheck -a newsfeeds=/var/tmp/newsfeeds.testing innfeed.conf=
```

## BUGS
If the -f and --perm options are used together, along with -a or some file or file=path arguments that refer to a file with a syntax problem, then the output will no longer be valid input for a shell.

In most cases, inncheck currently does not correctly understand option values spanning multiple lines. If you get error messages about runaway quotes, you either have to ignore them and check the correctness of the relevant lines yourself, or merge the value into a single line.

## HISTORY
Written by Brendan Kehoe <brendan@cygnus.com> and Rich Salz <rsalz@uunet.uu.net> for InterNetNews. Converted to POD by Julien Elie.

## SEE ALSO
active(5), control.ctl(5), expire.ctl(5), history(5), incoming.conf(5), inn.conf(5), innfeed.conf(5), moderators(5), newsfeeds(5), nntpsend.ctl(5), passwd.nntp(5), readers.conf(5), storage.conf(5).


innd

title: innd(8)

summary: InterNetNews daemon

text:
# innd(8)

## NAME
innd - InterNetNews daemon

## SYNOPSIS
innd [-adfNrsSu] [-4 address] [-6 address] [-c days] [-H count] [-i count] [-l size] [-m mode] [-n flag] [-o count] [-P port] [-t timeout] [-T count] [-X seconds]

## DESCRIPTION
innd, the InterNetNews daemon, handles all incoming NNTP feeds, coordinates the storage, retransmission, and overview generation for all accepted articles, and manages the active(5) and history(5) databases. It handles incoming connections on the NNTP port, and also creates and listens to a local Unix-domain stream socket in order to receive articles from local processes such as nnrpd(8) and rnews(1).

As the master daemon, innd should generally be started at boot and be always running. It listens to a Unix-domain datagram socket for commands to control its activities, commands that can be sent using ctlinnd(8). The current status of innd can be obtained by running "ctlinnd mode", or for more detailed output, innstat(8).

innd can be in one of three operating modes: running, paused, or throttled. Running is the normal mode; when the server is throttled, it closes connections and rejects new ones. Paused is like a temporary throttle, suspending innd's activities but not causing the server to shut down existing connections. The mode is normally changed via ctlinnd(8), either by various automated processes (such as nightly article expiration) or manually by the news administrator, but innd will also throttle itself if it encounters ENOSPC errors in writing data or an excessive number of I/O errors (among other problems).

innd normally takes care of spawning nnrpd(8) to handle connections from news reading clients, but it can be run on a separate port from nnrpd(8) so that feed connections and news reading connections are handled separately (this can often be faster). Normally, innd listens on port 119, the assigned port for NNTP; if it is desirable to run innd and nnrpd(8) on separate ports, it's recommended that nnrpd(8) be given port 119 (since many news reading clients connect only to that port) and that port 433 be used for innd.

The primary configuration files that control innd's activities are incoming.conf, which specifies what remote sites innd will accept connections from, newsfeeds, which specifies what is to be done with incoming articles besides storing them, and inn.conf, which sets a wide variety of configuration parameters. Some parameters in inn.conf(5) can also be set with command-line flags; for these, the command-line flags take precedence if used.

innd must be run as the news user and news group. It will check for this at startup and fail to start if not run properly. Normally it should be started via rc.news(8) as part of the system boot up process. It relies on the setuid root helper program innbind(8) to listen on a privileged port (119, 433 or 563).

## OPTIONS
For the options below that override inn.conf settings, see inn.conf(5) for the default values if neither the inn.conf setting nor the command-line option is given.

-4 address

Normally, innd binds to all local IP addresses (unless bindaddress is set in inn.conf). If this option is given, it specifies the IP address that INN should bind as. This is only relevant for servers with multiple local IP addresses. The IP address must be in dotted-quad ("nnn.nnn.nnn.nnn") format. If this option is specified, it's the same as setting bindaddress in inn.conf and may cause changes in whether INN binds to an IPv6 address as well. See inn.conf(5) for more details and also the -6 flag for innd.

This option has no effect when systemd socket activation is used.

-6 address

Only applies when INN has been built with IPv6 support. Normally innd binds to all local IP addresses (unless bindaddress6 is set in inn.conf). If this option is given, it specifies the IPv6 address that INN should bind to. The IPv6 address must be in colon-separated RFC 4291 format ("n:n:n:n:n:n:n:n"). If this option is specified, it's the same as setting bindaddress6 in inn.conf and may cause changes in whether INN binds to an IPv4 address as well. See inn.conf(5) for more details and also the -4 flag for innd.

This option has no effect when systemd socket activation is used.

-a

By default, if a host connects to innd but is not listed in incoming.conf, the connection is handed off to nnrpd (or rejected if noreader is set in inn.conf). If -a is given, incoming.conf is ignored and any host can connect and transfer articles. This flag should never be used with an accessible server connected to Usenet; it would open the server up for all sorts of abuse.

-c days

innd normally rejects any article that is older (in days) than the value of artcutoff in inn.conf. This option, if given, overrides the value of that setting. If days is 0, this check is suppressed and innd will accept articles regardless of how old they are. Note that rejected articles are remembered during the number of days specified by the "/remember/" line in expire.ctl(5). You'll have to wait that number of days before being able to inject again an article with the same previously rejected Message-ID.

In case you need re-injecting articles before that amount of time, you'll have to set "/remember/" to 0 in expire.ctl, run the expire process (for instance via news.daily called with the same parameters as in crontab, plus "notdaily") and undo the change in expire.ctl. All previously rejected or removed articles will then not be considered as duplicate if their Message-ID is proposed.

-d, -f

innd normally puts itself into the background, points its standard output and error to log files, and disassociates itself from the terminal. Using -d prevents all of this, resulting in log messages being written to standard output; this is generally useful only for debugging. Using -f prevents the backgrounding and disassociation but still redirects output; it may be useful if you want to monitor innd with a program that would be confused by forks.

-H count, -T count, -X seconds

These flags control the number of connections per seconds seconds that are allowed. This code is meant to protect your server from newsreader clients that make too many connections per minute (and therefore these flags are probably only useful when innd is spawning nnrpd). You probably should not use these options unless you're having problems. The table used for this check is fixed at 128 entries and is used as a ring; the size was chosen to make calculating the index easy and to be fairly sure that it won't run out of space. In practice, it is unlikely that even half the table will be used at any given moment. The -H flag limits the number of times a host is allowed to connect to the server per the time interval given by -X. The default is 2.

The -T flag limits the total number of incoming connections per the time interval given by -X. The maximum value is 128, and the default is 60.

Note that the time interval given by -X is set to 0 by default, that is to say no control is done on the number of connections.

-i count

innd normally allows a maximum number of concurrent NNTP connections given by the value of maxconnections in inn.conf. This option, if given, overrides the value of that setting. If count is 0, this check is suppressed.

-l size

innd normally rejects any article larger than the value of maxartsize in inn.conf. This option, if given, overrides the value of that setting and specifies a maximum article size of size. If size is 0, this check is suppressed.

-m mode

Normally, innd starts in the "running" mode. If this option is given, it specifies what mode innd should start in. mode should begin with one of "g", "p", or "t", and the starting mode will be set to "running", "paused", or "throttled", respectively, based on that initial letter. ("g" is short for "go".)

-N

If this option is given, any filters (Perl or Python) are disabled before innd starts (normally, filters default to being enabled). The filters can be enabled after innd has started with ctlinnd(8).

-n flag

Whether innd allows (and hands off to nnrpd) reader connections while paused or throttled is normally determined by the value of readerswhenstopped in inn.conf. This option, if given, overrides that value. If flag is "n", innd will not allow readers if it is paused or throttled. If flag is "y", readers will be allowed regardless of innd's operating mode.

-o count

This flag limits the number of file descriptors that are available for outgoing file feeds. The default is the number of available file descriptors minus some reserved for internal use (which could potentially starve innd of descriptors to use for accepting new connections). If innd has more file feeds than count, some of them will be buffered and only written out periodically. Normally you never need to use this option, since the number of outgoing feeds is fixed, being the number of file feeds configured in newsfeeds, and is generally small (particularly given that innfeed(8) is now used for most outgoing feeds at large sites).

-P port

The port innd should listen on is normally given by the value of port in inn.conf. This option, if given, overrides that value and specifies the port that innd should bind to.

-r

Instructs innd to renumber the active file after starting, just as if a "ctlinnd renumber" command were sent.

-s

Just check the syntax of the newsfeeds file and exit. innd will exit with a non-zero status if any errors are found; the actual errors will be reported via syslog(3).

-S

Report errors found in incoming.conf via syslog(3) and exit normally. (Yes, this is less useful than it should be.)

-t seconds

Normally, innd will flush any changes to history and the active file after 300 seconds of inactivity. This option changes that timeout to seconds.

-u

The news log (the trace information for every article accepted by innd) is normally buffered. This option changes the log to be unbuffered.

## CONTROL MESSAGES
Arriving articles that have a Control header field are called "control messages". Except for cancel messages, these messages are handled by controlchan(8) via a feed set up in newsfeeds.

(Cancel messages update the history database, so they must be handled internally; the cost of syncing, locking, then unlocking would be too high given the number of cancel messages that are received. Note that if an article is cancelled before it is received by the news server, it will be rejected when it arrives since the history database has been updated; it is useful for rejecting spam before it arrives.)

The distribution of control messages is different than that of standard articles. Control messages are normally filed into the pseudo-newsgroup named "control" regardless of which newsgroup they were actually posted to. If, however, a "control."command newsgroup exists that matches the control command, the control message will be filed into that group instead. For example, a newgroup control message will be filed in "control.newgroup" if that group exists; otherwise, it will be filed in "control".

If you want to specifically feed all control messages to a given site regardless of whether the control messages would affect the newsgroups you're feeding that site, you can put the appropriate control newsgroup in the subscription list. For example, to feed all cancel messages to a given remote site (normally a bad idea), add "control.cancel" to its subscription list. Normally it's best to exclude the control newsgroups from feeds to keep from sending your peers more control messages than they care about. That's why the newsfeeds pattern "!control,!control.*" is as often as not specified (adding this pattern do not prevent control messages which affect the newsgroups fed to a site from being sent to it).

checkgroups, newgroup and rmgroup control messages receive additional special treatment. If one of these control messages is approved and posted to the newsgroup being created or removed (or to the admin group to which the checkgroups is posted), the message will be sent to all sites whose subscription patterns would cause them to receive articles posted to that group. For example, if a newgroup control message for a nonexistent newsgroup "news.admin.meow" is received, it will be sent to any site whose subscription pattern would cause it to receive "news.admin.meow" if that newsgroup existed (such as a pattern of "news.admin.*"). For this reason, it is correct to post newgroup messages to the newsgroup that the control message would create. It is not generally correct to crosspost newgroup messages to some "well-propagated" newsgroup; not only will this not actually improve their propagation to sites that want such control messages, but it will also cause sites that do not want those control messages to receive them. Therefore, assuming that a newgroup control message is sent to the group "news.admin.meow" (specified in the Newsgroups header field body) in order to create the group "news.admin.meow", the sites with the following subscription patterns will receive it:

```
    *,@news.*
    news.*
    news.*,!control,!control.*
    control,control.*
```

As a matter of fact, for the first pattern, "control.newgroup" (or "control") is included in "*". However, the sites with the following subscription patterns will not receive it:

```
    *,@news.*,!control,!control.*
    comp.*,@news.*
```

If a control message is posted to a group whose name ends with the four characters ".ctl", this suffix is stripped off and the control message is propagated as if it were posted to the base group. For example, a cancel message posted to "news.admin.ctl" will be sent to all sites that subscribe to "control.cancel" (or "control" if that newsgroup doesn't exist) or "news.admin". This behavior is present for historical compatibility reasons and should be considered obsolete; support for the ".ctl" suffix may be removed in a future version of INN.

Finally, articles posted to newsgroups beginning with "to." are treated specially. Provided that either that newsgroup exists in the active file or mergetogroups is set in inn.conf, the remainder of the newsgroup is taken to be a site name, as configured in newsfeeds, and the article is sent to sites propagating "to.uunet". If mergetogroups is set, the article will be filed in the group named "to" (which must exist in the active file). For example, with mergetogroups set, an article posted to "to.uunet" will be filed in "to" and sent to the sites propagating "to.uunet".

## PROTOCOL DIFFERENCES
innd implements the NNTP commands defined in RFC 3977 (NNTP), RFC 4643 (NNTP authentication), RFC 4644 (streaming NNTP feeds) and RFC 6048 (NNTP LIST additions) with the following differences:

1.

A batch transfer command, XBATCH byte-count, is provided. This command will read byte-count bytes and store them for later processing by rnews(1) (which must be run separately, probably from cron). See innxbatch(8) and sendxbatches for more details on this extension.

2.

As INN is a mode-switching news server, innd implements a limited subset of the protocol useful for transferring news. The remaining commands are mostly only useful for readers and are implemented by nnrpd(8). Use of the MODE READER command will cause innd to pass the connection to nnrpd.

3.

innd allows a wider syntax for wildmats.

4.

Three commands (IHAVE, CHECK and TAKETHIS) will continue, for interoperability reasons, to return a reject code (respectively 435, 438 and 439) when the command contains a syntax error (which normally leads to 501).

## HEADER MODIFICATIONS
innd modifies as few article headers as possible, although it could be better in this area.

Empty header field bodies and header field bodies that consist of nothing but whitespace are dropped.

The local site's name (as set with the pathhost parameter in inn.conf) and an exclamation point are prepended to the Path header field body, provided the first site name in the Path header field body is different from the local one. In addition, pathalias and pathcluster may be similarly respectively prepended and appended as path identities immediately to the right or the left of pathhost in the Path header field body; see inn.conf(5) for the details.

The Xref header field is removed and a new one created.

innd does not rewrite incorrect header fields. For example, it will not replace an incorrect Lines header field, though it may reject such an article depending on the value of linecountfuzz in inn.conf.

## CANCEL FEEDS
In order to efficiently apply a large number of local cancels (such as from processing NoCeMs or from some other external source), INN supports a special feed mode available only to connections to the local Unix-domain socket (not to connections to any network sockets).

To enter this mode, connect to the Unix-domain socket (pathrun/nntpin) and send the command MODE CANCEL. The response will have code 284. Every subsequent line sent on that connection should consist of a single message-ID. An attempt will be made to cancel that message-ID, and the server will reply 289 for success or 484 for failure. (Failure can occur, for example, if the server is paused or throttled, or the message-ID is corrupt. Failure does not occur if the article to be cancelled does not exist.)

## LOGGING
innd reports all incoming articles in its log file (pathlog/news). This is a text file with a variable number of space-separated fields in one of the following formats:

```
    mon dd hh:mm:ss.mmm + feed <message-id> site ...
    mon dd hh:mm:ss.mmm j feed <message-id> site ...
    mon dd hh:mm:ss.mmm c feed <message-id> Cancelling <message-id>
    mon dd hh:mm:ss.mmm - feed <message-id> reason
    mon dd hh:mm:ss.mmm ? feed <message-id> reason
```

There may also be hostname and/or size fields after the message-ID depending on the settings of nntplinklog and logartsize in inn.conf.

The first three fields are the date and time to millisecond resolution. The fifth field is the site that sent the article (based on the Path header field body) and the sixth field is the article's Message-ID; they will be a question mark if the information is not available.

The fourth field indicates whether the article was accepted or not. If it is a plus sign, then the article was accepted. If it is the letter "j", then the article was accepted, providing all of the newsgroups to which the article was posted were set to status "j" in the active file (or not listed in the active file and wanttrash was set in inn.conf), and then the article was filed into the "junk" newsgroup. In both of these cases, the article has been accepted and the "site ..." field contains the space-separated list of sites to which the article is being sent.

If the fourth field is the letter "c", then a cancel message was accepted before the original article arrived, and a history entry for the cancelled message was created so that innd will reject that message if it arrives later.

If the fourth field is a minus sign, then the article was rejected. The reasons for rejection generated by innd include:

```
    "%s" header too long
    Article exceeds local limit of %s bytes
    Article posted in the future -- "%s"
    Bad "%s" header field
    Can't write history
    Duplicate
    Duplicate "%s" header field
    EOF in headers
    Linecount %s != %s +- %s
    Missing %s header field
    No body
    No colon-space in "%s" header field
    No matching newsgroups in cancel <%s>
    No space
    Space before colon in "%s" header field
    Too old -- "%s"
    Unapproved for "%s"
    Unwanted newsgroup "%s"
    Unwanted distribution "%s"
    Whitespace in "Newsgroups" header field -- "%s"
```

where %s, above, is replaced by more specific information. (The Perl and Python filters, if used, may reject articles with other reasons.)

If the fourth field is the letter "?", the article contains strange strings, such as CR without LF or LF without CR. (These characters should never occur in isolation, only together as CRLF to indicate the end of a line.) This log message is just informational, to give an idea of how widespread such articles are; innd does not reject such articles.

Note that when wanttrash is set to true in inn.conf and an article is received that isn't posted to any valid newsgroups, it will be accepted and logged with two lines, a "j" line and a minus sign line, unless the logtrash parameter is set to false (in which case only the "j" line is written).

innd also makes extensive reports through syslog(3). The first word of the log message will be the name of the site if the entry is site-specific (such as a "connected" message). The first word will be "SERVER" if the message relates to the server itself, such as when a read error occurs.

If the second word is the four letters "cant", then an error is being reported. (The absence of an apostrophe is intentional; it makes it easier to grep from the command line and easier to find error messages in FAQs using a search engine. However, "can't" is also used at a few places.) In this case, the next two words generally name the system call or library routine that failed and the object upon which the action was being performed. The rest of the line may contain other information.

In other cases, the second word attempts to summarize what change has been made, while the rest of the line gives more specific information. The word "internal" generally indicates an internal logic error.

## SIGNALS
innd will catch SIGTERM and SIGHUP and shut down. If -d is used, SIGINT will also be caught and will result in an orderly shutdown.

innd will catch the SIGUSR1 signal and recreate the control channel used by ctlinnd(8).

## BUGS
innd normally attempts to strip IP options from incoming connections, since it uses IP-based authentication and source routing can confuse that. However, this doesn't work on all systems, and it doesn't work at all in the presence of IPv6 support (and is disabled in that case). Hence, if using innd with IPv6 support, make sure that your kernel or router disables source routing.

## HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews.

## SEE ALSO
active(5), ctlinnd(8), history(5), incoming.conf(5), inn.conf(5), innbind(8), innfeed(8), innstat(8), libinn_dbz(3), libinn_inndcomm(3), newsfeeds(5), nnrpd(8), rnews(1), syslog(3).


inndf

title: inndf(8)

text:
# inndf(8)

## NAME
inndf - Report free disk, inodes, and overview information

## SYNOPSIS
inndf [-Fhi] [-f filename] directory [directory ...]

inndf -n

inndf -o

## DESCRIPTION
inndf was originally a replacement for "df | awk" in innwatch.ctl(5) and innstat(8), and now also reports various other usage information about INN's storage that df(1) doesn't understand. inndf doesn't sync, forks less, and is generally less complicated than df(1).

Its default behavior is to report free kilobytes (not disk blocks), or free inodes if -i is used, in the file systems holding the directories given on the command line. (A kilobyte in this case is 1024 bytes.) If only one directory is given, the output will be a simple number; if more than one directory is given, the output will be formatted for human readability.

If enableoverview is set to true in inn.conf, inndf can also be used to get information about the overview database. With the -n option, it reports a count of the total number of overview records stored. With -o, it reports the percentage of space used in the overview database (for those overview methods where this is meaningful data).

## OPTIONS
-f filename

filename should contain a list of directories to use in addition to those given by the arguments, one per line. Blank lines and anything after "#" on any line are ignored.

-F

Like -f except that the filename is pathetc/filesystems and it is not an error if this file doesn't exist. (This option is used primarily by such things as innstat(8), so that the news administrator can add additional file systems to check to pathetc/filesystems without having to modify the script.)

-h

Print a usage message and exit.

-i

Report the number of free inodes rather than the amount of free disk space.

-n

Report the total number of records in the overview database. Note that crossposted articles will have one overview record for each newsgroup they're posted to.

-o

Report the percentage usage of the overview database space. This is only meaningful for overview methods that pre-allocate a certain amount of space rather than grow to accommodate more records. Currently, this flag is only useful for the buffindexed overview method.

## EXAMPLES
Print the free kilobytes in pathspool as a simple number:

```
    inndf <pathspool in inn.conf>
```

Report the free inodes in pathnews and pathspool in a format designed for human readability:

```
    inndf -i <pathnews> <pathspool>
```

The same, but also add in all file systems in pathetc/filesystems:

```
    inndf -i -F <pathnews> <pathspool>
```

Print out the number of overview records and the percentage space used by a buffindexed overview database:

```
    inndf -no
```

## HISTORY
inndf was written by Ian Dickinson <idickins@fore.com>. This manual page was written by Swa Frantzen <Swa.Frantzen@belgium.eu.net>. Thanks also to the following folks for ports, patches, and comments:

```
    Mahesh Ramachandran <rr@eel.ufl.edu>
    Chuck Swiger <chuck@its.com>
    Sang-yong Suh <sysuh@kigam.re.kr>
    Brad Dickey <bdickey@haverford.edu>
    Taso N. Devetzis <devetzis@snet.net>
    Wei-Yeh Lee <weiyeh@columbia.edu>
    Jeff Garzik <jeff.garzik@spinne.com>
```

and to all the other folks I met and worked with during my 10 years as a newsadmin.

Katsuhiro Kondou added the -n and -o options. Russ Allbery added reporting of percentage free disk space. Support for -f and -F was added by Fabien Tassin <fta@sofaraway.org>.

## SEE ALSO
df(1), innwatch.ctl(5), innstat(8).


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.

Used in conjunction with delayer(1), innfeed can send a delayed feed to remote peers or to another local instance of innd, notably to permit the rejection of spam before it actually arrives.

## 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, and -b to specify a different backlog directory. The backlog-* keys in the configuration file parameterize the behaviour of backlogging. 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). Every backlog-rotate-period seconds, innfeed checks whether it is not empty, and, if no foo file exists and foo.input is empty, will then rename foo.output to foo.input and start reading from it.

- A foo file that is never created by innfeed, but if innfeed notices it when checking every backlog-newfile-period seconds, it will rename it to foo.input at the next opportunity (every backlog-rotate-period seconds if foo.input is empty) 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". You are encouraged to use the backlog-directory parameter in the configuration file to declare a specific directory, as otherwise news.daily won't get it and some maintenance operations on the backlog directory won't be performed.

-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. Note that if you use a different name than the default one, and also change the default setting of log-file or pid-file in the configuration file, scanlogs will not be able to rotate the debug log files (their names are searched in innfeed.conf and innfeed-delayed.conf). Other maintenance operations performed by news.daily won't also be done if backlog-directory is changed from its default in a configuration file named differently.

-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). You are encouraged to use the log-file parameter in the configuration file to declare a specific file name, as otherwise scanlogs won't get it and the log file won't be rotated.

-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. You are encouraged to use the pid-file parameter in the configuration file to declare a specific file name, as otherwise scanlogs won't get it and the log file won't be properly flushed before being rotated.

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

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


innreport

title: innreport(8)

summary: Summarize INN log files

text:
# innreport(8)

## NAME
innreport - Summarize INN log files

## SYNOPSIS
innreport -f config-file [-config] [-help] [-v] [-[no]archive] [-[no]casesensitive] [-[no]graph] [-[no]html] [-[no]html-unknown] [-[no]notdaily] [-[no]unknown] [-cycle num-cycle] [-dir http-dir] [-index index-file] [-maxunrec num-lines] [-path pictures-dir] [-separator char] [-webpath pictures-path] log-file [log-file ...]

## DESCRIPTION
innreport is a Perl script that summarizes INN log files, with optional HTML output and graphs. It is normally invoked by scanlogs(8) which includes the output of innreport in daily Usenet reports.

Supported programs are batcher, cnfsstat, controlchan, innd, innfeed, innxbatch, innxmit, nnrpd, nntplink (an external program), overchan, perl-nocem and rnews.

innreport also updates the count of newsgroups not locally carried by the news server, and for which articles have been received, in the unwanted.log log file. If that update should not be done, as it should occur only once a day while parsing daily logs, the -notdaily flag should be given to innreport.

If you want innreport to generate graphs in its HTML reports, you need the Perl graphic library GD.pm.

At least one non-empty log file to parse should be given at the end of the command line invoking innreport.

## OPTIONS
Only one option is mandatory:

-f config-file

Full path to the configuration file. It is usually innreport.conf in pathetc, but there is no default value. This file lists the options to use for the report. The options given in command line when calling innreport take precedence over the ones in the configuration file.

The other options are optional. Prepending "no" in front of boolean options permits unsetting them. For example, use -nograph to remove the feature -graph enables.

-archive or -a

Sets whether HTML pages and graphs should be archived if HTML reports are enabled. When this option is set, which is the default, a date will be added in the file name of each report and each graph. Otherwise, only the latest HTML report is kept.

-casesensitive

Whether to do case sensitive searches in news log files for predetermined patterns. This option is enabled by default.

-config

Prints to standard output configuration information for innreport, and exits.

-cycle or -c num-cycle

Sets how many report files should be kept if HTML reports are enabled and archived. The default is 0, meaning all archives are kept.

-dir or -d http-dir

Sets the directory for web pages if HTML reports are enabled. The default is the value of pathhttp as set in inn.conf.

-graph or -g

If the Perl graphic library GD.pm is installed and HTML reports are enabled, graphs are also generated in PNG if supported by "GD", which is the case in modern versions (GIF will otherwise be generated). The default is to enable graph generation.

-help or -h

Prints to standard output a help message with all the options recognized by innreport, and exits.

-html

Besides the plain text report printed to standard output, innreport generates HTML reports if this option is enabled. This option is disabled by default (that is to say -nohtml is the default).

-html-unknown

Whether to report unknown entries from news log files in HTML reports, when enabled. This option takes by default the same value as the one for text plain reports (as set with the unknown option).

-index or -i

Sets the name of the index web page if HTML reports are enabled. The default is "index.html".

-maxunrec num-lines

How many unrecognized entries from news log files to report, when the -unknown or -html-unknown options are set. The default is 50. Using "-1" means there is no limit.

-notdaily

Whether to defer daily actions for this run of innreport. Some actions should be performed only once a day for a log file (notably unwanted.log). This option is disabled by default, meaning that all actions are always done, as we assume a default setup of running scanlogs daily.

-path or -p pictures-dir

Sets the directory for pictures if HTML reports are enabled, and graphs are wanted. The default is pathhttp/pics. If both -dir and -webpath are used, and -path isn't, the directory used for pictures defaults to http-dir as set with -dir/pictures-path as set with -webpath.

-separator or -s char

Sets the separator between hours, minutes and seconds in file names if HTML reports are enabled and archived. The default is "." as ":" may not be properly read by all web browsers. Be careful not to use "/" as a separator, and to use only a valid file name character.

-unknown

Whether to report unknown entries from news log files in plain text reports. This option is enabled by default.

-v

Prints to standard output the version number of innreport, and exits.

-webpath or -w pictures-path

Sets the web path for pictures in HTML pages if HTML reports are enabled, and graphs are wanted. The default is "pics". It can be a relative path or an absolute path. If an absolute path is used, you have to set -path appropriately; otherwise it will not be computed right.

## HISTORY
Written by Fabien Tassin <fta@sofaraway.org> for InterNetNews. Rewritten into POD by Julien Elie.

## SEE ALSO
innreport.conf(5), news.daily(8), newslog(5), scanlogs(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 is notably run by news.daily, which integrates its output in daily Usenet reports.

innstat displays the following information:

- the operating mode of the server, as returned by "ctlinnd mode";

- the disk usage of several directories: patharticles, pathdb, pathetc, pathincoming, pathlog, pathoutgoing, pathoverview, and pathtmp. If used, the disk usage of the patharchive and pathhttp directories are also reported;

- the overview buffer usage, if using the buffindexed overview;

- the size of all batch files in pathoutgoing;

- the size of the errlog, news, news.crit, news.err, and news.notice log files in pathlog;

- the size of all lock files in pathrun;

- the current open connections from remote servers to innd.

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

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


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:

incoming.conf

- Rename nolist and noresendid to respectively list and resendid. Invert the related boolean values (since INN 2.7).

- Comment removed comment and email parameters (since INN 2.7).

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

- Remove the refusecybercancels and verifycancels parameters (since INN 2.7).

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

inn-secrets.conf

•

Create a non-world-readable inn-secrets.conf file in pathetc, if not already existing (new in INN 2.7).

newsfeeds

- Replace the use of startinnfeed with the appropriate direct invocation of innfeed or imapfeed (startinnfeed was removed in INN 2.5).

- Replace the use of filechan with buffchan in unbuffered mode (filechan was removed in INN 2.7).

readers.conf

•

Rename require_ssl to require_encryption (since INN 2.7).

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.

## SEE ALSO
incoming.conf(5), inn.conf(5), inn-secrets.conf(5), newsfeeds(5), readers.conf(5).


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 and stopped by rc.news when doinnwatch is set to true in inn.conf. Every innwatchsleeptime seconds, as set in inn.conf as well as other parameters tuning its behaviour, innwatch 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.

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


innxbatch

title: innxbatch(8)

text:
# innxbatch(8)

## NAME
innxbatch, sendxbatches - Send xbatched Usenet articles to a remote NNTP server

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

innxbatch -i [-Dv] [-t timeout] [-T timeout] host

sendxbatches sitename host file [file ...]

## DESCRIPTION
innxbatch connects to port 119 of the NNTP server at the specified host, and sends it the specified xbatch files, using the XBATCH extension to the NNTP protocol. These files are specified either from the command line or from standard input if i is used.

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.

If authentication credentials are present for the remote server in the passwd.nntp file in pathetc, then innxbatch will use them to authenticate.

innxbatch does not use itself any file locking. At worst, a batch could be transmitted twice in parallel by two independent invocations of innxbatch. To prevent this, it should be invoked by a script run out of cron(8) that uses shlock(1) to lock the host name, followed by a "ctlinnd flush" command to flush the batch file. sendxbatches is such a wrapper around innxbatch. It will ensure only one instance is run, flush sitename (as used in the newsfeeds entry) and send to host the files given as arguments.

As the XBATCH extension is not a standardized NNTP command, some news servers do not recognize it. Moreover, to accept batches from remote peers via XBATCH, you have to explicitly enable the capability with the xbatch setting in incoming.conf. Instead of using innxbatch, you may consider innfeed, or if that is not possible, nntpsend.

## OPTIONS
-D

Prints debugging information on standard error. This will show the protocol transactions between innxbatch and the NNTP server on the remote host.

-i

Reads batch file names from standard input. For each successfully transmitted batch, an "OK" is printed on stdout to indicate that another file name is expected.

-t timeout

Specifies a timeout in seconds on how long to try to make the connection. Otherwise, innxbatch normally blocks until the connection is made.

-T timeout

Specifies the total amount of time in seconds that should be allowed for article transfers. The default is to wait until an I/O error occurs, or all the articles have been transferred. If this 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 this flag is used, they will also be printed on the standard output.

## EXAMPLES
A sample newsfeeds entry to produce appropriate xbatch files is:

```
    nase\
        :*\
        :Tc,Wnb\
        :<pathbin>/batcher -p "(<$COMPRESS in <pathlib>/innshellvars>\
            > <pathoutgoing>/nase.\$\$)" nase.do.main
```

A sample script to invoke innxbatch(8) is:

```
    #! /bin/sh
    #  Send xbatches for a site, wrapped around innxbatch.
    if [ $# -lt 3 ]
    then
        echo "usage: $0 <sitename> <hostname> <xbatch file name> ..."
        exit 1
    fi
    . <pathlib>/innshellvars
    site="$1"; host="$2"; shift; shift
    ctlinnd flush "$site" \
    && sleep 5 \
    && exec ${NEWSBIN}/innxbatch -v -D "$host" $*
```

You can use sendxbatches, already shipped with INN, doing locking. An example of call is:

```
    sendxbatches nase remote.news.server.name <pathoutgoing>/nase*
```

## HISTORY
Written by Stefan Petri <petri@ibr.cs.tu-bs.de>, modelled after innxmit and the XBATCH patch for the NNTP reference implementation. Examples from Karsten Leipold <poldi@dfn.de>. Rewritten into POD by Julien Elie.

## SEE ALSO
ctlinnd(8), incoming.conf(5), innxmit(8), newsfeeds(5), nntpsend(8), passwd.nntp(5), 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 authentication credentials are present for the remote server in that file) 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 made to avoid sending articles already on the remote server. After a certain number of articles accepted in a row, innxmit will no longer send these queries, but will switch back to sending them upon receiving a reject (which may be for another reason than a duplicate, like for instance an unwanted newsgroup). The -c flag will, if streaming mode is supported, result in always 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 field 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.

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