Be sure to read the "RKT couplings" below for additional information and updates to this entry.
| Subject: (4.7) Make sure that "feeders" can connect. |
|---|
"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 INN FAQ #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. ------------------------------ [Last Changed: $Date: 1997/08/26 01:26:21 $ $Revision: 2.19 $] [Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.] |
