"feeders" are listed in hosts.nntp.  "readers" are listed in
nnrp.access.  This section deals with "feeders" and hosts.nntp.

When a machine connects to the NNTP port of nntphost, it connects to
the innd process.  innd knows the internet address of the machine that
is making this connection, and sees if it matches the internet
addresses many of the machines listed in the hosts.nntp file.

If the machine is not listed in hosts.nntp, it is assumed that this
machine is not a "feeder" and forks off a nnrpd to handle this
connection as a "reader".  If you didn't know that, you didn't read
enough of the INN installation documentation.  Go back and read it
now.

Read the man page hosts.nntp to get a complete understanding of what's
going on.  nnrpd uses its own authentication scheme, which is
described in the next section.

Since I know you didn't read that man page, I'll give you one more
chance to read it now.

Let's configure hosts.nntp.  Just enter the names of all the machines
that feed you:

feeder1.do.main:
feeder2.do.main:

I don't use passwords yet.  If you do, add them after the ":". (See also #4.14)

Now let's test to see if the feeder can connect properly.

Log into to the feeder and "telnet nntphost 119".

If you can't log into a feeder, configure your own machine as a feeder
(i.e. feeder to itself) for testing purposes.  Once you can see that
INN is treating that machine as a feeder you can replace the machine's
name with the name of a real feed.

If you are given an error message and booted out, check the error
message to see what's wrong.  Maybe the machine is running maintenance
at the time and you have to try again later.  Maybe the machine doesn't
recognize you at all and you have to edit "hosts.nntp" (and don't
forget the "ctlinnd reload hosts.nntp" command!).

Run "inncheck" to tell you if you have made any obvious mistakes.

If your "history" file or other files have the wrong ownership or
protections INN will mention the offending file in the error message.
Another common mistake is that people try to use wildcards in
hosts.nntp (which is not supported).  Remember, there are very few
machines that you consider to be "feeders", so you don't want to use a
wildcard.

To test a "feeder":  If "feeder1" can send an "ihave" command and get a
"335" as a response, you know that "nntphost" is permitting "feeder1"
to transfer news as a "feeder".  "ihave" requires an operand.  I
usually type "ihave <1@test>" and press RETURN.  "<1@test>" is a
Message-ID that I know doesn't exist.  If I get "500 What?" I know that
innd assumed that I'm a "reader" (so I have to edit my "hosts.nntp"
file and add this client).  If I get "335" and then a blank prompt,
then INN is expecting to be fed an article.  I usually just "^]"
(control-]) and "quit" out; I know that it was willing to accept the
article.  If I get some other error message, it usually gives me enough
information to debug the problem.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Name:

E-mail:

Show my email publicly

Type the code shown:

Public Comment:  (50-4000 characters)

Archived related questions and answers