Ubuntu Manpage: nnrpd - NNTP server for reader clients

Provided by: inn2_2.7.1~20230131-1build1_amd64

NAME

       nnrpd - NNTP server for reader clients

SYNOPSIS

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

DESCRIPTION

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

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

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

nnrpd only reads config files (both readers.conf and inn.conf) when it is spawned. You
can therefore never change the behavior of a client that's already connected. If nnrpd is
run from innd (the default) or from inetd(8), xinetd(8), or some equivalent, a new nnrpd
process is spawned for every connection and therefore any changes to configuration files
will be immediately effective for all new connections. If you are instead running nnrpd
with the -D option, any configuration changes won't take effect until nnrpd is restarted.

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

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

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

OPTIONS

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

-6 address
The -6 parameter instructs nnrpd to bind to the specified IPv6 address when started as
a standalone daemon using the -D flag. This has to be a valid IPv6 address belonging
to an interface of the local host. It can also be "::0", saying to bind to all IPv6
addresses.

By default, nnrpd in daemon mode listens to both IPv4 and IPv6 addresses. With this
option, it will listen only to the specified IPv6 addresses. On some systems however,
a value of "::0" will cause it to listen to all IPv4 addresses as well.

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

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

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

-D If specified, this parameter causes nnrpd to operate as a daemon. That is, it
detaches itself and runs in the background, forking a process for every connection.
By default, nnrpd listens on the NNTP port (119), so either innd(8) has to be started
on another port or the -p parameter used. Note that with this parameter, nnrpd
continues running until killed. This means that it reads inn.conf once on startup and
never again until restarted. nnrpd should therefore be restarted if inn.conf is
changed.

When started in daemon mode, nnrpd will write its PID into a file in the pathrun
directory. The file will be named nnrpd.pid if nnrpd listens on port 119 (default),
or nnrpd-%d.pid, where %d is replaced with the port that nnrpd is configured to listen
on (-p option is given and its argument is not 119).

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

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

-I instance
If specified, instance is used as an additional static portion within Message-IDs
generated by nnrpd, 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(8) is accepting articles and nnrpd is
started standalone or using inetd(8).

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

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

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

-s padding
As each command is received, nnrpd tries to change its "argv" array so that ps(1) will
print out the command being executed. To get a full display, the -s flag may be used
with a long string as its argument, which will be overwritten when the program changes
its title.

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

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

TLS SUPPORT

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

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

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

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

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

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

       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.

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

BLACKLISTD SUPPORT

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

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

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

       See the blacklistd(8) documentation for more information.

PROTOCOL DIFFERENCES

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

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

Note that LIST NEWSGROUPS should be used instead of XGTITLE.

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

Note that HDR should be used instead of XHDR.

3. The XOVER [range] command is provided. It returns a 224 reply code, followed by the
overview data for the specified range; the default is to return the data for the
current article. See RFC 2980.

Note that OVER should be used instead of XOVER.

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

5. A newsgroup name is case-sensitive for nnrpd.

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

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

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

HISTORY

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