nnrpd - NNTP server for reader clients
nnrpd [
-BDfnoSt] [
-4 address] [
-6
address] [
-b address] [
-c configfile]
[
-i initial] [
-I instance] [
-p
port] [
-P prefork] [
-r reason] [
-s
padding]
nnrpd is an NNTP server for newsreaders. It accepts commands on its
standard input and responds on its standard output. It is normally invoked by
innd(8) with those descriptors attached to a remote client connection.
nnrpd also supports running as a standalone daemon.
Unlike
innd(8),
nnrpd supports all NNTP commands for user-oriented
reading and posting.
nnrpd uses the
readers.conf file to control
who is authorized to access the Usenet database.
On exit,
nnrpd will report usage statistics through
syslog(3).
nnrpd is run from
innd (the default) or from
inetd(8),
xinetd(8), or some equivalent. As often as not, it is also run as a
daemon, with the
-D option, to provide TLS support on a dedicated port.
nnrpd only reads config files (
readers.conf,
inn.conf and
inn-secrets.conf) when it is spawned. You can therefore never change
the behaviour of a client that's already connected. As a new
nnrpd
process is spawned for every connection, any changes to these configuration
files will be immediately effective for all new connections. There's only one
exception: when
nnrpd is run as a daemon with the
-D option, any
configuration changes in
inn.conf won't take effect until
nnrpd
is restarted.
The
inn.conf setting
nnrpdflags can be used to pass any of the
options below to instances of
nnrpd that are spawned directly from
innd. Many options only make sense when
-D is used, so these
options should not be used with
nnrpdflags. See also the discussion of
nnrpdflags in
inn.conf(5).
When
nnrpdloadlimit in
inn.conf is not 0, it will also reject
connections if the load average is greater than that value (typically 16).
nnrpd can also prevent high-volume posters from abusing your resources.
See the discussion of exponential backoff in
inn.conf(5).
nnrpd injects articles into the local server running
innd through
a UNIX domain socket, or an INET domain socket if not supported. If another
server should be used for injection, you can set it with the
nnrpdposthost parameter in
inn.conf. In case authentication
credentials are requested during the injection,
nnrpd will use the
passwd.nntp file in
pathetc.
-
-4 address
- The -4 parameter instructs nnrpd to bind to
the specified IPv4 address when started as a standalone daemon using the
-D flag. This has to be a valid IPv4 address belonging to an
interface of the local host. It can also be 0.0.0.0, saying to bind to all
addresses (this is the default).
-
-6 address
- The -6 parameter instructs nnrpd to bind to
the specified IPv6 address when started as a standalone daemon using the
-D flag. This has to be a valid IPv6 address belonging to an
interface of the local host. It can also be "::0", saying to
bind to all IPv6 addresses.
By default, nnrpd in daemon mode listens to both IPv4 and IPv6
addresses. With this option, it will listen only to the specified IPv6
addresses. On some systems however, a value of "::0" will cause
it to listen to all IPv4 addresses as well.
-
-b address
- Similar to the -4 flag. -b is kept for
backwards compatibility.
- -B
- If specified, nnrpd will report login attempts to
blacklistd(8) for automatic blocking after a number of failed
attempts. To use this flag, the blacklist library must have been found at
configure time, or --with-blacklist specified at configure time.
For more information, see "BLACKLISTD SUPPORT" below.
-
-c configfile
- By default, nnrpd reads the readers.conf
configuration file to determine how to authenticate connections. The
-c flag specifies an alternate file for this purpose. If the file
name isn't fully qualified, it is taken to be relative to pathetc
in inn.conf. (This is useful to have several instances of
nnrpd running on different ports or IP addresses with different
settings.)
- -D
- If specified, this parameter causes nnrpd to operate
as a daemon. That is, it detaches itself and runs in the background,
forking a process for every connection. By default, nnrpd listens
on the NNTP port (119), so either innd(8) has to be started on
another port or the -p parameter used. Note that with this
parameter, nnrpd continues running until killed. This means that it
reads inn.conf once on startup and never again until restarted.
nnrpd should therefore be restarted if inn.conf is changed.
When started in daemon mode, nnrpd will write its PID into a file in
the pathrun directory. The file will be named nnrpd.pid if
nnrpd listens on port 119 (default), or nnrpd-%d.pid, where
%d is replaced with the port that nnrpd is configured to listen on
( -p option is given and its argument is not 119).
You may also want to use -s when running nnrpd as a
daemon.
- -f
- If specified, nnrpd does not detach itself and runs
in the foreground when started as a standalone daemon using the -D
flag.
-
-i initial
- Specify an initial command to nnrpd. When used,
initial is taken as if it were the first command received by
nnrpd. After having responded, nnrpd will close the
connection.
-
-I instance
- If specified, instance is used as an additional
static portion within Message-IDs generated by nnrpd, when
virtualhost is set in access groups in readers.conf;
typically this option would be used where a cluster of machines exist with
the same virtual hostname and must be disambiguated during posts.
- -n
- The -n flag turns off resolution of IP addresses to
names. If you only use IP-based restrictions in readers.conf and
can handle IP addresses in your logs, using this flag may result in some
additional speed.
- -o
- The -o flag causes all articles to be spooled
instead of sending them to innd(8). rnews with the -U
flag should be invoked from cron on a regular basis to take care of these
articles. This flag is useful if innd is accepting articles and
nnrpd is started standalone or using inetd(8).
-
-p port
- The -p parameter instructs nnrpd to listen on
port when started as a standalone daemon using the -D
flag.
-
-P prefork
- The -P parameter instructs nnrpd to prefork
prefork children awaiting connections when started as a standalone
daemon using the -D flag.
-
-r reason
- If the -r flag is used, then nnrpd will
reject the incoming connection giving reason as the text. This flag
is used by innd(8) when it is paused or throttled. reason
should be encoded in UTF-8.
-
-s padding
- As each command is received from a client, nnrpd
tries to change its "argv" array containing the process title so
that commands like ps(1) will print out the hostname of the
connected client and the command being executed. To get a full display,
the -s flag may be used with a long string as its argument, which
will be overwritten when nnrpd changes its title.
When innd spawns nnrpd, this flag is used with an argument
made of 48 spaces.
- -S
- If specified, nnrpd will start a negotiation for a
TLS session as soon as connected. To use this flag, the OpenSSL SSL and
crypto libraries must have been found at configure time, or
--with-openssl specified at configure time. For more information on
running nnrpd with TLS support, see "TLS SUPPORT".
- -t
- If the -t flag is used, then all client commands and
initial responses will be traced by reporting them in syslog. This flag is
set by innd(8) under the control of the ctlinnd(8)
"trace" command, and is toggled upon receipt of a SIGHUP; see
signal(2).
If INN is built with
--with-openssl or if the OpenSSL SSL and crypto
libraries are found at configure time,
nnrpd will support news reading
over TLS (also known as SSL). For clients that use the STARTTLS command, no
special configuration is needed beyond creating a TLS/SSL certificate for the
server. You should do this in exactly the same way that you would generate a
certificate for a web server.
If you're happy with a self-signed certificate (which will generate warnings
with some news reader clients), you can create and install one in the default
path by running "make cert" after "make install" when
installing INN, or by running the following commands:
umask 077
openssl req -new -x509 -nodes -out <pathetc>/cert.pem \
-days 366 -keyout <pathetc>/key.pem
chown news:news <pathetc>/cert.pem
chmod 640 <pathetc>/cert.pem
chown news:news <pathetc>/key.pem
chmod 600 <pathetc>/key.pem
Replace the paths with something appropriate to your INN installation. This will
create a self-signed certificate that will expire in a year. The
openssl program will ask you a variety of questions about your
organization. Enter the fully qualified domain name of your news service
(either the server canonical name or a dedicated alias for the news service)
as the name the certificate is for.
You then have to set these
inn.conf parameters with the right paths:
tlscapath: <pathetc>
tlscertfile: <pathetc>/cert.pem
tlskeyfile: <pathetc>/key.pem
If you want to use a complete certificate chain, you can directly put it in
tlscertfile (like Apache's
SSLCertificateFile directive).
Alternately, you can put a single certificate in
tlscertfile and use
tlscafile for additional certificates needed to complete the chain,
like a separate authority root certificate.
More concretely, when using Let's Encrypt certificates, Certbot's files
can be installed as follows:
tlscapath: /etc/letsencrypt/live/news.server.com
tlscertfile: /etc/letsencrypt/live/news.server.com/fullchain.pem
tlskeyfile: /etc/letsencrypt/live/news.server.com/privkey.pem
or:
tlscapath: /etc/letsencrypt/live/news.server.com
tlscafile: /etc/letsencrypt/live/news.server.com/chain.pem
tlscertfile: /etc/letsencrypt/live/news.server.com/cert.pem
tlskeyfile: /etc/letsencrypt/live/news.server.com/privkey.pem
Make sure that the permission rights are properly set so that the news user or
the news group can read these directories and files (typically, he should
access
/etc/letsencrypt/live/news.server.com and
/etc/letsencrypt/archive/news.server.com where the real keys are
located, and the private key should not be world-readable).
There are two common ways for a news client to negotiate a TLS connection:
either via the use of a dedicated port (usually 563) on which TLS is
immediately negotiated upon connection, or via the now discouraged way (per
RFC 8143) to use the STARTTLS command on the usual NNTP port (119) to
dynamically upgrade from unencrypted to TLS-protected traffic during an NNTP
session.
innd does not, however, know how to listen for connections to
that separate port (563). You will therefore need to arrange for
nnrpd
to listen on that port through some other means. This can be done with the
-D flag along with "-p 563" and put into your init scripts:
su news -s /bin/sh -c '<pathbin>/nnrpd -D -p 563 -S'
but the easiest way is probably to add a line like:
nntps stream tcp nowait news <pathbin>/nnrpd nnrpd -S
to
/etc/inetd.conf or the equivalent on your system and let
inetd
run
nnrpd. (Change the path to
nnrpd to match your
installation.) You may need to replace "nntps" with 563 if
"nntps" isn't defined in
/etc/services on your system. You
may also want to use the lowercase
-s flag with a long string as its
argument to see more information about incoming connections in
ps(1)
output.
Optionally, you may set the
tlsciphers,
tlsciphers13,
tlscompression,
tlseccurve,
tlspreferserverciphers, and
tlsprotocols parameters in
inn.conf to fine-tune the behaviour
of the TLS/SSL negotiation whenever a new attack on the TLS protocol or some
supported cipher suite is discovered.
blacklistd(8) is a FreeBSD/NetBSD daemon for preventing brute force
attacks by blocking attackers after a number of failed login attempts. When
nnrpd is built with blacklistd support, it will report login attempts
to the blacklistd daemon for potential blocking.
Adding the configuration below to
/etc/blacklistd.conf under the
"[local]" section, assuming
nnrpd is listening on port 563,
would lead to attackers being blocked for 10 minutes after 5 failed login
attempts.
# adr/mask:port type proto owner name nfail disable
563 stream * * * 5 10m
See the
blacklistd(8) documentation for more information.
nnrpd implements the NNTP commands defined in RFC 3977 (NNTP),
RFC 4642 updated by RFC 8143 (TLS/NNTP), RFC 4643 (NNTP
authentication), RFC 6048 (NNTP LIST additions) and RFC 8054
(NNTP compression) with the following differences:
- 1.
- The XGTITLE [wildmat] command is provided. This
extension is used by ANU-News and documented in RFC 2980. It
returns a 282 reply code, followed by a one-line description of all
newsgroups that match the pattern. The default is the current group.
Note that LIST NEWSGROUPS should be used instead of XGTITLE.
- 2.
- The XHDR header [message-ID|range]
command is implemented. It returns a 221 reply code, followed by specific
header fields for the specified range; the default is to return the data
for the current article. See RFC 2980.
Note that HDR should be used instead of XHDR.
- 3.
- The XOVER [range] command is provided. It returns a
224 reply code, followed by the overview data for the specified range; the
default is to return the data for the current article. See
RFC 2980.
Note that OVER should be used instead of XOVER.
- 4.
- A new command, XPAT header
message-ID|range pattern [ pattern ...], is
provided. The first argument is the case-insensitive name of the header
field to be searched. The second argument is either an article range or a
single message-ID, as specified in RFC 2980. The third argument is
a uwildmat-style pattern; if there are additional arguments, they
are joined together separated by a single space to form the complete
pattern. This command is similar to the XHDR command. It returns a 221
response code, followed by the text response of all article numbers that
match the pattern.
- 5.
- A newsgroup name is case-sensitive for nnrpd.
- 6.
- If IHAVE has been advertised, it will not necessarily be
advertised for the entire session (contrary to section 3.4.1 of
RFC 3977). nnrpd only advertises the IHAVE capability when
it is really available.
- 7.
-
nnrpd allows a wider syntax for wildmats and ranges
(especially "-" and "- article-number").
- 8.
- When keyword generation is used, an experimental feature
enabled with the keywords parameter in inn.conf,
"Keywords:full" is advertised in LIST OVERVIEW.FMT even though
overview information is computed and does not necessarily come from
Keywords header fields.
Written by Rich $alz <
[email protected]> for InterNetNews. Overview
support added by Rob Robertston <
[email protected]> and Rich in
January, 1993. Exponential backoff (for posting) added by Dave Hayes in
Febuary 1998.
blacklistd(8),
ctlinnd(8),
innd(8),
inn.conf(5),
inn-secrets.conf(5),
libinn_uwildmat(3),
nnrpd.track(5),
passwd.nntp(5),
readers.conf(5),
signal(2).