rkt logo

INN FAQ Part 4

Be sure to read the "RKT couplings" below for additional information and updates to this entry.

Subject: (4.8) Make sure that "readers" can connect.

As I wrote before, if a connection comes from a machine that isn't
listed in the hosts.nntp file, it is assumed to be a "reader". A
"feeder" can also issue the "mode reader" command to become a
"reader". If you have "telnet"'ed in as a "feeder", try issuing this

Note: If a site is going to feed *and* read, you'll have to link
readers with innd's client library. The reason for this is that the
clients must tell innd that they want to read using the "mode reader"
command. The library does that automagically. It is rare that you
have a machine that is a reader and a feeder (since people will want to
read on their local machine, not yours.) News readers are now
being packaged as "INN ready" so this will be less and less of a

Once the connection has been handed off to nnrpd, nnrpd checks to make
sure you are authorized. It does that by reading the nnrp.access

There is a problem with what you enter in that file. Namely, I might
call the client machine "client", but that doesn't matter. What
matters is what "nntphost" thinks "client" is called. Maybe "nntphost"
thinks its name is "client.do.main" or even "". It
doesn't matter what *you* call "client", permissions in the nnrp.access
file have to be specified based on what "nntphost" calls "client".
Technically, nnrpd uses gethostbyaddr() to reverse-lookup the name.
gethostbyaddr() uses DNS or, if you are on a brain-dead Sun running
Sun's NIS/DNS hack, it uses NIS, or DNS, or whatever the hell Sun was
thinking when they created that cruft.

To find out what "nntphost" thinks your machine is called, do the
following: Telnet from "client" to "nntphost" and execute the "finger"
command (just "finger" alone on the command line). The last column is
what "nntphost" thinks your machine is called.

If you don't have an account on both machines things are more
difficult, consult your NIS or DNS expert to tell you what the answer
would be.

There is one exception to this technique. If you are using SunOS and
braindead NIS you get just the machine name (like "milk") instead of
the FQDN (like "milk.warren.mentorg.com") then you must tack on a
period then the domain of the machine.

So, with this knowledge (what your nntphost thinks client's name is)
and a copy of the man page, edit nnrp.access and add "nntphost"'s name
for "client" to the file. Unlike hosts.nntp, nnrp.access can have
wildcards (for example, "*.sjc.mentorg.com"). You'll want to include
wildcards for all the domains that should be allowed to read/post.

Here are some decent examples from my nnrp.access file:

-------------------------------------- Tom's nnrp.access file START
## Default is no access, no way to authentication, and no groups.
*:: -no- : -no- :!*
*.warren.mentorg.com:Read Post:::*
-------------------------------------- Tom's nnrp.access file END

The second field of "nnrp.access" is case sensitive. "read post" does
not mean the same as "Read Post". If you know this already it's
because you read the man page.

Note: nnrpd will append the domain to a name that is not a FQDN.
There is no need to try to find a wildcard that will match non-FQDN
names (i.e. machines in your local NIS cluster). Previously this FAQ
had reported that "*[^.]*" would match these short names but that was
wrong (the wildcard matches everything, oi!). nnrpd turns non-FQDN's
into FQDNs.

After you change "nnrp.access" you don't have do "ctlinnd reload" since
the file is read by each nnrpd as they start up.

Now "nntphost" should be letting "client" read. Let's test this out:

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

To test a "reader": Give the "mode reader" command and see how it
it goes. If it doesn't give an error, then nnrp.access is letting you
through. To read an article (or just get the header) type "head
<2@test>" and press RETURN. Again, "<2@test>" is a message-id that I
know doesn't exist. If you are allowed to read at all, it will tell
you that it can't find that article. You should try the command with an
message-id that you know exists and make sure you see the article's

If reading works you can skip to the next section. The rest of this
section helps you debug reading problems.

If "mode reader" gives an error (and rudely disconnects you) then you
have a typo in nnrp.access OR you didn't issue the "ctlinnd reload"
command correctly (or at all) OR nntphost thinks that "client" is
called yet something else OR innd can't exec nnrpd for one reason or
another -- see the syslog output or the innd.err log file. Check all
of those things then go to the beginning of this section and start

Note: Some telnet implementations are Real Stupid and disconnect you
before showing the error message.

You can also run nnrpd by hand if you have
	stdin:Read Post:::*
in your nnrp.access file. Just run nnrpd and type interactively. This
is useful for making sure it's compiled right.


[Source: INN FAQ Part 4 Archive-name: usenet/software/inn-faq/part4]
[Last Changed: $Date: 1997/08/26 01:26:21 $ $Revision: 2.19 $]
[Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.]

(Corrections, notes, and links by Mib Software)

Debugging tip: The news.notice log will usually show what IP address was attempting the connect, if it was successful, or rejected.

NNRP_GETHOSTBYADDR (config.dist Section 6) controls whether the reverse DNS lookup is done by nnrpd.

More Detailed Topics
NNTP Protocol
INN FAQ Connecting to a TCP/IP server.

Overview and Related Topics
INN FAQ Make sure that "feeders" can connect.

Up to: INN FAQ Table Of Contents for Part 4/9
Up to: Usenet RKT For Providers...Troubleshooting INN
Up to: INN Setup and Changes

RKT Rapid-Links:[ Search ] [ RKT Tips ] Path: Usenet RKT / For Providers / INN FAQ / Part 4 / 0009.htm

You are reading from the Usenet RKT
Copyright 1997-1999, Forrest J. Cavalier III, Mib Software
INN customization and consulting
E-mail comments