incoming.conf - Configuration of incoming news feeds
The incoming.conf file configures from which remote peers
innd accepts NNTP feeds.
A common entry to allow
"news.server.com" as an incoming peer
is:
peer news.server.com {
hostname: "news.server.com"
}
The port used for incoming feeds is the one innd is
listening on (usually port 119 or 433).
Peer entries are read in the order they appear in the
configuration file. The first peer entry with a hostname value
matching the incoming connection will be used to grant access to the remote
peer. Subsequent entries will be discarded.
After any changes, run
"inncheck" to perform basic syntax checks,
and reload this configuration file with the following command:
ctlinnd reload incoming.conf 'new peer'
The file pathetc/incoming.conf consists of three types of
entries: key/value, peer and group. Comments are from the hash character
"#" to the end of the line. Blank lines
are ignored. All key/value entries within each type must not be duplicated.
Key/value entries are a keyword immediately followed by a colon, at least
one blank and a value. For example:
max-connections: 10
A legal key does not contains blanks, colons, nor
"#". There are three different types of
values: integers, booleans, and strings. Integers are as to be expected. A
boolean value is either "true",
"yes",
"on",
"false",
"no" or
"off" (case is not significant). A string
value is any other sequence of characters. If the string needs to contain
whitespace, then it must be quoted with double quotes.
Peer entries look like:
peer <name> {
# body
}
The word "peer" is required.
<name> is a label for this peer. It is any string valid as a key. The
body of a peer entry contains some number of key/value entries.
Group entries look like:
group <name> {
# body
}
The word "group" is required.
<name> is any string valid as a key. The body of a group entry
contains any number of the three types of entries. So key/value pairs can be
defined inside a group, and peers can be nested inside a group, and other
groups can be nested inside a group. Key/value entries that are defined
outside of all peer and group entries are said to be at global scope. Global
key/value entries act as defaults for peers. When innd looks for a
specific value in a peer entry (for example, the maximum number of
connections to allow), if the value is not defined in the peer entry, then
the enclosing groups are examined for the entry (starting at the closest
enclosing group). If there are no enclosing groups, or the enclosing groups
don't define the key/value, then the value at global scope is used. A small
example could be:
# Global value applied to all peers that have no value of their own.
max-connections: 5
# A peer definition.
peer uunet {
hostname: usenet1.uu.net
}
peer vixie {
hostname: gw.home.vix.com
max-connections: 10 # Override global value.
}
# A group of two peers which can open more connections than normal.
group fast-sites {
max-connections: 15
# Another peer. The max-connections value from the
# fast-sites group scope is used.
peer data.ramona.vix.com {
hostname: data.ramona.vix.com
}
peer bb.home.vix.com {
hostname: bb.home.vix.com
max-connections: 20 # He can really cook.
}
}
Given the above configuration file, the defined peers would have
the following values for the max-connections key.
uunet 5
vixie 10
data.ramona.vix.com 15
bb.home.vix.com 20
The following keys are allowed:
- hold-time
- This key requires a positive integer value. It defines the hold time
before closing, if the connection is over max-connections. A value
of zero specifies immediate close. The default is
0.
- hostname
- This key requires a string value. It is a list of hostnames separated by a
comma. A hostname is either a fully qualified domain name that resolves to
the IPv4 or IPv6 address of the peer, or the dotted-quad IP address of the
peer for IPv4, or the colon-separated IP address of the peer for IPv6. If
this key is not present in a peer block, the hostname defaults to the
label of the peer.
- identd
- This key requires a string value. It is used if you wish to require a
peer's user name retrieved through identd(8) match the specified
string. Note that currently innd does not implement any timeout in
identd callbacks, so enabling this option may cause innd to
hang if the remote peer does not respond to ident callbacks in a
reasonable timeframe. The default is an empty string, that is to say no
ident daemon.
- ignore
- This key requires a boolean value. Setting this entry to true causes
innd to answer negatively to proposals from the remote peer to send
you articles. The default is false.
More technically, if ignore is true, innd will
refuse every Message-ID proposed to be sent via CHECK or IHAVE by this
peer, thus behaving as though it already has the article. A complete
article sent by this peer via TAKETHIS (because it does not first query
with CHECK, or it does not take into account the refusal response code
from a previous CHECK) will still be accepted.
- list
- This key requires a boolean value. It defines whether a peer is allowed to
issue LIST commands. The default is true, that is to say it can.
- max-connections
- This key requires a positive integer value. It defines the maximum number
of connections allowed. A value of zero specifies an unlimited number of
maximum connections ("unlimited" or
"none" can be used as synonyms). The
default is 0.
- password
- This key requires a string value. It is used if you wish to require a peer
to supply a password via AUTHINFO USER/PASS. The default is an empty
string, that it to say no password is expected.
Note that innd will accept any username provided by the
remote peer as long as the password corresponds. (As the username is
mandatory in the authentication protocol, innd expects one but
does nothing with it.)
- patterns
- This key requires a string value. It is a list of
newsfeeds(5)-style list of newsgroups which are to be accepted from
this host. The default is the string
"*", that is to say all groups are
accepted.
- resendid
- This key requires a boolean value. When set to true, innd asks the
remote peer to retry later to send the proposed article (which happens
when another peer has already offered to send it, but has not yet), using
431 (response to CHECK, in streaming mode) or
436 (response to IHAVE in non-streaming mode)
codes. When set to false, innd does not ask any new attempt (which
will lead to the loss of an article in case the other peer does not send
it), using 438 (response to CHECK) or
435 (response to IHAVE) codes. The deferral
feature can be useful for peers that resend messages right away, as
innfeed does. The default is true: the deferral feature is used so
that the peer receives 431 and
436 codes, and therefore resends the article
later.
- skip
- This key requires a boolean value. Setting this entry causes this peer to
be skipped. The default is false.
- streaming
- This key requires a boolean value. It defines whether streaming commands
(CHECK and TAKETHIS) are allowed from this peer. The default is true.
- xbatch
- This key requires a boolean value. It defines whether a peer is allowed to
issue XBATCH commands. The default is false, that is to say it
cannot.
Written by Fabien Tassin <fta@sofaraway.org> for
InterNetNews. Converted to POD by Julien Elie.
inn.conf(5), innd(8), libinn_uwildmat(3),
newsfeeds(5).