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 command. 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 problem. 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 file. 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 "137.202.177.3". 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- :!* *.mentorg.com:Read:::* *.mentor.com:Read:::* *.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 header. 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 over. 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. ------------------------------ [Last Changed: $Date: 1997/08/26 01:26:21 $ $Revision: 2.19 $] [Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.] |
